現在、友人のLANのネットワーク問題を調査中です（また）。インターネット接続は非常に遅く、信頼性が低く、サービスがまったく機能しないこともあります。
Wireshark を使用して、しばらくの間トラフィックを監視してきました。ついに、再現可能な問題、つまり機能しないgit pullオーバーヘッドに遭遇しました。Wireshark ログは次のようになります。sshgit pull
TCP 再送信は、キー交換が開始されると常に開始されます。サーバーが私のマシンからパケットを受信していないか、私のマシンがその応答を受信していないかのどちらかです。この原因は、LAN の他のすべてのネットワークの問題の原因でもあるような気がします。
私が思いついたことの 1 つは、パケット長が1514で、フラグメント禁止ビットが設定されていることです。ただし、LAN ルーターは の MTU に設定されています1492。 より大きい MTU にルーターを設定することはできません1500。パケットが大きすぎてルーターでスタックしている可能性がありますか?
また、主に安全な接続 (https、ssh) が影響を受けるようですが、それらでも常に大きなパケット サイズが必要になる可能性があります。
実は、私はネットワークの経験があまりないので、経験豊富な皆さんなら、このことをもっと理解できると思います。
編集: 今のところ、 はgit pull再び正常に動作しています。MTU 構成が問題の原因ではないはずです...
答え1
「フラグメント化しない」と設定された大きなパケットは正常です。これは、OS が MTU 検出を実行する方法です。ネットワークがパケットを静かにフラグメント化できるようにする代わりに、ICMP の「フラグメント化が必要」エラーが返されることを期待します (正しい MTU になります)。
大きなパケットが再送信されている場合は、中間のルーターの設定が誤っており、ICMP エラー パケットをブロックしているか、必要なときに送信していないことを意味します。
答え2
重複したACKが発生すると思いますのみ受信側がシーケンス番号のギャップを見つけた場合、パケットが途中でドロップされたことを意味します。したがって、問題は 192.168.0.8 からリモート サーバーへの方向で始まります。数回の再送信にもかかわらず、ACK (重複 ACK さえも) が返ってこないという事実は、おそらくその方向で何かが完全に間違っていることを意味します。(リモート側が送信できないことを意味する可能性がありますが、これは前の重複 ACK とも、後の FIN-ACK とも一致しません。つまり、1 つの問題ではなく 2 つの問題があることになります。)
ここにいくつかのアイデアがあります:
- 接続が不良な公衆 Wi-Fi または 3G 経由の場合、短時間に 100% のパケット ドロップが発生する可能性があります。同時に別のサービスを使用して、そのサービスも停止の影響を受けていないかどうかを確認してください。
- プロトコル対応のファイアウォールでは、特定の接続でパケットをドロップするかどうかを決定する前に、ユーザーの行動を把握するのに少し時間がかかる場合があります。友人はオフにできる特殊なファイアウォールを実行していますか? ISP には使用規則がありますか?
- ドライバーを更新するか、Linux ライブ CD から起動して、同じことが起こるかどうかを確認してください。他のサービスを使用して接続の他の側面を変更し、問題の原因を絞り込んでみてください。