Transmission Control Protocol

TCP (Transmission Control Protocol) ist ein Netzwerkprotokoll, das definiert, auf welche Art und Weise Daten zwischen Netzwerk/Hardwaren ausgetauscht werden sollen.

Beschreibung

Ist ein zuverlässiges, verbindungsorientiertes, paketvermitteltes (nicht paketvermittelnd) Transportprotokoll.

TCP ermöglicht die Übertragung eines Datenstroms.
Im Unterschied zum verbindungslosen User Datagram Protokoll (UDP) stellt TCP eine Verbindung zwischen zwei Endpunkten (Sockets) einer Netzverbindung her.
Auf dieser Verbindung können in beide Richtungen Daten übertragen werden.

Vorteile

Netzwerküberlastungskontrolle.
Zuverlässige Datenübertragung:
- erkennt verlorene, doppelte und fehlerhafte Segmente.

Allgemeines

TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex.
Kann auch als zwei Halbduplexverbindungen betrachtet werden (Informationsfluss in beide Richtungen (allerdings nicht gleichzeitig)).
Die Daten in Gegenrichtung können zusätzliche Steuerungsinformationen enthalten.
Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver.

TCP-Software

Übernimmt Verbindungsverwaltung sowie die Datenübertragung.
Netz-Protokollstack des Betriebssystems.
Anwendungsprogramme nutzen Sockets.

Entwicklung

Entwickelt von Robert E. Kahn und Vinton G. Cerf als Forschungsarbeit.
Beginn 1973, erste Standardisierung 1981 als RFC 793.
Danach gab es viele Erweiterungen, diese werden bis heute in RFCs spezifiziert.

Das Transmission Control Protocol arbeitet auf dem OSI-04
TCP verwendet 16-Bit Portnummern zur Adressierung
Zusätzlich zur Adressierung übernimmt es weitere Aufgaben
Verbindungsmanagement (Three-Way-Handshake)
Verbindungsaufbau/-abbau
Fehlerkontrolle (-korrektur)
Flußkontrolle (Flow Control)
verhindert, dass der Empfänger von einem Sender schneller Daten erhält, als er entgegennehmen kann
Netzwerk-Überlastkontrolle (Congestion Control)
verhindert, dass es zu einer Überlastsituation im Netz kommt, die zum vollständigen Zusammenbruch des Netzes führen könnte (congestion collapse)
bei Erkennen einer Überlastsituation (Paketverlust!) wird vom Sender die Datenrate gedrosselt
transparente Übertragung von byte streams
Anwendungen, die TCP benutzen, sollen nicht merken, dass die Daten in Form von Paketen übertragen werden.
Mutliplexing
Mehrfachnutzung einer Verbindung
Verbindungsorientiertes Protokoll
Beinhaltet verschiedene Algorithmen zur Fehlererkennung und -behandlung
Sequenznummern
Quittungsnummern
Anzeigen (Flags)
Die richtige Reihenfolge der Daten ist garantiert
Bietet der Anwendungsschicht einen zuverlässigen Transportdienst
RFC 793. J. Postel. Transmission Control Protocol. 1981.
setzt direkt auf dem Internet Protokoll (IP) auf
IP Protokoll Nr.: 06
Theoretisch ist es möglich TCP mit einem beliebigen Protokoll der Schicht 3 zu kombinieren
Praktisch wird TCP allerdings immer in IP gekapselt
garantiert eine fehlergesicherte, zuverlässige Transportverbindung zwischen zwei Rechnersystemen (Ende zu Ende Kontrolle)

TCP im DoD-Modell

Rolle von TCP im OSI-Referenzmodell

Eigenschaften von TCP

Vollduplex-Verbindung
stellt eine “byte pipe” zur Verfügung - unstrukturierter Datenstrom
Folgenummern sind Bytenummern
Sliding Window-Protokoll
Variable Grösse des Sendefensters bestimmt durch das Maximum von:
Angabe des Empfängers (receiver window size)
Congestion window size, abhängig von einer lokalen Schätzung der Netzbelastung -> “Slow Start” Algorithmus

Basismechanismen

Unterteilt den byte stream in Einheiten
die jeweils in einem IP Paket übertragen werden, diese Einheiten heißen Segmente
Segmente haben eine variable Länge
Die maximale Segmentgrösse wird bei der Verbindungserstellung festgelegt
Jedes Segment hat eine Folgenummer, die seine Position im Datenstrom in Bytes spezifiziert.
Abgesendete Segmente müssen innerhalb einer bestimmten Zeit bestätigt werden (adaptiv geschätzte Round Trip Time).
Bestätigungen werden verzögert gesendet (ca. 200 ms)
Wenn keine Bestätigung über den erfolgreichen Empfang dieses Paketes innerhalb der Timer-Laufzeit eintrifft, wird die Übertragung wiederholt.
Jedes Segment hat eine Ende-zu-Ende-Prüfsumme
Fehlerhaft empfangene Segmente werden ignoriert.
Empfänger ordnet empfangene Segmente entsprechend ihrer Folgenummer
Duplikate werden ignoriert.

Socket-Schnittstelle

De-facto-Standard für TCP/IP Programmierschnittstelle
Zugang zu TCP, UDP und (eingeschränkt) IP
Unterstützung verschiedener Protokolle
Protocol familiy
Address familiy
Abstraktion für Kommunikationsendpunkte
sockets

… mit verschiedenen Kommunikationseigenschaften

socket types (stream socket, datagram socket)
Benennung/Adressierung von Kommunikations-endpunkten
name binding
Können benutzt werden wie Dateideskriptoren

Verbindungen und Verbindungsendpunkte

Eine TCP-Verbindung wird durch ein Paar von Adressen und Port-Nummern identifiziert (Verbindungsendpunkte):
IP-Adresse und Port-Nummer Host A
IP-Adresse und Port-Nummer Host B
Jede Verbindung wird durch ein Paar von Verbindungsendpunkten eindeutig identifiziert
mehrere Verbindung zwischen den gleichen Hosts sind dadurch gleichzeitig möglich.

Segmente, Datenströme und Sequenznummern

Erhaltung der Reihenfolge
Nummerierung:
Zufallszahl auf beiden Seiten (32 Bit)
Seq.nr. := Initiale Seq.nr. + Byte-Position im Datenstrom
TCP betrachtet einen Datenstrom als Sequenz von Bytes, die für die Übertragung in TCP-Segmente eingeteilt werden.
Jedes Segment wird dann in der Regel auf ein IP-Paket abgebildet.
Größe eines Segmentes bei lokaler Übertragung gemäß physikalischem Netz (MTU)
Ist diese nicht angegeben oder kann sie nicht ermittelt werden, dann wird ein Standartwert von 536 Bytes verwandt

Allgemeines

TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex, welche 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 (socket bind) auf Port 80, markiert diesen für eingehende Verbindungen (listen) und fordert vom Betriebssystem die nächste anstehende Verbindung an (accept).

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 listen 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 (Well Known Ports 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.

Header

Transmission Control Protocol/Header

Ports

siehe Port

Verbindungsverwaltung

siehe Transmission Control Protocol/Verbindungsverwaltung

TCP-Prüfsumme und TCP-Pseudo-Header

siehe Transmission Control Protocol/Prüfsumme

Datenintegrität und Zuverlässigkeit

Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten.

Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können.
TCP wurde entwickelt, um mit der Unsicherheit der darunterliegenden Schichten umzugehen.
Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher.
Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft.
Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen.

Der Datentransfer kann selbstverständlich jederzeit nach dem „Aufbau einer Verbindung“ gestört, verzögert oder ganz unterbrochen werden.

Das Übertragungssystem läuft dann in einen Timeout.
Der vorab getätigte „Verbindungsaufbau“ stellt also keinerlei Gewähr für eine nachfolgende, dauerhaft gesicherte Übertragung dar.

Bestätigungen

Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (windowing).

Dadurch ist das Ausnutzen der Netz-Bandbreite auch bei großen Strecken möglich.
Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten ACK-Signals aus technischen Gründen bisweilen mehrere 100 Millisekunden, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden.
Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft.
Alle Pakete im Puffer können gemeinsam bestätigt werden.
Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält.

Anhang

Siehe auch

Dokumentation

RFC

RFC 793 (Transmission Control Protocol)
RFC 1071 (Berechnen der Prüfsumme für IP, UDP und TCP)
RFC 1122 (Fehlerbehebungen bei TCP)
RFC 1323 (Erweiterungen bei TCP)
RFC 2018 (TCP SACK – Selective Acknowledgment Options)
RFC 3168 (Explicit Congestion Notification)
RFC 5482 (TCP User Timeout Option)
RFC 5681 (TCP Congestion Control – TCP-Überlastkontrolle)
RFC 7414 (Übersicht zu TCP RFCs)
RFC 793 (1981)
RFC 7323 (2014)

RFC	Titel
793	Transmission Control Protocol
0000	Beschreibung

Man-Pages

Info-Pages

Links

Projekt

Weblinks

Congestion Avoidance and Control
Warriors of the net (Film zu TCP)