一、為什么需要流量控制?

雙方在通信的時候，發(fā)送方的速率與接收方的速率是不一定相等，如果發(fā)送方的發(fā)送速率太快，會導(dǎo)致接收方處理不過來，這時候接收方只能把處理不過來的數(shù)據(jù)存在緩存區(qū)里（失序的數(shù)據(jù)包也會被存放在緩存區(qū)里）。

如果緩存區(qū)滿了發(fā)送方還在瘋狂著發(fā)送數(shù)據(jù)，接收方只能把收到的數(shù)據(jù)包丟掉，大量的丟包會極大著浪費網(wǎng)絡(luò)資源，因此，我們需要控制發(fā)送方的發(fā)送速率，讓接收方與發(fā)送方處于一種動態(tài)平衡才好。

對發(fā)送方發(fā)送速率的控制，我們稱之為流量控制。

二、如何控制?

接收方每次收到數(shù)據(jù)包，可以在發(fā)送確定報文的時候，同時告訴發(fā)送方自己的緩存區(qū)還剩余多少是空閑的，我們也把緩存區(qū)的剩余大小稱之為接收窗口大小，用變量win來表示接收窗口的大小。

發(fā)送方收到之后，便會調(diào)整自己的發(fā)送速率，也就是調(diào)整自己發(fā)送窗口的大小，當發(fā)送方收到接收窗口的大小為0時，發(fā)送方就會停止發(fā)送數(shù)據(jù)，防止出現(xiàn)大量丟包情況的發(fā)生。

三、發(fā)送方何時再繼續(xù)發(fā)送數(shù)據(jù)?

當發(fā)送方停止發(fā)送數(shù)據(jù)后，該怎樣才能知道自己可以繼續(xù)發(fā)送數(shù)據(jù)？

我們可以采用這樣的策略：當接收方處理好數(shù)據(jù)，接受窗口 win > 0 時，接收方發(fā)個通知報文去通知發(fā)送方，告訴他可以繼續(xù)發(fā)送數(shù)據(jù)了。當發(fā)送方收到窗口大于0的報文時，就繼續(xù)發(fā)送數(shù)據(jù)。

不過這時候可能會遇到一個問題，假如接收方發(fā)送的通知報文，由于某種網(wǎng)絡(luò)原因，這個報文丟失了，這時候就會引發(fā)一個問題：接收方發(fā)了通知報文后，繼續(xù)等待發(fā)送方發(fā)送數(shù)據(jù)，而發(fā)送方則在等待接收方的通知報文，此時雙方會陷入一種僵局。

為了解決這種問題，我們采用了另外一種策略：當發(fā)送方收到接受窗口 win = 0 時，這時發(fā)送方停止發(fā)送報文，并且同時開啟一個定時器，每隔一段時間就發(fā)個測試報文去詢問接收方，打聽是否可以繼續(xù)發(fā)送數(shù)據(jù)了，如果可以，接收方就告訴他此時接受窗口的大?。蝗绻邮艽翱诖笮∵€是為0，則發(fā)送方再次刷新啟動定時器。

四、一些術(shù)語及其注意點說明

1、這里說明下，由于TCP/IP支持全雙工傳輸，因此通信的雙方都擁有兩個滑動窗口，一個用于接受數(shù)據(jù)，稱之為接收窗口；一個用于發(fā)送數(shù)據(jù)，稱之為擁塞窗口(即發(fā)送窗口)。指出接受窗口大小的通知我們稱之為窗口通告。

2、接收窗口的大小固定嗎？

在早期的TCP協(xié)議中，接受接受窗口的大小確實是固定的，不過隨著網(wǎng)絡(luò)的快速發(fā)展，固定大小的窗口太不靈活了，成為TCP性能瓶頸之一，也就是說，在現(xiàn)在的TCP協(xié)議中，接受窗口的大小是根據(jù)某種算法動態(tài)調(diào)整的。

3、接受窗口越大越好嗎？

接受窗口如果太小的話，顯然這是不行的，這會嚴重浪費鏈路利用率，增加丟包率。那是否越大越好呢？答否，當接收窗口達到某個值的時候，再增大的話也不怎么會減少丟包率的了，而且還會更加消耗內(nèi)存。所以接收窗口的大小必須根據(jù)網(wǎng)絡(luò)環(huán)境以及發(fā)送發(fā)的的擁塞窗口來動態(tài)調(diào)整。

4、發(fā)送窗口和接受窗口相等嗎？

接收方在發(fā)送確認報文的時候，會告訴發(fā)送發(fā)自己的接收窗口大小，而發(fā)送方的發(fā)送窗口會據(jù)此來設(shè)置自己的發(fā)送窗口，但這并不意味著他們就會相等。首先接收方把確認報文發(fā)出去的那一刻，就已經(jīng)在一邊處理堆在自己緩存區(qū)的數(shù)據(jù)了，所以一般情況下接收窗口 >= 發(fā)送窗口。
編輯：hfy