☰

报告的长达一小时的 ping 时间怎么可能是真实的呢？

tag-icon • tag-icon networking routing adsl
报告的长达一小时的 ping 时间怎么可能是真实的呢？

我最近和父母一起度过了复活节银行假期，他们住在英国一个非常偏远的地区。他们家的 ADSL 互联网连接非常糟糕，需要通过几公里长的劣质铜线才能连接，当附近的农民将拖拉机倒车插入电话线时，互联网连接就会定期中断。

我注意到他们的路由器反复丢弃pptp握手并重新协商，从而有效地切断了连接。这令人沮丧。因此，为了避免失控，我告诉它将最低可接受 SNR 裕度和较低速度的握手加倍：

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

事情得到了改善，并且事物获得了一个（某种程度上）稳定的、尽管速度非常慢的、通向外界的管道：

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

就在这时，现实生活介入了进来，我花了好几个小时和猫一起玩，在手机上看猫的动图， 实际上和我的家人交谈等。我忘了我让这个 ping 过程一直在运行，大约一天之后又回来查看ctrl-c。

所展示的统计摘要让我震惊：

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

如你看到的，跨大西洋短途跳跃到达 Google DNS 服务器的 ICMP 数据包的最大响应时间为 3600577.732 毫秒。这差不多正好是一个小时ping，并且肯定比默认超时时间长得多。

怎么可能这可能吗？是准确吗？哪个路由器会乐意保留数据包六十分钟在发送之前？为什么这个数据包没有被丢弃？这是 8 位数据包计数器溢出与较大延迟相结合的结果吗？

最后，我很想知道，英国是否有任何行为准则规定，消费者的 ADSL 连接应具有比RFC 1149和RFC 2549;-)。

答案1

ping 的 ICMP 数据包和响应各有 32 个字节长，因此对于一个小时的 ping 来说，似乎每个字节都要花将近一分钟的时间来传输。

这只能通过非常慷慨的错误重试计数（您做的？）加上非常慢的路由器和每个传输字节的痛苦等待或重试来解释。

互联网协议 (IP) 通过数据报传输数据，并尽量不发送部分数据报。一旦开始传输，它将默认等待 200 毫秒，以便将更多字节添加到数据报中。超过该时间，软件/固件将以一个数据报的形式发送其所拥有的一切。在长达一小时的 ping 时间的情况下，数据包有效负载可能只有一个字节。只要数据仍在到达，参与双方就不会终止连接。

你可以做什么 ：

  • 如果其他电话、传真机或其他设备连接到同一电话线，请检查它们是否受到DSL 过滤器. 确保没有在通向 DSL 调制解调器的线路上放置过滤器。
  • 尝试另一个路由器 - 一旦您拥有一个坏的设备，您除了将其扔掉并换一个更好的设备之外什么也做不了。
  • 如果没有其他可用的路由器，请联系您的 ISP - 他们可以从他们那边运行有用的测试。
  • 如果 ISP 没有找到任何线索，请尝试要求更换路由器/调制解调器。
  • 如果另一个路由器也出现同样的问题，请联系电话公司。

找到有问题的交换机可能非常复杂，因为电话公司可能就是这样，但 ISP 也可能有自己的交换机。通常，交换机的问题会波及整个区域，这有助于找到故障交换机。但在农村地区，使用该交换机的用户并不多，因此可能无法检测到这种情况。如果一些邻居使用同一个 ISP，请尝试找出他们的连接情况。

答案2

我认为这种情况与数据拥塞管理非常相关，尽管无论出于何种原因，这种情况的管理都非常糟糕。据我所知，传输系统中存在数据包缓冲区管理不善，导致 ICMP 回显请求/回复数据包出现这种异常。

因此，糟糕的拥塞管理策略与持续数小时的 ping 会话相结合显然会导致这种奇怪的情况。

有关拥塞管理的更多信息这里。

相关内容