摘要

  • 当此前没有数据处于未确认状态时，Nagle 规则允许先发送一个小段；随后到来的小写入会被暂存，直到收到确认或积累出一个完整段。
  • 该规则不同于接收方的延迟确认、发送端避免糊涂窗口综合征的机制以及拥塞控制，并且必须允许应用按连接禁用它。

RFC 896 于 1984 年 1 月发布，描述了早期 TCP/IP 网络中的小包问题。应用若一次产生一个字符，一个字节的数据可能要携带四十个 TCP 和 IP 首部字节。在异构且负载较高的网络中，大量小包会消耗受限链路和网关的处理能力，增加拥塞，并可能带来丢包与重传。

早期常见的办法是用 200 到 500 毫秒的短计时器收集字符。但不同网络的带宽和往返时延差异很大：适合本地网络的时间可能无法在长路径上有效聚合，而适合长路径的时间又可能让本地交互显得迟缓。Nagle 的转变在于，让发送许可取决于确认状态，而不是一段固定的等待时间。

RFC 1122 用 SND.NXT > SND.UNA 描述这一状态。这意味着已经发送的数据仍未得到确认。只要条件成立，发送方就缓存用户数据，不论 PSH 位如何，直到未确认数据获得确认，或者排队数据达到 Eff.snd.MSS，足以组成完整段。完整段本身就是独立的释放条件。如果连接此前空闲、没有数据在途，那么第一次小写入可以立即发送。

RFC 1122 建议 TCP 实现 Nagle，同时强制要求应用能够对单条连接禁用它。RFC 9293 延续了这一规范边界，并指出发送仍受慢启动约束。Nagle 只回答是否应由排队数据形成另一个小段，不会替代拥塞控制。

它也不规定接收方何时发送确认。RFC 9293 将 Nagle 与发送端避免糊涂窗口综合征的机制区分开来，并明确提醒它可能与延迟确认发生不良互动。发送方等待 ACK 推进，而接收方又有意延迟 ACK 时，两个各自合理的机制可能在交界处叠加出额外停顿。

来源