Warum sehe ich ein RST, ACK-Paket anstelle eines RST-Pakets?

Wenn ich in Wireshark nachschaue, sehe ich oft, dass TCP-Streams mit einem RST-, ACK-Paket anstelle eines RST-Pakets enden. Weiß jemand warum das so ist?

Ein Beispiel für das, was ich sehe:

SYN SYN, ACK ... Daten ... RST, ACK

Wireshark empfängt kein RST-Paket vor dem RST-ACK-Paket.

Ein RST / ACK ist keine Bestätigung eines RST, genauso wie ein SYN / ACK nicht genau eine Bestätigung eines SYN ist. Die TCP-Einrichtung erfolgt in vier Richtungen: Der initiierende Host sendet eine SYN an den empfangenden Host, der eine ACK für diese SYN sendet. Der empfangende Host sendet eine SYN an den initiierenden Host, der eine ACK zurücksendet. Dies stellt eine zustandsbehaftete Kommunikation her.

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

Um dies effizienter zu gestalten, kann der empfangende Host den SYN-Code ACKEN und seinen eigenen SYN-Code im selben Paket senden, wodurch der gewohnte Drei-Wege-Prozess entsteht.

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

Im Falle eines RST / ACK bestätigt das Gerät alle Daten, die in den vorherigen Paketen in der Sequenz gesendet wurden, mit einem ACK und benachrichtigt dann den Absender, dass die Verbindung mit dem RST geschlossen wurde. Das Gerät kombiniert einfach die beiden Pakete zu einem, genau wie ein SYN / ACK. Ein RST / ACK ist normalerweise keine normale Antwort beim Schließen einer TCP-Sitzung, weist jedoch auch nicht unbedingt auf ein Problem hin.

Sobald die Verbindung hergestellt ist, muss für alle Pakete ACK eingestellt sein und mit der Sequenznummer der empfangenen Pakete übereinstimmen, um einen zuverlässigen Transport / Sicherheit zu gewährleisten. RST ohne ACK wird nicht akzeptiert. Wenn eine Seite RST sendet, wird der Socket sofort geschlossen, und die empfangende Seite schließt auch den Socket sofort, nachdem eine gültige RST empfangen wurde. Es muss nicht sein und kann nicht bestätigt werden.

nach TCP-Handshake

A ---> B Syn = x, Ack = y, len = z, ACK-Flag

B ---> A Syn = y, Ack = x + z, len = o, ACK-Flag

A -> B Syn = x + z, Ack = y + o, len = p, ACK Flag

B ---> A Syn = y + o, ACK = x + z + p, len = q, RST, ACK Flag

B schließt den Socket, nachdem es das letzte Paket gesendet hat, und A schließt den Socket, nachdem es es empfangen hat.

(TCP-Fenster wird hier nicht berücksichtigt, oder es sind möglicherweise mehr Pakete von einem Ende vor der Bestätigung vorhanden.)

ACK-Flag, Bestätigungsnummer und Bestätigungsverfahren sind miteinander verbunden, aber nicht dasselbe.

Per RFC793

RFC793

Bestätigungsnummer: 32 Bit

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.

Verarbeitung zurücksetzen

In allen Zuständen mit Ausnahme von SYN-SENT werden alle RST-Segmente durch Überprüfen ihrer SEQ-Felder validiert. Ein Reset ist gültig, wenn die laufende Nummer im Fenster steht. In dem SYN-SENT-Zustand (eine RST, die als Antwort auf eine anfängliche SYN empfangen wurde) ist die RST akzeptabel, wenn das ACK-Feld die SYN bestätigt.

Der Empfänger eines RST validiert es zuerst und ändert dann den Zustand. Wenn sich der Empfänger im Zustand LISTEN befand, wird er ignoriert. Wenn sich der Empfänger im SYN-RECEIVED-Status befand und zuvor im LISTEN-Status war, kehrt der Empfänger in den LISTEN-Status zurück, andernfalls bricht der Empfänger die Verbindung ab und wechselt in den CLOSED-Status. Wenn sich der Empfänger in einem anderen Zustand befand, bricht er die Verbindung ab, weist den Benutzer darauf hin und wechselt in den Zustand GESCHLOSSEN.