RTO 退避的形态
TCP 超时重传的间隔按指数退避增长：第一次约等于一个 RTO，其后约两倍、四倍、八倍。抓包时间线上看到这种倍增间隔，基本可以判定对端在持续丢包；如果间隔固定不变，更像是应用层的定时重试而不是 TCP 超时。这个形态差异是区分两层重试最实用的判据。
基本信息
| 关键字段 | tcp.analysis.retransmission、tcp.time_delta、tcp.seq |
|---|---|
| 退避规律 | 间隔约按 1、2、4、8 倍递增 |
| RTO 下限 | Linux 默认最小 RTO 约 200 毫秒，受系统参数约束 |
| 对照机制 | 快速重传由重复确认触发，间隔接近 RTT |
典型使用场景
- 区分链路持续丢包与应用层定时重试
- 判断接口闪断：一段超时重传之后突然恢复
- 估算一次中断造成的业务停顿时长
- 对比不同系统参数下的故障恢复节奏
- 佐证高延迟链路（无线、卫星）上的超时行为
观察退避间隔
观察退避间隔
tshark -r a.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.number -e tcp.stream -e tcp.seq -e frame.time_relative
# 同一流、同一序列号连续出现的帧，间隔按倍数增长即为 RTO 退避
tshark -r a.pcap -Y "tcp.analysis.retransmission && tcp.time_delta>0.2" -T fields -e frame.time_relative -e tcp.stream
# 间隔超过 RTO 下限的帧更值得关注，往往对应实质性持续丢包间隔形态对照
| 间隔形态 | 判读 | 下一步动作 |
|---|---|---|
| 约 1、2、4 倍递增 | TCP 超时退避，存在持续丢包 | 查丢包位置与链路质量 |
| 间隔基本固定 | 更像应用层定时重试 | 核对应用重试配置 |
| 单次重传后立即恢复 | 偶发丢包 | 看是否与特定时段相关 |
| 长时间静默后重传 | 对端长时间无响应 | 检查接口闪断与设备重启 |
| 间隔接近 RTT | 多为快速重传而非超时 | 看是否有重复确认 |
RTO 有下限，Linux 默认最小 RTO 约 200 毫秒，所以小 RTT 链路上的重传间隔也不会无限小。看到间隔短且规律的重传，要先排除是重复确认触发的快速重传，而不是超时重传。
无线链路的链路层重传会与 TCP 重传叠加，时间线形态变复杂。判断 TCP 层问题前先确认空口是否稳定，否则容易把无线抖动写成端到端 TCP 故障。
排查顺序
- 先按 TCP 流分组，确认退避发生在哪条连接与哪个方向
- 算出每次重传的时间间隔，确认是否成倍增关系
- 定位丢包位置：在两端同时抓包，比较数据在何处开始缺失
- 核对系统层面的 RTO 相关参数是否被调整过
- 把恢复耗时换算成业务影响，例如一次交易超时或一次重连