當乙個報文段丟失時，會等待一定的超時週期然後才重傳分組，增加了端到端的時延。
當乙個報文段丟失時，在其等待超時的過程中，可能會出現這種情況：其後的報文段已經被接收端接收但卻遲遲得不到確認，傳送端會認為也丟失了，從而引起不必要的重傳，既浪費資源也浪費時間。
幸運的是，由於tcp採用的是累計確認機制，即當接收端收到比期望序號大的報文段時，便會重**送最近一次確認的報文段的確認訊號，我們稱之為冗餘ack（duplicate ack）。
如圖所示，報文段1成功接收並被確認ack 2，接收端的期待序號為2，當報文段2丟失，報文段3失序到來，與接收端的期望不匹配，接收端重**送冗餘ack 2。
這樣，如果在超時重傳定時器溢位之前，接收到連續的三個重複冗餘ack（其實是收到4個同樣的ack，第乙個是正常的，後三個才是冗餘的），傳送端便知曉哪個報文段在傳輸過程中丟失了，於是重發該報文段，不需要等待超時重傳定時器溢位，大大提高了效率。這便是快速重傳機制。
首先要明白一點，即使傳送端是按序傳送，由於tcp包是封裝在ip包內，ip包在傳輸時亂序，意味著tcp包到達接收端也是亂序的，亂序的話也會造成接收端傳送冗餘ack。那傳送冗餘ack是由於亂序造成的還是包丟失造成的，這裡便需要好好權衡一番，因為把3次冗餘ack作為判定丟失的準則其本身就是估計值。
假定通訊雙方如下：
a為傳送端，b為接收端
a的待發報文段序號為 n-1,n,n+1,n+2
假設報文段n-1成功到達
從以上羅列的情況可以看出，
在沒丟失的情況下，有40%的可能出現3次冗餘ack
在亂序的情況下必定是2次冗餘ack
在丟失的情況下，必定出現3次冗餘ack
基於這樣的概率，選定3次冗餘ack作為閾值也算是合理的。在實際抓包中，大多數的快速重傳都會在大於3次冗餘ack後發生。
接收端快取佇列的視窗移動示意
TCP的快速重傳機制
幸運的是，由於tcp採用的是累計確認機制，即當接收端收到比期望序號大的報文段時，便會重 送最近一次確認的報文段的確認訊號，我們稱之為冗餘ack duplicate ack 如圖所示，報文段1成功接收並被確認ack 2，接收端的期待序號為2，當報文段2丟失，報文段3失序到來，與接收端的期望不匹配，接收...
TCP重傳機制
tcp進行傳輸時，發出去的請求包在規定時間內沒有收到ack，不管是請求包丟失，還是ack包丟失，還是網路延遲，總之，這裡都是需要有個重傳機制的。常見的導致重傳情況有 資料報傳輸途中丟失 接收端的ack確認報文在傳輸途中丟失 接收端異常未響應ack或被接收端丟棄。tcp的重傳機制有兩種 超時重傳和快速...
TCP的重傳機制
重傳機制是tcp 中最重要和最複雜的問題之一。tcp 每傳送乙個報文段，就對這個報文段設定一次計時器。只要計時器設定的重傳時間到 但還沒有收到確認，就要重傳這一報文段。由於tcp 的下層是乙個互連網環境，ip 資料報所選擇的路由變化很大。因而傳輸層的往返 時延的方差也很大。記錄每乙個報文段發出的時間...