☰

问题

tag-icon • tag-icon networking internet tcp google mtr
问题

问题

根据mtr，我在通过互联网发送数据包时，数据包丢失率很高。我应该向 ISP 投诉吗？

故事

我正在阅读，OReilly Linux Networking Cookbook这章Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problems引起了我的注意。在互联网上 ping 像 Google 这样的主机来自我的 ISP记录延迟达到 1200 毫秒甚至更高（不仅从今天开始；很久以来），所以我认为用 来分析数据包的方式不会有什么坏处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 次测试，每 5 分钟测试 1 次；这是代表可靠“平均值”的报告）

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. 我应该告诉我的 ISP 什么？如何描述问题？
  2. 除了促进故障排除之外，我还可以做哪些研究？*1
  3. 有什么建议么？

*1 技术支持人员并不总是理解我的问题，或者我不能清楚地表达我的问题（有时他们无疑是白痴）

答案1

许多路由器通常被编程为给予 ICMP 数据包较低的优先级，这样它们就不会在“实际”流量上“浪费”处理能力。仅仅因为您看到一个丢失率高的跳跃并不意味着它正在减慢“实际”流量；它可能只是在丢弃 ICMP。这不一定是好事，因为这可能意味着路由器太忙，但这并不能保证。

还可以对路由器进行编程，以限制其向 ICMP 数据包发送的响应数量，以减轻 DoS 攻击。

答案2

错误可能是发生在您的网络内部。

哪一个是您的互联网路由器/网关？

有可能

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

位于您自己的网络内。

答案3

什么样的连接和订阅带宽？DSL、租用线路、帧中继、电缆？下行 768/上行 128……等等。

您可以使用 WireShark 获取更真实的信息，并在一段时间内（30 分钟）捕获/过滤两个主机之间的数据包。然后使用统计信息 > TCP 流图 > 往返时间图。往返时间 (RTT) 是 tcp 层的实际延迟。

答案4

假设您在第 15 跳的丢失率为零，您就知道您可以将流量一直传输到那里而不会丢失。第 1-15 跳的所有丢失数字都是“本地的”，即路由器尚未响应 ICMP，但它们已转发您的流量。

丢失数据最多的是最后一跳，也就是第 20 跳，所以最好的猜测是问题出在另一端的拥塞。向 ISP 报告问题不会有什么用处，但向另一端的任何服务投诉也许会有所帮助。

编辑：我知道这是一个老问题，但我认为值得澄清如何解释损失数字> 0 随后是无损跳跃。

相关内容