Proseminar Rund ums Internet

TCP - UDP

privat@alexanderkipp.de

Inhaltsverzeichnis

        1. Grundlagen
                1.1 IP Eigenschaften
                1.2 Arten und Anforderung an die Kommunikation
                1.3 Adressierung
                1.4 Schichtenmodell
        2. UDP
                2.1 UDP-Header
                2.2 Einsatz von UDP
        3. TCP
                3.1 TCP-Header
                3.2 zuverlässige Verbindung
                3.3 Verbindungsaufbau und -abbau
                3.4 Fensterprinzip und Flusskontrolle
                3.5 Timeout - Bestimmung
                3.6 klassische Problemfälle bei TCP
                3.7 Ermittlung einer optimalen Datenübertragungsrate
                3.8 Eigenschaften von TCP
                3.9 Einsatz
        4 Zusammenfassung
        Literatur

1. Grundlagen

1.1 IP Eigenschaften

IP bietet einen verbindungslosen Ende-zu-Ende Pakettransport. Es garantiert weder die richtige Reihenfolge noch die korrekte Übertragung der Nachrichten. Es bietet keine Dienstadressierung (Ports).

1.2 Arten und Anforderung an die Kommunikation

Es wird von einem Netzwerk ausgegangen, das auf dem IP-Protokoll basiert. Der angeschlossene PC wird als Host bezeichnet. Die Protokolle UDP und TCP basieren auf IP und erweitern es. Möchte man nur eine Nachricht von einem Host zu einem anderen schicken, so spricht man von einer nachrichtenorientierten Kommunikation (vgl. SMS, Brief). Bei solch einer Kommunikation wird das UDP verwendet. Das TCP ermöglicht eine verbindungsorientierte Kommunikation (vgl. Telefongespräch) und überprüft das korrekte Versenden der Nachricht.

1.3 Adressierung

UDP und TCP erweitern das IP um die Dienstadressierung (durch Ports) - also einer zusätzlichen Indizierung. Dadurch werde mehrere gleichzeitige Verbindungen möglich (Multiplexing). Ports sind Dienstzugangspunkte für Programme. Man unterscheidet zwischen "well-known" Ports, die einem Dienst fest zugeordnet sind, und dynamischen Ports, die variabel zugeordnet und bei jedem Nachrichtenaustausch neu ausgehandelt werden. Ausgehende Verbindungen werden an freie Ports dynamisch angebunden; wohingegen eingehende Verbindungen wellkown Ports ansprechen. TCP nimmt die Nachrichten an, liest aus der Nachricht die Portnummer und übergibt diese Nachricht an das Programm, das diesen Port abruft.

1.4 Schichtenmodell

Eine Anwendung kann Daten zu einer Anwendung auf einem anderen Host schicken, indem sie die Daten und die Adresse (IP+Port) TCP bzw. UDP übergibt. Diese zu übertragenden Daten werden von UDP/TCP in Segmente zerlegt. Diese Segmente werden jeweils mit einer Kopfzeile - Header genannt - dem IP-Protokoll übergeben, das die weitere Vermittlung dieser Pakete durch das Netz übernimmt. Der Header enthält nähere Informationen zu den Daten, bei TCP enthält der Header zusätzlich noch Steuerelemente. In Abb.1 wird dargestellt, wie die Daten verpackt werden, damit sie durch das Netzwerk vermittelt werden können. Der IP-Block besteht aus IP-Header und Daten. Diese Daten bestehen aus einem TCP-/ UDP-Header und deren Daten. IP wird als Vermittlungsschicht und TCP/UDP als Transportschicht bezeichnet (siehe Abb. 1).

Abb. 1 Schichtenmodell

Bei der Segmentierung der Daten unterscheidet man die Segmentierung in der Vermittlungsschicht (IP) und in der Transportschicht (TCP/UDP). Die Pakete in der Transportschicht so groß wie möglich sein, um mit weniger Paketen unnötige Header zu vermeiden. Wenn diese Pakete für ein IP Segment zu groß sind, so werden sie in der Vermittlungsschicht (IP) fragmentiert.

2. UDP

UDP (user datagram protocol) ist nachrichtenorientiert und bietet keine sichere Datenübertragung und keine Flusskontrolle.

2.1 UDP-Header

Der Header (siehe Abb. 2) des Protokolls beinhaltet den Sender- bzw. den Empfängerport. Der Sendeport ist optional. Die Länge wird angegeben durch die Anzahl der Bytes (8-Bit) des UDP-Pakets. Sie ist mindestens acht, also die Länge des Headers selbst. Um die Prüfsumme zu berechnen, wird ein Pseudo-Header eingeführt, der aus der Quell- und Ziel-IP-Adresse, der Protokollnummer (UPD: 17) und der Länge des IP-Pakets besteht.

Abb. 2 UDP-Header

2.2 Einsatz von UDP

UDP wird überall dort eingesetzt, wo eine zuverlässige Datenübertragung in der Transportschicht nicht erforderlich ist. Die Fehlerroutinen werden in der Applikationsschicht übernommen, wie z.B. bei DNS- und NFS-Anfragen. Bleibt die Antwort aus, so wird die Anfrage erneut gesendet - schnell und unkompliziert. Diese Eigenschaft von UDP wird bei Anwendungen ausgenützt, die hohe Übertragungsgeschwindigkeiten erfordern, wie z.B. Multimedia-anwendungen. Das Real-Time-Protokoll (RTP) nutzt diese Vorteile von UDP aus und erweitert es um Verifikationsmechanismen - ähnlich denen des TCPs. UDP wird oft bei Anwendungen auf lokalen Netzwerken verwendet; dort treten aufgrund des relativ kleinen und überschaubaren Netzes meist keine Fehler beim Senden auf.

3. TCP

Das TCP-Protokoll (transmission control protocol) ist verbindungsorientiert. In einem Netzwerk können Daten verloren gehen, in unterschiedlicher Reihenfolge oder mehrfach beim Empfänger ankommen. TCP übernimmt die Überprüfung der korrekten Datenübertragung. Des weiteren hat TCP Routinen integriert, die eine abgestimmte Datenübertragung mit Flusskontrolle bieten.

3.1 TCP-Header

Der TCP-Header ist sehr komplex. Er beinhaltet neben Informationen zur Nachricht noch Steuerungs- und Quittierungselemente für die Verbindung (siehe Abb. 3). Der Header besteht wesentlich aus:

Quell- und Ziel-Portnummer des Anwendungsprozesses
Sequenznummer, die jedem TCP-Segment eindeutig zugeordnet wird. Sie wird bei der Quittierung ausgetauscht.
Quittungsnummer (Quittung = Acknowledgement ACK). Der Empfänger sendet die nächste erwartete Sequenznummer als ACK dem Quellrechner und bestätigt folglich den Empfang dieses Segments.
Offset gibt die Länge des TCP-Headers an und zeigt dadurch auf den Datenanfang.
Kontrollflags steuern die Verbindung und legen fest welche Felder im Header gültig sind. Für jedes Flag gibt es ein Bit; ist es gesetzt so gilt jeweils:
- URG: Urgent Pointer [Headerfeld] ist gültig.
- ACK: Quittierungsnummer [Headerfeld] ist gültig.
- PSH: Die Daten sollen sofort gesendet werden (Push-Funktion).
- RST: Die Verbindung soll zurückgesetzt werden (Reset).
- SYN: Ein Verbindungsaufbau ist gewünscht, muss quittiert werden.
- FIN: Ein Verbindungsabbau ist gewünscht, muss quittiert werden.
Empfangsfenster-Feld gibt wieder, wie viele Bytes das Empfangsfenster aufnehmen kann.
Prüfsumme ermöglicht es dem Zielrechner den TCP-Header, die Daten, die Quell- und Ziel-IP-Adresse zu verifizieren. Bei der Berechnung der Prüfsumme wird ein Pseudo-Header einbezogen, der die Quell- und Ziel-IP-Adresse, die Protokollnummer (TCP: 6) und die Länge des TCP-Pakets enthält.
Urgentpointer erlaubt es, dringliche Nachrichten (z.B. Interrupts) an die normal zu sendenden Daten zu hängen und mitzusenden. Der Urgentpointer zeigt auf das Ende der dringlichen Nachricht.
Optionenfeld legt weitere Verbindungseigenschaften fest, einige hier festgelegten Eigenschaften sind:
- MSS (Maximum Segment Size): Legt die maximale Segmentgröße fest, die verarbeitet werden kann.
- WSopt (Window Scale): Dieser Skalierungsfaktor wird beim Verbindungsaufbau ausgehandelt. Er bestimmt den Faktor mit dem der Wert im Empfangsfenster-Feld multipliziert wird. Der Faktor kann maximal den Wert 14 annehmen - das Fenster folglich 1 Gigabyte.

Abb. 3 TCP-Header

3.2 zuverlässige Verbindung

Um eine korrekte Nachrichtenübermittlung zu garantieren, quittiert der Empfänger das Datenpaket (siehe Abb. 4). Der Sender addiert die empfangene Sequenznummern und die Länge des TCP-Pakets. Diese Summe ist die nächste für den Empfang erwartete Sequenznummer. Diese wird über den Header als Quittungsnummer zurückgeschickt. Der Empfang ist quittiert. Die Quittierung erfolgt nicht über eine getrennte Nachricht, sondern wird über das nächste gesendete Paket in die Rückrichtung mit geschickt - auch Huckepackverfahren (piggyback) genannt.

Kommt ACK nicht innerhalb einer "Time-Out"-Zeit an, dann werden die Daten erneut gesendet. Eine Quittung wird für ein Packet immer erst dann gesendet, wenn alle vorhergehenden Packete angekommen sind.

Abb. 4 zuverlässige Verbindung durch ACK - [BAD] S. 164

3.3 Verbindungsaufbau und -abbau

Die TCP-Verbindung ist vollduplex, d.h. die Verbindung besteht aus zwei entgegengesetzten unidirektionalen Verbindungen. TCP geht von einem Zustandsmodell aus. Ein Zustande ist z.B. "Verbindung aufgebaut". Die Anfragen zum Verbindungsstatus werden über die Kontrollflags im Header mitgeteilt. Die Initialisierung der Verbindung kann von beiden Partnern A, B gleichermaßen erfolgen. Der Verbindungsaufbau erfolgt über einen 3-Wege-Handschlag (siehe Abb. 5). A möchte eine Verbindung aufbauen (aktiv). A schickt B eine Nachricht. Diese enthält die Quell-, Zielportnummer und die Sequenznummer; das SYN-Flag ist gesetzt. B wartet auf einen Verbindungsanfrage (passiv). Nach Erhalt der Anfrage von A sendet B die Portnummern, quittiert den Empfang (siehe Absatz 3.2); das SYN-Flag gesetzt. Der Empfang dieser Nachricht wird von A nochmals bestätigt. Die Verbindung steht. Der Abbau der bidirektionalen Verbindung erfolgt nacheinander. A setzt das FIN-Flag. B quittiert. B setzt das FIN-Flag und A quittiert.

Abb. 5 3-Wege-Handschlag zum Verbindungsaufbau

3.4 Fensterprinzip und Flusskontrolle

Das Netzwerk wird nicht effizient ausgenutzt, wenn man zum Senden eines Pakets wartet, bis die Quittung des zuvor versendeten Pakets eingegangen ist. Deshalb werden mehrere Pakete gleichzeitig versendet (siehe Abb. 6).

Abb. 6 überlagertes Senden

Dies wird mit einem Fenster realisiert (siehe Abb. 7). Das Fenster ist ein Zeiger auf den Zwischenspeicher - Puffer genannt -, der die Daten zum Senden bzw. zum Empfangen aufnimmt. Man unterscheidet zwischen Sende- und Empfangsfenster. Das Sendefenster ist maximal so groß wie das Empfangsfenster - somit wird auf die Verarbeitungskapazität des Empfängers beim Senden Rücksicht genommen. Das Sendefenster wird verkleinert, falls eine Netzwerküberlastung auftritt.

Das Sendefenster enthält die noch nicht quittierten, gesendeten Daten und die Daten die noch gesendet werden dürfen. Werden die zu erst gesendeten Daten (links im Fenster) quittiert, so wird das Fenster nach rechts um die Länge des quittierten Datenblocks verschoben. Daten die gesendet und quittiert wurden befinden sich links außerhalb des Fensters. Die noch zu sendenden Daten stehen rechts (siehe Abb. 7)

Das Empfangsfenster verhält sich analog. Es beinhaltet die noch nicht quittierten, empfangenen Daten und eine freie Empfangskapazität. Nachdem die Daten quittiert wurden, wird das Fenster nach links verschoben und weitere Empfangskapazität wird frei.

Abb. 7 Aufbau der Fenster

Die Größe des Empfangsfensters wird über das Headerfeld (Empfangsfenster) in Bytes (8 Bits) dem Sender mitgeteilt. Der Sendeprozess kann blockiert werden, wenn die Verzögerungszeit im Netzwerk groß oder das Fenster zu klein ist (siehe Abb. 8). Die Ermittlung der optimalen Fenstergröße ist die wesentliche Aufgabe der Flusskontrolle.

Abb. 8 Sendeblockade durch kleines Fenster - [BAD] S. 162

3.5 Timeout - Bestimmung

Wenn gesendete Daten nach einer bestimmten Zeit (Timeout) nicht quittiert werden, so werden sie erneut gesendet. Dieser Timeout hängt von der Verzögerung durch das Netzwerk ab. Die Verzögerung ist bedingt durch die Art des Netzwerks, dessen Größe und dessen Auslastung. Sie kann daher variieren. Die Verzögerungszeit kann durch, die Zeit die eine Hin- und Rücknachricht benötigt bestimmt werden und wird mit Round Trip Time (RTT) bezeichnet. Aus RTT kann der Timeout bestimmt werden. Diese Wartezeit zu optimieren steigert den Durchsatz und dadurch die Effizienz des Netzwerkes. Ist RTT zu groß, so wird zu lange gewartet bis die Daten erneut gesendet werden. Wenn sie zu klein ist, wird das Netzwerk mit unnötigen Wiederholungssendungen verstopft.

Die RTT wurde in der originalen Implementierung bestimmt, indem die Laufzeit einer Nachricht (RTT_Samp) vom Senden bis zum ACK gemessen wird und über folgende Funktion mit der bisherigen RTT rekursiv gemittelt:

RTT = a*RTT + (1-a)*RTT_Samp

Daraus wird der Timeout berechnet:

Timeout = b*RTT

Wobei am Anfang RTT_Samp = 2s angenommen wird. Der Gewichtungsfaktor wird meist a=0,9 und der Toleranzfaktor b=2 gesetzt. Gehen Datenpakete verloren, so müssen sie erneut gesendet werden. RTT_Samp wird von der letzten Wiederholungssendung bis zum ACK ermittelt, dadurch wird RTT zu niedrig angesetzt. Neuere Implementierungen ziehen bei der Ermittlung von RTT die wiederholten Datenpakete nicht mehr mit ein und haben die Bestimmung des Timeouts weiter optimiert:

Diff = RTT_Samp - RTT

RTT = RTT + n * Diff

Abweichung = Abweichung + m * Diff

Timeout = p*RTT + q*Abweichung

Die Parameter nehmen üblicher Weise die Werte n=0.125, m=0.25, p=1 und q=4 an. Wenn Datenpakete verloren gehen, beeinflussen diese Parameter wie stark sich der Timeout verändern soll.

3.6 klassische Problemfälle bei TCP

Nagle Algorithmus

Wenn Anwendungsprogramme TCP kleine Segmente zum Senden übergeben, sendet TCP diese nacheinander und getrennt. Um die Netzlast zu reduzieren werden diese kleine Segmente miteinander verkettet versendet. Damit wird die Anzahl der TCP-Pakete (inkl. Header) reduziert. Infolgedessen muss nicht jedes (kleine) Segment bestätigt werden. Vier Faktoren gehen in den Nagle Algorithmus ein: Die Haltezeit, die maximal abgewartet werden darf, die Größe des Sendepuffer, die RTT und den Anwendungstyp, z.B. multimediale Anwendungen erfordern sofortiges Senden.

Silly-Window

Wenn das Empfangsfenster ausgeschöpft ist, können keine Daten mehr gesendet werden. Vergrößert der Empfänger das zunächst kleine Empfangsfenster, so wird dies dem Sender umgehend mitgeteilt; der daraufhin ein kleines Datenpaket sendet. Wenn dieses Paket empfangen und quittiert wird gibt dies wiederum nur eine kleine Kapazität frei. Bei großen Datenmengen kann es vorkommen, dass nur noch kleine Datenpakete gesendet werden. Diesen Effekt kann man dadurch vermeiden, dass die Meldung der freien Empfangskapazität erst gesendet wird, wenn hinreichend freie Kapazität freigesetzt wurde. Auf der Senderseite kann mit dem Senden ebenfalls so lange abgewartet werden bis eine hinreichend große Kapazität freigeworden ist.

3.7 Ermittlung einer optimalen Datenübertragungsrate

Die Datenübertragung wird so lange gesteigert, indem das Sendefenster vergrößert wird, bis Durchsatzprobleme auftreten. Die von TCP verwendeten Mechanismen sind wie folgt. Die Datenübermittlung wird initiiert mit einem Slow-Start. Die des Sendefenster wird auf ein Segment (Defaultwert: 536 Byte) gesetzt und wird dann vergrößert. Nach jedem ACK wird das Fenster um die Länge des quittierten Segments vergrößert. Das Fenster wächst infolgedessen exponentiell. Wird ein Schwellenwert überschritten, wächst es nur noch linear. In heutigen Netzen gehen Datenpakete kaum noch verloren. Timeouts werden als Zeichen für Überlastung gesehen. Bei jedem ausbleibenden ACK wird das Sendefenster halbiert. Bleiben die ACK weiterhin aus, so wird das Sendefenster exponentiell verkleinert, gleichzeitig wird die Rate der Wiederholungssendung exponentiell gesteigert (Fast-Retransmit), der Time-Out wird dabei vernachlässigt. Dem Netzwerk wird hierdurch die Möglichkeit gegeben die Durchsatzprobleme zu beseitigen (Durchsatzprobleme vermeiden = Congestion Avoidance). TCP passt sich dadurch stets an die momentane Situation des Netzwerks an.

3.8 Eigenschaften von TCP

TCP basiert auf IP und erweitert dieses. Es bietet die Möglichkeit des Multiplexing. TCP bietet eine zuverlässige Verbindung durch ACK, Verbindungsauf- und abbau. Die Reihenfolgetreue wird durch Sequenznummern realisiert. Der Sender stellt sich auf die Ressourcen des Empfängers und des Netzwerks durch das Fensterprinzip, Slow-Start und Congestion Avoidance ein. TCP unterstützt keinen synchronen Datentransfer und keine 1:n Verbindung. Bei Netzen mit hoher Fehlerrate versagt die TCP-Flusskontrolle; TCP kann daher die volle Bandbreite von Weit- und Hochgeschwindigkeitsnetzen nicht ausschöpfen.

3.9 Einsatz

TCP ist das Basisprotokoll für das Internet und für viele Kommunikationsdienste. HTTP, FTP, SSH und die Mailprotokolle SMTP und POP3 basieren allesamt auf TCP.

4 Zusammenfassung

UDP und TCP sind wichtige Protokolle in der heutigen vernetzten Welt (siehe Abb. 9). Sie ermöglichen Multiplexing. UDP ist einfach und unkompliziert. Es überprüft weder das Senden noch die Ankunft der Daten und den Datenfluss. Dahingegen ist TCP komplexer und zuverlässig. Es kontrolliert die Datenübertragung durch ACK. Auch die Ressourcen des Empfängers und des Netzwerks werden berücksichtig durch das Fensterprinzip, Slow-Start und Congestion-Avoidance.

Abb. 9 TCP-/UDP-Einsatz

Literatur

[COM]: Douglas Comer, TCP/IP (3rd ed.), Vol. 1: Principles, Protocols and Architecture, Prentice Hall, 1995: .
[BAD]: Anatol Badach, Erwin Hoffmann, Technick der IP-Netze. TCP/IP incl. IPv6, München 2001: .

Letzte Änderung: 2002-12-11 15:08:11