☰

游戏延迟在白天会增加，但 ping 命令不会显示出来

tag-icon • tag-icon networking ping gaming
游戏延迟在白天会增加，但 ping 命令不会显示出来

命令行 ping 命令显示 eu.newerth.com 服务器 24/7 的 ping 时间为 81ms。然而，在过去几天里，我的游戏内 ping 在白天为 135，在晚上为 95（与服务器活动较少的时间相关）。

在游戏中大约有 15ms 的额外时间是正常的（就像我在晚上一样），但是白天的跳跃令人费解，因为它不会在 icmp ping 测量中转换。

游戏本身使用 UDP，尽管我认为游戏使用 TCP 来测量 ping。

我在美国使用一个非常快的大学 ISP，服务器在伦敦，这个问题似乎影响了其他美国客户，但我不确定。它没有影响来自欧洲的玩家。

我的游戏内延迟与同一游戏中其他服务器（例如德国的服务器）的延迟不会经历相同的昼夜循环并且保持稳定。

游戏中的 ICMP 数量增加但并没有相应增加，这是什么原因造成的？

答案1

诊断：

首先做一个Tracert至 eu.newerth.com。

Traceroute 是一种计算机网络工具，用于确定数据包在 IP 网络上所采用的路由。

以下是我的计算机的输出（删除了前几个跳数）：

Tracing route to eu.newerth.com [87.117.228.107]
over a maximum of 30 hops:

[snip]

  4    46 ms    70 ms    21 ms  asd-tr0610-cr101-ae6-0.core.as9143.net [213.51.158.82]
  5    88 ms    78 ms    83 ms  ae5-125.ams29.ip4.gtt.net [77.67.64.65]
  6    28 ms    36 ms    37 ms  xe-7-2-1.lon25.ip4.gtt.net [141.136.107.38]
  7   139 ms   125 ms    58 ms  iomart-gw.ip4.gtt.net [46.33.94.2]
  8    73 ms    87 ms    75 ms  610.net2.north.dc5.as20860.net [62.233.127.182]
  9    67 ms    71 ms    28 ms  87.117.212.42
 10    48 ms    27 ms    21 ms  eu.newerth.com [87.117.228.107]

由此我们可以看出第 7 跳存在问题，因为 3 次往返时间中有两次比预期的要长与任一侧的跳数相比。这可能表示网络拥塞或路由器过载：

  7   139 ms   125 ms    58 ms  iomart-gw.ip4.gtt.net [46.33.94.2]

现在尝试路径平至 eu.newerth.com。

Pathping 是一个基于 TCP/IP 的实用程序（命令行工具），它提供有关中间跳网络延迟和数据包丢失的有用信息源地址和目标地址之间。

它通过 ICMP 发送“回显请求”数据包并分析结果来实现这一点。

以下是我的计算机的输出（删除了前几个跳数）：

Tracing route to eu.newerth.com [87.117.228.107]
over a maximum of 30 hops:

[snip]

  3  hlo-lc0001-cr102-ae10-218.core.as9143.net [213.51.166.82]
  4  asd-tr0610-cr101-ae6-0.core.as9143.net [213.51.158.82]
  5  ae5-125.ams29.ip4.gtt.net [77.67.64.65]
  6  xe-7-2-1.lon25.ip4.gtt.net [141.136.107.38]
  7  iomart-gw.ip4.gtt.net [46.33.94.2]
  8  610.net2.north.dc5.as20860.net [62.233.127.182]
  9  87.117.212.42
 10  eu.newerth.com [87.117.228.107]

Computing statistics for 250 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address

[snip]

                                0/ 100 =  0%   |
  3   46ms     0/ 100 =  0%     0/ 100 =  0%  hlo-lc0001-cr102-ae10-218.core.as9143.net [213.51.166.82]
                                0/ 100 =  0%   |
  4   53ms     0/ 100 =  0%     0/ 100 =  0%  asd-tr0610-cr101-ae6-0.core.as9143.net [213.51.158.82]
                                0/ 100 =  0%   |
  5   39ms     0/ 100 =  0%     0/ 100 =  0%  ae5-125.ams29.ip4.gtt.net [77.67.64.65]
                                0/ 100 =  0%   |
  6   60ms     0/ 100 =  0%     0/ 100 =  0%  xe-7-2-1.lon25.ip4.gtt.net [141.136.107.38]
                                0/ 100 =  0%   |
  7   73ms     0/ 100 =  0%     0/ 100 =  0%  iomart-gw.ip4.gtt.net [46.33.94.2]
                                0/ 100 =  0%   |
  8   56ms     1/ 100 =  1%     1/ 100 =  1%  610.net2.north.dc5.as20860.net [62.233.127.182]
                                0/ 100 =  0%   |
  9   56ms     1/ 100 =  1%     1/ 100 =  1%  87.117.212.42
                                0/ 100 =  0%   |
 10   50ms     0/ 100 =  0%     0/ 100 =  0%  eu.newerth.com [87.117.228.107]

Trace complete.

由此我们可以看出跳数 8 和 9 存在问题，因为这些跳数上有 1% 的数据包丢失，但没有转发数据包丢失。这意味着第 8 跳和第 9 跳的路由器可能有点过载：

  8   56ms     1/ 100 =  1%     1/ 100 =  1%  610.net2.north.dc5.as20860.net [62.233.127.182]
                                0/ 100 =  0%   |
  9   56ms     1/ 100 =  1%     1/ 100 =  1%  87.117.212.42

你说 ”这不会影响来自欧洲的球员“。我在欧洲（NL）。从上述分析来看，如果我玩这个游戏，我预计会看到与您相同的问题，其他使用伦敦服务器的欧洲用户也会遇到同样的问题。

最后三个跳转都属于 iomart.com（一家云托管公司），因此任何问题似乎都发生在其基础设施内部。

结论：

62.233.127.182 和 87.117.212.42 处的路由器可能有点超载（容量不足以处理实际流量）。

警告：

这是一个快照分析。它也没有考虑到反向路线：

互联网上的任何连接实际上都依赖于两条路由：从源到目标的路由，以及从目标返回源的路由。

  • 这些路线可能（并且通常是）完全不同（“不对称”）。
  • 如果它们不同，则连接问题可能是到目标的路由存在问题，或者从目标返回的路由存在问题。
  • Pathping 输出中反映的问题实际上可能并不在于跟踪中明显的系统；而可能是位于从跟踪看来是问题原因的系统返回的反向路径上的某个其他系统。
  • 反向路径本身在正常的 Pathping 输出中完全不可见！

A松散源路由可用于查看反向路由。不幸的是，源路由极有可能被滥用，因此大多数网络管理员都会在边界路由器上阻止所有源路由数据包。因此，实际上，松散的源路由不会起作用。

因此，为了排除反向路由故障，必须从游戏服务器执行 pathping 回到您的公共 IP 地址。

相关内容