mtr 与 traceroute

Traceroute 和 mtr 都是诊断网络路径问题的命令行工具。mtr 做的是同样的事情，但它会持续探测，并随着时间的推移积累有关数据包丢失、延迟和抖动的统计数据。本文章将介绍每种工具的工作原理、如何读取输出以及何时使用。

traceroute 的工作原理

Traceroute 使用 IP 包头中的 "生存时间"（TTL）字段。它发送一个 TTL 设置为 1 的数据包，第一个路由器将 TTL 递减为 0，丢弃数据包，并发回一个 ICMP "超时 "信息。Traceroute 会记录路由器的 IP 地址和往返时间，然后发送另一个 TTL 设置为 2 的数据包，以此类推，直到数据包到达目的地或达到最大跳数限制（默认为 30，可用-m 调整）。

默认情况下，traceroute 会在每一跳发送三个探针，从而获得三个延迟读数。操作系统不同，协议也不同：

• Windows tracert命令发送 ICMP 回波请求。
• Linux/macOS： traceroute命令发送 UDP 数据报（端口 33434-33534）。如果 UDP 被阻止，则对 ICMP 使用-I或对 TCP 使用-T。

添加-n标志可跳过 DNS 反向查找，在多跳路径上可明显加快速度。

mtr 如何工作

mtr （My Traceroute）使用与 traceroute 相同的基于 TTL 的路径发现功能，但它会不断发送探测，通常每秒一次。您得到的不是每跳三个数据点，而是运行统计数据：丢包百分比、平均延迟、最佳和最差响应时间以及标准偏差（抖动）。

mtr 支持 ICMP（默认）、UDP 和 TCP SYN 探测。当防火墙阻止 ICMP 或要测试特定应用端口时，TCP 模式非常有用：

mtr --tcp --port 443 example.com

如果您想与支持团队共享非交互式报告，请使用报告模式：

mtr --report --report-cycles 100 example.com

运行 100 次探测并打印摘要。还可以使用--psize设置自定义数据包大小，以测试 MTU 或碎片问题。

mtr 可在 Linux 和 macOS 上运行。Windows 用户可以使用WinMTR以获得类似的图形用户界面。

主要区别

实际区别在于间歇性问题。mtr 可以捕捉到这些问题，因为它一直在测量。

阅读输出

在阅读 traceroute 或 mtr 输出时，最常见的错误是假定一个看起来有问题的中间跳意味着存在真正的问题。通常不是这样的。

traceroute 中的星号 (*)表示路由器没有响应探测。许多路由器被配置为忽略或限制 ICMP 的速率。如果之后的跳数响应正常，说明路径没有问题。

以 mtr 为单位的单跳数据包丢失遵循同样的逻辑。如果第 5 跳显示 20% 的丢包率，但最终目的地显示 0%，那么路由器只是在降低探测响应的优先级。真正的数据包丢失显示为一种模式：丢失出现在某一跳，并在随后到达目的地的每一跳中持续存在。

各跳之间的延迟跳变是正常的，也是预料之中的。从 10 毫秒到 80 毫秒的跳变通常意味着数据包跨越了海洋或漫长的陆地路线。只有当延迟在距离上异常高（都会区内低于 5 毫秒，跨国传输为几十毫秒，跨洋传输为 80-150 毫秒）或最终目的地延迟不可接受时，才会担心延迟问题。

以 mtr 为单位的 StDev（抖动）值得注意。任何一跳超过 10 毫秒的值都会给网络电话、视频通话和游戏带来问题。如果发现高抖动，请至少运行 100 个周期，以确认这是一种持续模式，而不是短暂的峰值。

何时使用每种工具

在需要快速得到答案时使用 traceroute：是否可以到达目的地，如果不能，路径在哪里中断？这是处理故障和验证基本路由的正确起点。

当问题是间歇性的或与性能有关时，使用 mtr。报告偶尔断线、VoIP 质量问题或延迟峰值的用户需要 mtr 的连续数据。至少运行 50-100 个周期，以获得可靠的统计数据。

为进行彻底诊断，请双向运行 mtr：从您的机器到服务器，再从服务器回到您的 IP。互联网路由是不对称的，因此返回路径可能具有完全不同的特性。如果只测试一个方向，可能会忽略问题的实际所在。

如果您的专用服务器或 VPS 出现问题，FDC 服务器支持团队接受 mtr 报告作为网络升级的标准诊断证据。