跟踪路由中的数据包丢失是速度受限的迹象吗?

跟踪路由中的数据包丢失是速度受限的迹象吗?

此连接存在严重的连接问题,例如网页超时和传输速度慢。这是一个无线 HSDPA 连接,我使用 USB 调制解调器(华为 E303c)进行访问。

执行mtr google.com后输出如下:

Traceroute 输出

该 IP 的高数据包丢失率是否表明我的 ISP 正在尝试限制速度并阻止连接?这种数据包丢失是 ISP 方面的错误,还是这是此类网络的正常实现方式?

编辑 1:由于这篇文章没有透露太多有关该问题的信息,因此下一篇文章是这里

编辑 2:在阅读有关分析mtr跟踪路由的文章时,我发现这一页。它说 :

如果在某一跳上发生数据包丢失,并且该数据包不会持续到后续跳,则丢失是由于ICMP 限制。

答案1

不。该 IP 在本地生成 ICMP 错误方面做得很差。证据是,超过该 IP 的点响应良好。如果该点真的有问题,则超过该 IP 的所有内容也会很糟糕。

路由器针对路由进行了优化。核心路由器让流量通过高度优化的硬件路径。但是,当它们必须在本地生成流量时,必须将其分派到进程级别。并且在进程级别进行的任何路由任务都会获得优先权。因此,它通常会延迟或不可靠。

它对路径的可靠性或吞吐量没有任何意义。

答案2

该 IP 的高数据包丢失是否表明我的 ISP 正在试图限制速度并阻止连接?

这可能是节流的迹象,但从我看到的情况来看,根据数据包丢失发生的位置,我怀疑情况并非如此。但如果这种情况不是间歇性的,而是持续发生的,那么像这样的高数据包丢失就是不正常.继续阅读。

这个数据包丢失是 ISP 端的错误吗,还是这是此类网络实现的正常方式?

“此类网络的正常实现方式”是对您在此处看到和分享的内容最简单的解释。请记住:互联网的构建首先是具有弹性,当遇到“损坏”时,速度将退居次要地位。

这就是说,持续的79% 的数据包丢失是远非正常。如果我mtr在美国进行类似的 Traceroute,除非存在明显问题,否则实际上不会出现这样的道路颠簸/数据包丢失“黑洞”。

查看您的mtrTraceroute 输出,您看到的问题 IP ( 115.255.253.17) 似乎远远超出了 ISP 阶段,可以视为大型互联网的一部分。所以我怀疑它是基于 ISP 的限制。特别是因为您的mtrTraceroute 似乎显示该问题发生在您的 ISP.bol.net.in交换机(59.180.210.20159.180.210.202)之后,而这些交换机似乎连接到 ISP马哈那加尔电话公司 (MTNL)

深入研究 GeoIP 数据115.255.253.17显示,这是一个位于马哈拉施特拉邦孟买的 IP 地址。那么,您看到的可能是孟买互联网的一部分发生了互联网中断/“故障”?通过查找同一whoisIP 地址进行进一步挖掘115.255.253.17,可以发现它是信实集团,它似乎是印度一家较大的基础设施提供商。

如果你问我,我怀疑主干基础设施提供商是否会像这样限制特定低级用户网络上的用户流量。为什么 Mahanagar Telephone Nigam Limited (MTNL) 系统上的每个人都要受到 Reliance Group 主干网络的这种惩罚?如果你在直接交换机的前几个跳数(例如来自交换机的那些跳数)中看到这种损失,我会认为这是限制.bol.net.in

从我在美国的角度来看,我认为这是正常的、间歇性的互联网故障。而您的mtrTraceroute 完成可以归因于互联网对这些故障的弹性。仅此而已……除非这种情况不间歇反而持续的;如果是这种情况,那么就会发生一些奇怪的事情,而且从最终用户的角度来看,没有简单的方法可以对其进行诊断。

话虽如此,我只是阅读印度网络中立性的概念而且印度似乎没有法律来管理网络中立性,所以据你所知,信实集团是故意在做某事。但说实话,我的直觉是,有人只是无意中错误配置了某个数据交换机,而你是唯一注意到的人。所以我会倾向于保持开放的态度,并建议mtr与 Mahanagar Telephone Nigam Limited (MTNL) 的技术支持人员分享此 Traceroute,看看他们怎么说。

十有八九,电脑上的错误(说实话很多事情)不是出于恶意,而是因为无能。我在美国见过技术基础设施上发生更奇怪的事情,所以值得一试,向您的 ISP 报告此事,看看他们如何回应。

相关内容