Fluss- und Überlastkontrolle

In dieser interaktiven Lerneinheit verstehst du die wichtigen Mechanismen der TCP-Flusskontrolle und Überlaststeuerung, die eine effiziente und zuverlässige Datenübertragung im Netzwerk gewährleisten. Du lernst, wie TCP das Übertragungstempo dynamisch an die verfügbare Bandbreite anpasst und wie Überlastungen im Netzwerk erkannt und verhindert werden. Diese Kenntnisse helfen dir bei der Analyse von Performanceproblemen und der Optimierung von Netzwerkverbindungen im praktischen Einsatz.

Einführung

Du streamst ein Video, die Verbindung ist stabil, und trotzdem stockt das Bild. Woran liegt’s? Nicht selten daran, dass dein Gerät mehr Daten erhält, als es gleichzeitig verarbeiten kann. Auf der anderen Seite will der Server möglichst viele Daten so schnell wie möglich verschicken. Dieses Spannungsverhältnis zwischen Sendetempo und Empfangskapazität ist eine der größten Herausforderungen im Netzwerkverkehr – und genau hier setzen Flusskontrolle und Überlastkontrolle im TCP-Protokoll an.

Ohne Kontrolle vs. Mit Flusskontrolle: Wie ein Ventil den Wasserfluss reguliert, so steuert das Sliding Window den Datenfluss — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Wie sorgt TCP dafür, dass keine Seite überfordert wird und das Netzwerk dennoch effizient bleibt? Das sehen wir uns jetzt an.

Lernziele

Nach dieser Lerneinheit kannst du:

• erklären, wie das Sliding Window Protokoll zur Flusskontrolle in TCP funktioniert,
• die Rolle von Empfangsfenster und Sendepuffer für eine stabile Datenübertragung beschreiben,
• den Unterschied zwischen Flusskontrolle und Überlastkontrolle (Congestion Control) benennen,
• typische TCP-Mechanismen zur Überlastvermeidung wie Slow Start, Congestion Avoidance und Fast Recovery nachvollziehen.

Überleitung

Damit Daten im Internet zuverlässig und effizient ankommen, muss sichergestellt werden, dass Sender und Empfänger im Gleichgewicht arbeiten. Hier kommt die Flusskontrolle im TCP ins Spiel. In dieser Einheit lernst du, wie das Sliding Window Protokoll funktioniert, wie sich TCP an die Empfangskapazität anpasst und was bei Überlastung passiert.

Was ist die Flusskontrolle im TCP?

Die Flusskontrolle ist ein essenzieller Bestandteil des Transmission Control Protocol (TCP). Sie verhindert, dass der Sender den Empfänger mit mehr Daten überflutet, als dieser verarbeiten und speichern kann. Dadurch wird die Effizienz der Datenübertragung gesteigert und Überlastungen im Netzwerk werden vermieden.

Was ist das Sliding Window Protokoll?

Das Sliding Window Protokoll ist ein zentraler Mechanismus zur Flusskontrolle in TCP. Es regelt die Datenübertragung zwischen Sender und Empfänger effizient und verhindert dabei eine Überlastung des Netzwerks.

Grundprinzip

Das Protokoll basiert auf zwei Arten von Fenstern:

• Sendefenster: Gibt an, wie viele Daten der Sender maximal senden darf, ohne eine Bestätigung (ACK) vom Empfänger erhalten zu haben. Die Größe hängt vom zuletzt bekannten Empfangsfenster ab.
• Empfangsfenster: Wird vom Empfänger festgelegt und gibt an, wie viele Daten dieser noch puffern kann. Es wird regelmäßig als sogenannte “Window Size Field” im TCP-Header zurückgemeldet.

Die Fenstergrößen sind dynamisch und können sich im Verlauf der Übertragung an Netzwerk- und Puffersituation anpassen (z. B. mithilfe von TCP-Window-Scaling).

Funktionsweise

1. Verbindungsaufbau: Beim Drei-Wege-Handshake teilt der Empfänger dem Sender mit, wie groß sein Empfangsfenster ist. Der Sender richtet sein Sendefenster daran aus.
2. Datenübertragung: Der Sender überträgt Datensegmente innerhalb der Fenstergröße. Jedes Segment erhält eine eindeutige Sequenznummer.
3. Empfangsbestätigung: Der Empfänger bestätigt empfangene Daten durch ACKs. Diese enthalten die Sequenznummer des nächsten erwarteten Segments.
4. Fensteranpassung: Nach Eingang einer Bestätigung verschiebt der Sender sein Sendefenster entsprechend. Der Empfänger kann bei Bedarf die Größe seines Empfangsfensters in den ACKs aktualisieren.

Beispiel

Ein vereinfachtes Szenario zur Illustration:

• Empfangsfenster = 4 Segmente
• Der Sender darf also bis zu 4 Segmente senden, bevor er auf eine Bestätigung warten muss.
• Nach Empfang der ACKs für die ersten 2 Segmente kann das Fenster um 2 Stellen nach vorne “geschoben” werden.

Beispielhafter Verlauf (Bildrechte: Ausbildung in der IT)

Empfängerfenster und Sendepuffer

Das Empfängerfenster und der Sendepuffer spielen eine kritische Rolle in der Flusskontrolle von TCP, um sicherzustellen, dass keine Daten verloren gehen und die Netzwerkressourcen effizient genutzt werden.

Was ist das Empfängerfenster?

Das Empfängerfenster, auch bekannt als Receive Window (RWIN), definiert die Menge an Daten, die der Sender senden darf, bevor er eine Bestätigung (ACK) vom Empfänger erhalten muss. Die Größe dieses Fensters wird vom Empfänger basierend auf seinen Pufferkapazitäten festgelegt und dem Sender mitgeteilt.

• Dynamische Anpassung: Der Empfänger passt seine Fenstergröße je nach verfügbarer Pufferkapazität an:
  • In der Anpassungsphase wird das Fenster verkleinert, um Datenfluss zu drosseln.
  • In der Erholungsphase wird es vergrößert, sobald wieder mehr Speicher frei ist.

Was ist der Sendepuffer?

Der Sendepuffer speichert Daten, die gesendet, aber noch nicht bestätigt wurden. So kann der Sender verlorene Pakete erneut senden, ohne die Anwendungsschicht zu involvieren.

• Unterstützt effiziente Nachsendungen
• Reagiert flexibel auf ACKs und Fensterveränderungen

Zusammenspiel

Das Zusammenspiel von Empfängerfenster und Sendepuffer ermöglicht eine adaptive und zuverlässige Datenübertragung, indem es sich an die Verarbeitungskapazität des Empfängers anpasst.

Vermeidung von Überlastung des Empfängers

Die Vermeidung von Überlastung ist zentral für die Stabilität von TCP. Übersteigt der Datenfluss die Verarbeitungskapazität des Empfängers, drohen Paketverluste.

Flow Control Mechanismen

1. Sliding Window Protocol: Erlaubt begrenzte unbestätigte Übertragungen und passt sich dynamisch an.
2. Zero Window: Wenn der Empfänger keine Kapazität mehr hat (RWND=0), pausiert der Sender die Übertragung vollständig.

Beispiel

Ein Video-Streaming-Server sendet Daten an einen Client. Wird der Client-Puffer knapp, verringert sich das Empfangsfenster. Der Server reduziert daraufhin die Datenrate und vermeidet eine Überlastung.

⏳ Lädt Dataview-Inhalt...

Was ist der Langsame Start?

Der Langsame Start (Slow Start) ist ein grundlegender Mechanismus im TCP/IP-Protokoll, der Netzwerküberlastungen vermeiden soll. Das Ziel ist es, die Menge der gesendeten Daten schrittweise zu erhöhen, bis entweder ein optimales Niveau erreicht oder eine Überlastung erkannt wird. Dieser Mechanismus wird beim Aufbau einer neuen TCP-Verbindung oder nach einem Timeout-Ereignis aktiviert.

Grundprinzip

Zu Beginn einer TCP-Verbindung kennt der Sender die Netzwerkkapazität nicht. Deshalb startet TCP vorsichtig mit dem Versand einer kleinen Anzahl von Datenpaketen und passt die Sendrate basierend auf dem Netzwerk-Feedback an.

Congestion Window (cwnd)

TCP verwendet dafür das Congestion Window (cwnd). Dieser Parameter legt fest, wie viele Segmente maximal gesendet werden dürfen, bevor eine Bestätigung (ACK) vom Empfänger eingegangen ist.

• Historisch wurde cwnd mit 1 MSS initialisiert (RFC 2001).
• Moderne Implementierungen verwenden oft bis zu 10 MSS (RFC 6928).

Exponentielles Wachstum

Für jedes vollständig bestätigte Segment erhöht sich cwnd um eins. Dadurch verdoppelt sich cwnd ungefähr pro Round-Trip Time (RTT). Dies führt zu einem exponentiellen Wachstum – solange keine Überlastung auftritt.

Slow Start Threshold (ssthresh)

Sobald cwnd einen Schwellenwert namens Slow Start Threshold (ssthresh) erreicht, wechselt TCP in den Modus der Überlastvermeidung (Congestion Avoidance). Das Wachstum des Congestion Window erfolgt ab diesem Punkt nur noch linear.

Reaktion auf Netzwerküberlastung

Zwei Fälle:

• Timeout: Dies deutet auf eine starke Überlastung hin. TCP halbiert ssthresh, setzt cwnd auf 1 MSS zurück und startet erneut mit Slow Start.
• 3 Duplicate ACKs: TCP erkennt einen Paketverlust frühzeitig und wechselt zu Fast Retransmit und Fast Recovery. Ein Rückfall in Slow Start erfolgt in diesem Fall nicht.

Beispielhafter Verlauf

1. cwnd = 1 MSS
2. Segment wird bestätigt → cwnd = 2 MSS
3. Zwei Segmente bestätigt → cwnd = 4 MSS
4. Vier Segmente bestätigt → cwnd = 8 MSS

Beispielhafter Verlauf (Bildrechte: Ausbildung in der IT)

Der Prozess wiederholt sich, bis ssthresh erreicht ist oder Paketverlust eintritt.

Überlastvermeidung (Congestion Avoidance)

Nach dem Erreichen des Schwellenwerts ssthresh tritt TCP in die Phase der Überlastvermeidung (Congestion Avoidance) ein. Das Ziel dieser Phase ist es, eine Überlastung präventiv zu vermeiden.

Grundprinzip

Im Gegensatz zum exponentiellen Wachstum bei Slow Start wird cwnd in dieser Phase linear erhöht:

• Für jedes empfangene ACK: cwnd += 1 / cwnd
• Pro RTT ergibt sich so eine Zunahme von etwa 1 MSS.

Reaktion auf Paketverlust

Wenn ein Paketverlust erkannt wird (z. B. durch 3 Duplicate ACKs):

1. ssthresh = cwnd / 2
2. TCP wechselt in den Fast-Retransmit-/Fast-Recovery-Modus (siehe unten)

Wichtig: Bei einem Timeout erfolgt zusätzlich ein Rückfall in Slow Start (cwnd = 1 MSS).

Zielsetzung

• Vermeidung von Netzüberlastung
• Effiziente Nutzung der verfügbaren Bandbreite
• Fairness zwischen verschiedenen TCP-Verbindungen

Schnelle Wiederübertragung (Fast Retransmit)

Fast Retransmit ist ein Mechanismus in TCP zur schnellen Reaktion auf Paketverluste – ohne auf das Retransmission Timeout (RTO) zu warten.

Funktionsweise

• Wenn ein Paket verloren geht, empfängt der Sender mehrere identische ACKs (Duplicate ACKs) für das letzte korrekt empfangene Paket.
• Bei drei duplizierten ACKs sendet TCP sofort das vermisste Paket erneut.

Beispielablauf

1. Sender überträgt Pakete 1–5.
2. Paket 3 geht verloren.
3. Empfänger erhält Paket 4 → sendet dupliziertes ACK für 2
4. Empfänger erhält Paket 5 → erneut ACK für 2
5. Nach dem 3. duplizierten ACK → Fast Retransmit für Paket 3

Schnelle Wiederherstellung (Fast Recovery)

Fast Recovery folgt direkt nach einem Fast Retransmit und dient dazu, die Übertragungsrate kontrolliert wieder zu steigern.

Ablauf

1. Erkennung des Verlusts: 3 Duplicate ACKs
2. Reduktion der Schwelle: ssthresh = cwnd / 2
3. Reduktion des Sendefensters: cwnd = ssthresh + 3
4. Wiederaufbau: Für jedes weitere Duplicate ACK: cwnd += 1
5. Rückkehr zum Normalbetrieb: Sobald ein neues ACK eintrifft, Wechsel in Congestion Avoidance

Beispiel

Webserver verliert ein Paket beim Laden einer Seite. Nach 3 Duplicate ACKs sendet er es erneut (Fast Retransmit) und startet Fast Recovery. cwnd wird nicht auf 1 zurückgesetzt, sondern leicht abgesenkt und dann linear erhöht.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung:

In dieser Lerneinheit hast du gelernt, wie das Transmission Control Protocol (TCP) eine zuverlässige und kontrollierte Datenübertragung ermöglicht. Ein zentrales Element ist die Flusskontrolle, die verhindert, dass ein Sender den Empfänger überlastet. Dafür nutzt TCP das Sliding Window Protokoll, bei dem der Sender nur so viele Daten senden darf, wie der Empfänger verarbeiten kann. Das geschieht über dynamische Fenstergrößen, die sich an die Netzwerkbedingungen anpassen.

Du hast außerdem verstanden, wie das Empfängerfenster (Receive Window) und der Sendepuffer zusammenarbeiten: Während der Empfänger dem Sender seine aktuelle Kapazität mitteilt, hält der Sendepuffer alle unbestätigten Daten bereit – für eine zuverlässige und effiziente Übertragung.

Ein weiterer wichtiger Punkt war die Vermeidung von Überlastung. Mit Mechanismen wie dem Zero Window kann der Empfänger die Übertragung gezielt pausieren, wenn sein Puffer voll ist.

Im zweiten Teil ging es um die Überlastkontrolle auf Netzwerkebene. Der Slow-Start-Mechanismus sorgt dafür, dass TCP-Verbindungen mit niedriger Sendrate beginnen und sich schrittweise steigern. Das Congestion Window (cwnd) wächst dabei exponentiell, bis ein Schwellenwert erreicht wird oder Paketverluste auftreten. Ab diesem Punkt übernimmt die Phase der Überlastvermeidung, in der das Fenster nur noch langsam (linear) wächst.

Tritt ein Paketverlust auf, reagiert TCP entweder mit einem Rückfall in Slow Start (nach Timeout) oder – im günstigeren Fall – mit Fast Retransmit und Fast Recovery. Dadurch wird das verlorene Paket zügig erneut gesendet, ohne die Sendefenstergröße drastisch zu verringern.

Ausblick

In der nächsten Einheit beschäftigen wir uns mit der Staukontrolle in Netzwerken (Congestion Control). Du wirst lernen, wie Router und Protokolle gemeinsam arbeiten, um Überlastungen im gesamten Netzwerk zu erkennen und zu begrenzen. Dabei lernst du auch den Unterschied zwischen Fluss- und Staukontrolle kennen.

---