在mtr手册页中，内容如下：
mtr 将 traceroute 和 ping 程序的功能整合到一个网络诊断工具中
我使用了mtr很多，发现它比 快得多traceroute。直觉上，mtr立刻给我答案，而traceroute每秒列出每个 IP 地址。在我自己的电脑上，我使用了time mtr www.google.com和time traceroute www.google.com，结果是 21.9 秒 VS 6.1 秒。
问题是为什么？既然mtr = ping + traceroute，这是否意味着它更慢或至少与相同traceroute。
谁能给我一个合理而详细的答案？
答案1
并行性是这些工具速度差异的主要原因。另一个影响因素是它们等待回复的时间，然后才会认为该跳转没有响应。如果执行了反向 DNS，您也必须等待。如果禁用反向 DNS，普通的 traceroute 命令会变得更快。
另一个重要的区别（我没有看到提到）是这两个工具如何呈现输出。Traceroute 按自上而下的顺序生成输出。Mtr 以不同的方式呈现输出，其中 mtr 可以返回并更新前几行的输出。
这意味着 mtr 可以在输出可用时立即显示输出，因为如果稍后的回复导致该输出不准确，mtr 可以返回并更新它。由于 traceroute 无法返回并更新输出，因此它必须等到最终决定要显示什么。
例如，如果跳数 2 没有响应（这是我在多个 ISP 上看到的症状），traceroute 将显示跳数 1，然后等待一段时间，然后显示跳数 2 和 3。即使来自跳数 3 的回复已经到达，也不会显示，因为 traceroute 仍在等待来自跳数 2 的回复。Mtr 没有这个限制，可以显示来自跳数 3 的回复，如果来自跳数 2 的回复稍后到达，则仍返回显示来自跳数 2 的回复。
过多的并行性会导致输出不准确。在某些情况下，您可以获得回复的数据包数量是有限的。在这些情况下，发送更多数据包不会加快处理速度，但会导致更多数据包丢失，因为您发送的数据包越多，获得的回复数量就越高。
一个例子是路由上的某个跳点不回复 ARP 请求。通常第一个数据包会触发 ARP 请求，如果在 ARP 请求超时之前有更多数据包到达，则只有最后一个数据包会被缓冲并得到回复。
另一个区别是，在工具停止显示更多跳数之前，将显示多少个没有响应的跳数。我曾看到 traceroute 命令继续执行请求的跳数（默认为 30），而 mtr 命令在经过 5 个没有响应的跳数后就会停止。
答案2
traceroute 命令每跳发送 3 次探测，如果您将其限制为 1 次探测-q 1，则结果将变得可比
time mtr -r -c 1 google.com
.
.
.
real 0m2.640s
user 0m0.003s
sys 0m0.018s
time traceroute6 -q 1 google.com
.
.
.
real 0m0.445s
user 0m0.006s
sys 0m0.007s
我预计可比测试之间的主要差异与 DNS 查询时间和路径差异有关。您会注意到我的 traceroute 比 mtr 更快，但情况并非总是如此。
答案3
我认为这是由于路由跟踪的实施方式造成的。
traceroute按顺序为到目的地的路由中的每一跳发送至少 3 个数据包。
mtr首先发现路由中的跳数，然后并行将数据包发送到每个节点。
mtr在我看来，处理跳跃不响应 ping/探测的方式也有所不同；它会比traceroute似乎一直发送 3 个数据包的速度更快地忽略它，即使第一次尝试未能获得响应。
答案4
主要原因是 traceroute 的运行方式。它向第一台主机发送一个 UDP（或 Windows 上的 ICMP）数据包，TTL 为 1，当它收到超时回复（或超过内部超时）时，它会为下一台主机生成下一个数据包，TTL 为 2，依此类推（将每台主机的 TTL 加一）。因此 traceroute 的总时间包括按顺序发送和接收每台主机的数据包。
mtr 在确定数据包所走的路径后，会并行发送所有 ICMP ECHO 数据包。