networking - Nagle 算法和延迟 ACK 是否用于批量数据？

Question

因此，当我遇到 Nagle 的算法和针对小型数据包(1 字节数据)的延迟 ACK 时，我正在研究 TCP。原因是，避免在网络上发送大量小数据包 (Nagle) 和搭载数据 (Delayed ACK)。然而，没有提到这些用于批量数据的算法，即我写了 > 8000 字节。 4 个问题:

1. 这些算法是否只适用于小数据包？

2. 例如，当我们写(8000)时，TCP 首先发送 1500 字节(假设 1500 为 MSS 并且正在发生慢启动)，在第一次收到 ACK 之前，它可以发送另一个 1500字节的数据，那么是不是违反了 Nagle 的规定？

3. 接收方是等待超时发送延迟ACK还是在收到1500字节数据后立即发送？

4. 它如何知道何时延迟 ACK？它是基于其接收缓冲区中的字节吗？

谢谢!

Answer 1

Nagle 算法的思想是防止同时传输多个尺寸过小的数据包。延迟 ACK 的想法(来自伯克利)是为了避免在使用远程回显通过 Telnet 连接键入时为接收到的每个字符发送单独的 ACK，方法是等待固定的反向流量时间段，ACK 可以搭载在该时间段上.

这两种算法的交互很糟糕。如果你做大发送，大发送，大发送，效果很好。如果你确实发送，得到回复，发送，得到回复，那工作正常。如果你做small send, small send, get reply，会有短暂的停顿。这是因为 Nagle 算法延迟了第二个小发送，直到 ACK 返回，而延迟的 ACK 算法在此之前增加了 0.5 秒左右。

延迟的 ACK 是一个赌注。 TCP 实现押注数据将很快发送，因此无需发送单独的 ACK。每次实际发送延迟的 ACK 时，该赌注就输了。 TCP 规范允许实现每次都输掉赌注而不关闭延迟的 ACK。正确地，延迟 ACK 应该只在连续发送了一些可能被搭载的不必要的 ACK 时打开，并且任何时候实际发送延迟 ACK 时，延迟 ACK 应该再次关闭。应该有一个柜台。

不幸的是，在我 1986 年离开网络后，延迟的 ACK 出现了，而且这个问题从未得到修复。现在已经太晚了。

约翰·内格尔