web-dev-qa-db-ja.com

この報告された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ミリ秒です。 これはほぼ正確に1時間であり、確かにpingのデフォルトのタイムアウトよりはるかに長くなります。

一体どうやってこれはどうなるの？ は正確ですか？どのルーターがパケットを60分間保持してから送信しますか？このパケットがドロップされなかったのはなぜですか？これは、8ビットパケットカウンターからのオーバーフローと大きな遅延の結果ですか？

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

networkingroutingadsl
15
Landak

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

これは、非常に寛大なエラー再試行回数（実行中ですか？）と、非常に遅いルーター、および送信されたすべてのバイトに対する苦痛な待機または再試行によってのみ説明できます。

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

あなたができること：

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

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

4
harrymc

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

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

輻輳管理の詳細 ここ 。

0
Tamadite