我将这两个mtr输出提供给最终用户，第一个是该网站的输出：
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 198.199.92.253 0.0% 200 7.3 4.2 0.9 89.6 8.0
2. 69.22.130.37 0.0% 200 0.4 2.5 0.3 51.4 8.0
3. 69.22.143.170 42.5% 200 1.3 2.0 1.1 47.9 4.9
4. 69.22.143.165 0.0% 200 2.3 6.4 1.6 56.9 9.7
5. 206.223.116.86 0.0% 200 2.5 3.0 1.8 14.1 1.5
6. 64.125.24.1 0.0% 200 3.0 6.9 2.2 65.7 9.9
7. 64.125.26.230 0.0% 200 56.3 61.4 55.6 119.0 10.0
8. 64.125.24.33 0.5% 200 76.4 78.9 76.0 116.1 7.1
9. 64.125.29.38 0.0% 200 73.9 77.5 73.4 238.8 13.4
10. 64.125.31.181 0.5% 200 160.0 159.4 156.2 181.4 4.3
11. 64.125.32.93 0.0% 200 156.9 157.8 155.9 217.0 6.8
12. 62.253.174.190 0.0% 200 166.0 166.5 165.6 172.8 1.2
13. 62.253.175.217 0.0% 200 162.1 163.1 161.7 200.4 4.2
14. 213.105.159.194 0.0% 200 163.8 165.0 163.4 241.2 8.3
15. 81.97.112.218 0.0% 200 164.7 166.5 164.5 220.0 7.4
16. ???
和我网络中的第二个：
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 216.16.235.1 0.0% 115 0.4 0.4 0.3 0.6 0.1
2. 216.16.232.37 0.0% 115 0.9 0.9 0.6 18.8 1.7
3. 216.16.255.141 0.0% 115 0.8 0.7 0.6 1.1 0.1
4. 216.16.255.130 0.0% 114 1.0 1.0 0.8 1.4 0.1
5. 24.153.3.141 0.0% 114 1.9 3.6 1.5 6.5 1.2
6. 64.71.241.97 0.0% 114 3.4 5.3 3.3 7.4 1.1
7. ???
8. 64.124.128.193 34.5% 114 18.9 19.2 18.7 39.0 2.3
9. 64.125.21.74 0.0% 114 19.2 20.4 18.9 49.9 5.0
10. 64.125.29.38 0.0% 114 19.3 23.1 19.2 48.3 7.6
11. 64.125.27.186 0.9% 114 105.2 106.1 105.1 137.8 3.2
12. 64.125.32.93 0.0% 114 106.3 107.1 106.1 163.3 5.8
13. 62.253.174.190 0.0% 114 181.8 123.5 115.8 206.3 20.9
14. 62.253.175.217 0.0% 114 113.8 114.8 113.6 144.3 4.2
15. 213.105.159.194 0.0% 114 115.3 115.9 115.2 163.5 4.6
16. 81.97.112.218 0.0% 114 113.3 114.4 113.2 140.7 4.5
17. ???
我应该如何解释那些具有大量数据包丢失的跃点？我倾向于认为这些跃点正在进行某种非对称路由，并且其中一条路径很拥挤。
这会对最终用户造成任何问题吗？
#1 楼
MTR使用ICMP，由于它可能被误用于产生问题（高CPU，带宽浪费，DoS等），因此在Internet上通常受速率限制。当您看到这样的输出时，通常这表明ICMP的速率限制已到位。通过快速的网络搜索，我找到了有关使用MTR的文档。虽然它不是官方的，但它看起来不错（至少可以进行快速扫描），并提供了一些使用MTR可能会发现的问题的示例。
#2 楼
正如@YLearn已经在具有数据包丢失的路由器上写ICMP速率限制很可能是原因，因为对ICMP请求的回复是在CPU中完成的，而数据包的转发通常是在ASIC中完成的。因此，这根本就不是问题。几年前，Richard Steenbergen写了一篇很好的解释跟踪路由（和MTR）输出的指南。他在NANOG上做了很好的介绍。
#3 楼
首先，我要说的是，您提到的路由可能是其中的一部分。这将是从那一跳回到主机的路由，而该路由却走了一条拥塞的路径，而其他路由却没有。我的家伙认为：如果这是该特定路由器上数据平面中的问题，我希望看到此跳之后所有跳的数据包丢失-但您看不到。
当数据包的TTL达到0时，则取决于路由器上的控制平面生成ICMP响应返回给发送主机。我的猜测是，该特定路由器上的控制平面CPU（在您执行跟踪的时间点）被充分利用，并且它会在MTR超时值之外向您发送一些响应。