前文详细介绍了滑动窗口，TCP 通过滑动窗口来完成流量控制，当接收方发现自己跟不上发送的速度了，就缩小接收窗口大小，抑制发送方的发送速度，防止发送方发送太快。
这里面其实有一个隐藏的问题，那就是接收方的接收能力越来越差怎么办？甚至一次性能接收的数据量就几个字节
几个字节是个什么概念
TCP 报文首部就占 20 字节了，如果每次接收方只允许发送方发送两三个字节，那就为了传输这么几个有效的字节，还得附加上 20 字节的数据。这开销属实是划不来。
这就好比古时行军二十个后勤人员才能补充前线一个战士所需的粮草，几天几夜跑过去就给人送一个小土豆
所以 TCP 糊涂窗口综合症（Silly Window Syndrome, SWS）简单来说，其实就是接收方接收能力变差，窗口变小，导致发送方犯傻，其发送的数据只有一个大大的头部，真正携带的数据很少。
接收方和发送方都有问题：
- • 接收方：通告了发送方窗口缩小
- • 发送方：即使窗口很小也还是发送数据
所以，解决接收方和发送方各自的问题，就能避免糊涂窗口综合症的出现。
老规矩，背诵版在文末
接收方的策略
接收方的策略很简单，目的就是防止发送方发送小数据嘛
- • 那只要窗口大小 < 某个值（内核缓冲区大小的一半，也称为
最大段长度 MSS）的时候，就直接将窗口大小设置为 0，防止发送方发送小数据 注意这里区分下内核缓冲区（buffer）和 CPU 缓存（cache）的概念，TCP 由内核维护，窗口的本质是内核缓冲区。很多博客这里写成缓存会给一些小伙伴造成误解~ - • 然后等到窗口大小 >= 内核缓冲区大小的一半 的时候，才打开窗口，通告发送方，告知其可以发送数据。
这样就阻止了发送方发送小报文了。
还有一种方法，称为 “延迟确认应答”
回顾下前文对接收窗口变化的介绍：
- • 接收方根据缓冲区空闲的空间大小，计算出后续能够接收多少字节的报文（即接收窗口的大小）
- • 当内核接收到报文时，将其存放在缓冲区中，这样缓冲区中空闲的空间就变小了，接收窗口也就随之变小了
- • 当进程调用
read函数后（将数据从内核缓冲区复制到用户/进程缓冲区），报文数据被读入了用户空间，内核缓冲区就被清空，这意味着主机可以接收更多的报文，接收窗口就会变大
如果接受数据的主机在接收到报文的时候（第二步）就立刻返回 ACK 应答，这时候返回的窗口可能比较小。为什么这么说呢，举个例子：
- • 假设接受方主机的内核缓冲区大小为 1M，一次性收到了 500K 的数据，如果在第二步就立刻回复应答，那么返回的窗口大小就是 500K
- • 但实际上可能第三步处理得速度很快，很快就把 500K 数据从缓冲区消费掉了
- • 所以，如果接收方稍微等一会再应答，那么这个时候返回的窗口大小就是 1M，这样，发送方能够发送的数据是不是更多了呢~
这就是延迟确认应答。通常来说，有以下两种情况：
- • 在没有收到 2 x MSS 的数据为止不做确认应答（根据操作系统的不同，有时也不论数据大小，只要收到两个包就立刻返回确认应答）
- • 其他情况下，最大延迟 0.5s（每个操作系统是不同的）发送确认应答
也确实没有必要对每一个数据段都进行确认应答，毕竟用的滑动窗口（累计应答），应答少一些也无妨。在 TCP 文件传输中，绝大多数都是每两个报文段返回一次确认应答：
发送方的策略
发送方的目的也很简单，就是不要犯傻去发送小报文就行了
常用的策略是 Nagle 算法
该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送的一种处理机制。
具体来说，就是仅在下列任意一种条件下才能发送数据
- • 已发送的数据都已经收到确认应答时
- • 可以发送的数据大小 >= MSS
如果两个条件都不满足，那么发送方就是囤积数据，等待一段时间后再进行数据发送。
最后放上这道题的背诵版：
