性能调优：三种情况下的重复ACK分析与处置建议

上一篇《》中我们分享了TCP异常流量标记“可能丢包”的几种常见场景及解决方案，这一篇我们一起来看TCP异常流量标记“重复ACK”的几种常见场景及解决方案。

ACK机制是TCP实现可靠性的重要组成部分，接收方通过ACK序列号通知发送方本端已经连续接收到了哪些字节。

图1

什么是“重复ACK”？

简单来说，符合以下几个条件的TCP ACK报文可被视为“重复ACK”，如图1所示：①TCP分段负载为0；②当前报文的TCP序列号等于上一个报文的TCP下一个序列号；③当前报文的TCP确认号等于上一个报文的TCP确认号；④当前报文的IP ID大于上一个报文的IP ID。稍显不严谨但通俗易懂的说法就是：与上一个纯ACK报文序列号一致并且确认序列号一致的纯ACK报文，但IPID更大。

图2

如图2所示，序号30的报文被标记为“重复ACK”。

在实践场景中，异常标记“重复ACK”常与“可能丢包”、“重传”、“乱序”等异常标记同时出现。同样的，我们也总结了以下几种常见情况及处置建议。

情况1

TCP分段丢失，触发重复ACK。

如图2所示，序号28的报文确认了序号26的报文，序号27的报文是服务器向客户端侧继续传输了一个报文分段，如果客户端正确收到了序号27的报文，则下一个ACK报文的确认序列号应为“Ack=3249073588”，但实际上序号30的ACK报文确认序列号同序号28的报文，并被标记为“重复ACK”。

这说明虽然流量捕获点处捕获到了服务器发向客户端侧的流量，但客户端并未收到，因此给出了重复的ACK报文。据此可判断出，从捕获点到客户端侧方向的链路存在丢包现象。

图2中序号29的报文被标记为“可能丢包”，据此可判断出，从服务器到捕获点方向的链路存在丢包现象。

图2所示的场景，说明从服务器到客户端方向的链路存在丢包情况，应及时排查链路质量。

情况2

TCP分段传输乱序，触发重复ACK。

图3

如图3所示，由于TCP报文传输乱序触发了“重复ACK”。

根因及处置建议

出现此种情况要综合判断，如果TCP传输乱序情况并不多，且不影响业务，则持续观察是否存在增长迹象即可，如果乱序情况严重，则建议按照上一篇TCP异常流量标记分析“可能丢包”中“情况1”的处置建议进行排查。

情况3

“虚假重传”异常标记触发重复ACK。

图4

如图4所示，这张TCP交易时序图中存在一些“虚假重传”的异常标记，每个“虚假重传”都触发一次“ACK”。注意观察，“重复ACK”的确认序列号ACK=1944823349，始终大于“虚假重传”报文的Next Seq。有关“虚假重传”标记我们另贴详细探讨。

根因及处置建议

通常情况下，出现“虚假重传”标记，是由于TCP ACK报文不及时或丢失造成。看到这样的TCP交易时序图，一般可考虑更换或升级浏览器访问服务器。

分析TCP交易时序图是运维人员和流量分析工程师的“日常”。了解科来网络分析系统TCP流分析视图中TCP交易时序图的TCP异常流量标记，能够做到在分析TCP流量时事半功倍，及时的定位故障层面，定位故障节点，定位故障根因。

↑↑↑长按图片识别二维码关註↑↑↑