（二十四）運輸層--超時重傳時間的選擇

超時重傳時間的選擇

前文提到，TCP的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段，由於TCP的下層是互聯網環境，發送的報文段可能只經過一個高速率的局域網，也可能經過多個低速率的網絡，並且每個IP數據報所選擇的路由還可能不同。如果把超時重傳時間設置得太短，就會引起很多報文段的不必要的重傳，使網絡負荷增大。但若把超時重傳時間設置得過長，則又使網絡的空閒時間增大，降低了傳輸效率。

那麼，運輸層的超時計時器的超時重傳時間究竟應設置爲多大呢？

TCP採用了一種自適應算法，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間RTTS。當第一次測量到RTT樣本時，RTTS就取爲所測量到的RTT樣本，但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTS：

新的RTTS = （1 - α）x （舊的RTTS）+ α x （新的RTT樣本）

在上式中， 0 ≤ α ＜ 1。若 α 很接近於零，表示新的RTTS值和舊的RTTS值相比變化不大，而對新的RTT樣本影響不大。若 α 接近於1，則表示新的RTTS值受新的RTT樣本的影響較大。已成爲建議標準的RFC 6298 推薦 α 值爲 0.125。

顯然，超時重傳時間 RTO 應略大於上面得出的加權平均往返時間RTTS。RFC 6298 建議使用下式計算 RTO：

RTO = RTTS + 4 x RTTD

RTTD是RTT的偏差的加權平均值。它與RTTS和新的RTT樣本之差有關。RFC 6298 建議這樣計算RTTD。當第一次測量時，RTTD 值取爲測量到的RTT樣本值的一半。在以後的測量中，則使用下式計算加權平均的RTTD：

新的RTTD = （1 - β）x （舊的RTTD） + β x |RTTS - 新的RTT樣本|

β是一個小於1的係數，它的推薦值是0.25。

選擇確認SACK

若收到的報文段無差錯，只是未按序號，中間還缺少一些序號的數據，那麼能否設法只傳送缺少的數據而不重傳已經正確到達接收方的數據？答案是可以的，選擇確認就是一種可行的處理方法。

如下圖所示，TCP的接收方接收對方發送過來的數據字節流的序號不連續，結果形成了一些不連續的字節快。可以看出，序號1_{1000收到了，但序號1001}1500沒有收到。接下來的字節流又收到了，可是又缺少了3001~3500，從序號4501起又沒有收到。也就是說，接收方收到了和前面的字節流不連續的兩個字節塊。如果這些字節的序號都在接收窗口內，那麼接收方就先收下這些數據，但要把這些信息準確的告訴發送方，使發送方不要再重複發送這些已收到的數據。

從上圖可以看出，和前後字節不連續的每一個字節塊都有兩個邊界：左邊界和右邊界。左邊界指出字節塊的第一個字節的序號，右邊界減一指出了字節塊的最後一個序號。TCP的首部沒有哪個字段能夠提供上述這些字節塊的邊界信息。RFC 2018 規定，如果要使用選擇確認SACK，那麼在建立TCP連接時，就要在TCP首部的選項中加上“允許SACK”的選項，雙方必須事先商定好。如果使用選擇確認，那麼原來首部中的“確認號字段”的用法依然不變。只是以後在TCP報文段的首部中都增加了SACK選項，以便報告收到的不連續的字節塊的邊界。由於首部選項的長度最多隻有40字節，而指明一個邊界就要用掉4字節（序號32位），指明一個字節塊需要8個字節，還需要留出兩個字節，一個字節用來指明是SACK選項，另一個字節指明這個選項要佔用多少字節，所以選項中最多指明4個字節塊的邊界信息。

然而，SACK文檔並沒有指明發送方應當怎樣響應SACK。因此大多數的實現還是重傳所有未被確認的數據塊。