文章目錄

• 一：滑動窗口
• 二：滑動窗口格式詳解
• • （1）發送方的滑動窗口
  • （2）接受方滑動窗口

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

一：滑動窗口

在前面的講解中，我們知道TCP是每發送一個數據都要進行依次確認應答，當上一個數據包收到ACK了，才會發送下一個，這種邏輯類似于我和你面對面聊天，我說一句你回一句，其實大家可以發現這種方式效率是十分低下的，放在TCP中也是如此，客戶端和服務端數據交互量非常大，如果按照這種速度那顯然不合理。

所以采用這種方式的弊端很大：數據包往返的時間很長，通信效率極低

因此，為了解決這樣的問題，TCP中引入了窗口這個概念，以保證即使在往返時間較長的情況下，也不會降低網絡通信的效率。
有了窗口就可以指定窗口大小，所謂窗口大小就是指無需等待確認應答，而可以繼續發送數據的最大值

• 窗口的實現實際上是操作系統開辟的一個緩存空間，發送剛主機在等到ACK返回之前，必須在緩沖區中保留已經發送的數據，如果按期收到ACK，那么數據就可以從緩沖區中清除

如下圖，假設窗口大小為3個TCP端，那么發送方就可以連續發送3個TCP，并且途中若有ACK丟失，則可以通過下一個確認應答進行確認

• 上圖中的ACK600確認應答報文丟失也沒有關系，因為可以通過下一個確認應答進行確認，只要發送方收到了ACK700確認應答，就意味著700之前的所有數據接收方都已經收到了。這個模式叫做累計確認或累計應答

前面說過TCP頭部中有一個字段就是窗口大小

該字段是接受端告訴發送端自己還有多少緩沖區可以接受數據。于是發送端就可以根據這個接收端的處理能力來發送數據，而不會導致接收端處理不過來。
所以，通常窗口的大小是由接收方的窗口大小決定的，發送方發送的數據大小可以超過接收方的窗口大小，否則接收方就無法正常接收到數據

二：滑動窗口格式詳解

（1）發送方的滑動窗口

如下是發送方緩存的數據，根據處理的情況可以分為四個部分。

• #1是已經發送并收到ACK確認的數據
• #2是已經發送但沒有收到ACK確認的數據
• #3是沒有發送但總大小在接收方處理范圍（接收方還有空間）的數據
• #4上是沒有發送但總大小超過接收方處理范圍（接收方沒有空間）的數據

如下圖，如果發送方把數據全部一下子發出去之后，可用窗口就變為0了，表示可用窗口用盡，在沒有收到ACK之前無法繼續發送數據

接著，當收到之前發送的數據的ACK時，比如下面的32-36字節ACK之后，如果發送窗口大小沒有變化，則滑動窗口右移5個字節，因為有5個字節已經被ACK。接著52-56字節就又成為了可用窗口，那么后序黃色范圍的數據也就可以又發送了

上面只是宏觀上面的描述，那么程序是如何描述這樣的操作的呢？
實際上，TCP滑動窗口使用三個指針來跟蹤在4個傳輸類別中的每一個類別的字節，其中兩個指針是絕對指針（指特定的序列號），一個是相對指針（需要做偏移）

• SND.WND：表示發送窗口的大小（由接收方指定）
• SND.UNA：是一個絕對指針，指向已發送但沒有收到確認的第一個字節的序列號
• SND.NXT：是一個絕對指針，指向沒有發送但在可發送范圍內的第一個字節的序列號
• 指向#4的是一個相對指針，它需要SND.UNA指針加上SUND.WND大小的偏移量

因此可用窗口大小=SND.WND-（SND.NXT-SND.UNA）

（2）接受方滑動窗口

如下是接收方滑動窗口格式，相對發送方要簡單一些

• #1，#2是已成功接收并確認的數據（等待應用層讀取）
• #3是沒有收到但可以接受的數據
• #4是沒有收到但不可以接受的數據

這幾個部分由如下指針指向

• RCV.WND：表示接收窗口大小，它會告知給發送方
• RCV.NXT：是一個指針，它指向期望從發送方接受來的下一個數據字節的序列號，也就是#3的第一個字節
• 指向#4的第一個字節是一個相對指針，需要RCV.NXT指針加上RCV.WND大小的偏移量

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

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

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