この報告された1時間のping時間はいったいどうして本当なのでしょうか？

私は最近、イースターバンクの休日を両親と過ごしました。両親は英国の非常に田舎に住んでいます。彼らは（ひどい）ADSLインターネット接続を持っています。これは数キロメートルの危険な銅線上で実行され、近くの農民がトラクターを電話回線に戻すと定期的に中断されます。

ルーターが繰り返しpptpハンドシェイクをドロップし、再ネゴシエートして、接続を効果的に切断していることに気付きました。これはイライラさせられました。だから、気が狂うのを避けるために、最低許容SNRマージンを2倍にし、低速でハンドシェイクするように指示しました。

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

これにより問題が改善され、信じられないほど遅いものの、外界へのパイプが（ある程度）安定したものになりました。

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

この時点で、実際の生活に介入し、猫と遊んだり、携帯電話で猫のgifを見たり、実際に家族と話したりするなど、数時間を費やしました 。このpingプロセスを実行したままにしておくと忘れてしまいました1日後にヒットするctrl-c。

示されている要約統計は私を床に落としました：

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

ご覧のとおり、GoogleのDNSサーバーへの大西洋横断ホップを短くするICMPパケットの最大記録応答時間は3600577.732 msです。これはほぼ正確に1時間で、pingデフォルトのタイムアウトよりもはるかに長くなります。

これは一体どうなるのでしょうか？ある正確な？パケットを送信する前に60分間パケットを保持するルーターは何ですか？このパケットがドロップされなかったのはなぜですか？8ビットのパケットカウンターからのオーバーフローと大きなレイテンシの組み合わせの結果ですか？

最後に、消費者ADSL接続は、RFC 1149およびRFC 2549よりも遅延が少なく、トラフィック管理が優れていると予想されるという英国の行動規範があるかどうかを知りたいと思います ;-)。

ICMPパケットとpingの応答はそれぞれ32バイト長であるため、1時間のpingの場合、すべてのバイトが送信に1分近くかかっていたようです。

これは、非常に寛大なエラー再試行回数（あなたのやっている？）と、非常に遅いルーターと、送信されるバイトごとの痛みを伴う待機または再試行によってのみ説明できます。

インターネットプロトコル（IP）は、データグラムによってデータを送信し、部分的なデータグラムを送信しないようにします。送信が開始されると、データグラムにさらにバイトが追加されるのをデフォルトで200ミリ秒待機します。その時間を過ぎると、ソフトウェア/ファームウェアは、それが持つすべてのものを1つのデータグラムとして送信します。1時間のping時間の場合、パケットペイロードは1バイトと小さい場合があります。データがまだ到着している限り、接続は参加している2つのサイドによって終了されません。

できること：

• 他の電話、ファックス、またはその他のデバイスが同じ電話回線に接続されている場合、それらがDSLフィルターで保護されているかどうかを確認します。DSLモデムに向かう回線にフィルターをかけないでください。
• 別のルーターを試してください-悪いデバイスを手に入れたら、それを捨ててより良いものを手に入れる以外に、それに対してできることはまったくありません。
• 他のルーターが利用できない場合は、ISPに連絡してください-ISPから便利なテストを実行できます。
• ISPが何も見つからない場合は、とにかく交換用のルーター/モデムを要求してください。
• 別のルーターで同じ問題が発生する場合は、電話会社に連絡してください。

問題のあるスイッチを見つけることは、電話会社の場合と同様に非常に複雑ですが、ISPにも独自のスイッチがある場合があります。通常、スイッチの問題はエリア全体で発生し、誤動作しているスイッチの特定に役立ちます。しかし、あまり多くの加入者がそのスイッチを使用していない農村地域では、これは検出されない可能性があります。一部のネイバーが同じISPを使用している場合、それらの接続がどのようなものであるかを確認してください。

このケースはデータ輻輳管理に非常に関連していると思いますが、理由は何であれ非常に悪い管理されたケースです。私の理解では、伝送システムにはパケットバッファがあり、管理が不十分であるため、ICMPエコー要求/応答パケットにこの異常が発生します。

したがって、悪い輻輳管理ポリシーを持つことと、何時間もpingセッションを開くことを組み合わせることにより、このような奇妙なシナリオが明らかになる可能性があります。

輻輳管理についての詳細はこちら。