间歇性高 ping/延迟问题

Question

我一直在与我的 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 毫秒，这就是为什么我认为这可能是一个问题。

事件期间的路径追踪会产生以下结果：

        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。

Answer 1

经过更多测试，这是 UDP 延迟的问题。

高延迟与较差的应用程序性能同时发生的原因似乎是受 CPU 限制的主机。具有过期 TTL 的 ICMP 数据包需要 CPU 时间来制作响应，因此大多数路由器都配置为“在需要时进行应答”。在这种情况下，过期 TTL ICMP 流量的延迟表明路由器繁忙。主机似乎位于其网络的边缘，因此所有流量的很大一部分都经过该跃点。

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