超时重传在说什么
发送方发出数据后如果没有在重传超时时间内收到确认，就会重发同一段数据，间隔按指数退避放大。抓包上的表现是同一序列号的数据包在一段明显间隔后重现，而且前面没有成群的重复确认作铺垫。它与快速重传的区别在于触发条件：快速重传靠三个重复确认，超时重传靠计时器到期。超时重传说明情况更严重——连后续数据的确认都没有回来，通常意味着链路中断或对端处理停滞。
基本信息
| 识别特征 | 同序列号重现，间隔约等于重传超时并成倍放大 |
|---|---|
| 初始超时 | 根据往返时延估算，常见从一秒左右开始 |
| 与快速重传的区别 | 没有成群重复确认，靠计时器触发 |
| 观察工具 | 相对时间列看间隔，异常标注看具体类型 |
| 统计命令 | 用命令行工具按条件输出时间与序列号 |
典型使用场景
- 判断是否真的丢包：超时重传比快速重传更接近链路中断
- 评估恢复能力：看退避次数与最终是否成功
- 定位发送侧问题：在发送方抓包才能看到重传原包
- 区分上行与下行丢包：按源地址分组统计重传条数
- 核对网络改造效果：对比改造前后的超时重传次数
常用示例
常用示例
tshark -r a.pcap -Y 'tcp.analysis.retransmission' -T fields -e frame.time_relative -e ip.src -e ip.dst -e tcp.seq | head -20
tshark -r a.pcap -Y 'tcp.analysis.retransmission && ip.src == 10.0.0.9' | wc -l # 某主机发出的重传
tcpdump -i eth0 -nn -ttt 'host 10.0.0.9 and port 443' -c 40 # 相对时间看间隔
ss -ti | grep -A1 '10.0.0.20:443' # 查看套接字重传统计两类重传对比
| 对比项 | 超时重传 | 快速重传 |
|---|---|---|
| 触发条件 | 重传计时器到期 | 收到三个重复确认 |
| 前置迹象 | 无明显重复确认 | 先有成群重复确认 |
| 间隔特征 | 按指数退避成倍放大 | 几乎立即补发 |
| 含义 | 链路中断或对端停滞，程度较重 | 轻量丢包，恢复快 |
| 统计字段 | 重传标注 | 快速重传标注 |
发送侧抓包才能看到重传原包；在接收侧看到的是同一段数据两次到达。判断丢包发生在哪个方向，要先确认抓包位置，否则结论会相反。
公网与长链路上出现个别超时重传属于常态，评估健康度应看比例与趋势。只有比例明显升高或伴随业务超时，才值得进一步追查中间链路设备。
按秒统计趋势
按秒统计趋势
tshark -r a.pcap -q -z io,stat,1,'COUNT(tcp.analysis.retransmission)tcp.analysis.retransmission' | head -20
tshark -r a.pcap -Y 'tcp.analysis.retransmission' -T fields -e frame.time_relative -e tcp.stream | head -30 # 看是否集中在少数流判读要点
- 重传集中在少数几条流时，问题可能与那几个对端或路径有关
- 重传在时间上均匀分布，说明链路整体质量不稳定
- 重传伴随零窗口提示时，问题在对端处理速度而非链路
- 出现多次指数退避后连接被重置，通常是应用层超时先触发，需要看两侧超时配置