TRACERT 问题,特定步骤持续超时

TRACERT 问题,特定步骤持续超时

我已经使用同一个互联网提供商 (ZoomInternet) 好几年了。体验相对较好,服务一般都很好。

然而,最近两三天,我在玩一些游戏时遇到了明显的延迟问题。例如,WGT 是一款高尔夫游戏,每次击球后加载新图像所需的时间大大增加。我在玩 Agario 时经常出现延迟,有时会完全断网。三天前都没有发生过这些情况。

因此,我按要求重置了电脑/调制解调器/路由器。释放/更新我的 IP。我总是认为是我的问题。但是,我已经一个星期没有安装任何新软件了,也找不到任何指向我的问题。由于我跟踪的每个站点都发生这种情况,所以我倾向于认为“这次不是我的问题”。

当我对 WGT 游戏服务器(或 Agar.io 甚至 yahoo.com)运行 tracert 时,我在完全相同的位置遇到超时。步骤 3 和 4。

下面是我做过的一些跟踪的截图:TraceRt 截图

在过去几天里,步骤 3 和步骤 4 一直出现超时。步骤 5 中的 209 IP 是印第安纳波利斯的一个数据中心。Zoom 和该 Indy IP 之间的某个地方出了问题。

因此支持人员要求我跟踪 armstrongonewire.com(特别是在他们的主干中)。在他告诉我终止它之前,我在 12 个步骤中遇到了大约 10 次超时。我像所有其他跟踪一样顺利地执行了第 2 步,然后它从那里开始变得糟糕。

然后那个人继续告诉我,主干网上的“某些”服务器没有设置为返回对跟踪的响应。我以前从未听说过,所以这让我很困惑。如果服务器没有响应,我的计算机如何知道数据已经到达那里?如果没有响应,它不是会一直发送直到重试超时吗?

我已经运行跟踪多年了,包括之前对 WGT 的跟踪,所有步骤通常都能顺利解决。现在我似乎无法在每个步骤中完全解决对任何服务器的整个行程。我认为这个“未配置为响应”的解释是胡说八道。似乎不合法。你们觉得呢?

我正在下载 WinMTR 来获取第二意见,但我确信 ISP(或其提供商)出了问题,而他们并没有提前告知或没有意识到这个问题。

这是我的 MTR 结果:http://vvcap.com/Ak0yyHjoT09

是否有人听说过“主干”服务器(或任何大型网络)被专门配置为不发送对跟踪或 ping 的响应?

谢谢。

答案1

免责声明:我不是这方面的专家,所以......请指出我写的任何废话。

但是,是的,这是很有可能的,因为这些诊断工具发送和期望的数据包不是和常规数据包完全一样。它们不会像 Web 浏览器那样尝试建立相同的 TCP 端口 80 连接。


ping命令很简单 - 它发送 ICMP“Echo”数据包(专用于此目的),并期望目标发出 ICMP“Echo Reply”响应。由于 ICMP 本身也用于报告连接错误,因此大多数操作系统已经内置了对响应 Echo 请求的支持,但是...

  • 还有一些其他 ICMP 数据包不太有用,例如“重定向”或甚至旧的“源抑制”(容易被滥用)。即使是相同的 Ping/Echo 也有被用作死亡之平针对各种有缺陷的网络堆栈。

    因此,至今许多系统管理员仍会配置全部传入的 ICMP 数据包,相信这将使他们的网络更加安全。

    有时它们甚至会阻止传出的 ICMP 数据包,这会破坏 Traceroute 以及其他功能(例如 MTU 发现)。(我的意思是,这显然他们的网络和他们的业务,但是......啊。)

  • 尽管 Windows 不常用于路由器,但它可能仍然是最常见的例子——自从 Windows XP SP3 以来,内置防火墙默认会丢弃所有传入的 Echo 请求。

(几乎所有防火墙都允许您根据源地址和/或目标端口等有选择地过滤 TCP 和 UDP 数据包。因此,防火墙可以通过 TCP 但阻止 ICMP 也就不足为奇了。)


至于 Traceroute,它没有专用的消息或协议,事实上它依赖错误回复。确切的实现各不相同 - 在 Windows 上,该tracert命令发送 ICMP Echo 数据包,而 Linuxtraceroute工具的大多数变体则通过 UDP 发送垃圾信息(尽管也可以执行 ICMP)。但共同点是它们发送的数据包具有较小的、不断增加的“生存时间”(又称“跳数”)限制,期望路径中的每个路由器都回复 ICMP“生存时间已超出”错误。大多数操作系统默认这样做。

但是,有些系统设置了防火墙来悄悄丢弃 ICMP Echo 数据包,因此它们不会发回任何错误消息。(在这种情况下,过滤似乎仅适用于路由器本身处理的数据包,而不适用于它只是转发的数据包。)

一些其他系统设置了防火墙来专门阻止传出的 ICMP 错误。老实说,我不知道为什么,但我见过这种情况。

还有一些路由器关闭 ICMP 错误生成本身,可能是为了减少负载或避免数据包被缓慢的主 CPU 处理,否则它们将由快速的专用硬件转发。


所以说到底,并不是“有些路由器没有设置为应答”,而是它们“设置为不接听“跟踪路由消息。

(我真的无法回答为什么有时mtr有效但没有调用traceroute有效。乍一看,它确实使用了与 traceroute 相同的方法,但我还没有深入研究它。)

相关内容