RSTシーケンス番号とウィンドウサイズ
RFC793は、RST処理について次のように述べています。
SYN-SENTを除くすべての状態で、すべてのリセット（RST）セグメントは、それらのSEQフィールドをチェックすることによって検証されます。シーケンス番号がウィンドウにある場合、リセットは有効です。
しかし、このステートメントが正確に何を意味するのかわかりません。次のシナリオがあるとしましょう。
したがって、ソケット2はソケット1にウィンドウサイズが6 KBであることを通知し、ソケット1は6KB相当のデータをソケット2に送信します。
次に、ソケット1はRSTパケットをソケット2に送信します。
この場合はどうなりますか？RSTパケットはソケット2によって受け入れられますか？
Linuxは、RSTシーケンス番号が次に予想されるシーケンス番号である場合にのみTCP接続を切断します。このルールは、ブラインドTCPリセット攻撃を回避するために適用されました（-を参照）。 RFC 5961セクション3.2 ）したがって、次のルールが適用されます。
1）RSTビットが設定されていて、シーケンス番号が現在の受信ウィンドウの外側にある場合は、セグメントをサイレントにドロップします。
2）RSTビットが設定され、シーケンス番号が次に予想されるシーケンス番号（RCV.NXT）と完全に一致する場合、TCPは接続をリセットする必要があります。
3）RSTビットが設定されていて、シーケンス番号が次に期待されるシーケンス値と正確に一致していないが、現在の受信ウィンドウ内にある場合（RCV.NXT <SEG.SEQ <RCV.NXT + RCV.WND）、TCP確認応答を送信する必要があります（チャレンジACK）：
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
したがって、ケース1の場合、RSTセグメントはサイレントにドロップされます（少なくともLinuxでは、これは実装に依存しますが、尊重する必要があります）。
MTU値を使用したフラグメントメカニズムを使用してすべてのデータがクライアントから宛先に転送されると、RSTではなくFINが開始されます。
- FIN：データ転送が完了し、パケットが残っていません。 （優雅な閉鎖）
- RST：このポートにリストされていません/過負荷です。 （強制終了）
RSTパケットの場合、src、dst、および中間デバイスがセッションと接続/状態テーブルエントリを強制終了するため、シーケンス番号が検証されます。