Das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP) sind die zwei Protokolle des Transport Layers des OSI-Referenzmodells. Beide haben entsprechend ihrem Aufgaben einen unterschiedlichen Aufbau und sollen hier einzeln dargestellt werden.
TCP ist wie der Name schon sagt neben IP der zweite wichtige Bestandteil der TCP/IP-Architektur. Wie wir bereits wissen bietet IP den darüberliegenden Schichten einen unzuverlässigen und verbindungslosen Dienst an. TCP ist nun das Protokoll, das eine Verbindung zwischen zwei Hosts zuverlässig und verbindungsorientiert macht.
Im Einzelnen leistet TCP folgendes:
Wichtig ist, dass man die Daten des Transport layers Segmente nennt, es liegen also TCP-Segmente vor und keine TCP-Pakete oder TCP-Datengramme.
TCP-Segmente haben eine ähnliche Struktur wir IP-Datengramme. Jedes TCP-Segment besteht aus einem Header mit verschiedenen Standartinformationen und einem Rumpf mit den eigentlichen Nutzdaten. Wichtig ist, dass das gesamte TCP-Segment in die Nutzdaten des IP-Datengramms eingekapselt ist, der TCP-Header also unmittelbar dem IP-Header folgt.
TCP-Header sind mindestens 20 Bytes groß. die eigentlichen TCP-Nutzdaten werden bis zu 64 KB groß, wobei 1,5 KB üblich sind. Das folgende Bild zeigt den genauen Aufbau des TCP-Headers:
Es gibt folgende Felder:
Feld | Feldlänge in Bytes | Beschreibung |
---|---|---|
Source Port /Destination Port | je 16 | gibt jeweils den Quell- und Zielport an |
Sequence Number / Acknowledgement Number | je 32 | geben die Stellung der Daten im Datenstrom an. Die Sequenznummer gilt in Senderichtung, die Bestätigungsnummer dient als Quittungsnummerierung. Jede Nummer ist dabei innerhalb des Datenstroms einmalig (was bei 2 32 Zahlenmöglichkeiten auch kein Problem sein sollte). Mit diesen Nummern können TCP-Segmente, die in verkehrten Reihenfolge ankomme, wieder ordnungsgemäß zusammengesetzt werden. |
Offset | 4 | gibt die Länge des TCP-Headers in 32-Bit-Einheiten (Worten) an. Dieses Feld ist notwendig, da der TCP-Header durch die Optionsfelder eine variable Größe hat. |
URG | 1 | Flag, die auf "1" gesetzt bedeutet, dass der Urgent Pointer (Dringentzeiger, siehe unten) gesetzt ist. |
ACK | 1 | Flag, die auf "1" gesetzt bedeutet, dass die Bestätigungsnummer gültig ist. Wenn Flag "0" gesetzt ist, wird die Bestätigungsnummer ignoriert und keine Quittung gesendet. |
PSH | 1 | Flag, die auf "1" gesetzt bedeutet, dass das ankommende TCP-Segment sofort an die nächsthöhere Schicht weitergeleitet wird, ohne es mit weiteren TCP-Segmenten zusammenzufügen und zu puffern. |
RST | 1 | Flag, die auf "1" gesetzt bedeutet, dass die Verbindung zurückgesetzt wird. Das kann z.B. auftreten, wenn ein Host abgestürzt ist oder vorher ein ungültiges Segment übertragen wurde. |
SYN | 1 | Flag, die genutzt wird, um TCP-Verbindungen aufzubauen. Siehe auch Dreiwege-Handshake |
FIN | 1 | Flag, die auf "1" gesetzt bedeutet, dass der sendende Host die Verbindung beenden will, da er alle zu übertragenden Daten übertragen hat. Diese Anweisung muss vom empfangenden Host bestätigt werden. |
Window | 16 | gibt die Anzahl an Bytes an, die der Empfänger ab dem bereits bestätigten Byte empfangen kann. Mit diesen Feld wird die Flusssteuerung in TCP bewerkstelligt. TCP 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, dass alle ankommenden Segmente empfangen wurden und dass der Empfänger keine weiteren Segmente mehr erhalten kann. |
Checksum | 16 | stellt eine Prüfsumme bereit, in deren Berechnung die IP-Adressen des sendenden und des empfangenden Hosts und die Länge der Nutzdaten eingehen. Die Verwendung der IP-Adressen stellt strenggenommen eine Verletzung der Protokollhirarchie dar, dient aber dazu falsch adressierte IP-Datengramme zu finden. |
Urgent Pointer | 16 | ergibt zusammen mit der Sequenznummer einen Zeiger auf ein Datenbyte. Dies entspricht einem "Verweis" zu einer Stelle, an der sich dringend benötigte Daten befinden, die sofort gelesen werden sollten. Das Feld wird nur gelesen, wenn auch das Urgent-Flag (s.o.) gesetzt ist. |
Options | variabel | gibt weitere Optionen an, die nicht standartisiert sein müssen. Das kann z.B. die MTU (Maximum Transfer Unit) sein, die festlegt, die groß ein TCP-Segment werden kann (nicht zu verwechsels mit dem Window-Feld, das nur angibt, wie viele Bytes ein Host insgesamt noch bekommen möchte). |
Padding | variabel | Füllbits ohne Bedeutung, die das Options-Feld auf 32-Bit-Einheiten auffüllen |
Bevor zwei Hosts eine TCP-Verbindung aufbauen können, müssen sie sich über verschiedene Dinge einig werden, z.B. über die Sequenznummer (siehe TCP-Header), die sie anfangs verwenden wollen. Dieses Verfahren ist als Dreiwege-Handshake bekannt, weil es genau drei TCP-Segmente versendet, um eine TCP-Verbindung zu initieren.
Zuerst sendet unser Host A unserem Host B ein TCP-Segment, in dem nur das SYN-Flag gesetzt ist und eine Sequenznummer angegeben wird. Damit wird Host B signalisiert: "Hallo, ich bin Host A. Du gefällst mir, ich würde gern eine Verbindung zu Dir aufnehmen und möchte dafür die Sequenznummer XXXXXXX verwenden."
Jetzt kann Host B den Kontaktversuch eingehen oder ihn ablehnen. Geht er auf ihn ein, so sendet er ein Segment zurück in dem das SYN- und das ACK-Flag auf "1" gesetzt sind und in dem eine Quittungsnummer enthalten ist, die der um eins erhöhten Sequenznummer aus dem ersten Segment von Host A entspricht. Damit sagt er bildlich: "Ja, mein lieber Host A, auch ich will mich mit dir verbinden. Mir gefällt deine Sequenznummer so sehr, dass ich sie dir gleich als Liebesbeweis um eins erhöht zurückschick."
Im letztem Schritt sendet Host A Host B noch ein Segment, in dem das ACK-Flag gesetzt ist und die Quittungsnummer der um eins erhöhten Sequenznumer des letzten empfangenen Packet von Host B entspricht. Jetzt können die ersten Daten übertragen werden.
Der eigentliche Datenaustausch findet "zuverlässig" statt. Das heißt, dass alle Segmente, die A sendet von B mit der Quittungsnummer bestätigt werden müssen. Erhält A nach einer bestimmten Zeit keine Bestätigung, so weiß er, dass entweder das Originalpaket oder die Quittung verlorengegangen ist. In beiden Fällen sendet A das Paket nochmal und nochmal, bis er eine Quittung erhält. B muss sich dabei darauf einstellen, mehrere Segmente mit der gleichen Sequenznummer zu erhalten.
Nachdem alle Daten übertragen wurden, wird die Verbindung beendet, indem wieder ein Dreiwege-Handshake stattfindet, nur wird dabei das FIN-Flag anstatt dem SYN-Flag verwendet.
TCP-Verbindungen können zwischen beliebigen Rechnern aufgebaut werden, doch nach unseren bisherigen Wissen pro Rechner immer nur eine. Da vor allen Server, aber auch normale Clients mehrere Verbindungen zu bearbeiten haben (Multitasking), ist ein neues Konzept zur Verwaltung mehrerer paralleler Verbindungen notwendig. Das wird mit den TCP-Ports realisiert.
Jeder Host hat 65536 Ports, die alle unterschiedliche TCP-Verbindungen aufbauen können. Man kann sich die Ports wie ein Postamt mit 65536 Briefkästen vorstellen. Nur sind die Ports nicht wirklich physisch vorhanden, sondern nur virtuell. Der Computer lauscht dabei an jedem "Briefkasten", um eine Verbindung aufbauen zu können. Jedes TCP-Segment, dass eintrifft enthält im Header eine Portnummer, unter der die Verbindung stattfinden soll. So werden z.B. WorldWideWeb-Daten (Hyper Text Transfer Protocol HTTP) über die Portnummer "80" ausgetauscht und E-Mails über die Portnummer "110" gesendet. Indem jetzt ein Nutzer über seinen Computer im Hintergrund mehrere TCP-Verbindungen mit mehreren Portnummern laufen lässt, kann er z.B. gleichzeitig Internet-Radio höhren, E-Mails senden und empfangen und im WordlWideWeb die neuesten Aktienkurse checken.
Zurück zum Technischen: Wie bereits gesagt, gibt es 65536 mögliche Port-Nummern (2 16). Mehrere davon (die meisten unter 1000) sind sog. Well-Known-Port, d.h. man hat vereinbart, dass über jede dieser speziellen Port-Nummern nur ein bestimmter Dienst läuft. Verschiedene Well-Known-Ports sind im Anhang A aufgelistet.
Portnummern werden meistens in der Form IP-Adresse:Portnummer angegeben, also z.B.
192.168.0.66:80für den HTTP-Port auf dem Rechner mit der IP-Adresse 192.168.0.66. Im Vergleich mit dem Telefonnetz würde das also heißen:
Die eindeutige Zuordnung von IP-Adresse und Portnummer nennt man Kommunikationsendpunkt oder auch Socket (unter Windows schlicht winsock.dll, ein anderer Name für Windows Socket).
Das User Datagram Protocol UDP ist das zweite bedeutende Protokoll der Transportschicht. Es ist im Gegensatz zu TCP unzuverlässig und verbindungslos. Das heißt es arbeitet vereinfacht gesagt nach dem Prinzip: "Fire and forget!". Es gibt keinerlei Mechanismen sicherzustellen, dass die Daten beim Empfänger auch sicher ankommen. Es findet nicht mal ein Verbindungsaufbau statt (Dreiwege-Handshake).
Diese scheinbaren Nachteile können bei bestimmten Anwendungen aber auch Vorteile sein. So hat UDP einen sehr kleinen Header, der nur die Felder Quellport, Zielport, Länge des Headers und Prüfsumme (optional) enthält. Dieser insgesamt ca. 64 Bit kleine UDP-Header ist im Vergleich zum mindestens 192 Bits großen TCP-Headers ein Winzling. Das wirkt sich vor allen in der Geschwindigkeit der Übertragung vorteilhaft aus. UDP ist also für Anwendungen sinnvoll, bei denen möglichst schnell geringe Datenmengen ausgetauscht werden müssen, z.B. beim SNMP (Simple Network Management Protocol) oder beim NFS (Network File System)
Merkmal | TCP | UDP |
---|---|---|
Verbindungsaufbau vor der Datenübertragung | Dreiwege-Handshake | nein |
Zuverlässigkeit | ja | nein |
Verbindungsorientierung | ja | nein |
Flusssteuerung + Zeitüberwachung | ja | nein |
Erkennung der Segmentreihenfolge | ja | nein |
Erkennung von Datengramm-Duplikaten | ja | nein |
Ports | ja | ja |
Integritätsprüfung (Prüfsumme) | ja | ja |
Geschwindigkeit | mittel | hoch |
Das Transmission Transport Protocol baut auf IP auf und macht dieses zuverlässig, d.h. TCP stellt sicher, dass die Daten, die gesendet wurden, auch beim Empfänger ankommen. Darüber hinaus stellt es das sog. Port-System bereit, mit dem ans Internet angeschlossene Rechner mehrere TCP-Verbindungen nebeneinander aufbauen können.
Das User Datagram Protocol baut auch auf IP auf, doch lässt es viele Funktionen von TCP vermissen, z.B. einen Kontrollmechanismus, mit dem man herausfinden kann, ob gesendete IP-Pakete auch wirklich beim Empfänger ankamen. Durch das Weglassen dieser Steueroptionen wird UDP insgesamt schneller als TCP.
Zusammenfassend lässt sich sagen, dass man TCP mit einem Brief mit Empfangsbestätigung und UDP mit einem rasend schnell verschicktem Telegramm ohne Bestätigung des Empfangs vergleichen kann.
vorhergehende Seite | Inhalt | nächste Seite |
---|