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