【網路】TCP的流量控制

標籤：style   http   color   資料   art   re   

一、利用滑動視窗實現流量控制

流量控制是讓發送方的發生速率不要太快，要讓接收方來得及接收。

發送方的發送視窗不能超過接收方給出的接收視窗的數值，TCP的視窗單位是位元組，不是報文段。

TCP為每一個串連設有一個持續計時器，只要TCP串連的一方收到對方的零視窗通知，就啟動持續計時器。若持續計時器設定的時間到期，就發送一個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值，如果視窗仍然是零，那麼收到這個報文段的一方就重新設定持續計時器。如果視窗不是零，那麼死結的僵局就可以打破了。

二、傳輸效率

MSS：最大報文段長度

如何控制TCP發送報文段的時機？

Nagle演算法：若發送應用進程把要發送的資料逐個位元組地送到TCP的發送緩衝，則發送方就把第一個資料位元組先發送出去，把後面到達的資料位元組都緩衝起來。當發送方收到對第一個資料字元的確認後，再把發送緩衝中的所有資料群組裝成一個報文段發送出去，同時繼續對隨後到達的資料進行緩衝。只有在收到對前一個報文段的確認後才繼續發送下一個報文段。當資料到達較快而網路速率較慢時，用這樣的方法可明顯減少所用的網路頻寬。Nagle演算法還規定：當到達的資料已達到發送視窗大小的一半或已達到報文段的最大長度時，就立即發送一個報文段.

Silly Window Syndrome

Silly Window Syndrome翻譯成中文就是“糊塗視窗綜合症”。正如你上面看到的一樣，如果我們的接收方太忙了，來不及取走Receive Windows裡的資料，那麼，就會導致發送方越來越小。到最後，如果接收方騰出幾個位元組並告訴發送方現在有幾個位元組的window，而我們的發送方會義無反顧地發送這幾個位元組。要知道，我們的TCP+IP頭有40個位元組，為了幾個位元組，要達上這麼大的開銷，這太不經濟了。

解決方案：

1.讓接收方等待一段時間，使得接收緩衝已有足夠空間容納一個最長的報文段，或者等到接收緩衝已有一般閒置空間

2.發送方不要發送太小的報文段，而是把資料累積成足夠大的報文段，或達到接收方緩衝的空間的一半大小

參考：

http://coolshell.cn/articles/11609.html