技术分享10 - 滑动窗口与流量控制
滑动窗口
引入窗口概念的原因
我们都知道 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。
这个模式就有点像两个人面对面聊天，你一句他一句。但这种方式的缺点是效率比较低的。
如果你说完一句话，他在处理其他事情，没有及时回复你，那你就要干等着他做完其他事情后，他回复你，你才能说下一句话，很显然这不现实。
所以，这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。
为解决这个问题，TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。
那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：
图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通话下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。
窗口大小由哪一方决定？
TCP 头里有一个字段叫 Window，也就是窗口大小。
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
所以，通常窗口的大小是由接收方的决定的。
发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
发送方的滑动窗口
我们先来看看发送方的窗口，下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中深蓝色方框是发送窗口，紫色方框是可用窗口：
- #1 是已发送并收到 ACK确认的数据：1~31 字节
- #2 是已发送但未收到 ACK确认的数据：32~45 字节
- #3 是未发送但总大小在接收方处理范围内（接收方还有空间）：46~51字节
- #4 是未发送但总大小超过接收方处理范围（接收方没有空间）：52字节以后
在下图，当发送方把数据「全部」都一下发送出去后，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。
在下图，当收到之前发送的数据 32~36 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来 52~56 字节又变成了可用窗口，那么后续也就可以发送 52~56 这 5 个字节的数据了。
程序表示发送窗口四个部分的方法
TCP 滑动窗口方案使用三个指针来跟踪在四个传输类别中的每一个类别中的字节。其中两个指针是绝对指针（指特定的序列号），一个是相对指针（需要做偏移）。
SND.WND：表示发送窗口的大小（大小是由接收方指定的）；SND.UNA：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节。- 指向 #4 的第一个字节是个相对指针，它需要
SND.UNA指针加上SND.WND大小的偏移量，就可以指向 #4 的第一个字节了。
那么可用窗口大小的计算就可以是：
可用窗口大小 = SND.WND -（SND.NXT - SND.UNA）
接收方的滑动窗口
接下来我们看看接收方的窗口，接收窗口相对简单一些，根据处理的情况划分成三个部分：
- #1 + #2 是已成功接收并确认的数据（等待应用进程读取）；
- #3 是未收到数据但可以接收的数据；
- #4 未收到数据并不可以接收的数据；
其中三个接收部分，使用两个指针进行划分:
RCV.WND：表示接收窗口的大小，它会通告给发送方。RCV.NXT：是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字节。- 指向 #4 的第一个字节是个相对指针，它需要
RCV.NXT指针加上RCV.WND大小的偏移量，就可以指向 #4 的第一个字节了。
接受窗口和发送窗口大小相等？
并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。
因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Window 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。
流量控制
发送方不能无脑的发数据给接收方，要考虑接收方处理能力。
如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。
为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。
下面举个栗子，为了简单起见，假设以下场景：
- 客户端是接收方，服务端是发送方
- 假设接收窗口和发送窗口相同，都为
200 - 假设两个设备在整个传输过程中都保持相同的窗口大小，不受外界影响
根据上图的流量控制，说明下每个过程：
- 客户端向服务端发送请求数据报文。这里要说明下，本次例子是把服务端作为发送方，所以没有画出服务端的接收窗口。
- 服务端收到请求报文后，发送确认报文和 80 字节的数据，于是可用窗口
Usable减少为 120 字节，同时SND.NXT指针也向右偏移 80 字节后，指向 321，这意味着下次发送数据的时候，序列号是 321。 - 客户端收到 80 字节数据后，于是接收窗口往右移动 80 字节，
RCV.NXT也就指向 321，这意味着客户端期望的下一个报文的序列号是 321，接着发送确认报文给服务端。 - 服务端再次发送了 120 字节数据，于是可用窗口耗尽为 0，服务端无法在继续发送数据。
- 客户端收到 120 字节的数据后，于是接收窗口往右移动 120 字节，
RCV.NXT也就指向 441，接着发送确认报文给服务端。 - 服务端收到对 80 字节数据的确认报文后，
SND.UNA指针往右偏移后指向 321，于是可用窗口Usable增大到 80。 - 服务端收到对 120 字节数据的确认报文后，
SND.UNA指针往右偏移后指向 441，于是可用窗口Usable增大到 200。 - 服务端可以继续发送了，于是发送了 160 字节的数据后，
SND.NXT指向 601，于是可用窗口Usable减少到 40。 - 客户端收到 160 字节后，接收窗口往右移动了 160 字节，
RCV.NXT也就是指向了 601，接着发送确认报文给服务端。 - 服务端收到对 160 字节数据的确认报文后，发送窗口往右移动了 160 字节，于是
SND.UNA指针偏移了 160 后指向 601，可用窗口Usable也就增大至了 200。
操作系统缓冲区与滑动窗口的关系
前面的流量控制例子，我们假定了发送窗口和接收窗口是不变的，但是实际上，发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。
当应用进程没办法及时读取缓冲区的内容时，也会对我们的缓冲区造成影响。