网络传输，请每次都开启 TCP

网络传输，请每次都开启 TCP_NODELAY

news2025/1/16 17:48:54

在这里插入图片描述

原文：Marc Brooker - 2024.05.09

（注：不必过于担心这个问题，大部分现代库，语言（如 Go），代理（如 Envoy），都默认设置了 TCP_NODELAY。如果遇到网络延迟问题，可再检查该套接字选项。）

我们已经不再生活在上世纪 80 年代了，谢天谢地！

在调试分布式系统的延迟问题时，我首先检查的就是 TCP_NODELAY 是否启用。不仅仅是我，我认识的每个分布式系统构建者，都曾因为启用了这个简单的套接字选项而迅速修复了延迟问题，这说明默认行为是错误的，也许整个概念都过时了。

首先，要明确我们在讨论什么。没有比 John Nagle 1984 年的 RFC896 更好的资料来源了。下面是问题陈述：

有一个与小数据包相关的特殊问题。当 TCP 用于传输源自键盘的单字符信息时，典型的结果是每传输一个字节的有效数据，就要传输 41 个字节的数据包（1 个字节的数据，40 个字节的报头）。这 4000% 的开销虽然令人讨厌，但在负载较低的网络中还是可以忍受的。

简单地说，Nagle 想要更好地摊销 TCP 报头的成本，以便从网络中获得更好的吞吐量。吞吐量最多可提高 40 倍！造成这些微小数据包的主要原因有两个：一是像 shell 这样的人机交互应用程序，人们一次只输入一个字节；二是程序的实现不佳，通过多次 write 调用向内核发送信息。Nagle 提出的解决的方案既简单又聪明：

我们已经找到了一个简单且优雅的解决方案。

这个解决方案就是，当用户发送新数据时，如果网络连接上之前传输的任何数据仍未被确认，则禁止发送新的 TCP 段。

很多人在谈到 Nagle 算法时都会提到计时器，但 RFC896 并没有使用除网络往返时间以外的任何计时器。

Nagle 的算法与延迟确认

Nagle 清晰、简洁的提案与另一个 TCP 功能交互不畅：延迟确认。延迟确认背后的理念是延迟发送对数据包的确认，至少要等到有数据要回传（例如 telnet 会话回传用户输入的内容），或者等到计时器到期。1982 年的 RFC813 似乎是第一个提出延迟确认的文件：

数据接收方在某些情况下将不发送 ACK，在这种情况下，接收方必须设置一个计时器，使 ACK 在稍后发送。不过，接收方只有在可以合理推测会有其他事件介入，从而避免定时器中断的情况下，才应该这样做。

随后，在 1989 年的 RFC1122 中，得到了进一步的正式规定。这两个特性之间的相互作用引发了一个问题：Nagle 算法会阻止发送更多数据，直到收到一个 ACK；而延迟确认则会延迟该 ACK，直到准备好一个响应。这对于保持数据包满载很有帮助，但对于延迟敏感的高并发应用就没那么好了。

这也是 Nagle 自己多次提出的观点。例如在这个 Hacker News 评论中：

这仍然让我感到恼火。真正的问题不是防止小报文。而是 ACK 延迟和那个愚蠢的固定计时器。这两个问题大约同时出现在 TCP 中，但各自独立。在 1980 年代初，我做了小报文优化的 Nagle 算法，伯克利做了延迟确认。两者的结合非常糟糕。

作为系统建设者，这种情况应该不陌生：系统中两个合理的特性相互作用，产生了不良行为。这种相互作用正是协议设计之所以如此困难的原因之一。

Nagle 算法真的无可指责吗？

遗憾的是，问题不仅仅在于延迟确认。即使没有延迟确认和那个愚蠢的固定定时器，在分布式系统中，Nagle 算法的行为可能也不是我们想要的。单个数据中心内的 RTT 通常约为 500 微秒，同一区域内的数据中心之间为几毫秒，全球范围内则高达数百毫秒。考虑到现代服务器在几百微秒内就能完成大量工作，即使延迟一个 RTT 发送数据也不会有明显的优势。

为了更清楚地说明这一点，让我们回到 Nagle 算法背后的理由：摊销报头成本，避免单字节数据包的 40 倍开销。但现在还有人发送单字节数据包吗？大多数分布式数据库和系统都不会。部分原因是它们有更多的数据，部分原因是 TLS 等协议的额外开销，部分原因是编码和序列化开销。但最主要的是，它们有更多的内容和数据。

不发送微小信息的核心问题依然存在，但我们已经非常有效地将其推向了应用层。无论 Nagle 算法如何处理，一次发送一个用 JSON 封装的字节都不会非常高效。