虚假重传是怎么产生的
虚假重传指的是重传了其实并没有丢失的数据。当 RTO 估计过小，或者链路延迟抖动很大时，发送方等不到确认就先重传，而原始数据只是晚到。抓包上的特征是重复的数据段之前没有缺口，原数据随后也被确认。它通常不造成业务故障，但会明显污染丢包率统计。
基本信息
| 关键字段 | tcp.analysis.retransmission、tcp.analysis.duplicate_ack、tcp.seq |
|---|---|
| 判定特征 | 重复段之前没有缺口，原包最终到达并被确认 |
| 相关机制 | Eifel 检测（RFC 3522）、F-RTO 等回退机制 |
| 高发场景 | 无线、跨洋、卫星等高抖动链路 |
典型使用场景
- 修正丢包率统计：剔除虚假重传再算真实丢包
- 解释「重传很多但业务完全正常」的现象
- 为高抖动链路的超时参数调优提供依据
- 对比不同内核或实现版本的重传行为差异
- 让质量评估报告的数字更经得起复核
识别与过滤
识别与过滤
tshark -r a.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.number -e tcp.stream -e tcp.seq -e frame.time_relative
# 逐个重传帧往回看：前一个序列号是否连续，有没有空洞
tshark -r a.pcap -Y "tcp.analysis.spurious_retransmission" -T fields -e frame.number
# 新版 Wireshark 会直接标注虚假重传；没有该字段的版本按序列号人工判断
tshark -r a.pcap -Y "tcp.analysis.duplicate_ack" -T fields -e frame.number -e tcp.seq
# 结合重复确认判断是快速重传还是超时重传真丢包与虚假重传对照
| 特征 | 真丢包重传 | 虚假重传 |
|---|---|---|
| 重传前是否存在缺口 | 存在 | 不存在 |
| 原数据是否最终到达 | 可能不到 | 会到达并被确认 |
| 是否触发窗口收缩 | 会，并按恢复机制调整 | 往往已收缩，检测机制可回退 |
| 对业务的影响 | 明显，需等恢复 | 通常很小 |
| 统计口径 | 计入丢包 | 应从丢包率中剔除 |
高抖动链路上虚假重传比例会上升。给这类链路做质量评估时，先剔除虚假重传再算丢包率，否则会把链路问题描述得比实际严重得多，可能误导扩容决策。
判断虚假重传必须同时看确认时序，只看重复包容易被误导。抓包点如果自身丢帧，也会造成「看着像有空洞」的假象，因此至少两端同时采集再下结论。
判断方法
- 先确认重复帧对应的序列号区间在之前是否已经出现过
- 检查同一序列号的原帧与其确认帧，确认原数据是否被成功接收
- 统计重复帧在总包数中的占比，量化对丢包率的影响
- 区分触发动因：重复确认导致还是超时导致
- 报告里分开列原始重传率与剔除虚假重传后的丢包率