Direkt zum Inhalt

Meinels Web-Tutorial: Wie verhindert man einen Stau auf der Datenautobahn?

In dieser Folge von Meinels Web-Tutorial geht es erneut um das Internetprotokoll TCP. Eins seiner besten Kunststücke verhindert, dass unser Internet im Dauerstau versinkt.
Stau auf der Datenschnellstraße?

Mit der Vielzahl an neuen digitalen Technologien und ihren Anwendungen im Internet der Dinge, dank Social Media, Online-Shopping, Streaming-Diensten und Online-Gaming steigt der Verkehr im Internet exponentiell an. Daten des statistischen Bundesamts belegen, dass der Internettraffic in den letzten fünf Jahren rasant gewachsen ist: Während 2014 weltweit noch monatlich 40 Exabyte (ein Exabyte entspricht einer Trillion oder 1018 Bytes beziehungsweise einer Milliarde Gigabyte) an Daten über das Netz der Netze geflossen ist, waren es 2019 bereits knapp 140 Exabyte. Bis 2022 rechnet die Statistikbehörde mit einem Anstieg auf über 270 Exabyte.

Bei dieser enormen Menge an Daten kann es natürlich zu Verdichtungen bis hin zu Datenstaus kommen – und damit zu Problemen, die mit Hilfe der Software koordiniert werden müssen. Ein solches Verfahren ist das schon beschriebene TCP, das Transmission Control Protocol. Es umfasst nicht nur den in der letzten Kolumne erläuterten Quittierungsmechanismus, der sicherstellt, dass Daten fehlerfrei beim Empfänger ankommen, sondern enthält auch Komponenten zur Internet-Flusskontrolle, die sich dem Problem der Vermeidung von Datenstaus widmen.

Das TCP-Protokoll nutzt dazu den Quittierungsmechanismus, um dem Sender mitzuteilen, welche Kapazität der Empfänger für neu zu übertragende Daten frei hat und in welcher Frequenz und in welchen Portionen neue Daten ausgesendet werden können, um Platz im Eingangspuffer finden. Dazu kommt das »Sliding Window Protocol« zum Einsatz. Analog zu einem Schiebefenster, das sich nach Bedarf öffnet und schließt, wird der Datenfluss zwischen Sender und Empfänger über lastabhängige »Fenster« adaptiv kontrolliert. Am besten illustriert sich das Prinzip an einem Beispiel:

Nehmen wir an, Sender A möchte 2500 Byte an Daten an den Empfänger B versenden. In einem ersten Schritt wird die maximale »Fenstergröße« (F) für den Datentransfer zwischen A und B definiert. F sei in diesem Beispiel 1500 Byte. A sendet also die erste 1000 Byte der zu übermittelnden Daten an B. B empfängt die 1000 Byte und quittiert nicht nur den Erhalt der Datenpakete mit der entsprechenden Sequenznummer, sondern bestätigt 1000 Byte der Daten erhalten zu haben (Acknowledgment ACK 1000). Mit der Quittierung sendet B außerdem eine Angabe zur verbleibenden Aufnahmekapazität im Eingangspuffer, die neue Fenstergröße. Die ergibt sich aus der Differenz der maximalen Fenstergröße F = 1500 Byte abzüglich der bereits empfangenen 1000 Byte. Die neue Fenstergröße ist also F = 500 Byte.

A weiß nun, dass es nicht sinnvoll ist, mehr als 500 Byte im nächsten Schritt zu versenden, weil eine höhere Datenmenge nicht aufgenommen werden könnte und entsprechend verworfen würde. A passt die Paketgröße entsprechend an und sendet nun Daten im Umfang von 500 Byte an B. Der wiederum quittiert den Empfang des zweiten Datenpakets mit ACK 1500 und F = 0. Nun ist der komplette Eingangspuffer mit Daten belegt.

Nun muss A warten, bis bei B die empfangenen Daten aus dem Eingangspuffer an das Betriebssystem übergeben sind und der Eingangspuffer über freie Aufnahmekapazitäten verfügt. Sobald Daten aus dem Eingangsspeicher an das Betriebssystem übergeben sind, versendet B ein neues Acknowledgment, zum Beispiel ACK 1500 und F = 1000. A weiß dadurch, dass nun die restlichen 1000 Byte an B versendet werden können.

Schematisch sieht der Prozess folgendermaßen aus:

Das Sliding Window Protocol ermöglicht angepasste Datenraten | In jedem Schritt übermittelt der Empfänger an den Sender, wie groß seine aktuelle Aufnahmekapazität ist. Der Sender passt die Größe der Datenpakete entsprechend an.

Ohne besondere Vorkehrungen kommt es in der Praxis zu einem Problem, das als »Silly Window Syndrome« bezeichnet wird: Wenn der Sender die maximale Fenstergröße immer vollständig ausnutzt, dann stellt sich im nächsten Schritt eine Fenstergröße nahe bei null ein, und der Sender kann nur noch eine sehr kleine Datenmenge senden. Das ist deshalb ein Problem, weil die Menge an gekapselten TCP-Informationen und IP-Daten, die jedes Mal mitgeschickt werden müssen, ja nicht kleiner wird. Dadurch leidet die Effizienz der Datenübertragung stark. Um zu verhindern, dass dieser Overhead relativ gesehen zur Nutzlast der Daten ins Missverhältnis rückt, wurden zwei Vorkehrungen in der Flusskontrolle getroffen, die dafür sorgen, dass gesendete Datenpakete immer möglichst groß sind:

1. Eine Quittierung erfolgt erst, wenn wenigstens 50 Prozent des Eingangspuffers F wieder frei sind. (In unserem Beispiel wären das 750 Byte. Die zweite Übertragung von 500 Byte hätte also nicht stattfinden dürfen.)

2. Der Sender nutzt bei der Zusammenstellung der zu transportierenden Daten nicht die maximal mögliche Fenstergröße aus, so dass der Eingangspuffer nie vollständig belegt wird.

Eines der schwierigsten Probleme bei der Gewährleistung eines möglichst effizienten Datentransports durch das Internet besteht darin, Überlastsituationen in den Zwischensystemen zu erkennen. Über TCP sind ja nur die beiden Endsysteme verbunden, sie können Daten über ihre Aufnahme- und Leistungsfähigkeit austauschen. Aber wie es um die Leistungsfähigkeit der Zwischensysteme steht, über die der Datentransport erfolgt, ist den Endsystemen unbekannt, da TCP nur in den Endsystemen wirkt und es keine Kommunikation mit den TCP-Instanzen anderer Verbindungen gibt.

Die Idee, wie TCP trotzdem Überlastsituationen in Zwischensystemen erkennen und ausgleichen kann, besteht darin, die Zahl der verlorenen Datenpakete als Hinweis und Parameter für einen Datenstau bei den auf dem Transportweg zu überbrückenden Zwischensystemen zu interpretieren. Wenn es also gehäuft vorkommt, dass Datensendungen nicht quittiert werden, dann schließt TCP, dass irgendwo auf dem Transportweg Überlast herrscht, und reagiert entsprechend. Um die optimale Übertragungsrate zu ermitteln, starten die beiden Endsysteme ihre Übertragung mit einem »Slow-Start-Algorithmus«, bei dem zunächst ein Datenpaket mit nur kleiner Fenstergröße gesendet wird und dann, nach jeder erfolgreichen Quittierung, die Datenpaketlänge verdoppelt wird. Die Paketlänge wächst also exponentiell an und nähert sich dadurch rasch dem Optimum. Erst wenn vermehrt Datenpakete verloren gehen, also nicht quittiert werden, bremst TCP den Längenzuwachs. Dann tritt der Congestion-Avoidance-Algorithmus in Kraft. Der Stau-Vermeidungs-Algorithmus senkt die Datenrate wieder, bis die Anzahl der verlorenen Pakete auf ein akzeptables Niveau fällt.

Wie die Praxis beweist, werden in jedem Zeitpunkt und bei jeder Lastsituation im Internet mit dem Zusammenspiel dieser zwei Algorithmen sehr gut angepasste Übertragungsraten erreicht und Staus auf der Datenautobahn eingeschränkt oder ganz vermieden.

Schreiben Sie uns!

Beitrag schreiben

Wir freuen uns über Ihre Beiträge zu unseren Artikeln und wünschen Ihnen viel Spaß beim Gedankenaustausch auf unseren Seiten! Bitte beachten Sie dabei unsere Kommentarrichtlinien.

Tragen Sie bitte nur Relevantes zum Thema des jeweiligen Artikels vor, und wahren Sie einen respektvollen Umgangston. Die Redaktion behält sich vor, Zuschriften nicht zu veröffentlichen und Ihre Kommentare redaktionell zu bearbeiten. Die Zuschriften können daher leider nicht immer sofort veröffentlicht werden. Bitte geben Sie einen Namen an und Ihren Zuschriften stets eine aussagekräftige Überschrift, damit bei Onlinediskussionen andere Teilnehmende sich leichter auf Ihre Beiträge beziehen können. Ausgewählte Zuschriften können ohne separate Rücksprache auch in unseren gedruckten und digitalen Magazinen veröffentlicht werden. Vielen Dank!

Partnerinhalte

Bitte erlauben Sie Javascript, um die volle Funktionalität von Spektrum.de zu erhalten.