tracerouteでのパケット損失は、速度調整の兆候ですか？
この接続には、ウェブページのタイムアウトや遅い転送速度などの深刻な接続の問題があります。 USBモデム（Huawei E303c）を使用してアクセスしているワイヤレスHSDPA接続です。
mtr google.comを実行すると、次の出力が得られます。
そのIPからの高いパケット損失は、ISPが速度を抑制して接続を妨げようとしていることを示していますか？このパケット損失はISP側からのエラーですか、それともこれらのタイプのネットワークが実装される通常の方法ですか？
編集1：この投稿は問題についてあまり明らかにしていないので、次の投稿は ここ
編集2：mtr traceroutesの分析を読んでいるときに、 このページ と書かれています：
後続のホップに持続しない1つのホップへのパケット損失がある場合、損失はICMP制限によって引き起こされます。
いいえ。そのIPは、ローカルでICMPエラーを生成するというお粗末な仕事をしているだけです。証拠は、それを過ぎたポイントがうまく応答するということです。その点に本当に何か問題があったとしたら、それ以降のすべても悪いでしょう。
ルーターはルーティング用に最適化されています。コアルーターは、高度に最適化されたハードウェア経路でトラフィックを通過させます。ただし、ローカルでトラフィックを生成する必要がある場合は、プロセスレベルにディスパッチする必要があります。また、プロセスレベルで実行されるルーティングタスクが優先されます。そのため、遅延したり、信頼性が低下したりすることがよくあります。
パスの信頼性やスループットについては何の意味もありません。
そのIPからの高いパケット損失は、ISPが速度を抑制して接続を妨げようとしていることを示していますか？
スロットリングの兆候かもしれませんが、私が見ていることから、パケット損失が発生している場所に基づいて、それが当てはまるとは思えません。しかし、それが断続的でなく、継続的に発生している場合、そのような高いパケット損失は正常ではありません。読む。
このパケット損失はISP側からのエラーですか、それともこれらのタイプのネットワークが実装される通常の方法ですか？
「これらのタイプのネットワークが実装される通常の方法」は、ここで表示および共有しているものの最も簡単な説明です。覚えておいてください：インターネットは最初に回復力があるように構築されており、「損傷」が発生したときに速度が後回しになります。
とは言うものの、consistent79％のパケット損失は通常からはほど遠いです。ここ米国で同様のmtr Tracerouteを実行した場合、明確な問題がない限り、そのようなロードバンプ/パケットロスの「ブラックホール」は実際にはありません。
mtr Tracerouteの出力を見ると、（115.255.253.17）で問題が発生しているIPは、ISPの段階をはるかに超えているようで、より大きなインターネットの一部と見なすことができます。したがって、ISPベースのスロットリングではないかと思います。特に、mtr Tracerouteは、ISPに接続されているように見えるISPの.bol.net.inスイッチ（59.180.210.201および59.180.210.202）を過ぎて問題が発生していることを示しているようです Mahanagar Telephone Nigam Limited（MTNL） 。
115.255.253.17のGeoIPデータを掘り下げると、それがムンバイのマハラシュトラに拠点を置くIPアドレスであることがわかります。それで、あなたが見ることができるのは、ムンバイ自体のインターネットの一部で起こっているインターネットの停止/「しゃっくり」ですか？また、同じIPアドレス115.255.253.17でwhoisルックアップを介してさらに掘り下げると、それが Reliance Group の一部であることがわかります。これは、インドでより大きなインフラストラクチャプロバイダーのようです。
私に言わせれば、バックボーンインフラストラクチャプロバイダーが、このような特定の低レベルのサブスクライバーネットワーク上のユーザーからのトラフィックを抑制しているのではないかと思います。 Mahanagar Telephone Nigam Limited（MTNL）のシステムのすべての人が、リライアンスグループのバックボーンネットワークによってこのように罰せられるべきなのはなぜですか？ .bol.net.inスイッチからのホップなど、直接のスイッチからの最初の数ホップでこの損失が発生した場合は、スロットルと見なします。
ここ米国での私の観点から、私はこれを通常の断続的なインターネットの一時的な中断にまでチョークで書きます。そして、mtr Tracerouteが完了したという事実は、これらの問題を回避するためのインターネットの回復力に起因する可能性があります。それ以上でもそれ以下でもない…でない限り、この状態は断続的ではなくではなく一貫性;その場合、何か奇妙なことが起こっており、エンドユーザーの側からそれを診断する簡単な方法はありません。
とはいえ、私はただ インドのネット中立性の概念を読んでください そしてインドにはネット中立性を管理する法律がないようですので、リライアンスグループが意図的に何かをしていることを知っています。しかし、正直なところ、私の本能は、誰かが誤ってどこかでデータスイッチを誤って構成しただけであり、あなただけが気付くということです。ですから、私は心を開いて、このmtr TracerouteをMahanagar Telephone Nigam Limited（MTNL）の技術サポート担当者と共有して彼らの発言を確認することをお勧めします。
10回のうち9回、コンピューターの間違い、そして正直なところ多くのことは、悪意ではなく無能に基づいています。ここ米国の技術インフラストラクチャで奇妙なことが起こっているのを見たので、これをISPに報告して、彼らがどのように反応するかを確認する価値があります。