Transmission Control Protocol

Grundidee und Bedeutung

Das Transmission Control Protocol (TCP) ist ein zuverlässiges, verbindungsorientiertes und paketvermitteltes Transportprotokoll der Internetprotokollfamilie. Es stellt zwischen zwei Endpunkten einen bidirektionalen, byte-orientierten Datenstrom bereit. TCP wird meist über IP eingesetzt und bildet die Transportschicht, während IP zur Internetschicht gehört. Die verbreitete Bezeichnung „TCP/IP-Protokoll“ ist daher nicht ganz genau. Im Unterschied zu TCP arbeitet UDP verbindungslos.

TCP ist wichtig, weil es trotz möglicher Paketverluste, falscher Reihenfolge und doppelter Pakete eine geordnete und weitgehend zuverlässige Übertragung ermöglicht. Es erkennt Übertragungsfehler, fordert verlorene Daten erneut an, regelt den Datenfluss und wirkt einer Netzüberlastung entgegen. Anwendungen wie Webbrowser, Webserver und E-Mail-Dienste nutzen TCP über eine Programmierschnittstelle, meist sogenannte Sockets. Im WWW tritt seit der Standardisierung im Jahr 2021 außerdem QUIC als konkurrierendes, verschlüsseltes Transportprotokoll auf.

Eine Verbindung wird eindeutig durch vier Werte bestimmt: Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse und Ziel-Port. Ein Socket ist dabei ein Paar aus IP-Adresse und Port. Ports sind 16-Bit-Zahlen von 0 bis 65535; die Ports 0 bis 1023 sind reserviert und werden von der IANA vergeben. Beispielsweise ist Port 80 für HTTP vorgesehen, die Verwendung dieses Ports ist jedoch nicht zwingend.

TCP wurde von Robert E. Kahn und Vinton G. Cerf entwickelt; ihre Forschungsarbeit begann 1973. Die erste Standardisierung erfolgte 1981 als RFC 793. RFC 9293 von 2022 bündelt die ursprüngliche Fassung und ihre Erweiterungen.

Verbindungen aufbauen und beenden

Ein Server richtet mit seiner IP-Adresse und einer Portnummer einen Socket für eingehende Verbindungen ein. Dieser Zustand heißt passive open oder listen. Ein Client erzeugt einen eigenen Socket und beginnt den Verbindungsaufbau als active open. Nach dem Aufbau sind beide Seiten aus Sicht von TCP gleichberechtigt und können Daten senden oder den Abbau einleiten.

Der Aufbau erfolgt durch einen Drei-Wege-Handschlag. Erstens sendet der Client ein Segment mit gesetztem SYN-Flag und einer Start-Sequenznummer x. Die Initial Sequence Number (ISN) wird von der TCP-Implementierung gewählt und sollte aus Sicherheitsgründen möglichst zufällig sein. Zweitens antwortet ein Server bei geöffnetem Port mit SYN/ACK: Er bestätigt x mit ACK=x+1 und übermittelt seine eigene Start-Sequenznummer y. Bei geschlossenem Port antwortet er stattdessen mit RST. Drittens bestätigt der Client mit ACK und sendet dabei y+1 zurück. Im Artikel lautet das Beispiel: SYN mit SEQ=100, SYN/ACK mit SEQ=300 und ACK=101, danach ACK mit SEQ=101 und ACK=301.

Beim geregelten Abbau zeigt FIN an, dass vom Sender keine weiteren Daten folgen. Die Gegenseite bestätigt dies mit ACK und sendet später ein eigenes FIN, das ebenfalls bestätigt wird. FIN und ACK können zusammengefasst werden. Nach dem letzten ACK folgt ein Wartezustand von zwei MSL. Die Maximum Segment Lifetime (MSL) ist die längste Zeit, die ein Segment im Netz bestehen kann. Der Wartezustand verhindert, dass verspätete Segmente einer neuen Verbindung mit denselben Ports zugeordnet werden, und ermöglicht eine erneute Übertragung des letzten Abbau-Segments, falls ein ACK verloren geht.

Wird nur eine Senderichtung geschlossen, bleibt die Gegenrichtung für Daten offen; dies heißt halb geschlossene Verbindung. Halb offen ist dagegen eine Verbindung, wenn eine Seite abstürzt, ohne dass die andere davon erfährt. Dann können Ressourcen belegt bleiben, bis die Anwendung oder ein anderer Mechanismus reagiert.

Segmente und TCP-Header

TCP zerlegt den Datenstrom in Segmente. Jedes Segment besteht aus einem Header und der Nutzlast. Ein typischer Header ohne Optionen ist 20 Byte groß; die Felder werden in Big-Endian-Reihenfolge übertragen.

Zu den wichtigsten Headerfeldern gehören Quell- und Zielport mit jeweils 2 Byte, Sequenznummer und Quittierungsnummer mit jeweils 4 Byte sowie das 2 Byte große Empfangsfenster. Die Sequenznummer bezeichnet das erste Datenbyte eines Segments oder bei gesetztem SYN-Flag die Initialisierungs-Sequenznummer. Sie ermöglicht die richtige Sortierung. Die Quittierungsnummer nennt bei gesetztem ACK-Flag die Sequenznummer, die als Nächstes erwartet wird. Data Offset gibt in 32-Bit-Blöcken die Headerlänge und damit den Beginn der Nutzlast an. Das Window-Feld teilt mit, wie viele Bytes der Absender ab der bestätigten Position empfangen kann.

Die Steuerflags kennzeichnen besondere Funktionen: SYN baut eine Verbindung auf, FIN beendet eine Senderichtung, ACK macht die Quittierungsnummer gültig und RST bricht eine Verbindung ab oder weist sie zurück. PSH kann dafür sorgen, dass gepufferte Daten zügig an die Anwendung weitergegeben werden. URG kennzeichnet selten verwendete dringende Daten; der Urgent Pointer zeigt auf das erste Byte nach diesen Daten. ECE meldet mit Explicit Congestion Notification eine Überlastung, CWR bestätigt die Verringerung des Congestion Window.

Das Optionsfeld ist 0 bis 40 Byte lang und kann etwa die Maximum Segment Size (MSS), also die maximale Nutzdatengröße eines Segments, aushandeln. Optionen müssen einschließlich Padding ein Vielfaches von 32 Bit belegen. Zwei weitere Byte enthalten die Prüfsumme zur Erkennung von Übertragungsfehlern.

Segmentierung, Bestätigung und Zuverlässigkeit

Ein TCP-Segment muss in die Maximum Transmission Unit (MTU) der darunterliegenden Schicht passen. Bei Ethernet stehen üblicherweise höchstens 1500 Byte für Layer-3-Daten zur Verfügung. Nach je 20 Byte für IP- und TCP-Header bleiben 1460 Byte Anwendungsdaten. Kommen bei DSL 8 Byte für einen PPP-Rahmen hinzu, beträgt die MSS 1452 Byte; das entspricht einer maximalen Nutzdatenrate von 96,8 %.

Bei der Segmentierung zerlegt TCP größere Anwendungsdaten in passende Teile. Ein 7-Kilobyte-Datenblock wird bei 1460 Byte Nutzlast in fünf Segmente aufgeteilt. Weil diese im Internet unterschiedliche Wege nehmen können, müssen sie nicht in Versandreihenfolge eintreffen. Sequenznummern erlauben dem Empfänger, sie richtig zusammenzusetzen und Duplikate zu verwerfen.

Beispielsweise sendet eine Seite 1460 Byte mit SEQ=1. Der Empfänger antwortet mit ACK=1461 und zeigt damit an, dass er als Nächstes Byte 1461 erwartet. Das folgende Segment beginnt mit SEQ=1461 und wird mit ACK=2921 bestätigt. ACKs sind kumulativ: Mehrere lückenlos eingetroffene Segmente können gemeinsam bestätigt werden. Fehlt Segment 3, kann die normale kumulative Bestätigung zunächst nur den lückenlosen Bereich bis Segment 2 erfassen. Selective ACKs (SACK) übermitteln im Optionsfeld genauer, welche späteren Bereiche bereits angekommen sind und welche fehlen. Bestätigungen lassen sich auch zusammen mit Daten der Gegenrichtung übertragen; dies heißt Piggybacking.

Für jedes unbestätigte Segment läuft ein Retransmission Timer. Der Retransmission Timeout RTO passt sich an die Verbindung an. Anfangs gilt RTO=1 s, wobei aus Kompatibilitätsgründen auch ein größerer Wert möglich ist. Nach der ersten Messung gilt SRTT:=RTT, RTTVAR:=0,5·RTT und RTO:=RTT+4·RTTVAR. Später werden empfohlen: RTTVAR:=(1−β)·RTTVAR+β·|SRTT−RTT′| mit β=1/4 sowie SRTT:=(1−α)·SRTT+α·RTT′ mit α=1/8. Danach gilt wieder RTO:=SRTT+4·RTTVAR; der Minimalwert beträgt 1 s, eine optionale Obergrenze mindestens 60 s. Nach einem Timeout wird RTO verdoppelt. Nach dem Karn-Algorithmus werden nur Pakete für RTT-Messungen verwendet, die nicht erneut gesendet wurden.

Die Prüfsumme ist das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter des TCP-Headers und der Nutzdaten sowie eines Pseudo-Headers. Bei ungerader Bytezahl wird nur für die Berechnung ein Padding-Byte ergänzt. Der Pseudo-Header enthält bei IPv4 Quell- und Zieladresse, ein Null-Byte, die Protokollnummer 6 und die TCP-Länge; er wird nicht übertragen. Bei IPv6 werden unter anderem die 128-Bit-Adressen verwendet. Der Empfänger berechnet die Summe erneut; das Ergebnis soll FFFF hexadezimal sein. Andernfalls wird das Segment verworfen und später wegen der ausbleibenden Bestätigung erneut gesendet. Die 16-Bit-Prüfsumme kann allerdings Fehler übersehen.

Flusssteuerung

Die Flusssteuerung verhindert, dass ein schneller Sender den Empfangspuffer überfüllt. Der Empfänger meldet im Window-Feld seinen freien Speicherplatz. Dieses Sliding Window, also gleitende Fenster, legt fest, wie viele noch nicht bestätigte Daten der Sender übertragen darf. Ist der Puffer voll, meldet der Empfänger Window=0, ein Zero Window. Nachdem die Anwendung Daten ausgelesen hat, vergrößert ein Window Update das Fenster wieder.

Sehr kleine Fenster können zum Silly Window Syndrome führen: Wenn die Anwendung beispielsweise nur zwei Byte freigibt, würden zwei Byte Nutzdaten in einem insgesamt 42 Byte großen Paket übertragen und der Puffer wäre sofort wieder voll. Clarks Lösung von 1982 lässt den Empfänger nach einem Zero Window mit dem Update warten, bis mindestens eine MSS frei oder der Puffer halb leer ist – je nachdem, was zuerst eintritt. Der Nagle-Algorithmus verhindert auf Senderseite ebenfalls unnötig kleine Pakete.

Flusssteuerung und Staukontrolle verwenden verschiedene Grenzen: Das Sliding Window richtet sich nach dem Empfänger, das Congestion Window nach der Belastung des Netzes. Als tatsächliche Sendefenstergröße wählt TCP das Minimum beider Fenster. Sendewiederholungen beruhen auf ARQ-Verfahren, also Automatic Repeat reQuest.

Staukontrolle

Staukontrolle oder Congestion Control verhindert, dass Paketwiederholungen ein bereits überlastetes Netz noch stärker belasten. TCP deutet Verluste gewöhnlich als Zeichen dafür, dass ein Router wegen eines vollen Puffers Pakete verworfen hat, und passt die Senderate an. RFC 2581 nennt Slow Start, Congestion Avoidance, Fast Retransmit und Fast Recovery.

Slow Start beginnt mit einem Congestion Window von einer MSS. Für jedes ACK wächst das Fenster um eine MSS und verdoppelt sich dadurch ungefähr in jeder Roundtrip-Zeit. Dieses exponentielle Wachstum endet am Slow-Start Threshold. Danach wächst das Fenster in der Congestion-Avoidance-Phase nur noch um ein Segment pro Roundtrip-Zeit. Bei einem Timeout wird das Congestion Window auf 1 zurückgesetzt und der Threshold auf die Hälfte der Flight Size gesetzt; die Flight Size ist die Menge gesendeter, aber noch nicht bestätigter Pakete.

Bei einer Lücke bestätigt der Empfänger für jedes weitere außer der Reihe eintreffende Paket erneut das letzte lückenlos empfangene Segment. Nach dem dritten solchen Duplicate ACK überträgt der Sender das fehlende Paket sofort erneut, ohne auf den Timer zu warten: Fast Retransmit. Weil die Duplicate ACKs zeigen, dass spätere Pakete noch ankommen, wird das Sendefenster beim Fast Recovery nur halbiert und anschließend schneller weitergeführt.

TCP Tahoe setzt nach einem erkannten Überlastereignis das Congestion Window auf 1 und beginnt wieder mit Slow Start; dieses Verfahren wird nicht mehr verwendet. TCP Reno behandelt Timeouts ebenso, halbiert das Fenster aber nach drei Duplicate ACKs und geht in Congestion Avoidance über. In modernen Betriebssystemen wird TCP CUBIC als Standard-Überlastalgorithmus eingesetzt.

Die Staukontrolle bleibt ein aktives Forschungsfeld. Besonders bei drahtlosen Netzen können Verluste durch das unzuverlässige Medium entstehen, ohne dass ein Router überlastet ist; eine Verringerung der Senderate ist dann nicht unbedingt sinnvoll. Neuere Ansätze verwenden unter anderem Router Congestion Feedback, Explicit Congestion Notification, Split-TCP oder den Informationsaustausch mehrerer Verbindungen. Genannt werden XCP, EWA, FEWA, FXCP, ETCP und EFCM. Der Artikel weist darauf hin, dass Teile dieser Forschungsdarstellung seit 2008 möglicherweise nicht mehr aktuell sind und reale Verfahren wesentlich komplexer sind als die vereinfachte Beschreibung.