mtr是 traceroute 的连续进化版，它融合路径追踪与持续探测能力，每秒刷新各跳延迟和丢包率，提供 loss%、avg、wrst、stdev 等统计指标，可精准识别间歇性故障与链路抖动。
连续性监测网络链路质量，traceroute 本身并不适合长期、实时跟踪——它是一次性路径快照工具。真正承担“连续监测”任务的，是它的增强组合体：MTR（My Traceroute）。它把 traceroute 的路径追踪能力与 ping 的持续探测能力融合在一起，每秒自动刷新各跳节点的延迟和丢包率，是诊断链路稳定性最实用的手段。
为什么 traceroute 不适合连续监测？
traceroute 默认只执行一次完整路径探测，输出固定跳数的结果后即退出。它不统计丢包率，也不持续采样；若某跳偶发超时（显示为 *），单次结果无法判断是瞬时抖动还是持续故障。
MTR 是 traceroute 的连续进化版
MTR 启动后默认持续运行，对路径中每一跳同时发送探测包，并滚动更新以下关键指标：
- Loss%：该节点丢包率，>0% 即提示该环节存在转发异常或限速
- Rcv/Snt：收到/发出包数，用于验证探测是否稳定生效
- Last/Avg/Best/Wrst/StDev：最近一次、平均、最优、最差及标准差延迟，反映抖动程度
常用连续监测命令示例
Linux/macOS 下启动 MTR 监测（以 100 次探测、0.2 秒间隔为例）：
mtr -c 100 -i 0.2 example.com
若需生成文本报告用于存档分析：
mtr --report-cycles 50 -r example.com > mtr_report.txt
结合 traceroute 定位问题节点后的连续验证
当 traceroute 发现某跳首次出现 * 或延迟陡增（如从 15ms 跳到 280ms），可立即用 MTR 锁定该跳 IP，做定向观测：
mtr -z -w -C -i 0.5 203.208.60.1（-z 禁用 DNS 解析，-w 宽格式，-C CSV 输出）
此时重点关注该节点的 Loss% 是否持续高于 5%，以及 Wrst 延迟是否反复突破阈值——这往往指向中间运营商链路拥塞或设备过载。
