【13】TCP/IP協議族詳解-TCP(2)

聲明:本博客參考自《TCP/IP詳解卷一:協議》

主要介紹TCP不同類型數據的交互方式:成塊數據和交互式數據(小數據)

1.交互式數據

交互式數據的工作方式一般是客戶端每鍵入一個按鍵傳送一個字節的數據到服務器,然後服務器再回顯客戶的輸入。流程如下圖所示:

這樣做,必然會導致網絡上的小分組過多,所以大神們提出了各種研究方法。

1.2 延時確認

TCP在接收數據時並不立即發送ACK,相反,它推遲發送,以便將ACK與需要沿該發現發送的數據一起發送。絕大多數系統的延時時間都是200ms。也就是說,TCP將以最大200ms的時延等待是否有數據一起發送。如果有,立即發送。如果沒有200ms超時發送ACK。

1.3 Nagle算法

TCP每次發送一個字節的數據,產生小分組(20字節IP頭部+20字節TCP頭部+1字節數據)在局域網通常沒有問題,但是在延時較大的廣域網容易出現阻塞問題。

Nagle算法規定一個TCP連接上最多只能有一個未被確認的未完成分組,在該分組的確認到達之前不能發送其它小分組。相反,TCP收集這些少量的分組,並在取人到來時以一個分組發送出去。該算法擁有自適應性:確認到達越快,數據發送得越快。數據到達越慢,分組越少。

但是,有時爲了減小系統的延時需要關閉Nagle算法,套接口選項中的TCP_NODELAY可以實現該功能。

2.成塊數據

2.1 滑動窗口協議

滑動窗口協議是一種流量控制方式,協議允許發送方在停止等待確認前可以連續發送多個分組。由於發送方不必每個分組停下來等待確認,因此該協議可以加速數據的傳輸。

其中接收方通告的窗口稱爲提供的窗口,上圖表明,接收方已經確認1,2,3數據,且通告的窗口爲6。當接收方確認數據後,這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或較小窗口的大小。具體的描述方法如下:

①窗口左邊沿向右邊沿靠近爲窗口合攏。這種現象發生在數據被髮送和確認時。

②窗口右邊沿向右移動時允許發送更多的數據,稱之爲窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了TCP的接收緩衝時。

③窗口右邊沿向左移動稱爲收縮。這種情況一般不會發生。

補充:TCP的每一端都有一個接收滑動窗口和發送滑動窗口,這兩者是不一樣的。

2.2 慢啓動

一般TCP建立連接之後,發送方一開始便會向網絡中發送多個報文端,直到達到接收方通告的窗口大小爲止。這在局域網中是可行的,但是當接收方和發送方之間存在多個路由器和速率較慢的鏈路時,就有可能出現一些問題。一些路由器必須緩存分組,並有可能耗盡設備內存。這是需要一種稱爲“慢啓動”的算法,對流量進行控制。

慢啓動爲發送方的TCP增加了一個“擁塞窗口”,記爲cwnd。當與另一個網絡的主機建立TCP連接時,擁塞窗口被初始化爲1個報文段(接收端通告的報文段大小)。每收到一個ACK,擁塞窗口增加一個報文段。發送方取擁塞窗口與通告窗口中的最小值最爲發送的上限。擁塞窗口是發送方的流量控制,而通告窗口則是接收方使用的流量控制。  

從圖中可以看出擁塞窗口是逐漸增大的,每接收到一個ACK都會增大。注意報文段大小爲512,圖中未標識出來。

2.3 帶寬時延乘積

在瞭解帶寬時延乘積之前,先來看看窗口大小和慢啓動對成塊TCP數據吞吐量的影響。

上圖顯示了左邊的發送發和右邊的接收方之間的一個TCP連接上的時間系列。間隔線的上半部分是從左到右的攜帶數據的報文段,下半部分反向傳輸的是ACK。

在時間0,發送發處於慢啓動狀態,只發送一個報文段。經過時間1,2,3,在時間4接收方讀取併產生報文的確認。經過時間4,5,6,在時間7,ACK被髮送方接收。如是就有了8個時間的RRT(Round-Trip Time)。

當接收到ack1之後,發送方的擁塞窗口大小變爲2,在時間8,9發送兩個報文段。在時間12和13接收方接收報文產生兩個ACK,在時間15,16兩個ACK被確認。此時擁塞窗口變爲4。

在時間16~19,有四個報文被髮送,時間23,這四個報文的第一個ACK到達。4個ACK都到達之後擁塞窗口變爲8,並在時間24~31發送8個報文段。在時間31及後續時間,發送方和接收方之間的管道被填滿。此時擁塞窗口和通告窗口的變化不會影響數據的發送。

那麼通道的容量該如何計算呢?在上圖中是8

這就引用帶寬時延乘積的概念

這個值取決與兩個方面:RTT和帶寬。帶寬增大其值增大,RTT變長,其值也增大。

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