出现虚假重复ACK但无丢包的TCP连接问题求助

观测现象 #

在一条TCP连接中捕获到如下行为：

• 客户端连续发送14个入站数据报文（1-14号），报文序列连续无丢失。
• 服务器先发送1个带数据的出站报文（15号），随后发送14个ACK报文（16-29号）。
• 异常点：前9个ACK（16-24号）为虚假重复ACK，ack_num始终为2259960578未递增；从25号报文开始，ack_num开始递增，到29号报文时直接确认全部14个入站报文。

报文详情 #

异常成因分析 #

结合Red Hat 7.5（内核版本3.10.0-862.el7）的TCP栈特性，该异常由以下机制共同导致：

1. TCP延迟确认与未消费接收缓冲区的冲突 #

RHEL7.5默认启用TCP延迟确认机制，规则为：

• 等待最多200ms（tcp_delack_max默认值）或累积2个未确认报文后发送ACK；
• 若主动发送数据报文，会携带当前的确认号。

在本场景中，服务器发送第15号带数据报文时，应用层尚未读取接收缓冲区中客户端发送的14个报文，因此TCP栈只能携带初始确认号（2259960578，即第一个入站报文的起始序列号）。后续的9个重复ACK是栈在延迟确认超时周期内，为维持连接活性发送的虚假ACK——由于接收缓冲区数据未被消费，栈无法更新确认号，只能重复发送当前值。

2. 应用层批量读取触发累积ACK #

当应用层最终一次性读取了所有14个入站报文的数据后，TCP栈立即更新确认状态：

• 先发送4个递增的ACK（25-28号），逐步确认部分报文；
• 最后发送一个累积ACK（29号），直接确认全部14个报文的完整数据（ack_num = 2259974268 + 257 = 2259974525，对应第14号报文的序列号+ payload长度）。这种累积ACK是内核优化的一部分，用于减少ACK报文数量，提升传输效率。

3. RHEL7.5内核的特定行为 #

3.10版本内核针对“主动发送数据但接收缓冲区未被消费”的场景，调整了延迟确认的定时器逻辑：栈会周期性发送重复ACK，直到应用层读取数据触发确认号更新。这不同于常规延迟确认逻辑（累积报文后发送ACK），是导致虚假重复ACK出现的核心原因。

内容的提问来源于stack exchange，提问作者Mark