快速重传在说什么
接收端收到乱序数据时会重复确认已经收到的位置，发送端连续收到三个重复确认就立即重发缺口那一段，不必等待超时计时器。抓包上的表现是：先出现成群的重复确认，紧接着缺口序列号的数据被重发，之后窗口与确认号恢复正常。这是协议的健康机制，说明系统能在不等待超时的情况下快速恢复；但频繁出现也意味着链路在持续丢包，值得关注丢包率而不是单次事件。
基本信息
| 触发条件 | 连续收到三个重复确认 |
|---|---|
| 识别特征 | 重复确认成群出现，随后缺口数据补发 |
| 过滤字段 | 快速重传与重复确认两个异常标注 |
| 与超时重传区别 | 无需等待计时器，恢复快 |
| 关联机制 | 选择性确认能让恢复更精确 |
典型使用场景
- 评估链路质量：统计快速重传出现的频率
- 确认恢复机制是否生效：看补发后确认号是否快速推进
- 区分丢包类型：快速重传多说明偶发丢包，超时重传多说明中断
- 核对选择性确认效果：有该机制时补发范围更小
- 排查小窗口场景：窗口偏小时重复确认未必触发快速重传
常用示例
常用示例
tcp.analysis.fast_retransmission # 全部快速重传
tcp.analysis.duplicate_ack # 重复确认
tcp.stream == 5 && tcp.analysis.flags # 某条流内的全部异常
tcp.analysis.fast_retransmission && ip.src == 10.0.0.9 # 某主机发出的快速重传
tcp.analysis.duplicate_ack && tcp.stream == 5 # 某条流的重复确认重传类型对照
| 对比项 | 快速重传 | 超时重传 |
|---|---|---|
| 触发条件 | 三个重复确认 | 重传计时器到期 |
| 前置迹象 | 成群重复确认 | 无明显前置迹象 |
| 恢复速度 | 立即补发，快 | 等待超时，慢 |
| 严重程度 | 轻，单包丢失 | 重，可能链路中断 |
| 统计字段 | 快速重传标注 | 重传标注 |
重复确认数量不足三个时不会触发快速重传，例如只丢了末尾几个包，这种情况下只能等待超时，属于正常行为，不必强行寻找快速重传记录。
流量稀疏或窗口很小的时候，乱序容易被误判为丢包。判断是否真的丢包要结合确认号推进情况与后续补发行为，而不是只看某个标注。
结合确认号判读
结合确认号判读
tcp.analysis.duplicate_ack && tcp.stream == 5 # 先看重复确认的确认号
tcp.seq == <缺口序列号> # 确认缺口段是否被补发
tcp.analysis.fast_retransmission && frame.time_relative > 10 # 某时间点之后的快速重传判读要点
- 快速重传之后确认号迅速前移，说明恢复机制工作正常
- 同一流里频繁出现快速重传，问题集中在这条路径或这个对端
- 快速重传与超时重传同时增多，说明链路质量整体恶化而非偶发
- 统计时按方向拆分，才能判断丢包发生在上行还是下行