☰

间歇性高 ping/延迟问题

tag-icon • tag-icon ping isp latency networking
间歇性高 ping/延迟问题

我一直在与我的 ISP（WISP，实际上是固定宽带无线）合作，试图找出为什么我会间歇性地出现高延迟。在在线游戏和其他流媒体应用中可以检测到延迟。如果我进行跟踪路由，您可以看到通过回程网络的路径：

Tracing route to google.com [74.125.67.105]
over a maximum of 30 hops:

  1     1 ms     4 ms    <1 ms  192.168.23.1
  2     1 ms     8 ms     9 ms  10.100.100.1
  3     9 ms     9 ms     3 ms  10.7.37.1
  4    15 ms    24 ms    19 ms  10.7.36.1
  5    10 ms    79 ms     9 ms  10.7.31.3
  6    10 ms    39 ms    39 ms  10.10.5.9
  7    19 ms    19 ms    19 ms  10.10.5.5
  8     9 ms    19 ms    19 ms  10.10.5.1
  9   341 ms   237 ms   226 ms  10.250.200.1
 10   249 ms   280 ms   991 ms  <ISP WAN IP>
 11   703 ms   681 ms   401 ms  <ISP WAN IP>
 12   819 ms   628 ms   484 ms  <AT&T IP>    <- Traffic enters AT&T backbone
 13   699 ms   528 ms   290 ms  <AT&T IP>
 14   201 ms   106 ms    52 ms  <AT&T IP>
 15   624 ms   392 ms   436 ms  <AT&T IP>
 16   666 ms     *      252 ms  <AT&T IP>
 17   456 ms   403 ms   581 ms  209.85.254.120
 18   430 ms   339 ms     *     209.85.242.215
 19  1061 ms    56 ms    53 ms  72.14.239.131
 20  3514 ms   734 ms   219 ms  209.85.255.190
 21    49 ms    59 ms    56 ms  74.125.67.105

这似乎表明问题出在 10.250.200.1 的主机上。但是，如果我直接 ping 主机，一切似乎都很好（往返时间约为 10 毫秒）。在可疑节点之后 ping 后续跳数也会给出合理的往返时间。高延迟一次可能只持续几秒钟，最多持续几分钟。

编辑是的，这是一个显示明确问题的跟踪的不好的例子，但经过反复测试，在第 9 跳之前的延迟从未超过 100 毫秒，这就是我认为它可能是一个问题的原因。

活动期间的 pathping 会产生以下结果：

        Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.23.129
                                0/ 100 =  0%   |
  1    2ms     0/ 100 =  0%     0/ 100 =  0%  192.168.23.1
                                0/ 100 =  0%   |
  2    3ms     0/ 100 =  0%     0/ 100 =  0%  10.100.100.1
                                0/ 100 =  0%   |
  3   14ms     0/ 100 =  0%     0/ 100 =  0%  10.7.37.1
                                0/ 100 =  0%   |
  4   15ms     0/ 100 =  0%     0/ 100 =  0%  10.7.36.1
                                0/ 100 =  0%   |
  5   19ms     0/ 100 =  0%     0/ 100 =  0%  10.7.31.3
                                0/ 100 =  0%   |
  6   27ms     0/ 100 =  0%     0/ 100 =  0%  10.10.5.9
                                0/ 100 =  0%   | 
  7   28ms     0/ 100 =  0%     0/ 100 =  0%  10.10.5.5
                                0/ 100 =  0%   |
  8  ---     100/ 100 =100%   100/ 100 =100%  10.10.5.1
                                0/ 100 =  0%   |
  9   25ms     0/ 100 =  0%     0/ 100 =  0%  10.250.200.1
                                0/ 100 =  0%   |
 10   24ms     1/ 100 =  1%     1/ 100 =  1%  <ISP WAN IP>
                                0/ 100 =  0%   |
 11   25ms     4/ 100 =  4%     4/ 100 =  4%  <ISP WAN IP>
                                0/ 100 =  0%   |
 12   35ms     0/ 100 =  0%     0/ 100 =  0%  <AT&T IP>
                                0/ 100 =  0%   |
 13  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 14  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 15  ---     100/ 100 =100%   100/ 100 =100%  <AT&T IP>
                                0/ 100 =  0%   |
 16   58ms     0/ 100 =  0%     0/ 100 =  0%  <AT&T IP>
                                1/ 100 =  1%   |
 17   59ms     1/ 100 =  1%     0/ 100 =  0%  209.85.254.120
                                0/ 100 =  0%   |
 18   59ms     1/ 100 =  1%     0/ 100 =  0%  209.85.242.215
                                0/ 100 =  0%   |
 19   56ms     1/ 100 =  1%     0/ 100 =  0%  72.14.239.127
                                0/ 100 =  0%   |
 20   60ms     1/ 100 =  1%     0/ 100 =  0%  209.85.255.194
                                0/ 100 =  0%   |
 21   59ms     1/ 100 =  1%     0/ 100 =  0%  74.125.67.105

为什么这种延迟只在跟踪路由期间出现，而在正常 ping 时不出现？我在我的应用程序中看到的性能不足与此相符。

换句话说，当我的应用程序出现问题时，如果我同时运行跟踪，我会得到上述结果同时对可疑主机进行 ping 操作，结果显示 ping 正常。

答案1

WISP？含义无线的ISP？如果是，那答案很可能是这样的。无线不可靠，你正在看到这方面的证据。

你无法真正解决这个问题，因为你的介质（大气）对于传输数据来说真的很糟糕。首先，因为空气是一个枢纽，而不是一个交换机，所以你与周围的任何人共享它并发生数据包冲突，其次因为载波监听/载波聚合比 CSMA/CD 慢，第三是因为无线通常是半双工而不是全双工，第四是因为与铜线相比，空中的干扰要高出几个数量级。[例如，微波的工作波长与 802.11b/g 相同……但微波的工作功率约为 500-1000 瓦，而无线天线的功率为 100 毫瓦。微波有屏蔽，但屏蔽并不完美，而且微波不受 FCC 监管，因此如果它们造成干扰并不违法。] 此外，您需要经过 10 多个跳转才能访问互联网。这无济于事，特别是在有 NAT 或防火墙的情况下。

正如 @dbasnett 所说，到给定主机的 traceroute ping 延迟仅指示该时间点接口之间的整个网络的状态。这就是为什么响应时间向下有时。它们会突然出现，因为网络不可靠。您的查询pathping看起来不错，因为它正在运行大量查询，而不是只tracert运行 3 个查询。因此，它pathping会向您显示网络在 325 秒内（默认情况下）正在做什么，并向tracert您显示网络上每跳 3 个数据包正在做什么。

答案2

10 次跟踪路由结果中有 9 次都不是网络问题的征兆。Traceroute 向源和目标之间的每个连续跳跃发送 ICMP 回显请求数据包，每个连续跳跃的 TTL 加一。每个跳跃的结果都表明该跳跃如何响应 ICMP 流量，而不是指示通过该跳跃和超出该跳跃的路径的质量。路由器的工作是转发流量，因此，许多路由器被编程为忽略、丢弃或降低指向自己的 ICMP 流量的优先级。跳跃 14、19 和 21 的响应时间非常好，这表明路径没有问题。如果在跳跃 12（如您所强调的）或影响路径的任何其他跳跃处存在问题，那么您会在每次连续跳跃中看到问题，并且您会看到每个跳跃都比前一个更糟糕。只有当您在跟踪路由中看到这些类型的结果时，您才应该怀疑路径问题。第 21 跳是目的地，响应时间为 59 毫秒，这说明源和目的地之间的路径没有问题。分析路径问题的关键是分析实际数据传输时的性能，除非您在每一跳都有数据包嗅探器/网络监视器，并且能够访问从源到目的地路径上每个网络节点（路由器和交换机）的内存、CPU 和吞吐量计数器，否则无法做到这一点。

您不应该尝试根据路径的 tracert 来找出性能问题的原因，而应该集中精力于源和目标之间的实际 TCP 会话，并查看这两个端点之间的响应时间（延迟）和任何数据包丢失。

跟踪路由，顾名思义，是一种用于发现两个端点之间的路径的工具，而不是一种用于分析该路径质量的工具。

答案3

我必须同意 joeqwerty 的观点，ICMP 很久以前就不再是衡量性能、延迟或吞吐量的可靠指标。对于在未知网络上有大量跳数的路由来说尤其如此。

更现实的测试是使用您所使用的协议。例如，如果是 http，您可以设置 Wireshark 网络数据包捕获。过滤与指定主机的对话，并使用 Wireshark 的“统计信息”>“TCP 流图”>“往返时间图”。如果您执行捕获至少几分钟，此测试会更准确。

另一个有趣的选择是PingPlotter 标准（不免费，但 30 天内功能齐全）。通过指定端口号，它提供了非常好的协议特定吞吐量测试功能，并且具有往返时间图表，可以保存和加载。

答案4

经过更多测试后，这是一个 UDP 延迟问题。

高延迟与应用程序性能不佳同时发生的原因似乎是 CPU 受限的主机。TTL 过期的 ICMP 数据包需要 CPU 时间来生成响应，因此大多数路由器都配置为“在我想响应时响应”。在这种情况下，TTL 过期的 ICMP 流量的延迟表明路由器很忙。主机似乎位于其网络的边缘，因此所有流量中的大部分都经过该跳转。

我高度怀疑 ISP 正在进行某种流量检查或 UDP 协议整形，这也需要 CPU 时间。

相关内容