为什么mtr比traceroute快得多？

在mtr手册页中，其内容为：

mtr在单个网络诊断工具中结合了traceroute和ping程序的功能

我用mtr了很多东西，发现它的速度比快得多traceroute。本能地，mtr温柔地给我答案，同时每秒钟traceroute列出每个IP地址。在我自己的计算机上，我使用time mtr www.google.com和time traceroute www.google.com，结果是21.9s VS 6.1s。

问题是为什么？因为mtr = ping + traceroute，这并不意味着它会变慢或至少与相同traceroute。

谁能给我一个合理而详尽的答案？

并行是这些工具速度变化的主要原因。另一个促成因素是，在跳被认为没有响应之前，他们等待答复的时间。如果执行反向DNS，则还必须等待。如果禁用反向DNS，则平原traceroute命令变得更快。

我没有看到的另一个重要区别是这两个工具如何呈现输出。Traceroute按自上而下的顺序生成输出。Mtr以不同的方式呈现输出，其中mtr可以返回并更新前一行的输出。

这意味着mtr可以立即显示输出，因为如果以后的答复导致输出不准确，则mtr可以返回并更新它。由于traceroute无法返回并更新输出，因此必须等待直到最终决定将显示什么。

例如，如果跳数2没有响应（这是我在多个ISP上看到的症状），traceroute将显示跳数1，然后等待一会儿才显示跳数2和3。 3到了，它没有显示，因为traceroute仍在等待来自跃点2的答复。Mtr没有此限制，可以显示来自跃点3的答复，并且仍然返回以显示来自跃点2的答复。它到达以后。

太多的并行性可能导致输出不准确。在某些情况下，可以答复多少个数据包是有限制的。在这种情况下，发送更多的数据包不会加快处理速度，但是会导致丢失更多的数据包，因为您得到的回复数与发送的更多数据包相同。

这样的一个例子是当路由上的一跳不回复ARP请求时。通常，第一个数据包将触发ARP请求，如果在ARP请求超时之前有更多数据包到达，则仅这些数据包中的最后一个将被缓冲并得到答复。

另一个区别是在工具停止显示更多跃点之前，将显示无响应的跃点数。我已经看到traceroute命令继续按照请求的跳数（默认为30），而mtr命令将在经过五跳而没有响应时立即停止。

如果将其限制为1个探针，-q 1则traceroute命令每跳发送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

我希望可比测试之间的主要差异与DNS查询时间和路径差异有关。您会注意到，我的traceroute比mtr更快，但并非总是如此。

我想这来自路由跟踪的实现方式。 traceroute依次发送到目的地的路由中的每个跃点至少3个数据包。

mtr 首先发现路由中的跃点，然后将数据包并行发送到每个节点。

在我看来，mtr处理跳数不响应ping / probe 的方式也有所不同。traceroute即使第一次尝试未能获得响应，它也比忽略似乎总是发送其3个数据包的速度更快。

主要原因是traceroute的运行方式。它向第一台主机发送TTL为1的UDP（或Windows上的ICMP）数据包，并在收到超时答复（或通过内部超时）后，为具有TTL的下一台主机生成下一个数据包。 2个，依此类推（以此类推（将每个主机的TTL加1）。因此，traceroute的总时间包括依次发送和接收每个主机的数据包。

mtr在确定数据包采用的路径后，并行发送所有ICMP ECHO数据包。