上次，我們談到了24個數據段。傳輸過程中丟失四段怎么辦？我們將繼續關注這一進程。接收方接收20個數據段，同時向發送方發回20個確認段。一段時間后，之前丟失的四個數據段的重傳定時器到期，發送方判斷網絡可能擁塞，于是進行下面的工作。

首先，當發生擁塞時，將慢啟動閾值更新為擁塞窗口cwnd的一半。

第二，將擁塞窗口cwnd的值減小到1，并重新啟動慢啟動算法。當執行慢啟動算法直到擁塞窗口cwnd增長到新的慢啟動門權限值時，停止慢啟動算法，而執行擁塞避免算法。

從這個例子可以看出，TCP發送方一開始使用慢啟動算法，使得擁塞窗口cwnd的值從一開始就呈指數級增長。當擁塞窗口cwnd的值增加到初始慢啟動閾值時，停止慢啟動算法，代之以執行擁塞避免算法，使得擁塞窗口cwnd的值線性增加加1。當發生超時重傳時，需要判斷網絡可能發生擁塞，并采取相應的措施。一方面在發生擁塞時將慢啟動閾值更新為擁塞窗口cwnd的一半，另一方面將擁塞窗口cwnd的值減小為1，重新啟動慢啟動算法。擁塞窗口cwnd的值從開始呈指數增加。當它達到新的慢啟動閾值時，停止使用慢啟動算法，而是實現擁塞避免算法，以便

需要注意的是，慢啟動是指開始時注入網絡的段較少，不是說擁塞窗口cwnd增長緩慢，擁塞地也不是說云擁塞可以完全避免，而是在擁塞避免階段控制擁塞窗口線性增長，使網絡不容易擁塞。

慢啟動和擁塞避免算法是1988年提出的TCP擁塞控制算法，即TCP的其他版本。1990年，增加了兩種新的擁塞控制算法來提高TCP的性能。這就是快速重傳快速恢復，被稱為Reno版的TCP。

有時候個別段會在網絡中丟失，但實際上網絡并不擁塞，這會導致發送方超時重傳，誤以為網絡擁塞。比如前面的例子，當擁塞窗口增大到24時，發生超時重傳，但此時網絡并不擁塞，而是發送方誤以為網絡擁塞，于是發送方錯誤地重啟慢啟動算法，將擁塞窗口cwnd設置為最小值1，從而降低了傳輸效率。使用快速重傳算法，發送方可以盡早知道各個數據段的重傳。所謂快速重傳，就是讓發送方盡快重傳，而不是等到超時重傳定時器再重傳。

這要求接收方立即發送確認，而不是等待自己發送數據。即使收到了丟失的數據段，也應立即發送收到數據段的重復確認。一旦發送方收到三個連續的重復確認，它將立即重傳相應的數據段，而不是等待該數據段的重傳計時器超時。

接下來，我們將說明快速重傳算法。我們仍然用圖表來講述故事。上一篇文章再說吧。下次見。