文章目錄

• 一：流量控制
• 一：操作系統緩沖區與滑動窗口的關系
• • （1）若應用程序沒有及時讀取緩沖區
  • （2）操作系統直接減少緩沖區大小

本文大部分內容來自小林coding《圖解網絡》，感謝分享，簡單整理。

一：流量控制

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

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

如下圖是一個經典的場景，其中

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

過程解釋如下

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

一：操作系統緩沖區與滑動窗口的關系

前面流量控制的例子，我們假定了發送窗口和接受窗口是不變的，但實際上，發送窗口和接受窗口中存放的字節數，都是存放在操作系統的內存緩沖區中的，因此一定收到操作系統控制而被調整

當應用程序由于各種原因未及時讀取緩沖區中的內容時，也會對緩沖區造成影響

（1）若應用程序沒有及時讀取緩沖區

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

• 客戶端為發送方，服務端為接收方，發送窗口和額接受窗口初始大小為360
• 服務端很忙，收到客戶端數據時，應用層未能及時處理數據

過程如下

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

最后窗口變為了0，也即是發生了窗口關閉。當發送方窗口為0時，發送方實際上會定時發送窗口探測報文，以便知道接受方的窗口是否發生了改變。

（2）操作系統直接減少緩沖區大小

當服務器系統資源很緊張的時候，操作系統可能會直接減少接受緩沖區的大小，這時應用程序又無法及時讀取緩沖區數據的話，那么可能導致丟包現象的產生

如下圖是一個經典的例子

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。