26

So, I was going through TCP stuff when I came across Nagle's algorithm and delayed ACKs for small sized packets (1 byte data). The reason being, avoiding to send lot of small packets on the network (Nagle) and piggybacking data(Delayed ACK). There was however, no mention about these algorithms for bulk data, i.e I do a write of > 8000 bytes. 4 questions:

  1. Is these algorithms only applicable for small sized packets?

  2. For ex, when we do a write(8000), TCP first sends 1500 bytes (Assume 1500 to be MSS and slow start is happening) , before an ACK is received for the first, it can send another 1500 bytes of data, then isn't violating Nagle's?

  3. Does the receiver wait for the timeout to send a delayed ACK or does it send immediately after receiving 1500 bytes of data?

  4. How does it know when to delay an ACK? Is it based on the bytes in its receive buffer?

Thanks!

4

3 回答 3

77

Nagle 算法的想法是防止一次超过一个尺寸过小的数据包在传输中。延迟 ACK（来自伯克利）的想法是避免在通过远程回显的 Telnet 连接键入时为接收到的每个字符发送一个单独的 ACK，方法是等待一个固定的时间段来接收反向方向的流量，在该时间段上可以捎带 ACK .

这两种算法的交互非常糟糕。如果您进行大发送，大发送，大发送，那效果很好。如果你确实发送，得到回复，发送，得到回复，那很好。如果你做小发送，小发送，得到回复，会有一个短暂的停顿。这是因为第二次小发送被 Nagle 算法延迟到 ACK 返回，而延迟 ACK 算法在此之前增加了 0.5 秒左右。

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

不幸的是，在我 1986 年退出网络之后，延迟的 ACK 就出现了，而且这个问题从未得到解决。现在为时已晚。

约翰·纳格尔

于 2013-05-21T06:06:09.220 回答
1

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，它们都是小数据包，可能会产生很多开销。

于 2013-05-01T00:24:44.310 回答
0

  1. Nagle 通过套接字选项关闭。Nagle 和 Delayed ack 均默认设置。Nagle 会延迟传输，除非形成完整的数据包或管道中有未确认的数据，因此，它会影响小数据包的应用程序受限流的性能。

  2. 这取决于发送模式

  3. 如果接收方已经有一个未确认的数据包，这 1500 个字节将进行确认。但是，如果之前没有接收到数据并且接收方没有使用快速确认，则发送确认将延迟一段时间（例如 200 毫秒）或除非收到下一个数据包。

  4. 3号会有所帮助。

于 2013-04-30T20:07:30.930 回答