2.2 快重傳和快恢復

    如果傳送方設定的超時計時器時限已到但還沒有收到確認，那麼很可能是網路出現了擁塞，致使報文段在網路中的某處被丟棄。這時，TCP馬上把擁塞視窗 cwnd 減小到1，並執行慢開始演算法，同時把慢開始門限值ssthresh減半。這是不使用快重傳的情況。

    快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認（為的是使傳送方及早知道有報文段沒有到達對方）而不要等到自己傳送資料時才進行捎帶確認。

接收方收到了M1和M2後都分別發出了確認。現在假定接收方沒有收到M3但接著收到了M4。顯然，接收方不能確認M4，因為M4是收到的失序報文段。根據可靠傳輸原理，接收方可以什麼都不做，也可以在適當時機發送一次對M2的確認。但按照快重傳演算法的規定，接收方應及時傳送對M2的重複確認，這樣做可以讓傳送方及早知道報文段M3沒有到達接收方。傳送方接著傳送了M5和M6。接收方收到這兩個報文後，也還要再次發出對M2的重複確認。這樣，傳送方共收到了接收方的四個對M2的確認，其中後三個都是重複確認。快重傳演算法還規定，傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段M3，而不必繼續等待M3設定的重傳計時器到期。由於傳送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網路吞吐量提高約20%。

    與快重傳配合使用的還有快恢復演算法，其過程有以下兩個要點：

    <1>. 當傳送方連續收到三個重複確認，就執行“乘法減小”演算法，把慢開始門限ssthresh減半。這是為了預防網路發生擁塞。請注意：接下去不執行慢開始演算法。

    <2>. 由於傳送方現在認為網路很可能沒有發生擁塞，因此與慢開始不同之處是現在不執行慢開始演算法（即擁塞視窗cwnd現在不設定為1），而是把cwnd值設定為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法（“加法增大”），使擁塞視窗緩慢地線性增大。

    下圖給出了快重傳和快恢復的示意圖，並標明瞭“TCP Reno版本”。

    區別：新的 TCP Reno 版本在快重傳之後採用快恢復演算法而不是採用慢開始演算法。

 也有的快重傳實現是把開始時的擁塞視窗cwnd值再增大一點，即等於 ssthresh + 3 X MSS 。這樣做的理由是：既然傳送方收到三個重複的確認，就表明有三個分組已經離開了網路。這三個分組不再消耗網路 的資源而是停留在接收方的快取中。可見現在網路中並不是堆積了分組而是減少了三個分組。因此可以適當把擁塞視窗擴大了些。

    在採用快恢復演算法時，慢開始演算法只是在TCP連線建立時和網路出現超時時才使用。

    採用這樣的擁塞控制方法使得TCP的效能有明顯的改進。

    接收方根據自己的接收能力設定了接收視窗rwnd，並把這個視窗值寫入TCP首部中的視窗欄位，傳送給傳送方。因此，接收視窗又稱為通知視窗。因此，從接收方對傳送方的流量控制的角度考慮，傳送方的傳送視窗一定不能超過對方給出的接收視窗rwnd 。

    傳送方視窗的上限值 = Min [ rwnd, cwnd ]

    當rwnd < cwnd 時，是接收方的接收能力限制傳送方視窗的最大值。

    當cwnd < rwnd 時，則是網路的擁塞限制傳送方視窗的最大值。