在mtr手册页中，它显示：
mtr将traceroute和ping程序的function结合在一个networking诊断工具中
我使用mtr很多，发现它比traceroute快得多。 本能地， mtr给了我emidiately的答案，而traceroute列出每个ip地址每秒。 在我自己的电脑上，我用了time mtr www.google.com和time traceroute www.google.com ，结果是21.9s VS 6.1s。
问题是为什么？ 由于mtr = ping + traceroute ，这并不意味着它慢或至less跟traceroute相同。
任何人都可以给我一个合理和详细的答案？
并行性是这些工具速度变化的主要原因。 另一个促成因素是在跳转被认为没有响应之前等待回复多久。 如果执行反向DNS，您也必须等待。 如果禁用反向DNS，则简单traceroute命令会更快。
另一个我没有看到提到的重要区别是两个工具如何呈现输出。 Traceroute按照从上到下的顺序生成输出。 Mtr以不同的方式呈现输出，其中mtr可以返回并更新前一行的输出。
这意味着mtr可以立即显示输出，因为如果以后的回复导致输出不准确，mtr可以返回并更新它。 由于traceroute无法返回并更新输出，因此必须等到它最终确定显示的内容。
例如，如果跳数2没有响应（这是我在多个ISP上看到的症状），traceroute将显示跳数1，然后等待一段时间，然后显示跳数2和3.即使从跳数3已经到达，因为traceroute仍然在等待来自第二跳的回复，所以Mtr没有被显示.Mtr不具有该限制并且可以显示来自第3跳的回复，并且仍然返回显示来自第2跳的回复，如果它迟到了。
太多的并行性会导致输出变得不准确。 在某些情况下，您可以获得多less数据包有限制。 在这些情况下发送更多的数据包不会加速这个过程，但是会导致更多的丢失数据包，因为您得到的发送数据包数量相同。
其中一个例子是当路由上的一个跳转没有回复ARP请求时。 通常情况下，第一个数据包会触发ARP请求，如果有更多的数据包在ARP请求超时之前到达，那么只有最后一个数据包将被caching并得到答复。
另一个区别是在工具停止显示更多跳数之前，没有响应的跳数会显示出来。 我已经看到traceroute命令会继续执行尽可能多的跳转（默认为30），而mtr命令只要跳过五跳而没有响应就会停止。
如果您将traceroute命令限制为1个探测器，则每次都会发送3个探测器，然后结果相当
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
我希望可比较的testing之间的主要区别与DNS查询时间和path差异有关。 你会注意到我的traceroute比mtr更快，但事实并非总是如此。
我想这是来自路线追踪的实施方式。 traceroute按顺序发送至目的地的路由中的每跳至less3个数据包。
mtr发现路由中的跳数，然后将数据包并行发送到每个节点。
在我看来， mtr处理hop不响应ping /探测器的方式也有所不同; 它忽略了比traceroute更快的速度，即使第一次尝试没有得到响应，似乎总是发送它的3个数据包。
主要原因是traceroute运行的方式。 它向第一个主机发送TTL为1的UDP（或ICMP）数据包，当它接收到超时应答（或者它传递了一个内部超时）时，它为下一个主机产生下一个数据包，使用TTL两个等等（每个主机添加一个TTL）。 因此，traceroute的总时间包括为每个主机发送和接收数据包，依次。
mtr，在确定了数据包的path之后，并行发送所有的ICMP ECHO数据包。