TCP Dup ACK / Retransmission、不適切な構成？
私は現在、友人のLANのネットワークの問題を調査しています（ 再び ）。インターネット接続は非常に遅く、信頼性が低く、サービスが機能しない場合があります。
Wiresharkを使用してトラフィックをしばらく監視しました。私はついに再現可能な問題を思いついた。git pull over sshは機能しなかった。 git pullのWiresharkログは次のようになります。
TCP鍵交換が開始されると、常に再送信が開始されます。サーバーが私のマシンからパケットを受信していないか、私のマシンが応答を受信していません。原因を感じています。これは、LANの他のすべてのネットワーク問題の原因でもあります。
私が思いついたのは、ここにあるすべての不良パケットの1514のパケット長ですが、フラグメント化しないビットが設定されていますが、LANルーターは1492のMTU用に構成されています。 1500より大きいMTU用にルーターを構成できません。パケットが大きすぎてルーターでスタックする可能性はありますか？
また、ほとんどの場合、安全な接続（https、ssh）が影響を受けるようですが、それらは常により大きなパケットサイズを必要とする可能性もあります。
ほら、私はネットワーキングの経験があまりないので、もっと経験のある人がこれをもっと理解できることを願っています。
編集：ちょうど今、git pullは再び正常に機能しています。 MTU構成が問題の原因になることはありません...
受信者がシーケンス番号のギャップを検出した場合、つまりパケットが途中でドロップされた場合にのみ、重複したackが発生すると思いますonly。したがって、問題は192.168.0.8からリモートサーバーへの方向から始まります。何度か再送信したにもかかわらず、バックにアックがない（重複したアックさえない）という事実は、おそらく何かがその方向に完全にねじ込まれていることを意味します。 （リモート側が送信できないことを意味する可能性がありますが、それは前の重複ackと後のfin-ackと一致していません。1つではなく2つの問題があることを意味します。）
ここにいくつかのアイデアがあります：
- 接続が悪い公共のwifiまたは3Gを介している場合は、100％のパケットドロップが短時間発生する可能性があります。同時に別のサービスを使用して確認し、停止の影響も受けていないか確認してください。
- プロトコル対応のファイアウォールがあり、特定の接続でパケットをドロップすることを決定する前に、実行していることを理解するのに少し時間がかかる場合があります。あなたの友人は、オフにできるエキゾチックなファイアウォールを実行していますか？ ISPにはいくつかの使用規則がありますか？
- ドライバを更新するか、LinuxライブCDから起動して、同じことが起こるかどうかを確認してください。他のサービスを使用して、接続の他の側面を変更して、問題を絞り込んでください。
「フラグメント化しない」大きなパケットは正常です。これがOSがMTU検出を実行する方法です。ネットワークにパケットを静かに断片化させる代わりに、ICMP「断片化が必要です」エラーが返されることを期待します（正しいMTUがあります）。
大きなパケットが再送信されている場合は、途中のルーターが正しく構成されておらず、ICMPエラーパケットをブロックしているか、必要なときに送信しないことを意味します。