我一直在从我的一台服务器上运行MTR，注意到一些对我来说很奇怪的事情。 因为我不是真的进了这个，我会给你三个输出：
这是从服务器到我家的位置：
My traceroute [v0.75] prag341.server4you.de (0.0.0.0) Sat Apr 16 12:31:36 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. v9-609a.s4y14.fra.routeserver.net 0.0% 143 6.6 2.9 0.7 15.6 2.4 2. 217.118.16.161 0.0% 143 0.7 5.7 0.4 67.3 13.2 3. 217.118.16.25 0.0% 143 3.3 5.3 3.3 63.5 8.6 4. 194.25.211.53 0.0% 143 3.4 5.5 3.2 61.1 9.1 5. vie-sb2-i.VIE.AT.NET.DTAG.DE 0.7% 143 17.8 21.7 17.6 131.1 14.8 vie-sb2-i.VIE.AT.NET.DTAG.DE 6. at-vie05b-ri1-pos-5-0.aorta.net 0.7% 143 18.7 18.4 17.6 23.8 0.9 7. at-vie05b-ri2-ge-2-1-9.aorta.net 0.0% 143 17.9 18.6 17.5 41.7 2.6 8. at-vie01a-rd1-xe-1-0-0.aorta.net 0.0% 143 18.2 21.1 17.3 104.1 12.0 9. at-vie-sk11-pe01-vl-20.upc.at 0.0% 143 18.2 20.6 17.7 55.7 7.0 10. at-vie-sk11-pe02-vl-1.upc.at 0.0% 143 17.8 19.6 17.3 55.2 6.6 11. ??? 这是从我家的位置到服务器：
My traceroute [v0.80] joe-desktop (0.0.0.0) Sat Apr 16 14:27:54 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 87 0.2 0.2 0.2 0.2 0.0 2. ??? 3. 84.116.4.33 0.0% 86 9.7 9.0 6.3 27.3 3.5 4. at-vie-sk11-cia01-vl-2070.upc.at 0.0% 86 22.7 22.8 20.0 52.2 4.7 5. at-vie-sk11-pe01-vl-2069.upc.at 0.0% 86 47.6 23.9 20.2 47.6 5.8 6. at-vie01a-rd1-vl-2042.aorta.net 0.0% 86 21.7 25.0 20.1 61.7 8.5 7. de-fra03a-rd1-xe-9-2-0.aorta.net 0.0% 86 21.3 22.8 19.6 44.0 5.0 8. 84.116.132.154 0.0% 86 20.2 22.8 19.3 41.0 4.1 9. tge-5-1-0-353a.cr2.fra.routeserver.net 0.0% 86 38.6 27.4 20.9 120.2 16.0 10. 217.118.16.130 0.0% 86 23.7 26.9 20.8 73.0 9.8 11. 217.118.16.26 0.0% 86 25.5 28.8 22.9 85.1 11.8 12. 217.118.16.165 81.2% 86 68.2 37.5 25.0 68.2 10.3 13. prag341.server4you.de 0.0% 86 35.7 27.1 24.0 49.3 4.3
这是从另一台服务器（亚马逊ec2）到服务器：
My traceroute [v0.75] flimmit.com (0.0.0.0) Sat Apr 16 12:32:50 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ip-10-48-192-3.eu-west-1.compute.internal 0.0% 178 0.4 0.9 0.3 16.4 1.7 ip-10-48-192-2.eu-west-1.compute.internal 2. ec2-79-125-0-244.eu-west-1.compute.amazonaws.com 0.0% 178 0.5 0.9 0.3 30.8 2.6 ec2-79-125-0-242.eu-west-1.compute.amazonaws.com 3. ??? 4. ??? 5. ??? 6. xe-4-1-0.dub10.ip4.tinet.net 36.5% 178 1.9 3.9 1.6 56.8 8.5 7. xe-4-1-0.dub10.ip4.tinet.net 0.0% 178 12.1 9.7 1.6 92.5 10.5 xe-0-1-0.lon14.ip4.tinet.net xe-2-1-0.lon14.ip4.tinet.net 8. xe-0-1-0.lon14.ip4.tinet.net 0.0% 177 17.4 17.7 11.1 184.3 24.6 xe-2-1-0.lon14.ip4.tinet.net 213.200.77.234 9. 213.200.77.234 0.0% 177 25.2 23.7 12.0 162.5 16.0 tge-4-2-0-0a.cr2.fra.routeserver.net 10. tge-4-2-0-0a.cr2.fra.routeserver.net 0.6% 177 178.6 57.1 24.7 178.6 39.0 217.118.16.26 11. 217.118.16.26 47.2% 177 32.7 61.1 29.1 164.4 35.4 217.118.16.165 12. 217.118.16.165 28.2% 177 28.9 29.8 27.8 48.9 4.2 prag341.server4you.de 13. prag341.server4you.de 1.1% 177 28.2 28.7 27.7 63.4 2.9
对我来说，看起来很奇怪的是，从我家的位置到服务器的最后一跳，这个非常高的损失> 80％。 服务器响应良好，服务运行顺利。
这可能是由于我缺乏networking知识，但对我来说，损失率应该加起来是合乎逻辑的。 但是我经常看到地铁在路上有高损失的地方输出，但最终的目标损失要低得多。
所以我的问题是：
在我的具体情况下，这是我应该注意的一个可能的问题的一个指标吗？
一般来说，如何正确解释mtr的输出？ 你能推荐一篇好文章吗？
数据包丢失不是一个问题的指示。 记住那些是直接与特定的networking节点进行通信的尝试。 通常这些中间路由器节点只负责将traffik 传递到另一个位置。 他们并不需要直接和你聊天，而且大部分聊天内容都不应该引起你的关注。 唯一重要的数字就是有多less数据包到达目的地 。
这些报告中最有用的信息是节点距离（包时间）有多远的相关数据，甚至更重要的是有多less跳，这样你就可以知道不同的时间段这个旅程将需要尝试与您的服务器通信的人。 通常，跳数越less，路由效率越高 – 表示ISP的质量。
MTR擅长测量站点间的延迟和跳跃。 在可达站点前面的防火墙上有百分之百的损失。 我通常将间隔设置为15秒或更长时间以减轻networking负载。 得到结果需要更长的时间，但是我发现结果更可靠。
有些路由器生成MTR用于检测中间路由器的错误报文的优先级较低。 如果路由器忙，可能会丢弃数据包，等待下一个。 这将导致该路由器的高丢弃率。 如果路由器远离0％，那么事情就很好。
当路由dynamic变化时也可能发生分组丢失。 您的最后一个跟踪显示路线随时间变化。 论文应该比较短期，容易恢复。
丢失率可以表示路由器过载。 如果有连接或数据包丢失问题，我开始调查在最接近的路由器损失率在0％以上。