Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol TCP / UDP.

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol TCP / UDP Proseminar: Kommunikationsprotokolle SS 2003 Stefan Hoferer Matrikelnummer: Betreuung: Ralf Wienzek Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhaltsverzeichnis 1 Einleitung 3 2 Grundlagen von TCP/IP Der Protokollstapel Ports und Sockets UDP Einführung Header Fragmentierung durch IP Effekte zwischen UDP und ARP Anwendungen TCP Einführung Header Header Optionen Verbindungsmanagement Verbindungsaufbau Verbindungsabbau Zustandsübergangsdiagramm Datenübertragung Verbindungssicherheit Interaktiver Datentransfer Bulk-Datentransfer Zusammenfassung 24 2

3 1 Einleitung Beide der hier behandelten Protokolle gehören zum TCP/IP-Protokollstapel, über den seit 1983 ein Großteil der Kommunikationsaufgaben im Internet abgewickelt wird. Aber auch schon vor TCP/IP gab es das Bedürfnis Daten zwischen Computern auszutauschen. Bereits 1969 rief die Defence Advanced 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 weitestgehend unabhängig von dem verwendeten Übertragungsmedium oder den daran angeschlossenen Rechnersystemen war. Außerdem sollte es eine einheitliche Schnittstelle zu diesen Protokollen geben, um die Entwicklung von Software deutlich zu vereinfachen. Nachdem das ARPANET in Betrieb genommen wurde und sich stark verbreitete, begann die Entwicklung der TCP/IP-Protokolle, die seit 1983 die Grundlage unseres heutigen Internets bilden. Wegen seiner großen Bedeutung ist TCP/IP heute für alle gängigen Rechnersysteme verfügbar. Bei den meisten ist es sogar direkt in das Betriebssystem integriert. Zwei der Protokolle des o.g. Protokollstapels sollen hier behandelt werden. Das verbindungsorientierte Transmission Control Protocol (TCP) [2], das aufgrund seiner großen Bedeutung mit zur Namensgebung von TCP/IP beitrug, sowie das verbindungslose User Datagram Protocol [1]. Im Folgenden werden zunächst einige Grundlagen, die den TCP/IP-Protokollstapel betreffen, erläutert. Wobei schon hier erwähnt sei, dass es sich dabei nur um einen groben Überblick handelt. Für detailliertere Informationen sei auf die Seminararbeiten zum Thema Was ist das Internet? Struktur, Aufbau und Technik, Routing im Internet, Was ist Ethernet? sowie IPv4 und IPv6 verwiesen. Nach der Behandlung der Grundlagen werden die beiden Protokolle UDP und TCP ausführlich behandelt. 2 Grundlagen von TCP/IP 2.1 Der Protokollstapel Kommunikationsprotokolle werden, um ihre Komplexität zu verringern, schichtweise implementiert. Auch wenn Anzahl und Aufgabenverteilung der Schichten von Netz zu Netz variiert, ist das grundsätzliche Prinzip, stets das gleiche. Eine Schicht bietet der jeweils über ihr liegenden Schicht bestimmte Dienste an, ohne jedoch Kenntnisse über die genaue Implementierung vorauszusetzen. In jeder Schicht können mehrere Dienste vorhanden sein, welche die Aufgaben der Schicht auf verschiedene Weise implementieren. Auf diese Weise kann die Implementierung einzelner Dienste geändert werden, ohne damit die restlichen zu beeinflussen. Wichtiger ist noch, dass man auf diese Weise neue Hardware (zum Beispiel für die Kommunikation über andere Netzwerkmedien) auf einfache Weise integrieren kann. Eine Anwendung auf Rechner A, die Daten an eine Anwendung auf Rechner B schicken möchte, kann dies nicht auf direktem Weg. Stattdessen gibt sie die Daten an einen Dienst der obersten Schicht weiter, welcher seine Steuerinformationen in Form von so genannten Headern hinzufügt und seinerseits Dienste der darunterliegenden Schicht nutzt, um die Daten weiterzugeben. Erst auf der untersten 3

4 ISO / OSI Verarbeitungsschicht Darstellungsschicht Sitzungsschicht Transportschicht Vermittlungsschicht Sicherungsschicht Bitübertragungsschicht TCP / IP Verarbeitungsschicht Transportschicht Internetschicht Host-an-Netz Schicht Im Modell nicht 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 Protokollstapel von unten nach oben. Dabei werden die Steuerinformationen in den Headern u.a. dazu genutzt, um das Protokoll und letztlich die Anwendung zu bestimmen, an welche die Daten weitergegeben werden sollen. Die zwei wichtigsten Modelle für die Aufgabenverteilung der Schichten sind das ISO/OSI-Referenzmodell 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 völlig ausreichend ist. Da in dieser Arbeit Protokolle aus dem TCP/IP-Protokollstapel vorgestellt werden, sollen im Folgenden lediglich die Aufgaben dieser vier Schichten beschrieben werden. Host-an-Netz-Schicht Diese Schicht übernimmt die Aufgaben der Sicherung und der Bitübertragung. Die Protokolle dieser Schicht sind von Netz zu Netz sehr unterschiedlich und von TCP/IP nicht weiter festgelegt. Die einzige Anforderung, die an sie gestellt wird, ist, dass IP-Pakete verschickt werden können. Internet-Schicht In dieser Schicht ist das wohl wichtigste Protokoll angesiedelt, das Internet Protocol (IP). Es soll sicherstellen, dass IP-Pakete richtig zugestellt werden können. IP übernimmt dabei Aufgaben wie die Adressierung der Daten und das so genannte Routing zwischen verschieden Netzwerken. Das Internet Protocol ist verbindungslos und übernimmt keine Garantie, dass die versendeten Daten an ihrem Ziel ankommen. Die Erkennung verloren gegangener Pakete und eine geeignete Reaktion darauf wird höheren Schichten überlassen. 4

5 Transportschicht Hier sind die beiden Ende-zu-Ende Protokolle TCP und UDP definiert. UDP ist genau wie IP ein verbindungsloses und unzuverlässiges Protokoll, während TCP ein zuverlässiges verbindungsorientiertes Protokoll darstellt. Anwendungen, die Daten verschicken möchten, haben die Wahl, welches der Protokolle sie verwenden möchten. Beide haben ihre Vor- und Nachteile, auf die in den entsprechenden Abschnitten näher eingegangen wird. Verarbeitungsschicht In dieser Schicht sind höhere Protokolle angesiedelt. Zu diesen gehören zum Beispiel TELNET, FTP, SMTP oder DNS, die zur Datenübertragung 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, werden IP-Adressen verwendet. Sind die Daten an ihrem Zielrechner angekommen muss es auch eine Möglichkeit geben, sie einem bestimmten Programm bzw. Prozess zuzuordnen. Diese Zuordnung erfolgt sowohl bei TCP als auch bei UDP über so genannte Ports. Ports sind 16 Bit groß, haben also einen Wertebereich von 0 bis Ports im Bereich von 0 bis 1023 werden als well-known Ports bezeichnet. Hinter diesen Nummern verbergen sich standardmäßig bestimmte Programme oder Prozesse, so dass zum Beispiel ein Benutzer, der sich mittels SSH zu einem entfernten Rechner verbinden möchte, weiß, dass er dies über Port 22 machen kann. Um entscheiden zu können, an welchen Prozess die Daten ausgeliefert werden sollen, kann jede Portnummer nur genau einmal zugewiesen werden. Allerdings kann ein Port für UDP und TCP gleichzeitig vergeben werden. Denn im empfangenden Rechner kann anhand der im IP-Header untergebrachten Steuerinformationen entschieden werden, an welchen 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 Einführung Wie breits erwähnt lässt sich das User Datagram Protocol [1] als verbindungslos und unzuverlässig charakterisieren. Das bedeutet, dass Daten ohne vorherige Ankündigung oder Überprüfung auf Erreichbarkeit des Hosts abgeschickt werden und dass bei Übertragungsfehlern die betroffenen Datensätze nicht erneut übertragen werden. In beiden Punkten unterscheidet sich UDP von TCP. Ein weiterer Unterschied besteht in der Art, wie die Daten verschickt werden. Die UDP-Schicht verschickt die Daten als Datagramme in der von der Anwendung bestimmten Größe, während die TCP- Schicht die Größe der Datensätze selbstständig bestimmt. Da das zugrunde liegende Netzwerk aber 5

6 16-Bit Source Port Number 16-Bit UDP Length 16-Bit Destination Port Number 16-Bit UDP Checksum 8 Byte Daten (Sofern vorhanden) Abbildung 2: UDP-Header nur eine begrenzte Kapazität hat, kann es die Daten möglicherweise nicht zusammenhängend transportieren. Sie müssen also unterteilt (fragmentiert) werden. Diese Fragmentierung wird durch die IP-Schicht vorgenommen und führt zu einem größeren Datenaufkommen, da für jedes Segment ein neuer Header generiert werden muss, damit alle Fragmente ihr Ziel finden. Durch diese Fragmentierung vergrößert sich aber auch die Übertragungsunsicherheit, denn die Gegenseite kann mit einzelnen Fragmenten nichts anfangen. Erst wenn alle Fragmente durch die IP-Schicht wieder in der richtigen Reihenfolge zusammengesetzt wurden, kann der Prozess die Daten auswerten. Aufgrund eines begrenzten Empfangspuffers können Fragmente nicht unbegrenzt zwischengespeichert werden. Nach einem festgelegten Zeitraum werden diese Daten verworfen. Auf die Fragmentierung durch IP wird in Abschnitt 3.3 eingegangen. Trotz dieser Schwierigkeiten hat UDP seine Daseinsberechtigung. Anwendungen die UDP verwenden werden 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 den Header angehängte Datenblock hat keine festgelegte Größe. Source Port (Bit 0-15) Für den Fall, dass die Gegenseite antworten möchte, kann sie Pakete an den hier angegebenen Port senden. Der sendende Rechner muss aber nicht zwangsläufig auf dem hier angegebenen Port empfangsbereit sein. Destination Port (Bit 16-31) Dieses Feld enthält den Port, auf dem ein Prozess auf dem Zielrechner auf UDP-Datagramme wartet. In vielen Fällen handelt es sich hier um die schon angesprochenen well-known Ports. UDP Length (Bit 32-47) Hier wird die Länge des gesamten Datagramms, also sowohl die der Nutzdaten als auch des Headers, in Byte angegeben. Da das Lenght-Feld im IP-Header ebenfalls 2 Bytes groß ist, kann 6

7 32-Bit Source IP Address 32-Bit Destination IP Address Zero 8-Bit Protocol (17) 16-Bit UDP Length UDP Pseudo Header 16-Bit Source Port Number 16-Bit UDP Length 16-Bit Destination Port Number 16-Bit UDP Checksum UDP Header Daten (Sofern vorhanden) Pad Byte (0) Abbildung 3: Pseudo Header zur Checksum-Berechnung die maximale Datenmenge eines UDP-Pakets nicht größer als Byte (16 Bit unsigned) - 20 Byte des IP-Headers - 8 Byte des UDP-Headers = Byte sein. Checksum (Bit 48-63) Die Prüfsumme (Checksum) erlaubt es, Fehler in der Datenübertragung aufzudecken. Ein solcher Fehler führt dazu, dass ein Datagramm ohne Fehlermeldung gelöscht wird. Die Berechnung der Prüfsumme deckt das komplette UDP-Datagramm, also sowohl den Header als auch die Daten, ab. Zusätzlich wird ein Pseudo-Header, der einige Felder des IP-Headers enthält, zur Berechnung hinzugezogen (s. Abb. 3). Bei der Berechnung werden 16-Bit-Wörter im Einer- Komplement addiert und das Einer-Komplement dieser Summe im Checksum-Feld eingetragen. Eine ungerade Bytezahl im Datenteil wird durch ein Pad-Byte mit Wert 0 ausgeglichen, das aber nicht mit übertragen wird. Im Gegensatz zu TCP ist bei UDP die Berechnung der Prüfsumme zwar nicht vorgeschrieben, wird aber immer empfohlen. Wenn keine Berechnung erfolgt, wird die Prüfsumme 0 gespeichert. Ergibt eine Berechnung den Wert 0, wird dieser, wie im Einer-Komplement üblich, durch 16 1-Bits repräsentiert. 3.3 Fragmentierung durch IP Eine Anwendung, die ihre Daten über UDP verschickt, legt die Größe der Datagramme fest, das bedeutet, dass jeder Schreibvorgang einer Anwendung zu einem eigenen Datagramm führt. Da die Größe der auf einmal übertragbaren Daten eines Netzwerkes durch die Maximum Transfer Unit 7

8 (MTU) nach oben begrenzt ist, sollten Anwendungen darauf bedacht sein, die Datagramme nicht zu groß werden zu lassen. Anderenfalls müssen diese fragmentiert werden, was für jedes Fragment einen 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 Umständen viele unterschiedliche Netze mit verschieden großen MTUs durchlaufen, bevor es den Zielhost erreicht. Ist die MTU eines dieser Netze kleiner als die Größe des Datensatzes, muss dieser Datensatz durch den entsprechenden Router fragmentiert werden, bevor er weitergeschickt werden kann. Unter Umständen muss in folgenden Netzen der schon fragmentierte Datensatz erneut fragmentiert werden. Wird beim Versand eines Datensatzes das IP-Header-Flag Don t Fragment gesetzt, um eine Fragmentierung zu verhindern, werden alle Pakete die größer als die Path-MTU sind verworfen. Als Path-MTU wird die kleinste MTU auf dem Pfad zwischen zwei Rechnern bezeichnet. 3.4 Effekte zwischen UDP und ARP Das Address Resolution Protocol (ARP) [3] wird verwendet, um zu einer IP-Adresse die zugehörige Hardwareadresse zu bestimmen. Wenn der ARP-Cache leer und das zu sendende UDP-Datagramm groß ist, kann ein interessanter Effekt zwischen diesen beiden Protokollen beobachtet werden. Das große UDP-Datagramm impliziert, dass es schon für den Versand durch das erste Netz fragmentiert werden muss. Die IP-Schicht generiert die Fragmente viel schneller, als eine Antwort auf die ARP- Anfrage für das erste Paket eintrifft. Also werden für alle weiteren Fragmente ebenfalls wegen des noch leeren Caches ARP-Anfragen generiert, was zum so genannten ARP-Flooding führt. Typische ARP-Implementierungen verwenden einen Puffer, in welchem Pakete zwischengespeichert werden, für die ein ARP-Request verschickt werden muss. Pakete in diesem Puffer werden überschrieben, 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 Puffer überschrieben wurde, und sich nur noch das letzte Paket darin befindet. Über diesen Fehler wird der Sender nicht informiert. Auch der Empfänger kann keine Fehlermeldung generieren, da der UDP- Header, der sich im ersten Paket befand, nie angekommen ist. Es kann also nicht mehr zugeordnet werden, von welchem Prozess dieses Paket stammte. Nach einem Timeout muss der Empfänger dieses einzelne Paket verwerfen. 3.5 Anwendungen Gerade wegen seiner Einfachheit gibt es einige Anwendungen, die UDP als Transportprotokoll bevorzugen. Vor allem bei geringen Datenmengen bedeutet der kleine Header einen im Vergleich zu den Nutzdaten 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 Anfrage und Antwort abläuft. Der Host, der die Anfrage verschickt, wird im Allgemeinen als Client, der Empfänger der Anfrage als Server bezeichnet. Gehen Daten bei der Übertragung in eine der beiden 8

9 Richtungen verloren, startet die Anwendung, nachdem sie bei Ablauf eines Timers keine Antwort erhalten hat, eine erneute Anfrage. Als Beispiel für eine solche Anwendung ist Remote-Procedure-Call (RPC) [5] zu erwähnen. RPC ermöglicht es, Funktionen auf entfernten Rechnern aufzurufen, wobei der Funktionsaufruf sich bis auf wenige Einschränkungen nicht von normalen lokalen Funktionsaufrufen unterscheidet. Diese Vorgehensweise erleichtert deutlich die Programmierung von Netzwerkanwendungen. Ein weiteres wichtiges Anwendungsgebiet sind alle Arten von multimedialen Datenübertragungen wie digitales Fernsehen, Internet Radio oder Videokonferenzen, also Anwendungen bei denen es wichtig ist, dass sie in Echtzeit empfangen werden. Hier ist es von Vorteil, das UDP über keine Art von Empfangsbestätigung oder erneutem Datagrammversand verfügt. Übertragungsfehler führen dann zu kurzen Übertragungslücken, die weiteren Daten kommen aber nach wie vor in Echtzeit an. Bei TCP als Transportprotokoll käme es aufgrund der erneuten Segmentübertragung zu Verzögerungen der folgenden Daten. So könnte also keine Echtzeit gewährleistet werden. Für diesen Anwendungsbereich wurde 1989 das heute weit verbreitete Real-Time Transport Protocol (RTP) [6] entwickelt. Es ist der Anwendungsschicht zugeordnet, obwohl es von der Arbeitsweise eigentlich der Transportschicht zugeordnet werden müsste. Dieses Protokoll ermöglicht durch einen weiteren Header einige Funktionen, die für multimediale Anwendungen nützlich sind. Beispielsweise werden die Datagramme nummeriert, um im Falle eines Datenverlustes entsprechend reagieren zu können. Fehlen nur wenige Daten kann so versucht werden, diese zu interpolieren. Eine weitere Funktion von RTP ist der Timestamp. Er ermöglicht eine relative Zeitangabe der Daten zum ersten übertragenen Datagramm. So können Daten zwischengespeichert werden, um dann zum richtigen Zeitpunkt ausgewertet zu werden. 4 TCP 4.1 Einführung Wie bereits erwähnt, handelt es sich bei TCP [2] um ein zuverlässiges, verbindungsorientiertes Protokoll, das Daten als Bytestrom versendet. Verbindungsorientiert bedeutet, dass bevor Daten ausgetauscht werden können, eine Verbindung zwischen den beiden Rechnern hergestellt werden muss. Bei diesem Verbindungsaufbau werden wichtige Daten ausgetauscht, um die Verbindung zu initialisieren. Diese TCP-Verbindungen arbeiten im Fullduplex-Betrieb, das heißt beide Seiten können unabhängig voneinander Daten verschicken. TCP und UDP unterscheiden sich in der Art der Datenübertragung. Aus diesem Grund werden die Datensätze auch mit unterschiedlichen Namen versehen. Während man bei UDP von einem Datagramm spricht, ist bei TCP von einem Segment die Rede. Im Gegensatz zu UDP, wo die Anwendung die Paketgröße und Anzahl festlegt, hat eine Anwendung, die Daten über TCP verschickt, keinen Einfluss auf die Größe der Segmente. Dabei ist es durchaus denkbar, dass beispielsweise 5 Segmente à 20 Byte versendet werden und diese auf der Gegenseite als 100 Byte oder 10 mal 10 Byte von der Anwendung gelesen werden. Außerdem überwacht die TCP-Schicht, wiederum im Gegensatz zu UDP, anhand der Sequenznummer die Reihenfolge, in der die Daten beim Empfänger eintreffen. 9

10 16-Bit Source Port Number 16-Bit Destination Port Number 32-Bit Sequence Number 32-Bit Acknowledgment Number 20 Byte 4-Bit Header 6-Bit Reserverd U R G A C K P S H R ST S Y N F I N 16-Bit Window Size 16-Bit TCP Checksum 16-Bit Urgent Pointer Options (Sofern vorhanden) Daten (Sofern vorhanden) Abbildung 4: TCP-Header Um Zuverlässigkeit gewährleisten zu können, gibt es verschiedene Ansatzpunkte. Jedem versendeten Byte wird eine Sequenznummer (Sequence Number) zugeordnet, wobei in dem entsprechenden Header-Feld jeweils die Sequenznummer des ersten Bytes eines Segmentes gespeichert wird. Nach dem erfolgreichen Empfang eines Segmentes auf der Gegenseite versendet diese eine Empfangsbestätigung. Bleibt eine Bestätigung aus, werden die Bytes ab dem letzten bestätigten Byte erneut übertragen. Außerdem verfügt TCP wie auch UDP über ein Header-Feld Checksum. Diese Prüfsumme wird nach dem gleichen Prinzip berechnet, muss aber im Gegensatz zu UDP immer berechnet und überprüft werden. Bei fehlerhafter Prüfsumme wird das Segment gelöscht, da in dem Fall einer ausbleibenden Bestätigung der Sender die Daten erneut überträgt. Als erstes folgt nun eine Beschreibung aller Felder des TCP-Headers. Im Anschluss wird ausführlich auf die Punkte Verbindungsaufbau, Verbindungsabbau und Datentransfer eingegangen. 4.2 Header Da TCP, wie auch UDP, das unzuverlässige, verbindungslose Internet Protocol zum Versenden der Daten verwendet, werden einige zusätzliche Informationen benötigt, um den gewünschten Dienst anbieten zu können. Hierzu wird ein Header mit einer Mindestgröße von 20 Byte, also 12 Byte mehr als bei UDP, verwendet (s. Abb. 4). Der Datenteil ist bei TCP optional. Das heißt, es können auch Segmente verschickt werden, die nur aus einem Header bestehen. Die Bedeutung der einzelnen Felder wird im Folgenden beschrieben. 10

11 Source Port (Bit 0-15), Destination Port (Bit 16-31) Eine Verbindung wird eindeutig über das 4-Tupel (Source-IP, Source-Port, Destination-IP, Destination-Port) identifiziert. Da die IP-Adresse der beiden Hosts im IP-Header festgelegt wird, müssen im TCP-Header nur die Ports gespeichert werden. Über diese Ports kann entschieden werden, an welche Anwendung auf dem jeweiligen Host die Daten weitergegeben werden sollen. Sequence Number (Bit 32-63) Jedem Byte wird eine Sequenznummer zugeordnet, wobei die Nummer des ersten versendeten Bytes jeder Seite während des Verbindungsaufbaus festgelegt wird. Diese Nummer wird vorzeichenlos gespeichert, daher können Nummern von 0 bis vergeben werden, bevor es zu einem Überlauf kommt. Acknowledgment (Bit 64-95) Die Bestätigungsnummer (Acknowledgment) gibt die Sequenznummer an, die als nächste erwartet wird. Sie ist nur gültig, wenn das ACK-Flag gesetzt ist. Implizit wird der Empfang aller Bytes mit kleinerer Sequenznummer bestätigt. Header Length (Bit 96-99) Die Länge des TCP-Headers kann aufgrund des Option-Feldes zwischen 20 Byte (keine Optionen) und 60 Byte variieren. Da mit den zur Verfügung stehenden 4 Byte nur 16 Werte dargestellt werden können, wird hier die Header-Länge in 32-Bit Worten angegeben. Reserved (Bit ) Dieser Bereich wird bis heute nicht genutzt. Die Tatsache, dass dieses Feld über ein Jahrzehnt überlebt hat, wird als Beleg dafür angesehen, wie gut TCP ausgelegt wurde. 6 Flags (Bit ) URG Urgent Dringende Daten wurden versendet. Der Urgent Pointer wurde gesetzt. ACK Acknowledgment Durch das Ack-Bit wird angezeigt, dass die Bestätigungsnummer gesetzt ist, um den Empfang von Daten zu mitzuteilen. PSH Push Wenn dieses Bit gesetzt ist, werden Daten so schnell wie möglich an die Anwendung weitergegeben. RST Reset Setzt eine Verbindung zurück. SYN Synchronize Dieses Flag wird gesetzt, wenn eine neue Verbindung aufgebaut wird. (s.u.) FIN Finished FIN dient zum Beenden einer Verbindung. 11

12 Window Size (Bit ) Der TCP-Empfangs-Puffer hat nur eine begrenzte Größe. Aus diesem Grund wird in diesem Feld angegeben, wie viele Byte noch empfangen werden können. Dadurch wird erreicht, dass kein schneller Sender einen langsamen Empfänger mit Daten überfluten kann. Checksum (Bit ) Die Berechnung die gleiche wie bei UDP. Der einzige Unterschied ist, dass die Berechnung und Auswertung hier obligatorisch ist und nicht wie bei UDP lediglich empfohlen wird. Urgent Pointer (Bit ) Bei gesetztem URG-Bit wird durch diesen Pointer das letzte Byte dringender Daten gekennzeichnet. Diese Daten werden dann umgehend, ohne Beachtung der Reihenfolge des Datenstroms, an den Prozess weitergeleitet. Options (zwischen 0 und 40 Byte) Dieses Feld ermöglicht die Verwendung von Funktionen, die im normalen Header nicht verfügbar sind. Im nächsten Abschnitt werden dazu einige Beispiele angegeben Header Optionen Soll dieses Feld für eine zusätzliche Option verwendet werden, muss zuerst der Typ, dann die Länge der Option und zum Schluss die eigentliche Option angegeben werden. Ist die Option lediglich ein Flag braucht nur der Typ angegeben werden. Die Gesamtlänge der Optionen muss ein Vielfaches von 4 Byte betragen, da die Header-Länge 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 Auffüllen des Headers auf ein Vielfaches von 4 Byte. Maximum Segment Size (Typ 2) Diese Option wird häufig beim Verbindungsaufbau verwendet und in diesem Zusammenhang noch genauer erläutert. Die Länge der Option ist auf 4 Byte festgelegt. 4.3 Verbindungsmanagement Verbindungsaufbau Vor jedem Datentransfer muss zuerst eine Verbindung hergestellt werden. In den meisten Fällen werden 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 vom Client ausgeht. Es gibt aber auch Fälle, in denen beide Parteien nahezu gleichzeitig eine Verbindung aufbauen wollen. Beide Varianten werden im Folgenden beschrieben. 12

13 Mit dem Aufbau einer Verbindung werden zwei Dinge beabsichtigt: Zum einen kann so überprüft werden, ob der Rechner, mit dem Daten ausgetauscht werden sollen, überhaupt empfangsbereit ist, zum anderen werden so wichtige, für die Verbindung benötigte Daten ausgetauscht. Eine erste wichtige Information, die dabei ausgetauscht wird, ist die Initial Sequence Number (ISN). ISN + 1 ist die Nummer des ersten zu versendenden Byte, da das SYN-Flag seinerseits eine Sequenznummer verbraucht. Bei jedem Verbindungsaufbau sollte die ISN variieren. Hierdurch soll verhindert werden, dass Segmente, die verspätet ankommen, nicht versehentlich der aktuellen Verbindung zugeordnet werden können. RFC 793 [2] schreibt dabei vor, die ISN als 32 Bit-Zähler alle 4 Mikrosekunden zu erhöhen. Tatsächlich wird die ISN in verschiedenen Implementierungen auf unterschiedliche Weise generiert (4.4BSD erhöht den Wert des Zählers beispielsweise alle 8 Mikrosekunden). Nach einem Verbindungsaufbau ist beiden Seiten der Socket ihres Kommunikationspartners bekannt. Über dieses 4-Tupel (RechnerA IP-Adresse, RechnerA Port, RechnerB IP-Adresse, RechnerB Port) ist eine TCP-Verbindung eindeutig identifiziert. Mehrere Verbindungen zwischen zwei Rechnern sind problemlos möglich, wenn für neue Verbindungen auf mindestens einem Rechner ein anderer Port verwendet wird. Oft wird beim Verbindungsaufbau auch die Maximum Segment Size (MSS) ausgetauscht. Die MSS ist ein Beispiel für eine Funktion, die vom Standard-Header nicht zur Verfügung gestellt wird und aus diesem Grund über das Feld Options realisiert wird. Sie ist 4 Byte groß und gibt die Segmentgröße, die maximal empfangen werden kann, in 2 Byte an. Geben beide Rechner eine MSS an, ist die niedrigere Zahl ausschlaggebend. Wird dagegen keine MSS angegeben, werden maximal 536 Byte an 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 wird über den so genannten 3-Way-Handshake aufgebaut. Wie der Name vermuten lässt, werden hier 3 Segmente ausgetauscht, um die Verbindung zu initialisieren. Abbildung 5 zeigt einen solchen typischen Verlauf. Vorraussetzung ist hierbei immer, dass auf einem Rechner (meist als Server bezeichnet) ein Prozess (z.b. SSH, FTP, etc.) gestartet ist, der auf einem festgelegten Port auf Verbindungen von anderen Rechnern wartet. Der Zustand von diesem Server wird mit LISTEN bezeichnet. Angaben des Zustandes wie hier LISTEN beziehen sich auf Abbildung 7, in der eine Übersicht über alle möglichen Zustände gegeben ist. 1. Das erste Segment geht vom Client aus, der einen Dienst des Servers nutzen möchte. Dieses Segment wird mit gesetztem SYN-Flag versendet, als Zeichen, dass eine neue Verbindung aufgebaut werden soll. Es enthält 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 Weiteren wird die ISN (hier ) übertragen. Da noch keine Daten empfangen wurden, ist die Window-Size noch gleich dem Startwert (hier 4096). Auch die Möglichkeit der Mitteilung der MSS (1024) wird hier genutzt. Der Client ändert nach dem Versand seinen Zustand von CLOSED in SYN SENT. 13

14 Client Server Segment 1 SYN : (0) <mss 1024> SYN : (0) ack , <mss 1024> Segment 2 Segment 3 ack Abbildung 5: TCP 3-Way-Handshake 2. Hat der Server dieses Segment empfangen, versendet er ein Segment, ebenfalls mit gesetztem SYN-Flag, in dem er seine ISN ( ) bekannt gibt. Außerdem muss er die ISN des Clients bestätigen, indem er bei gesetztem ACK-Flag ISN+1 als Bestätigungsnummer zurückschickt. Auch der Server teilt dem Client eine MSS von 1024 mit. Die Mitteilung der eigenen ISN und die Bestätigung der ISN des Clients geschieht in einem Segment. Danach wechselt der Server in den Zustand SYN RCVD. Obiges gilt jedoch nur für den Fall, dass der Server im Status LISTEN auf eine Verbindung gewartet hat. War dies nicht der Fall, kann keine Verbindung aufgebaut werden. Der Server sendet ein 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 Servers bestätigen, 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 empfängt, wechselt auch er in den Zustand ESTABLISHED. Damit ist die Verbindung erfolgreich aufgebaut und es können Daten übertragen werden. Der Client hat die Möglichkeit, zusammen mit dem ACK bereits die ersten Daten zu übertragen. Der Sender des ersten Segments mit SYN-Flag (hier der Client) vollzieht einen aktiven Verbindungsaufbau (Active Open), der Server, der das zweite Segment schickt einen passiven (Passive Open). Simultaner Verbindungsaufbau In seltenen Fällen, kann es auch vorkommen, dass zwei Hosts nahezu gleichzeitig versuchen, eine Verbindung aufzubauen. Dazu müssten aber beide Hosts den Port des jeweils anderen kennen. Bei einem simultanen Verbindungsaufbau entfällt 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 bestätigt. Nach dem Empfang dieser 14

15 Client Server Segment 1 FIN : (0) ack ack FIN : (0) ack Segment 2 Segment 3 Segment 4 ack Abbildung 6: TCP Verbindungsabbau Bestätigung ist die Verbindung aufgebaut. Für den Verbindungsaufbau werden in diesem Fall also 4 Segmente benötigt Verbindungsabbau Verbindungsabbau per Half Close Während für den Verbindungsaufbau im Normalfall drei Segmente benötigt werden, sind es beim Verbindungsabbau vier. TCP-Verbindungen arbeiten im Fullduplex-Betrieb, das heißt, in beide Richtungen können unabhängig voneinander Daten verschickt werden. Beim Beenden einer Verbindung müssen beide Richtungen separat getrennt werden. So kann durch den Half Close eine Seite ihre Verbindung beenden, aber noch beliebig lange Daten von der Gegenseite empfangen. Es gibt in der Praxis aber nur wenige Anwendungen, die diese Möglichkeit nutzen, eine davon, rsh, wird im Abschnitt Anwendung des Half-Close beschrieben. Wie auch beim Verbindungsaufbau wird zwischen aktivem 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 Fällen der Client, vollzieht den so genannten Active Close, indem er ein Segment mit gesetztem FIN-Flag versendet. Das kann auch das Segment sein, mit dem die letzten Daten verschickt wurden. Nach dem Versand dieses Segmentes wechselt der Client vom Status ESTABLISHED in den Status FIN WAIT Empfängt der Server ein Segment mit gesetztem FIN-Flag bestätigt er dessen Empfang, benachrichtigt die Anwendung, dass die Gegenseite die Verbindung beenden möcht und wechselt in den Zustand CLOSE WAIT. 15

16 Nach dem Empfang des ACK wechselt der Client vom Zustand FIN WAIT 1 in den Zustand FIN WAIT 2, um hier auf ein FIN des Servers zu warten. 3. Die Server-Anwendung kann, aufgrund des einseitigen Verbindungsabbaus, jetzt weiterhin Daten verschicken und sobald sie ebenfalls die Verbindung trennen möchte sendet sie ihrerseits ein FIN. Danach wechselt sie in den Zustand LAST ACK. 4. Der letzte Schritt ist die Bestätigung des FIN und der Wechsel in den Zustand TIME WAIT. Hier verbleibt der Client für die Zweifache Maximum Segment Lifetime (MSL) bevor er dann den Status CLOSED annimmt. Der Server wechselt direkt nach dem Empfang des ACK in den Zustand CLOSED. Anwendung des Half Close Eine Anwendung, die die Möglichkeit des Half Close nutzt, ist Remote Shell (rsh), welche Kommandos auf anderen Rechner ausführt. Dabei wird die Standard-Eingabe per TCP zu dem entfernten Rechner kopiert und dessen Ausgabe auf dem Terminal des Client-Rechners ausgegeben. Nach dem Kopieren 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 auszuführen. Da die Verbindung nur in einer Richtung geschlossen ist, kann der Rechner die Ausgabe des Kommandos ohne Probleme zurückschicken. Danach beendet auch er die Verbindung. Simultaner Verbindungsabbau In Analogie zum Verbindungsaufbau ist es beim Abbau möglich, wenn auch eher zufällig, dass beide Hosts nahezu gleichzeitig die Verbindung beenden möchten. Dabei wechseln beide nach dem Senden des FIN-Segments in den Zustand FIN WAIT 1 und von dort aus nach Empfang und Bestätigung des FIN in den Zustand CLOSING. Nachdem die Rechner die Bestätigung empfangen haben, wechseln sie in den Zustand TIME WAIT. Bei einem simultanen Verbindungsabbau müssen also beide Seiten zuerst die zweifache MSL abwarten, bevor sie den Zustand CLOSED annehmen. Verbindungs-Reset In einigen Fällen wird eine Möglichkeit gebraucht, um eine Verbindung abzubrechen. TCP ermöglicht dies durch das Setzen des RST-Flags im TCP-Header. Ein Reset wird oft versendet, wenn dem Port in der Verbindungsanfrage kein Prozess zugeordnet ist, beziehungsweise ein zugeordneter Prozess nicht im Zustand LISTEN auf eine Verbindung wartet. Empfängt ein Host, nachdem er das erste SYN versendet hat, ein Segment mit gesetztem RST-Flag, kann der User darüber informieren werden, dass keine Verbindung möglich ist. Es ist beiden Hosts möglich, eine Verbindung zurückzusetzen anstatt sie auf die oben beschriebene Weise zu beenden. In diesem Fall werden alle Daten verworfen die noch zum Versand anstanden und die Verbindung unmittelbar getrennt. Man spricht dann von einem Abortive Release im Gegensatz zu dem oben beschriebenen Orderly Release. 16

17 Auch in dem Fall von halb-offenen (Half-Open) Verbindungen wird ein RST versendet. Eine Verbindung wird als halb-offen bezeichnet, wenn eine Seite die Verbindung ohne Kenntnis der anderen Seite beendet oder abgebrochen hat. Das ist zum Beispiel der Fall, wenn einer der beiden Rechner abstürzt oder er ohne vorheriges Runterfahren ausgeschaltet wird. Solange der andere Rechner keine Daten übertragen will, wird er nicht merken, dass der Kommunikationspartner nicht mehr empfangsbereit ist. Dieses Problem entsteht oft bei Client-Server-Verbindungen, wenn der User sich nicht die Mühe macht, die Programme, die TCP verwenden, ordnungsgemäß zu beenden. Da der Server in den meisten Fällen 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. Auf diese Weise können viele halb-offene Verbindungen entstehen. In dem Fall, dass der Server doch von sich aus Daten über eine solche Verbindung senden will, antwortet der Client, der nichts mehr mit den empfangenen Verbindungsdaten anfangen kann, mit einem RST-Segment Zustandsübergangsdiagramm Im Zustandsübergangsdiagramm sind alle Regeln für den Verbindungsauf- und -abbau zusammengefasst (s. Abb. 7). Die Zustandsübergänge, die ein Client normalerweise vollzieht, sind fett und die des Servers gestrichelt markiert. Oberhalb der Pfeile ist notiert, welches Ereignis einen Übergang auslöst und unterhalb wie darauf reagiert werden soll. TIME WAIT oder 2 MSL Wait State Der Zustand TIME WAIT wird auch als 2 MSL Wait State bezeichnet. Die Verbindung muss für die zweifache MSL in diesem Zustand verharren, in dem alle verspäteten Segmente verworfen werden. Dadurch wird sichergestellt, dass keine verspäteten Segmente als Teil einer neuen Verbindung fehlinterpretiert werden. Quiet Time Es kann vorkommen, dass ein Host, während er sich in der TIME WAIT-Phase befindet, abstürzt, innerhalb von 2 MSL Sekunden rebootet und eine neue Verbindung aufbaut. In diesem Fall können verspätete Segmente ebenfalls als Teil der neuen Verbindung interpretiert werden. Um diesen Fall auszuschließen, gibt es das Quiet Time Concept, das besagt, dass ein Rechner nach einem Neustart MSL Sekunden warten muss, bevor er eine neue Verbindung aufbauen darf. 4.4 Datenübertragung Sobald beide Hosts den Status ESTABLISHED erreicht haben, können Daten in beide Richtungen über das Netzwerk übertragen werden. Auch in den Zuständen FIN WAIT und CLOSE WAIT (nach einem Half-Close) ist eine Datenübertragung möglich, hier aber nur in eine Richtung. In diesem Abschnitt wird immer vom Zustand ESTABLISHED ausgegangen, sofern nichts anderes erwähnt wird. 17

18 Abbildung 7: TCP Zustandsübergangsdiagramm [7] 18

19 Bei genauer Betrachtung der TCP-Segmente lassen sich diese in zwei Bereiche unterteilen. In Segmente, die interaktive Daten enthalten (Interaktiver Datentransfer zum Beispiel bei Anwendungen wie RLogin, SSH, TELNET, etc.) und solche, die dem Dateitransfer dienen (Bulk Datentransfer bei Anwendungen wie FTP, SMTP, HTTP, etc.). Während Segmente beim interaktiven Datentransfer meist nur wenige Byte groß sind, sind Bulk-Daten-Segmente häufig größtmöglich. Eine 1991 von Caceres durchgeführte Studie [10] ergab, dass ca. 90% der Segmente weniger als 10 Byte an Nutzdaten enthalten. Die unterschiedlichen Anforderungen beider Anwendungsbereiche an die Transportschicht führten zu unterschiedlichen Algorithmen für den Umgang mit den Daten. Algorithmen, die beim interaktiven Datentransfer eingesezt werden, versuchen, die Segmentanzahl und damit den durch deren Header entstehenden Overhead zu reduzieren. Solche, die beim Bulk-Datentransfer zum Einsatz kommen, haben einen hohen Durchsatz zum Ziel. Im Folgenden werden zuerst einige Gesichtspunkte der zuverlässigen Datenübertragung und dann die Algorithmen für die beiden Bereiche beschrieben Verbindungssicherheit TCP gewährleistet die Verbindungssicherheit unter anderem dadurch, dass empfangene Segmente bestätigt werden müssen. Bestätigungen erfolgen kumulativ, das heißt, dass jeweils das letzte korrekt empfangene Byte bestätigt wird. Es gibt keine Möglichkeit den Verlust eines Segmentes explizit mitzuteilen. Um dennoch auf der Senderseite einen Segmentverlust feststellen zu können, bestätigt der Empfänger bei jedem außerhalb der erwarteten Reihenfolge empfangenen Segment das letzte korrekt empfangene Byte erneut. Auf eine solche duplizierte Bestätigung können Algorithmen wie Slow Start entsprechend reagieren. Sowohl die Daten, als auch deren Bestätigung können während des Transportes durch das Netz verloren gehen. Aus diesem Grund wird ein Retransmission Timer verwendet, um Daten erneut zu versenden, wenn innerhalb einer vorgeschriebenen Zeit keine Bestätigung eintrifft. Da sich der Durchsatz des Netzes ändern kann (durch unterschiedlich starke Belastung oder sich ändernden Routen durch das Netz) ist ein fest vorgegebener Retransmission-Timeout-Value (RTO) nicht praktikabel. Um diesen Wert an die Netzgeschwindigkeit anzupassen, wird die Round-Trip- Time (RTT) so oft wie möglich gemessen, um daraus den RTO zu berechnen (s. unten). Trifft für ein Segment keine Bestätigung innerhalb von RTO Sekunden ein, wird das Segment erneut übertragen und die RTO verdoppelt, da das Netz stark ausgelastet scheint. Das Segment wird so lange neu übertragen und die RTO verdoppelt (ab einem Wert von 64 Sekunden bleibt die RTO konstant), bis entweder eine Bestätigung für dieses Segment eintrifft, oder 9 Minuten verstrichen sind (Exponential Backoff ). Im ersten Fall wird die RTT und damit auch der RTO neu berechnet, da die Netzauslastung scheinbar abgenommen hat. Im zweiten Fall wird die Verbindung mittels RST vom Sender beendet. Berechnung von RTT und RTO Die RTT ist die Zeit, die von dem Versenden eines Segments bis zum Empfang von dessen Bestätigung verstreicht. Um diese Zeitspanne zu bestimmen, wird ein 500ms Timer verwendet. Mit einem 19

20 Zähler wird bestimmt, wie oft dieser Timer zwischen Versand eines Segmentes und dessen Bestätigung abläuft. Da der Timer relativ zum Systemstart und nicht zum Versand des Segmentes abläuft, erfolgt die erste Erhöhung des Zählers zwischen 1ms und 500ms nach dem Segmentversand. Die Messung ist daher nicht sehr genau und kann auch trotz gleicher Zeiten Schwanken. Aus diesem Grund wird der Wert durch die folgende Formel geglättet, wobei M die aktuelle Messung und R den berechneten Wert bezeichnet. R = α R + (1 α) M, mit 0 α 1 Ein empfohlener Wert für α ist 0.9, das heißt, eine neue Messung geht zu 10% in die Berechnung ein. Die meisten TCP-Implementierungen verwenden nur einen Zähler pro Verbindung, das schränkt die Messung der RTT in einigen Fällen ein. Werden beispielsweise zwei Segmente kurz nacheinander verschickt, kann nur für das erste die RTT berechnet werden, da der Zähler schon in Gebrauch ist, wenn das zweite Segment versendet werden soll. Ebenfalls problematisch ist die Messung von Segmenten, die erneut übertragen wurden. Ein ACK kann hier nicht eindeutig zugeordnet werden, da es verspätet von der ersten Übertragung eingetroffen sein kann oder erst von der zweiten. In diesen Fällen wird die Berechnung verworfen. Der RTO wird aus dem Wert R mittels eines Faktor β berechnet, für den RFC 793 einen Wert von 2 empfiehlt. RT O = β R Nachdem es zu einem Timeout gekommen ist, darf die RTO aufgrund des Exponential Backoff nicht neu berechnet werden. Erst nachdem wieder eine Bestätigung eingetroffen, ist werden weitere RTT- Messungen vorgenommen Interaktiver Datentransfer Beim interaktiven Datentransfer werden nur kleine Datenmengen transportiert. Bei Konsolenanwendungen wie RLogin führt jeder Tastendruck zu zwei Segmenten in denen jeweils 1 Byte an Daten transportiert werden (so genannten Tinygrams), sowie zwei Segmenten zur Bestätigung: Beim Druck des Anwenders auf eine Taste wird ein Segment generiert, was vom Server zunächst durch ein weiteres Segment bestätigt wird. Anschließend wird dem Anwender die Auswirkung des Tastendrucks in einem dritten Segment mitgeteilt (Häufig ist das die Darstellung des Zeichens in der Konsole), welches abschließend ebenfalls bestätigt wird. Für dieses eine Zeichen werden also 80 Byte an TCP- Headern und lediglich 2 Byte an Daten transportiert. Dies macht deutlich, wie wichtig Algorithmen sind, die versuchen die Anzahl der versendeten Pakete zu reduzieren. Zwei dieser Algorithmen werden im Folgenden beschrieben. Delayed Acknowledgments Delayed Acknowledgments sind dafür verantwortlich, dass ein oben beschriebenes Szenario im Normalfall nicht vorkommt. Es ist nicht notwendig, dass der Empfang eines Segmentes umgehend bestätigt wird. Stattdessen besteht die Möglichkeit, bis zu 200 ms darauf zu wartet, ob Daten zurückgeschickt 20

21 werden müssen. Ist das der Fall, kann das ACK zusammen mit den Daten übertragen und so ein Segment eingespart werden. Für das obige Beispiel bedeutet dies, dass die Segmente 2 und 3 zu einem zusammengefasst werden. Für die Zeitmessung wird ein Timer benutzt, der alle 200 ms relativ zum Rechnerstart abläuft. Das bedeutet, dass die Bestätigungen zwischen 1 und 200 ms hinausgezögert werden können. Treffen in diesem Zeitraum Daten zum Versand ein, werden diese bereits vor Ablauf des Timers zusammen mit dem ACK verschickt. Falls nach Ablauf des Timers keine Daten angefallen sind, wird das ACK in einem eigenen Segment gesendet. Nagle Algorithmus Nagles Algorithmus [4] versucht, die Netzwerkbelastung, die durch den Versand von vielen Tinygrams entsteht, zu vermeiden. Für den Fall, dass eine Empfangsbestätigung für vorrangehende Daten noch nicht eingetroffen ist, werden alle von der Anwendung an die TCP-Schicht weitergegebenen Daten zurückgehalten. Trifft die Empfangsbestätigung ein, kann so eine größere Datenmenge versendet werden. Nagles Algorithmus passt sich somit an die Geschwindigkeit und Auslastung des Netzes an. Kommen bei einem wenig belasteten Netz ausstehende Segment-Bestätigungen schnell an, werden wartende Daten ebenso schnell verschickt. Ist dagegen die Netzauslastung hoch, werden Daten gesammelt und in großen Segmenten mit großen Zeitabständen verschickt, um dadurch das Netzwerk zu entlasten. Während bei der Datenübertragung in schnellen Netzen die Auswirkung dieses Algorithmus bei Konsolenanwendungen kaum spürbar ist, äußert sich sein Einsatz in langsamen Netzen dadurch, dass Zeichen bei Konsolenanwendungen verzögert und in Schüben dargestellt werden. Es gibt auch Anwendungen, für die Nagles Algorithmus hinderlich ist. Das X Windows System ist eine solche. Hier müssen auch kleine Datenmengen, zum Beispiel die Bewegung des Mauszeigers, sofort versendet werden. Aus diesem Grund kann durch die TCP NODELAY-Socket-Option der Algorithmus deaktiviert werden Bulk-Datentransfer Beim Bulk-Datentransfer werden häufig viele Daten in eine Richtung versendet. Die eingesetzten Algorithmen müssen also dafür sorgen, dass die Kapazität des Netzwerkes ausgelastet wird, ohne es zu überlasten. Bei TCP werden solche Algorithmen der Fluss- und Überlastkontrolle zugeordnet. Flusskontrolle sorgt empfängerseitig dafür, dass der Sender den Empfänger nicht mit Daten überfluten kann, Überlastkontrolle kontrolliert den Datenfluss auf der Senderseite. Sliding Window Das Sliding-Window-Protokoll [8] gehört zur Flusskontrolle. Über das Window-Size-Header-Feld kann der Empfänger dem Sender mitteilen, wie viele Daten noch empfangen werden können, bevor der Empfangspuffer voll ist (Offered Window). Aus dieser Angabe und der Datenmenge, die er bereits 21

22 durch Window-Size angegebene Fenstergröße (offered window) bereits bestätigt gesendet, nicht bestätigt noch nutzbar (usable window) erst nach Fensterbewegung nutzbar Abbildung 8: TCP Sliding Window ohne Bestätigung verschickt hat, kann der Sender errechnen, wie viel Speicherplatz im Empfangspuffer noch verfügbar ist (Usable Window). Alle zusätzlich versendeten Segmente würden nur unnötig das Netzwerk belasten, da der Empfänger sie aufgrund eines vollen Empfangspuffers löschen müsste. Die Größe und Position des Fensters verschiebt sich im Laufe einer Datenübertragung (s. Abb. 8). Es beginnt immer nach der letzten bestätigten Sequenznummer und hat die durch Window Size angegebene Größe. Durch die Bestätigung eines Segmentes verschiebt sich also der linke Rand des Fensters nach rechts und verkleinert es auf diese Weise. Es kann wieder vergrößert werden, wenn die Anwendung Daten aus dem Puffer gelesen hat und bei dem nächsten Segment in Richtung Sender die aktualisierte Window Size angegeben wird. Ist die Anwendung nicht in der Lage, die Daten schnell genug aus dem Puffer zu lesen (zum Beispiel bei einem langsamen Rechner), wird durch ein Empfangsfenster von 0 Byte der Datentransfer vorübergehend gestoppt. Wenn die Anwendung einen Teil des Puffers geleert hat, wird durch die TCP-Schicht das letzte ACK mit einer aktualisierten Fenstergröße (ein so genanntes Window Update) gesendet. Wie jedes andere Segment auch, kann dieses ACK verloren gehen. Ohne weitere Beachtung würde dies zu einem Deadlock führen: Der Sender wartet auf ein Window Update, um weitere Daten schicken zu können, und der Empfänger wartet auf neue Daten. Um dies zu verhindern, wurde der Persist Timer eingeführt. Dieser erlaubt es dem Sender in festgelegten Abständen (5, 6, 12, 24, 48, 60 Sekunden) eine Window Probe bestehend aus dem nächsten Byte an den Empfänger zu schicken, um zu überprüfen, ob sich die Window Size geändert hat. Ist dies nicht der Fall wird das vorherige Byte erneut bestätigt und eine Fenstergröße von 0 Byte angegeben. Falls das Empfangsfenster wieder geöffnet ist, wird das neue Byte bestätigt und eine positive Fenstergröße angegeben, so dass der Datentransfer wieder aufgenommen werden kann. Durch die Verwendung der fenster-orientierten Flusskontrolle kann es zu dem als Silly Window Syndrome bekannten Problem kommen. Es entsteht, wenn der Empfänger ein sehr kleines Fenster anbietet (ohne darauf zu warten ein größeres Fenster anbieten zu können), oder der Sender kleine Datenmengen sofort sendet ohne auf weitere Daten zu warten. Dieses Problem zu verhindern ist Aufgabe beider Seiten. So darf der Empfänger nur ein neues Empfangsfenster anbieten, wenn es mindestens um eine MSS oder um die Hälfte seines Empfangspuffers vergrößert werden kann. Der Sender darf nur dann Segmente versenden, wenn ein maximales Segment zum Versand ansteht, mit einem Segment mindestens die Hälfte des angebotenen Fensters gefüllt wird oder keine Bestätigung für ein vorangehendes Segment aussteht. 22

23 Die Größe des Empfangspuffers beträgt bei heutigen Implementierungen mindestens 4096 Byte, einige Verwenden größere Puffer von 8192 oder sogar Byte. Slow Start Das Sliding Window sorgt zwar dafür, dass der Empfänger nicht mit Segmenten überflutet wird, es kann aber nicht verhindern, dass Daten möglicherweise an einem Router verloren gehen. Dies kann passieren, wenn ein Router aufgrund eines langsamen Netzes Daten zwischenspeichern muss und sein Speicher überfüllt ist. Dann muss er Segemente verwerfen, was den Durchsatz einer TCP-Verbindung stark beeinträchtigen kann. Aus diesem Grund müssen aktuelle TCP-Implementierungen einen Algorithmus namens Slow Start unterstützen, der die Menge der Daten, die ins Netzwerk abgegeben werden, kontrolliert. Für diesen Zweck wird ein weiteres Fenster, das Congestion Window (cwnd) auf der Senderseite verwaltet und mit dem Wert der MSS initialisiert. Nach jedem ACK wird dieses Fenster um eine MSS erhöht. Dadurch wächst das Congestion Window exponentiell (wird das erste Segment bestätigt können zwei weitere gesendet werden, werden auch diese bestätigt 4, usw.). Der Sender kann maximal bis zum Minimum von cwnd und Window Size übertragen ohne eine Bestätigung zu erhalten. Der Sender überwacht den Empfang der ACKs und sieht den Empfang der dritten gleichen Sequenznummer als Anzeichen dafür an, dass mindestens ein Segment wegen der zu hohen Senderate auf dem Weg zum Empfänger verloren gegangen ist. Aus diesem Grund wird das Congestion Window wieder auf die Größe von einer MSS gesetzt und Slow Start beginnt erneut. Durch das exponentielle Wachstum wird sehr schnell eine optimale Netzauslastung erreicht. Ebenso schnell kann es aber zu Segmentverlusten kommen, die vorübergehend zu einer sehr geringen Netzauslastung führen. Aus diesem Grund wird Slow Start zusammen mit einem weiteren Algorithmus, Congestion Avoidance, implementiert. Congestion Avoidance Congestion Avoidance [9] versucht, besser als Slow Start auf einen Segmentverlust zu reagieren. Er basiert auf der Annahme, dass nur etwa 1% aller Segmente fehlerhaft übertragen werden. Die restlichen Segmente gehen durch überfüllte Router-Puffer verloren. Congestion Avoidance benötigt eine weitere Variable, ssthresh, die Anfangs mit Bytes initialisiert wird. Tritt jetzt ein Segmentverlust auf, wird ssthresh auf die Hälfte der Current Window Size (Minimum aus Window Size und cwnd, jedoch mindestens 2 MSS) gesetzt. Für den Fall, dass der Segmentverlust durch einen Timeout festgestellt wurde, wird cwnd auf eine MSS reduziert. Andernfalls (Segmentverlust wurde durch duplizierte ACKs festgestellt) wird cwnd auf sstresh gesetzt, da der Empfang eines ACK impliziert, dass nach wie vor Segmente beim Empfänger ankommen und so der Datenfluss auf eine geringere Menge aber nicht ganz zurück gesetzt werden muss. Die Vergrößerung des Sendefensters (cwnd) ist nun abhängig davon, welcher Algorithmus verwendet wird. Ist cwnd kleiner oder gleich ssthresh, wird Slow Start verwendet. Danach wird Congestion Avoidance verwendet, wodurch das Sendefenster lediglich um 1/cwnd vergrößert wird, wenn eine Bestätigung eintrifft. 23