TCP: bestätigter Fluss

Netzwerk-Staus mit dem Datagramm Congestion Control Protocol vermeiden

Praxis & Tipps | Praxis

Seite 2: TCP: bestätigter Fluss

TCP, im RFC 793 ursprünglich spezifiziert und durch zahlreiche Erweiterungen den Gegebenheiten und Technologieveränderungen angepasst, ist sozusagen die Mutter aller Protokolle. Es weist fünf charakteristische, im Folgenden genauer dargestellte Eigenschaften auf: Bytestrom- und Verbindungsorientierung, Flusskontrolle, Zuverlässigkeit und Vollduplex-Übertragung ­ zwei Kommunikationspartner können gleichzeitig sowohl Daten senden als auch empfangen.

Das Betriebssystem stellt Anwendungen eine Bytestrom-Schnittstelle zur Verfügung. Dank dieser Abstraktionsebene ist TCP so erfolgreich, da Anwendungsentwickler Netzverbindungen auf ebenso einfache Weise nutzen können wie Dateien. Verbindungsorientierte Eigenschaften ergeben sich aus der Tatsache, dass eine virtuelle Verbindung mit dem Kommunikationspartner den Datenaustausch einleitet (Dreiwege-Handshake).

Jede TCP-Instanz verfügt für die Speicherung von Daten über einen Puffer einer bestimmten initialen Größe. Wenn ihn die Anwendung nicht oder zu langsam ausliest, kann er überlaufen. Um das zu vermeiden, erhält der Kommunikationspartner bei jedem Datenaustausch Informationen über die aktuelle Größe des verbleibenden Puffers (Sliding-Window-Verfahren).

Mit jedem Byte im Datenstrom korrespondiert eine Sequenznummer. Der Empfänger muss empfangene Daten quittieren (Acknowledge). Dieses Verfahren gewährleistet, dass Datensegmente am Ende in die richtige Reihenfolge kommen. Bleiben Bestätigungen aus oder wiederholen sie sich, liegt ein Fehlverhalten vor. Die angemessene Reaktion kann etwa ein Bremsen der Übertragung sein. Die Prüfsumme im TCP-Header deckt außerdem Übertragungsfehler im Paketkopf sowie in den Nutzdaten auf.

Das User Datagram Protocol, der kleine, funktional beschnittene Bruder von TCP, ist nicht weniger wichtig im Internet-Protokollgespann. UDP arbeitet als minimalistisches Transportprotokoll (RFC 768) und erweitert IP nur minimal, unter anderem um eine Prüfsumme über die Anwendungsdaten und eine Adressierung der Anwendung (Quell- und Zielport). Es kennt keine Stauprävention oder ähnliche Korrekturmechanismen.

UDP eignet sich wegen seines geringen Overhead im Vergleich zu TCP für Anwendungen wie DNS, die einen minimalen, kurzzeitigen Datenaustausch betreiben, und wenn die Zuverlässigkeit keine allzu wichtige Rolle spielt oder sich sogar nachteilig auswirken kann. Ein typisches Beispiel ist die Übertragung von Audiodaten, die den Verlust einzelner Pakete besser verkraftet als enorme Latenzen. Wiederholte Übertragungen von Datenpaketen würden zu einer akustischen Katastrophe führen. Aktuelle Entwicklungstrends erfordern differenziertere Protokolleigenschaften, als TCP und UDP sie definieren. Zu den Anwendungen, die eine minimale Verzögerung (Jitter) verlangen und der Zuverlässigkeit einen minderen Stellenwert einräumen, gehören IP-Telefonie, Streaming Radio oder Onlinespiele. Mit der Beliebtheit solcher Dienste, die langanhaltende Verbindungen aufbauen, Engpässe aber nicht erkennen können, wächst allmählich der Druck, dem entgegenzuwirken (RFC 3714).

Derzeit bildet in der Regel UDP die Protokollgrundlage für die neuen Dienste. Es bietet den großen Vorteil, dass ein Paketverlust den Datenstrom nicht unterbricht, als Nachteil erweist sich aber das Fehlen einer Stauvermeidung. Der Ansatz eines solchen Algorithmus auf Anwendungsebene ist aus mehreren Blickwinkeln negativ zu bewerten. Es können Sicherheitslücken entstehen, wenn unzureichend getestete Insellösungen zum Einsatz kommen. Außerdem gibt es Durchsatznachteile gegenüber einer Nutzung des Kernadressraums, und Inkompatibilitäten bei späteren Erweiterungen lassen sich nicht ausschließen.

Solch hohe Einstiegshürden für eine proprietäre Stauvermeidung auf Anwendungsebene verleiten Entwickler in der Regel dazu, einfach vollständig darauf zu verzichten. Das beliebte Session Initiation Protocol (SIP, RFC 2543) sieht jedoch eine eigentlich unvollständige Staukontrolle auf Basis des "exponential backoff" bei der erneuten Übertragung und bei der Begrenzung von Paketen vor.

Anzeige