TCP協(xié)議是一種面向連接的可靠的傳輸層協(xié)議，它保證了數(shù)據(jù)的可靠傳輸，對于一些出錯、超時丟包等問題TCP設計了超時重傳機制，其基本原理：在發(fā)送一個數(shù)據(jù)之后，就開啟一個定時器，若是在這個時間內沒有收到發(fā)送數(shù)據(jù)的ACK確認報文，則對該報文進行重傳，在達到一定次數(shù)還沒有成功時放棄并發(fā)送一個復位信號。

1、超時重傳時間

RTO(Retransmission TimeOut)，影響超時重傳機制協(xié)議效率的一個關鍵參數(shù)是重傳超時時間RTO，RTO的值被設置過大過小都會對協(xié)議造成不利影響。如果RTO設置過大將會使發(fā)送端經(jīng)過較長時間的等待才能發(fā)現(xiàn)報文段丟失，降低了連接數(shù)據(jù)傳輸?shù)耐掏铝?#xff1b;另一方面，若RTO過小，發(fā)送端盡管可以很快地檢測出報文段的丟失，但也可能將一些延遲大的報文段誤認為是丟失，造成不必要的重傳，浪費了網(wǎng)絡資源。 如果底層網(wǎng)絡的傳輸特性是可預知的，那么重傳機制的設計相對簡單得多，可根據(jù)底層網(wǎng)絡的傳輸時延的特性選擇一個合適的RTO，使協(xié)議的性能得到優(yōu)化。但是TCP的底層網(wǎng)絡環(huán)境是一個完全異構的互聯(lián)結構。在實現(xiàn)端到端的通信時，不同端點之間傳輸通路的性能可能存在著巨大的差異，而且同一個TCP連接在不同的時間段上，也會由于不同的網(wǎng)絡狀態(tài)具有不同的傳輸時延。 因次，TCP協(xié)議必須適應兩個方面的時延差異：一個是達到不同目的端的時延的差異，另一個是統(tǒng)一連接上的傳輸時延隨業(yè)務量負載的變化而出現(xiàn)的差異。為了處理這種底層網(wǎng)絡傳輸特性的差異性和變化性，TCP的重傳機制相對于其他協(xié)議顯然也將更為復雜，其復雜性主要表現(xiàn)在對超時時間間隔的處理上。為此，TCP協(xié)議使用自適應算法（Adaptive Retransmission Algorithm）以適應互聯(lián)網(wǎng)分組傳輸時延的變化。這種算法的基本要點是TCP監(jiān)視每個連接的性能（即傳輸時延），由此每一個TCP連接推算出合適的RTO值，當連接時延性能變化時，TCP也能夠相應地自動修改RTO的設定，以適應這種網(wǎng)絡的變化。 RTO一般是根據(jù)RTT來設置的。若 RTO 小于 RTT，則會造成很多不必要的重傳；若 RTO 遠大于 RTT，則會降低整體網(wǎng)絡利用率，RTO 是保證 TCP 性能的關鍵。并且不同連接的RTT不相同，同一個連接不同時間的 RTT 也不相同，所以 RTO 的設置一直都是研究熱點。

2、連接往返時間

RTT(Round Trip Time)，對一個連接而言，若能夠了解端點間的傳輸往返時間，則可根據(jù)RTT來設置一合適的RTO。顯然，在任何時刻連接的RTT都是隨機的，無法事先預知。TCP通過測量來獲得連接當前RTT的一個估計值，并以該RTT估計值為基準來設置當前的RTO。自適應重傳算法的關鍵就在于對當前RTT的準確估計，以便適時調整RTO。 為了搜集足夠的數(shù)據(jù)來精確地估算當前的RTT，TCP對每個報文都記錄下發(fā)送出的時間和收到的確認時間。每一個（發(fā)送時間，確認時間）對就可以計算出一個RTT測量值的樣本（Sample RTT）。TCP為每一個活動的連接都維護一個當前的RTT估計值。該值是對已經(jīng)過去的一個時間段內該連接的RTT了兩只的加權平均，并作為TCP對連接當前實際的RTT值的一種估計。RTT估計值將在發(fā)送報文段時被用于確定報文段的RTO。為了保證它能夠比較準確地反應當前的網(wǎng)絡狀態(tài)，每當TCP通過測量獲得了個新的RTT樣本時，都將對RTT的估計值進行更新。不同的更新算法或參數(shù)可能獲得不同的特性。

2.1、RTT的精確估值測量--Karn算法

如果在一個報文段中的數(shù)據(jù)被一次性地成功傳輸和確認，那么發(fā)送端可以準確得到該報文段傳輸?shù)腞TT樣本。但若出現(xiàn)了重傳，情況就會變得很復雜。例如，一個報文段發(fā)送后出現(xiàn)超時，TCP將在另一個報文段中重傳。由于這兩個報文段包含了同樣的數(shù)據(jù)，發(fā)送方接收到確認信息時將無法分辨出確認信息到底是針對哪個報文段的，因為這兩個報文段產(chǎn)生的確認信息可能是完全相同的，確認信息既可能是針對原始報文段的（這種情況可能是由于原報文段或確認在傳輸中被延遲造成的），也可能是對重傳報文段的確認。這種現(xiàn)象稱為確認二義性（Acknowledgement Ambiguiity）。確認的二義性將導致TCP無法準確地估算RTT。 為了避免確認二義性帶來的問題，TCP采用了Karn算法來維護RTT的估計值。Karn算法規(guī)定，TCP只能利用沒有確認二義性（既無重發(fā)、一次發(fā)送成功并得到確認的報文段）的RTT樣本來對RTT的估計值進行調整。

3、重傳

3.1、重傳時發(fā)送數(shù)據(jù)的大小

數(shù)據(jù)在傳輸?shù)臅r候不能只使用一個窗口協(xié)議，還需要有一個擁塞窗口來控制數(shù)據(jù)的流量，使得數(shù)據(jù)不會一下子都跑到網(wǎng)路中引起“擁塞”。擁塞窗口最初使用指數(shù)增長的速度來增加自身的窗口，直到發(fā)生超時重傳，再進行一次微調。但是如何進行微調，擁塞避免算法和慢啟動門限就是為此而生。 所謂的慢啟動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免算法，而在門限以內就采用慢啟動算法。所以這個標準才叫做門限，通常，擁塞窗口記做cwnd，慢啟動門限記做ssthresh。下面來看看擁塞避免和慢啟動是怎么一起工作的。

3.2、算法概要

對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個字節(jié)。TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發(fā)送方使用的流量控制，而通告窗口則是接收方進行的流量控制。前者是發(fā)送方感受到的網(wǎng)絡擁塞的估 計，而后者則與接收方在該連接上的可用緩存大小有關。當擁塞發(fā)生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。當新的數(shù)據(jù)被對方確認時，就增加cwnd，但增加的方法依賴于是否正在進行慢啟動或擁塞避免。如果cwnd小于或等于ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續(xù)到回到當擁塞發(fā)生時所處位置的半時候才停止（因為記錄了在步驟2 中制造麻煩的窗口大小的一半），然后轉為執(zhí)行擁塞避免。

3.3、快速重傳和快速恢復算法

這是數(shù)據(jù)丟包的情況下給出的一種修補機制。一般來說，重傳發(fā)生在超時之后，但是如果發(fā)送端接受到3個以上的重復ACK的情況下，就應該意識到，數(shù)據(jù)丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，它可以避免發(fā)送端因等待重傳計時器的超時而空閑較長時間，以此增加網(wǎng)絡吞吐量。而重新傳遞以后，因為走的不是慢啟動而是擁塞避免算法，所以這又叫做快速恢復算法。流程如下： 當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口cwnd的一半。重傳丟失的?報文段。設置cwnd為ssthresh加上3倍的報文段大小。每次收到另一個重復的ACK時， cwnd增加1個報文段大小并發(fā)送1個分組（如果新的 cwnd允許發(fā)送）。當下一個確認新數(shù)據(jù)的ACK到達時，設置cwnd為ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳后的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該是對丟失的分組和收到的第1個重復的ACK之間的所有中間報文段?的確認。這一步采用的是擁塞避免。ICMP不會引起重新傳遞，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤并且通知用戶。

3.4、重新分組

TCP為了提高自己的效率，允許再重新傳輸?shù)臅r候，只要傳輸包含重傳數(shù)據(jù)報文的報文就可以，而不用只重傳需要傳輸?shù)膱笪摹?

轉載于:https://www.cnblogs.com/Jummyer/p/11069075.html

總結

以上是生活随笔為你收集整理的TCP之超时重传机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。