Nagle算法和延迟ACK用于批量数据吗？

Question

所以，当我看到Nagle的算法并为小数据包(1字节数据)延迟ACK时，我正在浏览TCP内容。其原因是，避免在网络上发送大量小数据包(Nagle)和携带数据(延迟ACK)。然而，没有提到这些大容量数据的算法，即我写的> 8000字节。4个问题：

1. 这些算法只适用于小型数据包吗？
2. 对于ex，当我们执行写(8000)时，TCP首先发送1500个字节(假设1500字节为MSS，慢启动正在发生)，在第一个ACK接收之前，它可以发送另外1500个字节的数据，那么它是否违反了Nagle的？
3. 接收方是等待超时来发送延迟的ACK，还是在接收到1500字节的数据后立即发送？
4. 它如何知道何时延迟ACK？它是否基于接收缓冲区中的字节？

谢谢!

Answer 1

Nagle算法的思想是防止一次传输多个小于大小的数据包。延迟ACK (来自伯克利)的想法是，当输入带有远程回波的Telnet连接时，避免为接收到的每个字符发送一个单独的ACK，方法是在反向方向等待固定的通信量，以支持ACK。

这两种算法之间的相互作用是可怕的。如果你做了大发送，那就好了。如果你确实发送，得到回复，发送，得到回复，这是很好的。如果你做小发送，小发送，得到回复，就会有一个短暂的停顿。这是因为第二个小的发送被Nagle算法延迟，直到ACK返回，而延迟的ACK算法在发生之前增加0.5秒左右。

延迟的ACK是个赌注。TCP实现押注的是，数据将很快发送，因此没有必要发送一个单独的ACK。每次一个延迟的ACK被实际发送，那个赌注就输掉了。TCP规范允许实现每次都在不关闭延迟ACK的情况下输掉该赌注。正常情况下，延迟ACK只应在以下情况下打开:可能已被备份的一些不必要的ACK已连续发送，并且任何时候延迟ACK实际上已发送，延迟ACK应再次关闭。这个应该有个柜台的。

不幸的是，在我1986年离开网络后，延迟的ACK进入了网络，而这个从来没有被修复过。现在已经太晚了。

约翰·纳格尔

Answer 2

Nagle的算法被认为是为了减少小数据包的数量(例如，它不会为您通过慢速链路输入到telnet中的每个字符发送单个数据包)。如果它可以发送一个完整的包，它应该发送一个完整的包。它没有违反RFC 1122节4.2.3.4中的描述

如果有未确认的数据(即SND.NXT > SND.UNA)，则发送TCP缓冲所有用户数据(无论PSH位)，直到未完成的数据被确认或直到TCP可以发送一个完整的段 (Eff.snd.MSS字节；请参阅第4.2.2.6节)。

延迟的ACK减少了向相反方向发送的数据包数量，但是RFC 1122中的描述在很大程度上取决于实现：

TCP应该实现延迟的ACK，但是ACK不应该被过度延迟；特别是，延迟必须小于0.5秒，并且在一个完整大小的段流中，至少每个第二个段都应该有一个ACK。

请注意，当您发送“批量数据”时，接收方不是！如果它立即发送ACK，它们都是小数据包，可能会有很大的开销。

Answer 3

1. 通过套接字选项关闭Nagle。默认情况下，Nagle和延迟ack都是设置的。Nagle延迟传输，除非形成一个完整的数据包，或者管道中有未加加的数据，因此，它会影响小数据包的应用受限流的性能。
2. 这取决于发送模式。
3. 如果在接收端已经有一个未加标记的数据包，这1500个字节将产生ack。但是，如果没有先前接收到的数据，并且接收器没有使用快速ack，则发送ack将被延迟一段时间(例如200 ms)，或者除非接收到下一个分组。
4. 3号会有帮助的。