介绍
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数据分为如下四类来看（见图）：
1 已发送且已应答（Sent/Acked）
2 已发送但尚未应答（Send/UnAcked）
3 未发送，但位于当前发送窗口之内（Unsent/Inside）
4 未发送，但位于当前发送窗口之外（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会增加，但是窗口大小会减少同样多的值。
（文章转自：EMC中文支持论坛 https://community.emc.com/go/chinese）
