Flow-Control

Kurz: Ein Mechanismus, der verhindert, dass ein schneller Sender einen langsameren Empfänger mit Daten überflutet, indem die Übertragungsrate dynamisch angepasst wird.

Genauer: Ohne Flow-Control könnte ein Empfänger mit begrenztem Puffer Daten verlieren, wenn sie schneller ankommen als er sie verarbeiten kann. TCP regelt das über ein “Sliding Window”, bei dem der Empfänger dem Sender signalisiert, wie viele Daten er aktuell noch aufnehmen kann.

Im Detail

Das Sliding-Window-Verfahren

Das Sliding-Window-Verfahren, über das TCP Flow-Control umsetzt, funktioniert im Prinzip so: Jedes ACK des Empfängers enthält neben der reinen Bestätigung auch ein “Receive Window” (rwnd) — die Angabe, wie viele weitere Bytes der Empfänger aktuell noch in seinem Puffer aufnehmen kann, bevor die Anwendung sie ausliest und verarbeitet. Der Sender darf immer nur so viele unbestätigte Daten gleichzeitig “im Flug” haben, wie dieses Fenster erlaubt, und muss pausieren, sobald das Fenster voll ist:

Sender:                          Empfänger (rwnd=4000):
--------  4000 Bytes Daten --->
<-------- ACK, rwnd=0 (Puffer voll) ---
(Sender pausiert, wartet auf freigegebenes Fenster)
<-------- ACK, rwnd=2000 (Puffer teilweise geleert) ---
--------  2000 Bytes Daten --->

Wird der Empfangspuffer vom Anwendungsprogramm langsamer geleert, als neue Daten ankommen (z. B. weil die Anwendung gerade intensiv mit etwas anderem beschäftigt ist, etwa einer aufwendigen Datenbankabfrage), schrumpft das gemeldete Fenster automatisch — im Extremfall bis auf 0, was den Sender komplett anhält, bis der Empfänger wieder Platz gemeldet hat. Der Sender wiederholt in diesem Zustand periodisch kleine “Window Probes”, um zu erkennen, sobald wieder Kapazität frei ist, ohne unnötig große Datenmengen zu riskieren.

Flow-Control vs. Congestion Control

Wichtig ist die klare Abgrenzung zu Congestion Control, zwei Mechanismen, die häufig verwechselt werden: Flow-Control schützt den EMPFÄNGER vor Überlastung, basierend auf dessen tatsächlicher, gemeldeter Pufferkapazität — ein rein lokales Problem zwischen genau zwei Endpunkten. Congestion Control schützt dagegen das NETZWERK dazwischen vor Überlastung, basierend auf beobachtetem Datenverlust oder steigender Latenz als indirektem Überlastsignal — ein Problem, das potenziell viele Verbindungen gleichzeitig betrifft, die sich dieselben Leitungen und Router teilen. Beide Mechanismen arbeiten in TCP parallel und unabhängig voneinander (mit getrennten Fenstergrößen, dem Receive Window für Flow-Control und dem Congestion Window für Congestion Control), begrenzen aber GEMEINSAM, wie viele Daten der Sender tatsächlich auf einmal verschicken darf — es gilt jeweils das kleinere der beiden Fenster.

Flow-Control jenseits von TCP

Das Grundprinzip taucht auch außerhalb von TCP auf: USB, PCIe und viele andere Hardware-Bus-Systeme implementieren eigene Flow-Control-Mechanismen, um zu verhindern, dass ein schnelles Gerät ein langsameres mit Daten überfordert. Auch auf Anwendungsebene (etwa bei manchen Streaming-Protokollen oder Message-Queues) findet sich das gleiche Konzept unter anderem Namen wieder — häufig als “Backpressure” bezeichnet, wenn ein nachgelagertes System einem vorgelagerten explizit signalisiert, langsamer zu senden, weil es sonst überlastet würde.

Siehe auch: TCP, Datenverlust, Latenz