Was ist der Zweck von TIME WAIT beim Abbau von TCP-Verbindungen?

12

Ich fand heraus, dass der Grund, warum der aktive Schließer TIME WAIT eingibt, darin besteht, sicherzustellen, dass das endgültige ACK nicht verloren geht. Aber woher weiß es, ob das endgültige ACK verloren geht? Wird der passive Schließer die FIN erneut senden und der aktive Schließer weiß, dass die ACK verloren gegangen ist? Hier ist ein Bild des TCP FSM.

TCP FSM

tcp

— czhao
quelle

TCP

— Craig Constantine

1

Dieser Blog-Beitrag hat eine großartige Antwort: vincent.bernat.im/en/blog/…

— Warlike Chimpanzee

5

Wird der passive Schließer die FIN erneut senden und der aktive Schließer weiß, dass die ACK verloren gegangen ist?

Ja. Zitieren aus TCP / IP Illustrated Volume 1 im Abschnitt TCP-Verbindungsverwaltung:

Um den Abschluss abzuschließen, enthält das letzte Segment eine ACK für das letzte FIN. Beachten Sie, dass ein verloren gegangenes FIN erneut übertragen wird, bis eine ACK dafür empfangen wird.

Es gibt eine Zeitüberschreitung. In LAST_ACKdiesem Fall wird der passive Schließer FINbei einer Zeitüberschreitung erneut gesendet , sofern er verloren gegangen ist. Wenn es tatsächlich verloren gegangen ist, wird der aktive Schließer schließlich die erneut übertragene Nachricht empfangen FINund eintreten TIME_WAIT. Wenn das FINnicht verloren war, aber das Finale ACKverloren war, dann ist der aktive Schließer drin TIME_WAITund erhält FINwieder. Wenn dies geschieht - Empfangen eines FINin TIME_WAIT- das ACKist neu übertragen.

Der Timeout-Wert in TIME_WAITwird NICHT für die erneute Übertragung verwendet. Bei einer Zeitüberschreitung TIME_WAITwird davon ausgegangen, dass das Finale ACKerfolgreich übermittelt wurde, da der passive Schließer keine FINPakete erneut übertragen hat. Das Timeout in TIME_WAITist also nur eine Zeitspanne, nach der wir davon ausgehen können, dass das andere Ende nichts gesendet hat, weil es das Finale empfangen ACKund die Verbindung geschlossen hat.

— Filipe Gonçalves
quelle

1

Aber woher weiß es, ob das endgültige ACK verloren geht?

Weil es es nicht innerhalb des Timeout-Zeitraums erhalten hat. Ich weiß, das ist eine "duh" Antwort, aber genau deshalb gibt es diese Zustände und Zeitüberschreitungen.

Wird der passive Schließer die FIN erneut senden?

Nein. Nur wenn weitere Pakete für diesen Stream eintreffen und dies dazu führen würde, dass "RST" (Reset) gesendet wird.

Der gesamte Prozess ist eine komplizierte Zustandsmaschine, um ein ordnungsgemäßes Herunterfahren trotz der Möglichkeit von Netzwerkfehlern auszuführen. Netzwerke brechen ab, bei Verbindungen treten Fehler auf, Verbindungen werden gesättigt und müssen Pakete verwerfen, Geräte fallen aus usw. Führen Sie als Übung den Statusbaum für eine aktive Verbindung aus, wenn einer der Endpunkte gerade verschwindet (z. B. Stromausfall).

TL; DR Dieser Zustandsbaum ist für jeden möglichen Fehlermodus ausgelegt.

— Ricky Beam
quelle

Danke, aber ich bin immer noch verwirrt über den ersten Teil. Ich meinte, woher weiß der aktive Schließer, dass die ACK nicht vom passiven Schließer empfangen wurde? Wenn der passive Schließer die ACK empfängt, reißt er nur die Seite der Verbindung ab, und wenn er die ACK nicht empfängt, bleibt er nur in der LETZTEN ACK. Woher weiß der aktive Schließer, ob die ACK empfangen wurde?

— czhao

denn jedem Staat sind Zeitgeber zugeordnet.

— Ricky Beam

Entschuldigung, ich verstehe nicht. Wie teilen diese Timer dem aktiven Schließer mit, dass der passive Schließer die endgültige Bestätigung nicht erhalten hat? dh woher weiß der aktive Näher, ob er die endgültige ACK erneut senden muss?

— Czhao

0

Der Zweck von TIME_WAIT besteht darin, dem Netzwerk die Unterscheidung von Paketen zu ermöglichen, die als zur 'alten, vorhandenen' Verbindung gehörig ankommen, und von einer neuen Verbindung. Es wird empfohlen, den TIME_WAIT-Timer auf die doppelte maximale Segmentlebensdauer (MSL) zu setzen. Auf meinem System beträgt die MSL 1 Minute, sodass Verbindungen 2 Minuten lang im TIME_WAIT-Status verbleiben.

Nach dieser Zeit werden eingehende Pakete nicht mehr der alten Verbindung zugeordnet.

TIME_WAIT wird nicht direkt auf das Senden von ACK-Paketen gewartet. Dies wird durch die Zustände CLOSE_WAIT und FIN_WAIT gesteuert. Wenn Sie zu TIME_WAIT gelangen, ist der Socket bereits geschlossen.

Referenzen: http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ linux-tcpip-tuning /

— Neil Katin
quelle