文章目錄

• 一：流量控制
• 一：操作系統(tǒng)緩沖區(qū)與滑動窗口的關(guān)系
• • （1）若應(yīng)用程序沒有及時讀取緩沖區(qū)
  • （2）操作系統(tǒng)直接減少緩沖區(qū)大小

本文大部分內(nèi)容來自小林coding《圖解網(wǎng)絡(luò)》，感謝分享，簡單整理。

一：流量控制

我們知道發(fā)送方是不能無腦發(fā)送數(shù)據(jù)給接受方的，如果一直無腦發(fā)送，而導(dǎo)致對方處理不過來，那么就會觸發(fā)重傳，從而引起資源浪費

為了解決這一問題，tcp提供了一種機制可以讓發(fā)送方根據(jù)接收方實際接受能力控制發(fā)送的數(shù)據(jù)量，也即流量控制

如下圖是一個經(jīng)典的場景，其中

• 客戶端是接收方，服務(wù)端是發(fā)送方
• 假設(shè)接受窗口和發(fā)送窗口都為200
• 假設(shè)兩個設(shè)備在傳輸過程中都保持相同的窗口大小，不受外界影響

過程解釋如下

• 1：客戶端向服務(wù)端發(fā)送請求數(shù)據(jù)報文
• 2：服務(wù)端受到請求報文后，發(fā)送確認(rèn)報文和80字節(jié)的數(shù)據(jù)，于是可用窗口可用窗口減少為120字節(jié)。同時，SND.NXT指針也向右移動80字節(jié)，指向321，意味著下次發(fā)送數(shù)據(jù)序列號為321
• 3：客戶端收到80字節(jié)數(shù)據(jù)后，其接受窗口向右移動80字節(jié)，RCV.NXT指向321，意味著客戶端期望的下一個報文序列號是321，接著發(fā)送確認(rèn)報文給服務(wù)端
• 4：服務(wù)端再次發(fā)送120字節(jié)數(shù)據(jù)，可用窗口耗盡為0，無法再發(fā)送數(shù)據(jù)
• 5：客戶端收到120字節(jié)數(shù)據(jù)后，接受窗口向右移動120字節(jié)，RCV.NXT指向441，接著發(fā)送ACK
• 6：服務(wù)端收到對80字節(jié)數(shù)據(jù)的確認(rèn)報文后，SUD.UNA指針向右偏移指向321，于是可用窗口增大到80
• 7：服務(wù)端受到對120字節(jié)的確認(rèn)報文后，SUD.UNA指針向右偏移指向441，于是可用窗口增大到200
• 8：服務(wù)端現(xiàn)在可以繼續(xù)發(fā)送，發(fā)送160個字節(jié)的數(shù)據(jù)后，SND.NXT指向601，可用窗口減少到40
• 9：客戶端收到160字節(jié)后，接收窗口向右移動160字節(jié)，RCV.NXT指向601，接著發(fā)送ACK
• 10：服務(wù)端收到對160字節(jié)數(shù)據(jù)的確認(rèn)報文后，發(fā)送窗口向右面移動60字節(jié)，SND.UNA指針偏移160后指向601，可用窗口增大至200

一：操作系統(tǒng)緩沖區(qū)與滑動窗口的關(guān)系

前面流量控制的例子，我們假定了發(fā)送窗口和接受窗口是不變的，但實際上，發(fā)送窗口和接受窗口中存放的字節(jié)數(shù)，都是存放在操作系統(tǒng)的內(nèi)存緩沖區(qū)中的，因此一定收到操作系統(tǒng)控制而被調(diào)整

當(dāng)應(yīng)用程序由于各種原因未及時讀取緩沖區(qū)中的內(nèi)容時，也會對緩沖區(qū)造成影響

（1）若應(yīng)用程序沒有及時讀取緩沖區(qū)

下面的例子展示的是由于應(yīng)用程序沒有及時讀取緩沖區(qū)時，發(fā)送窗口和接受窗口的變化情況，其中

• 客戶端為發(fā)送方，服務(wù)端為接收方，發(fā)送窗口和額接受窗口初始大小為360
• 服務(wù)端很忙，收到客戶端數(shù)據(jù)時，應(yīng)用層未能及時處理數(shù)據(jù)

過程如下

• 1：客戶端發(fā)送140字節(jié)數(shù)據(jù)，可用窗口變?yōu)?20
• 2：服務(wù)端受到140字節(jié)數(shù)據(jù)，由于服務(wù)器繁忙，應(yīng)用程序僅僅讀取了40字節(jié)，還有100字節(jié)占用緩沖區(qū)，因此接收窗口縮小到260（360-100），最后發(fā)送ACK時，將窗口大小告知客戶端
• 3：客戶端收到ACK后，將發(fā)送窗口減少為260
• 4：客戶端發(fā)送180字節(jié)數(shù)據(jù)，可用窗口減少到80
• 5：服務(wù)端收到180字節(jié)后，但是應(yīng)用層沒有讀取任何數(shù)據(jù)，180字節(jié)直接留在了緩沖區(qū)，于是接收窗口縮小到了80（260-180），最后發(fā)送ACK時，將窗口大小告知客戶端
• 6：客戶端收到ACK后，將發(fā)送窗口減少為80
• 7：客戶端發(fā)送80字節(jié)數(shù)據(jù)后，可用窗口耗盡
• 8：服務(wù)端收到80字節(jié)數(shù)據(jù)，但是應(yīng)用程序依然沒有讀取任何數(shù)據(jù)，這80字節(jié)仍然留在緩沖區(qū)，于是接收窗口縮小到了0，最后發(fā)送ACK時，將窗口大小告知客戶端
• 9：客戶端收到ACK后，將發(fā)送窗口減少為0

最后窗口變?yōu)榱?，也即是發(fā)生了窗口關(guān)閉。當(dāng)發(fā)送方窗口為0時，發(fā)送方實際上會定時發(fā)送窗口探測報文，以便知道接受方的窗口是否發(fā)生了改變。

（2）操作系統(tǒng)直接減少緩沖區(qū)大小

當(dāng)服務(wù)器系統(tǒng)資源很緊張的時候，操作系統(tǒng)可能會直接減少接受緩沖區(qū)的大小，這時應(yīng)用程序又無法及時讀取緩沖區(qū)數(shù)據(jù)的話，那么可能導(dǎo)致丟包現(xiàn)象的產(chǎn)生

如下圖是一個經(jīng)典的例子

• 1：客戶端發(fā)送140字節(jié)的數(shù)據(jù)，可用窗口減少到了220
• 2：服務(wù)端因為現(xiàn)在非常繁忙，操作系統(tǒng)于是就把接受緩存減少了120字節(jié)，當(dāng)收到140字節(jié)數(shù)據(jù)后，由因為應(yīng)用程序沒有及時讀取數(shù)據(jù)，所以140字節(jié)留在了緩沖區(qū)中，于是接受窗口大小由360縮小到了100。最后發(fā)送ACK時，通知窗口大小給對方
• 3：此時客戶端因為還沒有收到服務(wù)端的ACK，所以不知道此時接受窗口縮減到了100，客戶端只會看到自己的可用窗口還有220，于是客戶端發(fā)送了180字節(jié)數(shù)據(jù)，可用窗口減少到了40
• 4：服務(wù)端收到了140字節(jié)數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)大小超過了接收窗口的大小，于是直接把數(shù)據(jù)丟了
• 5：客戶端收到第2步服務(wù)端發(fā)送的ACK后，嘗試減少發(fā)送窗口到100，把窗口的右端向左收縮了80，但是在第3步時，已經(jīng)發(fā)送了超過100字節(jié)的數(shù)據(jù)，所以可用窗口出現(xiàn)負(fù)值

所以如果發(fā)生了先減少緩存，再收縮窗口，就會出現(xiàn)丟包的現(xiàn)象。因此為了防止這種情況發(fā)生，tcp規(guī)定不允許同時減少緩存又收縮窗口的，而是先收縮窗口，一定時間后再減少緩存

總結(jié)

以上是生活随笔為你收集整理的4-7：TCP协议之流量控制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。