原创 TCP滑动窗口【转】

滑动窗口协议可以用图四来形象表示。

图中我们已经将字节进行了1到11的编号。由接收者通告的窗口称为提议窗口（offered window），它覆盖了第4到第9个字节，意味着接收方已经确认了第3字节之前（包括第3字节）的数据，并且通告窗口的大小是6。窗口大小与确认的顺序号（acknowledged sequence number）有关。发送者计算它的可用窗口（usable window），用以度量它可以立即发送多少数据。

随着接收者对收到数据的确认，滑动窗口随时向右移动。窗口两端的相关运动增加或减少着窗口大小。我们使用3个术语来描述窗口边缘（edge）的左右运动。

1．              当窗口左边缘靠近右边缘时称窗口闭合（window closes）。窗口闭合发生在数据已经发送并被确认的情况下。

2．              当窗口右边缘向右移动时称窗口打开（window opens）。窗口打开发生在另一端的接收进程读取已确认数据的时候，它释放了TCP接收缓冲区的空间。

3．              当窗口右边缘向左移动时称窗口收缩（window shrinks）。Host Requirement RFC强烈不鼓励这种做法，但TCP必须能够在一端发生这种情况时进行处理。

     图五表示了这三个术语。由于窗口的左边缘是受从连接另一端收到的确认号来控制的，因此它不会向左移动。如果收到一个ACK要求将左边缘向左移动，那么它是一个重复的（duplicate）的确认，并被丢弃。

如果窗口左边缘重合了右边缘，就称它为零窗口（zero window）。它将停止发送者传输任何数据。

示例

图六显示了图一数据传输中TCP滑动窗口的动态变化

以此图为例，我们可以总结几个要点：

1．  发送者不必传送满窗口大小的数据。

2．  收到接收者对数据的确认后，窗口向右滑动。这是由于窗口大小与确认顺序号相关。

3．  从段7到段8的变化，可以看出窗口可以减小，但窗口右边缘不能向左移动。

4．  接收者不必等待窗口被填满才发送确认。在许多实现中，接收者每收到两个段发送一个确认。