?

超時重傳是TCP協(xié)議保證數(shù)據(jù)可靠性的另一個重要機制，其原理是在發(fā)送某一個數(shù)據(jù)以后就開啟一個計時器，在一定時間內如果沒有得到發(fā)送的數(shù)據(jù)報的ACK報文，那么就重新發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。

1.超時

超時時間的計算是超時的核心部分，TCP要求這個算法能大致估計出當前的網絡狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網絡利用率不高。(2)定時太短會造成多次重傳，使得網絡阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器準確的措施。

1.1.遞推公式概說

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

R<-aR+(1-a)MRTP=Rb

其中a是一個經驗系數(shù)為0.1，b通常為2。注意，這是經驗，沒有推導過程，這個數(shù)值是可以被修改的。這個公式是說用舊的RTT(R)和新的RTT (M)綜合到一起來考慮新的RTT(R)的大小。但是，我們又看到，這種估計在網絡變化很大的情況下完全不能做出“靈敏的反應”（Jacoboson說的，不是偶說的，呵呵），于是就有下面的修正公式：

Err=M-AA<-A+gErrD<-D+h(|Err|-D)RTO=A+4D

具體的解釋請看書的228頁，這個遞推公式甚至把方差這種統(tǒng)計概念也使用了進來，使得偏差更加的小。而且，必須要指出的是，這兩組公式更新，都是在數(shù)據(jù)成功傳輸?shù)那闆r下才進行，在發(fā)生數(shù)據(jù)重新傳輸?shù)那闆r下，并不使用上面的公式進行網絡估計，理由很簡單，因為程序已經不在正常狀態(tài)下了，估計出來的數(shù)據(jù)也是沒有意義的。

1.2.RTO的初始化

RTO的初始化是由公式決定的，例如最初的公式，初始的值應該是1。而修正公式，初始RTO應該是A+4D。

1.3.RTO的更新

當數(shù)據(jù)正常傳輸?shù)那闆r下，我們就會用上面的公式來更新各個數(shù)據(jù)，并重開定時器，來保證下一個數(shù)據(jù)被順利傳輸。要注意的是：重傳的情況下，RTO不用上面的公式計算，而采用一種叫做“指數(shù)退避”的方式。例如：當RTO為1S的情況下，發(fā)生了數(shù)據(jù)重傳，我們就用RTO=2S的定時器來重新傳輸數(shù)據(jù)，下一次用4S。一直增加到64S為止。

1.4.估計器的初始化

在這里，SYN用的估計器初始化似乎和傳輸用的估計器不一樣（我也沒有把握）造我的理解，在修正公式中，SYN的情況下，A初始化為0,D初始化為3S。

而在得到傳輸?shù)谝粋€數(shù)據(jù)的ACK的時候，應該按照下面的公式進行初始化：

A=M+0.5D=A/2

1.5.估計器的更新

和上面的討論差不多，就是在正常情況下，用上面的公式計算，在重傳的情況下，不更新估計器的各種參數(shù)。原因還是因為估計不準確。

1.6.Karn算法

這不算是一個算法，這應該是一個策略，說的就是更新RTO和估計器的值的時機選擇問題，1.3.和1.5.所說得更新時機就是Karn算法。

1.7.計時器的使用

兩句話:

一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續(xù)發(fā)出3組數(shù)據(jù)，只有一組數(shù)據(jù)會被測量。

ACK數(shù)據(jù)報不會被測量，原因很簡單，沒有ACK的ACK回應可以供結束定時器測量。

2.重傳

有了超時就要有重傳，但是就算是重傳也是有策略的，而不是將數(shù)據(jù)簡單的發(fā)送。

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

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

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

算法概要(直接從書中拷貝)

對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個字節(jié)。

TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發(fā)送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發(fā)送方感受到的網絡擁塞的估 計，而后者則與接收方在該連接上的可用緩存大小有關。

當擁塞發(fā)生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置為1個報文段（這就是慢啟動）。

當新的數(shù)據(jù)被對方確認時，就增加cwnd，但增加的方法依賴于我們是否正在進行慢啟動或擁塞避免。如果cwnd小于或等于ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續(xù)到我們回到當擁塞發(fā)生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們制造麻煩的窗口大小的一半），然后轉為執(zhí)行擁塞避免。

補充上面的擁塞避免公式在P238頁。這整個的流程讓我聯(lián)想到開車換檔的過程。

2.2.快速重傳和快速恢復算法

這是數(shù)據(jù)丟包的情況下給出的一種修補機制。一般來說，重傳發(fā)生在超時之后，但是如果發(fā)送端接受到3個以上的重復ACK的情況下，就應該意識到，數(shù)據(jù)丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以后，因為走的不是慢啟動而是擁塞避免算法，所以這又叫做快速恢復算法。流程如下：

當收到第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之間的所有中間報文段的確認。這一步采用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。

2.3.ICMP會引起重新傳遞么？

答案是：不會，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤并且通知用戶。

2.4.重新分組

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

?

總結

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

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