Traceroute中丟包是速度限制的標誌嗎?

Traceroute中丟包是速度限制的標誌嗎?

此連線有嚴重的連線問題,例如網頁逾時和傳輸速度慢。我使用 USB 數據機(華為 E303c)存取它的無線 HSDPA 連接。

執行mtr google.com給出以下輸出:

追蹤路由輸出

該 IP 的高資料包遺失是否表明我的 ISP 正在嘗試限制速度並阻止連線?這種封包遺失是 ISP 方面的錯誤還是這是此類網路實施的正常方式?

編輯 1:由於這篇文章沒有透露太多有關該問題的信息,所以下一篇文章是這裡

編輯2:在閱讀分析mtr追蹤路由時,我發現這一頁。它說 :

當一跳發生丟包且不持續到後續跳躍時,丟失的原因是ICMP 限制。

答案1

不。事實證明,超過它的點反應良好。如果那一點真的出了問題,那麼過去的一切也會很糟糕。

路由器針對路由進行了最佳化。核心路由器讓流量以高度優化的硬體路徑通過它們。然而,當他們必須在本地生成流量時,必須將其分派到進程層級。在流程層級發生的任何路由任務都具有優先權。所以它經常被延遲或不可靠。

它並不意味著路徑的可靠性或吞吐量。

答案2

該 IP 的高資料包遺失是否表明我的 ISP 正在嘗試限制速度並阻止連線?

這可能是節流的跡象,但從我所看到的情況來看,我懷疑是否是基於丟包發生位置的情況。但如果它不是間歇性的並且持續發生,那麼像這樣的高丟包率就是不正常。請繼續閱讀。

這種封包遺失是 ISP 方面的錯誤還是這是此類網路實施的正常方式?

「此類網路的正常實現方式」是您在這裡看到和分享的內容的最簡單的解釋。請記住:網路首先是為了有彈性而建構的,當遇到「損害」時,速度就退居二線。

也就是說,一個持續的79% 丟包率是遠非正常。如果我mtr在美國進行類似的 Traceroute,除非有明顯的問題,否則實際上不會出現這樣的道路顛簸/封包丟失「黑洞」。

查看您的mtrTraceroute 輸出,您看到 ( ) 問題的 IP115.255.253.17似乎已經遠遠超出了 ISP 階段,可以被視為更大互聯網的一部分。所以我懷疑是ISP的限流。特別是因為您的 Traceroute 似乎mtr顯示問題發生在您的 ISP.bol.net.in交換器 (59.180.210.20159.180.210.202) 上,這些交換器似乎已連接到 ISPMahanagar 電話 Nigam 有限公司 (MTNL)

深入研究 GeoIP 數據115.255.253.17表明,這是位於孟買馬哈拉施特拉邦的 IP 位址。那麼您可能會看到孟買本身的部分互聯網發生了互聯網中斷/“打嗝”?透過whois查找相同 IP 位址進行進一步挖掘115.255.253.17表明它是信實集團,這似乎是印度較大的基礎設施提供者。

如果你問我,我懷疑骨幹基礎設施供應商會像這樣限制來自特定較低級別訂戶網路上的用戶的流量。為什麼 Mahanagar Telephone Nigam Limited (MTNL) 系統上的每個人都要受到 Reliance Group 主幹網路的這種懲罰?如果您在直接交換器的前幾跳(例如來自交換器的那些跳)周圍看到這種損失,我會認為它受到限制.bol.net.in

從我在美國的角度來看,我會把這歸因於正常的、間歇性的網路故障。您的 Traceroute 完成的事實mtr可以歸因於互聯網解決這些問題的彈性。不多也不少…除非這個條件是不間歇反而持續的;如果是這種情況,則表示發生了一些奇怪的事情,並且沒有簡單的方法可以從最終用戶的角度進行診斷。

說了這麼多,我只是了解印度網路中立的概念印度似乎沒有管理網路中立性的法律,所以據你所知,信實集團正在故意做一些事情。但老實說,我的直覺是,有人只是無意中在某處錯誤配置了數據交換機,而您是唯一注意到的人。因此,我傾向於持開放態度,建議mtr與 Mahanagar Telephone Nigam Limited (MTNL) 的技術支援人員分享此 Traceroute,看看他們怎麼說。

電腦上的錯誤(老實說,很多事情)十有八九不是源自於惡意,而是源自於無能。我在美國的技術基礎設施中看到過更奇怪的事情,因此值得嘗試向您的 ISP 報告此情況並看看他們如何回應。

相關內容