Das Transmission Control Protocol (TCP) ist ein zuverlässiges, verbindungsorientiertes, Bytestrom Protokoll. Die Hauptaufgabe von TCP besteht in der Bereitstellung eines sicheren Transports von Daten durch das Netzwerk. TCP ist im RFC 793 definiert. Diese Definitionen wurden im Laufe der Zeit von Fehlern und Inkonsistenzen befreit (RFC 1122) und um einige Anforderungen ergänzt (RFC 1323).

Im weiteren sollen nun die oben genannten Eigenschaften des Transmission Control Protocol - zuverlässig (reliable), verbindungsorientiert (connection-oriented), Bytestrom (byte-stream) - näher betrachtet werden.

Das Transmission Control Protocol stellt die Zuverlässigkeit der Datenübertragung mit einem Mechanismus, der als Positive Acknowledgement with Re-Transmission (PAR) bezeichnet wird, bereit. Dies bedeutet nichts anderes als das, daß das System, welches Daten sendet, die Übertragung der Daten solange wiederholt, bis vom Empfänger der Erhalt der Daten quittiert bzw. positiv bestätigt wird. Die Dateneinheiten, die zwischen den sendenden und empfangenden TCP-Einheiten ausgetauscht werden, heißen Segmente. Ein TCP-Segment besteht aus einem mindestens 20 Byte großen Protokollkopf (s.u. Der TCP-Header) und den zu übertragenden Daten. In jedem dieser Segmente ist eine Prüfsumme enthalten, anhand derer der Empfänger prüfen kann, ob die Daten fehlerfrei sind. Im Falle einer fehlerfreien Übertragung sendet der Empfänger eine Empfangsbestätigung an den Sender. Andernfalls wird das Datengramm verworfen und keine Empfangsbestätigung verschickt. Ist nach einer bestimmten Zeitperiode (timeout-period) beim Sender keine Empfangsbestätigung eingetroffen, verschickt der Sender das betreffende Segment erneut. Näheres zur Zeitüberwachung siehe [Sa94].

TCP ist ein verbindungsorientiertes Protokoll. Verbindungen werden über ein Dreiwege-Handshake (three-way handshake) aufgebaut. Über das Dreiwege-Handshake werden Steuerinformationen ausgetauscht, die die logische Ende-zu-Ende-Verbindung etablieren. Zum Aufbau einer Verbindung sendet ein Host (Host 1) einem anderen Host (Host 2), mit dem er eine Verbindung aufbauen will, ein Segment, in dem das SYN-Flag (s.u. Der TCP-Header - Flags) gesetzt ist. Mit diesem Segment teilt Host 1 Host 2 mit, das der Aufbau einer Verbindung gewünscht wird. Die Sequenznummer des von Host 1 gesendeten Segments gibt Host 2 außerdem an, welche Sequenznummer Host 1 zur Datenübertragung verwendet. Sequenznummern sind notwendig, um sicherzustellen, daß die Daten vom Sender in der richtigen Reihenfolge beim Empfänger ankommen. Der empfangende Host 2 kann die Verbindung nun annehmen oder ablehnen. Nimmt er die Verbindung an, wird ein Bestätigungssegment gesendet. In diesem Segment sind das SYN-Bit und das ACK-Bit (s.u. Der TCP-Header - Flags) gesetzt. Im Feld für die Quittungsnummer bestätigt Host 2 die Sequenznummer von Host 1, dadurch, daß die um Eins erhöhte Sequenznummer von Host 1 gesendet wird. Die Sequenznummer des Bestätigungssegments von Host 2 an Host 1 informiert Host 1 darüber, mit welcher Sequenznummer beginnend Host 2 die Daten empfängt. Schlußendlich bestätigt Host 1 den Empfang des Bestätigungssegments von Host 2 mit einem Segment, in dem das ACK-Flag gesetzt ist und die um Eins erhöhte Sequenznummer von Host 2 im Quittungsnummernfeld eingetragen ist. Mit diesem Segment können auch gleichzeitig die ersten Daten an Host 2 übertragen werden. Nach dem Austausch dieser Informationen hat Host 1 die Bestätigung, daß Host 2 bereit ist Daten zu empfangen. Die Datenübertragung kann nun stattfinden. Eine TCP-Verbindung besteht immer aus genau zwei Endpunkten (Punkt-zu-Punkt-Verbindung).

Dreiwege-Handshake (hier Verbindungsaufbau).

Zum Beenden der Verbindung tauschen die beiden Host wiederum einen Dreiwege-Handshake aus, bei dem das FIN-Bit (s.u. Der TCP-Header - Flags) zum Beenden der Verbindung gesetzt ist. Natürlich verläuft der Verbindungsaufbau nicht immer ohne Probleme. Eine Reihe interessanter Betrachtungen ist zu finden in [Ta96].

TCP nimmt Datenströme von Applikationen an und teilt diese in höchsten 64 KByte große Segmente auf (üblich sind ungefähr 1.500 Byte). Jedes dieser Segmente wird als IP-Datengramm verschickt. Kommen IP-Datengramme mit TCP-Daten bei einer Maschine an, werden diese an TCP weitergeleitet und wieder zu den ursprünglichen Byteströmen zusammengesetzt. Die IP-Schicht gibt allerdings keine Gewähr dafür, daß die Datengramme richtig zugestellt werden. Es ist deshalb, wie oben bereits gesagt, die Aufgabe von TCP für eine erneute Übertragung der Daten zu sorgen. Es ist aber auch möglich, daß die IP-Datengramme zwar korrekt ankommen, aber in der falschen Reihenfolge sind. In diesem Fall muß TCP dafür sorgen, daß die Daten wieder in die richtige Reihenfolge gebracht werden. Hierfür verwendet TCP eine Sequenznummer und eine Bestätigungsnummer (siehe: Der TCP-Header - Sequence Number, Acknowledgement Number).

TCP ist außerdem dafür verantwortlich, die empfangenen Daten an die korrekte Applikation weiterzuleiten. Zur Adressierung der Anwendungen werden auf der Transportebene deshalb sogenannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit groß; theoretisch kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen aufbauen. Auch UDP verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig zwischen den Transportprotokollen - die Transportprotokolle haben jeweils eigene Adreßräume. Das bedeutet TCP und UDP können die gleichen Portnummern belegen. Das heißt, daß die Portnummer 53 in TCP nicht identisch mit der Portnummer 53 in UDP ist. Der Gültigkeitsbereich einer Portnummer ist auf einen Host beschränkt.

----- Das passt noch nicht ganz...
Eine IP-Adresse zusammen mit der Portnummer spezifiziert einen Kommunikationsendpunkt, einen sogenannten Socket. Die Socketnummern von Quelle und Ziel identifizieren die Verbindung (socket1, socket2). Eine Verbindung ist durch die Angabe dieses Paares eindeutig identifiziert. Möchte z.B. ein Host A eine Verbindung zu einem entfernten Host B aufnehmen, z.B. um den Inhalt einer Webseite anzuzeigen, so wird auf der TCP-Schicht als Zielport die Portnummer 80 für das Hypertext Transfer Protocol (http) angegeben. Host A, der den Dienst auf Port 80 von Host B in Anspruch nehmen möchte gibt als Quellport eine dynamische Portnummer (s.u.) aus dem Bereich 49.152 - 65.535 an, damit die von ihm gewünschten Daten von Host B an ihn zurückgeliefert werden können. Damit ist die Verbindung auf der TCP-Schicht über die Angabe von Quell- und Zielport eindeutig identifiziert. Zusammen mit den IP-Adressen bilden die Portnummern die beiden Sockets, die die Kommunikation zwischen Host A und Host B eindeutig kennzeichnen.
-----

Bis 1992 waren Portnummern unter 256 für gut bekannte Ports (well-known ports) reserviert. Well-known Ports werden für Standarddienste, wie z.B telnet, ftp etc. genutzt. Ports zwischen 256 und 1023 wurden im allgemeinen für UNIX-spezifische Dienste (wie z.B. rlogin) benutzt. Ein Beispiel für den Unterschied zwischen einem Internet-weiten Dienst und einem UNIX-spezifischen Dienst ist der Unterschied zwischen Telnet und RLogin. Beide Dienste erlauben es, sich über das Netz auf einem entfernten Host einzuloggen. Telnet ist ein TCP/IP-Standard mit der Portnummer 23 und kann von so gut wie auf allen Betriebssystemen implementiert werden. RLogin ist im Gegensatz dazu ein UNIX-spezifischer Dienst, dessen Portnummer 53 ist.
Die Verwaltung der Portnummern ist nun auch von der Internet Assigned Numbers Authority (IANA) [http://www.iana.org] übernommen worden. Portnummern sind dabei in drei Bereiche aufgeteilt worden: well-known ports, registered ports und dynamic ports.

Auf UNIX-Systemen sind Portnummern in der Datei /etc/services definiert. Auszug aus der Datei /etc/services eines Linux-Systems:

        heiko@phoenix:~> more /etc/services 
        #
        # Network services, Internet style
        #
        # Note that it is presently the policy of IANA to assign a single well-known
        # port number for both TCP and UDP; hence, most entries here have two entries
        # even if the protocol doesn't support UDP operations.
        # Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
        # are included, only the more common ones.
        #
        #       from: @(#)services      5.8 (Berkeley) 5/9/91
        #       $Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $
        #
        tcpmux          1/tcp           # TCP port service multiplexer
        echo            7/tcp
        echo            7/udp
        systat          11/tcp          users
        daytime         13/tcp
        daytime         13/udp
        netstat         15/tcp
        qotd            17/tcp          quote
        msp             18/tcp          # message send protocol
        msp             18/udp          # message send protocol
        chargen         19/tcp          ttytst source
        chargen         19/udp          ttytst source
        ftp             21/tcp
        # 22 - unassigned
        telnet          23/tcp
        # 24 - private
        smtp            25/tcp          mail
        # 26 - unassigned
        time            37/tcp          timserver
        time            37/udp          timserver
        rlp             39/udp          resource        # resource location
        nameserver      42/tcp          name            # IEN 116
        whois           43/tcp          nicname
        domain          53/tcp          nameserver      # name-domain server
        domain          53/udp          nameserver
        #
        # UNIX specific services
        #
        exec            512/tcp
        biff            512/udp         comsat
        login           513/tcp
        who             513/udp         whod
        shell           514/tcp         cmd             # no passwords used
        syslog          514/udp
        printer         515/tcp         spooler         # line printer spooler
        talk            517/udp
        ntalk           518/udp
        route           520/udp         router routed   # RIP
        timed           525/udp         timeserver
        

Der TCP-Header.

Die Felder des TCP-Headers haben die folgende Bedeutung:

Source-/Destination-Port:

Die Felder Source Port (Quellport) und Destination Port (Zielport) adressieren die Endpunkte der Verbindung. Die Größe für die beiden Felder beträgt 16 Bit (siehe auch den Abschnitt Portnummern).

Sequence Number, Acknowledgement Number:

Die Sequenznummer und die Bestätigungsnummer sind jeweils 32-Bit-Zahlen. Die Nummern geben die Stellung der Daten des Segments innerhalb des in der Verbindung ausgetauschten Datenstroms an. Die Sequenznummer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der beiden TCP-Verbindungspartner generiert beim Verbindungsaufbau eine Sequenznummer, die sich während des Zeitraums der Verbindung nicht wiederholen darf. Dies ist allerdings durch den großen Zahlenraum von 2³² wohl ausreichend gesichert. Diese Nummern werden beim Verbindungsaufbau ausgetauscht und gegenseitig quittiert. Bei der Datenübertragung wird die Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger an, bis zu welchem Byte er die Daten bereits korrekt empfangen hat. Die Nummer gibt allerdings nicht an, welches Byte zuletzt korrekt empfangen wurde, sondern welches Byte als nächstes zu erwarten ist.

Offset:

Das Feld Offset (oder auch Header Length) gibt die Länge des TCP-Headers in 32-Bit Worten an. Dies entspricht dem Anfang der Daten im TCP-Segment. Das Feld ist notwendig, da der Header durch das Optionsfeld eine variable Länge hat.

Flags:

Mit den sechs 1-Bit-Flags im Flags-Feld werden bestimmte Aktionen im TCP-Protokoll aktiviert:

URG

Wird das Flag URG auf 1 gesetzt, so bedeutet dies, daß der Urgent Pointer (Dringendzeiger) verwendet wird.

ACK

Das ACK-Bit wird gesetzt, um anzugeben, daß die Bestätigungsnummer im Feld Acknowledgement Number gültig ist. Ist das Bit auf 0 gesetzt, enthält das TCP-Segment keine Bestätigung, das Feld Acknowledgement Number wird ignoriert.

PSH

Ist das PSH-Bit gesetzt, so werden die Daten in dem entsprechenden Segment sofort bei Ankunft der adressierten Anwendung bereitgestellt ohne sie zu puffern.

RST

Das RST-Bit dient dazu eine Verbindung zurückzusetzen, falls ein Fehler bei Übertragung aufgetreten ist. Dies kann sowohl der Fall sein, wenn ein ungültiges Segment übertragen wurde, ein Host abgestürzt ist oder der Versuch eines Verbindungsaufbaus abgewiesen werden soll.

SYN

Das SYN-Flag (Synchronize Sequenze Numbers) wird verwendet, um Verbindungen aufzubauen. Zusammen mit der Acknowledgement Number und dem ACK-Bit wird die Verbindung im Form eines Dreiwege-Handshake aufgebaut (siehe oben).

FIN

Das FIN-Bit dient zum Beenden einer Verbindung. Ist das Bit gesetzt, gibt dies an, daß der Sender keine weiteren Daten zu Übertragen hat. Das Segment mit gesetztem FIN-Bit muß quittiert werden.

Window:

Das Feld Fenstergröße enthält die Anzahl Bytes, die der Empfänger ab dem bereits bestätigten Byte empfangen kann. Mit der Angabe der Fenstergröße erfolgt in TCP die Flußsteuerung. Das TCP-Protokoll arbeitet nach dem Prinzip eines Schiebefensters mit variabler Größe (Sliding Window). Jede Seite einer Verbindung darf die Anzahl Bytes senden, die im Feld für die Fenstergröße angegeben ist, ohne auf eine Quittung von der Empfängerseite zu warten. Währen des Sendens können gleichzeitug Quittungen für die von der anderen Seite empfangenen Daten eintreffen (diese Quittungen können wiederum neue Fenstergrößen einstellen). Eine Fenstergröße von 0 besagt, daß die Bytes bis einschließlich der Acknowledgement Number minus Eins empfangen wurden, der Empfänger momentan aber keine weiteren Daten empfangen kann. Die Erlaubnis zum weiteren Senden von Daten erfolgt durch das versenden eines Segments mit gleicher Bestätigungsnummer und einer Fenstergröße ungleich Null.

Checksum:

Die Prüfsumme prüft den Protokollkopf, die Daten und den Pseudo-Header (siehe Abbildung).

Der Pseudo-Header in der Prüfsumme.

Der Algorithmus für die Bildung der Prüfsumme ist einfach: alle 16-Bit Wörter werden im 1er-Komplement addiert und die Summe ermittelt. Bei der Berechnung ist das Feld Checksum auf Null gesetzt und das Datenfeld wird bei ungerader Länge um ein Nullbyte aufgefüllt. Führt der Empfänger des Segments die Berechnung auf das gesamte Segment aus - inklusive des Feldes für die Prüfsumme - sollte das Ergebnis 0 sein [Ta96]. Der Pseudo-Header enthält die 32-bit großen IP-Adressen der Quell- und Zielmaschine sowie die Protokollnummer (für TCP 6) und die Länge des TCP-Segments. Die Einbeziehung der Felder des Pseudo-Headers in die Prüfsummenberechnung hilft, durch IP falsch zugeteilte Pakete zu erkennen. Die Verwendung von IP-Adressen auf der Transportebene stellt allerdings eine Verletzung der Protokollhierarchie dar.

Urgent Pointer:

Der Urgent-Zeiger ergibt zusammen mit der Sequenznummer einen Zeiger auf ein Datenbyte. Dies entspricht einem Byteversatz zu einer Stelle, an der dringende Daten vorgefunden werden. TCP signalisiert damit, daß sich an einer bestimmten Stelle im Datenstrom wichtige Daten befinden, die sofort gelesen werden sollten. Das Feld wird nur gelesen, wenn auch das Urgent-Flag (s.o.) gesetzt ist.

Options:

Das Options-Feld soll eine Möglichkeit bieten Funktionen bereitzustellen, die im normalen TCP-Protokollkopf nicht vorgesehen sind. In TCP sind drei Optionen definiert: End of Option List, No-Operation und Maximum Segment Size. Die wichtigste dieser drei Optionen ist die Maximale Segmentgröße. Mit dieser Option kann ein Host die maximale Anzahl Nutzdaten übermitteln, die er annehmen will bzw. annehmen kann. Während eines Verbindungsaufbaus kann jede Seite ihr Maximum an Nutzdaten übermitteln, die kleinere der beiden Zahlen wird als maximale Nutzdatengröße für die Übertragung übernommen. Wird diese Option von einem Host nicht unterstützt wird als default die Vorgabe von 536 Byte verwendet.

Padding:

Das Feld Padding wird verwendet, um sicherzustellen, daß der Header an einer 32-Bit Grenze endet und die Daten an einer 32-Bit Grenze beginnen. Das Füllfeld wird mit Nullen gefüllt.

Das User Datagram Protocol (UDP) ist im RFC 768 definiert. UDP ist ein unzuverlässiges, verbindungsloses Protokoll. Wie zuvor schon gesagt, bedeutet unzuverlässig in diesem Zusammenhang nicht, daß die Daten evtl. fehlerhaft beim Zielrechner ankommen, sondern, daß das Protokoll keinerlei Mechanismen zur Verfügung stellt, die sichern, daß die Daten auch tatsächlich beim Zielrechner ankommen. Sind die Daten aber beim Zielrechner angekommen, so sind sie auch korrekt. UDP bietet gegenüber TCP den Vorteil eines geringen Protokoll-Overheads. Viele Anwendungen, bei denen nur eine geringen Anzahl von Daten übertragen wird (z.B. Client/Server-Anwendungen, die auf der Grundlage einer Anfrage und einer Antwort laufen), verwenden UDP als Transportprotokoll, da unter Umständen der Aufwand zur Herstellung einer Verbindung und einer zuverlässigen Datenübermittlung größer ist als die wiederholte Übertragung der Daten.

Ein UDP-Segment besteht aus einem Header von 8 Byte, gefolgt von den Daten. Der Header ist in der folgenden Abbildung dargestellt:

Der UDP-Header.

Die Sender- und Empfänger-Portnummern erfüllen den gleichen Zweck wie beim Transmission Control Protocol. Sie identifizieren die Endpunkte der Quell- und Zielmaschine. Das Feld für die Länge enthält die Länge des gesamten Datengramms, inklusive der Länge des Protokollkopfes. Die Prüfsumme enthält die Internet-Prüfsumme der UDP-Daten, des Protokollkopfs und des Pseudo-Headers. Das Prüfsummenfeld ist optional. Enthält das Feld eine 0, wurde vom Absender keine Prüfsumme eingetragen und somit findet beim Empfänger keine Überprüfung statt.

Das User Datagram Protocol liefert über die Leistungen des Internet Protokolls hinaus nur Portnummern für die Adressierung der Kommunikationsendpunkte und eine optionale Prüfsumme. Das Protokoll beinhaltet keine Transportquittungen oder andere Mechanismen für die Bereitstellung einer zuverlässigen Ende-zu-Ende-Verbindung. Hierdurch wird UDP allerdings sehr effizient und eignet sich somit besonders für Anwendungen, bei denen es in erster Linie auf die Geschwindigkeit der Datenübertragung ankommt (z.B. verteilte Dateisysteme wie NFS).