Transmission Control Protocol Familie: Internetprotokollfamilie Einsatzgebiet: Zuverlässiger bidirektionaler Datentransport Standards: RFC 9293 (2022) RFC 7323 (2014)
Das (TCP, englisch für „Übertragungssteuerungsprotokoll“) ist ein Netzwerkprotokoll, das definiert, auf welche Art und Weise Daten zwischen Netzwerkkomponenten ausgetauscht werden sollen. Nahezu sämtliche aktuellen Betriebssysteme moderner Computer beherrschen TCP und nutzen es für den Datenaustausch mit anderen Rechnern. Das Protokoll ist ein zuverlässiges, verbindungsorientiertes, paketvermitteltesNicht zu verwechseln mit paketvermittelnd. Die Aufgabe von TCP ist es nicht, Pakete zu übertragen, sondern die Bytes eines Datenstroms. Die Paketvermittlung wird durch das Internetprotokoll (IP) bereitgestellt. Daher ist IP paketvermittelnd, aber TCP paketvermittelt. Transportprotokoll in Computernetzwerken. Es ist Teil der Internetprotokollfamilie, der Grundlage des Internets.
Entwickelt wurde TCP von Robert E. Kahn und Vinton G. Cerf. Ihre Forschungsarbeit, die sie im Jahr 1973 begannen, dauerte mehrere Jahre. Die erste Standardisierung von TCP erfolgte deshalb erst im Jahr 1981 als RFC 793. Danach gab es viele Erweiterungen, die bis heute in neuen RFCs, einer Reihe von technischen und organisatorischen Dokumenten zum Internet, spezifiziert werden. RFC 9293 bündelt die ursprüngliche Fassung und alle ihre Erweiterungen in ein einziges Dokument.
Im Unterschied zum verbindungslosen UDP () stellt TCP eine Verbindung zwischen zwei Endpunkten einer Netzverbindung (Sockets) her. Auf dieser Verbindung können in beide Richtungen Daten übertragen werden. TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf, weshalb häufig (und oft nicht ganz korrekt) auch vom „TCP/IP-Protokoll“ die Rede ist. In Protokollstapeln wie dem OSI-Modell sind TCP und IP nicht auf derselben Schicht angesiedelt. TCP ist eine Implementierung der Transportschicht.
Aufgrund seiner vielen positiven Eigenschaften (Datenverluste werden erkannt und automatisch behoben, Datenübertragung ist in beiden Richtungen möglich, Netzüberlastung wird verhindert usw.) ist TCP ein sehr weit verbreitetes Protokoll zur Datenübertragung. Beispielsweise wurde TCP lange Zeit als fast ausschließliches Transportprotokoll für das WWW, E-Mail und viele andere populäre Netzdienste verwendet. Im WWW bekommt TCP Konkurrenz durch das verschlüsselte Transportprotokoll QUIC, das im Jahr 2021 standardisiert wurde.
Allgemeines TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex, die die Übertragung der Informationen in beide Richtungen zulässt, analog zu einem Telefongespräch. Diese Verbindung kann auch als zwei Halbduplexverbindungen, bei denen Informationen in beide Richtungen (allerdings nicht gleichzeitig) fließen können, betrachtet werden. Die Daten in Gegenrichtung können dabei zusätzliche Steuerungsinformationen enthalten. Die Verwaltung dieser Verbindung sowie die Datenübertragung werden von der TCP-Software übernommen. Die TCP-Software ist üblicherweise im Netz-Protokollstack des Betriebssystems angesiedelt. Anwendungsprogramme benutzen eine Schnittstelle dazu, meist Sockets, die sich (je nach Betriebssystem unterschiedlich) beispielsweise bei Microsoft Windows in extra einzubindenden Programmbibliotheken („Winsock.dll“ bzw. „wsock32.dll“) befinden. Linux und viele andere unixoide Betriebssysteme enthalten einen Socketlayer im Betriebssystemkern. Auf den Socketlayer wird über Systemaufrufe zugegriffen. Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver.
Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert. Ein Endpunkt stellt ein geordnetes Paar dar, bestehend aus IP-Adresse und Port. Ein solches Paar bildet eine bidirektionale Software-Schnittstelle und wird auch als Socket bezeichnet. Somit wird eine TCP-Verbindung durch vier Werte (einem Quadrupel) identifiziert:
(Lokaler Rechner, Lokaler Port, Entfernter Rechner, Entfernter Port)
Dabei kommt es auf das gesamte Quadrupel an. Beispielsweise können zwei verschiedene Prozesse auf demselben Rechner denselben lokalen Port benutzen und dabei sogar mit demselben Rechner auf der gegenüberliegenden Seite kommunizieren, sofern die beteiligten Prozesse auf der anderen Seite unterschiedliche Ports benutzen. In einem solchen Fall würde es sich um zwei verschiedene Verbindungen handeln, deren Quadrupel sich nur in einem von vier Werten unterscheidet: dem Port auf der gegenüberliegenden Seite.
Verbindung 1: (Lokaler Rechner, Port x, Entfernter Rechner, Port y) Verbindung 2: (Lokaler Rechner, Port x, Entfernter Rechner, Port z)
Ein Serverprozess erzeugt beispielsweise einen Socket (, ) auf Port 80, markiert diesen für eingehende Verbindungen () und fordert vom Betriebssystem die nächste anstehende Verbindung an (). Diese Anforderung blockiert den Serverprozess zunächst, da noch keine Verbindung existiert. Kommt dann die erste Verbindungsanfrage durch einen Client an, wird sie vom Betriebssystem angenommen, so dass die Verbindung zustande kommt. Ab jetzt wird diese Verbindung durch das oben beschriebene Quadrupel identifiziert.
Schließlich wird der Serverprozess aufgeweckt und ihm ein Handle für diese Verbindung überreicht. Üblicherweise startet der Serverprozess anschließend einen Kindprozess, zu dem er die Behandlung der Verbindung delegiert. Er selbst setzt dann seine Arbeit mit einer weiteren Accept-Anforderung an das Betriebssystem fort. Dadurch ist es möglich, dass ein Webserver mehrere Verbindungen von verschiedenen Rechnern annehmen kann. Mehrfaches auf demselben Port ist nicht möglich. Üblicherweise bestimmt das Programm auf der Clientseite den Port nicht selbst, sondern lässt ihn sich vom Betriebssystem zuweisen.
Ports sind 16-Bit-Zahlen (Portnummern) und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert und werden von der IANA vergeben, z. B. ist Port 80 für das im WWW verwendete HTTP reserviert. Das Benutzen der vordefinierten Ports ist nicht bindend. So kann jeder Administrator beispielsweise einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen anderen Port laufen lassen.
Verbindungsaufbau und -abbau mini|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 oder auch als 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 () 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 (deutsch: „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.W. Richard Stevens: TCP/IP Illustrated. Vol. 1: The Protocols. Addison-Wesley, Kapitel 18.
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 mini|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. ‚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 mini|TCP-Teardown
Der geregelte Verbindungsabbau erfolgt ähnlich. Statt des SYN-Bits kommt das FIN-Bit (von ‚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.