解释这些 traceroute 命令的输出

解释这些 traceroute 命令的输出

当我从新西兰玩游戏时,我发现与英雄联盟 OCE 服务器(澳大利亚)的 ping 值异常高(~180ms),因此我对该服务器的 IP 进行了跟踪路由。

有人能提供一些关于问题可能原因的见解吗?我尝试联系我的 ISP,但他们似乎“检查了线路”,没有发现问题,而且没有提供任何帮助。同样不寻常的是,这种情况专门发生在英雄联盟 OCE 服务器上(NA 服务器大约 250 毫秒,这是典型的情况),至于在澳大利亚托管的其他服务器/游戏,我大约 30 毫秒。

以下是 OCE 和 NA 服务器的 tracert 输出。

OCE 服务器 tracert 输出:

OCE 服务器 tracert 输出

NA 服务器 tracert 输出:

NA 服务器 tracert 输出

答案1

网络上的路由可能不对称 – 互联网是一个网格,您的请求可能通过一组 ISP 和运营商,然后通过另一组返回。而且您无法使用 实际看到返回路由traceroute,除非您也有某种方法从另一端运行它。

(有些公司有特殊的“窥镜”网页,您可以在其中输入自己的 IP 地址,然后让 ISP 的系统运行跟踪路由回到您身边 - 但不幸的是 Riot Games 没有这个功能。)

此外,每一个跳数将自行选择将回复发送到何处:Telstra 返回到您的 ISP 的 Traceroute 响应采用较短的路径,但来自 VOCUS 或 Megaport 的响应采用较长的路径。因此突然跳跃和向下沿途的延迟。

这可能是因为您的 ISP故意地使得通常最短的路径看起来比其他路径更长——也许它想将入站流量从与运营商 A 的过载(或昂贵)连接转移到与运营商 B 的未充分利用的连接。

例如,当查看 Megaport 时“镜子“网页上,返回 Compass 的路径可以是 1 跳通过 VOCUS,或 1 跳通过 Devoli,或 2 跳通过 Spark 然后 Voyager。然而,这两条“短”路线故意显得更长,这样就会采用“长”的 Spark→Voyager→Compass 路线。这很可能会使延迟增加 2 倍或 3 倍。

(请注意,我只是根据网上的各种按钮做出这个猜测,并没有真正的办法知道你的数据包为什么真的走这条路还是那条路——我不是为他们工作。因此,这很可能是完全的垃圾。)

相关内容