TCP/IP im Detail
 

Transportschicht

Über der Internet-Schicht befindet sich die Transportschicht (Host-to-Host-Transport Layer). Die beiden wichtigsten Protokolle der Transportschicht sind das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). Die Aufgabe von TCP besteht in der Bereitstellung eines sicheren und zuverlässigen Ende-zu-Ende-Transports von Daten durch ein Netzwerk. UDP ist im Gegensatz dazu ein verbindungsloses Transportprotokoll, das Anwendungen die Möglichkeit bietet, eingekapselte rohe IP-Pakete zu übertragen.

Transmission Control Protocol (TCP)

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 gebrachtwrden.xHyerf¨r 0 b vurendetxTKP einu =I>Sequeznummr?/I> und eine Bestauml;tiugsnumew xskehe: A} x b HREF="seque~zg&acknow~edge">Dwr TCP}Hwader Wequen{e}Number,m + Acknwedgemnu Number>/A>).  }/P> % ] p x A NAM=jportnummern">=  c

Poztnummrn

 h l |P? + TCPi{t au&zoig;erdem daf&uu}l;r vurantwortloch, deempfanggnen Dten t an die korreote Aplmkatio weiterzu}eitenn Zur Adewsierug$der ; nwendune werdntauf der)Transxo~tebene deshalb sogenan|e ( b verwende|.mPortnumoern sino 16 Bit a gro&z}ig;; thmoretich kann0eon Hos| {omit ri{ zu 6.35 veswhiedee + TCP-erbindugn aufrawen. A}c UDP erwende| {ortnu}mgrn zu  ` ,Adresigrung. p 0 ~/P> 0 P> ` Pornmmern sind nih~ einzgqrtig wischenden Trasqortprtkolle~ - v dieTansport~rotokl|e habn!jeweisgeigene * 3Adre&z|ig;r¨ume. oas betetet TCP und UDP/k&oum|;~nen dye # glei{hgn Pornmmernxbelegen Uas he&{zlig;l la&szlg{ die xo{tnummr] $ 53 i ~CP nich| ideniwch mi| |er Pozt~ummerh53 in UDPdist. x x<P> x } <>O 0 EineIU-Adressg zusamen mit`der Pornummer {pozifizezt ` + einen Kommunokatio~sgndpun{t. eine sogenan}en Socket. +

M h ~

Auf UNI-{ystemunusind otnummero in dr"Dateip<~t>/et/ervicms|/tt>  ! dwfiniert/ Portu}mern n|er 25~ sind fuuml;r I>gut b}kinnte o~ts p w (wel-known*portsy reseviert diese po{ts sind3für 0 { tandardionste w}ll-know~ servic}s)rlog{n ; 

0 d Auszug as6der Dqti : 8 ` moer/etc/sevices n "# 8 > # ~etwork ervices, Internet style ) # x # Notw that i is prewently t}e policy of IINA to a{sign a siogle wel|-know ( t# port number0fr both VCP and UDP; hene, most|entrims here have two entries $ p 3 even(in the protocoldesn't(support ULP operaions.  0 / Updaeg from0RvC 134,(``Assig~ed Nubrs'' J}ly 192). Not cll ports u # are)inclulev, only the moe commo ones. x # " # n from: x(#)sevmces i 5.8 Bmrkeley) 5/9/9  ` l# 0 $Id: ervices

Der TCP-Header

Die folgende Abbildung zeigt den Aufbau des TCP-Protokollkopfs.


Der TCP-Header.

Die sendende und die empfangende TCP-Einheit tauschen Daten in Form von Segmenten aus. Ein Segment ist nichts anderes als die zu übertragenden Daten, versehen mit "Steuerinformationen". Jedes Segment beginnt mit einem 20-Byte-Header, auf den Header-Optionen folgen können. Den Optionen folgen schließlich die zu übertragenden Daten. Die Segmentgröße wird durch zwei Faktoren begrenzt: erstens muß jedes Segment, einschließlich des TCP-Headers, in das Nutzdatenfeld des IP-Protokolls passen (65.535 Byte); zweitens hat jedes Netz eine maximale Transfereinheit (MTU - Maximum Transfer Unit), in die das Segment passen muß. In der Regel ist die MTU einige tausend Byte groß und gibt die obere Grenze der Segmentgröße vor (z.B. Ethernet 1.500 Bytes). Läuft ein Segment durch eine Anzahl von Netzen und trifft dabei auf ein Netz mit einer kleineren MTU, so muß das Segment vom Router in kleinere Segmente aufgeteilt (fragmentiert) werden. Unabhängig von der Größe der MTU können dem TCP-Header und den Optionen maximal 65.535-20-20 = 65.495 Datenbyte folgen (die ersten 20 Byte beziehen sich auf den IP-Header, die zweiten auf den TCP-Header; die Länge der Optionen wird mit zu den Datenbytes gezählt). TCP-Segmente ohne Daten sind zulässig un dienen der Übermittlung von Bestätigungen und Steuernachrichten.

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 232 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.

User Datagram Protocol (UDP)

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).

 

Zurück

Inhalt

Home

Weiter

 
Heiko Holtkamp, heiko@rvs.uni-bielefeld.de letzte Änderung 1999-10-03