2015年，Julia Evans在工作中遇到了一个诡异的问题：向本地NSQ消息队列发布消息，每次请求都莫名其妙地多出40毫秒延迟。这是一个本地回环请求，理论上应该在1毫秒内完成。CPU负载正常，内存充足，没有任何明显的性能瓶颈。

调试了一周后，她想起了之前读过的一篇文章。尝试在代码中加入一行setsockopt(socket, TCP_NODELAY)后，所有40毫秒延迟瞬间消失。这个困扰团队一周的问题，根源竟在TCP协议栈的两个默认机制之间的"消极对峙"。

这不是个案。2025年，Cloudflare工程师在优化隐私代理服务时，发现"双花检查"环节存在稳定的40毫秒延迟。Marc Brooker在AWS博客中写道：“每次调试分布式系统延迟问题，我第一件事就是检查TCP_NODELAY是否开启。我认识的每一个分布式系统开发者，都在这个问题上浪费过时间。”

这个问题的根源可以追溯到1984年——两个独立设计、各自合理的TCP优化机制，在特定场景下形成了长达数百毫秒的"临时死锁"。

小包问题与Nagle算法的诞生

1984年1月，John Nagle在Ford Aerospace工作时发表了RFC 896，标题是《IP/TCP互联网络中的拥塞控制》。这篇文档讨论了一个当时越来越严重的问题：小包泛滥。

当时的ARPANET上出现了一种现象：某些Telnet应用会逐字符发送数据，每发送一个字节的用户数据，TCP就要封装一个41字节的包（1字节数据 + 20字节IP头 + 20字节TCP头）。这在网络负载较轻时还可以忍受，但当网络变得拥挤时，这些小包会严重加剧拥塞。

Nagle举了个例子：假设用户以每个字符200毫秒的速度打字，在一个往返时间为5秒的长距离链路上，5秒内会发送25个小包。而他提出的算法，只会发送1个包含25个字符的包，开销从4000%降低到320%。

Nagle算法的核心逻辑非常简单：如果连接上有未被确认的数据，就暂时不发送新的小包，等待累积更多数据或收到确认。用伪代码描述：

if 有足够数据填满一个MSS:
    立即发送
else if 连接空闲（所有数据都已确认）:
    立即发送
else:
    等待，直到收到ACK或累积足够数据

这个算法不需要任何定时器，完全依赖于网络的往返时间（RTT）来调节发送节奏。在当时的网络环境下，这是一个优雅的解决方案。

Delayed ACK：另一边的优化思路

就在Nagle算法诞生的同时，Berkeley的BSD团队在实现TCP时引入了另一个优化：Delayed ACK（延迟确认）。

Delayed ACK的逻辑同样合理：如果你刚收到一个数据包，很可能马上就要发送一些数据回去（比如Telnet的字符回显）。与其先发一个空的ACK包，再发一个数据包，不如等一小会儿，把ACK和数据合并在一起发送。

RFC 1122（1989年）对Delayed ACK做出了规范：接收方可以延迟发送ACK，但延迟时间不得超过500毫秒，且每收到两个全尺寸段就必须发送一个ACK。大多数系统实现中，这个延迟时间被设置为40-200毫秒：Linux通常使用40毫秒，Windows默认使用200毫秒。

这两个机制各自的出发点都是善意的：Nagle算法防止小包泛滥，Delayed ACK减少ACK包数量。但当它们相遇时，问题就出现了。

临时死锁：两个优化机制的消极对峙

2005年，Apple的工程师Stuart Cheshire写了一篇经典文章，详细描述了Nagle算法与Delayed ACK的交互问题。他当时正在调试一个WiFi性能测试程序，发现一个奇怪的现象：发送99,900字节时速度正常，但发送100,000字节时速度突然下降近一半。

通过抓包分析，他发现了问题的本质。当发送的数据量恰好需要奇数个全尺寸段加上一个短尾包时，会触发这样的序列：

  1. 发送方连续发送若干全尺寸段，最后一个段不满MSS
  2. 根据Nagle算法，发送方等待前面数据的ACK
  3. 接收方收到数据，但根据Delayed ACK规则，它在等待第二个全尺寸段或超时
  4. 最后一个短段还没发出，接收方只收到了奇数个段
  5. 双方都在等待：发送方等ACK，接收方等更多数据

这就是所谓的"临时死锁"。直到Delayed ACK的超时时间到期，接收方才发送ACK，打破僵局。

sequenceDiagram
    participant S as 发送方
    participant R as 接收方
    S->>R: 数据段1 (MSS)
    S->>R: 数据段2 (MSS)
    S->>R: 数据段3 (MSS, 最后一个)
    Note over S: Nagle: 还有未确认数据<br/>等待ACK再发送尾包
    Note over R: Delayed ACK: 收到奇数个段<br/>等待超时或更多数据
    S--xR: 尾包被Nagle阻塞
    Note over S,R: 40-200ms的沉默...
    R->>S: ACK (Delayed ACK超时)
    S->>R: 尾包终于发出

这个死锁不是永久的，但造成的延迟可能高达200毫秒甚至更多。在Julia Evans遇到的案例中，是40毫秒；在某些Windows系统上，可能是200毫秒。

为什么这个问题如此隐蔽

这个问题之所以难以排查，有几个原因：

数据量的相位效应

问题只在特定数据量下出现。以太网的标准MSS是1460字节（如果启用TCP时间戳选项则为1448字节）。只有当数据量恰好落在"奇数个MSS + 短尾包"的区间时，才会触发问题。

Stuart Cheshire的测试发现：99,900字节（68个MSS + 1436字节）工作正常，但100,000字节（69个MSS + 88字节）就会触发延迟。仅仅改变88字节的数据量，延迟就从0跳到200毫秒。

write模式的敏感性

问题还与程序的write调用模式有关。如果程序一次性write整个请求，TCP栈通常会正确处理。但如果程序分多次write（比如先写HTTP头部，再写body），问题更容易出现。

Ruby的Net::HTTP库就曾经有这个问题：它把POST请求分成两个TCP包发送——一个放头部，一个放body。同时它没有设置TCP_NODELAY。结果每次POST请求都会触发Nagle + Delayed ACK的交互延迟。

操作系统的实现差异

不同操作系统的Delayed ACK超时值不同：

  • Linux：通常40毫秒（可通过/proc/sys/net/ipv4/tcp_ato_min调整）
  • Windows：默认200毫秒（可通过注册表调整）
  • macOS/iOS：实现方式略有不同，在OS X 10.5之后采用了Minshall修改

这意味着同样的程序在不同系统上可能表现完全不同。Stuart Cheshire的测试中，Windows"碰巧"避开了问题（因为它的MSS是1460而非1448），而macOS则暴露了bug。

John Nagle本人的评论

有趣的是，John Nagle本人对这个问题有明确的态度。他在Hacker News上评论道：

“真正的问题是ACK延迟。那个200毫秒的’ACK延迟’定时器是个糟糕的主意，是1985年左右Berkeley某人在不完全理解问题的情况下加入BSD的。Delayed ACK是在赌应用层会在200毫秒内给出回复。TCP却持续使用Delayed ACK，即使它每次都输掉这个赌注。”

他进一步指出，ACK包很小且发送成本很低，Delayed ACK在实践中造成的问题远比它解决的问题严重。

这个评论揭示了一个重要的历史细节：Nagle算法和Delayed ACK虽然都在1980年代早期进入TCP实现，但它们是独立设计的，设计者之间没有充分协调。Nagle本人认为问题出在Delayed ACK的实现上，而不是他的算法。

学术界的深入研究

2001年，Compaq西部研究实验室的Jeffrey C. Mogul和Greg Minshall在SIGCOMM CCR上发表了一篇重要论文《Rethinking the TCP Nagle Algorithm》，系统分析了这个问题并提出了多种修改方案。

他们首先量化了问题的影响范围。通过分析真实的HTTP流量追踪数据，他们发现根据MSS和缓冲区大小的不同假设，有6.7%到18.8%的响应可能受到"奇数个全尺寸段 + 短尾包"问题的影响。

论文提出了几种修改方案：

Minshall修改：不阻塞紧跟在全尺寸段之后的短包。只有前一个短包未被确认时，才阻塞新的短包发送。这个修改允许"一个短包在飞"，打破了原始Nagle算法的绝对阻塞。

EOM（End of Message）方案：在套接字缓冲区管理中增加一个标记，指示应用层数据是否已全部写入。如果已到达消息末尾，即使包不够大也立即发送。

DLDET（Deadlock Detection）方案：当检测到进程即将阻塞在读操作上时，主动触发发送缓冲区中剩余的数据。这是一种优先级继承的思路。

他们的基准测试表明，Minshall修改和DLDET方案在大多数场景下表现良好，但各自都有边缘情况的问题。最佳方案取决于应用的具体行为模式。

重要的是，作者强调：不应该简单地禁用Nagle算法。虽然禁用Nagle可以避免延迟，但这会让网络暴露在写得不好的应用的"小包风暴"下。正确的做法是改进算法本身，而不是放弃它提供的保护。

生产环境的解决方案

在工程实践中，最常见的解决方案是设置TCP_NODELAY套接字选项：

int flag = 1;
setsockopt(socket, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

这会完全禁用Nagle算法，数据会在write时立即发送，不再等待ACK。

但这是否意味着我们应该到处设置TCP_NODELAY？Marc Brooker认为，对于现代数据中心环境中的延迟敏感型分布式系统，答案是肯定的：

“如果你正在现代数据中心级硬件上构建延迟敏感的分布式系统，无需顾虑地启用TCP_NODELAY。这不是什么罪过。去做就是了。”

他的理由是：现代应用很少发送单字节数据。大多数数据库和分布式系统的消息都足够大，而且还有TLS、序列化等额外的开销。“小包问题"已经在应用层得到了解决——没有人会愚蠢到在JSON里逐字节发送数据。

TCP_QUICKACK：另一个选择

Linux提供了TCP_QUICKACK选项，用于禁用Delayed ACK：

int flag = 1;
setsockopt(socket, IPPROTO_TCP, TCP_QUICKACK, &flag, sizeof(flag));

但这有个问题：TCP_QUICKACK不是一次性的设置，它只影响当前的ACK行为。下次收到数据时，Delayed ACK机制又会恢复。这使得它难以正确使用。

Marc Brooker指出，TCP_QUICKACK并没有解决根本问题：内核仍然可能在程序希望发送数据时把数据"扣留"一段时间。当你调用write()时，你期望数据被发送，而不是被缓冲。

TCP_CORK：Linux独有的选项

Linux还提供了一个有趣的选项：TCP_CORK。它与TCP_NODELAY相反：不是"立即发送”，而是"等到足够多再发送"。

TCP_CORK的设计意图是让应用程序可以精确控制发送时机：先设置CORK，写入所有数据，然后取消CORK。取消时会立即flush所有缓冲的数据。这在某些场景下比TCP_NODELAY更高效——如果你确实需要累积数据再发送。

双缓冲策略

Stuart Cheshire建议从根本上改变应用的设计模式：使用双缓冲。不要等待每个请求完成后才发送下一个，而是在等待第一个请求响应的同时，准备并发送第二个请求。这样管道中始终有数据流动，Nagle算法不会阻塞发送。

他观察到，从单缓冲改为双缓冲通常能获得几乎全部的性能提升，再增加到三缓冲、四缓冲收益有限。关键是确保管道中有"东西"在流动，而不是空转等待。

现代操作系统的改进

值得注意的是，现代操作系统已经对这个问题有所改进。

macOS从10.5（Leopard）开始，以及iOS，都实现了Greg Minshall在1998年提出的修改方案。这个修改允许一个短包在"飞行中"，即使前面还有未确认的数据——前提是前面的数据包都是全尺寸的。

OpenBSD在2024年5月宣布"废除"Nagle算法，将其设为可选而非默认行为。这引发了相当大的讨论，但最终反映了一个趋势：在现代高速网络环境中，Nagle算法的保护作用可能已经不如当初那么重要。

然而，Linux和Windows仍然保持Nagle算法默认开启。这意味着作为开发者，你仍然需要意识到这个问题的存在，并在必要时明确禁用它。

HTTP/2和QUIC的影响

有趣的是，HTTP/2和HTTP/3/QUIC在某种程度上让这个问题变得不那么相关了。

HTTP/2实现了自己的多路复用层，可以在单个TCP连接上并行发送多个请求。应用层已经做了批处理，不再需要TCP层的小包合并。

QUIC更进一步，它运行在UDP之上，完全绕过了TCP的这些机制。QUIC有自己的拥塞控制和确认机制，设计时就考虑到了这些历史教训。

但这并不意味着我们可以完全忽略这个问题。大量的遗留代码仍在使用HTTP/1.1，大量的TCP连接仍在使用默认的Nagle + Delayed ACK配置。在未来相当长的时间内，这仍然是一个需要了解和处理的工程问题。

实践指南

面对这个问题，应该怎么做？

对于新开发的服务端程序

如果延迟敏感，开启TCP_NODELAY。这是最简单、最可靠的解决方案。现代网络和应用层协议已经解决了小包泛滥的问题，Nagle算法的保护作用有限。

对于需要精确控制发送时机的场景

考虑TCP_CORK（仅限Linux）。在知道有多少数据要发送的情况下，这可以避免Nagle算法带来的延迟，同时仍然保持良好的网络效率。

对于请求-响应模式的协议

考虑实现双缓冲或流水线。这不仅可以避免Nagle延迟，还可以更好地利用网络带宽。

对于RPC框架

大多数现代RPC框架已经默认设置了TCP_NODELAY。如果你在实现自己的框架，记得加上这个选项。

对于客户端库

检查你使用的库是否设置了TCP_NODELAY。Ruby的Net::HTTP在较新版本中已经修复了这个问题。其他语言和库可能还有类似的问题。

TCP协议已经有四十多年的历史，其中包含了很多在当时的网络环境下设计的优化机制。这些机制各自合理，但在交互时可能产生意料之外的行为。Nagle算法与Delayed ACK的"临时死锁"就是这样一个经典的例子。

理解这些底层机制，不是要让我们成为"协议专家"，而是为了在遇到问题时能够快速定位和解决。正如Julia Evans所说：“你不需要理解TCP的一切，但一点点TCP知识是必不可少的。”

那个神秘的40毫秒延迟，可能就藏在你的TCP栈的默认配置里。

参考资料

  • Nagle, J. “Congestion Control in IP/TCP Internetworks” RFC 896, January 1984
  • Braden, R. “Requirements for Internet Hosts – Communication Layers” RFC 1122, October 1989
  • Mogul, J. & Minshall, G. “Rethinking the TCP Nagle Algorithm” ACM SIGCOMM CCR, January 2001
  • Cheshire, S. “TCP Performance problems caused by interaction between Nagle’s Algorithm and Delayed ACK” May 2005
  • Minshall, G. “A Suggested Modification to Nagle’s Algorithm” IETF Draft, December 1998
  • Brooker, M. “It’s always TCP_NODELAY. Every damn time.” May 2024
  • Evans, J. “Why you should understand (a little) about TCP” November 2015
  • Cloudflare Blog “Reducing double spend latency from 40 ms to < 1 ms on privacy proxy” August 2025