TCP-Kommunikation
Als verbindungsorientiertes Protokoll ist TCP für den Verbindungsaufbau und Verbindungsabbau zwischen zwei Stationen einer Ende-zu-Ende-Kommunikation zuständig. Obwohl es sich eher um eine virtuelle Verbindung handelt, stehen Sender und Empfänger während der Verbindungständig in Kontakt zueinander. Der Empfänger bestätigt dem Sender jedes empfangene Datenpaket. Trifft keine Bestätigung beim Absender ein, wird das Paket noch mal verschickt.
Verbindungsaufbau (Connection Establishment)
Der Verbindungsaufbau läuft nach dem Three-Way-Handshake ab. Zuerst schickt der Client an den Server einen Verbindungswunsch (SYN). Der Server bestätigt den Erhalt der Nachricht (ACK) und äußert ebenfalls seinen Verbindungswunsch (SYN). Der Client bestätigt den Erhalt der Nachricht (ACK). Danach erfolgt der Datenaustausch zwischen Client und Server.
Datenaustausch (Data Transfer)
Der Sender beginnt mit dem Senden des ersten Datenpakets (Send Paket 1). Der Empfänger nimmt das Paket entgegen (Receive Paket 1) und bestätigt den Empfang (Send ACK Paket 1). Der Sender nimmt die Bestätigung entgegen (Receive ACK Paket 1) und sendet das zweite Datenpaket (Send Paket 2). Der Empfänger nimmt das zweite Paket entgegen (Receive Paket 2) und bestätigt den Empfang (Send ACK Paket 2). Der Sender nimmt die zweite Bestätigung entgegen (Receive ACK Paket 2).
Und so läuft der Datenaustausch weiter, bis alle Pakete übertragen wurden.
Hinweis: In der Praxis werden immer mehrere Pakete auf einmal geschickt und dann auf die Acknowledgements gewartet und dann wieder mehrere Pakete auf einmal.
Fehlerbehandlung (Error Detection)
Um festzustellen, ob Datenpakete ankommen, wird ein Timer gesetzt. Läuft der Timer ab, dann muss der Sender das Datenpaket noch mal schicken.
Im Prinzip läuft die Kommunikation wie gewohnt. Der Sender beginnt mit dem Senden des ersten Datenpakets (Send Paket 1). Gleichzeitig setzt er einen Timer. Bekommt er die Bestätigung (Send ACK Paket 1) des Empfängers, dann sendet er das zweite Paket. Läuft der Timer jedoch ab, dann geht der Sender von einem Paketverlust aus und sendet das Datenpaket noch mal (Send Paket 1).
Verbindungsabbau (Connection Termination)
Der Verbindungsabbau kann sowohl vom Client als auch vom Server vorgenommen werden. Zuerst schickt einer der beiden der Gegenstelle einen Verbindungsabbauwunsch (FIN). Die Gegenstelle bestätigt den Erhalt der Nachricht (ACK) und schickt gleich darauf ebenfalls einen Verbindungsabbauwunsch (FIN). Danach bekommt die Gegenstelle noch mitgeteilt, dass die Verbindung abgebaut ist (ACK).
TCP-Flags zur Steuerung der Kommunikation
| Bezeichnung | Flag | Beschreibung |
|---|---|---|
| Urgent-Pointer | URG | Ist das URG-Flag gesetzt wird das Urgent-Pointer-Feld ausgewertet. Ein solches Datenpaket ist keiner Anwendung zugeordnet. Es hat eine besondere Priorität. |
| Acknowledgement | ACK | Da sich die Acknowledgement-Nummer nicht bei jedem Datenpaket ändert, kennzeichnet ein gesetztes ACK-Flag die Gültigkeit der Acknowledgement-Nummer. |
| Push | PSH | TCP puffert einzelne Datenpakete bis eine größere zusammenhängende Datenmenge vorhanden ist. Ist das PSH-Flag gesetzt, wird dieses Paket sofort an den TCP-Port weitergeleitet. |
| Reset | RST | Ist ein Abbruch der TCP-Verbindung notwendig, wird das RST-Flag gesetzt. Es kommt auch zum Einsatz, wenn eine TCP-Verbindung abgewiesen wird. |
| Syncronization | SYN | Das SYN-Flag wird gesetzt, wenn zwischen Sender und Empfänger eine Verbindung aufgebaut werden soll. |
| Final-Flag | FIN | Sind zwischen zwei Stationen alle Daten übertragen, senden beide Stationen ein TCP-Paket mit gesetztem FIN-Flag. Danach gilt die TCP-Verbindung als beendet. |
Flusssteuerung (Flow Control)
In der Literatur findet man häufig auch die Bezeichnung Flusskontrolle, was von der Übersetzung von "Flow Control" herrührt. Allerdings wird das englische "control" üblicherweise nicht in "Kontrolle", sondern in "Steuerung" übersetzt. Eine "Flusskontrolle" würde nur Werte ermitteln und vergleichen. Die Übersetzung "Flusssteuerung" trifft den Mechanismus hinter "Flow Control" viel besser, weil er aktiv in die Datenübertragung eingreift. Das besondere daran ist, dass die Steuerung in den Endgeräten stattfindet und nicht zentral gesteuert und geregelt wird.
Eine Daten-Flusssteuerung ist deshalb notwendig, weil es im Internet für eine Ende-zu-Ende-Verbindung keinen exklusiven Kanal mit fester Übertragungsgeschwindigkeit gibt. Eine Verbindung im Internet ist immer nur so schnell, wie es die einzelnen Teilstücke der Kommunikationsverbindungen zwischen Netze und Router zulassen.
Die Flusssteuerung passt sich also an die maximal mögliche Übertragungsgeschwindigkeit an. Dazu passt der Algorithmus der Flusssteuerung die Anzahl der zusammen verschickten Datenpakete an die verfügbare Bandbreite und die Netzauslastung an.
Die Flusssteuerung erhöht nach dem Verbindungsaufbau die Anzahl der gleichzeitig verschickten Datenpakete kontinuierlich, bis irgendwo auf dem Weg zum Empfänger Pakete verloren gehen. TCP reagiert dann umgehend mit der Halbierung der gleichzeitig verschickten Pakete. Die Flusssteuerung basiert also auf den Empfangsbestätigungen durch den Empfänger.
Windows-Size
TCP arbeitet mit einer Windows-Size von etwa 64 kByte. Doch die Datenpakete können nur mit einer bestimmten Maximalgeschwindigkeit transportiert werden. Nach jedem Paket wartet TCP beim Sender auf ein ACK (Bestätigung) vom Empfänger. In dieser Zeit ist die Verbindung ungenutzt. Im ungünstigsten Fall wartet TCP länger auf die Bestätigung als die Datenübertragung dauert.
Um das zu vermeiden, wird die Windows-Size so groß gewählt, dass die ungenutzte Zeit möglichst klein ist. Dabei steigt jedoch das Risiko, dass bei einem Datenverlust, ein Datenpaket noch mal übertragen werden muss.
Um die Wartezeiten zwischen Datenpaketen, Bestätigungen und nächsten Datenpaketen zu reduzieren, werden mehrere Datenpakete zusammen hintereinander verschickt (Sliding Window). Die Bestätigungen treffen dann mit Verzögerung ein. Weitere Datenpakete werden aber nur dann verschickt, wenn auch vorhergehende Datenpakete bestätigt wurden.
Überlaststeuerung (Congestion Control)
Die an der Datenübertragung beteiligten Kommunikationspartner, in der Regel Client und Server, wissen nicht, wie viel Übertragungskapazität auf der Übertragungsstrecke zur Verfügung steht. Im Prinzip geht es darum, die maximale Kapazität auszuschöpfen. Das erfolgt über die indirekte Flusssteuerung von TCP. Allerdings geht es auch darum, die Verbindung nicht zu überlasten, um dadurch entstehende Übertragungsfehler zu vermeiden.
Bei der Flusssteuerung von TCP regelt der Sender die Übertragungsgeschwindigkeit durch variable Paketmengen, die zusammen losgeschickt werden. Man spricht dabei vom Sendefenster (Congestion Window). Der Anfangswert liegt bei der maximal zulässigen Nutzdatengröße eines IP-Pakets (MSS, Maximum Segment Size), der vom IP-Stack laufend ermittelt wird.
Anfangs ist das Sendefenster klein, also wenige Pakete (Slow Start). Mit jeder eintreffenden Empfangsbestätigung vergrößert der Sender das Congestion Window um das doppelte. Bis zum ersten Paketverlust. Dann geht der Sender von einem Übertragungsfehler aus und halbiert die Paketanzahl. Das heißt, er verkleinert das Congestion Window. Dabei verringert sich natürlich auch die Übertragungsgeschwindigkeit der Verbindung.
Während der weiteren Übertragung vergrößert der Sender das Congestion Window bei jeder Empfangsbestätigung nur noch um eine MSS-Größe, bis die Empfangsbestätigungen ausbleiben (Saturierungspunkt). Dann wird das Congestion Window wieder halbiert. Danach beginnt die lineare Erhöhung erneut.
Der Sender legt also anhand der eingehenden Empfangsbestätigungen das Sendefenster (Congestion Window) fest. Gleichzeitig kann aber auch der Empfänger festlegen, wie viele unquittierte Pakete unterwegs sein dürfen (Receive Window, RWIN). Damit verhindert der Empfänger, dass der Sender ihn mit Paketen flutet und deswegen Pakete verloren gehen. Da Pakete unterschiedlich groß sein können, ist RWIN keine Paketanzahl, sondern stellt die maximale Größe in Byte dar, die der Empfänger verarbeiten kann. Wenn er mit der Annahme der Datenpakete nicht hinterherkommt, kann er dem Sender auch einen kleineren RWIN-Wert mitteilen. Hat der Sender das Limit erreicht, darf er erst weitersenden, wenn er die Empfangsbestätigungen der bereits gesendeten Pakete erhalten hat. Ist der Engpass beim Empfänger abgebaut, kann er den RWIN wieder erhöhen.
Während einer längeren Übertragung wird sich das Congestion Window immer am Receive Window (RWIN) des Empfängers orientieren. Der Wert ist im wesentlichen von der Größe des Pufferspeichers abhängig. Je mehr Verbindungen offen sind, desto größer muss der Pufferspeicher sein.
Die Größe des RWIN leitet sich allerdings hauptsächlich von der Latenz der Verbindung ab. Die Latenz ist die Dauer vom Absenden eines Pakets bis zum Eintreffen der Bestätigung. Man bezeichnet das auch als Roundtrip Time (RTT) oder Ping-Zeit. Je größer die RTT, desto größer muss das Congestion Window sein, um die Übertragungskapazität auszuschöpfen. In der Regel kümmern sich die Betriebssysteme darum, dass dieser Wert optimiert wird.
Bufferbloat
Die Flusssteuerung funktioniert gut, wenn einzelne Anwendungen Daten übertragen oder die Übertragungsstrecke nur von wenigen Teilnehmer genutzt wird. Nun ist es aber so, dass eine Übertragungsstrecke von mehreren Anwendungen und Teilnehmern gleichzeitig genutzt wird, weshalb für jede Verbindung die Übertragungskapazität nur für eine bestimmte Zeit zur Verfügung steht. Erschwerend kommt hinzu, dass der Paketversand unkoordiniert erfolgt. Dabei kommt es vor, dass sehr viele Pakete gleichzeitig bei einem Router oder Gateway ankommen.
Können Router und Gateways eingehende Datenpakete nicht sogleich weiterleiten, dann müssen sie diese verwerfen, was zu Paketverlusten führt und wiederholte Übertragungen notwendig machen würde. Das verzögert nicht nur die Datenübertragung erheblich, sondern drückt auch die mögliche Nutzdatenrate, weil viele Datenpakete doppelt übertragen werden müssen.
Damit die Datenpakete nicht verloren gehen, kommen sie in einen Puffer und müssen dort warten. Dadurch werden kurzfristige Spitzen abgefangen und die Übertragungskapazität gleichmäßig verteilt.
Die Puffer, die in jedem Router oder Gateway enthalten sind, nehmen eine Verzögerung in kauf, um Paketverluste und damit Doppelsendungen zu vermeiden. Das führt dazu, dass Datenpakete später und dadurch auch die Bestätigungen später beim Sender ankommen. Das bremst die Erhöhung der Paketanzahl und verhindert natürlich auch eine größere Übertragungsrate. Allerdings verhindert es Paketverluste und dadurch wiederholte Paketsendungen (Retransmissions). Die Paketverluste bleiben begrenzt und die Nutzdatenrate ist so groß wie möglich.
In den Puffern entstehen Warteschlangen, auch Queue genannt, die länger werden, je größer ein Puffer ist. Doch je größer der Puffer, desto länger wird die Warteschlange und die Wartezeit für die Pakete steigt, was die Latenz erhöht. Für manche Anwendungen ist das ein Problem.
Wenn die Wartezeit zu lange ist, dann geht TCP von einem Paketverlust aus und reduziert das Sendefenster. Die Flusssteuerung von TCP kann aber nur dann das Sendefenster nach oben optimieren (Übertragungsgeschwindigkeit erhöhen und dadurch die Übertragungskapazität ausnutzen), wenn Paketverluste ausbleiben. In so einem Fall ist der Puffer kontraproduktiv.
Diesen Effekt nennt man Bufferbloat. Er führt dazu, dass die Nutzdatenrate auf einen Bruchteil der möglichen Übertragungskapazität zusammenbricht.
Deshalb werden eher kleine Puffer empfohlen, damit die Flusssteuerung effektiver funktionieren kann. Allerdings besteht dann die Gefahr, dass es zu mehr Paketverlusten kommt. Zu klein dürfen die Puffer also nicht sein. Je kleiner ein Puffer, desto höher die Paketverluste und desto geringer die Saturierung (Auslastung).
Ganz ohne Puffer geht es aber auch nicht. Denn dann müssten viel mehr Datenpakete verworfen werden, was viel mehr auf die Übertragungsrate drücken würde als nur ein paar verzögerte Pakete. Für UDP sind Puffer noch viel wichtiger, weil hier keine Sendewiederholung vorgesehen ist.
Die Flusssteuerung und die Puffer regeln also die Übertragungsgeschwindigkeit der einzelnen TCP-Verbindungen unter laufend wechselnden Bedingungen, die sich durch andere TCP-Verbindungen ergeben. Wenn es irgendwo eng wird entstehen Warteschlangen, die abgebaut werden, wenn sich die Lage entspannt hat. Deshalb ist eine lange Queue auch nicht unbedingt schlecht. Sie verhindert schließlich Paketverluste. Ungünstig ist das nur, wenn sie länger bestehen bleibt und sich nicht auflöst. Erfahrungsgemäß muss mit einer höheren Übertragungsgeschwindigkeit auch die Puffer vergrößert werden.
DCTCP - Data Center TCP
Bei DCTCP geht es darum den Datenfluss in den Netzwerken von Rechenzentren zu optimieren. DCTCP informiert Server und Switche per Explicit Congestion Notification (ECN), dass große Daten anders gehandhabt werden als kleine. Bei kleinen kommt es oft auf kurze Latenzen an.
Mit DCTCP kommen sich verschiedene Datenströme weniger in die Quere, sodass die Latenzen im Optimalfall sinken und der Datendurchsatz insgesamt steigt. Außerdem soll zu starkes Puffern verhindert werden, bei dem es zu hohe Latenzen und Verbindungsabbrüchen führt (Bufferbloat).
Weitere verwandte Themen:
- TCP - Transmission Control Protocol
- TCP- und UDP-Ports
- UDP - User Datagram Protocol
- Ermittlung TCP-Ports und -Dienste
- TCP/IP
Frag Elektronik-Kompendium.de
Netzwerktechnik-Fibel
Alles was Sie über Netzwerke wissen müssen.
Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.
Artikel-Sammlungen zum Thema Netzwerktechnik
Collection: Netzwerk-Grundlagen
Was du über Netzwerk-Grundlagen wissen solltest.
Netzwerktechnik-Fibel
Alles was Sie über Netzwerke wissen müssen.
Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.