Wie kommt es, dass LAST_ACK nicht in CLOSE_WAIT eintritt?

Question

Wenn eine TCP-Verbindung an einem Ende der Verbindung geschlossen wird, empfängt das andere Ende eine FINund antwortet mit einer ACK. Dieses Ende der Verbindung wechselt dann in den CLOSE_WAITZustand . Sobald close()an diesem Ende aufgerufen wird, sendet TCP ein FINPaket und wechselt in den LAST_ACKZustand. Es wechselt jedoch nie in den TIME_WAITZustand .

Nehmen wir nun an, dass Host A close()den Socket aufruft und ein FINPaket an Host B sendet. Host A wechselt in den FIN_WAIT_1Status. Host B empfängt das FINPaket, sendet ein ACKund wechselt dann in den CLOSE_WAITStatus. Das ACK wird jedoch irgendwo in einem Upstream-Router gelöscht.

In der Zwischenzeit ruft Host B an close()(denken Sie daran, dass sich Host B im CLOSE_WAITStatus befindet) und sendet ein FINPaket an Host A. Host B wechselt jetzt in den LAST_ACKStatus. Host A empfängt das FINPaket und antwortet mit einem ACK. Dann wechselt er in den CLOSINGStatus.

Am anderen Ende befindet sich Host B immer noch in diesem LAST_ACKZustand. Er empfängt dann das ACKvon Host A und wechselt in den CLOSEDZustand. Denken Sie daran, dass das ACKvon Host B zu Host A unterbrochen wurde und dass Host A sein FINPaket nicht erneut gesendet hat. Host A sendet sein FINPaket nach Zeitüberschreitung erneut – Host B hat die Verbindung jedoch geschlossen.

Hängt Host A nun in diesem CLOSINGZustand fest? Kann der Verbindungsabbau fortgesetzt werden? Was passiert als nächstes?

Answer 1

Mein TCP ist etwas eingerostet, aber ich glaube, es funktioniert so:

Wenn Host B anruft close()und seine sendet , zeigt FINdie Sequenznummer darauf Host A an, dass ein Paket von Host B verpasst wurde. Host A wird daher die von Host B nicht bestätigen , sondern weiterhin das letzte TCP-Segment bestätigen, das er erfolgreich von Host B empfangen hat. Dadurch wird Host B aufgefordert, die fehlenden erneut zu übertragen .FINFINACK

Daher erreicht Host A diesen Zustand nicht CLOSING, da er den Empfang der Out-of-Order-Nachricht FINerst dann als wirklich ansieht, wenn er die ACKvorhergehende fehlende Nachricht empfängt.