📜  傻窗综合症

📅  最后修改于: 2021-09-27 14:45:23             🧑  作者: Mango

Silly Window Syndrome是由于 TCP 执行不善而引起的问题。它会降低 TCP 性能并使数据传输效率极低。之所以这样称呼这个问题,是因为:

  1. 它会导致发送窗口大小缩小到一个愚蠢的值。
  2. 窗口大小缩小到传输数据小于 TCP 标头的程度。

原因是什么?
该综合征的两个主要原因如下:

  1. 发送者窗口重复传输一个字节的数据。
  2. 接收器窗口重复接受一字节数据。

原因 1:发送方窗口重复传输 1 个字节的数据 –
假设应用程序仅生成一个字节的数据。 TCP 的糟糕实现导致传输这一小段数据。应用程序每次生成一个字节的数据时,窗口都会传输它。这使得传输过程缓慢且效率低下。该问题由Nagle 算法解决。

Nagle 的算法建议:

  1. 从应用程序接收到一个字节数据时,发送方应仅发送第一个字节。
  2. 发送者应该缓冲所有剩余的字节,直到未完成的字节得到确认。
  3. 换句话说,发送方应该等待 1 个 RTT(往返时间)。

发送方收到确认后,应将缓存的数据发送到一个 TCP 报文段中。然后,发送方应再次缓冲数据,直到先前发送的数据得到确认。

原因 2:接收器窗口重复接受 1 个字节的数据 –
假设考虑接收方无法处理所有传入数据的情况,在这种情况下,接收方会通告一个很小的窗口大小。这个过程继续进行,窗口大小越来越小。重复通告窗口时到达一个阶段1 个字节的大小。这使得接收过程缓慢且效率低下。这个问题的解决方案是克拉克的解决方案。

克拉克的解决方案建议:

  1. 接收器不应发送 1 个字节的窗口更新。
  2. 接收器应该等到它有足够的可用空间。
  3. 接收方然后应该将该窗口大小通告给发送方。

笔记:

  1. 对于那些需要立即发送数据的应用程序,Nagle 的算法被关闭。 Nagle 的算法会引入延迟,因为它每次往返仅发送一个数据段。
  2. Nagle 和 Clark 的算法可以一起工作。两者是互补的。

例子:
一个快速的打字员每分钟可以打 100 个单词,每个单词平均有 6 个字符。通过显示具有来自我们的快速打字员的输入的客户端和服务器之间的 TCP 段交换序列来演示 Nagle 的算法。表示客户端发送的每段包含多少个字符。假设客户端和服务器在同一个局域网内,RTT为20毫秒?

Nagle 的算法建议:
发送方在发送数据之前应等待 1 个 RTT。 1个RTT中从应用层接收到的数据量应该发送给接收者。

1个RTT累积的数据量,

= (600 characters / 1 minute) x 20 msec
= (600 characters / 60 sec) x 20 msec
= (10 characters / 103 msec) x 20 msec
= 0.2 characters 

从这里,我们观察到:
即使发送方等待 1 个 RTT,也不会产生一个字符。因此,发送方必须等到它收到至少 1 个字符。然后,发送方将其分成一个段发送。因此,每个段将发送一个字符。假设 TCP 头部长度为 20 字节,则每段将发送 41 字节的数据。