4. 网络延迟基础：RTT、RTO 的概念与 Wireshark 查看方法
说到网络延迟，很多人第一反应就是「ping 一下」。但说实话，ping 只能告诉你一个大概的往返时间，真正要定位重传和性能瓶颈，你得搞懂两个核心指标：RTT 和 RTO。
我刚开始做网络排障那会儿，也分不清这两个东西。直到有一次线上业务超时，我盯着抓包文件看了半天，才发现是 RTO 计算出了问题。嗯，从那以后我就把这两个概念刻在脑子里了。
4.1 什么是 RTT？
RTT（Round-Trip Time），就是数据包从发送端到接收端，再返回确认所花的总时间。说白了，就是「你发一句，对方回一句，中间等了多久」。
在 TCP 里，RTT 是动态变化的。网络拥堵、链路抖动、服务器负载，都会影响它。Wireshark 会为每个 TCP 会话计算 RTT，而且分两种：
- 初始 RTT：三次握手阶段算出来的 RTT，通常比较准
- 采样 RTT：数据传输过程中，每个数据包和对应的 ACK 之间的时间差
关键点：RTT 是衡量网络「快不快」的直接指标。如果 RTT 突然飙升，大概率是链路出了问题。
4.2 什么是 RTO？
RTO（Retransmission Timeout），是发送端等待 ACK 的超时时间。如果超过这个时间还没收到确认，发送端就会认为数据丢了，触发重传。
RTO 不是拍脑袋定的，它是根据 RTT 算出来的。TCP 协议里有一套算法：
- 先测量 RTT 的平滑值（SRTT）
- 再计算 RTT 的偏差（RTTVAR）
- 最后 RTO = SRTT + 4 × RTTVAR
为什么是 4 倍？我个人的理解是：TCP 想留出足够的余量，避免因为网络抖动就误判丢包。但余量太大也不行，业务会等死。
注意：RTO 的最小值通常是 200ms（Linux 内核默认），最大值不超过 120 秒。如果你看到 RTO 频繁触发，说明网络状况已经很差了。
4.3 RTT 和 RTO 的关系
这两个指标是「父子关系」。RTT 是实测值，RTO 是计算值。RTT 越稳定，RTO 就越准；RTT 抖动越大，RTO 就越保守。
我曾经遇到过一个案例：某业务跨海链路，RTT 平时 150ms，但每隔几分钟会跳到 500ms。结果 RTO 被算法拉到了 2 秒以上，导致正常丢包也要等 2 秒才重传。这就是 RTT 抖动引发的连锁反应。
4.4 在 Wireshark 中查看 RTT
Wireshark 查看 RTT 有几种方式，我常用的有两个：
4.4.1 通过「统计」菜单查看
- 打开抓包文件，选中任意一个 TCP 数据包
- 点击菜单栏 统计 → TCP 流图形 → 往返时间（RTT）
- Wireshark 会弹出一个散点图，横轴是时间，纵轴是 RTT 值
这个图特别直观。如果 RTT 点都集中在一条水平线上，说明网络稳定。如果点散得到处都是，那就要小心了。
4.4.2 直接在数据包详情里看
选中一个 TCP 数据包，展开 Transmission Control Protocol 部分，找到 Timestamps 或 SEQ/ACK 分析。Wireshark 会显示：
- Time since first frame in this TCP stream：相对时间
- RTT：当前数据包与对应 ACK 之间的时间差
小技巧：在 Wireshark 的列显示里添加「RTT」列，可以一眼看到每个数据包的 RTT。右键点击列头 → 列首选项 → 添加「tcp.analysis.ack_rtt」。
4.5 在 Wireshark 中查看 RTO
RTO 不像 RTT 那样直接显示在数据包上，但 Wireshark 会通过分析告诉你「这个包是不是超时重传」。
4.5.1 通过过滤表达式
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.spurious_retransmission这三个过滤条件分别对应：
| 过滤表达式 | 含义 | 触发条件 |
|---|---|---|
tcp.analysis.retransmission |
超时重传 | 超过 RTO 未收到 ACK |
tcp.analysis.fast_retransmission |
快速重传 | 收到 3 个重复 ACK |
tcp.analysis.spurious_retransmission |
虚假重传 | 重传后收到原始 ACK |
4.5.2 查看 RTO 计算值
Wireshark 不会直接显示 RTO 数值，但你可以通过 SEQ/ACK 分析 间接推断：
- 找到重传的数据包
- 看它和原始数据包的时间差
- 这个时间差 ≈ 当时的 RTO 值
举个例子：原始包在 0.5 秒发送，重传包在 1.2 秒发送，时间差 0.7 秒。那当时的 RTO 大概就是 700ms 左右。
避坑指南：我曾经遇到过一种情况，RTT 只有 10ms，但 RTO 被算到了 1 秒。原因是 TCP 的 RTO 计算有「退避」机制——连续重传时，RTO 会翻倍。第一次 1 秒，第二次 2 秒，第三次 4 秒……这就是所谓的「指数退避」。
4.6 实战：从 RTT 和 RTO 判断网络问题
光知道概念没用，得会用。我总结了几种常见场景：
| 现象 | RTT | RTO | 可能原因 |
|---|---|---|---|
| RTT 稳定但偏高 | 100-300ms | 正常 | 物理距离远（跨海、跨国） |
| RTT 突然飙升 | 从 20ms 跳到 500ms | 随之增大 | 链路拥堵或路由变化 |
| RTT 正常但频繁重传 | 10-20ms | 偏大 | 中间设备丢包（交换机、防火墙） |
| RTT 抖动剧烈 | 10ms ~ 1000ms 波动 | 被拉大 | 无线网络、卫星链路 |
你想想看，如果 RTT 只有 10ms，但 RTO 是 1 秒，那中间肯定有问题。要么是 TCP 参数配置不合理，要么是网络存在间歇性丢包。
核心思路：RTT 看「快不快」，RTO 看「等多久」。两者结合，才能判断网络到底「好不好」。
4.7 本章小结
RTT 和 RTO 是 TCP 性能分析的基石。RTT 是实测的往返时间，RTO 是计算的重传超时。Wireshark 里看 RTT 很方便，看 RTO 需要结合重传包的时间差来推断。
我个人习惯是：先看 RTT 散点图，判断网络稳定性；再看重传类型，判断是超时还是快速重传；最后结合时间差，反推 RTO 是否合理。这套流程走下来，大部分延迟问题都能找到根因。