Transmission Control Protocol (TCP)

  

Abbildung 2.15: TCP-Protokollkopf

Quelle: [32]

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:

• Sequenznummern
• Prüfsummenbildung mit Empfangsquittungen
• Quittung mit Zeitüberwachung
• Segmentwiederholung nach Quittungszeitablauf

Ein TCP-Segment besteht aus dem festen Protokollkopf von 20 Bytes, Optionen und Daten. Abbildung 2.15 zeigt den TCP-Protokollkopf. Die einzelnen Felder enthalten folgende Informationen:

 

 

Tabelle 2.1: Flags im TCP-Protokollkopf

Kürzel	engl. 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 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

• Sender- und Empfänger-Port: Zwei 16 Bits breite Portnummern, welche die Endpunkte der virtuellen Verbindung bezeichnen. Hostrechner können mehrere TCP-Verbindungen über verschiedene Kanäle (engl. ports) aufbauen. Jeder Dienst einer höheren Schicht muss eine Portnummer für die Kommunikation festlegen. Über diese Nummer adressiert der Kunde (engl. client) den Server, der den Dienst bereitstellt. Teilweise sind für bestimmte Anwendungen, wie z. B. TELNET oder FTP^2.19, vordefinierte Portnummern festgelegt.
• Sequenz- und Quittungsnummer: Jeweils ein 32 Bit Wort, das die Anzahl der Daten-Bytes angibt, die über die Verbindung gesendet wurden. Die Sequenznummer gilt für die Senderichtung, die Quittungsnummer für die Empfangsrichtung.
• Datenabstand: Länge des TCP-Protokollkopfes in 32-Bit-Worten. Dient zur Bestimmung des Datenbeginns.
• Flags: Mit Hilfe dieser sechs Flags werden Aktionen in der TCP-Protokollmaschine ausgelöst (siehe Tabelle 2.1).
• Fenstergröße: Enthält die Zahl der Bytes, die der Empfänger in seinem Datenpuffer augenblicklich aufnehmen kann. Mit dieser Angabe steuert der TCP-Empfänger den Datenfluss, eine Fenstergröße von 0 würde den TCP-Sender stoppen.
• Prüfsumme: Bildet eine Prüfsumme aus den Informationen im TCP-Protokollkopf, den Daten und einem Teil des IP-Protokollkopfes. Dieser Pseudo-IP-Protokollkopf besteht aus Internet-Sende- und Empfangsadressen, Transportprotokollkennung und Länge des Datenpakets.
• Urgent-Zeiger: Zusammen mit der Sequenznummer ergibt der Urgent-Pointer einen Zeiger auf ein Datenbyte. Somit wird der Anfang eines Datenpaketes referenziert, das besonders wichtig ist. Dieser Mechanismus dient zum Signalisieren eines außergewöhnlichen Zustands, z. B. ein Programmabbruch oder Ähnliches.
• Optionen: Dieses Feld bietet die Möglichkeit, zusätzliche Funktionen bereitzustellen, die im normalen Header nicht verfügbar sind. Die wichtigste Option erlaubt jedem Host, seine maximale Größe der TCP-Nutzdaten zu spezifizieren, die er annehmen kann.

  

Abbildung 2.16: TCP-Verbindungsmanagement als Zustandsautomat

Quelle: [39], Seite 553

Abbildung 2.16 zeigt das TCP-Verbindungsmanagement in Form einer Zustandsmaschine. 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.

  

Abbildung 2.17: Schematische Darstellung des Sliding-Window-Prinzips als Zeitfolgediagramm

Quelle: [39]

Das TCP-Protokoll verwendet das Prinzip des ,,Sliding Window``. Einfache Protokolle senden z. B. einen Datenblock und warten auf Bestätigung, bevor sie ein neues Datenpaket verschicken. Das Sliding-Window-Prinzip erlaubt jedoch, mehrere Segmente ohne Bestätigung zu versenden. Die Anzahl der Bytes, die versendet werden dürfen, wird durch die Fenstergröße festgelegt. Während des Sendevorgangs können gleichzeitig Quittungen empfangen werden, die neue Fenstergrößen festlegen. Diese Aufgabe übernimmt das Feld Fenstergröße im TCP-Protokollkopf. Dieses Prinzip ist vor allem bei Übertragungsstrecken mit großer Laufzeit sinnvoll, da sonst die Übertragungsbandbreite durch das Warten des Senders auf die Bestätigung nicht genutzt werden kann. Abbildung 2.17 zeigt das Sliding-Window-Prinzip in einem Zeitfolgediagramm.
Die Zeitüberwachung spielt im TCP-Protokoll eine große Rolle. Es werden folgende Timer gestartet, um die Abläufe zu überwachen:

• Segmentwiederholungs-Timer, dynamische Zeitdauer, veranlasst die Wiederholung eines Segments nach Ablauf des Timers.
• Persistenz-Timer, ca. 5 Sekunden, überprüft die Gegenseite durch Senden eines Minipaketes, wenn das Empfangsfenster gleich null ist.
• Quiet-Time-Timer, ca. 30 Sekunden, gibt Ports nach Abbau einer Verbindung erst nach Ablauf des Timers wieder frei.
• Keep-Alive-Timer, ca. 45 Sekunden, überprüft den Zustand der Gegenseite durch Senden eines Paketes.
• Idle Timer, ca. 360 Sekunden, bricht die Verbindung nach Ablauf ab, wenn der Keep-Alive-Timer keine Antwort erhalten hat.

Durch die dynamische Manipulation der Fenstergröße und Zeitüberwachung durch Timer, wird im TCP-Protokoll eine Überlastungsüberwachung realisiert. Bei Aufbau einer Verbindung muss eine geeignete Fenstergröße gewählt werden. Der Empfänger kann ein Fenster z. B. auf Grundlage seiner Puffergröße spezifizieren. Hält sich der Sender an diese Größe, können Übertragungsprobleme nicht aufgrund eines Pufferüberlaufs am Empfangsende auftreten. Ein Timeout im TCP ist deshalb entweder auf einen Paketverlust oder auf eine Überlastung des Netzes zurückzuführen. Häufen sich die Timeouts, müssen die Fenstergröße und die Timeouts, die eine Wiederholung des Segments bewirken, entsprechend angepasst werden. Dadurch wird einer Überlastung entgegengewirkt.
Das TCP ist ein kompliziertes Protokoll mit mehreren Optionen und vielen Erweiterungen. Für den Einsatz von TCP als Kommunikationsprotokoll für diese Internetkamera sind diese Zusatzfunktionen uninteressant. Sie werden deshalb an dieser Stelle nicht beschrieben.