超時重傳的時間計算

我們都知道，tcp傳送方在規定時間內沒有收到確認就要重傳已傳送的報文段（裡面有乙個超時計數器），這個邏輯很簡單，但是這個超時計數器的值每次都是不一樣的，也就是說：重傳時間的選擇是不一樣的，它是如何確定的呢？？？

tcp下層是網際網路環境，傳送的報文段可能只經過乙個高速率的區域網，也可能經過多個低速率的網路，並且每個ip資料報所選擇的路由還可能不同。如果把超時重傳時間設定太短，就會引起很多報文段的不必要的重傳，使網路負荷增大。但若把超時重傳時間設定的太長，那麼網路空閒時間會增大，極大的降低了網路的效率

到底應該設定為多大呢？？？？

tcp採用了一種自適應演算法，它記錄乙個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間rtt。tcp保留了rtt的乙個加權平均往返時間rtts（這又成為平滑的往返時間，s表示smoothed。因為進行的是加權平均，因此獲得的結果更加平滑，也就是讓我們計算出的結果更加合理）。每回的第一次測量到rtt樣本時，rtts值就取為所測量到的rtt樣本值，但以後每次測量到乙個新的rtt樣本，就按下面的公式重新計算一次rtts：

新的rtts=（1-α）×（舊的rtts）+α×（新的rtt樣本）

rfc 2988：推薦的α（阿爾法）值為1/8,也就是0.125 （這種方式得出的值更為平滑）

顯然：超時計數器設定的超時重傳時間rto（retransmission time-out）應略大於上面計算的結果。同樣的：

rfc  2988：建議使用下面的公式計算rto：

rto=rtts+4×rttd

新的rttd=（1-β）×（舊的rttd）+ β × | 新的rtt樣本-rtts |

好了，通過上面這些東西：我們就可以求出超時計數器所要設定的時間問題了，但是，但是，但是，新的問題也來了？

傳送乙個報文段，設定的重傳時間到了，還沒有收到確認。於是重傳報文段，經過一段時間後：收到了確認報文段。

現在的問題是：如何判定此報文段是對先傳送的報文段的確認，還是對後來重傳的報文段的確認？？？由於重傳的報文段和原來的報文段完全一樣，所以源主機在接受到確認後，無法做出正確的判斷，而正確的判斷對確定加權平均rtts的值關係很大。

1，若收到的是對重傳報文段的確認，但卻被源主機當作是對原來報文段的確認，則計算出的rtts和超時重傳時間rto就會偏大。若後面再傳送的報文段又是經過重傳後才收到的確認報文段，則rto這個時間會越來越長。直接影響效率

2，若收到的是對原來的報文段的確認，但被當作是對重傳報文段的確認，則由此計算出的rtts和rto都會偏小，這樣就會導致過多的重傳，使的rto越來越小

根據以上所說：karn提出了乙個演算法：在計算加權平均rtts時，只要報文段重傳了，就不採用其往返時間樣本。這樣得出的加權平均rtts和rto就相對比較準確了。

但是，但是，要是出現這樣的情況呢？？：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據karn演算法，不考慮重傳的報文段的往返時間樣本。這樣：超時重傳時間就無法更新。

因此：要對karn演算法進行修正：方法是：報文段每重傳一次，就把超時衝傳時間rto增大一些。典型的做法是：取新的重傳時間為2倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出公式計算超時重傳時間。

超時重傳的時間計算

我們都知道，tcp傳送方在規定時間內沒有收到確認就要重傳已傳送的報文段 裡面有乙個超時計數器 這個邏輯很簡單，但是這個超時計數器的值每次都是不一樣的，也就是說 重傳時間的選擇是不一樣的，它是如何確定的呢？tcp下層是網際網路環境，傳送的報文段可能只經過乙個高速率的區域網，也可能經過多個低速率的網路，...

TCP 超時重傳

tcp是一種可靠的協議，在網路互動的過程中，由於tcp報文是封裝在ip協議中的，ip協議的無連線特性導致其可能在互動的過程中丟失，在這種情況下，tcp協議如何保障其傳輸的可靠性呢？t c p通過在傳送資料報文時設定乙個超時定時器來解決這種問題，如果在定時器溢位時還沒有收到來自對端對傳送報文的確認，它...

tcp超時重傳

重傳定時器 tcp 必須維護乙個重傳定時器，以進行超時重傳 問題 如何設定超時時間間隔 rto？時間間隔太短則可能導致大量不必要的重傳 太長則導致效能下降 tcp 採用了乙個高度動態的演算法，來不斷的調整時間間隔，這個演算法就是 jacobson 1988 演算法 在此演算法中，tcp 需要維護幾個...