TCP 滑動窗口

• 滑動窗口協議
  • 流量控制方法
• PUSH
• 慢啓動

 

隔一個報文段確認」的策略實際就是由於 delayed ack，同時接收到兩個待確認的ACK包時，就當即發送確認包。

 

滑動窗口實例

---

 

解決了快的發送方-》慢的接收方

 

• 發送方發送 4個背靠背（back-to-back）的數據報文段去填充接收方的窗口，而後停下來等待一個ACK。
• 接收方發送 ACK（報文段 8），但通告其窗口大小爲 0，這說明接收方已收到全部數據，但這些數據都在接收方的 TCP緩衝區，由於應用程序尚未機會讀取這些數據。
• 另外一個ACK，窗口更新 在17.4ms後發送，代表接收方如今能夠接收另外的4096個字節的數據。
• 發送方發送最後4個報文段(10~13)，再次填充了接收方的窗口。
• • 注意到報文段13中包括兩個比特標誌：PUSH和FIN。
• 隨後從接收方傳來另外兩個 ACK，它們確認了最後的 4096字節的數據（從4097到8192字節）和FIN（標號爲8192）

 

滑動窗口協議：

 

 

 

• 窗口大小6個字節，覆蓋第4-9字節
  • 說明字節1-3 是發送並被確認的
• 窗口大小起始於確認序號字段。
  • 發送方能夠計算它的可用窗口，
    • 好比窗口大小6，已經被確認1-3，發送但未被確認4-6，則可用窗口大小3，起始第7序號
    • 可用窗口代表有多少數據能夠當即被髮送
• 當接收方確認數據後，這個滑動窗口不時地向右移動。
• 窗口左右邊沿的運動現象的三個術語
  • 左邊沿向右靠近----窗口合攏
    • 現象發生在數據被髮送和確認時。
  • 右邊沿向右靠近----窗口張開
    • 將容許發送更多的數據
    • 現象發生在接收端進程讀取已經確認的數據並釋放了TCP的接收緩存時。
  • 右邊沿向左靠近----窗口收縮
    • RFC 強烈建議不要使用這種方式
    • 但TCP 有特殊場景會使用到
• 若是左邊沿到達右邊沿，則稱其爲一個零窗口，此時發送方不可以發送任何數據

 

 

對應上圖的滑動窗口協議的動態性

 

 

窗口大小

由接收方提供的窗口的大小一般能夠由接收進程控制，這將影響 TCP的性能

 

PUSH標誌

• 發送方使用該標誌通知接收方將全部接收到的數據所有提交給接收進程
• 包括與PUSH一塊兒傳送的數據以及接收方TCP 已經接收到的其餘數據

 

慢啓動

• 出現緣由
• • 在發送與接收方存在多個路由器和速率較慢的鏈路時
  • • 中間路由器必須緩存分組包，並可能耗盡存儲器的空間
    • 嚴重下降TCP鏈接的吞吐量
• 工做原理
• • 觀察新分組進入網絡的速率應該與另外一端返回確認的速率相同而進行工做。
  • 慢啓動爲發送方增長另外一個窗口：擁塞窗口(congestion window) cwnd.
  • • 當創建TCP鏈接時，擁塞窗口被初始化爲1個報文段（即另外一端通告的報文段大小）
    • 每收到一個ACK，擁塞窗口就增長一個報文段，擁塞窗口從1增長到2，便可以發送兩個報文段。
    • 發送方取擁塞窗口與通告窗口中的最小值做爲發送上限。
• 擁塞窗口是發送方使用的流量控制
• 通告窗口則是接收方使用的流量控制

 

 

 

capacity(bit) = bandwidth(b/s) * round-trip(s)

            容量  = 帶寬 * 延時

 

電話線每193bit 有1個做爲 幀同步

所以原始比特率 1544000 b/s --》 實際比特率 1544000/193=8000,1544000-8000=1536000 b/s

 

計算滑動窗口大小：

有人抱怨說美國和日本之間的一個 128 ms時延、速率爲256 000 b/s的鏈

路吞吐量爲120 000 b/s（利用率爲47 %），而當鏈路經過衛星時其吞吐量則爲33 000 b/s（利用

率爲13％）。試問在這兩種狀況下窗口大小各爲多少（假定衛星鏈路的時延爲 500 ms）？衛星

鏈路的窗口大小應該如何調整？

 

1.吞吐量12000 b/s * 延時128ms =15360 b  / 8 =1920 bit

 

2.鏈路經過衛星

吞吐量33000 b/s * 延時500ms =16500 b /8 = 2062 bit