原文发表于：如何用 MTR 诊断网络问题？---下篇
从如何用 MTR 诊断网络问题？（上）我们了解了什么是 MTR，以及如何生成一份报告等知识。这里，我们深入分析一下 MTR 报告的含义，以及常见的 MTR 结果分析。
分析 MTR 报告
验证数据包丢失
在分析 MTR 输出时，您正在寻找两件事情：丢包和延迟。首先让我们来谈谈丢包。如果您在任何特定跳点看到一定百分比的丢失，这可能表明该特定路由器存在问题。然而，一些服务提供商通常的做法是限制 MTR 使用的ICMP流量。这实际上没有损失可以给出丢包的错觉。要确定您看到的损失是真实的还是由于速率限制，请查看随后的一跳，如果该跳丢包率是0.0％，那么您可以确定您看到 ICMP 速率限制，而不是实际丢包。参见下面的例子：
root@localhost:~# mtr --report www.google.com
HOST: example 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 50.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. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
在这种情况下，第一跳和第二跳之间报告的丢包可能是由于第二跳速率限制。虽然剩下的八跳的流量都触及第二跳，但是没有丢包。如果丢失持续多于一个跳，则可能存在一些丢包或路由问题。请记住，速率限制和丢失可能同时发生。在这种情况下，将序列中的最低损失百分比作为实际损失。例如，考虑以下输出：
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 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
在这种情况下，您会看到跳数2和3之间以及跳数3和4之间的损失为60％。您可以假设第三跳和第四跳可能会丢失一定数量的流量，因为后续的主机报告零损失。然而，一些损失是由于速率限制，因为几个最终的跳数只有40％的损失。报告不同数量的损失时，请始终信任来自后期的报告。
一些损失也可以通过返回路线中的问题来解释。数据包将无错误地到达目的地，但很难做出回程。这在报告中很明显，但可能难以从 MTR 的输出中推断出来。因此，当您遇到问题时，通常最好双向收集 MTR 报告。
另外，抵制调查或报告您的连接中所有丢包发生的诱惑。互联网协议被设计为对一些网络退化具有弹性，并且数据跨 Internet 的路由可以响应于负载，简短的维护事件和其他路由问题而波动。如果您的 MTR 报告显示10％附近的少量损失，则没有任何理由引起真正的关注，因为应用层将补偿可能短暂的丢包。
了解网络延迟
除了帮助您评估数据包丢失之外，MTR 还将帮助您评估主机与目标主机之间的连接延迟。由于物理限制，延迟总是随着路由中的跳数而增加。但是，增幅应该是一致和线性的。不幸的是，延迟通常是相对的，并且非常依赖于主机连接的质量和它们的物理距离。在评估可能存在问题的连接的地铁报告时，除了在给定区域内的其他主机之间的已知连接速度之外，还可以将早期的全功能报告视为上下文。
连接质量也可能会影响特定路由的延迟时间。可以预见的是，拨号连接将比同一目的地的电缆调制解调器连接具有更高的延迟。考虑以下地铁报告显示高延迟：
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 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2
跳数在跳数3和4之间显着跳跃，并保持高电平。这可能指向网络延迟问题，因为在第四跳之后的往返时间保持较高。从这个报告来看，不可能确定原因，尽管饱和的对等会话，配置不良的路由器或拥塞的链路是比较频繁的原因。
不幸的是，高延迟并不总是意味着当前路由的问题。像上面这样的报告意味着，尽管第四跳有某种问题，但流量仍然到达目的地主机并返回到源主机。延迟可能是由于返回路线的问题引起的。您的 MTR 报告中不会显示返回路由，并且数据包可以采取与特定目的地完全不同的路由。
在上面的例子中，虽然主机3和4之间的延迟有很大的跳跃，但延迟在任何后续跳都不会异常增加。从这一点来说，假设第四个路由器有一些问题是合乎逻辑的。
ICMP 速率限制还可以产生类似延迟的现象，类似于它可以产生类似丢包的现象。请考虑以下示例：
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. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
乍看之下，跳数4和5之间的延迟引起了关注。然而，在第五跳之后，潜伏期急剧下降。这里测量的实际延迟约为40ms。在这种情况下，中期审查提请注意不影响服务的问题。在评估 MTR 报告时，考虑到最后一跳的延迟。
解决您的 MTR 报告中确定的路由和网络问题
审查报告显示的大部分路由问题是暂时的。大多数问题将在24小时内自行清理。在大多数情况下，当您能够注意到路由问题时，Internet服务提供商的监控已经报告了问题，管理员正在努力解决问题。如果您在长时间内遇到劣化服务的情况，您可以选择向提供商提醒您遇到的问题。联系服务提供商时，可以发送MTR 报告和您可能拥有的任何其他相关数据。
