RTT 是怎么测出来的
RTT（往返时延）指一次「发出数据到收到对应确认」的耗时。抓包里有两种取法：握手阶段直接读 SYN 与 SYN-ACK 的时间差，最省事；传输阶段用 Wireshark 标注的 tcp.analysis.ack_rtt 批量取样。单点数值意义有限，样本的中位数与上限分布才能反映链路质量与队列状态。
基本信息
| 适用工具 | Wireshark / tshark；用 tcpdump 需按时间戳自行计算 |
|---|---|
| 核心字段 | tcp.analysis.ack_rtt，单位秒 |
| 快速估算 | SYN 与 SYN-ACK 的时间差 |
| 采样注意 | 样本越密越接近真实值，纯 ACK 受延迟确认污染 |
| 统计手段 | tshark -z io,stat 的 AVG/MAX 聚合或 Time Sequence 的 RTT 图 |
典型使用场景
- 判断用户侧延迟投诉是否由链路时延造成
- 对比同业务在不同机房的 RTT 与 SLA 承诺
- 区分「时延大」与「丢包多」：两者对业务的伤害方式不同
- 监控长连接业务的时延是否随时间劣化
统计示例
统计示例
tcp.analysis.ack_rtt > 0.1 # 快速筛出高时延确认
tshark -r a.pcap -Y 'tcp.analysis.ack_rtt > 0.1' -T fields -e ip.dst -e tcp.analysis.ack_rtt | head
tshark -r a.pcap -q -z io,stat,0,"AVG(tcp.analysis.ack_rtt)tcp.analysis.ack_rtt" # 平均 RTT
tshark -r a.pcap -q -z io,stat,0,"MAX(tcp.analysis.ack_rtt)tcp.analysis.ack_rtt" # 峰值 RTT现象与结论
| 现象 | 含义 | 下一步 |
|---|---|---|
| RTT 稳定且小 | 链路健康 | 把注意力转向应用处理耗时 |
| RTT 锯齿上升后骤降 | 队列堆积后被丢包释放 | 检查是否伴随重传与窗口收缩 |
| RTT 持续高但无丢包 | 路径本身就是长时延 | 核对物理距离、专线或 SLA |
| ACK 间隔固定为 0.04 或 0.2 秒 | 延迟确认在起作用 | 改用数据段样本，不要用纯 ACK 样本 |
延迟确认会让纯 ACK 样本偏大，判断时优先取「携带数据的段 → 其确认」这类样本。
抓包点的 RTT 只代表该点到对端的一段路径，端到端时延需要两端抓包相减或应用层埋点佐证。
进阶要点
- 先取握手 RTT 作为路径基线，再看数据阶段样本，两者接近说明网络本身稳定
- 把样本按会话分组比较，能区分「只有个别对端慢」与「整条链路都慢」
- 高 RTT 链路要同时看窗口大小，窗口不足时吞吐会被时延直接限制
- 测时延变化趋势时固定过滤条件与时间窗，避免样本口径漂移
- 把结论与 ping、MTR 等工具的结果对照，交叉验证更有说服力
Linux 侧可用 ss -ti 查看内核记录的 rtt 与 rttvar，与抓包得到的结论互相印证。