重复 ACK 是什么
接收端收到数据后都回一个 ACK。当它发现序列号出现缺口（丢包）或收到乱序包时，会重复发送同一个确认号，催促对端重发缺失的那一段。Wireshark 用 tcp.analysis.duplicate_ack 标注这类报文，并给出这是同一确认号的第几次重复。它是丢包的早期信号，也可能纯粹由乱序引起。
基本信息
| 适用工具 | Wireshark 3.x / 4.x |
|---|---|
| 字段 | tcp.analysis.duplicate_ack，计数子字段 .num |
| 触发阈值 | 收到 3 个重复 ACK 触发快速重传 |
| 查看位置 | 报文列表的 [TCP Dup ACK n#k] 标注 |
| 配套字段 | tcp.analysis.fast_retransmission、tcp.options.sack |
典型使用场景
- 快速定位丢包方向：谁在发重复 ACK，缺口就在谁的上行
- 区分丢包与乱序：看后续是否有重传跟随
- 评估快速重传是否生效：重复 ACK 后是否及时出现重传
- 检查网络设备的乱序处理是否合理
常用示例
常用示例
tcp.analysis.duplicate_ack # 全部重复 ACK
tcp.analysis.duplicate_ack.num >= 3 # 达到快速重传阈值的
ip.src == 10.0.0.9 && tcp.analysis.duplicate_ack
tcp.analysis.duplicate_ack && tcp.analysis.fast_retransmission # 重复 ACK 与快重传同现判读对照
| 组合现象 | 结论 | 说明 |
|---|---|---|
| 重复 ACK 后有重传 | 确实丢包 | 接收端无法靠已有数据补齐 |
| 重复 ACK 后靠 SACK 补齐 | 多为乱序 | 数据其实到了，只是顺序错 |
| 重复 ACK 数不足 3 | 影响有限 | TCP 不会触发快速重传 |
| 大量重复 ACK 且伴随重传激增 | 链路丢包严重 | 查链路质量与缓冲不足 |
收到一个乱序包就会补发一次确认，所以重复 ACK 数量大不等于丢弃了同样多的包。
无线接入与多路径调度会天然制造乱序，重复 ACK 与真实丢包要结合重传率一起判断。
进阶要点
- 按源地址统计重复 ACK 数量，能快速看出是普遍现象还是个别对端
- 重复 ACK 与实际重传成对出现才说明丢包，单独出现先怀疑乱序
- 把重复 ACK 与 SACK 块放在一起看，缺口逐步缩小说明恢复在推进
- 先确认链路误码与拥塞指标，再考虑调整恢复算法
- 结论写清统计口径：哪个地址、哪条流、多长时间窗
重复 ACK 的计数来自分析引擎的推断，重要结论要用 seq/ack 的实际取值复核一遍。