滑动窗口协议这样理解更简单

引言

想象一下这个场景：主机 A 一直向主机 B 发送数据，不考虑主机 B 的接收能力，则可能导致主机 B 的接收缓冲区满了而无法再接收数据，从而导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机 B 的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。

所以引入了流量控制机制，主机 B 通过告诉主机 A 自己接收缓冲区的大小，来使主机 A 控制发送的数据量。总结来说：所谓流量控制就是控制发送方发送速率，保证接收方来得及接收。

TCP 实现流量控制主要就是通过 滑动窗口协议。

对于发送方来说，窗口大小就是指无需等待确认应答，可以连续发送数据的最大值。

窗口大小具体由谁来设定呢？

窗口大小和 TCP 报文首部中 16 位的 窗口大小 Window 字段有关：

该字段的含义是指自己接收缓冲区的剩余大小，于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

所以，通常来说窗口大小是由接收方来决定的。

滑动窗口详解

说了半天，窗口其实就是操作系统开辟的一个缓冲区

发送方在收到确认应答报文之前，必须在缓冲区中保留已发送的报文段（因为报文段可能在网络中丢失，所以必须把这些未确认的报文段保留这，以便必要时重传）；如果在规定时间间隔内收到接收方发来的确认应答报文，就可以将这些报文段从缓冲区中清除。

站在发送方的角度，滑动窗口可以分为四个部分：

1. 已发送且已确认，这部分已经发送完毕，可以忽略；
2. 已发送但未确认，这部分可能在网络中丢失，数据必须保留以便必要时重传；
3. 未发送但可发送，这部分接收方缓冲区还有空间保存，可以发出去；
4. 未发送且暂不可发送，这部分已超出接收方缓冲区存储空间，就算发出去也没意义；

第 2 和第 3 部分加起来就刚好就是接收方窗口（缓冲区）大小，它规定了当前发送方能发送的最大数据量。

当发送方收到接收方发来的确认应答后，就将缓冲区中那些被确认的报文清除出去，然后窗口向右移动，如下图所示：

随着双方通信的进行，窗口将不断向右移动，因此被形象地称为滑动窗口（Sliding Window）

对于 TCP 的接收方，窗口稍微简单点，分为三个部分：

1. 已接收
2. 未接收准备接收 (也即接收窗口，再强调一遍，接收窗口的大小决定发送窗口的大小，或者说，决定缓冲区的大小。)
3. 未接收并未准备接收

由于 ACK 直接由 TCP 协议栈回复，默认无应用延迟，不存在 “已接收未回复 ACK”

综上，举个例子，假设发送方需要发送的数据总长度为 400 字节，分成 4 个报文段，每个报文段长度是 100 字节:

1）三次握手连接建立时接收方告诉发送方，我的接收窗口大小(rwnd) 是 300 字节

此时的接收方滑动窗口如下：

此时的发送方滑动窗口如下：

2）发送方发送第一个报文段（序号 1 - 100），还能再发送 200 个字节

3）发送方发送第二个报文段（序号 101 - 200），还能再发送 100 个字节

4）发送方发送第三个报文段（序号 201 - 300），还能再发送 0 个字节

此时，发送方的窗口（缓冲区）中存了三个报文段了

此时的发送方滑动窗口如下：

5）接收方接收到了第一个报文段和第三个报文段，中间第二个报文段丢失。此时接收方返回一个报文段 ack = 101, rwnd = 200（假设这里发生流量控制，把窗口大小降到了 200，允许发送方继续发送起始序号为 101，长度为 200 的报文）

此时的接收方滑动窗口如下（本来窗口右端应该右移，但是这里发生了流量控制，接收方希望缩小窗口大小，所以正好，这里就不需要向右扩展了）：

发送方收到了第一个报文段的确认，从窗口（缓冲区）中移除掉第一个报文段

此时的发送方滑动窗口如下：

6）发送方一直没有收到第二个报文段的确认应答，在等待超时后重传第二个报文段（序号 101 - 200）

7）接收方成功收到第二个报文段（缓冲区中有第二个和第三个报文段了），于是向发送方返回一个报文段 ack = 301, rwnd = 100（假设这里发生流量控制，把窗口大小降到了 100）

此时的接收方滑动窗口如下：（本来窗口右端应该右移，但是这里发生了流量控制，接收方希望缩小窗口大小，所以正好，这里就不需要向右扩展了）

发送方收到了第二个和第三个报文段的确认，从窗口（缓冲区）中移除掉这俩报文段

8）发送方发送第四个报文段（序号 301 - 400）

此时的发送方滑动窗口如下：

通俗的例子

下面来更通俗地解释下滑动窗口，看下面这个场景，老师说一段话，学生来记

最原始的模式，一股脑把所有的报文段全都发出去。

老师说 "危楼高百尺，手可摘星辰，不敢高声语，恐惊天上人"（咱把每个字看成一个报文段，总共 20 个报文段）

学生写道"危楼高百尺，手可......."

上面的模式过于简单粗暴，发送方发送速度太快，接收方跟不上，并且重传成本过高。

于是他们换了一种模式：每发送一个报文段就等待确认一个报文段，收到确认后才能发送下一个

老师说 "危"，学生说"确认"

老师说 "楼"，学生说"确认"

老师说 "高"，学生说"高"

.........

上面的模式每发一个报文段，必须等到确认后才能再次发送，效率低下。

于是他们又换了一种模式：累积确认，既不是一股脑把所有的报文段全都发出去，也不是一次只发一个报文段，而是分组发送，每次发几个报文段。

老师说 "危楼高百尺" （5 个报文段），学生说 "确认"

老师说 "手可摘星辰"，学生说 "手可..."（3 个报文段丢失）

老师说 "不敢高声语"，学生说 "确认"

老师一直没有收到 "摘星辰" 的确认，于是重新说了一遍 "摘星辰"，学生说 "确认"

老师说 "恐惊天上人"，学生说 "确认"

上面的模式提高了效率，连续多个报文段一起进行发送, 但是到底该怎么决定多少个报文段一起发送呢呢？

于是他们在上面模式的基础上，做出了一些改进：滑动窗口，接收方认为状态好（窗口比较大）的时候, 让发送方每次多发一点；接收方认为状态不好（窗口比较小）的时候，让发送方每次少发送一点，起到一个流量控制的作用，限制发送方的速度。

学生告诉老师，我一次性可以接收 10 个报文段

老师说 "危楼高百尺，手可摘星辰"，学生说 "危楼高百尺，手可..."（3 个报文段丢失，返回 ”可" 的确认应答，一共确认了 7 个报文段，老师的可用窗口右移，窗口中现在还有 “摘星辰” 3 个报文段）

学生说，我状态不行，一次性现在只能接收 5 个报文段（流量控制，缩小窗口）

老师说 "不敢"（窗口中还有 “摘星辰” 3 个报文段，所以只能发送 2 个），学生说 "确认"

老师一直没有收到 "摘星辰" 的确认，于是重新说了一遍，学生说 "确认"

（可用窗口恢复为 5 个）老师说 "恐惊天上人"，......