mtr 与探测协议选择
mtr 把 ping 的持续探测与 traceroute 的逐跳还原合成一张表，默认用 ICMP。但很多设备对 ICMP 单独限速，测出来的丢包与抖动并不代表业务流量。mtr 支持切换探测协议：用 -T -P 指定 TCP 端口模拟真实业务，用 -u -P 走 UDP，等于换一条「命」去测同一条链路，结论差异往往就是答案。
什么时候必须换协议
当 ICMP 结果显示中间跳开始大量丢包、而末跳与业务端口完全正常时，第一反应应该是换 TCP 模式复测，而不是去报链路故障。反过来，如果 TCP 模式在某一跳之后出现与业务一致的丢包和抖动，那才是可以上报的证据。原则很简单：探测协议与业务协议越接近，结论越有代表性。
业务级探测
业务级探测
mtr -T -P 443 -r -c 100 -n 10.0.0.5 # TCP 443，模拟 HTTPS 流量
mtr -T -P 3306 -r -c 100 -n 10.0.0.6 # TCP 3306，模拟数据库访问
mtr -u -P 53 -r -c 100 -n 10.0.0.7 # UDP 探测，用于对照
mtr -s 1400 -r -c 50 -n 10.0.0.5 # 指定包大小，配合 MTU 排查
mtr -i 0.5 -r -c 200 -n 10.0.0.5 # 0.5 秒间隔长跑，观察稳定性
mtr -r -c 100 -n 10.0.0.5 | tee /tmp/mtr-before.txt # 留存基线便于前后对比字段逐列读法
| 字段 | 含义 | 正常与异常 |
|---|---|---|
| Loss% | 该跳探针丢失比例 | 中间跳偏高但末跳为 0 通常只是限速 |
| Snt | 已发送探针数 | 样本少于 100 时百分比噪声大 |
| Last | 最近一次往返时延 | 容易受瞬时波动影响，仅作参考 |
| Avg | 平均往返时延 | 与相邻跳对比可看出时延在何处抬升 |
| Best | 最小往返时延 | 接近物理下限，可用于估算链路距离 |
| Wrst | 最大往返时延 | 与 Best 差距过大说明存在排队或抖动 |
| StDev | 往返时延标准差 | 偏大即抖动明显，实时业务体感差 |
典型使用场景
- 用户反馈视频会议卡顿：用 TCP 模式长跑，看是丢包还是抖动主导
- 怀疑运营商集客线路质量：把 ICMP 与 TCP 两种模式的报告一起对比提交
- 云上跨地域调用变慢：逐跳看时延在哪一段抬升，判断是公网还是内网段
- 带宽验收：结合 iperf3 结果与 mtr 的丢包抖动，形成完整的链路画像
- 故障前后对比：同一命令、同一源点分别留存报告，量化恢复效果
mtr 的 TCP 模式需要目标端口有监听或至少网络可达；选真实业务端口（443、3306）结果最有代表性，选一个对端没开的端口会被防火墙直接拒绝，反而看不出链路质量。
用 TCP 模式探测负载均衡或集群地址时，多次探测可能落到不同后端，结果方差会明显放大；此时应针对单个真实节点探测。