RSTパケットの代わりにRST、ACKパケットが表示されるのはなぜですか？

Wiresharkを見ると、TCPストリームがRSTパケットではなくRST、ACKパケットで終わることがよくあります。これがなぜだか誰でも知っていますか？

私が見るものの例：

SYN SYN、ACK ...データ... RST、ACK

Wiresharkは、RST、ACKパケットの前にRSTパケットをピックアップしていません。

RST / ACKはRSTの確認応答ではありません。SYN/ ACKはSYNの確認応答とまったく同じではありません。TCPの確立は、実際には4方向のプロセスです。開始ホストはSYNを受信ホストに送信し、受信ホストはそのSYNに対するACKを送信します。受信ホストはSYNを開始ホストに送信し、開始ホストはACKを送り返します。これにより、ステートフルな通信が確立されます。

SYN --> 
    <-- ACK
    <-- SYN
ACK -->

これをより効率的にするために、受信ホストはSYNにACKを返し、同じパケットで独自のSYNを送信して、見慣れた3方向プロセスを作成できます。

SYN -->
    <-- SYN/ACK
ACK -->

RST / ACKの場合、デバイスはACKを使用してシーケンス内の前のパケットで送信されたデータを確認し、RSTで接続が閉じたことを送信者に通知します。デバイスは、SYN / ACKのように、2つのパケットを1つに結合するだけです。RST / ACKは通常、TCPセッションを閉じる際の通常の応答ではありませんが、必ずしも問題を示しているわけではありません。

接続が確立されると、信頼性のあるトランスポート/セキュリティのために、すべてのパケットにACKが設定され、受信パケットのシーケンス番号と一致する必要があります。ACKなしのRSTは受け入れられません。一方がRSTを送信すると、ソケットはすぐに閉じられ、受信側も有効なRSTを受信した直後にソケットを閉じます。そうである必要はなく、認めることもできません。

TCPハンドシェイク後

A ---> B Syn = x、Ack = y、len = z、ACKフラグ

B ---> A Syn = y、Ack = x + z、len = o、ACKフラグ

A ---> B Syn = x + z、Ack = y + o、len = p、ACKフラグ

B ---> A Syn = y + o、ACK = x + z + p、len = q、RST、ACKフラグ

Bは最後のパケットを送信した後にソケットを閉じ、Aはそれを受信した後にソケットを閉じます。

（ここでTCPウィンドウを考慮しないか、確認の前に一方の端からより多くのパケットがあるかもしれません）

ACKフラグ、確認番号、確認手順は関連していますが、同じものではありません。

RFC793に準拠

RFC793

確認番号：32ビット

If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive.  Once a connection is established this is always sent.

リセット処理

SYN-SENTを除くすべての状態で、すべてのリセット（RST）セグメントは、SEQフィールドをチェックすることで検証されます。シーケンス番号がウィンドウ内にある場合、リセットは有効です。SYN-SENT状態（最初のSYNに応答して受信したRST）では、ACKフィールドがSYNを確認した場合、RSTは受け入れ可能です。

RSTの受信者は最初にそれを検証し、次に状態を変更します。受信者がLISTEN状態にあった場合、それは無視されます。受信者がSYN-RECEIVED状態で以前にLISTEN状態だった場合、受信者はLISTEN状態に戻ります。それ以外の場合、受信者は接続を中止してCLOSED状態になります。レシーバーが他の状態にあった場合、接続を中止し、ユーザーに通知してCLOSED状態になります。