Nagle 与小包延迟
Nagle 算法为减少网络中碎包数量，规定在已有未被确认的数据在途时，后续的小段要攒起来等确认回来再发。它与接收端的延迟确认叠加时会明显放大交互延迟：发送方在等确认，接收方在等更多数据，典型表现是请求响应型小报文多出几十毫秒。抓包判据是看小段的发送间隔是否与确认返回时间相关，而关闭该算法之后小段会立即连续发出。区分的要点在于间隔量级——与往返时间同量级才说明是协议行为。
基本信息
| 算法依据 | RFC 896（Nagle 算法） |
|---|---|
| 关闭方式 | 设置 TCP_NODELAY 套接字选项 |
| 抓包特征 | 小段发送间隔与确认返回时间相关 |
| 放大因素 | 与接收端延迟确认机制叠加 |
| 高发场景 | RPC、交互式协议、请求响应型小报文 |
典型使用场景
- 交互延迟排查：请求报文很小但响应很慢，检查是否被攒包机制拖住
- 参数对比：比较开启与关闭该选项时的发送间隔分布
- 协议设计评估：确认交互式协议是否应当关闭该算法
- 与延迟确认区分：两者叠加时延迟更明显，需要分别确认
- 回归验证：调整选项后复测并确认小包数量没有失控
观察与对照
观察与对照
tcp.len > 0 && tcp.len < 100 && tcp.stream == N # 小段
tcp.analysis.acks_frame # 看后续小段等的是哪个确认
# 间隔约等于往返时间 → 与攒包机制相关
# 关闭 TCP_NODELAY 相关行为后小段立即连续发出两种表现对照
| 设置状态 | 抓包表现 | 影响 |
|---|---|---|
| 保持默认 | 小段可能等待前段确认，间隔接近往返时间 | 交互延迟偏大 |
| 关闭攒包 | 小段立即连续发出 | 报文中包数量上升 |
| 叠加延迟确认 | 间隔出现台阶状变化 | 延迟更明显，需两端一起看 |
交互式协议与应用层心跳通常配合关闭攒包使用，属于常见组合；但纯批量传输场景关闭它会让包数量明显增加，成本与收益需要权衡。
发送间隔分析要排除应用自身写入节奏的干扰：程序每隔固定时间才写一次数据时，间隔反映的是业务逻辑而不是协议行为。