2024 软件水平测试：TCP 协议的部分解析(2)端到端意义上的 TCP 协议效率 1.三个问题以及解决 问题 1 描述：接收端处理慢，导致接收窗口被填满 这明显是速率不匹配引发的问题，然而即使速率不匹配，只要滑动窗口能协调好它们的速率就好，要快都快，要慢都慢，事实上滑动窗口在这一点上做的很好。但是假如我们不得不从效率上来考虑问题的话，事实就不那么乐观了。考虑此时接收窗口已然被填满，慢速的应用程序慢腾腾的读取了一个字节，空出一个位置，然后通告给 TCP 的发送端，发送端得知空出一个位置，立即发出一个字节，又将接收端填满，然后接收应用程序又一次慢腾腾...这就是糊涂窗口综合症，一个大多数人都很熟识的词。这个问题极大的铺张了网络带宽，降低了网络利用率。好比从大同拉 100 吨煤到北京需要一辆车，拉 1Kg 煤到北京也需要一辆车(超级夸张的一个例子，请不要信任)，但是一辆车开到北京的开销是肯定的... 问题 1 解决：窗口通告 对于问题 1，很明显问题出在接收端，我们没有方法限制发送端不发送小分段，但是却可以限制接收端通告小窗口，这是合理的，这并不影响应用程序，此时经典的延迟/吞吐量反比律将不再适用，因为接收窗口是满的，其空出一半空间表示还有一半空间有数据没有被应用读取，和其空出一个字节的空间的效果是一样的，因此可以限制接收端当窗口为 0 时，直接通告给发送端以阻挡其连续发送数据，只有当其接收窗口再次达到 MSS 的一半大小的时候才通告一个不为 0 的窗口，此前对于全部的发送端的窗口 probe 分段(用于探测接收端窗口大小的 probe 分段，由 TCP 标准规定)，全部通告窗口为 0，这样发送端在收到窗口不为 0 的通告，那么确定是一个比较大的窗口，因此发送端可以一次性发出一个很大的 TCP 分段，包含大量数据，也即拉了好几十吨的煤到北京，而不是只拉了几公斤。 即，限制窗口通告时机，解决糊涂窗口综合症 问题 2 描述：发送端持续发送小包，导致窗口闲置 这明显是发送端引起的问题，此时接收端的窗口开得很大，然而发送端却不积累数据，还是一味的发送小块数据分段。只要发送了任和的分段，接收端都要无条件接收并且确认，这完全符合 TCP法律规范，因此必定要限制发送端不发送这样的小分段。 问题 2 解决：Nagle 算法 Nagel 算法很简洁，标准的 Nagle 算法为： IF 数据的大小和窗口的大小都超过了 MSS Then 发送数据分段 ELSE IF 还有发出的 T...
