mtr是动态链路监测的核心工具，因其持续发送探测包、实时更新每跳丢包率（loss%）、平均/最大/最小延迟（avg/wrst/best）及抖动（stdev）等统计指标，能准确识别间歇性丢包、路由震荡和延迟波动；而traceroute仅一次性发送少量包（通常每跳3次），无统计功能、不记录历史、易受防火墙限速或临时拥塞干扰，输出为静态快照，无法反映链路真实质量。
单独用 traceroute 只能看一次路径快照，mtr 才是做动态链路监测的核心工具。traceroute 更适合快速定位“路径是否通”或“哪一跳断了”，而 mtr 能持续观测每一跳的丢包率、延迟波动和稳定性，真正反映链路的真实质量。
为什么 traceroute 不适合动态监测
traceroute 默认只发一组探测包（通常3个），每跳仅测1–3次往返时间，无法区分瞬时抖动和持续异常。它不统计丢包率，也不记录历史变化，输出结果是一次性静态信息。遇到防火墙限速、中间节点 ICMP 限流或临时拥塞时，容易误判为“***”（无响应），实际链路可能完全正常。
- Windows 的 tracert 用 ICMP Echo，易被企业防火墙拦截
- Linux traceroute 默认走 UDP 高端口（如33434），部分云厂商会默认丢弃
- 所有 traceroute 变体都不支持自动重试、趋势对比或阈值告警
mtr 是动态链路监测的实际执行者
mtr 启动后默认每秒发送一个探测包（可调），对路径上每一跳持续采样，实时更新 Loss%、Avg、Wrst、StDev 等指标。它不是“跑一遍就完”，而是像网络心电图一样持续跳动，特别适合发现间歇性丢包、路由震荡、MTU 不匹配或某段链路高延迟抖动等问题。
- 交互界面中按 r 键可刷新统计，按 s 键切换排序（如按丢包率升序）
- 用 mtr --report -c 50 example.com 生成含50次采样的静态报告，便于存档比对
- 加 -n 参数跳过 DNS 解析，避免本地解析慢干扰判断
- 目标屏蔽 ICMP？可用 --tcp -P 443 改走 HTTPS 端口探测
traceroute 和 mtr 协同使用的典型场景
两者不是替代关系，而是分工配合：先用 traceroute 快速确认路径结构和基础可达性，再用 mtr 在关键跳或疑似异常跳上做深度观测。
- 发现 traceroute 第5跳开始大量 *，立刻用 mtr -r -c 100 -n --show-ips example.com 检查该跳及后续节点的丢包趋势
- traceroute 显示路径突然绕行（比如从北京→上海→东京→旧金山），用 mtr 观察东京节点是否持续高延迟，判断是否 BGP 路由异常
- 业务突发卡顿，先 traceroute -n example.com 看路径有无变更，再开 mtr -i 0.2 -s 1200 example.com（缩短间隔、加大包长）复现 MTU 或带宽瓶颈
实用建议：让动态监测更有效
真实网络问题往往藏在波动里，而不是单次超时中。不要只盯着“最后一跳”，要关注整条链路上延迟突增或丢包集中出现的位置——那才是瓶颈所在。
- 连续运行 mtr 至少60秒以上，避开瞬时毛刺干扰
- 对比不同时间段（如早高峰 vs 凌晨）的 mtr 报告，识别周期性拥塞
- 若某跳 Loss% > 2% 且 Avg 延迟明显高于前后跳，优先排查该设备或其出口链路
- 结合 tracepath（无需 root、自带 MTU 发现）验证是否存在分片问题
