Das Transmission Control Protocol (TCP)

Inhalt

1. Einleitung

2. TCP-Header
2.1. TCP im IP-Datagramm
2.2. Übersicht über den TCP-Header
2.2.1. Portnummern, Sequenznummer, Bestätigungsnummer
2.2.2. Erläuterung der Flag-Bits
2.2.3. Optionen und weitere Bestandteile des TCP-Headers

3. Auf- und Abbau einer Verbindung
3.1. Aufbau einer TCP-Verbindung
3.1.1. Three-Way-Handshake
3.1.2. Simultaneous Open
3.2. Abbau einer TCP-Verbindung
3.2.1. Beenden einer Verbindung
3.2.1.1. Full Close / Half Close
3.2.1.2. Simultaneous Close
3.2.2. Abbruch einer Verbindung (Reset)
3.3. Begriffserläuterung: Active / Passive Open und Active / Passive Close

4. Datenübertragung
4.1. Flußkontrolle
4.1.1. Benutzerabhängiger Transfer (Interactive Data Flow)
4.1.1.1. verzögertes Bestätigen (Delayed Acknowledgement)
4.1.1.2. Nagle-Algorithmus
4.1.2. Benutzerunabhängiger Transfer (Bulk Data Flow)
4.1.2.1. Normaler Datenfluß
4.1.2.2. Sliding Windows und Fenstergröße
4.1.2.3. Slow-Start-Algorithmus
4.2. Behandlung von Timeouts
4.2.1. Congestion-Avoidance-Algorithmus
4.2.2. Fast-Retransmit- / Fast-Recovery-Algorithmus
4.2.3. Timer in TCP
4.3. Silly-Window-Phänomen

5. TCP-Zustandsdiagramm

6. Literatur

1. Einleitung

Obwohl IP seinen Dienst nach „bestem Bemühen“ versieht, ist es nicht ausreichend, um eine verläßliche Datenübertragung zu gewährleisten: zwar gelangen die meisten Datagramme auf ihrem Weg auch ans Ziel, aber eine Garantie gibt es aufgrund möglicher Übermittlungsfehler oder lokaler Staus nicht. Es liegt in der Natur des IP, daß Datagramme in falscher Reihenfolge ankommen können - die Pakete werden ja unabhängig voneinander verschickt und können somit völlig unterschiedliche Routen nehmen.

Hier kommt TCP ins Spiel, das entwickelt wurde, um Fehler der Datenübertragung und des Netzwerkes so weit wie möglich vor der Applikation, die das eigentliche Interesse am Datentransfer hat, zu verbergen. TCP ermöglicht eine zuverlässige Verbindung zwischen zwei Applikationen und bedient sich dabei des IP- Protokolls, welches die TCP-Segmente in IP-Datagramme kapselt und an einen Rechner weiterleitet. Somit ist TCP nicht für die Kommunikation zwischen Rechnern zuständig, sondern für die Kommunikation von Appli- kationen.

Anders ausgedrückt: TCP kann als Dienst für verbindungsorientierte, verläßliche Datenströme¹ bezeichnet werden. Der Begriff „verbindungsorientiert“ bedeutet hier, daß zwei Applikationen, die einen Datenaustausch vornehmen möchten, zunächst eine Verbindung auf Basis des TCP erstellen müssen. Erst dann können Daten ausgetauscht werden. Zum Abschluß muß die Verbindung ordnungsgemäß beendet werden. Weil TCP Verbindungen zwischen genau zwei Computern ermöglicht, sind Multi-Receiver-Jobs wie Broadcasting nicht möglich. TCP ist insofern „verläßlich“, als daß es

a) die zu sendende Datenmenge in sogenannte Segmente aufteilt.
b) beim Senden eines Segments einen Timer initialisiert, der die Empfangsbestätigung (Acknowledgement, später kurz als ACK bezeichnet) des anderen Endes der Verbindung überwacht. Läuft der Timer ab, ohne daß eine Bestätigung eingegangen ist, wird das Segment erneut gesendet². Man nennt dies Positive Acknowledgement With Re-Transmission (PAR).
c) wie in b) beschrieben, korrekt empfangene Datenpakete bestätigt. TCP benutzt Prüfsummen, um die Kor- rektheit des Segmentinhaltes festzustellen. Allerdings hat TCP keinerlei Informationen darüber, welche Daten (binär, ASCII...) es transportiert. Dies ist allein Angelegenheit der beteiligten Applikationen.
d) Datenpakte in der richtigen Reihenfolge, die wie bereits beschrieben nicht unbedingt mit der Reihenfolge des Empfangs identisch sein muß, an die Empfängerapplikation weiterleitet.
e) doppelt empfangene Segmente erkennt und das Duplikat entfernt.
f) Flußkontrolle ermöglicht, so daß immer nur so viele Daten an den Empfänger gesendet werden, wie dieser auch aufnehmen kann³.

Historischer Überblick über die Entstehung und Verbesserung von TCP:

Die Geschichte des TCP beginnt bei der ARPA, der Advanced Research Project Agency, die in den 60er Jah- ren ein Netzwerk entwickelte, das Computer auf der ganzen Welt verbinden sollte. 1969 wurde das ARPANET zum ersten Mal mit 4 Knotenpunkten geschaltet. Die ersten Anwendungen waren Terminalsitzungen und Da- teitransfer. 1974 wurde von Vinton G. Cerf und Robert E. Kahn eine Kombination von Protokollen mit dem Namen TCP/IP vorgeschlagen, welche das frühere, funktionell nicht ausreichende, Network Control Program (NCP) ablösen sollte. Die an diese Protokollkombination gestellten Bedingungen waren anspruchsvoll:

- Routing der Daten mußte zwischen Subnetzwerken möglich sein
- Die Technologie der Subnetzwerke sollte nicht klar festgelegt werden müssen
- Hardwareunabhängigkeit der Hosts und Betriebssystemunabhängigkeit
- Umgehen fehlerhafter oder ausgefallener Router
- Stabiler und schneller Wiederaufbau nach Versagen des Netzes
- Neue Subnetzwerke mußten bei laufendem Betrieb hinzugefügt werden können

Obwohl TCP/IP diese Anforderungen erfüllte, erfolgte nach Standardisierungen in den Jahren 1978 bis 1981 [2,3,4] erst 1982 im gesamten ARPANET der Umstieg von NCP auf TCP/IP. Heutzutage ist es das Protokoll des Internet (das Resultat des 1985 beendeten ARPANET-Projektes). 1988 wurden wichtige Verbesserungen vor allem im Bereich des Zeitmanagements und der Stausteuerung (Einführung des Slow-Start⁴ )[6]durchge- führt und 1992 Vorschläge zur Anpassung des Protokolls an sehr hohe Übermittlungsraten diskutiert. Ziel: Op- timierung der Übertragungen für Hosts, die im Bereich von Terrabits / Sekunde operieren können7.

Das Transmission Control Protocol (TCP)

2. TCP-Header

2.1 TCP im IP-Datagramm:

TCP benutzt für die Kommunikation eine Datenstruktur, die Header genannt wird. Dem Header werden von der Applikation erhaltenen Daten zugefügt. Im Header befinden sich alle Informationen, die der Empfänger benötigt, um die ankommenden Segmente richtig zu handhaben. Ein TCP-Segment ist immer in ein IPDatagramm eingebettet. Die Größe dieses IP-Datagramms berechnet sich wie folgt:

- IP-Header (20 Bytes)
- TCP-Header (20 Bytes)
- TCP-Daten

Die Segmentgröße wird durch zwei Faktoren begrenzt:

- jedes Segment muß in das Nutzdatenfeld des IP-Protokolls passen (65.535 Byte)
- jedes Netz hat eine maximale Transfereinheit (MTU - Maximum Transfer Unit), in die das Segment eben- falls passen muß. In der Regel ist die MTU einige tausend Byte groß (beispielsweise Ethernet: 1.500 Bytes). Läuft ein Segment durch eine Anzahl von Netzen und trifft dabei auf ein Netz mit einer kleineren MTU, so muß das Segment vom Router in kleinere Segmente aufgeteilt werden.

Segmente ohne Daten sind zulässig und dienen der Übermittlung von Bestätigungen und Steuernachrichten.

2.2 Übersicht über den TCP-Header

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1 - Aufbau des TCP-Headers

2.2.1 Portnummern, Sequenznummer, Bestätigungsnummer

Jedes TCP-Segment beinhaltet zwei Portadressen, die beide jeweils eine Länge von 16 Bit haben. Die erste Portadresse identifiziert die Senderapplikation, die zweite die Empfängerapplikation. Zusammen mit den beiden Adressen im IP-Header - alle vier Zahlen zusammen nennt man auch einen „Socket“4 - kann man so jedes Segment einer spezifischen Verbindung zuordnen. Bestimmte Applikationen verwenden Portnummern, die ihnen fest zugeordnet, allgemein bekannt und üblicherweise zwischen 1 und 1024 liegen. Diese werden als „well-known“9 bezeichnet. Es sind standardisierte Portnummern; jede Applikation kennt sie. Beispiele sind Telnet (Port 23), FTP Control Channel (Port 21) und WWW (Port 80).

Die Sequenznummer spezifiziert die Position des ersten Datenbytes im Segment. Dadurch kann TCP die Zustellung eines Segments garantieren. TCP nummeriert fortlaufend jedes Byte, das es als Daten von der Applikation bekommt. Anhand der Sequenznummer kann also jedes einzelne Segment identifiziert werden.

Die Sequenznummer wird nach folgendem Algorithmus festgelegt: Beim Start des Systems ist sie 1 und wird jede halbe Sekunde um 64.000 erhöht. Dieses Vorgehen ist allerdings vom verwendeten System abhängig und kann somit zwischen unterschiedlichen Implementierungen variieren. Zusätzlich wird die Sequenznummer bei jedem Verbindungsaufbau um diesen Faktor erhöht. Werden darüberhinaus in einem Segment noch Nutzdaten transportiert, so hat das zweite Segment, welches übertragen wird, die Sequenznummer des vorherigen Seg- ments plus die Anzahl der Bytes, welche im ersten Segment übertragen wurden. Jedes Segment ist im Netz somit eindeutig.

Die Bestätigungsnummer (Acknowledgement Number) stellt lediglich die Nummer des Segments dar, das TCP bestätigen möchte. Es wird also nur die Sequenznummer des zu bestätigen Datenpaketes in das Acknowledge- ment-Feld kopiert und das ACK-Flag gesetzt. Dieses neue Segment wird dann als Bestätigung geschickt.

2.2.2 Flag-Bits

Im TCP-Header ist Platz für folgende sechs Flag-Bits reserviert:

- URG Markiert einen Teil der Daten als dringend. Dieser wird unabhängig von der Reihenfolge im Datenstrom sofort an die Applikation weitergegeben. Markiert wird das letzte abzuliefernde Byte. Anwendung findet das URG-Flag beispielsweise, wenn der Benutzer einen Dateitransfer (in FTP) abbrechen möchte.

- ACK Das Segment dient zum Bestätigen eines bereits korrekt empfangenen Segments.
- PSH Daten in diesem Segment sollen sofort der Anwendung übergeben werden: eine Bestätigung für dieses Segment bedeutet, daß alle Daten bis zu der gelieferten Bestätigungsnummer bei der Applikation angekommen sind und nicht mehr im TCP-Empfangspuffer liegen.
- RST⁵ Bricht eine Verbindung ab
- SYN⁶ Verbindungsaufbau: Synchronisieren der Sequenznummern
- FIN⁷ Es folgen keine weiteren Datensendungen des Senders

2.2.3 Optionen und weitere Bestandteile des TCP-Headers Optionen

Das Feld Optionen soll eine Möglichkeit bieten, Funktionen bereitzustellen, die im TCP-Header nicht explizit vorgesehen sind. In TCP sind drei Optionen definiert:

- End of Option List
- No Operation
- Maximum Segment Size (MSS)

Die Option End of Option List zeigt das Ende aller zu übertragenden Optionen an, No Operation wird zur Trennung zweier Optionen benutzt.

Die wichtigste dieser drei Optionen stellt die Maximum Segment Size dar: Mit dieser Option kann ein Host die maximale Anzahl Nutzdaten übermitteln, die er annehmen möchte. Während eines Verbindungsaufbaus kann jede Seite ihre maximale Segmentgröße übermitteln, die kleinere der beiden Zahlen wird dann für die Übertragung übernommen. Wird diese Option von einem Host nicht unterstützt, wird als Standardvorgabe ein Wert von 536 Byte angenommen.

TCP-Prüfsumme

Damit TCP einen verläßlichen Datentransport durchführen kann, muß es die empfangenen Daten auf Korrektheit überprüfen. Das geschieht anhand einer Prüfsumme, deren Algorithmus wie folgt konzipiert ist:

Alle 16-Bit Wörter werden im 1er-Komplement addiert und die Summe ermittelt. Bei der Berechnung ist das Checksum-Feld auf Null gesetzt und das Datenfeld wird bei ungerader Länge um ein Nullbyte aufgefüllt.

Führt der Empfänger des Segments die Berechnung auf das gesamte Segment aus - inklusive des Feldes für die Prüfsumme - sollte das Ergebnis 0 sein.

3. Auf- und Abbau einer Verbindung

3.1 Aufbau einer TCP-Verbindung

3.1.1 Three-Way-Handshake

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1 - Three-Way-Handshake

Der Verbindungsaufbau unter TCP geschieht durch eine Prozedur, die Three-Way-Handshake genannt wird.

Der Sinn dieses Three-Way-Handshake ist es, die Möglichkeit einer falschen Verbindung erheblich zu reduzie- ren.

1) Die Seite (normalerweise als "Client" bezeichnet), die eine Verbindung aufbauen möchte, sendet ein Seg- ment (SYN genannt), das folgende Informationen beinhaltet:
- SYN-Flag
- Portnummer des Empfängers (Server), über die kommuniziert werden soll
- Initial Sequence Number (ISN) des Clients

2) Der Server antwortet mit einem eigenen SYN-Segment. Enthalten sind darin:
- SYN- und ACK-Flag
- die ISN des Servers
- die ISN des Clients plus 1 (Bestätigungsnummer)

3) Der Client bestätigt das empfangene SYN Segment des Servers mit:
- ACK-Flag
- die ISN des Servers plus 1 (Bestätigungsnummer)

Die ISN wird bei gesetztem SYN-Flag erhöht, damit jede Verbindung und jeder Status eines Verbindungsaufbaus eindeutig ist. Nach Ablauf der beschriebenen Schritte ist eine Verbindung etabliert.

3.1.2 Simultaneous Open

Eine Ausnahme beim Verbindungsaufbau tritt dann ein, wenn beide Seiten gleichzeitig ein SYN-Segment sen- den. Hier kann man nicht mehr von einer Client-Server-Verbindung sprechen, da beide Computer sowohl Client wie auch Server sind. Weil vier Schritte notwendig sind, um eine Verbindung zu etablieren, ist der Beg- riff Three-Way-Handshake in diesem Zusammenhang ebenfalls falsch. Beide Seiten senden je ein SYN- Segment und bestätigen das SYN-Segment der anderen Verbindungsseite. Dann erst kann man die Verbindung als etabliert bezeichnen.

3.2 Abbau einer TCP-Verbindung

3.2.1 Beenden einer Verbindung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2 - Full Close

3.2.1.1 Full Close / Half Close

Im Gegensatz zum Verbindungsaufbau (Three-Way-Handshake) benötigt ein regulärer Verbindungsabbau (Full-Close) vier Schritte. Weil TCP gleichzeitige, unabhängige Übertragungen in zwei Richtungen zuläßt (Full-Duplex), kann jede Seite ihre Verbindung schließen, ohne daß dies das Senden der Gegenseite beeinflußt. In einem solchen Fall spricht man von einem Half-Close, der aber nur von wenigen Applikationen genutzt wird. Normalerweise werden beide Verbindungen so lange aufrechterhalten, wie Daten übertragen werden.

Der Regelfall (Full-Close) läuft wie folgt ab:

1) Die Seite (Seite a), die ihre Verbindung beenden möchte, sendet ein TCP-Segment (FIN-Segment ge- nannt), das u.a. folgende Informationen transportiert:
- FIN-Flag
2) Die Gegenseite (Seite b) antwortet mit einer Bestätigung des FIN-Segments
- ACK-Flag
Zusätzlich informiert TCP die beteiligte Applikation, daß die Gegenseite das Senden eingestellt hat.
3) Die Applikation hat die Benachrichtigung erhalten und beauftragt TCP, seine Verbindung ebenfalls zu schließen. Gesendet wird:
- FIN-Flag
4) Seit a bestätigt (ACK) das empfangene FIN-Segment. Somit ist die Verbindung ordnungsgemäß geschlossen.

3.2.1.2 Simultaneous Close

Beide Seiten senden gleichzeitig ein FIN und initiieren somit beide ein aktives Schließen der Verbindung (active close⁸ ). Daraufhin wird auf beiden Seiten die Verbindung geschlossen und eine Bestätigung des empfangenen FIN-Segments gesendet.

3.2.2 Abbruch einer Verbindung (Reset)

Der TCP-Header beinhaltet ein Kontrollbit, welches mit RST (Reset) bezeichnet wird⁹. Ein Reset wird generell dann gesendet, wenn ein Segment am Port angelangt, welches nicht zur aktuellen Verbindung gehört. Diese ist ja durch IP-Adresse und Port beider Endsysteme charakterisiert (Socket). Ein Reset erfordert keine Bestäti- gung.

a) Verbindungsanfrage an einen nicht existierenden Port

Versucht ein Computer ergebnislos, eine Verbindung mit einer Applikation auf einem Server herzustellen, wird ein TCP-Reset gesendet und die ISN durch ein ACK=SYN+1 bestätigt.

b) Beenden einer Verbindung durch Reset-Flag

Normalerweise wird eine Verbindung durch ein FIN-Segment beendet¹⁰. Es ist jedoch auch möglich, die Verbindung durch ein RST-Flag zu beenden. Das RST-Segment wird nicht mehr bestätigt. Diese Art des Abbruchs muß von der Applikation unterstützt werden. Kommt das RST-Segment nicht am Ziel an, so bleibt die Verbindung immer geöffnet. Einige Betriebssysteme implementieren daher den automatische Verbindungsabbau, wenn beispielsweise länger als 10 Minuten nichts gesendet oder empfangen wurde¹¹.

c) Verspätetes SYN-Segment

Das TTL-Feld (Time To Live) ist ein 1 Byte langes Feld im IP-Header. Es dient zur Begrenzung der Lebensdauer von Datagrammen und wird als Zähler von jedem Router dekrementiert. Wird der Wert Null, wird das Datagram gelöscht. Als Zeiteinheit ist die Sekunde definiert. Die relative Lebensdauer eines Datagramms beträgt maximal 255 Sekunden oder das Durchlaufen von 255 Routern.

Annahme: Seite 1 sendet zur Herstellung einer Verbindung an Seite 2 ein SYN-Segment. Dieses wird inner- halb des TTL nicht bestätigt. Folge: Seite 1 sendet eine erneute Anfrage. Die Verbindung kommt zustande und wird durch FIN korrekt beendet. All dieses geschah innerhalb der TTL des SYN-Segments. Nun kommt das zuerst gesendete SYN-Segment aber doch noch an Seite 2 an bevor sein TTL endgültig abläuft. Seite 2 wird den offensichtlich gewünschten Verbindungsaufbau nun bestätigen. Seite 1 rechnet nicht mehr mit der Bestäti- gung des ersten SYN-Segments. Der erneute Aufbau einer Verbindung ist also nicht gewünscht. Folge: Seite 1 sendet an Seite 2 ein Reset.

3.3 Begriffserläuterung: Active / Passive Open bzw. Active / Passive Close

In Zusammenhang ¹² mit dem Auf- und Abbau von Verbindungen werden bestimmte Begriffe wie folgt benutzt:

- Die Seite, die eine Verbindung aufbauen möchte, führt einen „Active Open“ durch.
- Die Gegenseite führt einen „Passive Open“ durch.

Die Begriffe Active / Passive Close werden in Bezug auf den Verbindungsabbau synonym benutzt.

4. Datenübertragung

4.1 Flußkontrolle

4.1.1 Benutzerabhängiger Transfer

Unter benutzerabhängigem Transfer¹³ (Interactive Data Flow) versteht man Anwendungen, bei denen die An- forderungen an den Server vom Nutzer direkt bestimmt werden. Telnet ist eine solche Anwendung. Der gene- relle Ablauf einer Anforderung ist in Abbildung 4.1 dargestellt: Der Benutzer tippt ein Zeichen ein, das zum Server übertragen wird. Dieser antwortet mit einer Bestätigung des korrekten Empfangs, und die dahinterliegende Applikation veranlaßt gegebenenfalls, ein Echo des empfangenen Buchstabens zu senden. Der Client bestätigt das Echo des Servers.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1 - benutzerabhängiger Transfer (mit Echo)

4.1.1.1 Verzögertes Bestätigen (Delayed Acknowledgement)

Wie Abbildung 4.2 zeigt, sind 28 Segmente nötig, um das Wort „Hamburg“ zu übertragen. Für nur sieben Zeichen ist das ein erheblicher Aufwand, den man aber optimieren kann. Ein erster Schritt ist das verzögerte Bestätigen von empfangenen Zeichen:

- Der Server wartet nach Empfang eines Zeichens eine gewisse Zeit, ob die Applikation Daten (das Echo) zum Senden anbietet und verschickt dann die Empfangsbestätigung zusammen mit den
- Der Client sendet die Bestätigung des Echos zusammen mit dem nächsten Zeichen.

In Abbildung 4.2 verkleinert sich der Aufwand auf 17 Segmente. Natürlich wartet TCP nur eine begrenzte Zeit auf Daten, die es gemeinsam mit der Bestätigung verschicken kann; in der Regel ist ein Timer von 200ms implementiert. Liegen nach Ablauf dieser Zeit keine Daten im Sendepuffer, wird nur die Bestäti- gung verschickt.

4.1.1.2 Nagle-Algorithmus

Der 1984 eingeführte Nagle-Algorithmus5 verhindert das Versenden einzelner, kleiner TCP-Segmente und geht noch einen Schritt weiter, als das Konzept des verzögerten Bestätigens: Die zu sendenden Segmente werden beim Sender so lange zwischengepuffert, bis alle zuletzt gesendeten Daten von der Gegenseite bestätigt sind. Der Algorithmus reagiert somit flexibel auf die Umgebung: Je schneller Daten bestätigt werden, um so schneller werden neue Segmente verschickt. Im unteren Beispiel optimiert der Nagle Algorithmus die Datenübertragung auf 9 Segmente. Soll eine Anwendung aber in Echtzeit reagieren (wenn beispielsweise aktuelle Mouse-Bewegungen übertragen werden), muß der Nagle-Algorithmus abgeschaltet werden, um Verzögerungen, die vom Benutzer bemerkt werden, zu vermeiden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.2 - Optimierung des benutzerabhängigen Transfers

4.1.2 Benutzerunabhängiger Transfer

4.1.2.1 Normaler Datenfluß

Abbildung 4.3 zeigt den Ablauf ¹⁴ einer TCP- Verbindung. Beteiligt sind Computer A und B; die Pfeile geben das Senden eines Segmentes an. Der Ablauf einer Verbindung läuft in drei Schritten ab:

1. Verbindungsaufbau (Segmente 1 bis 3)
2. Datentransfer (Segmente 4 bis 16)
3. Verbindungsabbau (Segmente 17 bis 20)

Verbindungsaufbau:

A initiiert den bekannten Three-Way-Handshake und bietet eine Fenstergröße von 4096 Bytes und eine Maximum Segment Size (MSS) von 1024 Bytes an. B antwortet mit einem eigenen SYN-Segment und offeriert ebenfalls eine MSS von 1024 Bytes. Zum Abschluß des Verbindungsaufbaus bestätigt A das empfangene SYN-Segment; die Verbindung ist etabliert.

Datentransfer:

A sendet gemäß MSS drei 1024 Bytes große Segmente (Segmente 4 bis 6), von denen B aber zunächst nur die ersten beiden bestätigt (die bestätigte Sequenznummer ist 2049). Erst das achte Segment bestätigt das sechste Segment. TCP verzögert nach Empfang von Segment 4 die Bestätigung (Delayed Acknowledgement); nach Empfang von Segment 5 wird Delayed Acknowledgement wieder abgeschaltet und eine Bestätigung gesendet. Dasselbe Verhalten zeigt TCP bei Erhalt des sechsten Segments. Weil aber der Timer des Delayed Acknowledgement abläuft, bevor weitere Daten hinzugekommen sind, sendet TCP nur die Bestätigung von Segment 6.

Die Segmente 11 bis 16 werden ähnlich behandelt,

allerdings läuft hier der Timer des Delayed

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3- Normaler Datenfluß

Acknowledgement noch, während Segment 15 empfangen wird. Segment 16 bestätigt also sowohl Segment 13 als auch Segment 15. Offensichtlich gibt es nicht einen einzigen korrekten Weg für TCP, Daten zu übertragen. Das Verhalten ist von vielen Umgebungsparametern abhängig, beispielsweise, wie schnell gesendet wird, wieviel Zeit im Netzwerk vergeht, ob Segmente unterschiedliche Wege gehen etc.

Verbindungsabbau:

Der Datentransfer ist beendet, also initiiert einen A einen Acitve Close und sendet ein FIN-Segment. B bestätigt und informiert die beteiligte Applikation, daß A die Verbindung geschlossen hat. Diese reagiert mit einer Aufforderung an TCP, ebenfalls ein FIN-Segment zu senden (Segment 19), das von A bestätigt wird. Die Verbindung wurde ordnungsgemäß beendet.

4.1.2.2 Sliding Windows und Fenstergröße

Mit der Angabe der Fenstergröße erfolgt in TCP die Flußsteuerung. TCP arbeitet nach dem Prinzip eines Schiebefensters mit variabler Größe (Sliding Windows). Jede Seite einer Verbindung darf die Anzahl Bytes senden, die im Feld für die Fenstergröße angegeben ist, ohne auf eine Bestätigung der Empfängerseite zu war- ten. Während des Sendens können gleichzeitig Bestätigungen für die von der anderen Seite empfangenen Da- ten eintreffen (diese Bestätigungen können wiederum neue Fenstergrößen einstellen). Eine Fenstergröße von 0 besagt, daß die Bytes bis einschließlich der Acknowledgement-Nummer minus Eins empfangen wurden, der Empfänger momentan aber keine weiteren Daten empfangen kann. Die Erlaubnis zum weiteren Senden von Daten erfolgt durch das erneute Versenden einer Bestätigung mit gleicher Nummer und einer Fenstergröße un- gleich Null. Beispiel:

Das zuletzt empfangene Segment hat bis Byte 39 bestätigt und eine Fenstergröße von 6 Bytes zugelassen. Der Sender schickt drei Bytes (40 - 42):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.4- Sliding Windows

4.1.2.3 Slow-Start-Algorithmus

Solange sich die beiden Enden der Verbindung in demselben lokalen Netzwerk befinden, stellt das unmittelba- re Senden von Segmenten (nach dem Handshake) in der vom Empfänger vorgegebenen Fenstergröße kein Problem dar. Anders verhält es sich bei Verbindungen, die über Router und unterschiedlich schnelle Leitungen ablaufen: Ein Router könnte beispielsweise aufgrund der vielen gesendeten Segmente überlastet werden. Es ist gezeigt worden, daß ein solch „unüberlegter“ Start den Datendurchsatz der Verbindung erheblich negativ be- einflussen kann.

Die Lösung dieses Problems ist der Slow-Start-Algorithmus8 ; er führt eine neues Fenster ein (Congestion Window, kurz cwnd) und läßt sich anhand der folgenden Punkte charakterisieren:

- sende nach dem Verbindungsaufbau erst einmal nur ein einzelnes Segment (cwnd = 1)
- vergrößere für jede erhaltene Bestätigung die Sendeerlaubnis um ein Segment (cwnd ++)
- sende niemals mehr Segmente, als durch die zulässige Fenstergröße des Empfängers erlaubt ist

Wie man leicht erkennt, ist der Zuwachs des Congestion Window exponentiell: Bestätigung des erstes Segments => cwnd = 2; Bestätigungen des zweiten und dritten Segments => cwnd = 4; Bestätigungen des vierten bis siebten Segments => cwnd = 8 usw.

4.2 Behandlung von Timeouts

4.2.1 Congestion-Avoidance-Algorithmus

Der Slow-Start-Algorithmus ist ein zuverlässiges Hilfsmittel, um Überlastungen zu vermeiden. Doch je weiter der Algorithmus fortschreitet, um so größer wird die Wahrscheinlichkeit, daß Router an ihre Grenze stoßen und Datensegmente verloren gehen. Das liegt vor allem am exponentiellen Wachstum der Algorithmus. Probleme können vor allem dann auftreten, wenn Daten von einem „schnellen“ Netzwerk (beispielsweise LAN) auf ein „langsameres“ (beispielsweise WAN) übergehen.

1988 wurde der Congestion-Avoidance-Algorithmus8 eingeführt, der von der Annahme ausgeht, daß Hard- wareschäden (und in der Folge Segmentverluste) nur sehr selten auftreten (in viel weniger als 1% der Verlust- fälle), Routerüberlastungen jedoch sehr viel häufiger. Es gibt zwei Indikatoren, die auf Segmentverluste auf- merksam machen:

- Timeouts
- Empfang von doppelten Bestätigungen

Obwohl der Slow-Start Algorithmus und der Congestion-Avoidance-Algorithmus zwei unterschiedliche Algorithmen sind, lassen sie sich hervorragend kombinieren und sind in der Praxis normalerweise auch gemeinsam implementiert. Es werden zwei Variablen benötigt: Congestion-Window (cwnd) und Slow-Start-Threshold- Size (ssthresh). Folgende Punkte kennzeichnen den neu entstandenen, kombinierten Algorithmus:

- Die Variablen werden mit cwnd = 1 Segment und sstresh = 65535 Bytes initialisiert.
- Wenn ein Engpaß auftritt, wird die Hälfte der aktuellen Fenstergröße, mindestens jedoch 2 Segmente, in ssthresh gespeichert. Ist der Engpaß durch einen Timeout indiziert, wird cwnd auf 1 gesetzt.
- Wenn neue Daten von der Gegenseite bestätigt wurden, wird cwnd erhöht. Um wieviel cwnd wächst, hängt jedoch davon ab, ob TCP einen Slow-Start oder Congestion-Avoidance durchführt. Ist cwnd kleiner oder gleich ssthresh, befindet sich TCP im Slow-Start, der ausgeführt wird, bis die Daten aus sstresh übertragen wurden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.5- Congestion-Avoidance-Algorithmus

Danach tritt Congestion-Avoidance an die Stelle von Slow-Start. Bei Erhalt einer Bestätigung wird cwnd um (Segmentgröße*Segmentgröße /cwnd) vergrößert.

TCP „tastet“ sich also mit Hilfe dieses Algorithmus an die Größe des Fensters heran, bei dem der Fehler verursacht wurde. Weil cwnd ab einer bestimmten Größe (in Abbildung 4.4 wechselt das Verhalten nach cwnd = 8) nicht mehr - wie bei Slow-Start - exponentiell wächst, reagiert TCP insgesamt stabiler.

4.2.2 Fast-Retransmit- / Fast-Recovery-Algorithmus

Bei Empfang einer doppelten Bestätigung wird der Fast-Retransmit- / Fast-Recovery-Algorithmus eingesetzt. TCP nimmt an, daß Segmente vertauscht wurden und veranlaßt deshalb keine Verminderung der aktuellen Sendegeschwindigkeit. Wird dieselbe Bestätigung aber dreimal empfangen, wird angenommen, daß ein Segment verloren ging. Ein erneutes Senden dieses Segments wird sofort veranlaßt, wobei zwar CpngestionAvoidance gestartet, aber kein Slow-Start initiiert wird.

4.2.3 Timer in TCP

TCP soll eine ¹⁵ verläßliche Datenübertragung gewährleisten. Dies geschieht hauptsächlich durch das Bestätigen von empfangenen Segmenten, die aber verloren gehen können. Man hat deshalb vier verschiedene Timer ein- geführt:

a) „Retransmission-Timer“
b) „Persist-Timer“¹⁶
c) „Keepalive-Timer“¹⁷ (nicht Teil des TCP-Standards)
d) „2MSL-Timer“

Der Retransmission Timer

Die Round-Trip-Time (RTT) ist die Zeit, die vom Senden eines Segments bis zum Eintreffen der Bestätigung des Empfängers vergeht. Aus der RTT wird die Retransmission Time gebildet: Retransmission Time = 2*RTT. Bleibt ein ACK innerhalb der Retransmission Time aus, wird die Datenübertragung auf Senderseite ab dem letzten noch nicht quittierten Datensegment wiederholt. Ist der Retransmission Timer kleiner als die RTT, so wird fälschlicherweise eine erneute Übertragung des betroffenen Segments veranlaßt (der Sender geht vom Verlust des Segments aus), was die Netzlast in einer Stausituation noch erhöhen kann. Ist der Retransmission Timer größer als die RTT, so wird zu lange bei einem Segmentverlust gewartet und die Applikation besitzt keine optimale Performance.

Der Persist Timer

Schaltet der Empfänger die Fenstergröße auf Null, weil er im Moment keine weiteren Daten verarbeiten kann, muß er später eine erneute Bestätigung der letzten empfangenen Daten mit einem größeren Empfangsfenster senden, damit die andere Seite mit dem Senden von Daten fortfahren kann. Obgleich TCP über das Bestätigungskonzept eine zuverlässige Übermittlung zuläßt, werden Bestätigungen natürlich selbst nicht von der empfangenden Seite bestätigt. Es kann nun vorkommen, daß eine Bestätigung verloren geht und beide Seiten aufeinander warten. Der Persist Timer verhindert einen solchen Deadlock, indem - falls die Fenstergröße Null istin regelmäßigen Abständen nachgefragt wird, ob nun ein größeres Fenster zur Verfügung steht.

Der Keepalive Timer

Dieser Timer sendet bei Verbindungen ohne aktiven Datenfluß (beispielsweise eine Telnet Applikation, die momentan nicht genutzt wird) in regelmäßigen Abständen Testsegmente, um festzustellen, ob die andere Seite noch existiert, oder ob sie abgeschaltet wurde und kein Verbindungsabbau durchgeführt wurde.

Der 2MSL Timer

Wenn TCP einen Active Close einleitet und die letzte Bestätigung sendet, wird der sogenannte 2MSL (Maximum Segment Lirhindern, daß verspätete Segmente einer vorherigen Verbindung als Teil einer evtl. neuen Verbindung interpretiert wefetime) Timer initiiert, der doppelt so lang ist, wie die von TCP angenommene TTL des IPDatagrams. Der 2MSL Timer soll verden.

4.3 Silly-Window-Phänomen

TCP bedient sich, wie bereits erläutert, eines flexiblen Übertragungsfensters, um Flußkontrolle zu ermöglichen. Gerade dies birgt aber die Gefahr in sich, daß nur sehr kleine Segmente gesendet werden, anstatt eine größere und effizientere Fenstergröße zu nutzen. Dieses Phänomen nennt man Silly-Window-Phänomen. Es kann in zwei Fällen auftreten:

a) Der Empfänger bietet eine kleine Fenstergröße, anstatt zu warten, bis der Empfangspuffer ein größeres Fenster zuläßt.
b) Der Sender sendet kleine Segmente, anstatt zu warten, bis die Senderapplikation mehr Daten zur Verfü- gung gestellt hat.

Beide Seiten der Verbindung müssen also das Problem behandeln können. Der Empfänger darf keine kleinen Übertragungsfenster anbieten sondern muß entweder ein Fenster in der Größe der MSS oder eines in der Größe des halben Empfangspuffers ermöglichen. Der Sender darf solange nicht senden, bis eine der folgenden Vor- aussetzungen erfüllt ist:

a) ein Segment in MSS-Größe kann gesendet werden
b) es kann mindestens ein Segment in der halben vom Empfänger angebotenen Fenstergröße übermittelt werden (kommt nur auf älteren Hosts vor, die die Option der MSS im TCP-Header nicht unterstützen).
c) es werden alle Daten geschickt, wobei entweder keine Empfangsbestätigung erwartet wird, oder der Nagle-Algorithmus für diese Verbindung abgeschaltet wurde.

5. TCP-Zustandsdiagramm

Die folgende Grafik zeigt ein wenig vereinfacht den „Lebenszyklus“ einer TCP-Verbindung, wobei die gestrichelt gezeichneten Pfeile Zustandsübergänge des Servers und die dick gezeichneten Pfeile die Zustandsübergänge des Clients beschreiben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.1 - TCP-Zustandsdiagramm

Erklärung der Zustände:

- LISTEN: Warten auf ein SYN-Segment.
- SYN-SENT: Warten auf eine passende Verbindungsanfrage, nachdem ein SYN-Segment gesendet wurde.
- SYN-RECEIVED: Warten auf Bestätigung, nachdem beide Teilnehmer ein SYN-Segment empfangen und gesendet haben.
- ESTABLISHED: Etablierte Verbindung.
- FIN-WAIT-1: Warten auf ein Beenden der Verbindung der anderen Seite oder auf eine Bestätigung des FIN-Segments, das vorher gesendet wurde.
- FIN-WAIT-2: Warten auf eine Bestätigung der anderen Seite.
- CLOSE-WAIT: Warten auf eine Anfrage der Applikation nach einem Beenden der Verbindung.
- CLOSING: Warten auf eine Anfrage nach einem Beenden der Verbindung durch die andere Seite
- LAST-ACK: Warten auf die Bestätigung desFIN-Segments, das zuvor gesendet wurde

6. Literatur

Allgemeine Literaturangaben im Text sind in eckigen Klammern angegeben und können hier nachgeschlagen werden:

1 W. R. Stevens; „TCP/IP Illustrated, Volume 1 – The Protocols”; Addison-Wesley

2 J. Postel; „Specifications of Internetwork Transmission Control Protocol, TCP Version 4”; September 1978

3 J. Postel; „Transmission Control Protocol”; August 1979

4 J. Postel; „RFC 793: Transmission Control Protocol”; 1. September 1981

5 John Nagle; „RFC 896: Congestion Control in IP/TCP Internetworks“; 6. Januar 1984

6 B. Braden; “RFC 1121: Requirements for Internal Hosts – Communication Layers”; 1. Oktober 1989

7 Borman, Braden, v. Jacobsen; „TCP Extensions for High Performance“; 13. Mai 1992

8 W. R. Stevens; “RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit / Recovery Algorithms”; Januar 1997

9 Thomas Riemer; „Well Known Port Numbers“; http://www.con.wesleyan.edu/~triemer/network/docservs.html

Internet:

- RFC (Request For Comments):

Ein RFC ist ein Papier, das sich in irgendeiner Form mit Verfahren, die im Internet verwendet werden, beschäftigt. Dabei kann es sich um einen Verbesserungsvorschlag oder eine Anmerkung für ein bestehendes Verfahren handeln oder einem Vorschlag zu einem neuen Verfahren. Ein Vorschlag zu einem neuen Verfahren kann nach Prüfung dann zu einem Standard erklärt werden. Jedem vorgeschlagenen Standard wird eine Nummer zugeordnet. URL: http://www.cis.ohio-state.edu/hypertext/information/rfc.html

(Ohio State University; Computer and Information Science)

- Interaktive Simulation des Verhaltens von TCP bei Fehlern und Verzögerungen: http://www.tu-darmstadt.de/fb/et/ipsk/student/ps_alg/tcp

(TH Darmstadt; Fachgebiet Industrielle Prozeß- und Systemkommunikation)

- Einführung in TCP/IP:

http://www.rvs.uni-bielefeld.de/~heiko/tcpip Heiko Holtkamp (Universität Bielefeld)

Abbildungsnachweis:

Abbildung 4.2:

Andreas Sons; „Vortrag 5: TCP (II)“; 24. November. 1998

http://www.informatik.uni-hamburg.de/TKRN/world/events/ws9899/iprn/TCPII_folien.pdf

Abbildungen 4.1, 4.3, 5.1:

W. R. Stevens; „TCP/IP Illustrated, Volume 1 - The Protocols”; Addison-Wesley

[...]

---

¹ [1], Kap. 17.2; S. 223 ff

² Kapitel 4.2.3

³ Kapitel 4.1

⁴ Kapitel 4.1.2.3

⁵ Kapitel 3.2.2

⁶ Kapitel 3.1

⁷ Kapitel 3.2.1

⁸ Kapitel 3.3

⁹ Kapitel 2.2.2

¹⁰ Kapitel 3.2.1

¹¹ Kapitel 4.2.3

¹² Kapitel 5

¹³ [1], Kap. 19; S. 263 ff

¹⁴ [1], Kap. 20; S. 275 f

¹⁵ [1], Kap. 21; S. 297 ff

¹⁶ [1], Kap. 22; S. 323 ff

¹⁷ [1], Kap. 23; S. 331 ff