Transmission Control Protocol/Verbindungsverwaltung

Verbindungsverwaltung

Ein Server, der seinen Dienst anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse.

• Bezeichnet als "passive open" oder "listen".

Ein Client, der eine Verbindung aufbauen will, erzeugt einen Endpunkt (Socket) mit seiner IP-Adresse und einer eigenen, noch freien Portnummer.

• Mit der Adresse des Servers und dem Port kann dann eine Verbindung aufgebaut werden.

Während der Datenübertragungsphase sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch.

• Bezeichnet als "active open"

Jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.

TCP-Verbindungsmanagement

• Das TCP-Verbindungsmanagement ist notwendig, weil die tieferen Netzwerkschichten keinen zuverlässigen Transport der Daten gewährleisten
• Daten können beim Transport
• verloren gehen
• verfälscht werden (defekte Pakete)
• durcheinander gebracht werden (falsche Reihenfolge)
• verzögert werden
• dupliziert werden

Phasen

1. Verbindungsaufbau
2. Datenaustausch
3. Verbindungsabbau

Verbindungsaufbau

• Verbindungswunsch

Bestätigung durch beide Seiten

• TCP-Verbindungsaufbau Beispiel

Verbindungsaufbau

1. Der Client sendet dem Server ein SYN-Paket mit einer Sequenznummer x.
   • Die Sequenznummern sind für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig.
   • Ein Paket, dessen SYN-Bit im Header gesetzt ist.
   • Die Start-Sequenznummer ist eine beliebige zufällige Zahl, abhängig von der TCP-Implementierung.
2. Der Server empfängt das Paket und antwortet.
   • Port geschlossen, antwortet er mit einem TCP-RST, ein Signal, dass keine Verbindung aufgebaut werden kann.
   • Port geöffnet, bestätigt er den Erhalt des ersten SYN-Pakets und stimmt dem Verbindungsaufbau zu, indem er ein SYN/ACK-Paket zurückschickt.
     • Ein Paket, mit ACK-Flag im TCP-Header, welche die Sequenznummer x+1 des SYN-Pakets im Header enthält.
     • Der Server sendet im Gegenzug seine Start-Sequenznummer y, diese ist unabhängig von der Start-Sequenznummer des Clients.
3. Der Client bestätigt den Erhalt des SYN/ACK-Pakets durch ein eigenes ACK-Pakets mit der Sequenznummer x+1.
   • Wird auch als „Forward Acknowledgement“ bezeichnet.
   • Aus Sicherheitsgründen sendet der Client die Sequenznummer des Servers + 1 im ACK-Segment zurück.
4. Die Verbindung ist damit aufgebaut.

Verbindungsaufbau Beispiel

1.	SYN-SENT	→	<SEQ=100><CTL=SYN>	→	SYN-RECEIVED
2.	SYN/ACK-RECEIVED	←	<SEQ=300><ACK=101><CTL=SYN,ACK>	←	SYN/ACK-SENT
3.	ACK-SENT	→	<SEQ=101><ACK=301><CTL=ACK>	→	ESTABLISHED

• Nach Aufbau ist die Verbindung für beide Kommunikationspartner gleichberechtigt
• Man kann einer bestehenden Verbindung auf TCP-Ebene nicht ansehen, wer der Server und wer der Client ist.
• Eine Unterscheidung dieser beiden Rollen in der weiteren Betrachtung keine Bedeutung mehr.

Verbindungsabbau

• 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.

Halb geschlossene Verbindungen

• Der Verbindungsabbau erfolgt schrittweise einseitig.
• Erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen.

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.

Maximum segment lifetime (MSL)

• 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 als Teil einer neuen Verbindung fehlinterpretiert werden können.
  • 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.

Puffer

• Beim Datenversand über TCP werden zwei Puffer verwendet.

1. Senderseitig übermittelt die Applikation die Sendedaten an TCP und dieses puffert die Daten.
2. Effizient werden mehrere kleine Übertragungen in Form einer einzigen großen gesendet.
3. Empfängerseitig landen die empfangenen Daten im Puffer, dieser verfolgt ähnliche Ziele.

• Wenn von TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben.

Drei-Wege-Handschlag

• Typisch werden Antworten auf das erste SYN- bzw. FIN-Paket zu einem einzelnen Paket zusammengefasst (SYN/ACK bzw. FIN/ACK).
  • Theoretisch wäre auch das Versenden zweier separater Pakete denkbar.
• In diesem Fall müssen nur noch drei Pakete versendet werden, man spricht vom Drei-Wege-Handschlag.
• Das Zusammenfassen des FIN-Pakets und ACK-Pakets ist problematisch.
  • Das Fin-Paket signalisiert „keine weiteren Daten“.
• Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen wollen (halb geschlossenen Verbindung).

Überlegung

1. Den Beginn einer HTTP-Anfrage im SYN-Paket mitschicken, weitere Daten nach Verbindungsaufbau.
2. Im letzten HTTP-Request-Paket die Verbindung mittels FIN schließen.

• In der Praxis nicht angewendet da:
  • Wenn der Browser die Verbindung auf diese Art schließt, würde möglicherweise der Server die Verbindung schließen, anstatt die Anfrage vollständig zu beantworten.

Timeout bei Verbindungsaufbau

• Was passiert, wenn der Kommunikationspartner nicht antwortet?
• die Übertragung des Paketes wird wiederholt, TCP betrachtet dies als gewöhnlichen Paketverlust
• nach einer festen Zeit (timeout) wird der Verbindungsversuch abgebrochen und die Anwendung informiert

Verbindungsaufbau

• Aktives Öffnen einer Verbindung (SYN)
• Passive Seite nimmt eine Verbindung auf einer bestimmten Port-Nummer entgegen
• Die initialen Sequenznummern werden auf jeder Seite zufällig gewählt und bestätigt.
• 3-fach-Handshake (nötig wegen des unzuverlässigen Dienstes von IP)

Datenübertragung

TCP-/IP-Segment-Größe

• Typischerweise eine Größe von maximal 1500 Byte
• Muss in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP).
• IP-Pakete sind zwar bis 65.535Bytes (64KiB) spezifiziert, werden aber meist über Ethernet übertragen.
  • Bei Ethernet ist die Größe der (Layer-3-)Nutzdaten auf 64 bis 1500Bytes festgelegt (bei Jumbo Frames höher).
• TCP- und IP-Protokoll definieren jeweils einen Header von 20Bytes Größe.
• Für die (Applikations-)Nutzdaten bleiben in einem TCP/IP-Paket also 1460Bytes übrig.
• Da die meisten Internet-Anschlüsse DSL verwenden, kommt zusätzlich das Point-to-Point Protocol (PPP) zwischen IP und Ethernet zur Anwendung (8Bytes).

Die Nutzdaten reduzieren sich also auf insgesamt 1500− 20− 20− 8 =1452Bytes Maximum Segment Size (MSS).

• Dies entspricht einer maximalen Nutzdatenrate von 96,8 %.

Aufteilen der Anwendungsdaten auf TCP-/IP-Segmente

1. Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der Maximum Segment Size (MSS).
2. Als Beispiel legt ein Webserver einen 7Kilobyte großen Datenblock im Puffer ab.
   • Um mit einem 1460Byte großen Nutzdatenfeld 7Kilobyte Daten zu versenden:
     1. Teilt die TCP-Software die Daten auf mehrere Pakete auf
     2. Fügt einen TCP-Header hinzu und versendet die TCP-Segmente.
   • Dieser Vorgang wird Segmentierung genannt.
3. Der Datenblock im Puffer wird in fünf Segmente aufgeteilt, diese werden nacheinander abgeschickt.
   1. Jedes Segment erhält durch die TCP-Software einen TCP-Header.
4. Segmente kommen nicht zwingend in richtiger Reihenfolge an.
5. Um die Segmente wieder zu sortieren, ist jedes Segment nummeriert.
   • Bei der Zuordnung der Segmente im Empfänger wird die Sequenznummer herangezogen.
6. Die TCP-Software des Empfängers bestätigt die einwandfrei angekommenen TCP-Segmente.
   • Andernfalls werden die Pakete neu angefordert.

TCP-/IP-Datenübertragung

1. Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 und einer Nutzdatenlänge von 1460Bytes an den Empfänger.
2. Der Empfänger bestätigt es mit einem TCP-Header, ohne Daten, mit ACK=1461 und fordert das zweite TCP-Segment ab dem Byte Nummer 1461 an.
3. Sender schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger.
4. Empfäner bestätigt es wieder mit einem ACK=2921.

• Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind.
• Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen.
• Fehlt zum Beispiel das 3. Segment, kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht.
  • Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal.
  • Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, wenn beide die TCP-Option Selective ACK (SACK) unterstützen.
• Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer.

Retransmission Timer

• Zur Feststellung, wann ein Paket im Netzwerk verloren gegangen ist, wird vom Sender ein Timeout verwendet, bis zu dem das ACK der Gegenseite eingetroffen sein muss.
  • Timeout zu niedrig, Pakete werden doppelt geschickt.
  • Timeout zu hoch, velorene Pakete werden zu spät neu geschickt.

• Aufgrund unterschiedlicher Laufzeiten der IP-Pakete ist nur ein dynamischer Timer sinnvoll.

Flusssteuerung und Staukontrolle

In den folgenden zwei Abschnitten werden die TCP-Konzepte zur Flusssteuerung und Staukontrolle (oder Überlaststeuerung) erläutert.

• Dabei werden das Sliding Window und das Congestion Window eingeführt.
• Der Sender wählt als tatsächliche Sendefenstergröße das Minimum aus beiden Fenstern.
• Es werden ARQ-Protokolle (Automatic Repeat reQuest) für eine zuverlässige Datenübertragung eingesetzt.

Flusssteuerung

Da Daten aus dem Puffer gelesen werden, ändert sich der Füllstand des Puffers ständig.

• Deshalb ist es notwendig, den Datenfluss dem Füllstand entsprechend zu steuern.
  • Dies geschieht mit dem Sliding Window und dessen Größe.
• Der Puffer des Senders wird auf auf 10 Segmente erweitert.

Im Sliding Window (a) werden gerade die Segmente 1–5 übertragen.

1. Obwohl der Puffer voll ist, werden die nächsten Daten (ab Byte 7301) mit ACK=7301 angefordert.
   • Das nächste Segment kann nicht mehr verarbeitet werden.
   • Mit dem Window-Feld (=0) teilt er dem Sender mit, dass keine Daten mehr verschickt werden sollen.
2. Die Anwendung liest die Segmente 1–5 aus dem Puffer, es werden 7300Byte frei.
3. Er kann die restlichen Segmente 6–10 mit einem TCP-Header (SEQ=1, ACK=7301, Window=7300), beim Sender anfordern.
4. Der Sender weiß nun, dass er maximal fünf Segmente schicken kann, und verschiebt das Window um fünf Segmente nach rechts (Sliding Window (b)).
5. Die Segmente 6–10 werden nun alle zusammen als Burst verschickt.
6. Beim Ankommen aller TCP-Segmente beim Empfänger, quittiert er sie (SEQ=1 und ACK=14601) und fordert die nächsten Daten an.

Fehlerbehandlung

• Checksummen-Fehler
• Erkennen von Übertragungsfehlern
• Defekte Pakete werden weggeworfen
• Nach Timeout wird das entsprechende Paket neu gesendet
• Abgebrochene Verbindung
• plötzlicher Abbruch (Absturz, Kabel entfernt, ...)
• Schließen der Verbindung nach Timeout

Datenaustausch

• Senden eines Segments und Start eines Timer
• Bestätigung mit nächster erwarteter Sequenznummer
• Wird Timer überschritten, erneutes Senden

Effiziente Datenübertragung

• TCP verwendet das Sliding-Window-Protocol
• um möglichst effizient Daten zu übertragen und Flusskontrolle zu ermöglichen.
• Bei einer Vollduplex-Verbindung müssen insgesamt 4 Fenster verwaltet werden.

TCP PUSH Flag (PSH)

• die ursprüngliche Aufgabe des PSH Flags war es, dass der Sender eines Segmentes den Empfänger auffordert, dieses (und alle vorangegangenen) sofort bei der jeweiligen Anwendung auszuliefern, ohne dass es lange gepuffert wird
• dies sollte z. B.  für interaktive Anwendungen verwendet werden
• wird inzwischen jedoch standardmäßig (fast) immer gesetzt, da keine Rechenzeit beim Auslesen der Puffer gespart werden muss

Variable Fenstergröße

• Größe des Fensters kann variieren
• Reagieren auf Netzwerk-Engpässe
• Flusskontrolle (z. B.  zwischen verschieden starken Partnern)
• Verkehrssteuerung
• Jacobsen's "slow start" Algorithmus variiert die Grösse des Sendefensters, um die Senderate an die Netzbelastung anzupassen
• Siehe Überlastungskontrolle
• Flusssteuerung
• Jedes Bestätigungspaket enthält einen "window advertisement" Wert, in dem der Empfänger angibt, für wieviele weitere Pakete er noch freie Kapazität hat
• das Fenster kann also größer oder kleiner werden

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

Überlastungskontrolle

• Bei Paketvermittelten Netzen kann es zu Überlastung kommen
• Beim Zielhost
• Innerhalb des Netzwerkes
• Lösungen

Änderung der Fenstergröße

• Congestion Windows Size (Größe des Überlastungsfensters)
• Die tatsächliche Segmentgröße ist ein Limit aus beiden Werten

Slow Start with Congestion Avoidance

• Beim Verbindungsaufbau wird das Überlastungfenster auf die Größe eines Segmentes gesetzt
• Kommen die Quittungen des versandten Segmentes ohne Timeout an, wird die Größe des Überlastungsfensters verdoppelt
• Dies geschieht bis zum Schwellenwert von 64 KByte
• Danach pro erfolgreichem Sende- und Empfangszyklus um jeweils eine Segmentgröße
• Dieser Algorithmus ist für zuverlässige Verbindungen konzipiert und sollte z. B.  bei WLANs deaktiviert werden
• Dort verringert er stark die effektive Bandbreite

Überlaststeuerung/Staukontrolle (Congestion Control)

• Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen.
• Durch die Wiederholung steigt wiederum die Belastung, dies sorgt (ohne Maßnahmen) für einen Datenstau.
• Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet.
• Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow-Start) und die Senderate schrittweise erhöht, bis zum Datenverlust.
• Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht.

Algorithmus zur Überlaststeuerung

Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit (Timeout) kein ACK erhält.

• Man muss davon ausgehen, dass das Paket aufgrund zu hoher Netzlast von einem Router im Netz verworfen wurde (Stau im Netz).
• Um den Stau aufzulösen, müssen alle beteiligten Sender ihre Netzlast reduzieren.

Dazu werden im RFC 2581 vier Algorithmen definiert:

1. slow start
2. congestion avoidance
3. fast retransmit
4. fast recovery,

• slow start und congestion avoidance werden zusammen verwendet.
• fast retransmit und fast recovery werden zusammen verwendet, sind eine Erweiterung von slow start und congestion avoidance.

Slow Start Slow Start und Congestion Avoidance

Grafische Darstellung des Slow-Start-Algorithmus

• Der Slow-Start-Algorithmus dient zur Bestimmung des congestion window.
• Da die momentane Auslastung des Netzes nicht bekannt ist, wird mit kleinen Datenmengen begonnen.

1. Der Algorithmus startet mit einem kleinen Fenster, von einer Maximum Segment Size (MSS), in dem Datenpakete vom Sender zum Empfänger übertragen werden.
2. Der Empfänger sendet ACK an den Sender zurück.
3. Für jedes empfangene ACK wird die Größe des congestion window um eine MSS erhöht.
   • Dies führt innerhalb einer Roundtrip-Zeit zu einer Verdopplung des Congestion Windows.
4. Dieses exponentielle Wachstum wird so lange fortgesetzt, bis der Slow-Start Threshold erreicht wird.
   • Die Phase des exponentiellen Wachstums wird auch Slow Start Phase genannt.
5. Danach wird das Congestion Window nur noch um eine MSS erhöht, wenn alle Pakete aus dem Fenster erfolgreich übertragen wurden.
   • Es wächst pro Roundtrip-Zeit nur noch um eine MSS, also nur noch linear.
     • Diese Phase wird als Congestion Avoidance Phase bezeichnet.
   • Das Wachstum wird beendet, wenn das vom Empfänger festgelegte Empfangsfenster erreicht worden ist.

Kommt es zu einem Timeout, wird das congestion window auf 1 zurückgesetzt, der slow-start threshold wird auf die Hälfte der gesendeten, unquittierten Pakete herabgesetzt (Flight Size).

• Die Phase des exponentiellen Wachstums wird also verkürzt.
• Das Fenster wächst bei häufigen Paketverlusten nur langsam.

Fast-Retransmit und Fast-Recovery

• Werden eingesetzt, um nach Paketverlust schneller auf die Stau-Situation zu reagieren.
• Empfänger informiert den Sender, wenn Pakete außer der Reihe ankommen und somit dazwischen ein Paketverlust vorliegt.
• Der Empfänger bestätigt das letzte korrekte Paket erneut für jedes weitere ankommende Paket außer der Reihe.
• Man spricht dabei von Dup-Acks (duplicate acknowledgments),
  • Mehrere aufeinanderfolgende Nachrichten, welche dasselbe Datensegment ACKen.
• Der Sender bemerkt die duplizierten ACKS, und nach dem dritten Duplikat sendet er sofort, vor Ablauf des Timers, das verlorene Paket erneut.
  • Da nicht auf den Timerablauf gewartet werden muss, heißt das Prinzip Fast Retransmit.
• Dup-Acks: auch Hinweise darauf, dass ein Paketverlust stattfand, dennoch die folgenden Pakete angekommen sind.
• Das Sendefenster wird nach dem Fehler nur halbiert (kein Slow-Start).

Zusätzlich kann das Sendefenster noch um die Anzahl der Dup-Acks erhöht werden,

• Jedes Dup-Ack steht für ein weiteres Paket, welches den Empfänger erreicht hat.
• Dadurch kann nach dem Fehler schneller wieder die volle Sendeleistung erreicht werden.
• Das Prinzip nennt man Fast-Recovery.

Verwaltung der TCP-Verbindungen als endlicher Automat

Verbindungsaufbau und -abbau

Abb. 2: Verwaltung der TCP-Verbindungen als endlicher Automat

Ein Server, der seinen Dienst anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse. Dies wird als passive open oder auch als listen bezeichnet.

Will ein Client eine Verbindung aufbauen, erzeugt er einen eigenen Socket aus seiner Rechneradresse und einer eigenen, noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden. Eine TCP-Verbindung ist durch folgende 4 Werte eindeutig identifiziert:

• Quell-IP-Adresse
• Quell-Port
• Ziel-IP-Adresse
• Ziel-Port

Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.

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

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.

Verbindungsaufbau

Abb. 3: TCP-Handshake

Der Client, der eine Verbindung aufbauen will, sendet dem Server ein SYN-Paket (von ) mit einer Sequenznummer x. Die Sequenznummern sind dabei für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die Start-Sequenznummer (auch Initial Sequence Number (ISN) genannt) ist eine beliebige Zahl, deren Generierung von der jeweiligen TCP-Implementierung abhängig ist. Sie sollte jedoch möglichst zufällig sein, um Sicherheitsrisiken zu vermeiden.

Der Server (siehe Skizze) empfängt das Paket. Ist der Port geschlossen, antwortet er mit einem TCP-RST, um zu signalisieren, dass keine Verbindung aufgebaut werden kann. Ist der Port geöffnet, bestätigt er den Erhalt des ersten SYN-Pakets und stimmt dem Verbindungsaufbau zu, indem er ein SYN/ACK-Paket zurückschickt (ACK von engl. acknowledgement ‚Bestätigung‘). Das gesetzte ACK-Flag im TCP-Header kennzeichnet diese Pakete, welche die Sequenznummer x+1 des SYN-Pakets im Header enthalten. Zusätzlich sendet er im Gegenzug seine Start-Sequenznummer y, die ebenfalls beliebig und unabhängig von der Start-Sequenznummer des Clients ist.

Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1. Dieser Vorgang wird auch als „Forward Acknowledgement“ bezeichnet. Aus Sicherheitsgründen sendet der Client den Wert y+1 (die Sequenznummer des Servers + 1) im ACK-Segment zurück. Die Verbindung ist damit aufgebaut. Im folgenden Beispiel wird der Vorgang abstrakt dargestellt:

1.	SYN-SENT	→	<SEQ=100><CTL=SYN>	→	SYN-RECEIVED
2.	SYN/ACK-RECEIVED	←	<SEQ=300><ACK=101><CTL=SYN,ACK>	←	SYN/ACK-SENT
3.	ACK-SENT	→	<SEQ=101><ACK=301><CTL=ACK>	→	ESTABLISHED

Einmal aufgebaut, ist die Verbindung für beide Kommunikationspartner gleichberechtigt, man kann einer bestehenden Verbindung auf TCP-Ebene nicht ansehen, wer der Server und wer der Client ist. Daher hat eine Unterscheidung dieser beiden Rollen in der weiteren Betrachtung keine Bedeutung mehr.

Verbindungsabbau

Abb. 4: TCP-Teardown

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.

Puffer

Beim Versenden von Daten über das TCP werden zwei Puffer verwendet. Senderseitig übermittelt die Applikation die zu sendenden Daten an das TCP und dieses puffert die Daten, um mehrere kleine Übertragungen effizienter in Form einer einzigen großen zu senden. Nachdem die Daten dann an den Empfänger übermittelt wurden, landen sie im empfängerseitigen Puffer. Dieser verfolgt ähnliche Ziele. Wenn vom TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben.