重传怎么判读
重传是丢包或超时最直接的证据：发送方在一段时间内没等到确认，就把同一份数据再发一次。抓包工具会根据序号与确认号的关系自动标出这类报文，并区分超时重传、快速重传与多余重传。判读的关键不是数出多少条，而是看「谁在重传」与「重传前的间隔有多长」：不同方向的重传指向不同的链路，间隔长短则能区分超时机制与重复确认触发的机制。
基本信息
| 标记来源 | 抓包工具根据序号与确认号推算出的分析结论，不是协议字段 |
|---|---|
| 常见类型 | 超时重传、快速重传、多余重传，另有乱序（不属于重传） |
| 观察重点 | 重传方向、重传前的间隔、后续是否被正常确认 |
| 常见误判 | 本机抓包时网卡的分段与聚合卸载会制造出并不存在的重传 |
| 验证方式 | 看两端抓包结果，或先关闭卸载功能再复测 |
典型使用场景
- 量化丢包：统计重传数量与比例，为链路质量提供硬指标
- 判断方向：确认本端发出方向的丢包，还是对端方向的丢包
- 排除误判：关闭分段与聚合卸载后复测，区分真丢包与假重传
- 评估业务影响：重传比例高时吞吐通常明显下降，用来解释性能问题
- 向线路管理方举证：整理重传的帧号与时间点，作为可核查的证据
定位重传
定位重传
tcp.analysis.retransmission # 全部重传
tcp.analysis.fast_retransmission # 快速重传
tcp.analysis.spurious_retransmission # 多余重传，多为卸载造成
tcp.analysis.retransmission && ip.src == 10.0.0.5 # 只看某个方向的重传
tcp.analysis.retransmission && tcp.stream eq 12 # 只看某条会话
tcp.analysis.lost_segment # 工具推断的丢包前兆
tcp.analysis.duplicate_ack # 重复确认，丢包的先行指标标记类型与指向
| 标记类型 | 含义 | 排查指向 |
|---|---|---|
| 超时重传 | 等待确认超时后重发同一份数据 | 本段链路丢包或对端响应慢 |
| 快速重传 | 收到多个重复确认后立即重发 | 单个报文丢失但后续报文已到达，属典型轻度丢包 |
| 多余重传 | 原报文其实已被确认，重发属于冗余 | 多为本机卸载功能或抓包点问题，不是真丢包 |
| 乱序 | 到达顺序与发送顺序不同 | 路径存在多链路负载分担，不一定是故障 |
| 重复确认 | 反复确认同一个序号 | 丢包的前兆，配合后续重传一起看 |
方向与间隔判读
| 现象 | 含义 | 下一步 |
|---|---|---|
| 本机发出的方向重传多 | 上行链路或本机侧存在问题 | 查本机出口链路的接口计数与质量 |
| 对端发出的方向重传多 | 下行链路或对端出口存在问题 | 结合对端数据与线路质量核对 |
| 间隔接近超时时间 | 超时机制触发，链路丢包偏严重 | 按丢包处理，定位发生在哪一段 |
| 间隔极短且伴随重复确认 | 快速重传，属轻度丢包 | 结合业务影响决定是否上报 |
重传前的时间间隔是最有价值的线索：间隔与超时时间相仿说明是超时重传，间隔极短说明是被重复确认触发的快速重传。两者对业务的破坏程度不同，处置优先级也不同。
在本机抓包时，网卡的分段与聚合卸载会改变报文在抓包点的形态，从而制造出并不存在的重传。看到大量「多余重传」时先关闭卸载再复测，否则很容易把一个抓包假象当成链路故障上报。