TCP逾時重傳機制

逾時重傳是TCP協定保證數據可靠性的另一個重要機制，其原理是在傳送某一個數據以後就開啟一個計時器，在一定時間內如果沒有得到傳送的數據報的ACK報文，那么就重新傳送數據，直到傳送成功為止。

基本介紹

• 中文名：TCP逾時重傳機制

簡介

TCP可靠性中最重要的一個機制是處理數據逾時和重傳。TCP協定要求在傳送端每傳送一個報文段，就啟動一個定時器並等待確認信息；接收端成功接收新數據後返回確認信息。若在定時器逾時前數據未能被確認，TCP就認為報文段中的數據已丟失或損壞，需要對報文段中的數據重新組織和重傳。儘管逾時重傳的概念十分簡單，但是在實現中，TCP處理逾時重傳的機制與其他可靠性協定相比是相當複雜的。

重傳逾時時間

RTO

影響逾時重傳機制協定效率的一個關鍵參數是重傳逾時時間（RTO，Retransmission TimeOut）。RTO的值被設定過大過小都會對協定造成不利影響。如果RTO設定過大將會使傳送端經過較長時間的等待才能發現報文段丟失，降低了連線數據傳輸的吞吐量；另一方面，若RTO過小，傳送端儘管可以很快地檢測出報文段的丟失，但也可能將一些延遲大的報文段誤認為是丟失，造成不必要的重傳，浪費了網路資源。

RTO的設定

如果底層網路的傳輸特性是可預知的，那么重傳機制的設計相對簡單得多，可根據底層網路的傳輸時延的特性選擇一個合適的RTO，使協定的性能得到最佳化。但是TCP的底層網路環境是一個完全異構的互聯結構。在實現端到端的通信時，不同端點之間傳輸通路的性能可能存在著巨大的差異，而且同一個TCP連線在不同的時間段上，也會由於不同的網路狀態具有不同的傳輸時延。

因次，TCP協定必須適應兩個方面的時延差異：一個是達到不同目的端的時延的差異，另一個是統一連線上的傳輸時延隨業務量負載的變化而出現的差異。為了處理這種底層網路傳輸特性的差異性和變化性，TCP的重傳機制相對於其他協定顯然也將更為複雜，其複雜性主要表現在對逾時時間間隔的處理上。為此，TCP協定使用自適應算法（Adaptive Retransmission Algorithm）以適應網際網路分組傳輸時延的變化。這種算法的基本要點是TCP監視每個連線的性能（即傳輸時延），由此每一個TCP連線推算出合適的RTO值，當連線時延性能變化時，TCP也能夠相應地自動修改RTO的設定，以適應這種網路的變化。

連線往返時間

RTT

對一個連線而言，若能夠了解端點間的傳輸往返時間（RTT，Round Trip Time），則可根據RTT來設定一合適的RTO。顯然，在任何時刻連線的RTT都是隨機的，無法事先預知。TCP通過測量來獲得連線當前RTT的一個估計值，並以該RTT估計值為基準來設定當前的RTO。自適應重傳算法的關鍵就在於對當前RTT的準確估計，以便適時調整RTO。

為了蒐集足夠的數據來精確地估算當前的RTT，TCP對每個報文都記錄下傳送出的時間和收到的確認時間。每一個（傳送時間，確認時間）對就可以計算出一個RTT測量值的樣本（Sample RTT）。TCP為每一個活動的連線都維護一個當前的RTT估計值。該值是對已經過去的一個時間段內該連線的RTT了兩隻的加權平均，並作為TCP對連線當前實際的RTT值的一種估計。RTT估計值將在傳送報文段時被用於確定報文段的RTO。為了保證它能夠比較準確地反應當前的網路狀態，每當TCP通過測量獲得了個新的RTT樣本時，都將對RTT的估計值進行更新。不同的更新算法或參數可能獲得不同的特性。

最早的TCP曾經用了一個非常簡單的公式來估計當前網路的狀況，如下

R<-aR+(1-a)MRTP=Rb其中a是一個經驗係數為0.1，b通常為2。注意，這是經驗，沒有推導過程，這個數值是可以被修改的。這個公式是說用舊的RTT(R)和新的RTT (M)綜合到一起來考慮新的RTT(R)的大小。但又可以看到，這種估計在網路變化很大的情況下完全不能做出“靈敏的反應”，於是就有下面的修正公式：

Err=M-AA<-A+gErrD<-D+h(|Err|-D)RTO=A+4D，這個遞推公式甚至把方差這種統計概念也使用了進來，使得偏差更加的小。而且，必須要指出的是，這兩組公式更新，都是在 數據成功傳輸的情況下才進行，在發生數據重新傳輸的情況下，並不使用上面的公式進行網路估計，理由很簡單，因為程式已經不在正常狀態下了，估計出來的數據 也是沒有意義的。

RTT的精確估值測量—Karn算法

如果在一個報文段中的數據被一次性地成功傳輸和確認，那么傳送端可以準確得到該報文段傳輸的RTT樣本。但若出現了重傳，情況就會變得很複雜。例如，一個報文段傳送後出現逾時，TCP將在另一個報文段中重傳。由於這兩個報文段包含了同樣的數據，傳送方接收到確認信息時將無法分辨出確認信息到底是針對哪個報文段的，因為這兩個報文段產生的確認信息可能是完全相同的，確認信息既可能是針對原始報文段的（這種情況可能是由於原報文段或確認在傳輸中被延遲造成的），也可能是對重傳報文段的確認。這種現象稱為確認二義性（Acknowledgement Ambiguiity）。確認的二義性將導致TCP無法準確地估算RTT。

為了避免確認二義性帶來的問題，TCP採用了Karn算法來維護RTT的估計值。Karn算法規定，TCP只能利用沒有確認二義性（既無重發、一次傳送成功並得到確認的報文段）的RTT樣本來對RTT的估計值進行調整。

重傳

有了逾時就要有重傳，但是就算是重傳也是有策略的，而不是將數據簡單的傳送。

重傳時傳送數據的大小

前面曾經提到過，數據在傳輸的時候不能只使用一個視窗協定，還需要有一個擁塞視窗來控制數據的流量，使得數據不會一下子都跑到網路中引起“擁 塞”。也曾經提到過，擁塞視窗最初使用指數增長的速度來增加自身的視窗，直到發生逾時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免算法和 慢啟動門限就是為此而生。

所謂的慢啟動門限就是說，當擁塞視窗超過這個門限的時候，就使用擁塞避免算法，而在門限以內就採用慢啟動算法。所以這個標準才叫做門限，通常，擁塞視窗記做cwnd，慢啟動門限記做ssthresh。下面來看看擁塞避免和慢啟動是怎么一起工作的。

算法概要

對一個給定的連線，初始化cwnd為1個報文段，ssthresh為65535個位元組。TCP輸出例程的輸出不能超過cwnd和接收方通告視窗的大小。擁塞避免是傳送方使用 的流量控制，而通告視窗則是接收方進行的流量控制。前者是傳送方感受到的網路擁塞的估 計，而後者則與接收方在該連線上的可用快取大小有關。當擁塞發生時（逾時或收到重複確認），ssthresh被設定為當前視窗大小的一半（cwnd 和接收方通告視窗大小的最小值，但最少為2個報文段）。此外，如果是逾時引起了擁塞，則 cwnd被設定為1個報文段（這就是慢啟動）。當新的數據被對方確認時，就增加cwnd，但增加的方法依賴於是否正在進行慢啟動或擁塞避免。如果cwnd小於或等於ssthresh，則正 在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續到回到當擁塞發生時所處位置的半時候才停止（因為記錄了在步驟2 中製造麻煩的視窗大小的一半），然後轉為執行擁塞避免。

快速重傳和快速恢復算法

這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在逾時之後，但是如果傳送端接受到3個以上的重複ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，它可以避免傳送端因等待重傳計時器的逾時而空閒較長時間，以此增加網路吞吐量。而重新傳遞以後，因為走的不是慢啟動而是擁塞避免算法，所以這又叫做快速恢復算法。流程如下：

當收到第3個重複的ACK時，將ssthresh設定為當前擁塞視窗cwnd的一半。重傳丟失的 報文段。設定cwnd為ssthresh加上3倍的報文段大小。每次收到另一個重複的ACK時， cwnd增加1個報文段大小並傳送1個分組（如果新的 cwnd允許傳送）。當下一個確認新數據的ACK到達時，設定cwnd為ssthresh（在第1步中設定的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該是對丟失的分組和收到的第1個重複的ACK之間的所有中間報文段 的確認。這一步採用的是擁塞避免。ICMP不會引起重新傳遞，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤並且通知用戶。

重新分組

TCP為了提高自己的效率，允許再重新傳輸的時候，只要傳輸包含重傳數據報文的報文就可以，而不用只重傳需要傳輸的報文。