愚蠢的“窗户综合征”

愚蠢的“窗户综合征”这是一个由于实施不当而产生的問題。TCP它会降低TCP的传输性能，使得数据传输变得极其低效。之所以会有这样的问题，是因为：

1. 这会导致发送方的窗口大小缩小到一个荒谬的数值。
   
2. 窗口的大小缩小到如此小的程度，以至于传输的数据量甚至小于TCP头部所包含的数据量。
   

造成这种情况的原因是什么？
这种综合征的两个主要成因如下：

1. 发送方以重复的方式传输一个字节的数据。
   
2. 接收窗口可以连续接收一个字节的数据。
   

原因1：发送方以重复的方式传输一个字节的数据。
假设一个应用程序只生成1字节的数据。由于TCP的实现方式不佳，这些少量数据会被一次性传输出去。每当应用程序生成1字节的数据时，窗口就会立即将其发送出去。这就使得数据传输过程变得缓慢且效率低下。这个问题可以通过Nagle算法来解决。
Nagle的算法建议如下：

1. 发送方在收到应用程序发送的一个字节的数据后，只需发送第一个字节即可。
   
2. 发送方应该缓存所有剩余的字节数据，直到那些尚未被确认的字节得到确认为止。
   
3. 换句话说，发送方需要等待1个往返时间。
   

在收到确认消息之后，发送方应该将缓冲的数据通过一条TCP数据包发送出去。然后，发送方需要继续对数据进行缓冲处理，直到之前发送的数据得到确认为止。
原因2：接收窗口能够反复接受一个字节的数据。
假设接收方无法处理所有传入的数据。在这种情况下，接收方会采用较小的窗口大小来传输数据。随着过程的持续进行，窗口大小会逐渐变小。最终，接收方会反复使用1字节的窗口大小来传输数据。这样一来，接收过程就会变得缓慢且效率低下。解决这个问题的方法是使用Clark的解决方案。
克拉克的解决方案是：

1. 接收方不应为1字节的数据发送更新窗口信息。
   
2. 接收者应该等待，直到有足够的空间可用为止。
   
3. 然后，接收方应该向发送方告知该窗口大小。
   

注意：

1. 对于那些需要立即发送数据的应用程序来说，Nagle算法是会被关闭的。因为Nagle算法在每次往返过程中只传输一个数据段，所以可能会导致延迟。
   
2. Nagle的算法和Clark的算法可以协同工作。两者是互补的。
   

例如：
一个打字速度很快的人，每分钟可以输入100个字。每个字平均包含6个字符。通过展示客户端与我们这个打字速度快的人之间的TCP数据包交换过程，来演示Nagle算法。同时，需要说明客户端发送的每个数据包中包含多少个字符。假设客户端和服务器位于同一局域网内，且RTT为20毫秒。
Nagle的算法建议如下：
发送方应在发送数据之前等待 1 个 RTT 的时间。在 1 个 RTT 内，从应用层接收到的数据量应该被发送给接收方。
在1个RTT时间内累积的数据量。

=(600个字符/1分钟) × 20毫秒
=(600个字符/60秒) × 20毫秒
=(1个字符/100毫秒) × 20毫秒
= 0.2个字符

从这里来看，我们可以得出以下结论：
即使发送方等待1个RTT的时间，也根本无法发送出任何一个字符。因此，发送方必须等待，直到至少接收到1个字符之后，才能继续发送下一个字符。这样，每个段中就会包含1个字符。假设TCP头部的长度为20字节，那么每个段中就会包含41字节的数据。