TCP liegt in den Schichten oberhalb von IP, der Transportschicht. TCP setzt ausschließlich auf IP auf. Das TCP arbeitet im Gegensatz zum IP verbindungsorientiert, was heißt, dass vor dem Übertragen von Datenpaketen eine bidirektionale virtuelle Verbindung auf und später wieder abgebaut wird. Während in den Schichten unterhalb vom TCP kaum Überlegungen hinsichtlich möglicher Verluste ganzer Datenpakete angestellt werden, wird dies hier berücksichtigt. Das TCP überträgt aus Sicht des Dienstnutzers einen kontinuierlichen, aus Bytes bestehenden Datenstrom in beliebige Richtungen. Dabei legt es die Blockgrößen und das Weiterleiten von Daten selbst fest. Die Daten werden gesichert durch:
Der TCP Header hat eine Länge von mindestens 20 Byte und gliedert sich wie folgt auf:
Feldinhalt | Bit | Beschreibung |
---|---|---|
Source Port | 16 | Beschreibt den Quellport des Paketes |
Destination Port | 16 | Beschreibt den Zielport des Paketes |
Sequenz Number | 32 | Bei jeder TCP-Verbindung werden Nummern zwischen den Kommunikationspartner ausgehandelt. Während der Verbindung werden diese Nummern verwendet um die TCP-Pakete eindeutig zu identifizieren |
Acknowledgement Number | 32 | Alle Datenpakete werden bestätigt. Dazu dient das ACK-Flag und die Acknowledgement-Nummer, die sich aus der Sequenz-Nummer und der Anzahl von empfangenen Bytes errechnet. Damit kann der Sender feststellen, ob die Daten beim Empfänger vollständig angekommen sind |
Header Length | 4 | Hier steht die Anzahl der 32-Bit-Blöcke des TCP-Headers. Die Mindestmenge beträgt 5 |
Window | 16 | Der Empfänger sendet dem Sender in diesem Feld die Anzahl an Daten, die der Sender senden darf. Dadurch wird das Überlaufen des Empfangspuffers beim Empfänger verhindert. Den Vorgang nennt man Windowing und dient der Datenflusssteuerung |
Checksum | 16 | Dieses Feld dient der Kontrolle von Header- und Datenbereich. |
Urgent Pointer | 16 | Zusammen mit der Sequenz-Nummer gibt dieser Wert die genaue Position der Daten im Datenstrom an. Der Wert ist nur gültig, wenn das URG-Flag gesetzt ist. |
Options | Dieses Feld beinhaltet optionale Informationen. Um die 32-Bit-Grenze einzuhalten wird das Options-Feld mit Nullen aufgefüllt | |
Flags | 6 | Kennzeichnung bestimmter für die Kommunikation und Weiterverarbeitung der Daten wichtiger Zustände (URG, ACK, PSH, RST, SYN, FIN). |
test | test | test |
Neben den Quell- und Zielports sind die TCP-Flags mit die wichtigste Information im TCP-Header, wenn man diesen zur Analyse von Netzwerkproblemen heranzieht. Sie kennzeichnen den Zustand und die Dringlichkeit eines Paket. zB kennzeichnet das SYN-Flag einen Verbindungsaufbau und wird uA von Firewalls ausgewertet um festzustellen ob an dieser Stelle und in diese Richtung ein Verbindungsaufbau unterbunden werden soll oder nicht. Die TCP-Flags definieren sich im Einzelnen wie folgt:
Flag | Bedeutung | Funktion |
---|---|---|
URG | Urgent | Gesetzt, wenn der Urgent-Zeiger genutzt wird |
ACK | Acknowledge | Quittungsnummer ist gültig |
PSH | Push | Der Empfänger wird dazu aufgefordert, die Daten der Anwendung bei Ankunft bereitzustellen und sie nicht erst zwischenzuspeichern |
RST | Reset | Rücksetzen der Verbindung oder Antwort auf ein ungültiges Segment |
SYN | Synchronize | Verbindungsaufbau wird gewünscht: SYN muss mit ACK bestätigt werden. SYN = 1, ACK = 0 für Verbindungsanfrage; SYN = 1, ACK = 1 für Empfangsbestätigung |
FIN | Finish | Wird genutzt um eine Verbindung einseitig abzubauen. FIN muss bestätigt werden; FIN = 1, ACK = 0 Verbindungsabbau-Anfrage; FIN = 1, ACK = 1 Bestätigung |
Der Verbindungsaufbau läuft nach dem Three-Way-Handshake ab. Zuerst schickt der Client an den Server einen Verbindungswunsch (SYN). Der Server bestätigt den Erhalt der Nachricht (ACK) und äußert ebenfalls seinen Verbindungswunsch (SYN). Der Client bestätigt den Erhalt der Nachricht (ACK). Danach erfolgt die Kommunikation zwischen Client und Server.
Das folgende Diagramm zeigt den Ablauf einer TCP Verbindung in Form einer Zustandmaschine. Dabei kennzeichnet die fette Linie den normalen Pfad des Clients und die fett gestrichelte Linie den Pfad des Servers. Feine Linien kennzeichnen ungewöhnliche Ereignisse. Anhand dieses Diagramms soll der Auf- und Abbau einer TCP-Verbindung verdeutlicht werden. Jeder Übergang ist mit einem Ereignis/ Aktion-Paar gekennzeichnet. Die Ereignisse CONNECT, LISTEN, SEND und CLOSE sind Systemaufrufe aus höheren Schichten. Die Aktion besteht im Senden eines Segments mit gesetztem Steuerelement (Flag), wie SYN, ACK, FIN, RST. Keine Aktion ist durch - gekennzeichnet.
Zuerst wird der Pfad des Clients verfolgt. Im Startzustand CLOSED erfolgt ein CONNECT-Aufruf der Clientmaschine. TCP sendet ein SYN-Segment und wechselt in den Zustand SYN SENT. Darauf wird auf den Empfang eines SYN+ACK des Servers gewartet und dies wiederum mit einem ACK bestätigt. Es wird also der Empfang einer Bestätigung nochmals bestätigt. Dieser Mechanismus wird 3-Wege-Handshake genannt. Er erkennt sowohl den Verlust einer Nachricht, als auch den Verlust einer Bestätigung. Durch die Verwendung von Sequenz- und Quittungsnummern kann gewährleistet werden, dass es sich nicht um irgendein ACK handelt, sondern um die Antwort des Servers auf die vorangegangene Anfrage. Nach erfolgreichem 3-Wege-Handshake befindet sich der Automat im Zustand ESTABLISHED. Nun können Daten übertragen werden.
Nach der Datenübertragung beendet die Anwendung die Verbindung durch die CLOSE-Operation. Der Client sendet ein FIN-Segment und wechselt in den Zustand FIN WAIT 1. Kommt ein ACK vom Server, wird die Verbindung in einer Richtung geschlossen und der Zustand wechselt zu FIN WAIT 2. Schließt auch die andere Seite die Verbindung, wird ein FIN vom Client empfangen, das bestätigt wird. Wenn beide Seiten geschlossen sind, wartet TCP die maximale Lebensdauer eines Pakets ab, um sicherzustellen, dass alle Pakete empfangen wurden.
Der Pfad des Servers beginnt mit einer LISTEN-Operation der Anwendung. Der Server wartet auf ein SYN vom Client und nach einem erfolgreichen 3-Wege-Handshake befindet er sich im Zusand ESTABLISHED. Die Verbindung ist aufgebaut.
Hat der Client kein Interesse mehr an einer Datenübertragung, empfängt der Server FIN und sendet sein ACK. Wird der Server seitens der Anwendung ebenfalls geschlossen, sendet er ein FIN zum Client. Kommt die Bestätigung des Clients an, schließt der Server die Verbindung und löscht den Datensatz.
— pronto 2010/03/31 18:44