Transmission Control Protocol

Das Transmission Control Protocol (TCP, Übertragungssteuerungsprotokoll) ist ein Netzwerkprotokoll, das definiert, auf welche Art und Weise Daten zwischen Netzwerkkomponenten ausgetauscht werden sollen.

Geschichte

• Entwickelt von Robert E. Kahn und Vinton G. Cerf als Forschungsarbeit.
• Beginn 1973, erste Standardisierung 1981 als RFC 793.
• Danach gab es viele Erweiterungen, diese werden bis heute in RFCs spezifiziert.

Was ist TCP

• Ist ein zuverlässiges, verbindungsorientiertes, paketvermitteltes (nicht paketvermittelnd) Transportprotokoll.
• Ist eine Implementierung der Transportschicht.
• Fast alle aktuelle Betriebssysteme beherrschen TCP (Nutzung für Datenaustausch mit anderen Rechnern)
• Ist ein sehr weit verbreitetes Protokoll zur Datenübertragung.
• Es ist Teil der Internetprotokollfamilie (der Grundlage des Internet).
• Setzt meistens auf das Internet-Protokoll auf, weshalb häufig auch vom „TCP/IP-Protokoll“ die Rede ist.
• Im Unterschied zum verbindungslosen User Datagram Protokoll (UDP) stellt TCP eine Verbindung zwischen zwei Endpunkten (Sockets) einer Netzverbindung her.
  • Auf dieser Verbindung können in beide Richtungen Daten übertragen werden.

Vorteile

• Datenverluste werden erkannt und automatisch behoben.
• Datenübertragung ist in beiden Richtungen möglich.
• Netzüberlastung wird verhindert.

Aufgabe

• TCP wird als fast ausschließliches Transportmedium für das World Wide Web, E-Mail und andere Netzdienste verwendet.
• Die Aufgabe von TCP ist es nicht, Pakete zu übertragen, sondern die Bytes eines Datenstroms.
  • Die Paketvermittlung wird durch das Internetprotokoll bereitgestellt.
  • IP ist paketvermittelnd, aber TCP paketvermittelt.

Allgemeines

TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex.

• Kann auch als zwei Halbduplexverbindungen betrachtet werden (Informationsfluss in beide Richtungen (allerdings nicht gleichzeitig)).
• Die Daten in Gegenrichtung können zusätzliche Steuerungsinformationen enthalten.
• Anwendungen, die TCP häufig nutzen, sind zum Beispiel Webbrowser und Webserver.

TCP-Software

• Übernimmt Verbindungsverwaltung sowie die Datenübertragung.
• Ist üblicherweise im Netz-Protokollstack des Betriebssystems angesiedelt.
• Anwendungsprogramme benutzen eine Schnittstelle dazu (meist Sockets).

Software-Schnitstelle

• bei Windows in extra einzubindenden Programmbibliotheken („Winsock.dll“ bzw. „wsock32.dll“).
• Linux und andere unixoide Betriebssysteme enthalten einen Socketlayer im Betriebssystemkern (Zugriff über Systemaufrufe).

TCP-Verbindung

• Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert.
  • Ein Endpunkt stellt ein geordnetes Paar dar (IP-Adresse und Port).
  • Ein solches Paar bildet eine bidirektionale Software-Schnittstelle (Socket).

TCP-Verbindungen werden durch vier Werte (einem Quadrupel) eindeutig identifiziert:

(Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port)

Dabei kommt es auf das gesamte Quadrupel an, das heißt:

• Es können zwei verschiedene Prozesse auf demselben Rechner denselben lokalen Port benutzen und mit demselben Rechner auf der Gegenseite kommunizieren, sofern die beteiligten Prozesse auf der anderen Seite unterschiedliche Ports benutzen.
• Dies sind dann zwei verschiedene Verbindungen, deren Quadrupel sich nur in einem Wert unterscheidet: dem Ziel-Port.

Verbindung 1: (Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port x)
Verbindung 2: (Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port y)

Beispiel

1. Ein Serverprozess erzeugt einen Socket auf Port 80 (bind).
   • Markiert diesen für eingehende Verbindungen (listen).
   • Fordert vom Betriebssystem die nächste anstehende Verbindung an (accept).
   • Diese Anforderung blockiert den Serverprozess zunächst, da noch keine Verbindung existiert.
2. Die erste Verbindungsanfrage kommt und wird vom Betriebssystem angenommen, die Verbindung kommt zustande.
3. Jetzt wird diese Verbindung durch das Quadrupel identifiziert.
   1. Der Serverprozess wird aufgeweckt und ihm ein Handle für diese Verbindung überreicht.
   2. Üblich startet der Serverprozess einen Kindprozess, dem er die Behandlung der Verbindung delegiert.
   3. Der Serverprozess fährt mit einer weiteren Accept-Anforderung an das Betriebssystem fort.

• Dadurch ist es möglich, dass ein Webserver mehrere Verbindungen von verschiedenen Rechnern annehmen kann.

Ports

• Portnummern sind Dualsystem 16-Bit-Zahlen und reichen von 0 bis 65535.
• Ports von 0 bis 1023 sind reserviert (vergeben von Internet Assigned Numbers Authority z.B. ist Port 80 für Hypertext Transfer Protocol reserviert.
• Das Benutzen der vordefinierten Ports ist nicht bindend.
• Jeder Administrator kann bspw. einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen Port laufen lassen.
• Üblich bestimmt das Programm auf der Clientseite den Port nicht, sondern lässt ihn sich vom Betriebssystem zuweisen.
• Mehrfaches listen auf demselben Port ist nicht möglich.

Verbindungsaufbau und -abbau

Abb. 2: Verwaltung der TCP-Verbindungen als endlicher Automat

Allgemein

Ein Server, der seinen Dienst anbietet, erzeugt einen Endpunkt (Socket) mit der Portnummer und seiner IP-Adresse.

• Bezeichnet als "passive open" oder "listen".

Ein Client, der eine Verbindung aufbauen will, erzeugt einen Endpunkt (Socket) mit seiner IP-Adresse und einer eigenen, noch freien Portnummer.

• Mit der Adresse des Servers und dem Port kann dann eine Verbindung aufgebaut werden.

Während der Datenübertragungsphase sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch.

• Bezeichnet als "active open"

Jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.

Halb geschlossene Verbindungen

• Der Verbindungsabbau erfolgt schrittweise einseitig.
• Erlaubt der Gegenseite nach der einseitigen Trennung noch Daten zu übertragen.

Halb offene Verbindungen

• wenn eine Seite abstürzt, ohne dass die verbleibende Seite dies erfährt.
• Effekt: Betriebssystemressourcen werden nicht freigegeben.
• Ursprung: TCP-Verbindungen von der Protokollseite bestehen, bis sie abgebaut werden.

Verbindungsaufbau

Abb. 3: TCP-Handshake

1. Der Client sendet dem Server ein SYN-Paket mit einer Sequenznummer x.
   • Die Sequenznummern sind für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig.
   • Ein Paket, dessen SYN-Bit im Header gesetzt ist.
   • Die Start-Sequenznummer ist eine beliebige zufällige Zahl, abhängig von der TCP-Implementierung.
     
     
2. Der Server empfängt das Paket und antwortet.
   • Port geschlossen, antwortet er mit einem TCP-RST, ein Signal, dass keine Verbindung aufgebaut werden kann.
   • Port geöffnet, bestätigt er den Erhalt des ersten SYN-Pakets und stimmt dem Verbindungsaufbau zu, indem er ein SYN/ACK-Paket zurückschickt.
     • Ein Paket, mit ACK-Flag im TCP-Header, welche die Sequenznummer x+1 des SYN-Pakets im Header enthalten.
     • Der Server sendet im Gegenzug seine Start-Sequenznummer y, diese ist unabhängig von der Start-Sequenznummer des Clients.
       
       
3. Der Client bestätigt den Erhalt des SYN/ACK-Pakets durch ein eigenes ACK-Pakets mit der Sequenznummer x+1.
   • Wird auch als „Forward Acknowledgement“ bezeichnet.
   • Aus Sicherheitsgründen sendet der Client die Sequenznummer des Servers + 1 im ACK-Segment zurück.
     
     
4. Die Verbindung ist damit aufgebaut.

Verbindungsaufbau Beispiel

1.	SYN-SENT	→	<SEQ=100><CTL=SYN>	→	SYN-RECEIVED
2.	SYN/ACK-RECEIVED	←	<SEQ=300><ACK=101><CTL=SYN,ACK>	←	SYN/ACK-SENT
3.	ACK-SENT	→	<SEQ=101><ACK=301><CTL=ACK>	→	ESTABLISHED

• Nach Aufbau ist die Verbindung für beide Kommunikationspartner gleichberechtigt
• Man kann einer bestehenden Verbindung auf TCP-Ebene nicht ansehen, wer der Server und wer der Client ist.
• Eine Unterscheidung dieser beiden Rollen in der weiteren Betrachtung keine Bedeutung mehr.

Verbindungsabbau

Abb. 4: TCP-Teardown

• Der Verbindungsabbau kann auf zwei Arten erfolgen: beidseitig oder schrittweise einseitig.
• Der geregelte Verbindungsabbau erfolgt dem Verbindungsaufbau ähnlich.
  1. Statt dem SYN-Bits kommt das FIN-Bit zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen werden.
  2. Der Erhalt des Pakets wird wiederum mittels ACK bestätigt.
  3. Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird.

• Ein verkürztes ist Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.

Maximum segment lifetime (MSL)

• Ist die maximale Zeit, die ein Segment im Netzwerk verbringen kann, bevor es verworfen wird.
• Nach dem Senden des letzten ACKs wechselt der Client in einen zwei MSL andauernden Wartezustand (wait state), in dem alle verspäteten Segmente verworfen werden.
  • Dadurch wird sichergestellt, dass keine verspäteten Segmente als Teil einer neuen Verbindung fehlinterpretiert werden können.
  • Außerdem wird eine korrekte Verbindungsterminierung sichergestellt.
• Geht ACK y+1 verloren, läuft beim Server der Timer ab, und das LAST_ACK-Segment wird erneut übertragen.

Puffer

• Beim Datenversand über TCP werden zwei Puffer verwendet.

1. Senderseitig übermittelt die Applikation die Sendedaten an TCP und dieses puffert die Daten.
2. Effizient werden mehrere kleine Übertragungen in Form einer einzigen großen gesendet.
3. Empfängerseitig landen die empfangenen Daten im Puffer, dieser verfolgt ähnliche Ziele.

• Wenn von TCP mehrere einzelne Pakete empfangen wurden, ist es besser, diese zusammengefügt an die Applikation weiterzugeben.

Drei-Wege-Handschlag

Sowohl beim Verbindungsaufbau als auch beim Verbindungsabbau werden die Antworten auf das erste SYN- bzw. FIN-Paket typischerweise zu einem einzelnen Paket (SYN/ACK bzw. FIN/ACK) zusammengefasst – theoretisch wäre auch das Versenden zweier separater Pakete denkbar. Da in diesem Fall nur noch drei Pakete versendet werden müssen, spricht man auch häufig vom sogenannten Drei-Wege-Handschlag . Das Zusammenfassen des FIN-Pakets und des ACK-Pakets ist allerdings problematisch, da das Senden eines FIN-Pakets die Bedeutung hat „es folgen keine weiteren Daten mehr“. Allerdings kann der Sender des FIN-Pakets weiterhin Daten empfangen (wollen); man spricht von einer halb geschlossenen Verbindung (die Empfangsrichtung ist weiterhin offen, während die Senderichtung geschlossen wurde). Es wäre z. B. denkbar, den Beginn einer HTTP-Anfrage (HTTP-Request) direkt im SYN-Paket mitzuschicken, weitere Daten, sobald die Verbindung aufgebaut wurde, und im letzten HTTP-Request-Paket die (Senderichtung der) Verbindung gleich mittels FIN zu schließen. In der Praxis wird dieses Verfahren allerdings nicht angewendet. Würde der Browser die Verbindung auf diese Art sofort schließen, würde möglicherweise auch der Server die Verbindung schließen anstatt die Anfrage vollständig zu beantworten.

Aufbau des TCP-Headers

Allgemeines

Das TCP-Segment besteht immer aus zwei Teilen: dem Header und der Nutzlast (enS payload). Die Nutzlast enthält die zu übertragenden Daten, die wiederum Protokollinformationen der Anwendungsschicht, wie Hypertext Transfer Protocol HTTP oder File Transfer Protocol FTP , entsprechen können. Der Header enthält für die Kommunikation erforderliche Daten sowie die Dateiformat-beschreibende Information. Den schematischen Aufbau des TCP-Headers kann man in Abbildung 5 sehen. Da das Options-Feld in der Regel nicht genutzt wird, hat ein typischer Header eine Größe von 20 Byte. Die Werte werden in der Byte-Reihenfolge Big-Endian angegeben.

Erläuterung

Abb. 5: Aufbau des TCP-Headers

Source Port (Quellport) (2 Byte)

Gibt die Portnummer auf der Senderseite an.

Destination Port (Zielport) (2 Byte)

Gibt die Portnummer auf der Empfängerseite an.

Sequence Number (4 Byte)

Sequenznummer des ersten Daten- Oktett (Informatik) Oktetts (Byte) dieses TCP-Pakets oder die Initialisierungs-Sequenznummer falls das SYN-Flag gesetzt ist. Nach der Datenübertragung dient sie zur Sortierung der TCP-Segmente, da diese in unterschiedlicher Reihenfolge beim Empfänger ankommen können.

Acknowledgement Number (Quittierungsnummer) (4 Byte)

Sie gibt die Sequenznummer an, die der Absender dieses TCP-Segmentes als Nächstes erwartet. Sie ist nur gültig, falls das ACK (Signal) ACK-Flag gesetzt ist.

Data Offset (4 Bit)

Länge des TCP-Headers in 32-Bit-Blöcken – ohne die Nutzdaten (Payload). Hiermit wird die Startadresse der Nutzdaten angezeigt.

Reserved (4 Bit)

Das Reserved-Feld ist für zukünftige Verwendungen reserviert. Alle Bits müssen null sein.

Control- Flag (Informatik) Flags (8 Bit)

Sind zweiwertige Variablen mit den möglichen Zuständen gesetzt und nicht gesetzt, die zur Kennzeichnung bestimmter für die Kommunikation und Weiterverarbeitung der Daten wichtiger Zustände benötigt werden. Im Folgenden werden die Flags des TCP-Headers und die von ihrem Zustand abhängigen, auszuführenden Aktionen beschrieben.

CWR und ECE

sind zwei Flags, die für Explicit Congestion Notification (ECN) benötigt werden. Mit gesetztem ECE-Bit (ECN-Echo) teilt der Empfänger dem Sender mit, dass das Netzwerk überlastet ist und die Senderate reduziert werden muss. Hat der Sender das getan, teilt er dies dem Empfänger durch Setzen des CWR-Bit ( Congestion Window Reduced) mit.

URG

Ist das Urgent-Flag (urgent = dringend) gesetzt, so werden die Daten nach dem Header sofort von der Anwendung bearbeitet. Dabei unterbricht die Anwendung die Verarbeitung der Daten des aktuellen TCP-Segments und liest alle Bytes nach dem Header bis zu dem Byte, auf das das Urgent- Zeiger (Informatik) Pointer -Feld zeigt, aus. Dieses Verfahren ist fern verwandt mit einem Softwareinterrupt . Dieses Flag kann zum Beispiel verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen. Das Verfahren wird nur äußerst selten benutzt, Beispiele sind die bevorzugte Behandlung von CTRL-C (Abbruch) bei einer Terminalverbindung über Remote login rlogin oder telnet .

In der Regel wird dieses Flag nicht ausgewertet.

ACK

Das Acknowledgment-Flag hat in Verbindung mit der Acknowledgment-Nummer die Aufgabe, den Empfang von TCP-Segmenten beim Datentransfer zu bestätigen. Die Acknowledgment-Nummer ist nur gültig, wenn das Flag gesetzt ist.

PSH

RFC 1122 und RFC 793 spezifizieren das Push-Flag so, dass bei gesetztem Flag sowohl der ausgehende, als auch der eingehende Puffer übergangen wird. Da man bei TCP keine Datagramme versendet, sondern einen Datenstrom hat, hilft das PSH-Flag, den Strom effizienter zu verarbeiten, da die empfangende Applikation so gezielter aufgeweckt werden kann und nicht bei jedem eintreffenden Datensegment feststellen muss, dass Teile der Daten noch nicht empfangen wurden, die aber nötig wären, um überhaupt weitermachen zu können.

Hilfreich ist dies, wenn man zum Beispiel bei einer Telnet -Sitzung einen Befehl an den Empfänger senden will. Würde dieser Befehl erst im Puffer zwischengespeichert werden, so würde dieser (stark) verzögert abgearbeitet werden.

Das PSH-Flag kann, abhängig von der TCP-Implementation im Verhalten zu obiger Erklärung abweichen.

RST

Das Reset-Flag wird verwendet, wenn eine Verbindung abgebrochen werden soll. Dies geschieht zum Beispiel bei technischen Problemen oder zur Abweisung unerwünschter Verbindungen (wie etwa nicht geöffneten Ports, hier wird – anders als bei UDP – kein ICMP-Paket mit „Port Unreachable“ verschickt).

SYN

Pakete mit gesetztem SYN-Flag initiieren eine Verbindung. Der Server antwortet normalerweise entweder mit SYN+ACK, wenn er bereit ist, die Verbindung anzunehmen, andernfalls mit RST. Dient der Synchronisation von Sequenznummern beim Verbindungsaufbau (daher die Bezeichnung SYN).

FIN

Dieses Schlussflag (finish) dient zur Freigabe der Verbindung und zeigt an, dass keine Daten mehr vom Sender kommen. Die FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden.

RWin (Receive) Window (2 Byte)

Ist – nach Multiplikation mit dem RWin#TCP Window Scale Option Fensterskalierungsfaktor – die Anzahl der Daten- Oktett (Informatik) Oktetts (Bytes), beginnend bei dem durch das Acknowledgementfeld indizierten Daten-Oktett, die der Sender dieses TCP-Pakets bereit ist zu empfangen.

Checksum (2 Byte)

Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird über den TCP-Header, die Daten und einen Pseudo-Header berechnet. Dieser Header besteht aus der Ziel-IP, der Quell-IP, der TCP-Protokollkennung (0x0006) und der Länge des TCP-Headers inkl. Nutzdaten (in Bytes).

Urgent Pointer (2 Byte)

Zusammen mit der Sequenz-Nummer gibt dieser Wert die Position des ersten Bytes nach den Urgent-Daten im Datenstrom an. Die Urgent-Daten beginnen sofort nach dem Header. Der Wert ist nur gültig, wenn das URG-Flag gesetzt ist.

Options (0–40 Byte)

Das Options-Feld ist unterschiedlich groß und enthält Zusatzinformationen. Die Optionen müssen ein Vielfaches von 32 Bit lang sein. Sind sie das nicht, muss mit Nullbits aufgefüllt werden ( Padding). Dieses Feld ermöglicht, Verbindungsdaten auszuhandeln, die nicht im TCP-Header enthalten sind, wie zum Beispiel die Maximalgröße des Nutzdatenfeldes.

Datenübertragung

Abb. 6: Segmentierung der Nutzdaten

TCP-/IP-Segment-Größe

Ein TCP-Segment hat typischerweise eine Größe von maximal 1500 Bytes. Ein TCP-Segment muss jedoch in die darunter liegende Übertragungsschicht passen, das Internetprotokoll (IP); siehe hierzu auch Maximum Transmission Unit (MTU).

IP-Paket e wiederum sind zwar theoretisch bis 65.535 Bytes (64  Kibibyte KiB ) spezifiziert, werden aber selbst meist über  Ethernet  übertragen, und bei Ethernet ist die Größe der (Layer-3-)Nutzdaten (wenn man von  Jumbo Frames  absieht) auf 64 (ggf. inklusive Padding) bis 1500 Bytes festgelegt. TCP- und IP-Protokoll definieren jeweils einen Header von 20 Bytes Größe. Für die (Applikations-)Nutzdaten bleiben in einem TCP/IP-Paket also 1460 Bytes (= 1500 Bytes Ethernet-[Nutzdaten] − 20 Bytes Headerdaten TCP − 20 Bytes Headerdaten IP) übrig. Da die meisten Internet-Anschlüsse  Digital Subscriber Line DSL  verwenden, kommt dort zusätzlich noch das  Point-to-Point Protocol Point-to-Point Protocol (PPP)  zwischen IP und Ethernet zur Anwendung, was weitere 8 Bytes für den PPP-Rahmen verbraucht. Die Nutzdaten reduzieren sich also auf insgesamt 1500 − 20 − 20 − 8 = 1452 Bytes  Maximum Segment Size MSS  (Maximum Segment Size). Dies entspricht einer maximalen Nutzdatenrate von 96,8 %.

Aufteilen der Anwendungsdaten auf TCP-/IP-Segmente

Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der Maximum Segment Size MSS . Die Anwendung, die Daten versenden möchte, etwa ein Webserver, legt zum Beispiel einen 7 Kilobyte großen Datenblock im Puffer ab. Um mit einem 1460 Byte großen Nutzdatenfeld 7 Kilobyte Daten zu versenden, teilt die TCP-Software die Daten auf mehrere Pakete auf, fügt einen TCP-Header hinzu und versendet die TCP-Segmente. Dieser Vorgang wird Segmentierung genannt. Der Datenblock im Puffer wird in fünf Segmente aufgeteilt (siehe Abb. 6). Jedes Segment erhält durch die TCP-Software einen TCP-Header. Die TCP-Segmente werden nacheinander abgeschickt. Diese kommen beim Empfänger nicht notwendigerweise in derselben Reihenfolge an wie sie versendet wurden, da im Internet unter Umständen jedes TCP-Segment einen anderen Weg nimmt. Damit die TCP-Software im Empfänger die Segmente wieder sortieren kann, ist jedes Segment nummeriert. Bei der Zuordnung der Segmente im Empfänger wird die Sequenznummer herangezogen.

Abb. 7: Beispiel eines Datentransfers

Die TCP-Software des Empfängers bestätigt diejenigen TCP-Segmente, die einwandfrei (das heißt mit korrekter Prüfsumme) angekommen sind. Andernfalls werden die Pakete neu angefordert.

Beispiel einer TCP-/IP-Datenübertragung

Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Bytes an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1–5, so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verlorengegangen ist, so kann er nur die 1 und die 2 bestätigen, 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt, läuft sein Timer ab, und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle fünf TCP-Segmente, sofern beide Seiten die TCP-Option SACK (Selective ACK) unterstützen. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Retransmission Timer.

Retransmission Timer

• Zur Feststellung, wann ein Paket im Netzwerk verloren gegangen ist, wird vom Sender ein Timeout verwendet, bis zu dem das ACK der Gegenseite eingetroffen sein muss.
  • Timeout zu niedrig, Pakete werden doppelt geschickt.
  • Timeout zu hoch, velorene Pakete werden zu spät neu geschickt.

• Aufgrund unterschiedlicher Laufzeiten der IP-Pakete ist nur ein dynamischer Timer sinnvoll.

Zusammenhang von Flusssteuerung und Staukontrolle

In den folgenden zwei Abschnitten werden die TCP-Konzepte zur Flusssteuerung und Staukontrolle (oder Überlaststeuerung) erläutert. Dabei werden das Sliding Window und das Congestion Window eingeführt. Der Sender wählt als tatsächliche Sendefenstergröße das Minimum aus beiden Fenstern. Um eine zuverlässige Datenübertragung durch Sendewiederholungen zu gewährleisten, werden sogenannte ARQ-Protokoll e (englisch Automatic Repeat reQuest, dt. Automatische Wiederholungsanfrage) eingesetzt.

Flusssteuerung

Abb. 8: Sliding Window

Da die Anwendung Daten aus dem Puffer liest, ändert sich der Füllstand des Puffers ständig. Deshalb ist es notwendig, den Datenfluss dem Füllstand entsprechend zu steuern. Dies geschieht mit dem Sliding Window und dessen Größe. Den Puffer des Senders erweitern wir, wie in Abb. 8 zu sehen, auf 10 Segmente. In der Abb. 8a werden gerade die Segmente 1–5 übertragen. Die Übertragung ist vergleichbar mit Abb. 7. Obwohl der Puffer des Empfängers in Abb. 7 am Ende voll ist, fordert er mit ACK=7301 die nächsten Daten ab dem Byte 7301 beim Sender an. Dies hat zur Folge, dass das nächste TCP-Segment vom Empfänger nicht mehr verarbeitet werden kann. Ausnahmen sind jedoch TCP-Segmente mit gesetztem URG-Flag. Mit dem RWin Window -Feld kann er dem Sender mitteilen, dass er keine Daten mehr verschicken soll. Dies geschieht, indem er im Window-Feld den Wert Null einträgt (Zero Window). Der Wert Null entspricht dem freien Speicherplatz im Puffer. Die Anwendung des Empfängers liest nun die Segmente 1–5 aus dem Puffer, womit wieder ein Speicherplatz von 7300 Byte frei ist. Damit kann er die restlichen Segmente 6–10 mit einem TCP-Header, der die Werte SEQ=1, ACK=7301 und Window=7300 enthält, beim Sender anfordern. Der Sender weiß nun, dass er maximal fünf TCP-Segmente an den Empfänger schicken kann, und verschiebt das Window um fünf Segmente nach rechts (siehe Abb. 8b). Die Segmente 6–10 werden nun alle zusammen als Burst verschickt. Kommen alle TCP-Segmente beim Empfänger an, so quittiert er sie mit SEQ=1 und ACK=14601 und fordert die nächsten Daten an.

Silly Window Syndrome

Der Empfänger sendet ein Zero Window an den Sender, da sein Puffer voll ist. Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Puffer. Der Empfänger schickt einen TCP-Header mit Window=2 (Window Update) an den Sender und fordert gleichzeitig die zwei Byte an. Der Sender kommt der Aufforderung nach und schickt die zwei Byte in einem 42 Byte großen Paket (mit IP-Header und TCP-Header) an den Empfänger. Damit ist der Puffer des Empfängers wieder voll, und er schickt wieder ein Zero Window an den Sender. Die Anwendung liest jetzt zum Beispiel hundert Byte aus dem Puffer. Der Empfänger schickt wieder einen TCP-Header mit einem kleinen Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder fort und verschwendet Bandbreite, da nur sehr kleine Pakete versandt werden. Clarks Lösung ist, dass der Empfänger ein Zero Window sendet und so lange mit dem Window Update warten soll, bis die Anwendung mindestens die maximale Segmentgröße (maximum segment size, in unseren bisherigen Beispielen 1460 Byte) aus dem Puffer gelesen hat oder der Puffer halbleer ist – je nachdem, was zuerst eintritt (Dave Clark, 1982). Auch der Sender kann zu kleine Pakete abschicken und dadurch Bandbreite verschwenden. Dieser Umstand wird mit dem Nagle-Algorithmus beseitigt. Deswegen ergänzt er sich mit Clarks Lösung.

Überlaststeuerung/Staukontrolle (Congestion Control)

Im Internet, in dem viele Netze mit unterschiedlichen Eigenschaften verbunden werden, ist Datenverlust einzelner Pakete durchaus normal. Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen, die entsprechend wiederholt werden müssen. Durch die Wiederholung steigt wiederum die Belastung, ohne geeignete Maßnahmen kommt es zu einem Datenstau.

Die Verlustrate wird von einem Internet Protocol IP-Netzwerk ständig beobachtet. Abhängig von der Verlustrate wird die Senderate durch geeignete Algorithmus Algorithmen beeinflusst: Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow-Start) und die Senderate schrittweise erhöht, bis es zum Datenverlust kommt. Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht. Insgesamt nähert sich die Datenrate so zunächst dem jeweiligen zur Verfügung stehenden Maximum und bleibt dann ungefähr dort. Eine Überbelastung wird vermieden.

Algorithmus zur Überlaststeuerung

Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit ( Timeout (Netzwerktechnik) Timeout ) keine Bestätigung (ACK) erhält. Man muss davon ausgehen, dass das Paket aufgrund zu hoher Netzlast von einem Router im Netz verworfen wurde. Das heißt, der Puffer eines Routers ist vollgelaufen; es handelt sich hier sozusagen um einen Stau im Netz. Um den Stau aufzulösen, müssen alle beteiligten Sender ihre Netzlast reduzieren. Dazu werden im RFC 2581 vier Algorithmen definiert: slow start, congestion avoidance, fast retransmit und fast recovery, wobei slow start und congestion avoidance zusammen verwendet werden. Die zwei Algorithmen fast retransmit und fast recovery werden auch zusammen verwendet und sind eine Erweiterung der Algorithmen slow start und congestion avoidance.

Slow Start Slow Start und Congestion Avoidance

Grafische Darstellung des Slow-Start-Algorithmus

Zu Beginn einer Datenübertragung dient der Slow-Start-Algorithmus zur Bestimmung des congestion window (wörtlich: Überlastfenster), um einer möglichen Überlastsituation vorzubeugen. Man möchte Staus vermeiden, und da die momentane Auslastung des Netzes nicht bekannt ist, wird mit zunächst kleinen Datenmengen begonnen. Der Algorithmus startet mit einem kleinen Fenster von einer Maximum Segment Size MSS (Maximum Segment Size), in dem Datenpakete vom Sender zum Empfänger übertragen werden.

Der Empfänger sendet nun eine Bestätigung (ACK) an den Sender zurück. Für jedes empfangene ACK wird die Größe des congestion window um eine MSS erhöht. Da für jedes versandte Paket bei erfolgreicher Übertragung ein ACK geschickt wird, führt dies innerhalb einer Roundtrip-Zeit zu einer Verdopplung des Congestion Windows. In dieser Phase gibt es also ein exponentielles Wachstum. Wenn das Fenster beispielsweise das Versenden von zwei Paketen gestattet, so erhält der Sender auch zwei ACKs und erhöht das Fenster daher um 2 auf 4. Dieses exponentielle Wachstum wird so lange fortgesetzt, bis der sogenannte Slow-Start Threshold erreicht wird (engl. threshold ‚Schwelle‘). Die Phase des exponentiellen Wachstums wird auch Slow Start Phase genannt.

Danach wird das Congestion Window nur noch um eine MSS erhöht, wenn alle Pakete aus dem Fenster erfolgreich übertragen wurden. Es wächst also pro Roundtrip-Zeit nur noch um eine MSS, also nur noch linear. Diese Phase wird als Congestion Avoidance Phase bezeichnet. Das Wachstum wird beendet, wenn das vom Empfänger festgelegte Empfangsfenster erreicht worden ist (siehe Fluss-Steuerung).

Kommt es zu einem Timeout, wird das congestion window wieder auf 1 zurückgesetzt, und der slow-start threshold wird auf die Hälfte der Flight Size (Flight Size ist die Anzahl an Paketen, die verschickt, aber noch nicht quittiert wurden) herabgesetzt. Die Phase des exponentiellen Wachstums wird also verkürzt, so dass das Fenster bei häufigen Paketverlusten nur langsam wächst.

Fast-Retransmit und Fast-Recovery

Fast-Retransmit und Fast-Recovery („schnelles Erholen“) werden eingesetzt, um nach einem Paketverlust schneller auf die Stau-Situation zu reagieren. Dazu informiert ein Empfänger den Sender, wenn Pakete außer der Reihe ankommen und somit dazwischen ein Paketverlust vorliegt. Hierfür bestätigt der Empfänger das letzte korrekte Paket erneut für jedes weitere ankommende Paket außer der Reihe. Man spricht dabei von Dup-Acks ( duplicate acknowledgments), also mehrere aufeinanderfolgende Nachrichten, welche dasselbe Datensegment ACKen. Der Sender bemerkt die duplizierten Bestätigungen, und nach dem dritten Duplikat sendet er sofort, vor Ablauf des Timers, das verlorene Paket erneut. Weil nicht auf den Ablauf des Timers gewartet werden muss, heißt das Prinzip Fast Retransmit. Die Dup-Acks sind auch Hinweise darauf, dass zwar ein Paketverlust stattfand, aber doch die folgenden Pakete angekommen sind. Deshalb wird das Sendefenster nach dem Fehler nur halbiert und nicht wie beim Timeout wieder mit Slow-Start begonnen. Zusätzlich kann das Sendefenster noch um die Anzahl der Dup-Acks erhöht werden, denn jedes steht für ein weiteres Paket, welches den Empfänger erreicht hat, wenn auch außer der Reihe. Da dadurch nach dem Fehler schneller wieder die volle Sendeleistung erreicht wird, nennt man das Prinzip Fast-Recovery.