Transmission Control Protocol/Verbindungsabbau: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Textersetzung - „ TCP“ durch „ TCP“ |
||
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
=== Verbindungsabbau === | === Verbindungsabbau === | ||
[[Datei:TCP-Teardown.svg|300px| TCP-Teardown]] | [[Datei:TCP-Teardown.svg|300px| [[TCP]]-Teardown]] | ||
* Der Verbindungsabbau kann ''beidseitig'' oder ''schrittweise einseitig'' erfolgen | * Der Verbindungsabbau kann ''beidseitig'' oder ''schrittweise einseitig'' erfolgen | ||
| Zeile 11: | Zeile 11: | ||
; Verbindungsabbau | ; Verbindungsabbau | ||
[[Datei:TCP-Teardown.svg|mini|Abb. 4: TCP-Teardown]] | [[Datei:TCP-Teardown.svg|mini|Abb. 4: [[TCP]]-Teardown]] | ||
Der geregelte Verbindungsabbau erfolgt ähnlich | Der geregelte Verbindungsabbau erfolgt ähnlich | ||
| Zeile 26: | Zeile 26: | ||
=== Abbau einer TCP-Verbindung === | === Abbau einer [[TCP]]-Verbindung === | ||
* Senden eines Segments mit FIN=1 | * Senden eines Segments mit FIN=1 | ||
* Bestätigung | * Bestätigung | ||
* muss für beide Richtungen separat erfolgen | * muss für beide Richtungen separat erfolgen | ||
==== TCP-Verbindungsabbau ==== | ==== [[TCP]]-Verbindungsabbau ==== | ||
* durch zweimal half-close | * durch zweimal half-close | ||
* da die TCP-Verbindung bidirektional ist, können beide Richtungen getrennt voneinander beendet werden | * da die [[TCP]]-Verbindung bidirektional ist, können beide Richtungen getrennt voneinander beendet werden | ||
* wer seine Senderolle beenden möchte, setzt das FIN Flag | * wer seine Senderolle beenden möchte, setzt das FIN Flag | ||
* FIN | * 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 | * 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 | * derjenige Teilnehmer, der zuerst seine Verbindung beendet, führt ein "active close" (i.d.R | ||
* der Client) durch, der Kommunikationspartner ein | * der Client) durch, der Kommunikationspartner ein "passive close" (i.d.R | ||
* der Server) | * der Server) | ||
| Zeile 44: | Zeile 44: | ||
* 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 | * 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 | * Grund: das ack könnte verloren gehen und müsste dann erneut übertragen werden | ||
* die | * die "gewisse Zeit" beträgt 2 maximal segment lifetimes (daher 2MSL wait state) | ||
* implementiert wird eine MSL als 30 - 120 Sekunden | * 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 | * während 2MSL Wait State kann daher die Port-Nummer noch nicht wieder für andere [[TCP]]-Verbindungen verwendet werden | ||
==== TCP Reset ==== | ==== [[TCP]] Reset ==== | ||
* ein Segment, bei dem das RST (reset) bit im TCP header gesetzt ist, terminiert die Verbindung in Form eines | * 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 | * 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) | * es können beim Reset Daten verloren gehen (das passiert beim Verbindungsabbau mit FIN nicht) | ||
| Zeile 59: | Zeile 59: | ||
==== Ablehnung einer Verbindung ==== | ==== Ablehnung einer Verbindung ==== | ||
* Versuch eines Verbindungsaufbaus zu einem geschlossenen Port | * Versuch eines Verbindungsaufbaus zu einem geschlossenen Port | ||
* Beispiel TCP | * Beispiel [[TCP]] | ||
* Beispiel UDP | * Beispiel UDP | ||
===== Ablehnung einer Verbindung TCP ===== | ===== Ablehnung einer Verbindung [[TCP]] ===== | ||
===== Ablehnung einer Verbindung UDP ===== | ===== Ablehnung einer Verbindung UDP ===== | ||
| Zeile 76: | Zeile 76: | ||
* Sie erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen | * 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 | Halb geschlossene Verbindungen sind ein Erbe des Betriebssystems [[Unix]], in dessen Umfeld [[TCP]] entstanden ist | ||
* Entsprechend dem Grundsatz ''[[everything is a file]]'' (dt. | * Entsprechend dem Grundsatz ''[[everything is a file]]'' (dt. "''Alles ist eine Datei''") unterstützt Unix bei [[TCP]]-Verbindungen eine zu [[Pipe (Informatik)|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 | * 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 [[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 | 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 | * 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 | * 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 | ||
| Zeile 88: | Zeile 88: | ||
* wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt | * wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt | ||
* Effekt: Betriebssystemressourcen werden nicht freigegeben | * Effekt: Betriebssystemressourcen werden nicht freigegeben | ||
* Ursprung: TCP-Verbindungen von der Protokollseite bestehen, bis sie abgebaut werden | * Ursprung: [[TCP]]-Verbindungen von der Protokollseite bestehen, bis sie abgebaut werden | ||
; Halb offene Verbindungen | ; Halb offene Verbindungen | ||
Eine Verbindung ist halb offen, wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt | 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 | * 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 | * 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 | * Häufig werden jedoch von Anwendungsseite entsprechende Vorkehrungen getroffen | ||
[[Kategorie:TCP]] | |||
Aktuelle Version vom 4. Juli 2026, 12:10 Uhr
Verbindungsabbau
- Der Verbindungsabbau kann beidseitig oder schrittweise einseitig erfolgen
- Der geregelte Verbindungsabbau erfolgt dem Verbindungsaufbau ähnlich
- Statt dem SYN-Bit kommt das FIN-Bit zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen werden
- Der Erhalt des Pakets wird mit ACK bestätigt und der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket
- 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
- Verbindungsabbau
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
Abbau einer TCP-Verbindung
- Senden eines Segments mit FIN=1
- Bestätigung
- muss für beide Richtungen separat erfolgen
TCP-Verbindungsabbau
- 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)
2MSL Wait State
- 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
TCP Reset
- 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)
Ablehnung einer Verbindung
- Versuch eines Verbindungsaufbaus zu einem geschlossenen Port
- Beispiel TCP
- Beispiel UDP
Ablehnung einer Verbindung TCP
Ablehnung einer Verbindung UDP
Halb geschlossene Verbindungen
- Der Verbindungsabbau erfolgt schrittweise einseitig
- Erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen
- Halb geschlossene Verbindungen
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
Halb offene Verbindungen
- 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
- Halb offene Verbindungen
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