TCP / UDP Proseminar: Kommunikationsprotokolle SS 2003 · PDF fileRheinisch-Westfalische...

24
Rheinisch-Westf¨ alische Technische Hochschule Aachen Lehrstuhl f ¨ ur Informatik IV Prof. Dr. rer. nat. Otto Spaniol TCP / UDP Proseminar: Kommunikationsprotokolle SS 2003 Stefan Hoferer Matrikelnummer: 234173 Betreuung: Ralf Wienzek Lehrstuhl f ¨ ur Informatik IV, RWTH Aachen

Transcript of TCP / UDP Proseminar: Kommunikationsprotokolle SS 2003 · PDF fileRheinisch-Westfalische...

Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IV

Prof. Dr. rer. nat. Otto Spaniol

TCP / UDP

Proseminar: KommunikationsprotokolleSS 2003

Stefan HofererMatrikelnummer: 234173

Betreuung: Ralf WienzekLehrstuhl fur Informatik IV, RWTH Aachen

Inhaltsverzeichnis

1 Einleitung 3

2 Grundlagen von TCP/IP 3

2.1 Der Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Ports und Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 UDP 5

3.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Fragmentierung durch IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.4 Effekte zwischen UDP und ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.5 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 TCP 9

4.1 Einfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2.1 Header Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Verbindungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3.1 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3.2 Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3.3 Zustandsubergangsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Datenubertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.1 Verbindungssicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.2 Interaktiver Datentransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.3 Bulk-Datentransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Zusammenfassung 24

2

1 Einleitung

Beide der hier behandelten Protokolle gehoren zum TCP/IP-Protokollstapel,uber den seit 1983 einGroßteil der Kommunikationsaufgaben im Internet abgewickelt wird. Aber auch schon vor TCP/IPgab es das Bedurfnis Daten zwischen Computern auszutauschen. Bereits 1969 rief dieDefence Ad-vanced Research Projects Agency(DARPA) ein Projekt ins Leben, aus dem das so genannte ARPA-NET entstand. Die Zielsetzung dabei war ein heterogenes Netzwerk zu schaffen, das weitestgehendunabhangig von dem verwendetenUbertragungsmedium oder den daran angeschlossenen Rechner-systemen war. Außerdem sollte es eine einheitliche Schnittstelle zu diesen Protokollen geben, um dieEntwicklung von Software deutlich zu vereinfachen. Nachdem das ARPANET in Betrieb genommenwurde und sich stark verbreitete, begann die Entwicklung der TCP/IP-Protokolle, die seit 1983 dieGrundlage unseres heutigen Internets bilden. Wegen seiner großen Bedeutung ist TCP/IP heute furalle gangigen Rechnersysteme verfugbar. Bei den meisten ist es sogar direkt in das Betriebssystemintegriert.Zwei der Protokolle des o.g. Protokollstapels sollen hier behandelt werden. Das verbindungsorien-tierteTransmission Control Protocol(TCP) [2], das aufgrund seiner großen Bedeutung mit zur Na-mensgebung von TCP/IP beitrug, sowie das verbindungsloseUser Datagram Protocol[1].Im Folgenden werden zunachst einige Grundlagen, die den TCP/IP-Protokollstapel betreffen, erlautert.Wobei schon hier erwahnt sei, dass es sich dabei nur um einen grobenUberblick handelt. Fur detail-liertere Informationen sei auf die Seminararbeiten zum Thema “Was ist das Internet? Struktur, Aufbauund Technik”, “Routing im Internet”, “Was ist Ethernet?” sowie “IPv4 und IPv6” verwiesen. Nachder Behandlung der Grundlagen werden die beiden Protokolle UDP und TCP ausfuhrlich behandelt.

2 Grundlagen von TCP/IP

2.1 Der Protokollstapel

Kommunikationsprotokolle werden, um ihre Komplexitat zu verringern, schichtweise implementiert.Auch wenn Anzahl und Aufgabenverteilung der Schichten von Netz zu Netz variiert, ist das grundsatz-liche Prinzip, stets das gleiche. Eine Schicht bietet der jeweilsuber ihr liegenden Schicht bestimm-te Dienste an, ohne jedoch Kenntnisseuber die genaue Implementierung vorauszusetzen. In jederSchicht konnen mehrere Dienste vorhanden sein, welche die Aufgaben der Schicht auf verschiedeneWeise implementieren. Auf diese Weise kann die Implementierung einzelner Dienste geandert wer-den, ohne damit die restlichen zu beeinflussen. Wichtiger ist noch, dass man auf diese Weise neueHardware (zum Beispiel fur die Kommunikationuber andere Netzwerkmedien) auf einfache Weiseintegrieren kann.Eine Anwendung auf Rechner A, die Daten an eine Anwendung auf Rechner B schicken mochte,kann dies nicht auf direktem Weg. Stattdessen gibt sie die Daten an einen Dienst der obersten Schichtweiter, welcher seine Steuerinformationen in Form von so genannten Headern hinzufugt und seiner-seits Dienste der darunterliegenden Schicht nutzt, um die Daten weiterzugeben. Erst auf der untersten

3

Verarbeitungsschicht

Darstellungsschicht

Sitzungsschicht

Transportschicht

Vermittlungsschicht

Sicherungsschicht

Bitübertragungsschicht

Verarbeitungsschicht

Transportschicht

Internetschicht

Host-an-Netz Schicht

ISO / OSI TCP / IP

Im Modellnicht

vorhanden

Abbildung 1: ISO/OSI- und TCP/IP-Protokollstapel im Vergleich

Ebene werden die Daten von Rechner A zu Rechner B transportiert und durchlaufen dort den Pro-tokollstapel von unten nach oben. Dabei werden die Steuerinformationen in den Headern u.a. dazugenutzt, um das Protokoll und letztlich die Anwendung zu bestimmen, an welche die Daten weiterge-geben werden sollen.Die zwei wichtigsten Modelle fur die Aufgabenverteilung der Schichten sind das ISO/OSI-Referenz-modell sowie das TCP/IP-Referenzmodell (s. Abb. 1). Im Gegensatz zu den 7 Schichten des ISO/OSI-Modells werden bei TCP/IP nur 4 Schichten implementiert. Es hat sich aber gezeigt, dass dies volligausreichend ist.Da in dieser Arbeit Protokolle aus dem TCP/IP-Protokollstapel vorgestellt werden, sollen im Folgen-den lediglich die Aufgaben dieser vier Schichten beschrieben werden.

• Host-an-Netz-SchichtDiese Schichtubernimmt die Aufgaben der Sicherung und der Bitubertragung. Die Protokolledieser Schicht sind von Netz zu Netz sehr unterschiedlich und von TCP/IP nicht weiter fest-gelegt. Die einzige Anforderung, die an sie gestellt wird, ist, dass IP-Pakete verschickt werdenkonnen.

• Internet-SchichtIn dieser Schicht ist das wohl wichtigste Protokoll angesiedelt, dasInternet Protocol(IP). Essoll sicherstellen, dass IP-Pakete richtig zugestellt werden konnen. IPubernimmt dabei Auf-gaben wie die Adressierung der Daten und das so genannte Routing zwischen verschiedenNetzwerken. DasInternet Protocolist verbindungslos undubernimmt keine Garantie, dass dieversendeten Daten an ihrem Ziel ankommen. Die Erkennung verloren gegangener Pakete undeine geeignete Reaktion darauf wird hoheren Schichtenuberlassen.

4

• TransportschichtHier sind die beiden Ende-zu-Ende Protokolle TCP und UDP definiert. UDP ist genau wie IPein verbindungsloses und unzuverlassiges Protokoll, wahrend TCP ein zuverlassiges verbin-dungsorientiertes Protokoll darstellt. Anwendungen, die Daten verschicken mochten, haben dieWahl, welches der Protokolle sie verwenden mochten. Beide haben ihre Vor- und Nachteile, aufdie in den entsprechenden Abschnitten naher eingegangen wird.

• VerarbeitungsschichtIn dieser Schicht sind hohere Protokolle angesiedelt. Zu diesen gehoren zum Beispiel TELNET,FTP, SMTP oder DNS, die zur Datenubertragung die Dienste von UDP oder TCP nutzen.

2.2 Ports und Sockets

Um im Netzwerk den Rechner ausfindig zu machen, an den die Daten geschickt werden sollen, wer-den IP-Adressen verwendet. Sind die Daten an ihrem Zielrechner angekommen muss es auch eineMoglichkeit geben, sie einem bestimmten Programm bzw. Prozess zuzuordnen. Diese Zuordnung er-folgt sowohl bei TCP als auch bei UDPuber so genannte Ports. Ports sind 16 Bit groß, haben alsoeinen Wertebereich von 0 bis 65.535. Ports im Bereich von 0 bis 1023 werden alswell-knownPortsbezeichnet. Hinter diesen Nummern verbergen sich standardmaßig bestimmte Programme oder Pro-zesse, so dass zum Beispiel ein Benutzer, der sich mittels SSH zu einem entfernten Rechner verbindenmochte, weiß, dass er diesuber Port 22 machen kann. Um entscheiden zu konnen, an welchen Prozessdie Daten ausgeliefert werden sollen, kann jede Portnummer nur genau einmal zugewiesen werden.Allerdings kann ein Port fur UDP und TCP gleichzeitig vergeben werden. Denn im empfangendenRechner kann anhand der im IP-Header untergebrachten Steuerinformationen entschieden werden, anwelchen der beiden Dienste die Daten weitergegeben werden und somit ist die Zuweisung eindeutig.Die Kombination aus IP-Adresse und Port bezeichnet man als Socket.

3 UDP

3.1 Einfuhrung

Wie breits erwahnt lasst sich dasUser Datagram Protocol[1] als verbindungslos und unzuverlassigcharakterisieren. Das bedeutet, dass Daten ohne vorherige Ankundigung oderUberprufung auf Er-reichbarkeit des Hosts abgeschickt werden und dass beiUbertragungsfehlern die betroffenen Da-tensatze nicht erneutubertragen werden. In beiden Punkten unterscheidet sich UDP von TCP. Einweiterer Unterschied besteht in der Art, wie die Daten verschickt werden. Die UDP-Schicht ver-schickt die Daten als Datagramme in der von der Anwendung bestimmten Große, wahrend die TCP-Schicht die Große der Datensatze selbststandig bestimmt. Da das zugrunde liegende Netzwerk aber

5

Daten (Sofern vorhanden)

8 Byte

16-Bit Source Port Number 16-Bit Destination Port Number

16-Bit UDP Length 16-Bit UDP Checksum

Abbildung 2: UDP-Header

nur eine begrenzte Kapazitat hat, kann es die Daten moglicherweise nicht zusammenhangend trans-portieren. Sie mussen also unterteilt (fragmentiert) werden. Diese Fragmentierung wird durch dieIP-Schicht vorgenommen und fuhrt zu einem großeren Datenaufkommen, da fur jedes Segment einneuer Header generiert werden muss, damit alle Fragmente ihr Ziel finden. Durch diese Fragmentie-rung vergroßert sich aber auch dieUbertragungsunsicherheit, denn die Gegenseite kann mit einzelnenFragmenten nichts anfangen. Erst wenn alle Fragmente durch die IP-Schicht wieder in der richtigenReihenfolge zusammengesetzt wurden, kann der Prozess die Daten auswerten. Aufgrund eines be-grenzten Empfangspuffers konnen Fragmente nicht unbegrenzt zwischengespeichert werden. Nacheinem festgelegten Zeitraum werden diese Daten verworfen. Auf die Fragmentierung durch IP wirdin Abschnitt 3.3 eingegangen.Trotz dieser Schwierigkeiten hat UDP seine Daseinsberechtigung. Anwendungen die UDP verwendenwerden in Abschnitt 3.5 beschreiben.

3.2 Header

Der UDP-Header belegt 8 Byte, die in 4 je 2 Byte große Felder aufgeteilt sind (s. Abb. 2). Der an denHeader angehangte Datenblock hat keine festgelegte Große.

• Source Port(Bit 0 - 15)Fur den Fall, dass die Gegenseite antworten mochte, kann sie Pakete an den hier angegebenenPort senden. Der sendende Rechner muss aber nicht zwangslaufig auf dem hier angegebenenPort empfangsbereit sein.

• Destination Port (Bit 16 - 31)Dieses Feld enthalt den Port, auf dem ein Prozess auf dem Zielrechner auf UDP-Datagrammewartet. In vielen Fallen handelt es sich hier um die schon angesprochenenwell-knownPorts.

• UDP Length (Bit 32 - 47)Hier wird die Lange des gesamten Datagramms, also sowohl die der Nutzdaten als auch desHeaders, in Byte angegeben. Da dasLenght-Feld im IP-Header ebenfalls 2 Bytes groß ist, kann

6

Daten (Sofern vorhanden)

16-Bit Source Port Number

16-Bit UDP Length

UDP

Pseudo

Header

32-Bit Source IP Address

32-Bit Destination IP Address

Zero 8-Bit Protocol (17)

16-Bit UDP Length

16-Bit Destination Port Number

16-Bit UDP Checksum

Pad Byte (0)

UDP

Header

Abbildung 3: Pseudo Header zur Checksum-Berechnung

die maximale Datenmenge eines UDP-Pakets nicht großer als 65.535 Byte (16 Bit unsigned) -20 Byte des IP-Headers - 8 Byte des UDP-Headers = 65.507 Byte sein.

• Checksum(Bit 48 - 63)Die Prufsumme (Checksum) erlaubt es, Fehler in der Datenubertragung aufzudecken. Ein sol-cher Fehler fuhrt dazu, dass ein Datagramm ohne Fehlermeldung geloscht wird. Die Berech-nung der Prufsumme deckt das komplette UDP-Datagramm, also sowohl den Header als auchdie Daten, ab. Zusatzlich wird ein Pseudo-Header, der einige Felder des IP-Headers enthalt, zurBerechnung hinzugezogen (s. Abb. 3). Bei der Berechnung werden 16-Bit-Worter im Einer-Komplement addiert und das Einer-Komplement dieser Summe imChecksum-Feld eingetra-gen. Eine ungerade Bytezahl im Datenteil wird durch einPad-Bytemit Wert 0 ausgeglichen,das aber nicht mitubertragen wird.Im Gegensatz zu TCP ist bei UDP die Berechnung der Prufsumme zwar nicht vorgeschrieben,wird aber immer empfohlen. Wenn keine Berechnung erfolgt, wird die Prufsumme 0 gespei-chert. Ergibt eine Berechnung den Wert 0, wird dieser, wie im Einer-Komplementublich, durch16 1-Bits reprasentiert.

3.3 Fragmentierung durch IP

Eine Anwendung, die ihre Datenuber UDP verschickt, legt die Große der Datagramme fest, dasbedeutet, dass jeder Schreibvorgang einer Anwendung zu einem eigenen Datagramm fuhrt. Da dieGroße der auf einmalubertragbaren Daten eines Netzwerkes durch dieMaximum Transfer Unit

7

(MTU) nach oben begrenzt ist, sollten Anwendungen darauf bedacht sein, die Datagramme nichtzu groß werden zu lassen. Anderenfalls mussen diese fragmentiert werden, was fur jedes Fragmenteinen Overhead von 20 Byte bedeutet.Der IP-Schicht ist nur die MTU des Netzes, an das der Rechner direkt angeschlossen ist bekannt.Ein Paket muss aber unter Umstanden viele unterschiedliche Netze mit verschieden großen MTUsdurchlaufen, bevor es den Zielhost erreicht. Ist die MTU eines dieser Netze kleiner als die Große desDatensatzes, muss dieser Datensatz durch den entsprechenden Router fragmentiert werden, bevor erweitergeschickt werden kann. Unter Umstanden muss in folgenden Netzen der schon fragmentier-te Datensatz erneut fragmentiert werden. Wird beim Versand eines Datensatzes das IP-Header-FlagDon’t Fragmentgesetzt, um eine Fragmentierung zu verhindern, werden alle Pakete die großer alsdie Path-MTUsind verworfen. AlsPath-MTUwird die kleinste MTU auf dem Pfad zwischen zweiRechnern bezeichnet.

3.4 Effekte zwischen UDP und ARP

DasAddress Resolution Protocol(ARP) [3] wird verwendet, um zu einer IP-Adresse die zugehorigeHardwareadresse zu bestimmen. Wenn der ARP-Cache leer und das zu sendende UDP-Datagrammgroß ist, kann ein interessanter Effekt zwischen diesen beiden Protokollen beobachtet werden. Dasgroße UDP-Datagramm impliziert, dass es schon fur den Versand durch das erste Netz fragmentiertwerden muss. Die IP-Schicht generiert die Fragmente viel schneller, als eine Antwort auf die ARP-Anfrage fur das erste Paket eintrifft. Also werden fur alle weiteren Fragmente ebenfalls wegen desnoch leeren Caches ARP-Anfragen generiert, was zum so genanntenARP-Floodingfuhrt. TypischeARP-Implementierungen verwenden einen Puffer, in welchem Pakete zwischengespeichert werden,fur die ein ARP-Request verschickt werden muss. Pakete in diesem Puffer werdenuberschrieben,sobald ein neues Paket verschickt werden soll. Nachdem die Antwort auf die erste Anfrage ankommt,wird nur noch das letzte Paket verschickt, da jedes Paket durch seinen Nachfolger im Pufferuber-schrieben wurde, und sich nur noch das letzte Paket darin befindet.Uber diesen Fehler wird derSender nicht informiert. Auch der Empfanger kann keine Fehlermeldung generieren, da der UDP-Header, der sich im ersten Paket befand, nie angekommen ist. Es kann also nicht mehr zugeordnetwerden, von welchem Prozess dieses Paket stammte. Nach einemTimeoutmuss der Empfanger dieseseinzelne Paket verwerfen.

3.5 Anwendungen

Gerade wegen seiner Einfachheit gibt es einige Anwendungen, die UDP als Transportprotokoll bevor-zugen. Vor allem bei geringen Datenmengen bedeutet der kleine Header einen im Vergleich zu denNutzdaten geringen Overhead. Auch die Tatsache, dass keine Verbindung aufgebaut werden muss,reduziert im Vergleich zu TCP den Overhead.Ein Anwendungsgebiet ist der Client-Server Bereich, wo der Datenaustausch in Form von Anfra-ge und Antwort ablauft. Der Host, der die Anfrage verschickt, wird im Allgemeinen als Client, derEmpfanger der Anfrage als Server bezeichnet. Gehen Daten bei derUbertragung in eine der beiden

8

Richtungen verloren, startet die Anwendung, nachdem sie bei Ablauf eines Timers keine Antwort er-halten hat, eine erneute Anfrage. Als Beispiel fur eine solche Anwendung istRemote-Procedure-Call(RPC) [5] zu erwahnen. RPC ermoglicht es, Funktionen auf entfernten Rechnern aufzurufen, wo-bei der Funktionsaufruf sich bis auf wenige Einschrankungen nicht von “normalen” lokalen Funkti-onsaufrufen unterscheidet. Diese Vorgehensweise erleichtert deutlich die Programmierung von Netz-werkanwendungen.Ein weiteres wichtiges Anwendungsgebiet sind alle Arten von multimedialen Datenubertragungenwie digitales Fernsehen, Internet Radio oder Videokonferenzen, also Anwendungen bei denen eswichtig ist, dass sie in Echtzeit empfangen werden. Hier ist es von Vorteil, das UDPuber keineArt von Empfangsbestatigung oder erneutem Datagrammversand verfugt. Ubertragungsfehler fuhrendann zu kurzenUbertragungslucken, die weiteren Daten kommen aber nach wie vor in Echtzeit an.Bei TCP als Transportprotokoll kame es aufgrund der erneuten Segmentubertragung zu Verzogerun-gen der folgenden Daten. So konnte also keine Echtzeit gewahrleistet werden.Fur diesen Anwendungsbereich wurde 1989 das heute weit verbreiteteReal-Time Transport Proto-col (RTP) [6] entwickelt. Es ist der Anwendungsschicht zugeordnet, obwohl es von der Arbeitsweiseeigentlich der Transportschicht zugeordnet werden musste. Dieses Protokoll ermoglicht durch einenweiteren Header einige Funktionen, die fur multimediale Anwendungen nutzlich sind. Beispielswei-se werden die Datagramme nummeriert, um im Falle eines Datenverlustes entsprechend reagierenzu konnen. Fehlen nur wenige Daten kann so versucht werden, diese zu interpolieren. Eine weitereFunktion von RTP ist derTimestamp. Er ermoglicht eine relative Zeitangabe der Daten zum erstenubertragenen Datagramm. So konnen Daten zwischengespeichert werden, um dann zum richtigenZeitpunkt ausgewertet zu werden.

4 TCP

4.1 Einfuhrung

Wie bereits erwahnt, handelt es sich bei TCP [2] um ein zuverlassiges, verbindungsorientiertes Pro-tokoll, das Daten als Bytestrom versendet. Verbindungsorientiert bedeutet, dass bevor Daten ausge-tauscht werden konnen, eine Verbindung zwischen den beiden Rechnern hergestellt werden muss. Beidiesem Verbindungsaufbau werden wichtige Daten ausgetauscht, um die Verbindung zu initialisieren.Diese TCP-Verbindungen arbeiten im Fullduplex-Betrieb, das heißt beide Seiten konnen unabhangigvoneinander Daten verschicken.TCP und UDP unterscheiden sich in der Art der Datenubertragung. Aus diesem Grund werden dieDatensatze auch mit unterschiedlichen Namen versehen. Wahrend man bei UDP von einem Data-gramm spricht, ist bei TCP von einem Segment die Rede. Im Gegensatz zu UDP, wo die Anwendungdie Paketgroße und Anzahl festlegt, hat eine Anwendung, die Datenuber TCP verschickt, keinen Ein-fluss auf die Große der Segmente. Dabei ist es durchaus denkbar, dass beispielsweise 5 Segmentea20 Byte versendet werden und diese auf der Gegenseite als 100 Byte oder 10 mal 10 Byte von der An-wendung gelesen werden. Außerdemuberwacht die TCP-Schicht, wiederum im Gegensatz zu UDP,anhand der Sequenznummer die Reihenfolge, in der die Daten beim Empfanger eintreffen.

9

Daten (Sofern vorhanden)

16-Bit TCP Checksum

Options (Sofern vorhanden)

FIN

ACK

RST

PSH

SYN

URG

16-Bit Window Size

20 Byte

16-Bit Urgent Pointer

16-Bit Source Port Number 16-Bit Destination Port Number

32-Bit Sequence Number

32-Bit Acknowledgment Number

4-Bit

Header6-Bit Reserverd

Abbildung 4: TCP-Header

Um Zuverlassigkeit gewahrleisten zu konnen, gibt es verschiedene Ansatzpunkte. Jedem versende-ten Byte wird eine Sequenznummer (Sequence Number) zugeordnet, wobei in dem entsprechendenHeader-Feld jeweils die Sequenznummer des ersten Bytes eines Segmentes gespeichert wird. Nachdem erfolgreichen Empfang eines Segmentes auf der Gegenseite versendet diese eine Empfangs-bestatigung. Bleibt eine Bestatigung aus, werden die Bytes ab dem letzten bestatigten Byte erneutubertragen.Außerdem verfugt TCP wie auch UDPuber ein Header-FeldChecksum. Diese Prufsumme wird nachdem gleichen Prinzip berechnet, muss aber im Gegensatz zu UDP immer berechnet unduberpruftwerden. Bei fehlerhafter Prufsumme wird das Segment geloscht, da in dem Fall einer ausbleibendenBestatigung der Sender die Daten erneutubertragt.Als erstes folgt nun eine Beschreibung aller Felder des TCP-Headers. Im Anschluss wird ausfuhrlichauf die Punkte Verbindungsaufbau, Verbindungsabbau und Datentransfer eingegangen.

4.2 Header

Da TCP, wie auch UDP, das unzuverlassige, verbindungslose Internet Protocol zum Versenden derDaten verwendet, werden einige zusatzliche Informationen benotigt, um den gewunschten Dienstanbieten zu konnen. Hierzu wird ein Header mit einer Mindestgroße von 20 Byte, also 12 Byte mehrals bei UDP, verwendet (s. Abb. 4). Der Datenteil ist bei TCP optional. Das heißt, es konnen auchSegmente verschickt werden, die nur aus einem Header bestehen.Die Bedeutung der einzelnen Felder wird im Folgenden beschrieben.

10

• Source Port(Bit 0 - 15),Destination Port (Bit 16 - 31)Eine Verbindung wird eindeutiguber das 4-Tupel (Source-IP, Source-Port, Destination-IP, Des-tination-Port) identifiziert. Da die IP-Adresse der beiden Hosts im IP-Header festgelegt wird,mussen im TCP-Header nur die Ports gespeichert werden.Uber diese Ports kann entschiedenwerden, an welche Anwendung auf dem jeweiligen Host die Daten weitergegeben werden sol-len.

• Sequence Number(Bit 32 - 63)Jedem Byte wird eine Sequenznummer zugeordnet, wobei die Nummer des ersten versendetenBytes jeder Seite wahrend des Verbindungsaufbaus festgelegt wird. Diese Nummer wird vor-zeichenlos gespeichert, daher konnen Nummern von 0 bis232 − 1 vergeben werden, bevor eszu einemUberlauf kommt.

• Acknowledgment(Bit 64 - 95)Die Bestatigungsnummer (Acknowledgment) gibt die Sequenznummer an, die als nachste er-wartet wird. Sie ist nur gultig, wenn das ACK-Flag gesetzt ist. Implizit wird der Empfang allerBytes mit kleinerer Sequenznummer bestatigt.

• Header Length (Bit 96 - 99)Die Lange des TCP-Headers kann aufgrund desOption-Feldes zwischen 20 Byte (keine Optio-nen) und 60 Byte variieren. Da mit den zur Verfugung stehenden 4 Byte nur 16 Werte dargestelltwerden konnen, wird hier die Header-Lange in 32-Bit Worten angegeben.

• Reserved(Bit 100 - 105)Dieser Bereich wird bis heute nicht genutzt. Die Tatsache, dass dieses Felduber ein Jahrzehnt“ uberlebt” hat, wird als Beleg dafur angesehen, wie gut TCP ausgelegt wurde.

• 6 Flags(Bit 106 - 111)

– URG UrgentDringende Daten wurden versendet. Der Urgent Pointer wurde gesetzt.

– ACK AcknowledgmentDurch das Ack-Bit wird angezeigt, dass die Bestatigungsnummer gesetzt ist, um den Emp-fang von Daten zu mitzuteilen.

– PSHPushWenn dieses Bit gesetzt ist, werden Daten so schnell wie moglich an die Anwendungweitergegeben.

– RST ResetSetzt eine Verbindung zuruck.

– SYNSynchronizeDieses Flag wird gesetzt, wenn eine neue Verbindung aufgebaut wird. (s.u.)

– FIN FinishedFIN dient zum Beenden einer Verbindung.

11

• Window Size(Bit 112 - 127)Der TCP-Empfangs-Puffer hat nur eine begrenzte Große. Aus diesem Grund wird in diesemFeld angegeben, wie viele Byte noch empfangen werden konnen. Dadurch wird erreicht, dasskein schneller Sender einen langsamen Empfanger mit Datenuberfluten kann.

• Checksum(Bit 128 - 143)Die Berechnung die gleiche wie bei UDP. Der einzige Unterschied ist, dass die Berechnung undAuswertung hier obligatorisch ist und nicht wie bei UDP lediglich empfohlen wird.

• Urgent Pointer (Bit 144 - 159)Bei gesetztem URG-Bit wird durch diesen Pointer das letzte Byte dringender Daten gekenn-zeichnet. Diese Daten werden dann umgehend, ohne Beachtung der Reihenfolge des Daten-stroms, an den Prozess weitergeleitet.

• Options (zwischen 0 und 40 Byte)Dieses Feld ermoglicht die Verwendung von Funktionen, die im normalen Header nicht verfugbarsind. Im nachsten Abschnitt werden dazu einige Beispiele angegeben.

4.2.1 Header Optionen

Soll dieses Feld fur eine zusatzliche Option verwendet werden, muss zuerst der Typ, dann die Langeder Option und zum Schluss die eigentliche Option angegeben werden. Ist die Option lediglich einFlag braucht nur der Typ angegeben werden. Die Gesamtlange der Optionen muss ein Vielfaches von4 Byte betragen, da die Header-Lange ein Vielfaches von 32-Bit (4 Byte) betragen muss.

End Of Option List (Typ 0) Mit dieser Option wird das Ende der Optionenliste im Header markiert.

No Operation (Typ 1) Diese Option dient zum Auffullen des Headers auf ein Vielfaches von 4 Byte.

Maximum Segment Size (Typ 2)Diese Option wird haufig beim Verbindungsaufbau verwendet undin diesem Zusammenhang noch genauer erlautert. Die Lange der Option ist auf 4 Byte festge-legt.

4.3 Verbindungsmanagement

4.3.1 Verbindungsaufbau

Vor jedem Datentransfer muss zuerst eine Verbindung hergestellt werden. In den meisten Fallen wer-den Verbindungen zwischen einem Server, der einen speziellen Dienst anbietet, und einem Client,der diesen Nutzen will, hergestellt. Wobei der Wunsch nach einer Verbindung dann meist aktiv vomClient ausgeht. Es gibt aber auch Falle, in denen beide Parteien nahezu gleichzeitig eine Verbindungaufbauen wollen. Beide Varianten werden im Folgenden beschrieben.

12

Mit dem Aufbau einer Verbindung werden zwei Dinge beabsichtigt: Zum einen kann souberpruftwerden, ob der Rechner, mit dem Daten ausgetauscht werden sollen,uberhaupt empfangsbereit ist,zum anderen werden so wichtige, fur die Verbindung benotigte Daten ausgetauscht.Eine erste wichtige Information, die dabei ausgetauscht wird, ist dieInitial Sequence Number(ISN).ISN + 1 ist die Nummer des ersten zu versendenden Byte, da das SYN-Flag seinerseits eine Se-quenznummer “verbraucht”. Bei jedem Verbindungsaufbau sollte die ISN variieren. Hierdurch sollverhindert werden, dass Segmente, die verspatet ankommen, nicht versehentlich der aktuellen Ver-bindung zugeordnet werden konnen. RFC 793 [2] schreibt dabei vor, die ISN als 32 Bit-Zahler alle4 Mikrosekunden zu erhohen. Tatsachlich wird die ISN in verschiedenen Implementierungen aufunterschiedliche Weise generiert (4.4BSD erhoht den Wert des Zahlers beispielsweise alle 8 Mikro-sekunden).Nach einem Verbindungsaufbau ist beiden Seiten der Socket ihres Kommunikationspartners bekannt.Uber dieses 4-Tupel (RechnerA IP-Adresse, RechnerA Port, RechnerB IP-Adresse, RechnerB Port)ist eine TCP-Verbindung eindeutig identifiziert. Mehrere Verbindungen zwischen zwei Rechnern sindproblemlos moglich, wenn fur neue Verbindungen auf mindestens einem Rechner ein anderer Portverwendet wird.Oft wird beim Verbindungsaufbau auch dieMaximum Segment Size(MSS) ausgetauscht. Die MSSist ein Beispiel fur eine Funktion, die vom Standard-Header nicht zur Verfugung gestellt wird undaus diesem Grunduber das FeldOptionsrealisiert wird. Sie ist 4 Byte groß und gibt die Segment-große, die maximal empfangen werden kann, in 2 Byte an. Geben beide Rechner eine MSS an, ist dieniedrigere Zahl ausschlaggebend. Wird dagegen keine MSS angegeben, werden maximal 536 Bytean Daten versendet. Das entspricht einem IP-Paket von 536 Byte (Daten) + 20 Byte (TCP-Header) +20 Byte (IP-Header) = 576 Byte.

3-Way-Handshake (3 Wege Handschlag)Ein Großteil aller Verbindungen wirduber den so genannten 3-Way-Handshake aufgebaut. Wie derName vermuten lasst, werden hier 3 Segmente ausgetauscht, um die Verbindung zu initialisieren.Abbildung 5 zeigt einen solchen typischen Verlauf. Vorraussetzung ist hierbei immer, dass auf einemRechner (meist als Server bezeichnet) ein Prozess (z.B. SSH, FTP, etc.) gestartet ist, der auf einemfestgelegten Port auf Verbindungen von anderen Rechnern wartet. Der Zustand von diesem Serverwird mit LISTEN bezeichnet.Angaben des Zustandes wie hier LISTEN beziehen sich auf Abbildung 7, in der eineUbersichtuberalle moglichen Zustande gegeben ist.

1. Das erste Segment geht vom Client aus, der einen Dienst des Servers nutzen mochte. DiesesSegment wird mit gesetztem SYN-Flag versendet, als Zeichen, dass eine neue Verbindung auf-gebaut werden soll. Es enthalt außerdem den Port auf dem der Server auf die Verbindung wartet,sowie den eigenen Port, auf dem seinerseits der Client Daten empfangen kann. Des Weiterenwird die ISN (hier 1415531521)ubertragen. Da noch keine Daten empfangen wurden, ist dieWindow-Size noch gleich dem Startwert (hier 4096). Auch die Moglichkeit der Mitteilung derMSS (1024) wird hier genutzt.Der Clientandert nach dem Versand seinen Zustand von CLOSED in SYNSENT.

13

SYN 1415531521:1415531521 (0)<mss 1024>

SYN 1823083521:1823083521 (0)

ack<mss 1024>

1415531522,

ack 1823083522

Client Server

Segment 1

Segment 3

Segment 2

Abbildung 5: TCP 3-Way-Handshake

2. Hat der Server dieses Segment empfangen, versendet er ein Segment, ebenfalls mit gesetztemSYN-Flag, in dem er seine ISN (1823083521) bekannt gibt. Außerdem muss er die ISN desClients bestatigen, indem er bei gesetztem ACK-Flag ISN+1 als Bestatigungsnummer zuruck-schickt. Auch der Server teilt dem Client eine MSS von 1024 mit. Die Mitteilung der eigenenISN und die Bestatigung der ISN des Clients geschieht in einem Segment. Danach wechselt derServer in den Zustand SYNRCVD.Obiges gilt jedoch nur fur den Fall, dass der Server im Status LISTEN auf eine Verbindung ge-wartet hat. War dies nicht der Fall, kann keine Verbindung aufgebaut werden. Der Server sendetein Segment mit gesetztem RST-Flag (s. Verbindungs-Reset), um die Verbindung abzubrechen.

3. Um den Verbindungsaufbau abzuschließen, muss nun auch der Client die ISN des Serversbestatigen, indem wiederum dessen ISN+1 bei gesetztem ACK-Flag gesendet wird. Das SYN-Flag ist nun nicht mehr gesetzt.Nach dem Versand des dritten Segments, wechselt der Client in den Zustand ESTABLISHED.Sobald der Server das 3. Segment empfangt, wechselt auch er in den Zustand ESTABLISHED.Damit ist die Verbindung erfolgreich aufgebaut und es konnen Datenubertragen werden.Der Client hat die Moglichkeit, zusammen mit dem ACK bereits die ersten Daten zuubertragen.

Der Sender des ersten Segments mit SYN-Flag (hier der Client) vollzieht einen aktiven Verbindungs-aufbau (Active Open), der Server, der das zweite Segment schickt einen passiven (Passive Open).

Simultaner VerbindungsaufbauIn seltenen Fallen, kann es auch vorkommen, dass zwei Hosts nahezu gleichzeitig versuchen, ei-ne Verbindung aufzubauen. Dazu mussten aber beide Hosts den Port des jeweils anderen kennen.Bei einem simultanen Verbindungsaufbau entfallt die Unterscheidung zwischen Server und Client.Beide senden ein Segment mit SYN-Flag und der jeweiligen ISN (wie oben unter 1. beschrieben).Dieses SYN Segment wird von beiden Hosts empfangen und bestatigt. Nach dem Empfang dieser

14

ack 1823083523

FIN 1415531522:1415531522 (0) ack 1823083522

FIN 1823083522:1823083522 (0) ack 1415531523

ack 1415531523

Client Server

Segment 2

Segment 1

Segment 4

Segment 3

Abbildung 6: TCP Verbindungsabbau

Bestatigung ist die Verbindung aufgebaut. Fur den Verbindungsaufbau werden in diesem Fall also 4Segmente benotigt.

4.3.2 Verbindungsabbau

Verbindungsabbau per Half CloseWahrend fur den Verbindungsaufbau im Normalfall drei Segmente benotigt werden, sind es beimVerbindungsabbau vier. TCP-Verbindungen arbeiten im Fullduplex-Betrieb, das heißt, in beide Rich-tungen konnen unabhangig voneinander Daten verschickt werden. Beim Beenden einer Verbindungmussen beide Richtungen separat getrennt werden. So kann durch denHalf Closeeine Seite ihreVerbindung beenden, aber noch beliebig lange Daten von der Gegenseite empfangen. Es gibt in derPraxis aber nur wenige Anwendungen, die diese Moglichkeit nutzen, eine davon, rsh, wird im Ab-schnitt “Anwendung des Half-Close” beschrieben. Wie auch beim Verbindungsaufbau wird zwischenaktivem Verbindungsabbau (Active Close, Sender des ersten FIN) und passivem Verbindungsabbau(Passive Close, Sender des zweiten FIN) unterschieden.In Abbildung 6 ist diese Art des Verbindungsabbaus dargestellt.

1. Einer der beiden Hosts, auch hier ist es wieder in den meisten Fallen der Client, vollzieht denso genanntenActive Close, indem er ein Segment mit gesetztem FIN-Flag versendet. Das kannauch das Segment sein, mit dem die letzten Daten verschickt wurden.Nach dem Versand dieses Segmentes wechselt der Client vom Status ESTABLISHED in denStatus FINWAIT 1.

2. Empfangt der Server ein Segment mit gesetztem FIN-Flag bestatigt er dessen Empfang, be-nachrichtigt die Anwendung, dass die Gegenseite die Verbindung beenden mocht und wechseltin den Zustand CLOSEWAIT.

15

Nach dem Empfang des ACK wechselt der Client vom Zustand FINWAIT 1 in den ZustandFIN WAIT 2, um hier auf ein FIN des Servers zu warten.

3. Die Server-Anwendung kann, aufgrund des einseitigen Verbindungsabbaus, jetzt weiterhin Da-ten verschicken und sobald sie ebenfalls die Verbindung trennen mochte sendet sie ihrerseitsein FIN. Danach wechselt sie in den Zustand LASTACK.

4. Der letzte Schritt ist die Bestatigung des FIN und der Wechsel in den Zustand TIMEWAIT.Hier verbleibt der Client fur die ZweifacheMaximum Segment Lifetime(MSL) bevor er dannden Status CLOSED annimmt. Der Server wechselt direkt nach dem Empfang des ACK in denZustand CLOSED.

Anwendung des Half CloseEine Anwendung, die die Moglichkeit des Half Close nutzt, istRemote Shell(rsh), welche Kom-mandos auf anderen Rechner ausfuhrt. Dabei wird die Standard-Eingabe per TCP zu dem entferntenRechner kopiert und dessen Ausgabe auf dem Terminal des Client-Rechners ausgegeben. Nach demKopieren der Standard-Eingabe beendet rsh die Richtung zu dem Rechner, um ihm zu signalisieren,dass die Eingabe beendet ist, und er beginnen kann das Kommando auszufuhren. Da die Verbindungnur in einer Richtung geschlossen ist, kann der Rechner die Ausgabe des Kommandos ohne Problemezuruckschicken. Danach beendet auch er die Verbindung.

Simultaner VerbindungsabbauIn Analogie zum Verbindungsaufbau ist es beim Abbau moglich, wenn auch eher zufallig, dass beideHosts nahezu gleichzeitig die Verbindung beenden mochten. Dabei wechseln beide nach dem Sendendes FIN-Segments in den Zustand FINWAIT 1 und von dort aus nach Empfang und Bestatigung desFIN in den Zustand CLOSING. Nachdem die Rechner die Bestatigung empfangen haben, wechselnsie in den Zustand TIMEWAIT. Bei einem simultanen Verbindungsabbau mussen also beide Seitenzuerst die zweifache MSL abwarten, bevor sie den Zustand CLOSED annehmen.

Verbindungs-ResetIn einigen Fallen wird eine Moglichkeit gebraucht, um eine Verbindung abzubrechen. TCP ermoglichtdies durch das Setzen des RST-Flags im TCP-Header. Ein Reset wird oft versendet, wenn dem Portin der Verbindungsanfrage kein Prozess zugeordnet ist, beziehungsweise ein zugeordneter Prozessnicht im Zustand LISTEN auf eine Verbindung wartet. Empfangt ein Host, nachdem er das erste SYNversendet hat, ein Segment mit gesetztem RST-Flag, kann der User daruber informieren werden, dasskeine Verbindung moglich ist.Es ist beiden Hosts moglich, eine Verbindung zuruckzusetzen anstatt sie auf die oben beschriebeneWeise zu beenden. In diesem Fall werden alle Daten verworfen die noch zum Versand anstanden unddie Verbindung unmittelbar getrennt. Man spricht dann von einemAbortive Releaseim Gegensatz zudem oben beschriebenenOrderly Release.

16

Auch in dem Fall von halb-offenen (Half-Open) Verbindungen wird ein RST versendet. Eine Verbin-dung wird als halb-offen bezeichnet, wenn eine Seite die Verbindung ohne Kenntnis der anderen Seitebeendet oder abgebrochen hat. Das ist zum Beispiel der Fall, wenn einer der beiden Rechner absturztoder er ohne vorheriges Runterfahren ausgeschaltet wird. Solange der andere Rechner keine Datenubertragen will, wird er nicht merken, dass der Kommunikationspartner nicht mehr empfangsbereitist. Dieses Problem entsteht oft bei Client-Server-Verbindungen, wenn der User sich nicht die Muhemacht, die Programme, die TCP verwenden, ordnungsgemaß zu beenden. Da der Server in den meis-ten Fallen von sich aus keine Daten versendet, bemerkt er nicht, dass der Rechner neu gestartet wurde.Verwendet der User ein entsprechendes Programm erneut, wird eine neue Verbindung aufgebaut. Aufdiese Weise konnen viele halb-offene Verbindungen entstehen. In dem Fall, dass der Server doch vonsich aus Datenuber eine solche Verbindung senden will, antwortet der Client, der nichts mehr mitden empfangenen Verbindungsdaten anfangen kann, mit einem RST-Segment.

4.3.3 Zustandsubergangsdiagramm

Im Zustandsubergangsdiagramm sind alle Regeln fur den Verbindungsauf- und -abbau zusammenge-fasst (s. Abb. 7). Die Zustandsubergange, die ein Client normalerweise vollzieht, sind fett und die desServers gestrichelt markiert. Oberhalb der Pfeile ist notiert, welches Ereignis einenUbergang auslostund unterhalb wie darauf reagiert werden soll.

TIME WAIT oder 2 MSL Wait StateDer ZustandTIME WAIT wird auch als 2 MSL Wait State bezeichnet. Die Verbindung muss fur diezweifache MSL in diesem Zustand verharren, in dem alle verspateten Segmente verworfen werden.Dadurch wird sichergestellt, dass keine verspateten Segmente als Teil einer neuen Verbindung fehlin-terpretiert werden.

Quiet TimeEs kann vorkommen, dass ein Host, wahrend er sich in derTIME WAIT-Phase befindet, absturzt,innerhalb von 2 MSL Sekunden rebootet und eine neue Verbindung aufbaut. In diesem Fall konnenverspatete Segmente ebenfalls als Teil der neuen Verbindung interpretiert werden. Um diesen Fallauszuschließen, gibt es dasQuiet Time Concept, das besagt, dass ein Rechner nach einem NeustartMSL Sekunden warten muss, bevor er eine neue Verbindung aufbauen darf.

4.4 Datenubertragung

Sobald beide Hosts den Status ESTABLISHED erreicht haben, konnen Daten in beide Richtungenuber das Netzwerkubertragen werden. Auch in den Zustanden FINWAIT und CLOSEWAIT (nacheinem Half-Close) ist eine Datenubertragung moglich, hier aber nur in eine Richtung. In diesem Ab-schnitt wird immer vom Zustand ESTABLISHED ausgegangen, sofern nichts anderes erwahnt wird.

17

Abbildung 7: TCP Zustandsubergangsdiagramm [7]

18

Bei genauer Betrachtung der TCP-Segmente lassen sich diese in zwei Bereiche unterteilen. In Seg-mente, die interaktive Daten enthalten (Interaktiver Datentransfer zum Beispiel bei Anwendungen wieRLogin, SSH, TELNET, etc.) und solche, die dem Dateitransfer dienen (Bulk Datentransfer bei An-wendungen wie FTP, SMTP, HTTP, etc.). Wahrend Segmente beim interaktiven Datentransfer meistnur wenige Byte groß sind, sind Bulk-Daten-Segmente haufig großtmoglich. Eine 1991 von Caceresdurchgefuhrte Studie [10] ergab, dass ca. 90% der Segmente weniger als 10 Byte an Nutzdaten ent-halten.Die unterschiedlichen Anforderungen beider Anwendungsbereiche an die Transportschicht fuhrten zuunterschiedlichen Algorithmen fur den Umgang mit den Daten. Algorithmen, die beim interaktivenDatentransfer eingesezt werden, versuchen, die Segmentanzahl und damit den durch deren Headerentstehenden Overhead zu reduzieren. Solche, die beim Bulk-Datentransfer zum Einsatz kommen,haben einen hohen Durchsatz zum Ziel.Im Folgenden werden zuerst einige Gesichtspunkte der zuverlassigen Datenubertragung und dann dieAlgorithmen fur die beiden Bereiche beschrieben.

4.4.1 Verbindungssicherheit

TCP gewahrleistet die Verbindungssicherheit unter anderem dadurch, dass empfangene Segmentebestatigt werden mussen. Bestatigungen erfolgen kumulativ, das heißt, dass jeweils das letzte korrektempfangene Byte bestatigt wird. Es gibt keine Moglichkeit den Verlust eines Segmentes explizit mit-zuteilen. Um dennoch auf der Senderseite einen Segmentverlust feststellen zu konnen, bestatigt derEmpfanger bei jedem außerhalb der erwarteten Reihenfolge empfangenen Segment das letzte korrektempfangene Byte erneut. Auf eine solche duplizierte Bestatigung konnen Algorithmen wieSlow Startentsprechend reagieren.Sowohl die Daten, als auch deren Bestatigung konnen wahrend des Transportes durch das Netz ver-loren gehen. Aus diesem Grund wird einRetransmission Timerverwendet, um Daten erneut zu ver-senden, wenn innerhalb einer vorgeschriebenen Zeit keine Bestatigung eintrifft.Da sich der Durchsatz des Netzesandern kann (durch unterschiedlich starke Belastung oder sichandernden Routen durch das Netz) ist ein fest vorgegebenerRetransmission-Timeout-Value(RTO)nicht praktikabel. Um diesen Wert an die Netzgeschwindigkeit anzupassen, wird dieRound-Trip-Time(RTT) so oft wie moglich gemessen, um daraus den RTO zu berechnen (s. unten).Trifft f ur ein Segment keine Bestatigung innerhalb von RTO Sekunden ein, wird das Segment er-neut ubertragen und die RTO verdoppelt, da das Netz stark ausgelastet scheint. Das Segment wirdso lange neuubertragen und die RTO verdoppelt (ab einem Wert von 64 Sekunden bleibt die RTOkonstant), bis entweder eine Bestatigung fur dieses Segment eintrifft, oder 9 Minuten verstrichen sind(Exponential Backoff). Im ersten Fall wird die RTT und damit auch der RTO neu berechnet, da dieNetzauslastung scheinbar abgenommen hat. Im zweiten Fall wird die Verbindung mittels RST vomSender beendet.

Berechnung von RTT und RTODie RTT ist die Zeit, die von dem Versenden eines Segments bis zum Empfang von dessen Bestati-gung verstreicht. Um diese Zeitspanne zu bestimmen, wird ein 500ms Timer verwendet. Mit einem

19

Zahler wird bestimmt, wie oft dieser Timer zwischen Versand eines Segmentes und dessen Bestati-gung ablauft. Da der Timer relativ zum Systemstart und nicht zum Versand des Segmentes ablauft,erfolgt die erste Erhohung des Zahlers zwischen 1ms und 500ms nach dem Segmentversand. DieMessung ist daher nicht sehr genau und kann auch trotz gleicher Zeiten Schwanken. Aus diesemGrund wird der Wert durch die folgende Formel geglattet, wobei M die aktuelle Messung und R denberechneten Wert bezeichnet.

R = α ·R + (1− α) ·M, mit 0 ≤ α ≤ 1

Ein empfohlener Wert fur α ist 0.9, das heißt, eine neue Messung geht zu 10% in die Berechnung ein.Die meisten TCP-Implementierungen verwenden nur einen Zahler pro Verbindung, das schrankt dieMessung der RTT in einigen Fallen ein. Werden beispielsweise zwei Segmente kurz nacheinanderverschickt, kann nur fur das erste die RTT berechnet werden, da der Zahler schon in Gebrauch ist,wenn das zweite Segment versendet werden soll. Ebenfalls problematisch ist die Messung von Seg-menten, die erneutubertragen wurden. Ein ACK kann hier nicht eindeutig zugeordnet werden, daes verspatet von der erstenUbertragung eingetroffen sein kann oder erst von der zweiten. In diesenFallen wird die Berechnung verworfen.Der RTO wird aus dem Wert R mittels eines Faktorβ berechnet, fur den RFC 793 einen Wert von 2empfiehlt.

RTO = β ·RNachdem es zu einem Timeout gekommen ist, darf die RTO aufgrund desExponential Backoffnichtneu berechnet werden. Erst nachdem wieder eine Bestatigung eingetroffen, ist werden weitere RTT-Messungen vorgenommen.

4.4.2 Interaktiver Datentransfer

Beim interaktiven Datentransfer werden nur kleine Datenmengen transportiert. Bei Konsolenanwen-dungen wie RLogin fuhrt jeder Tastendruck zu zwei Segmenten in denen jeweils 1 Byte an Datentransportiert werden (so genanntenTinygrams), sowie zwei Segmenten zur Bestatigung: Beim Druckdes Anwenders auf eine Taste wird ein Segment generiert, was vom Server zunachst durch ein wei-teres Segment bestatigt wird. Anschließend wird dem Anwender die Auswirkung des Tastendrucksin einem dritten Segment mitgeteilt (Haufig ist das die Darstellung des Zeichens in der Konsole),welches abschließend ebenfalls bestatigt wird. Fur dieses eine Zeichen werden also 80 Byte an TCP-Headern und lediglich 2 Byte an Daten transportiert. Dies macht deutlich, wie wichtig Algorithmensind, die versuchen die Anzahl der versendeten Pakete zu reduzieren. Zwei dieser Algorithmen wer-den im Folgenden beschrieben.

Delayed AcknowledgmentsDelayed Acknowledgments sind dafur verantwortlich, dass ein oben beschriebenes Szenario im Nor-malfall nicht vorkommt. Es ist nicht notwendig, dass der Empfang eines Segmentes umgehend bestatigtwird. Stattdessen besteht die Moglichkeit, bis zu 200 ms darauf zu wartet, ob Daten zuruckgeschickt

20

werden mussen. Ist das der Fall, kann das ACK zusammen mit den Datenubertragen und so ein Seg-ment eingespart werden. Fur das obige Beispiel bedeutet dies, dass die Segmente 2 und 3 zu einemzusammengefasst werden.Fur die Zeitmessung wird ein Timer benutzt, der alle 200 ms relativ zum Rechnerstart ablauft. Dasbedeutet, dass die Bestatigungen zwischen 1 und 200 ms hinausgezogert werden konnen. Treffen indiesem Zeitraum Daten zum Versand ein, werden diese bereits vor Ablauf des Timers zusammen mitdem ACK verschickt. Falls nach Ablauf des Timers keine Daten angefallen sind, wird das ACK ineinem eigenen Segment gesendet.

Nagle AlgorithmusNagles Algorithmus [4] versucht, die Netzwerkbelastung, die durch den Versand von vielenTiny-gramsentsteht, zu vermeiden. Fur den Fall, dass eine Empfangsbestatigung fur vorrangehende Datennoch nicht eingetroffen ist, werden alle von der Anwendung an die TCP-Schicht weitergegebenenDaten zuruckgehalten. Trifft die Empfangsbestatigung ein, kann so eine großere Datenmenge versen-det werden.Nagles Algorithmuspasst sich somit an die Geschwindigkeit und Auslastung des Netzes an. Kommenbei einem wenig belasteten Netz ausstehende Segment-Bestatigungen schnell an, werden warten-de Daten ebenso schnell verschickt. Ist dagegen die Netzauslastung hoch, werden Daten gesammeltund in großen Segmenten mit großen Zeitabstanden verschickt, um dadurch das Netzwerk zu entlas-ten. Wahrend bei der Datenubertragung in schnellen Netzen die Auswirkung dieses Algorithmus beiKonsolenanwendungen kaum spurbar ist,außert sich sein Einsatz in langsamen Netzen dadurch, dassZeichen bei Konsolenanwendungen verzogert und in Schuben dargestellt werden.Es gibt auch Anwendungen, fur die Nagles Algorithmus hinderlich ist. Das X Windows System isteine solche. Hier mussen auch kleine Datenmengen, zum Beispiel die Bewegung des Mauszeigers,sofort versendet werden. Aus diesem Grund kann durch die TCPNODELAY-Socket-Option der Al-gorithmus deaktiviert werden.

4.4.3 Bulk-Datentransfer

Beim Bulk-Datentransfer werden haufig viele Daten in eine Richtung versendet. Die eingesetzten Al-gorithmen mussen also dafur sorgen, dass die Kapazitat des Netzwerkes ausgelastet wird, ohne es zuuberlasten.Bei TCP werden solche Algorithmen der Fluss- undUberlastkontrolle zugeordnet. Flusskontrollesorgt empfangerseitig dafur, dass der Sender den Empfanger nicht mit Datenuberfluten kann,Uber-lastkontrolle kontrolliert den Datenfluss auf der Senderseite.

Sliding WindowDas Sliding-Window-Protokoll [8] gehort zur Flusskontrolle.Uber dasWindow-Size-Header-Feld

kann der Empfanger dem Sender mitteilen, wie viele Daten noch empfangen werden konnen, bevorder Empfangspuffer voll ist (Offered Window). Aus dieser Angabe und der Datenmenge, die er bereits

21

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

bereits bestätigtgesendet,

nicht bestätigt

noch nutzbar

(usable window)

durch angegebene

Fenstergröße

(offered window)

Window-Size

erst nach

Fensterbewegung

nutzbar

Abbildung 8: TCP Sliding Window

ohne Bestatigung verschickt hat, kann der Sender errechnen, wie viel Speicherplatz im Empfangspuf-fer noch verfugbar ist (Usable Window). Alle zusatzlich versendeten Segmente wurden nur unnotigdas Netzwerk belasten, da der Empfanger sie aufgrund eines vollen Empfangspuffers loschen musste.Die Große und Position des Fensters verschiebt sich im Laufe einer Datenubertragung (s. Abb. 8). Esbeginnt immer nach der letzten bestatigten Sequenznummer und hat die durchWindow Sizeangege-bene Große. Durch die Bestatigung eines Segmentes verschiebt sich also der linke Rand des Fenstersnach rechts und verkleinert es auf diese Weise. Es kann wieder vergroßert werden, wenn die An-wendung Daten aus dem Puffer gelesen hat und bei dem nachsten Segment in Richtung Sender dieaktualisierteWindow Sizeangegeben wird. Ist die Anwendung nicht in der Lage, die Daten schnellgenug aus dem Puffer zu lesen (zum Beispiel bei einem langsamen Rechner), wird durch ein Emp-fangsfenster von 0 Byte der Datentransfer vorubergehend gestoppt. Wenn die Anwendung einen Teildes Puffers geleert hat, wird durch die TCP-Schicht das letzte ACK mit einer aktualisierten Fenster-große (ein so genanntesWindow Update) gesendet.Wie jedes andere Segment auch, kann dieses ACK verloren gehen. Ohne weitere Beachtung wurdedies zu einem Deadlock fuhren: Der Sender wartet auf einWindow Update, um weitere Daten schi-cken zu konnen, und der Empfanger wartet auf neue Daten. Um dies zu verhindern, wurde derPersistTimer eingefuhrt. Dieser erlaubt es dem Sender in festgelegten Abstanden (5, 6, 12, 24, 48, 60 Se-kunden) eineWindow Probebestehend aus dem nachsten Byte an den Empfanger zu schicken, um zuuberprufen, ob sich dieWindow Sizegeandert hat. Ist dies nicht der Fall wird das vorherige Byte erneutbestatigt und eine Fenstergroße von 0 Byte angegeben. Falls das Empfangsfenster wieder geoffnet ist,wird das neue Byte bestatigt und eine positive Fenstergroße angegeben, so dass der Datentransferwieder aufgenommen werden kann.Durch die Verwendung der fenster-orientierten Flusskontrolle kann es zu dem alsSilly Window Syn-dromebekannten Problem kommen. Es entsteht, wenn der Empfanger ein sehr kleines Fenster anbietet(ohne darauf zu warten ein großeres Fenster anbieten zu konnen), oder der Sender kleine Datenmen-gen sofort sendet ohne auf weitere Daten zu warten. Dieses Problem zu verhindern ist Aufgabe beiderSeiten. So darf der Empfanger nur ein neues Empfangsfenster anbieten, wenn es mindestens um ei-ne MSS oder um die Halfte seines Empfangspuffers vergroßert werden kann. Der Sender darf nurdann Segmente versenden, wenn ein maximales Segment zum Versand ansteht, mit einem Segmentmindestens die Halfte des angebotenen Fensters gefullt wird oder keine Bestatigung fur ein vorange-hendes Segment aussteht.

22

Die Große des Empfangspuffers betragt bei heutigen Implementierungen mindestens 4096 Byte, ei-nige Verwenden großere Puffer von 8192 oder sogar 16384 Byte.

Slow StartDas Sliding Window sorgt zwar dafur, dass der Empfanger nicht mit Segmentenuberflutet wird, eskann aber nicht verhindern, dass Daten moglicherweise an einem Router verloren gehen. Dies kannpassieren, wenn ein Router aufgrund eines langsamen Netzes Daten zwischenspeichern muss und seinSpeicheruberfullt ist. Dann muss er Segemente verwerfen, was den Durchsatz einer TCP-Verbindungstark beeintrachtigen kann.Aus diesem Grund mussen aktuelle TCP-Implementierungen einen Algorithmus namensSlow Startunterstutzen, der die Menge der Daten, die ins Netzwerk abgegeben werden, kontrolliert. Fur diesenZweck wird ein weiteres Fenster, dasCongestion Window(cwnd) auf der Senderseite verwaltet undmit dem Wert der MSS initialisiert. Nach jedem ACK wird dieses Fenster um eine MSS erhoht. Da-durch wachst dasCongestion Windowexponentiell (wird das erste Segment bestatigt konnen zweiweitere gesendet werden, werden auch diese bestatigt 4, usw.). Der Sender kann maximal bis zumMinimum voncwndundWindow Sizeubertragen ohne eine Bestatigung zu erhalten.Der Senderuberwacht den Empfang der ACKs und sieht den Empfang der dritten gleichen Sequenz-nummer als Anzeichen dafur an, dass mindestens ein Segment wegen der zu hohen Senderate auf demWeg zum Empfanger verloren gegangen ist. Aus diesem Grund wird dasCongestion Windowwiederauf die Große von einer MSS gesetzt undSlow Startbeginnt erneut.Durch das exponentielle Wachstum wird sehr schnell eine optimale Netzauslastung erreicht. Eben-so schnell kann es aber zu Segmentverlusten kommen, die vorubergehend zu einer sehr geringenNetzauslastung fuhren. Aus diesem Grund wirdSlow Startzusammen mit einem weiteren Algorith-mus,Congestion Avoidance, implementiert.

Congestion AvoidanceCongestion Avoidance [9] versucht, besser als Slow Start auf einen Segmentverlust zu reagieren. Erbasiert auf der Annahme, dass nur etwa 1% aller Segmente fehlerhaftubertragen werden. Die rest-lichen Segmente gehen durchuberfullte Router-Puffer verloren.Congestion Avoidancebenotigt eineweitere Variable,ssthresh, die Anfangs mit 65.535 Bytes initialisiert wird. Tritt jetzt ein Segment-verlust auf, wirdssthreshauf die Halfte derCurrent Window Size(Minimum ausWindow Sizeundcwnd, jedoch mindestens 2 MSS) gesetzt. Fur den Fall, dass der Segmentverlust durch einen Timeoutfestgestellt wurde, wirdcwndauf eine MSS reduziert. Andernfalls (Segmentverlust wurde durch du-plizierte ACKs festgestellt) wirdcwndaufsstreshgesetzt, da der Empfang eines ACK impliziert, dassnach wie vor Segmente beim Empfanger ankommen und so der Datenfluss auf eine geringere Mengeaber nicht ganz zuruck gesetzt werden muss.Die Vergroßerung des Sendefensters (cwnd) ist nun abhangig davon, welcher Algorithmus verwen-det wird. Istcwndkleiner oder gleichssthresh, wird Slow Startverwendet. Danach wirdCongestionAvoidanceverwendet, wodurch das Sendefenster lediglich um 1/cwnd vergroßert wird, wenn eineBestatigung eintrifft.

23

5 Zusammenfassung

In der vorliegenden Arbeit wurden nach der Einfuhrung einiger Grundlagen die beiden Transport-protokolle UDP und TCP aus dem TCP/IP-Protokollstapel vorgestellt. Die vielen verschiedenen An-wendungen im Bereich des Internets fuhrten zur Entwicklung von zwei sehr verschiedenen Proto-kollen. Das verbindungslose und unzuverlassige UDP wird haufig bei Echtzeit-Anwendungen (Ton,Bild oder Sprache) eingesetzt. Auch der Client-Server-Bereich, mit einem Kommunikationsschemanach dem Anfrage-Antwort Prinzip gehort zum Einsatzbereich von UDP. TCP wird immer dann ein-gesetzt, wenn zuverlassige Datenubertragung erforderlich ist. Dies ist vor allem beim Dateitransfer(FTP, HTTP, SMTP, usw.) der Fall. Aber auch Konsolenanwendungen wie TELNET oder SSH ver-wenden TCP.Nach der Vermittlung einiger Grundlagen wurde zuerst das wesentlich einfachere der beiden Pro-tokolle, UDP, beschrieben. Hauptaugenmerk lag hier bei der Erlauterung des Header-Aufbaus, demZusammenspiel von UDP mit IP und ARP, sowie zwei Anwendungen, bei denen UDP als Transport-ptotokoll zum Einsatz kommt.Bei der Beschreibung von TCP wurde ebenfalls zuerst auf den Aufbau des Headers eingegangen.Danach wurde das Verbindungsmanagement beschrieben, um abschließend Algorithmen fur die Op-timierung derUbertragunsleistung vorzustellen.

Literatur

[1] Postel, J.,User Datagram Protocol, RFC 768, 1980.

[2] Postel, J.,Transmission Control Protocol, RFC 793, 1981.

[3] Plummer, D. C.,An Ethernet Address Resolution Protocol, RFC 826, 1982.

[4] Nagle J.,Congestion Control in IP/TCP Internetworks, RFC 896, 1984.

[5] Srinivasan, R.,RPC: Remote Procedure Call Protocol Specification Version 2, RFC 1831, 1995.

[6] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,RTP: A Transport Protocol for Real-Time Applications, RFC 1889, 1996.

[7] Stevens, W. R.,TCP/IP Illustrated, Volume I, Adison-Wesley, Massachusetts, 1997, ISBN 0-201-63346-9 (v.1).

[8] Tanenbaum, A. S.,Computer Networks, Prentice Hall PTR, Amsterdam, 1996, ISBN 0-13-349945-6.

[9] Kurose, J. F., Ross, K. W.,Computer Networking: A topdown approach featuring the Internet,Adison-Wesley, Massachusetts, 2001, ISBN 0-201-47711-4.

[10] Caceres, R., Danzig, P. B., Jamin, S. und Mitzel, D. J.,Characteristics of Wide-Area TCP/IPConversations, Computer Communication Review, vol. 21(4), pp. 101-112, September 1991.

24