TCP

Das TCP (Transmission Control Protocol) stellt eine Verbindung zwischen 'Endverbrauchern' also in der Regel zwischen in Ausführung befindlichen Programmen auf unterschiedlichen Rechnern in unterschiedlichen Netzen zur Verfügung. Diese Eigenschaft fehlt auf der datagrammorientierten IP-Ebene. TCP geht von einem fortlaufenden Bytestrom aus den höheren Schichten aus und zerlegt diesen in sogenannte Segmente mit einer Länge von bis zu 65K Byte. TCP muss folgendes gewährleisten:

• Der Anwendungs-Prozess bzw dessen Protokoll (ULP, upper layer protocol) muss sich gegenüber TCP mit Hilfe einer Port-Adresse - auch als Socket bekannt - identifizieren. Beispiele sind FTP (21), TELNET (23), SMTP(25) oder HTTP (80). Eine ULP Verbindung kann damit vollständig durch ihre Port-Adresse (16-Bit) und ihre IP-Adresse (32 Bit) beschrieben werden.
  
  
• Die Fehlerkontrolle muss die richtige Reihenfolge der übermittelten Informationen garantieren, sowie das Fehlen und die Duplizität von Informationen erkennen können.
  
  
• Die Flusskontrolle muss sicherstellen, dass ein schneller Sender nicht einen langsamen Sender überschwemmt.
  
  
• Das Verbindungsmanagement muss Funktionen zur Verfügung stellen, mit denen eine Ende-zu-Ende Verbindung aufgebaut, beendet, unterbrochen und unterhalten werden kann.

TCP ist ist formell im RFC 793 definiert. Im Laufe der Zeit wurden verschiedene Fehler und Inkonsistenzen gefunden. Ebenso haben sich Erweiterungen als nötig erwiesen. Die Fehlerkorrekturen und Erweiterungen sind im RFC 1122 bzw. im RFC 1323 beschrieben.

Ein Socket kann für mehrere Verbindungen gleichzeitig genutzt werden, d.h zwei oder mehr Verbindungen enden auf dem gleichen Socket. Portnummern unter 256 nennt man gut bekannte Ports (well known Ports). Diese Portnummern sind für die Standarddienste reserviert, Beispiele siehe oben. Eine Liste der gut bekannten Ports ist im RFC 1700 enthalten. Portnummern werden für TCP und UDP getrennt vergeben.

Eine schöne Veranschaulichung von Netzen, Hostadressen und Portnummern geben (Scheller, et al. 1994): In Analogie zum Telefonsystem stehen Portnummern auf der gleichen Stufe wie Nebenstellenanlagen. Die Netzadresse entspricht dabei der Ortsvorwahl, die Hostadresse der Rufnummer und der Port entspricht der Durchwahl des Teilnehmers.

TCP-Verbindungen sind immer Vollduplex und Punkt-zu-Punkt. Vollduplex bedeutet, daß Verkehr gleichzeitig in beide Richtungen fliessen kann. Punkt-zu-Punkt bedeutet, dass jede Verbindung genau zwei Endpunkte hat. TCP unterstützt weder Multicasting noch Broadcasting. Eine TCP-Verbindung ist ein Bytestrom, kein Nachrichtenstrom. Die Grenzen von Nachrichten werden nicht von Ende-zu-Ende beibehalten, d.h. der Empfänger kann nicht erkennen , in welchen Einheiten die Daten geschrieben wurden.

Die sendende und die empfangende TCP-Einheit tauschen Daten in Form von Segmenten aus. Ein Segment besteht aus einem festen 20-Byte-Header, einem optionalen Teil und den Datenbytes. Die TCP-Software entscheidet über die Segmentgröße. Sie kann Daten vom mehreren Schreiboperationen zu einem Segment zusammenfassen oder Daten aus einem Schreibvorgang zu einem Segment zusammenfassen oder auf mehrere Segmente aufteilen. Die Segmentgröße wird durch zwei Faktoren beschränkt:
Erstens muß jedes Segment, einschließlich des TCP-Headers in das IP-Nutzdatenfeld von 65535 Bytes passen. Zweites hat jedes Netz eine maximale Transfereinheit (MTU, Maximum Transfer Unit) in die jedes Segment passen muss. Normalerweise ist die MTU einige tausend Bytes gross und gibt die obere Grenze der Segmentlänge an. Genau wie bei den IP-Datagrammen müssen TCP-Segmente beim Durchlauf durch Netze mit kleinerer MTU vom entsprechenden Router fragmentiert werden. Jedes neue Segment erhält einen eigenen TCP- und IP-Header, so dass die Fragmentierung zusätzliche Belastung (jeweils 40 Byte) für das Übertragungsnetz bedeutet, ohne das der Durchsatz gesteigert wird.
TCP-Segmente benutzen das Sliding-Windows-Protokoll zur Flusskontrolle. Überträgt ein Sender ein Segment, startet er gleichzeitig einen Timer. Kommt nicht innerhalb einer vorbestimmten Zeitspanne ein Segment mit einer Bestätigungsnummer zurück, wird das Segment erneut übertragen. Es wird nun nicht extra zu diesem Bestätigungszweck ein Segment erzeugt, sondern die Bestätigungsnummer - die die Nummer des nächsten erwarteten Segmentes entspricht - wird huckepack mit dem nächsten Datensegment zurückgeschickt. Daher spricht man beim Sliding-Window-Protokoll auch von einem Piggyback-Verfahren (Tanenbaum, 1998). Auf die Feinheiten dieses Algorithmus - insbesonders im Zusammenhang mit der Segmentverdoppelung wegen vorzeitig abgelaufener Timer oder wegen Fragmentierung und Ausfall einiger Segmente - soll hier nicht eingegangen werden. In (Tanenbaum, 1998) und in (Tanenbaum, et al. 1995) finden sich Diskussionen dieser Problematik.

Nachfolgend soll analog zum IP-Datagramm-Header der Aufbau eines TCP-Headers schematisch wiedergegeben werden (Tanenbaum, 1998 und Miller, 1991).

Erläuterung:

Nach den 20-Bytes Kopfinformationen mit fest vorgegebenem Format folgen die Header-Optionen. Den Optionen können 65535-20-20=65515 Datenbytes folgen. Der zweite 20-Byte-Summand gehört zum IP-Header. Segmente ohne Daten sind zulässig und werden für Bestätigungen oder als Steuernachricht verschickt.

• Die Felder Source und Destination Port identifizieren die lokalen Endpunkte der Verbindung. Jeder Host kann selbst festlegen, wie er seine eigenen Ports oberhalb 256 zuweist. Ein Port plus IP-Adresse seines Hostes bildet einen eindeutigen 48 Bit langen TSAP (Transport Service Access Point).
  
  
• Die Sequence Number stellt das korrekte Eintreffen und die richtige Reihenfolge der Daten sicher. Das Feld ist mit der Nummer des ersten Bytes im TCP-Datenblock belegt.
  
  
• Die Acknowledgement Number trägt die Folge-Nummer des nächsten erwarteten Bytes. Beide Felder sind 32 Bit lang, weil in einem TCP Datenstrom jedes Datenbyte (=65515) einzeln numeriert ist.
  
  
• Das Feld TCP-Header-Length gibt an, wieviel 32 Bit Worte im TCP Header enthalten sind. Dies ist wegen der Variabilität der Länge des Optionsfeldes erforderlich. Die Header-Length ist gleichzeitig der Offset der Daten im Segment.
  
  
• Auf sechs unbenutzte Bits folgen sechs 1-Bit-Flags.
  
  
  • U ist 1 wenn der Urgent-Pointer benutzt wird. Der Urgent-Pointer bezeichnet einen Byteversatz von der aktuellen Folgenummer, an der dringend zu verarbeitende Daten vorgefunden werden können. Diese Funktion ersetzt einen Interrupt.
    
    
  • A ist 1 wenn die Acknowledgement Number gültig ist. Ist A=0 wird das Feld Acknowledgement Number ignoriert.
    
    
  • P bezeichnet Push-Daten. Der Empfänger wird mit P=1 aufgefordert die Daten sofort der Anwendung bereitzustellen und sie erst dann zwischenzuspeichern wenn der Empfangs-Puffer voll ist.
    
    
  • R bedeutet Reset und fordert den Empfänger zum Rücksetzen z.B. nach einer Störung auf. R wird auch benutzt um ein ungültiges Segment oder einen Verbindungsversuch abzuweisen.
    
    
  • S wie Syn wird beim Aufbau einer Verbindung benutzt. Die Verbindungsanfrage (Connection Request) benutzt Syn=1 und Ack=0, die Verbindungsantwort (Connebtion Accepted) benutzt Syn=1 und Ack=1.
    
    
  • F wie Fin wird benutzt eine Verbindung abzubauen. Der Sender signalisiert damit dass er keine Daten mehr zu übertragen hat.
  
  
  
• Das Window-Feld bezeichnet die Länge des Sliding Windows mit variabler Größe. Das Window Feld bezeichnet, wieviele Bytes ab dem zuletzt bestätigten Byte gesendet werden können bis auf die nächste Bestätigungs-Nummer gewartet werden muß.
  
  
• Das Checksum-Feld sichert den Header und die Daten. Das Checksum-Feld selbst wird zur Berechnung der Checksumme auf 0 gesetzt. Besitzt das Datenfeld einen ungerade Länge wird es mit einer angehängten 0 aufgefüllt. Zur Berechnung der Checksumme werden alle 16-Bit-Worte im Einserkomplement addiert. Führt der Empfänger die Berechnung für das ganze Segment einschliesslich des Checksum-Feldes durch, sollte das Ergebnis 0 sein.
  
  
• Das Optionsfeld soll genau wie im IP-Header eine Möglichkeit bieten Funktionen bereitzustellen die im normalen Header nicht verfügbar sind. Die wichtigste Option dient dazu die maximale Nutzdatenlänge zwischen zwei Hosts auszuhandeln. Die Benutzung großer Segmente ist offenbar effizienter weil der 20 Byte Header dann besser amortisiert wird. Während des Verbindungsaufbaues gibt jede Seite ihre Maximum bekannt. Die kleinere der beiden Zahlen 'gewinnt'. Wird von einer Seite nichts spezifiziert wird die 536-Byte Vorgabe benutzt. Alle Internet Hosts müsen TCP-Segmente von 536+20=556 Byte akzeptieren.