断続的な高ping /遅延の問題
私はISP（WISP、実際には固定ブロードバンドワイヤレス）と協力して、断続的に高遅延が発生する理由を解明しようとしています。待ち時間は、オンラインゲームやその他のストリーミングアプリケーションで検出できます。トレースルートを実行すると、バックホールネットワークを介したパスを確認できます。
Tracing route to google.com [74.125.67.105]
over a maximum of 30 Hops:
1 1 ms 4 ms <1 ms 192.168.23.1
2 1 ms 8 ms 9 ms 10.100.100.1
3 9 ms 9 ms 3 ms 10.7.37.1
4 15 ms 24 ms 19 ms 10.7.36.1
5 10 ms 79 ms 9 ms 10.7.31.3
6 10 ms 39 ms 39 ms 10.10.5.9
7 19 ms 19 ms 19 ms 10.10.5.5
8 9 ms 19 ms 19 ms 10.10.5.1
9 341 ms 237 ms 226 ms 10.250.200.1
10 249 ms 280 ms 991 ms <ISP WAN IP>
11 703 ms 681 ms 401 ms <ISP WAN IP>
12 819 ms 628 ms 484 ms <AT&T IP> <- Traffic enters AT&T backbone
13 699 ms 528 ms 290 ms <AT&T IP>
14 201 ms 106 ms 52 ms <AT&T IP>
15 624 ms 392 ms 436 ms <AT&T IP>
16 666 ms * 252 ms <AT&T IP>
17 456 ms 403 ms 581 ms 209.85.254.120
18 430 ms 339 ms * 209.85.242.215
19 1061 ms 56 ms 53 ms 72.14.239.131
20 3514 ms 734 ms 219 ms 209.85.255.190
21 49 ms 59 ms 56 ms 74.125.67.105
これは、問題が10.250.20.1のホストであることを示しているようです。ただし、ホストに直接pingを実行すると、すべてが正常に見えます（往復で約10ミリ秒）。疑わしいノードの後に後続のホップをpingすると、妥当なラウンドトリップ時間も得られます。高い遅延は、一度に数秒から数分まで持続する可能性があります。
[〜＃〜] edit [〜＃〜]はい、これは明確な問題を示すトレースの悪い例ですが、テストを繰り返した後、ホップ9の前に100ミリ秒を超える遅延が発生することはありません。それは問題かもしれません。
イベント中のパスにより、次のようになります。
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 192.168.23.129
0/ 100 = 0% |
1 2ms 0/ 100 = 0% 0/ 100 = 0% 192.168.23.1
0/ 100 = 0% |
2 3ms 0/ 100 = 0% 0/ 100 = 0% 10.100.100.1
0/ 100 = 0% |
3 14ms 0/ 100 = 0% 0/ 100 = 0% 10.7.37.1
0/ 100 = 0% |
4 15ms 0/ 100 = 0% 0/ 100 = 0% 10.7.36.1
0/ 100 = 0% |
5 19ms 0/ 100 = 0% 0/ 100 = 0% 10.7.31.3
0/ 100 = 0% |
6 27ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.9
0/ 100 = 0% |
7 28ms 0/ 100 = 0% 0/ 100 = 0% 10.10.5.5
0/ 100 = 0% |
8 --- 100/ 100 =100% 100/ 100 =100% 10.10.5.1
0/ 100 = 0% |
9 25ms 0/ 100 = 0% 0/ 100 = 0% 10.250.200.1
0/ 100 = 0% |
10 24ms 1/ 100 = 1% 1/ 100 = 1% <ISP WAN IP>
0/ 100 = 0% |
11 25ms 4/ 100 = 4% 4/ 100 = 4% <ISP WAN IP>
0/ 100 = 0% |
12 35ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP>
0/ 100 = 0% |
13 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP>
0/ 100 = 0% |
14 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP>
0/ 100 = 0% |
15 --- 100/ 100 =100% 100/ 100 =100% <AT&T IP>
0/ 100 = 0% |
16 58ms 0/ 100 = 0% 0/ 100 = 0% <AT&T IP>
1/ 100 = 1% |
17 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.254.120
0/ 100 = 0% |
18 59ms 1/ 100 = 1% 0/ 100 = 0% 209.85.242.215
0/ 100 = 0% |
19 56ms 1/ 100 = 1% 0/ 100 = 0% 72.14.239.127
0/ 100 = 0% |
20 60ms 1/ 100 = 1% 0/ 100 = 0% 209.85.255.194
0/ 100 = 0% |
21 59ms 1/ 100 = 1% 0/ 100 = 0% 74.125.67.105
この遅延がトレースルート中にのみ表示され、通常のpingでは表示されないのはなぜですか？私のアプリケーションで見られるパフォーマンスの欠如は、これと一致しています。
つまり、アプリケーションで問題が発生しているときに、同時にトレースを実行すると、上記の結果が得られ、同時に疑わしいホストにpingが表示されます。通常のping。
さらにテストした後、これはUDP遅延の問題です。
待ち時間が長く、アプリケーションのパフォーマンスが低いのは、CPUにバインドされたホストのようです。期限切れのICMPパケットTTLは応答を作成するためにCPU時間を必要とするため、ほとんどのルーターは「気が向いたら応答する」ように構成されています。期限切れのTTLICMPトラフィックの遅延はこの場合、ルーターがビジーであることを示しています。ホストはネットワークのエッジにあるように見えるため、すべてのトラフィックの大部分がそのホップを通過しています。
私は、ISPが何らかのトラフィック検査またはUDPプロトコルのシェーピングを行っていることを強く疑っています。これにはCPU時間も必要です。
WISP？意味ワイヤレスISP？もしそうなら、あなたの可能性のある答えがあります。ワイヤレスは信頼性が低く、その証拠が見られます。
あなたの媒体（大気）はデータを送信するのに本当にひどいので、あなたはそれを本当に修正することはできません。 1つ目は、空気がスイッチではなくハブであるため、周囲の人と共有してパケットを衝突させるためです。2つ目は、 CSMA/CA がCSMA/CDよりも遅いため、3つ目は、ワイヤレスが一般的に半分であるためです。全二重ではなく二重であり、4番目は、銅よりも空気を介した干渉が桁違いに大きいためです。 [たとえば、マイクロ波は802.11b/gと同じ波長で動作しますが、マイクロ波はワイヤレスアンテナの100ミリワットに対して約500〜1000ワットで動作します。マイクロ波はシールドされていますが、シールドは完全ではなく、マイクロ波はFCCによって規制されていないため、干渉を引き起こしても違法ではありません。]さらに、インターネットにアクセスするためだけに10回以上のホップを通過しているという事実。特にNATまたはファイアウォールが実行されている場合は、それは役に立ちません。
@dbasnettが言うように、特定のホストへのtraceroute ping遅延は、その時点で全体として取得されたインターフェイス間のネットワーク全体の状態のみを示します。そのため、応答時間がdownになることがあります。ネットワークの信頼性が低いため、スパイキーです。 pathpingが実行しているクエリが3つだけではなく、多数のクエリを実行しているため、tracertは見栄えがします。したがって、pathpingは、ネットワークが325秒（デフォルト）にわたって実行していることを示し、tracertは、ネットワーク上のホップごとに3パケットが実行していることを示します。
10回のトレースルート結果のうち9回は、ネットワークの問題を示すものではありません。 Tracerouteは、送信元と宛先の間の連続する各ホップにICMPエコー要求パケットを送信し、連続するホップごとにTTLを1ずつ増やします。各ホップの結果は、そのホップがどのように応答しているかを示します。 ICMPトラフィックは、そのホップを通過するパスの品質を示すものではありません。ルーターのジョブはトラフィックを転送することであるため、多くの場合、自分宛てのICMPトラフィックを無視、ドロップ、または優先度を低くするようにプログラムされています。ホップ14、19、および21の応答時間が非常に良好であるという事実は、パスに問題がないことを示しています。ホップ12（強調表示したとおり）またはパスに影響を与えていた他のホップに問題があった場合は、連続するすべてのホップで問題が発生し、各ホップが以前よりも悪化します。tracerouteでこれらのタイプの結果が表示された場合にのみ、パスの問題が疑われます。ホップ21が宛先であり、応答時間は59ミリ秒です。との間のパスがウルス川と目的地は大丈夫です。パスの問題を分析するための鍵は、実際のデータが通過している間のパフォーマンスを分析することです。これは、各ホップにパケットスニファ/ネットワークモニターがあり、それぞれのメモリ、CPU、およびスループットカウンターにアクセスできない限り実行できません。送信元から宛先へのパス内のネットワークノード（ルーターとスイッチ）。
パスのtracertに基づいてパフォーマンスの問題が発生する理由を理解しようとするのではなく、送信元と宛先の間の実際のTCPセッションに集中し、応答時間（遅延）を確認する必要があります。これら2つのエンドポイント間のパケット損失。
トレースルートは、その名前が示すように、2つのエンドポイント間のパスを検出するためのツールであり、そのパスの品質を分析するためのツールではありません。
私はjoeqwertyに同意する必要があります。ICMPはずっと前に、パフォーマンス、遅延、またはスループットの信頼できる測定値ではなくなりました。これは、未知のネットワーク上に多くのホップがあるルートに特に当てはまります。
より現実的なテストは、使用しているプロトコルを使用したテストです。たとえば、httpの場合、Wiresharkネットワークパケットキャプチャを設定できます。指定されたホストとの会話をフィルタリングし、Wiresharkの統計> TCPストリームグラフ>ラウンドトリップ時間グラフ]を使用します。このテストは、キャプチャを少なくとも数分間実行すると、より正確になります。
もう1つの興味深いオプションは PingPlotter Standard （無料ではありませんが、30日間機能が完了しています）です。これは、ポート番号を指定することにより、プロトコル固有のスループットテストに非常に優れた機能を提供し、ラウンドトリップ時間のグラフがあり、保存およびロードできます。
Pingとトレースルート（特定のTTLを使用したping）は一時的なものです。ある特定の瞬間に目にするのはそれだけであり、過去または将来の出来事とは何の関係もありません。
インターネットの帯域幅の一部（2％ish）はpingトラフィックです。これは、インターネットバックボーンの人でない限り、実際の目的には役立ちません。問題がある場合は、ISPに連絡してください。