TCP窗口機制

TCP header中有一個Window Size字段，它其實是指接收端的窗口，即接收窗口。用來告知發(fā)送端自己所能接收的數據量，從而達到一部分流控的目的。

其實TCP在整個發(fā)送過程中，也在度量當前的網絡狀態(tài)，目的是為了維持一個健康穩(wěn)定的發(fā)送過程，比如擁塞控制。因此，數據是在某些機制的控制下進行傳輸的，就是窗口機制。

窗口縮放因子(Window Scaling)

以前，window size最大為2的16次方，為65535，隨著寬帶不斷提高，65535字節(jié)已經小了，為了突破限制，便有了Window Size Scaling選項，假設window scale為7，也就是要將Window Size的值左移七位，即乘以128。window scale最大為14.

在整個雙方的交互過程中，發(fā)送方和接收方Window size scaling factor乘積因子必須保持不變，但是發(fā)送方的乘積因子和接收方的乘積因子可以不同，由各自決定。

在標志位中有SYN的消息，會在選項中通知接收方，本端具體的放大因子，該消息本身不放大

上圖中的放大因子擴大了256倍，8212*256=2102272

發(fā)送窗口

（1）已經發(fā)送并且對端確認（Sent/ACKed）---------------發(fā)送窗外 緩沖區(qū)外

（2）已經發(fā)送但未收到確認數據（Sent/UnACKed）----- --發(fā)送窗內 緩沖區(qū)內

（3）允許發(fā)送但尚未防的數據（Unsent/Inside）-----------發(fā)送窗內 緩沖區(qū)內

（4）未發(fā)送暫不允許（Unsent/Outside）-------------------發(fā)送窗外 緩沖區(qū)內

2，3兩部分為發(fā)送窗口

接受窗口

對于TCP的接收方，在某一時刻在它的接收緩存內存在3種。“已接收”，“未接收準備接收”，“未接收并未準備接收”（由于ACK直接由TCP協議棧回復，默認無應用延遲，不存在“已接收未回復ACK”）。其中“未接收準備接收”稱之為接收窗口。

發(fā)送窗口與接收窗口關系

TCP是雙工的協議，會話的雙方都可以同時接收、發(fā)送數據。TCP會話的雙方都各自維護一個“發(fā)送窗口”和一個“接收窗口”。其中各自的“接收窗口”大小取決于應用、系統(tǒng)、硬件的限制（TCP傳輸速率不能大于應用的數據處理速率）。各自的“發(fā)送窗口”則要求取決于對端通告的“接收窗口”，要求相同。

滑動窗口

TCP并不是每一個報文段都會回復ACK的，可能會對兩個報文段發(fā)送一個ACK，也可能會對多個報文段發(fā)送1個ACK【累計ACK】，比如說發(fā)送方有1/2/3 3個報文段，先發(fā)送了2,3 兩個報文段，但是接收方期望收到1報文段，這個時候2,3報文段就只能放在緩存中等待報文1的空洞被填上，如果報文1，一直不來，報文2/3也將被丟棄，如果報文1來了，那么會發(fā)送一個ACK對這3個報文進行一次確認。

滑動窗口實現面向流的可靠性

最基本的傳輸可靠性來源于“確認重傳”機制。

TCP的滑動窗口的可靠性也是建立在“確認重傳”基礎上的。

發(fā)送窗口只有收到對端對于本段發(fā)送窗口內字節(jié)的ACK確認，才會移動發(fā)送窗口的左邊界。

接收窗口只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有字節(jié)未接收但收到后面字節(jié)的情況下，窗口不會移動，并不對后續(xù)字節(jié)確認。以此確保對端會對這些數據重傳。

滑動窗口的流控特性

TCP的滑動窗口是動態(tài)的，我們可以想象成小學常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿了就不允許再注入了，如果有個液壓系統(tǒng)控制水池大小，那么就可以控制水的注入速率和量。這樣的水池就類似TCP的窗口。應用根據自身的處理能力變化，通過本端TCP接收窗口大小控制來對對對端的發(fā)送窗口流量限制。

應用程序在需要（如內存不足）時，通過API通知TCP協議棧縮小TCP的接收窗口。然后TCP協議棧在下個段發(fā)送時包含新的窗口大小通知給對端，對端按通知的窗口來改變發(fā)送窗口，以此達到減緩發(fā)送速率的目的。

滑動窗口動態(tài)調整

主要是根據接收端的接收情況，動態(tài)去調整Window Size，然后來控制發(fā)送端的數據流量

客戶端不斷快速發(fā)送數據，服務器接收相對較慢，看下實驗的結果

a. 包175，發(fā)送ACK攜帶WIN = 384，告知客戶端，現在只能接收384個字節(jié)

b. 包176，客戶端果真只發(fā)送了384個字節(jié)，Wireshark也比較智能，也宣告TCP Window Full

c. 包177，服務器回復一個ACK，并通告窗口為0，說明接收方已經收到所有數據，并保存到緩沖區(qū)，但是這個時候應用程序并沒有接收這些數據，導致緩沖區(qū)沒有更多的空間，故通告窗口為0, 這也就是所謂的零窗口，零窗口期間，發(fā)送方停止發(fā)送數據

d. 客戶端察覺到窗口為0，則不再發(fā)送數據給接收方

e. 包178，接收方發(fā)送一個窗口通告，告知發(fā)送方已經有接收數據的能力了，可以發(fā)送數據包了

f. 包179，收到窗口通告之后，就發(fā)送緩沖區(qū)內的數據了.

總結一點，就是接收端可以根據自己的狀況通告窗口大小，從而控制發(fā)送端的接收，進行流量控制

參考：

TCP 滑動窗口（發(fā)送窗口和接收窗口）

解析TCP之滑動窗口(動畫演示)

TCP-IP詳解：滑動窗口（Sliding Window）

總結

以上是生活随笔為你收集整理的TCP滑动窗口（发送窗口和接受窗口）的全部內容，希望文章能夠幫你解決所遇到的問題。

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