滑動窗口與擁塞窗口

滑動窗口協議是傳輸層進行流控的一種措施,接收方通過通告發送方自己的窗口大小,從而控制發送方的發送速度,從而達到防止發送方發送速度過快而導致自己被淹沒的目的。

對ACK的再認識,ack通常被理解爲收到數據後給出的一個確認。事實上該確認是指接收端已經收到確認楨以前的所有的楨。舉個例子,假如接收端收到 1-1024字節,它會發送一個確認號爲1025的ACK,但是接下來收到的是2049-3072,它是不會發送確認號爲3072的ACK,而依舊發送 1025的ACK。

滑動窗口協議如圖所示:




在這個圖中,我們將字節從1至11進行標號。接收方通告的窗口稱爲提出的窗口,它覆蓋了從第4字節到第9字節的區域,表明接收方已經確認了包括第3字節在 內的數據,且通告窗口大小爲6。我們知道窗口大小是與確認序號相對應的。發送方計算它的可用窗口,該窗口表明多少數據可以立即被髮送。當接收方確認數據 後,這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或減少了窗口的大小。我們使用三個術語來描述窗口左右邊沿的運動:

  • 稱窗口左邊沿向右邊沿靠近爲窗口合攏。這種現象發生在數據被髮送和確認時。 
  • 當窗口右邊沿向右移動時將允許發送更多的數據,我們稱之爲窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了T C P的接收緩存時。 
  • 當右邊緣向左移動時,稱之爲窗口收縮。

二、擁塞窗口
迄今爲止,在本章所有的例子中,發送方一開始便向網絡發送多個報文段,直至達到接收方通告的窗口大小爲止。當發送方和接收方處於同一個局域網時,這種方式 是可以的。但是如果在發送方和接收方之間存在多個路由器和速率較慢的鏈路時,就有可能出現一些問題。一些中間路由器必須緩存分組,並有可能耗盡緩存, [Jacobson 1988]證明了這種連接方式是如何嚴重降低了TCP連接的吞吐量的。現在,TCP需要支持一種被稱爲“慢啓動(slow start)”的算法。該算法通過觀察到新分組進入網絡的速率應該與另一端返回確認的速率相同而進行工作。
慢啓動爲發送方的TCP增加了另一個窗口:擁塞窗口(congestion window),記爲cwnd。當與另一個網絡的主機建立TCP連接時,擁塞窗口被初始化爲1個報文段(即另一端通告的報文段大小)。每收到一個ACK, 擁塞窗口就增加一個報文段(cwnd以字節爲單位,但是慢啓動以報文段大小爲單位進行增加)。發送方取擁塞窗口與通告窗口中的最小值作爲發送上限。擁塞窗 口是發送方使用的流量控制,而通告窗口則是接收方使用的流量控制。

發送方開始時發送一個報文段,然後等待ACK。當收到該ACK時,擁塞窗口從1增加爲2,即可以發送兩個報文段。當收到這兩個報文段的ACK時,擁塞窗口就增加爲4。這是一種指數增加的關係。

原文地址:http://blog.chinaunix.net/uid-27164517-id-3335260.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章