网络排障大法之Delayed ACK与Nagle算法相互作用导致交易变慢

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流数据，能够建立覆盖数据中心重要链路、关键设备、核心服务路径的监控视图。将复杂的网络分析技术注入产品的核心技术中，将数以月计的服务路径梳理缩短为周。同时，基于成熟的数据采集与处理技术，能够全量采集网络数据、实时刷新关键网络监控指标、精准告警，并对关键业务的网络行为进行监控、审计和回溯分析，提升业务系统的安全保障能力。