TRACERT问题,始终如一地完成具体步骤


1

我已经在同一家互联网提供商(ZoomInternet)工作了几年。这是一个相对较好的体验,服务通常都很好。

然而,在过去的2或3天里,我玩过一些游戏时出现了明显的延迟问题。例如,WGT是一种高尔夫游戏,每次射击后加载新图像所需的时间大大增加。我经常落后于Agario,有时完全失去联系。这些都不是3天前发生的。

所以,我做必须的计算机/调制解调器/路由器重置。在整个9码内释放/更新我的IP。我总是认为这是我。但是,我没有在一周内安装任何新软件,我找不到任何指向我的问题。由于这种情况发生在我追踪的每个网站上,我倾向于倾向于“这不是我这个时间”的方向。

当我将一个tracert运行到WGT游戏服务器(或者Agar.io甚至是yahoo.com)时,我会在完全相同的位置获得超时。第3步和第4步。

这是我完成的一些痕迹的截图TraceRt截图

在过去的第3步和第4步中,这一直持续超时。步骤5中的209 IP是印第安纳波利斯的数据中心。在Zoom和Indy IP之间出现问题。

所以支持人员让我跟踪armstrongonewire.com(特别是他们的主干)。在他告诉我杀死它之前,我在12个步骤中得到了大约10次超时。就像所有其他痕迹一样,我点击了第2步,然后就从那里开始了。

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

我已经运行了多年的跟踪,包括之前的WGT跟踪,以及通常在没有问题的情况下解决的所有步骤。现在我似乎无法完成每一步完全解决的任何服务器的整个行程。我打电话给BS这个“没有配置回应”的解释。似乎不合法。你们有什么感想?

我正在下载WinMTR以获得第二意见,但我确定ISP(或其提供商)的某些事情已经出现,并且他们并未对此问题提前或未知。

这是我的MTR成绩:http//vvcap.com/Ak0yyHjoT09

有没有人听说过'骨干'服务器(或任何大规模网络)被专门配置为不发送对跟踪或ping的响应?

谢谢。


2
“支持者”说的是实话。如果真的超时,你永远不会到达目的地。看到超时的情况并不少见
Keltari 2016年

这并没有真正回答我的问题。我知道它已经到了那里。我仍然可以玩游戏。我想要确定的是“某些服务器未配置为响应跟踪”是否有任何道理。我认为这是BS的解释,并且与我之前看到的不一致。根据我发布的痕迹,这显然不在我身上。我正在打他们的骨干,但它在某个地方的骨干中迷路了,他们不会承认它。他们要我叫“游戏公司”。我不会打电话给世界上的每个网站。
J. Young

这些跳不是超时,它们没有响应,这有时是正常的...基本上它们被设置为不向你返回ping。这里的问题似乎是一个很长的延迟,你的运营商将他们的流量交给Zayo ......完全不在你手中。除非您的运营商网络运营是完整的baffoons,他们知道存在问题,只是在纠正之前购买时间。
acejavelin 2016年

@acejavelin好的,这是我从一开始就想到的。但我不知道你实际上可以设置服务器不返回响应,所以当他说我觉得我得到了BS'ed。这回答了我的问题。等一下我猜是吗?令人震惊的是,他们似乎没有看到任何错误。显然有些东西。谢谢。
J. Young

当tracert进入Zoom的网络时,我试着追踪到那个armtrongonewire主机,在任何地方都没有响应。此外,在进入该网络之前,我看到了大量的数据包丢失。imgur.com/L9CQ03G所以显然有些问题,它可能在您的ISP网络之外,只是勉强。
acejavelin 2016年

Answers:


0

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

但是,是的,这很有可能,因为这些诊断工具发送和期望的数据包与常规数据包完全相同。他们不会尝试使用与Web浏览器相同的TCP-port-80连接。


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

  • 还有一些其他ICMP数据包不是很有用,例如“Redirect”甚至是旧的“Source Quench”(易于滥用)。即使是相同的Ping / Echo也有被用作Ping of Death对抗各种错误网络堆栈的历史。

    因此,到目前为止,许多系统管理员都配置了所有传入ICMP数据包的总体块,相信这会使他们的网络更加安全。

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

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

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


对于Traceroute,它没有专用的消息或协议,实际上它依赖于错误回复。确切的实现方式各不相同 - 在Windows上,tracert命令发送ICMP Echo数据包,而Linux traceroute工具的大多数变体都通过UDP发送垃圾(尽管也可以执行ICMP)。但常见的部分是他们发送的数据包具有较小的,增加的“生存时间”,即“跳数”限制,期望路径中的每个路由器都以ICMP“超时生存”错误回复。大多数操作系统默认都这样做。

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

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

并且一些路由器确实关闭了ICMP错误,可能是为了减少负载或避免由慢速主CPU处理数据包,否则它们将被快速专用硬件转发。


所以最后,并不是“某些路由器没有设置回答”,而是“ 设置为不回答 ”traceroute消息。

(我无法回答为什么有时会mtr工作但没有调用traceroute。初看起来,它确实使用与traceroute相同的方法,但我没有深入研究它。)


这是很好的信息。感谢您抽出宝贵时间来解释它。
J. Young
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.