TCP 为了防止发送方无脑的发送数据，导致接收方缓冲区被填满，所以就有了滑动窗口的机制，它可利用接收方的接收窗口来控制发送方要发送的数据量，也就是流量控制。
接收窗口是由接收方指定的值，存储在 TCP 头部中，它可以告诉发送方自己的 TCP 缓冲空间区大小，这个缓冲区是给应用程序读取数据的空间：
- 如果应用程序读取了缓冲区的数据，那么缓冲空间区的就会把被读取的数据移除
- 如果应用程序没有读取数据，则数据会一直滞留在缓冲区。
接收窗口的大小，是在 TCP 三次握手中协商好的，后续数据传输时，接收方发送确认应答 ACK 报文时，会携带当前的接收窗口的大小，以此来告知发送方。
假设接收方接收到数据后，应用层能很快的从缓冲区里读取数据，那么窗口大小会一直保持不变，过程如下：
理想状态下的窗口变化
但是现实中服务器会出现繁忙的情况，当应用程序读取速度慢，那么缓存空间会慢慢被占满，于是为了保证发送方发送的数据不会超过缓冲区大小，则服务器会调整窗口大小的值，接着通过 ACK 报文通知给对方，告知现在的接收窗口大小，从而控制发送方发送的数据大小。
服务端繁忙状态下的窗口变化
零窗口通知与窗口探测
假设接收方处理数据的速度跟不上接收数据的速度，缓存就会被占满，从而导致接收窗口为 0，当发送方接收到零窗口通知时，就会停止发送数据。
如下图，可以接收方的窗口大小在不断的收缩至 0：
窗口大小在收缩
接着，发送方会定时发送窗口大小探测报文，以便及时知道接收方窗口大小的变化。
以下图 Wireshark 分析图作为例子说明：
零窗口 与 窗口探测
- 发送方发送了数据包 1 给接收方，接收方收到后，由于缓冲区被占满，回了个零窗口通知；
- 发送方收到零窗口通知后，就不再发送数据了，直到过了 3.4 秒后，发送了一个 TCP Keep-Alive 报文，也就是窗口大小探测报文；
- 当接收方收到窗口探测报文后，就立马回一个窗口通知，但是窗口大小还是 0；
- 发送方发现窗口还是 0，于是继续等待了 6.8（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；
- 发送方发现窗口还是 0，于是继续等待了 13.5（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；
可以发现，这些窗口探测报文以 3.4s、6.5s、13.5s 的间隔出现，说明超时时间会翻倍递增。
这连接暂停了 25s，想象一下你在打王者的时候，25s 的延迟你还能上王者吗？
发送窗口的分析
在 Wireshark 看到的 Windows size 也就是 " win = "，这个值表示发送窗口吗？
这不是发送窗口，而是在向对方声明自己的接收窗口。
你可能会好奇，抓包文件里有「Window size scaling factor」，它其实是算出实际窗口大小的乘法因子，「Windos size value」实际上并不是真实的窗口大小，真实窗口大小的计算公式如下：
「Windos size value」 * 「Window size scaling factor」 = 「Caculated window size 」
对应的下图案例，也就是 32 * 2048 = 65536。
实际上是 Caculated window size 的值是 Wireshark 工具帮我们算好的，Window size scaling factor 和 Windos size value 的值是在 TCP 头部中，其中 Window size scaling factor 是在三次握手过程中确定的，如果你抓包的数据没有 TCP 三次握手，那可能就无法算出真实的窗口大小的值，如下图：
如何在包里看出发送窗口的大小？
很遗憾，没有简单的办法，发送窗口虽然是由接收窗口决定，但是它又可以被网络因素影响，也就是拥塞窗口，实际上发送窗口是值是 min(拥塞窗口，接收窗口)。
发送窗口和 MSS 有什么关系？
发送窗口决定了一口气能发多少字节，而 MSS 决定了这些字节要分多少包才能发完。
举个例子，如果发送窗口为 16000 字节的情况下，如果 MSS 是 1000 字节，那就需要发送 1600/1000 = 16 个包。
发送方在一个窗口发出 n 个包，是不是需要 n 个 ACK 确认报文？
不一定，因为 TCP 有累计确认机制，所以当收到多个数据包时，只需要应答最后一个数据包的 ACK 报文就可以了。
转自https://www.toutiao.com/i6834634888386183688/?timestamp=1591490656&app=news_article&group_id=6834634888386183688&use_new_style=0&req_id=202006070844160100140470421E965B4E