(6.7)-7.TCP可靠傳輸?shù)膶崿F(xiàn)

以字節(jié)為單位的滑動窗口

超時重傳時間的選擇

TCP可靠傳輸?shù)膶崿F(xiàn)根據(jù)B給出的確認號和窗口值（確認號31，窗口值20個字節(jié)），A構(gòu)造出自己的發(fā)送窗口。發(fā)送窗口表示：在沒有收到B的確認的情況下，A可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。發(fā)送窗口里面的序號表示允許發(fā)送的序號。（31-50）顯然，窗口越大，發(fā)送方就可以在收到對方確認之前連續(xù)發(fā)送更多的數(shù)據(jù)，因而可能獲得更高的傳輸效率。前移不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口=20允許發(fā)送的序號26272829303132333435363738394041424344454647484950515253545556B期望收到的序號前沿后沿前移收縮TCP標準強烈不贊成發(fā)送窗口前沿向后收縮A發(fā)送了11個字節(jié)的數(shù)據(jù)P3–P1

=A的發(fā)送窗口（又稱為通知窗口）P2–P1=已發(fā)送但尚未收到確認的字節(jié)數(shù)P3

–P2

=允許發(fā)送但尚未發(fā)送的字節(jié)數(shù)（又稱為可用窗口）不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口位置不變允許發(fā)送但尚未發(fā)送262728293031323334353637383940414243444546474849505152535455已發(fā)送但未收到確認56P1P2P3不允許接收已發(fā)送確認并交付主機B的接收窗口允許接收26272829303132333435363738394041424344454647484950515253545556未按序收到可用窗口TCP標準強烈不贊成發(fā)送窗口前沿向后收縮允許接收B的接收窗口向前滑動262728293031323334353637383940414243444546474849505152535455已發(fā)送確認并交付主機不允許接收56未按序收到先存下，等待缺少的數(shù)據(jù)的到達A發(fā)送了11個字節(jié)的數(shù)據(jù)不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口位置不變允許發(fā)送但尚未發(fā)送26272829303132333435363738394041424344454647484950已發(fā)送但未收到確認515253545556P1P2P3可用窗口A收到新的確認號，發(fā)送窗口向前滑動允許發(fā)送但尚未發(fā)送A的發(fā)送窗口向前滑動262728293031323334353637383940414243444546474849505152535455已發(fā)送并收到確認不允許發(fā)送已發(fā)送但未收到確認56P1P2P3允許接收B的接收窗口向前滑動262728293031323334353637383940414243444546474849505152535455已發(fā)送確認并交付主機不允許接收56未按序收到先存下，等待缺少的數(shù)據(jù)的到達A的發(fā)送窗口內(nèi)的序號都已用完，P2與P3重合，但還沒有再收到確認，必須停止發(fā)送。已發(fā)送但未收到確認A的發(fā)送窗口已滿，有效窗口為零262728293031323334353637383940414243444546474849505152535455已發(fā)送并收到確認不允許發(fā)送56P1P3P2發(fā)送窗口內(nèi)的序號都屬于已發(fā)送但未被確認發(fā)送緩存發(fā)送窗口通常只是發(fā)送緩存的一部分。最后被確認的字節(jié)發(fā)送應用程序發(fā)送緩存最后發(fā)送的字節(jié)發(fā)送窗口已發(fā)送TCP序號增大下一個期望收到的字節(jié)（確認號）接收應用程序接收緩存接收窗口已收到TCP序號增大下一個讀取的字節(jié)接收緩存需要強調(diào)兩點第一，A的發(fā)送窗口并不總是和B的接收窗口一樣大，因為有一定的時間滯后。還有就是A還可能根據(jù)網(wǎng)絡(luò)擁塞情況適當?shù)臏p小自己的發(fā)送窗口數(shù)值。第二，TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。接收方可以在合適的時候發(fā)送確認，也可以在自己有數(shù)據(jù)發(fā)送時捎帶上確認信息。但要注意，接收方不應過分推遲發(fā)送確認，否則會引起不必要的重傳，二是捎帶確認并不經(jīng)常發(fā)生，因為大多數(shù)應用程序很少同時在兩個方向上發(fā)送數(shù)據(jù)。

超時重傳時間的選擇重傳時間的選擇是TCP最復雜的問題之一。如果時間設(shè)置太短，就會引起很多報文段不必要的重傳；如果時間過長，又會使網(wǎng)絡(luò)空閑時間增大，降低傳輸效率。TCP每發(fā)送一個報文段，就對這個報文段設(shè)置一次計時器。只要計時器設(shè)置的重傳時間到但還沒有收到確認，就要重傳這一報文段。一種自適應算法:加權(quán)平均往返時間TCP保留了RTT的一個加權(quán)平均往返時間RTTS（這又稱為平滑的往返時間）。第一次測量到RTT樣本時，RTTS

值就取為所測量到的RTT樣本值。以后每測量到一個新的RTT樣本，就按下式重新計算一次RTTS：式中，0

1。若

很接近于零，表示RTT值更新較慢。若選擇

接近于1，則表示RTT值更新較快。RFC6298推薦的

值為1/8，即0.125。新的RTTS

(1

)

(舊的RTTS)+

(新的RTT樣本)超時重傳時間RTORTO(RetransmissionTime-Out)應略大于上面得出的加權(quán)平均往返時間RTTS。RFC6298建議使用下式計算RTO：RTTD

是RTT的偏差的加權(quán)平均值。RFC6298建議這樣計算RTTD

。第一次測量時，

RTTD值取為測量到的RTT樣本值的一半。在以后的測量中，則使用下式計算加權(quán)平均的RTTD

：

是個小于1的系數(shù)，其推薦值是1/4，即0.25。RTO=RTTS+4

RTTD

新的RTTD

=(1

)

(舊的RTTD)

+

RTTS

新的RTT樣本

Karn算法在計算平均往返時間RTT時，只要報文段重傳了，就不采用其往返時間樣本。這樣得出的加權(quán)平均平均往返時間RTTS

和超時重傳時間RTO就較準確。但是，這又引起新的問題。當報文段的時延突然增大了很多時，在原來得出的重傳時間內(nèi)，不會收到確認報文段。于是就重傳報文段。但根據(jù)Karn算法，不考慮重傳的報文段的往返時間樣本。這樣，超時