クライアントがSYN、ACKへの応答としてRSTパケットを送信するのはなぜですか？
HTTP Webサービスを使用していますが、接続のセットアップが奇妙な方法で失敗することがあります。
- クライアントがSYNパケットを送信する
- サーバーがSYN、ACK応答を送信する
- クライアントはRSTで応答します
クライアントシステムがRSTパケットで応答することを決定できるのはどのような場合ですか？これは、SYN、ACKに次のものが含まれているときに発生すると想像できます。シーケンス番号が正しくありません（ただし、これは私の場合には適用されないようです-シーケンス番号は問題なく見えます）。だから私は、クライアントがSYN、ACKパケットを受信した後にRSTパケットを送信するケースの完全な:-)リストに興味があります。
特に、クライアントアプリケーションコード（Linuxで通常のBSDスタイルのソケットAPIを使用）がこのRSTパケットを引き起こす可能性はあります。 3ウェイハンドシェイクがまだ進行中にclose()を呼び出すことによって？
閉鎖の場合：問題は私のコード（クライアント内）の愚かなバグでした。
この場合のクライアントはノンブロッキングソケットを使用するため、カーネルがサーバーからのSYN、ACKパケットを待機している間、connect()呼び出しはすぐに返されます。残念ながら、クライアントコードは非常にせっかちでした。接続が数百ミリ秒後に確立されなかった場合、クライアントはソケットでclose()を呼び出します。
一部のまれなケースでは、サーバーからのSYN、ACKパケットが、ネットワークを経由する途中で数百ミリ秒遅れることがあります。遅延した応答が最終的にクライアントのホストに到着すると、カーネルはソケットがすでに閉じていることを確認し、SYN、ACK応答を無効なソケットに属するものとして扱います。そのため、サーバーにRSTパケットで応答します。
そのため、はい、アプリケーションコード（Linuxで通常のBSDスタイルのソケットAPIを使用）がこのRSTパケットを引き起こす可能性があります。非ブロッキングソケットを使用し、3ウェイハンドシェイクがまだ進行中に接続を閉じることによって。