重复 ACK 的语义
接收端每收到一个数据段都回确认。当它发现序列号出现缺口时，会把同一个确认号再发一次——这就是重复 ACK，本质是「我这里缺了一段，请补发」。对发送端来说，连续收到 3 个重复 ACK 就触发快速重传，不必等超时。因此重复 ACK 是丢包的早期信号，但也可能只是乱序造成的假信号。
基本信息
| 触发者 | 接收端（缺口/乱序时补发同一确认号） |
|---|---|
| 触发阈值 | 3 个重复 ACK 触发快速重传（RFC 5681） |
| 相关机制 | SACK 描述已收到的块，减少无谓重传 |
| 抓包表现 | 连续相同的 ack 号，Wireshark 标注 TCP Dup ACK |
| 系统级计数 | Linux 可用 netstat -s 或 nstat 查看重复 ACK 类计数，字段命名随内核版本略有差异 |
典型使用场景
- 判断吞吐下降是丢包还是接收端处理慢
- 确认快速重传机制是否生效（重复 ACK 后是否很快出现重传）
- 评估链路质量：重复 ACK 与重传同时激增通常指向链路丢包
- 区分乱序与丢包，避免给正常调度行为贴上故障标签
观察方式
观察方式
连续相同 ack 号的 ACK 报文 # 重复 ACK 的特征
tcp.analysis.duplicate_ack && tcp.analysis.fast_retransmission # 重复 ACK 后紧跟快重传
tcp.options.sack # 看缺口是否被 SACK 补齐
netstat -s | grep -i -E 'dup ack|dupacks' # 系统级计数（命名随内核版本）现象与结论
| 组合现象 | 结论 | 依据 |
|---|---|---|
| 重复 ACK 后有重传 | 真实丢包 | 接收端无法用现有数据补齐缺口 |
| 重复 ACK 后靠 SACK 补齐 | 多为乱序 | 数据已到，只是顺序错 |
| 重复 ACK 数量不足 3 | 影响有限 | 未达快速重传阈值 |
| 重复 ACK 与重传同步激增 | 链路丢包 | 结合链路误码与拥塞指标核查 |
重复 ACK 的条数不等于丢包数：每收到一个乱序包接收端就会补发一次确认，数量会被明显放大。
重复 ACK 由接收端发出，缺口出现在对端的上行方向，反向推断方向时要结合该侧抓包或会话表。
进阶要点
- 同一连接的重复 ACK 数量突然增多，往往说明链路质量在短时间内恶化
- 接收窗口同时变小又出现重复 ACK，说明接收端在丢包与读取慢两个方向上承压
- 把重复 ACK 与时间轴对齐，能看出问题是持续存在还是偶发
- 区分「观测到重复 ACK」与「确认发生丢包」，后者必须有重传证据
- 确认丢包后先查链路误码与中间设备队列，再考虑协议参数
抓包时开启完整长度保存，否则重传段可能被截断，重复 ACK 与重传无法配对分析。