如何用MTR诊断网络问题
MTR 是一个强大的网络诊断工具，管理员能够用它诊断和隔离网络错误，并向上游提供商提供有关网络状态的有用报告。MTR 通过更大的采样来跟踪路由，就像 traceroute + ping 命令的组合。本文详细介绍了 MTR，其产生的数据，以及如何根据其提供的数据正确解释和得出结论。
背景
网络诊断工具包括 ping，traceroute 和 mtr，使用“ICMP”数据包来测试互联网上两点之间的节点和流量。当用户在互联网上 ping 主机时，会向主机发送一系列 ICMP 报文，主机通过发送报文进行响应。用户的客户端能够计算互联网上两点之间的往返时间。
相比之下，诸如 traceroute 和 MTR 之类的工具会以递增增加的 TTL 发送 ICMP 数据包，以便查看数据包在源和目的地之间进行的路由或一系列跳数。 TTL 或生存时间控制数据包在“死亡”并返回主机之前将产生多少“跳”。通过发送一系列数据包，使它们在一跳之后死亡并返回，然后两个，然后三个，客户端机器能够组合在因特网上的主机之间的流量所占用的路由。
MTR 收集关于中间主机的状态，连接和响应性的其他信息，而不是简单地概述流量跨越 Internet 的路由。由于这些附加信息，建议您尽可能使用 MTR 提供 Internet 上两台主机之间的连接的最完整的概述。以下部分概述如何安装 MTR 软件以及如何解释此工具提供的结果。
安装 MTR
在 CentOS 和 Fedora 系统中，使用如下命令更新系统，并安装 MTR：
yum update yum install mtr
生成 MTR 报告
因为 MTR 提供了从一个主机到另一个主机的路由流量的映像，您可以将其视为定向工具。此外，在因特网上两点之间采取的路由可能会根据位置和位于您上游的路由器而有很大变化。因此，通常建议您在遇到连接问题的所有主机或尽可能多的主机时双向收集 MTR 报告。
为了清楚起见，当引用 MTR 报告时，本文件将运行 mtr 作为源主机的主机和查询所针对的主机作为目标主机。
基于类Unix的系统上使用MTR
mtr -rw [destination_host]
例如，要测试到目标主机 example.com 的流量的路由和连接质量，请从所需的源主机运行以下命令：
mtr -rw example.com
如果没有丢包丢失，可以使用更快的间隔时间运行：
mtr -rwc 50 -i 0.2 example.com
我们上面使用的标志（rwc [x] -i [y]）在很有用。
-
r 选项标志生成报告（缩写为–report）
-
w 选项标志使用长版本的主机名，您可以看到每个跳的完整主机名（–report-wide的缩写）
-
c 选项标志设置报告中发送和记录的数据包数量。当不使用时，默认值通常为 10，但是对于更快的间隔，您可能希望将其设置为 50 或 100.报告可能需要较长时间才能完成
-
i 选项标志以更快的速率运行报告，以显示只能在网络拥塞期间发生的数据包丢失。该标志指示 MTR 每n秒发送一个数据包。默认值为1秒，因此将其设置为十分之一秒（0.1，0.2等）通常是有帮助的
刚才我们了解了什么是 MTR，以及如何生成一份报告等知识。这里，我们深入分析一下 MTR 报告的含义，以及常见的 MTR 结果分析。
分析 MTR 报告
验证数据包丢失
在分析 MTR 输出时，您正在寻找两件事情：丢包和延迟。首先让我们来谈谈丢包。如果您在任何特定跳点看到一定百分比的丢失，这可能表明该特定路由器存在问题。然而，一些服务提供商通常的做法是限制 MTR 使用的ICMP流量。这实际上没有损失可以给出丢包的错觉。要确定您看到的损失是真实的还是由于速率限制，请查看随后的一跳，如果该跳丢包率是0.0％，那么您可以确定您看到 ICMP 速率限制，而不是实际丢包。参见下面的例子：
1 [root@localhost ~]# mtr -r www.goole.com 2 HOST: PBSVVTRADER01 Loss% Snt Last Avg Best Wrst StDev 3 1. 10.1.1.254 0.0% 10 1.6 0.8 0.7 1.6 0.3 4 2. 10.1.253.22 0.0% 10 0.5 0.6 0.3 1.4 0.3 5 3. 210.74.5.2 0.0% 10 1.0 1.1 0.9 1.3 0.2 6 4. 10.244.246.9 0.0% 10 2.0 2.5 1.6 5.2 1.2 7 5. 10.244.200.1 0.0% 10 1.8 2.3 1.6 3.8 0.7 8 6. 172.18.0.149 0.0% 10 4.2 9.9 4.2 35.1 11.0 9 7. 222.35.253.153 0.0% 10 2.2 2.2 2.1 2.6 0.2 10 8. 61.233.9.209 0.0% 10 3.4 5.2 3.1 7.0 1.5 11 9. 61.237.123.134 0.0% 10 32.9 34.4 32.7 36.7 1.4 12 10. 61.237.123.214 0.0% 10 33.5 33.5 33.1 34.1 0.3 13 11. prs-b4-link.telia.net 10.0% 10 217.3 217.5 217.2 217.9 0.2 14 12. prs-bb2-link.telia.net 0.0% 10 222.8 234.4 222.7 291.5 24.8 15 13. ffm-bb4-link.telia.net 0.0% 10 218.0 220.1 218.0 223.5 2.3 16 14. ffm-b1-link.telia.net 0.0% 10 217.9 223.8 217.9 233.9 6.2 17 15. 1o1internet-ic-309319-ffm-b1 0.0% 10 234.4 227.2 223.1 234.4 3.2 18 16. ae-11.bb-c.bs.kae.de.oneando 0.0% 10 228.2 231.2 225.1 238.0 5.0 19 17. ae-3.bb-c.bap.rhr.de.oneando 0.0% 10 226.1 231.4 226.1 238.1 4.6 20 18. ae-11.gw-distp-a.bap.rhr.de. 0.0% 10 226.3 227.3 226.0 235.7 3.2 21 19. ae-1.gw-prtr-r231-a.bap.rhr. 0.0% 10 221.3 221.4 221.2 221.7 0.2 22 20. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 #后面会讲到 23 21. s325913783.websitehome.co.uk 0.0% 10 223.3 223.6 222.1 225.1 1.1 24 [root@localhost ~]#
在这种情况下，第10跳和第11跳之间报告的丢包可能是由于第11跳速率限制。虽然剩下的跳数的流量都触及第11跳，但是没有丢包。如果丢失持续多于一个跳，则可能存在一些丢包或路由问题。请记住，速率限制和丢失可能同时发生。在这种情况下，将序列中的最低损失百分比作为实际损失。例如，考虑以下输出：
1 [root@localhost ~]# mtr -r www.goole.com 2 HOST: PBSVVTRADER01 Loss% Snt Last Avg Best Wrst StDev 3 1. 10.1.1.254 0.0% 10 1.6 0.8 0.7 1.6 0.3 4 2. 10.1.253.22 0.0% 10 0.5 0.6 0.3 1.4 0.3 5 3. 210.74.5.2 0.0% 10 1.0 1.1 0.9 1.3 0.2 6 4. 10.244.246.9 0.0% 10 2.0 2.5 1.6 5.2 1.2 7 5. 10.244.200.1 0.0% 10 1.8 2.3 1.6 3.8 0.7 8 6. 172.18.0.149 0.0% 10 4.2 9.9 4.2 35.1 11.0 9 7. 222.35.253.153 0.0% 10 2.2 2.2 2.1 2.6 0.2 10 8. 61.233.9.209 0.0% 10 3.4 5.2 3.1 7.0 1.5 11 9. 61.237.123.134 0.0% 10 32.9 34.4 32.7 36.7 1.4 12 10. 61.237.123.214 0.0% 10 33.5 33.5 33.1 34.1 0.3 13 11. prs-b4-link.telia.net 10.0% 10 217.3 217.5 217.2 217.9 0.2 14 12. prs-bb2-link.telia.net 0.0% 10 222.8 234.4 222.7 291.5 24.8 15 13. ffm-bb4-link.telia.net 0.0% 10 218.0 220.1 218.0 223.5 2.3 16 14. ffm-b1-link.telia.net 0.0% 10 217.9 223.8 217.9 233.9 6.2 17 15. 1o1internet-ic-309319-ffm-b1 0.0% 10 234.4 227.2 223.1 234.4 3.2 18 16. ae-11.bb-c.bs.kae.de.oneando 0.0% 10 228.2 231.2 225.1 238.0 5.0 19 17. ae-3.bb-c.bap.rhr.de.oneando 10.0% 10 226.1 231.4 226.1 238.1 4.6 20 18. ae-11.gw-distp-a.bap.rhr.de. 10.0% 10 226.3 227.3 226.0 235.7 3.2 21 19. ae-1.gw-prtr-r231-a.bap.rhr. 20.0% 10 221.3 221.4 221.2 221.7 0.2 22 20. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 #后面会讲到 23 21. s325913783.websitehome.co.uk 10.0% 10 223.3 223.6 222.1 225.1 1.1
在这种情况下，您会看到跳数17和18之间的损失为10％,18和19跳之间的损失为20％。您可以假设第18跳和第19跳可能会丢失一定数量的流量，因为后续的主机报告零损失。然而，一些损失是由于速率限制，因为几个最终的跳数只有10％的损失。报告不同数量的损失时，请始终信任来自后期的报告。
一些损失也可以通过返回路线中的问题来解释。数据包将无错误地到达目的地，但很难做出回程。这在报告中很明显，但可能难以从 MTR 的输出中推断出来。因此，当您遇到问题时，通常最好双向收集 MTR 报告。
另外，抵制调查或报告您的连接中所有丢包发生的诱惑。互联网协议被设计为对一些网络退化具有弹性，并且数据跨 Internet 的路由可以响应于负载，简短的维护事件和其他路由问题而波动。如果您的 MTR 报告显示10％附近的少量损失，则没有任何理由引起真正的关注，因为应用层将补偿可能短暂的丢包。
了解网络延迟
除了帮助您评估数据包丢失之外，MTR 还将帮助您评估主机与目标主机之间的连接延迟。由于物理限制，延迟总是随着路由中的跳数而增加。但是，增幅应该是一致和线性的。不幸的是，延迟通常是相对的，并且非常依赖于主机连接的质量和它们的物理距离。在评估可能存在问题的连接的地铁报告时，除了在给定区域内的其他主机之间的已知连接速度之外，还可以将早期的全功能报告视为上下文。
连接质量也可能会影响特定路由的延迟时间。可以预见的是，拨号连接将比同一目的地的电缆调制解调器连接具有更高的延迟。考虑以下MTR报告显示高延迟：
1 [root@localhost ~]# mtr -r www.goole.com 2 HOST: PBSVVTRADER01 Loss% Snt Last Avg Best Wrst StDev 3 1. 10.1.1.254 0.0% 10 0.7 1.2 0.7 5.8 1.6 4 2. 10.1.253.22 0.0% 10 0.6 0.7 0.3 1.6 0.4 5 3. 210.74.5.2 0.0% 10 1.6 1.1 0.8 1.6 0.2 6 4. 10.244.246.9 0.0% 10 2.1 2.0 1.6 2.8 0.3 7 5. 10.244.200.1 0.0% 10 1.7 2.0 1.7 2.7 0.3 8 6. 172.18.0.149 0.0% 10 4.2 11.8 4.2 34.5 12.2 9 7. 222.35.253.153 0.0% 10 2.1 2.5 2.0 3.2 0.4 10 8. 61.233.9.209 0.0% 10 4.6 5.3 4.3 6.4 0.6 11 9. 61.237.123.134 0.0% 10 37.2 35.5 33.4 37.2 1.1 12 10. 61.237.123.214 0.0% 10 33.6 33.5 33.1 33.7 0.2 13 11. prs-b4-link.telia.net 0.0% 10 218.6 217.6 217.2 218.6 0.4 14 12. prs-bb2-link.telia.net 0.0% 10 222.9 224.8 222.7 240.5 5.5 15 13. ffm-bb4-link.telia.net 0.0% 10 219.2 221.4 218.4 226.5 2.7 16 14. ffm-b1-link.telia.net 0.0% 10 225.6 222.3 218.1 229.8 4.5 17 15. 1o1internet-ic-309319-ffm-b1 0.0% 10 229.2 227.5 223.5 232.9 3.1 18 16. ae-11.bb-c.bs.kae.de.oneando 0.0% 10 225.7 228.7 225.2 238.0 4.2 19 17. ae-3.bb-c.bap.rhr.de.oneando 0.0% 10 226.0 228.2 225.9 236.7 4.3 20 18. ae-11.gw-distp-a.bap.rhr.de. 10.0% 10 230.3 227.3 225.9 231.9 2.2 21 19. ae-1.gw-prtr-r231-a.bap.rhr. 10.0% 10 221.3 222.1 221.3 226.7 1.7 22 20. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 23 21. s325913783.websitehome.co.uk 10.0% 10 224.9 224.8 223.2 226.5 0.9
跳数在跳数10和11之间显着跳跃，并保持高电平。这可能指向网络延迟问题，因为在第11跳之后的往返时间保持较高。从这个报告来看，不可能确定原因，尽管饱和的对等会话，配置不良的路由器、拥塞的链路是比较频繁或物理链路过长的原因。
不幸的是，高延迟并不总是意味着当前路由的问题。像上面这样的报告意味着，尽管第11跳有某种问题，但流量仍然到达目的地主机并返回到源主机。延迟可能是由于返回路线的问题引起的。您的 MTR 报告中不会显示返回路由，并且数据包可以采取与特定目的地完全不同的路由。
在上面的例子中，虽然主机10和11之间的延迟有很大的跳跃，但延迟在任何后续跳都不会异常增加。从这一点来说，假设第四个路由器有一些问题是合乎逻辑的。
ICMP 速率限制还可以产生类似延迟的现象，类似于它可以产生类似丢包的现象。请考虑以下示例：
1 [root@localhost ~]# mtr -r www.baidu.com 2 HOST: PBSVVTRADER01 Loss% Snt Last Avg Best Wrst StDev 3 1. 10.1.1.254 0.0% 10 0.7 1.3 0.7 3.7 1.0 4 2. 10.1.253.22 0.0% 10 0.6 0.9 0.5 2.5 0.6 5 3. 210.74.5.2 0.0% 10 1.1 1.0 0.8 1.5 0.2 6 4. 10.244.246.9 0.0% 10 1.9 2.0 1.7 2.8 0.4 7 5. 10.244.244.10 0.0% 10 2.9 2.8 2.4 3.5 0.4 8 6. 14.197.149.173 0.0% 10 2.4 2.6 2.2 3.2 0.3 9 7. 14.197.253.49 0.0% 10 68.7 71.8 2.9 104.7 28.4 10 8. 14.197.178.94 0.0% 10 3.6 3.4 3.1 4.3 0.4 11 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12 10. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13 11. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14 12. 220.181.112.244 0.0% 10 3.1 3.3 3.0 3.7 0.2 15 [root@localhost ~]#
乍看之下，跳数6和7之间的延迟引起了关注。然而，在第7跳之后，潜伏期急剧下降。这里测量的实际延迟约为3.6ms。在这种情况下，中期审查提请注意不影响服务的问题。在评估 MTR 报告时，考虑到最后一跳的延迟。
MTR 通用报告
一些网络问题是新颖的，需要升级到上游网络的运营商。然而，有一些常见的地铁报告描述了常见的网络问题。如果您遇到某种网络问题，并想要诊断您的问题，请考虑以下示例。
目的主机网络配置不正确
在下一个示例中，由于配置不正确的路由器，目标主机似乎有100％的损失。乍看之下，数据包似乎没有到达主机，但情况并非如此。
1 root@localhost:~# mtr --report www.google.com 2 HOST: localhost Loss% Snt Last Avg Best Wrst StDev 3 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 4 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 5 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 6 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 7 5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9 8 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 9 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 10 8. gw-in-f147.1e100.net 100.0 10 0.0 0.0 0.0 0.0 0.0
然而，流量确实到达目的主机，MTR 报告显示丢失，因为目的地主机没有发送回复。这可能是导致主机丢弃ICMP数据包的不正确配置的网络或防火墙（iptables）规则的结果。
你可以告诉这个失败是由于一个配置错误的主机造成的，是看看100％损失的跳数。从以前的报告可以看出，这是最后一次跳跃，MTR不会尝试额外的跳数。虽然在没有基线测量的情况下难以分离这个问题，但这些错误是很常见的。
住宅或商业路由器
通常，住宅网关将使mtr报告看起来有点误导。
1 % mtr --no-dns --report google.com 2 HOST: deleuze Loss% Snt Last Avg Best Wrst StDev 3 1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2 4 2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0 5 3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2 6 4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4 7 5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3 8 6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9 9 7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9 10 8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6 11 9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9 12 10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2 13 11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5
不要因报告的100％损失而感到震惊。这并不表示有问题。你可以看到后续的跳数没有损失。
ISP路由器配置不正确
有时，您的数据包路由器上的路由器配置错误，您的数据包可能永远不会到达目的地。请考虑以下示例：
1 root@localhost:~# mtr --report www.google.com 2 HOST: localhost Loss% Snt Last Avg Best Wrst StDev 3 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 4 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 5 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 6 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 7 5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 8 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 11 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 12 10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
当没有其他路线信息时会出现问号。以下报告显示相同的问题：
1 root@localhost:~# mtr --report www.google.com 2 HOST: localhost Loss% Snt Last Avg Best Wrst StDev 3 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 4 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 5 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 6 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 7 5. 172.16.29.45 0.0% 10 0.0 0.0 0.0 0.0 0.0 8 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 11 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 12 10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
有时，配置不佳的路由器会以循环的形式发送数据包。您可以在以下示例中看到：
root@localhost:~# mtr --report www.google.com HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 14. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
所有这些报告显示，第4跳的路由器未正确配置。当这些情况发生时，解决问题的唯一方法是联系来自主机的网络管理员的运营商团队。
ICMP速率限制
ICMP速率限制可能会导致明显的丢包，如下所述。当丢包到一跳不持续到后续跳数时，丢失是由ICMP限制引起的。请参阅以下示例：
1 root@localhost:~# mtr --report www.google.com 2 HOST: localhost Loss% Snt Last Avg Best Wrst StDev 3 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 4 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 5 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 6 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 7 5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9 8 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 9 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 10 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
在这样的情况下，不用担心。速率限制是一种常见的做法，它可以减少拥塞以优先考虑更重要的流量。
超时
超时可能由于各种原因而发生。一些路由器将丢弃ICMP，并且输出中没有回应将作为超时显示（???）。或者，返回路线可能有问题：
1 root@localhost:~# mtr --report www.google.com 2 HOST: localhost Loss% Snt Last Avg Best Wrst StDev 3 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 4 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 5 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 6 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 7 5. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9 8 6. ??? 0.0% 10 39.1 39.4 39.1 39.7 0.2 9 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 10 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
超时不一定表示丢包。数据包仍然到达目的地，而不会显着丢包或延迟。超时可能因为路由器丢弃用于QoS（服务质量）的分组，或者可能存在导致超时的返回路由的某些问题。
新版 MTR 技术
mtr现在保存在github中的git仓库中
1 git clone https://github.com/traviscross/mtr.git 2 cd mtr/ 3 yum install aclocal autoheader automake autoconf 4 ./bootstrap.sh && ./configure && make 5 make install
与默认使用ICMP（ping）协议相比，更新版本的MTR现在能够在TCP模式下以指定的TCP端口运行。在某些情况下，网络劣化只会影响某些端口，或者路由器上错误配置的防火墙规则可能会阻塞一定的协议。在某个端口上运行MTR可能会显示丢包，默认的ICMP报告可能没有。
1 [root@localhost ~]# mtr -P 443 -i 0.5 -r www.baidu.com 2 Start: 2017-08-22T22:51:17+0800 3 HOST: PBSVVTRADER02 Loss% Snt Last Avg Best Wrst StDev 4 1.|-- 10.1.1.254 0.0% 10 0.7 0.7 0.7 0.8 0.0 5 2.|-- 10.1.253.22 0.0% 10 0.5 0.5 0.4 0.7 0.1 6 3.|-- 210.74.5.3 0.0% 10 1.1 1.1 0.8 1.3 0.2 7 4.|-- 10.244.246.13 0.0% 10 3.2 2.6 1.7 6.3 1.4 8 5.|-- 10.244.200.5 0.0% 10 2.0 3.7 1.7 19.2 5.4 9 6.|-- 10.244.253.1 0.0% 10 2.6 2.6 2.4 2.9 0.1 10 7.|-- 10.244.199.237 0.0% 10 3.4 3.3 3.0 3.7 0.2 11 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12 9.|-- 220.181.177.41 90.0% 10 98.6 98.6 98.6 98.6 0.0 13 10.|-- 220.181.0.46 80.0% 10 4.3 4.5 4.3 4.7 0.2 14 11.|-- 180.149.128.190 0.0% 10 7.1 13.8 5.8 63.9 17.9 15 12.|-- 180.149.129.54 0.0% 10 4.3 3.9 3.8 4.3 0.2 16 13.|-- 192.168.0.121 0.0% 10 4.2 4.1 4.0 4.3 0.1 17 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 18 15.|-- 180.149.131.98 0.0% 10 4.0 3.8 3.5 4.1 0.2 19 [root@localhost ~]#
