根据mtr ，在互联网上发送数据包时，我的数据包丢失率很高。 我应该向我的ISP抱怨吗？
我正在阅读OReilly Linux Networking Cookbook以及Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problems这一章引起了我的注意。 通过互联网从ISP那里 ping一个像Google这样的主机给我的logging延迟时间为1200ms或者更长（不仅从今天开始，因为很长一段时间） ，所以我认为我不会用mtr分析数据包的方式。
Mtr is a network diagnostic tool that combines ping and traceroute into one program.
摘录，同时，这个问题的原因线程是：
如果这些路由器中的任何一个始终挂在相同的路由器上，或者如果mtr在同一台路由器上一直显示大于5％的数据包丢失和较长的传输时间，那么可以肯定地说特定路由器有问题。 如果它是一个你控制的路由器，那么天哪就修好它。 如果不是，请使用dig或whois来找出它属于谁，并很好地向他们报告麻烦。
请参阅mtr --report www.google.com输出您自己:( 总共12次testing，每5分钟进行一次testing;这是代表可靠“平均值”的报告）
HOST: km Loss% Snt Last Avg Best Wrst StDev 1. 192.168.0.1 0.0% 10 1.2 3.7 1.2 6.3 1.8 2. 10.150.144.145 10.0% 10 89.1 77.3 58.7 90.4 11.1 3. 172.16.251.1 50.0% 10 52.2 62.1 52.2 70.3 8.8 4. 172.16.250.54 60.0% 10 74.9 87.5 74.9 100.4 12.1 5. 172.16.250.251 40.0% 10 68.6 75.4 52.4 113.8 24.2 6. 200.85.47.2 10.0% 10 109.6 110.6 80.6 146.2 21.1 7. 201.217.4.113 0.0% 10 103.6 87.3 64.4 103.7 12.2 8. 201.217.0.9 0.0% 10 229.0 102.6 46.7 229.0 48.1 9. 201.217.0.3 0.0% 10 78.8 88.1 53.9 128.8 23.8 10. So2-3-2-0-grtbueba2.red.tele 0.0% 10 134.1 129.2 71.3 176.6 29.2 11. Xe4-1-3-0-grtmiabr7.red.tele 0.0% 10 257.3 255.1 221.0 291.6 21.1 12. Xe2-0-2-0-grtmiana3.red.tele 0.0% 10 290.4 267.0 213.2 319.1 31.0 13. Xe2-0-2-0-grtmiana3.red.tele 0.0% 10 300.0 250.8 217.3 312.7 34.6 14. GOOGLE-xe-5-0-0-0-grtmiana3. 10.0% 10 249.8 256.9 206.7 324.0 34.6 15. 209.85.254.252 0.0% 10 254.3 253.8 217.1 283.1 23.4 16. 209.85.254.252 10.0% 10 301.2 280.6 252.1 319.7 21.6 17. 72.14.236.200 10.0% 10 273.4 278.4 238.4 311.0 25.0 18. 216.239.49.145 20.0% 10 291.0 276.3 240.4 293.5 19.1 19. 72.14.232.25 10.0% 10 297.9 286.3 242.4 337.1 30.0 20. yo-in-f105.1e100.net 70.0% 10 300.7 304.7 280.3 333.0 26.6
您立即看到主机3-5正在经历远远超过5％的非常高的数据包丢失。 做一个whois数据库查询显示我是那些名字服务器（请纠正我，如果我错了）。
* 1 那些来自技术支持的人并不总是理解，或者我不能清楚地expression我的问题（有时他们毫无疑问只是白痴）
许多路由器通常被编程为给予ICMP分组更低的优先级，所以它们不会“浪费”处理“真实”业务的能力。 仅仅因为你看到一个高损失的跳跃并不意味着它会减缓“真实”的stream量。 它可能只是扔掉ICMP。 这不一定好，因为这可能意味着路由器太忙，但不能保证。
路由器也可以编程来限制发送给ICMP数据包的响应数量，以减轻DoS攻击。
这可能是错误是在你的networking内。
哪一个是你的互联网路由器/网关？
机会是这样的
3. 172.16.251.1 50.0% 10 52.2 62.1 52.2 70.3 8.8 4. 172.16.250.54 60.0% 10 74.9 87.5 74.9 100.4 12.1 5. 172.16.250.251 40.0% 10 68.6 75.4 52.4 113.8 24.2
在你自己的networking里面
什么样的连接和订阅带宽？ DSL，租用线路，帧中继，电缆？ 768下降/ 128上升…等
您可以使用WireShark获取更为真实的信息，并在两台主机之间捕获/过滤数据包一段时间（30分钟）。 然后使用统计> TCPstream图>往返时间图。 往返时间（RTT）是tcp层的实际延迟。
鉴于您在第15跳处有零损失，您知道，您可以一路畅通无阻地stream量。 所有的跳数1-15的损失是“本地的”，即路由器没有响应ICMP，但他们已经转发您的stream量。
在最后一跳，最大的损失是20，所以最好的猜测是问题是在另一端的拥塞。 向您的ISP提交问题报告不会有任何好处，但是可能对另一端的任何服务提出投诉可能会有所帮助。
编辑：我知道这是一个古老的问题，但我认为它应该解释如何解释损失数字> 0，然后是无损失的啤酒花。