Wikipedia

Transmission Control Protocol

Vereinbarung darüber, wie Daten zwischen Computern ausgetauscht werden
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 19. Juni 2006 um 13:29 Uhr durch 84.58.26.216 (Diskussion) (→Allgemeines). Sie kann sich erheblich von der aktuellen Version unterscheiden.
TCP (Transmission Control Protocol)
Familie: Internetprotokollfamilie
Einsatzgebiet: Zuverlässiger bidirektionaler
Datentransport
TCP im TCP/IP-Protokollstapel
Anwendungsschicht FTP SMTP DNS ...
Transportschicht TCP UDP ...
Vermittlungsschicht IP
Netzzugangsschicht Ethernet Token
Ring 		FDDI ...
Standards:

RFC 793 (1981)
RFC 1323 (1992)

Das Transmission Control Protocol (TCP) ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Alle Betriebssysteme moderner Computer beherrschen TCP und nutzen es für den Datenaustausch mit anderen Rechnern. Das Protokoll ist ein zuverlässiges, verbindungsorientiertes Transportprotokoll in Computernetzwerken. Es ist Teil der Internetprotokollfamilie, der Grundlage des Internets.

Entwickelt wurde TCP von Robert E. Kahn und Vinton G. Cerf. Ihre Forschungsarbeit, die sie im Jahre 1973 begannen, dauerte mehrere Jahre. Die erste Standardisierung von TCP erfolgte deshalb erst im Jahre 1981 als RFC 793. Danach gab es viele Erweiterungen, die bis heute in neuen RFCs, einer Reihe von technischen und organisatorischen Dokumenten zum Internet, spezifiziert werden, und alle zu TCP gehören.

Im Unterschied zum verbindungslosen UDP (User Datagram Protocol), stellt TCP einen virtuellen Kanal zwischen zwei Endpunkten einer Netzwerkverbindung (Sockets) her. Auf diesem Kanal können in beide Richtungen Daten übertragen werden. TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf, weshalb häufig (und oft nicht ganz korrekt) auch vom „TCP/IP-Protokoll“ die Rede ist. Es ist in Schicht 4 des OSI-Referenzmodells angesiedelt.

Aufgrund seiner vielen angenehmen Eigenschaften – Datenverluste werden erkannt und automatisch behoben, Datenübertragung ist in beiden Richtungen möglich, Netzwerküberlastung wird verhindert, und viele andere mehr – ist TCP ein sehr weit verbreitetes Protokoll zur Datenübertragung. Beispielsweise wird TCP als (fast) ausschließliches Transportmedium für das WWW, E-Mail, Daten in Peer-to-Peer-Netzwerken und viele andere populäre Netzwerkdienste verwendet.

Allgemeines

Datei:Tcp soft.png
Abb. 1
 
Abb. 2: Verwaltung der TCP-Verbindungen als endlicher Automat

TCP ist im Prinzip eine Ende-zu-Ende-Verbindung in Vollduplex, welche die Übertragung der Informationen in beide Richtungen zu gleicher Zeit zulässt. Diese Verbindung kann in zwei Halbduplex-Verbindungen, bei denen Informationen in beide Richtungen (allerdings nicht gleichzeitig) fließen können, eingeteilt werden. Die Daten in Gegenrichtung können dabei zusätzliche Steuerungsinformationen enthalten. Das Management dieser Verbindung sowie die Datenübertragung wird von der TCP-Software übernommen, wie in Abb. 1 dargestellt. Die TCP-Software ist eine Funktionssammlung und (je nach Betriebssystem unterschiedlich) beispielsweise bei Microsoft Windows in extra einzubindenden Programmbibliotheken Winsock.dll beziehungsweise der wsock32.dll oder bei Linux auch im Betriebssystemkern, dem Linux-Kernel, angesiedelt. Anwendungen, die diese Software häufig nutzen, sind zum Beispiel Webbrowser und Webserver.

Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert. Ein Endpunkt stellt ein geordnetes Paar bestehend aus IP-Adresse und Port dar. Ein solches Paar bildet eine bi-direktionale Software-Schnittstelle, und wird auch als Socket bezeichnet. Mit Hilfe der IP-Adressen werden die an der Verbindung beteiligten Rechner identifiziert; mit Hilfe der Ports werden dann auf den beiden beteiligten Rechnern die beiden miteinander kommunizierenden Programme identifiziert. Durch die Verwendung von Portnummern auf beiden Seiten der Verbindung ist es beispielsweise möglich, dass ein Webserver auf einem Port (normalerweise Port 80) gleichzeitig mehrere Verbindungen zu einem anderen Rechner geöffnet haben kann. Die Ports sind 16-Bit-Zahlen (Portnummern) und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert (englisch: well known ports[1]) und werden von der IANA vergeben, z. B. ist Port 80 für das im WWW verwendete HTTP-Protokoll reserviert. Allerdings ist das Benutzen der vordefinierten Ports nicht bindend. So kann jeder Administrator einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen anderen Port laufen lassen.

Verbindungsaufbau und -abbau

Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen). Dies wird als passive open oder auch als listen bezeichnet.

Will ein Client eine Verbindung aufbauen, generiert er einen eigenen Endpunkt aus seiner Rechneradresse und einer noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden.

Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten.

Während des Abbaus kann die Gegenseite noch Daten übertragen, die Verbindung kann also halb-offen sein.

Der Drei-Wege-Handshake

Drei-Wege-Handshake ist die Bezeichnung für ein bestimmtes Verfahren, um eine in Bezug auf Übertragungsverluste sichere Datenübertragung zwischen zwei Instanzen zu ermöglichen. Obwohl überwiegend in der Netzwerktechnik verwendet, ist der Drei-Wege-Handshake nicht auf diese beschränkt

Verbindungsaufbau

 
Abb. 3: TCP-Handshake

Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung aufbauen will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Die Sequenznummern sind dabei für die Sicherstellung einer vollständigen Übertragung in der richtigen Reihenfolge und ohne Duplikate wichtig. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die Start-Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt.

Die Gegenstelle (siehe Skizze) empfängt das Paket und sendet in einem eigenen SYN-Paket im Gegenzug ihre Start-Sequenznummer y. Zugleich bestätigt sie den Erhalt des ersten SYN-Pakets, indem sie die Sequenznummer um den Wert Eins erhöht und x+1 im ACK-Teil des Headers zurückschickt.

Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung ist damit aufgebaut.

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

Verbindungsabbau

Datei:Tcp-teardown.png
Abb. 4: TCP-Teardown

Der geregelte Verbindungsabbau erfolgt ähnlich. Statt des SYN-Bits kommt das FIN-Bit (Fin für Finish) zum Einsatz, welches anzeigt, dass keine Daten mehr vom Sender kommen. Der Erhalt des Pakets wird wiederum mittels ACK bestätigt. Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird.

Obwohl eigentlich vier Wege genutzt werden, handelt es sich beim Verbindungsabbau auch um einen Drei-Wege-Handshake, da die ACK- und FIN-Operationen vom Server zum Client als ein Weg gewertet werden. Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden. Die 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 2MSL langen Wartezyklus (Waitstate). Im 2MSL Waitstate muss die Verbindung 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. 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.

Aufbau des TCP-Headers

Allgemeines

Das TCP-Segment besteht immer aus zwei Teilen – dem Header und der Nutzlast (Payload). Die Nutzlast enthält die zu übertragenden Daten, die wiederum Protokollinformationen der Anwendungsschicht wie HTTP oder FTP entsprechen können. Der Header enthält für die Kommunikation erforderliche Daten, sowie das Dateiformat beschreibende Information. Den schematischen Aufbau des TCP-Headers kann man im Bild rechts sehen. Die Werte werden in network byte order (big endian) angegeben.

Erläuterung

Datei:Tcp header.png
Abb. 5: Aufbau des TCP-Headers
Source Port
Gibt die Portnummer auf der Senderseite an.
Destination Port
Gibt die Portnummer auf der Empfängerseite an.
Sequence Number
Sequenznummer des ersten Daten-Oktetts (Byte) dieses TCP-Paketes 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.
Acknowledgment Number (Quittierungsnummer)
Sie gibt die Sequenznummer an, die der Sender dieses TCP-Segmentes als nächstes erwartet. Sie ist nur gültig, falls das ACK-Flag gesetzt ist.
Data Offset
Länge des TCP-Headers in 32-Bit-Blöcken – ohne die Nutzdaten (Payload). Hiermit wird die Startadresse der Nutzdaten angezeigt.
Reserved
Das Reserved-Feld wird nicht verwendet und muss null sein.
Control-Flags

sind zweiwertige Variablen, mit den möglichen Zuständen gesetzt und nicht gesetzt, welche 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.

URG
Ist das Urgent-Flag (Urgent = Dringend) gesetzt, so werden die Daten, auf die das Urgent Pointer-Feld zeigt, sofort von der Anwendung bearbeitet. Dabei unterbricht die Anwendung alle anderen Aufgaben. Dieses Verfahren ist fern verwandt mit einem Softwareinterrupt. Dieses Flag kann zum Beispiel verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen.
ACK
Das Acknowledgment-Flag hat in Verbindung mit dem Acknowledgment-Feld folgende Aufgaben. Einmal dient es, in Verbindung mit dem ACK- und SYN-Flag, zur Bestätigung beim Drei-Wege-Handshake und zweitens zur Bestätigung von TCP-Segmenten beim Datentransfer. Das Acknowledgment-Feld ist nicht gültig, wenn das Flag nicht gesetzt ist.
PSH
Das Push-Flag hat die Aufgabe, die Daten unter Umgehung des Buffers, eines Speichers für die Zwischenlagerung von Daten, sofort an die Anwendung weiterzuleiten. 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 Buffer zwischengespeichert werden, so würde dieser (stark) verzögert abgearbeitet werden.
RST
Das Reset-Flag wird verwendet, wenn eine Verbindung abgebrochen werden soll. Dies geschieht zum Beispiel bei technischen Problemen oder zur Abweisung von unerwünschten Verbindungen.
SYN
Pakete mit gesetztem SYN-Flag initiieren eine Verbindung, d. h. beginnen den Drei-Wege-Handshake. 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 Finish-Flag 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.
Window
Ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgmentfeld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen.
Checksum
Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird über den Header und die Daten berechnet.
Urgent Pointer
Zusammen mit der Sequenz-Nummer gibt dieser Wert die genaue Position der Daten im Datenstrom an. Der Wert ist nur gültig, wenn das URG-Flag gesetzt ist.
Options
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 Null-Bits 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

Datei:Tcp daten.png
Abb. 6: Segmentierung der Nutzdaten

TCP/IP-Paket-Größe

Ein TCP-Segment hat typischerweise eine Größe von 1500 Bytes. Es darf nur so groß sein, dass es in die darunter liegende Übertragungsschicht passt, das Internetprotokoll IP. Das IP-Paket ist theoretisch bis 65535 Bytes (64 kB) spezifiziert, wird aber selbst meist über Ethernet übertragen, und dort ist die Rahmengröße auf 1500 Bytes festgelegt. TCP und IP Protokoll definieren jeweils einen Header von 20 Bytes Größe. Für die Nutzdaten bleiben in einem TCP/IP-Paket also 1460 Bytes übrig. Da die meisten Internet-Anschlüsse DSL verwenden, gibt es dort noch das Point-to-Point Protocol (PPP) zwischen IP und Ethernet, was nochmal 8 Bytes für den PPP-Rahmen kostet. Dem TCP/IP-Paket verbleiben im Ethernet-Rahmen nur 1492 Bytes MTU, die Nutzdaten reduzieren sich auf insgesamt 1452 Bytes MSS. Dies entspricht einer Auslastung von 96,8 %.

Aufteilen der Anwendungsdaten auf TCP/IP-Pakete

Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der MSS. Die Anwendung, die Daten versenden möchte, beispielsweise ein Webserver, legt zum Beispiel einen 10 Kilobyte großen Datenblock im Buffer ab. Um beispielsweise mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten zu versenden, teilt man die Daten auf mehrere Pakete auf, fügt einen TCP-Header hinzu und versendet die TCP-Segmente. Dieser Vorgang wird Segmentierung genannt. Im Puffer ist der Datenblock, dieser wird in fünf Segmente aufgeteilt (siehe Abb. 6). Jedes Segment erhält durch die TCP-Software einen TCP-Header. Drei TCP-Segmente wurden aktuell abgeschickt. Diese sind nicht geordnet, da im Internet jedes TCP-Segment einen anderen Weg nehmen und es dadurch zu Verzögerungen kommen kann. Damit die TCP-Software im Empfänger die Segmente wieder ordnen kann, ist jedes Segment "nummeriert" (die Segmente werden sozusagen gezählt). Bei der Zuordnung der Segmente wird die Sequenznummer herangezogen.

 
Abb. 7: Beispiel eines Datentransfers

Der Empfänger muss TCP-Segmente, die einwandfrei (Prüfsumme ist in Ordnung) angekommen sind, bestätigen.

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 Byte 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, 2, 3, 4, 5 so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3, weil es verloren gegangen 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. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt, einen Timer (RTT).

Flusssteuerung

Datei:Sliding window.png
Abb. 8: Sliding Window

Da die Anwendung Daten aus dem Buffer liest, ändert sich der Füllstand des Buffers 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 Buffer 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 Buffer 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. Ausnahme sind jedoch TCP-Segmente mit gesetztem URG-Flag. Mit dem 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 Buffer. Die Anwendung des Empfängers liest nun die Segmente 1–5 aus dem Buffer, 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 Buffer voll ist. Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Buffer. Der Empfänger schickt ein 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 Buffer 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 Buffer. Der Empfänger schickt wieder ein 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 senden und solange mit dem Window Update warten soll, bis die Anwendung mindestens die maximale Segmentgröße (Maximum Segmentsize, in unseren bisherigen Beispielen 1460 Byte) aus dem Buffer gelesen hat oder der Buffer 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.

Slow-Start

Zu Beginn einer Datenübertragung dient der Slow-Start-Algorithmus zur Bestimmung des Congestion Windows (wörtlich: Überlast-Zeitfenster), um einer möglichen Überlastsituation vorzubeugen. Man möchte Stau vermeiden, und da die momentane Auslastung des Netzes nicht bekannt ist, wird mit zunächst kleinen Datenmengen begonnen. Der Algorithmus startet mit einem kleinen Zeitfenster von zwei MSS, in dem Datenpakete vom Sender zum Empfänger übertragen werden. Der Empfänger sendet nun eine Bestätigung (Acknowledgement, ACK) an den Sender zurück. Anschließend wird die Größe des Congestion Windows um eine Segmentgröße erhöht. Für jede weitere Bestätigung wird dieses wieder um eine Segmentgröße erhöht, das Limit ist das vom Empfänger festgelegte Empfangsfenster (siehe Flusssteuerung). Das Wachstum des Fensters ist in der Regel exponentiell, also erst langsam, dann schnell, daher der Name Slow-Start.

Überlastkontrolle

Gehen bei einer bestimmten Fenstergröße Pakete verloren, kann das festgestellt werden, wenn der Sender innerhalb einer bestimmten Zeit (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 diesen aufzulösen, müssen alle beteiligten Sender ihre Netzlast reduzieren. Wird ein Paketverlust festgestellt, so wählt man die Hälfte der noch unbestätigten Daten im Netz als geeignetes Zeitfenster für die Datenübertragung zwischen diesem Sender und diesem Empfänger über den benutzten Kanal. Das verlorene Paket wird erneut übertragen, für jede Bestätigung wird die Sendefenstergröße wieder um eine MSS erhöht wie beim Slow-Start.

Fast-Retransmit und Fast-Recovery 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). Der Sender bemerkt die duplizierten Bestätigungen und nach dem dritten Duplikat sendet er sofort, vor Ablauf des Timer, das verlorene Paket erneut. Weil nicht auf den Ablauf des Timer 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.

Bis zum Erkennen des Paketverlust wurden noch weitere Pakete bis zur Sendefenstergröße übertragen. Der Empfänger konnte diese nicht nutzen, weil ein Paket der Serie verloren ging, aber er kann sie im Puffer halten; nach der Neuübertragung des verlorenen Pakets durch den Sender bestätigt der Empfänger mittels ACK und einer höheren Sequenznummer die nun vollständige Paketfolge. Das erspart dem Sender, alle nach dem Paketverlust übertragenen Pakete erneut zu übertragen und er kann sofort mit ganz neuen Paketen fortfahren, man nennt das kumuliertes ACK.

Selective Acks werden genutzt, um noch mehr Kontrollinformationen über den Datenfluss vom Empfänger an den Sender zurückzuschicken. Dabei wird nach einem Paketverlust vom Empfänger in die Dup-Acks für die Pakete außer der Reihe die Anzahl der momentan zwischengespeicherten Pakete eingefügt. Damit erfährt der Sender genauer, welche Pakete bereits angekommen sind und welche fehlen. Die Information wird in einem TCP-Options-Feld des Header bereitgestellt. Bestätigt sind die Pakete aber weiterhin erst, wenn der Empfänger dem Sender ein ACK für die Pakete übermittelt hat.

Aufbau und Funktion des TCP Pseudo-Headers

Datei:Pseudo header.png
Der Aufbau des TCP-Pseudo-Headers

Der Pseudo-Header wird zur Prüfsummenberechnung verwendet und dient daher zur Erhöhung der Zuverlässigkeit. Es ist dadurch auch möglich, fehlgeleitete Pakete zu erkennen. In die Berechnung fließen außerdem noch der TCP-Header und seine Nutzdaten (TCP-Segment) ein. Bevor die TCP-Software ein TCP-Segment abschickt, bildet sie einen Pseudo-Header aus der IP-Adresse des Senders und des Empfängers sowie der TCP-Segment-Länge. Vor Berechnung der Prüfsumme wird das Checksum-Feld im TCP-Header auf Null gesetzt und es wird dem Nutzdatenfeld ein Null-Byte angehängt, wenn die Länge eine ungerade Zahl ist. Die Berechnung der Prüfsumme erfolgt durch Addition von 16 Bit-Werten im Einerkomplement. Aus der Summe wird noch einmal das Einerkomplement gebildet. Nach der Berechnung wird das 16 Bit-Ergebnis im TCP-Header abgelegt und das TCP-Segment abgeschickt. Der Empfänger führt diese Berechnung noch einmal unter Einbezug der Prüfsumme aus, wodurch das Ergebnis Null sein sollte. Ist die Prüfsumme beim Empfang des TCP-Segmentes nicht Null, so wird es ohne Nachricht verworfen. Dies hat zur Folge, dass der RTT-Timer beim Absender abläuft und das TCP-Segment nochmal abgeschickt wird.

Source IP Address
IP-Adresse des Absenders.
Destination IP Address
IP-Adresse des Empfängers.
00000000
Füllbits.
Protocol
Hat immer den Wert Sechs für das TCP-Protokoll (siehe auch IP-Header).
TCP Length
Länge des TCP-Segments in Bytes.

Datenintegrität und Zuverlässigkeit

Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten. Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können. TCP wurde entwickelt, um mit der Unsicherheit der darunter liegenden Schichten umzugehen. Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher. Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft. Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen.

Der Datentransfer kann selbstverständlich jederzeit nach dem „Aufbau einer Verbindung“ gestört, verzögert oder ganz unterbrochen werden. Das Übertragungssystem läuft dann in einen Timeout. Der vorab getätigte „Verbindungsaufbau“ stellt also keinerlei Gewähr für eine nachfolgende, dauerhaft gesicherte Übertragung dar.

Bestätigungen

Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (Windowing). Dadurch ist das Ausnutzen der Netzwerk-Bandbreite auch bei großen Strecken möglich. Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten Acknowledges (ACK) aus technischen Gründen bisweilen mehrere 100 ms, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden. Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft. Alle Pakete im Puffer können gemeinsam bestätigt werden. Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (Piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält.

Weitere Protokolleigenschaften

Über ein Dringlichkeitsbit (Urgent) können Daten als vorrangig gekennzeichnet werden. Dadurch ist beispielsweise die bevorzugte Behandlung von CTRL-C (Abbruch) bei einer Terminalverbindung (TELNET) möglich.

Um Bandbreite zu sparen, wird auf der TCP Ebene meistens der Nagle-Algorithmus eingesetzt.

Problematik der Datenwiederholung

Die Wiederholung von Daten, für die noch keine Bestätigung empfangen wurde, ist nicht unproblematisch. Im Internet, in dem viele Netzwerke 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 IP-Netzwerk ständig beobachtet. Abhängig von der Verlustrate wird die Senderrate durch geeignete 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 im Wesentlichen dann dort. Eine Überbelastung wird vermieden.

Literatur

Quellen

  1. ↑ IANA: Port numbers

Vorlage:Exzellent Wiederwahl

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Transmission_Control_Protocol&oldid=18044015“