Transmission Control Protocol/Verbindungsabbau: Unterschied zwischen den Versionen

Aktuelle Version vom 28. Januar 2024, 13:19 Uhr

Der Verbindungsabbau kann beidseitig oder schrittweise einseitig erfolgen
Der geregelte Verbindungsabbau erfolgt dem Verbindungsaufbau ähnlich
1. Statt dem SYN-Bit kommt das FIN-Bit zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen werden
2. Der Erhalt des Pakets wird mit ACK bestätigt und der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket
3. Dieses FIN-Paket wird ihm zuletzt bestätigt

Ein verkürztes ist Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden

Der geregelte Verbindungsabbau erfolgt ähnlich

Statt des SYN-Bit kommt das FIN-Bit (von engl. finish ‚Ende‘, ‚Abschluss‘) zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen werden
Der Erhalt des Pakets wird wiederum mittels ACK bestätigt
Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird

Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden

Die maximum segment lifetime (MSL) ist die maximale Zeit, die ein Segment im Netzwerk verbringen kann, bevor es verworfen wird
Nach dem Senden des letzten ACKs wechselt der Client in einen zwei MSL andauernden Wartezustand (wait state), in dem alle verspäteten Segmente verworfen werden
Dadurch wird sichergestellt, dass keine verspäteten Segmente fehlinterpretiert werden können als Teil einer neuen Verbindung, die zufällig den gleichen Port benutzt
Außerdem wird eine korrekte Verbindungsterminierung sichergestellt
Geht ACK y+1 verloren, läuft beim Server der Timer ab, und das LAST_ACK-Segment wird erneut übertragen

durch zweimal half-close
da die TCP-Verbindung bidirektional ist, können beide Richtungen getrennt voneinander beendet werden
wer seine Senderolle beenden möchte, setzt das FIN Flag
FIN „kostet“ ein Byte und wird daher durch ein ack(nowledgement) bestätigt
der andere Teilnehmer kann weiter senden - jedoch sieht man fast immer das Verhalten, dass der andere Teilnehmer als Reaktion auch seine Senderolle beendet
derjenige Teilnehmer, der zuerst seine Verbindung beendet, führt ein „active close“ (i.d.R
der Client) durch, der Kommunikationspartner ein „passive close“ (i.d.R
der Server)

derjenige Teilnehmer, der einen active close durchführt, muss nach Senden des ACKS die Verbindung für eine gewisse Zeit für das FIN des Kommunikationspartners offen halten
Grund: das ack könnte verloren gehen und müsste dann erneut übertragen werden
die „gewisse Zeit“ beträgt 2 maximal segment lifetimes (daher 2MSL wait state)
implementiert wird eine MSL als 30 - 120 Sekunden
während 2MSL Wait State kann daher die Port-Nummer noch nicht wieder für andere TCP-Verbindungen verwendet werden

ein Segment, bei dem das RST (reset) bit im TCP header gesetzt ist, terminiert die Verbindung in Form eines „abortive release“ (im Gegensatz zum „orderly release“ mit FIN):
alle Daten, die beim Sender gepuffert waren, werden verworfen und das reset Segment wird sofort gesendet, die Verbindung ist damit aus Sicht des RST Senders sofort terminiert
es können beim Reset Daten verloren gehen (das passiert beim Verbindungsabbau mit FIN nicht)
der Emfänger eines RST Segmentes meldet dies der Anwendung und terminiert sofort
es gibt prinzipiell zwei unterschiedliche Situationen, wann ein RST gesendet wird:
wenn ein Port nicht belegt ist (connection refused)
wenn eine bestehende Verbindung abgebrochen wird (connection reset by peer)

Der Verbindungsabbau kann auf zwei Arten erfolgen: beidseitig oder schrittweise einseitig

Bei letzterer Variante spricht man von einer halb geschlossenen Verbindung (nicht zu verwechseln mit halb offenen Verbindungen, siehe unten)
Sie erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen

Halb geschlossene Verbindungen sind ein Erbe des Betriebssystems Unix, in dessen Umfeld TCP entstanden ist

Entsprechend dem Grundsatz everything is a file (dt. „Alles ist eine Datei“) unterstützt Unix bei TCP-Verbindungen eine zu Pipes völlig analoge Interaktion zweier Prozesse: für ein Programm soll es schlichtweg irrelevant sein, ob es von einer TCP-Verbindung oder einer Datei liest
Ein Unix-Programm liest typischerweise bis zum Ende der Standardeingabe und schreibt anschließend das Verarbeitungsergebnis in die Standardausgabe
Die Standard-Datenströme werden vor Ausführung des Programms mit Dateien verbunden

Die Hin- und Rückkanäle einer TCP-Verbindung werden mit Standardein- und -ausgabe verbunden und somit logisch als je eine Datei repräsentiert

Eine geschlossene Verbindung wird dem lesenden Prozess als erreichtes Dateiende übersetzt
Das angesprochene typische Unix-Verarbeitungsschema setzt voraus, dass die Verbindung in Rückrichtung nach dem Lesen des Dateiendes noch zum Schreiben bereitsteht, woraus der Bedarf für halb geschlossene Verbindungen resultiert

wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt
Effekt: Betriebssystemressourcen werden nicht freigegeben
Ursprung: TCP-Verbindungen von der Protokollseite bestehen, bis sie abgebaut werden

Eine Verbindung ist halb offen, wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt

Dies hat den unerwünschten Effekt, dass Betriebssystemressourcen nicht freigegeben werden
Halb offene Verbindungen können entstehen, weil TCP-Verbindungen von Protokollseite solange bestehen, bis sie abgebaut werden
Häufig werden jedoch von Anwendungsseite entsprechende Vorkehrungen getroffen

@@ Zeile 95: / Zeile 95: @@
 * Halb offene Verbindungen können entstehen, weil TCP-Verbindungen von Protokollseite solange bestehen, bis sie abgebaut werden
 * Häufig werden jedoch von Anwendungsseite entsprechende Vorkehrungen getroffen
+[[Kategorie:TCP]]