TCP是目前Internet上最為流行的傳輸控制協議，即便你是搞存儲的，我覺得多少也得知道點兒，因為在File-Level storage慢慢成為主角的今天，SMB、NFS、FTP等關鍵協議都依賴于TCP，就連block-level的iSCSI協議也是如此。窗口是TCP中一個極為重要的概念，它直接關系到TCP的一個關鍵功能-流量控制。今天我簡單介紹下TCP發送窗口，從較為微觀的角度去理解TCP是如何限制發送端可發送的數據量的。

我們知道TCP header中有一個Window Size字段，它其實是指接收端的窗口，即接收窗口，用來告知發送端自己所能接收的數據量，從而達到一部分流控的目的。假設你現在有10MB的數據要通過TCP發送，或許你點個按鈕就開始發送了，然后就認為TCP僅僅是簡單的把數據從一端挪到另一端（宏觀上的確如此）。其實TCP在整個發送過程中，也在度量當前的網絡狀態，目的是為了維持一個健康穩定的發送過程。因此，這10MB數據是在某些機制的控制下進行傳輸的，其中一種重要機制就是窗口機制。發送端的發送窗口是基于接收端的接收窗口來計算的，我們可以把這10MB數據分為如下四類來看（見圖）：

• 已發送且已應答（Sent/Acked）
• 已發送但尚未應答（Send/UnAcked）
• 未發送，但位于當前發送窗口之內（Unsent/Inside）
• 未發送，但位于當前發送窗口之外（Unsent/Outside）

已發送且已應答（Sent/Acked）

Sent/Acked數據的第一個字節是ISN+1，ISN是指在TCP建立連接時由SYN分段所選擇的第一個編號。SYN Flag被當作是一個字節的數據，特地會被應答一次。因此，TCP連接上發送的數據的第一個字節編號就是ISN+1，被應答的數據的最后一個字節編號為【ACK編號-1】。例如，A發送1000個字節給B，假設ISN=1，則所要發送數據的第一個字節的編號為2，全部發送到B之后，B會應答1002，意思是說前1001（包括ISN）個字節我都收到了，請給我第1002個字節。所以，被應答的數據的最后一個字節的編號為1001。

已發送但尚未應答（Send/UnAcked）

Send/UnAcked數據的狀態可能是正在傳輸的過程中，或是被網絡丟棄了，或是已到達接收端但應答尚未被發送（因為Delayed-Ack），又或是應答正在傳輸過程中。為了區分Sent/UnAcked數據和Unsent/Inside數據，TCP維護一個叫做SND.NEXT的變量，它是下一個即將被發送的字節的編號。所以SND.NEXT的值將是下一個即將被發送的TCP分段的Sequence Number字段的值。Send/UnAcked數據的第一個字節是接收端上一次接受的應答分段的Acknowledge Number字段的值。

未發送，但位于當前發送窗口之內（Unsent/Inside）

Unsent/Inside數據是接收端允許發送端發送的數據，發送端可以發送窗口內的所有數據，無需等待應答以及窗口更新。換句話說，如果發送端停止發送并等待應答，那就說明已經沒有Unsent/Inside的數據了。然而，如果遇到擁塞，發送端的流控機制，即slow start和congestion avoidance會阻止發送端發送所有位于接收窗口內的數據。在這種情況下，這些機制會主宰等待應答之前的可發送數據量。

未發送，但位于當前發送窗口之外（Unsent/Outside）

Unsent/Outside數據是位于當前發送窗口意外的數據，代表將來要發送的數據，但根據目前的接收窗口它們是不允許被發送的。接收端會丟棄無法保存在接收緩存區中的數據，并用當前的應答編號來應答發送端。

發送窗口的移動

發送窗口有一個左側邊緣和一個右邊邊緣。當收到一個帶有更高Ack number的應答時，發送窗口的左側邊緣就會向右移動（close）。當收到的應答的Ack number+Window>之前的Ack number+Window時，發送窗口的右側邊緣會向右移動（open）。另外，發送窗口僅close但不open也是有可能的。比如發送端收到一個應答，它的Ack number增加了，但是窗口變小了，最終Ack number+Window并沒有變化。這種情況發生在接收端收到了數據，但還沒有把數據給應用層，因此Ack number會增加，但是窗口大小會減少同樣多的值。

更多新體驗，歡迎試用TCP安全信息開發控件。另外還有5折限時搶購和免費領iPhone 6、iPad air等好禮!