共计 1684 个字符，预计需要花费 5 分钟才能阅读完成。
TCP 的 Delayed ACK 与 Nagle 算法相互作用造成交易处理延迟，是我们最常见的典型网络故障之一。不久前，某金融机构的运维部门对支付平台程序升级后，就经历了 Delayed ACK 与 Nagle 算法相互作用导致交易变慢的问题。我们利用网络故障分析方法一起来看看这个案例。
问题突发
这家金融机构的运维人员在完成支付平台的程序升级后，发现新系统的业务处理能力并没有得到明显提高：在支付高峰期，业务交易反而变慢，交易量一直上不去，严重影响用户的在线消费支付体验。反反复复检查网络与应用配置，都没有发现明显异常，最后决定采取捕获数据包来进行分析。
数据包分析
运维人员拿到数据包后用分析工具打开，并未发现有丢包重传、服务器响应慢等问题。但是通过 TCP 时间间隔进行排序，发现了异常现象：间隔中有许多 200ms 左右的延迟，几乎没有 payload 数据负载 ACK 的回应。大家第一时间联想到这些延迟可能是 Delayed ACK 与 Nagle 算法相互作用而产生的。
用基于数据流的 Dali 工具打开数据包，进行时间间隔设置，把超过 190ms 的触发用红色标记显示。查看数据交互会话流，发现服务端在回复 ACK 时有连续多个 200ms 的延迟，这大大降低了数据传输效率，影响业务处理速度。
具体分析每个 200ms 延迟，发现这些延迟的 ACK 都没有 payload 的数据负载，全部在延迟了 200ms 后确认了之前的同一个数据包。
问题定位
通过以上现象可以看出，没有 payload 数据负载的 ACK 延迟了 200ms 左右，这些延迟了的 ACK 仅仅确认了一个数据包的请求。打开其它的会话发现是同样的现象，最终确定这些延迟就是 TCP 的 Delayed ACK 与 Nagle 算法相互作用导致的。
问题总结
Delayed ACK
Delayed ACK 是 TCP 的一种流控手段。如果有响应数据发送时，ACK 会随响应数据一起发送给对方；如果没有响应数据，ACK 的发送就会有延迟，以等待看是否有响应数据一起发送。
Nagle 算法
Nagle 算法是通过减少网络连接中 <MSS 的数据包的数量，从而防止网络拥塞的控制手段。任意时刻中最多只能有一个未被确认的小包（尺寸 <MSS 的数据包）。简单来说，当发送方要发出不满 MSS 的数据包时，需要前面发出的数据包都得到 ACK 确认。而接收方因为 Delayed ACK 的原因延迟了 ACK 的回应，导致发送方和接收方都在等待，造成了我们所说的 ACK 延迟。
Delayed ACK+Nagle 算法
双方不会无限制等待下去，最多不超过 500ms，一般情况下系统内核启动的定时器默认 200ms 的延迟。从 0 到 200 循环计时，每隔 200ms 检查是否有 ACK 需要发送，因此 ACK 延迟可能是 200ms 内任意一个数值。
解决问题
Nagle 算法只适用于特定的场景。有一种说法认为 Nagle 算法引入了不必要的延迟，这种说法目前来看适用于多数场景，譬如本案例。该机构在支付平台升级后，Nagle 算法默认开启，导致 ACK 延迟进而影响业务。关掉 Nagle 算法后，问题得以解决。
自动化服务路径监控解决方案
解决此类问题时，我们需要了解 TCP 的各种拥塞控制和 TCP/IP 相关的原理知识，排查分析的过程相对比较复杂。当然也可以通过服务路径监控的方式，进行自动化的持续监控，在出现问题时做到自动化分析、告警，提升运维效率，保障业务稳定。
天旦网络性能管理 NPM 产品将复杂的网络性能管理化繁为简。NPM 利用网络数据包、IPFIX 流数据，能够建立覆盖数据中心重要链路、关键设备、核心服务路径的监控视图。将复杂的网络分析技术注入产品的核心技术中，将数以月计的服务路径梳理缩短为周。同时，基于成熟的数据采集与处理技术，能够全量采集网络数据、实时刷新关键网络监控指标、精准告警，并对关键业务的网络行为进行监控、审计和回溯分析，提升业务系统的安全保障能力。
————————————————
版权声明：本文为 CSDN 博主「天旦 Netis」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Netis20…