Das Congestion Window (Überlastungsfenster, kurz cwnd) ist die zentrale Zustandsvariable der Überlastkontrolle von TCP. Es begrenzt, wie viele Daten sich gleichzeitig in Flight befinden dürfen, und schützt damit das Netz davor, mit Paketen überflutet zu werden.
Flusskontrolle vs. Überlastkontrolle
TCP führt zwei Fenster: Das Empfängerfenster (rwnd) kommt vom Empfänger und verhindert, dass dessen Puffer überläuft — das ist Flusskontrolle. Das Congestion Window schätzt dagegen die Kapazität des Netzes. Das effektiv genutzte Fenster ist das Minimum beider Werte: min(cwnd, rwnd).
Slow Start und Congestion Avoidance
Nach dem Verbindungsaufbau startet cwnd klein (klassisch ein Segment, modern oft zehn Segmente) und wächst in der Slow-Start-Phase pro Rundlaufzeit (RTT) exponentiell, bis es den Schwellwert ssthresh erreicht. Danach folgt die lineare Congestion Avoidance: pro RTT wächst cwnd um ein Segment. Dieses Muster heißt AIMD (Additive Increase, Multiplicative Decrease).
Reaktion auf Verluste
Bei drei doppelten Bestätigungen (Triple Duplicate ACK) wertet TCP den Verlust als Überlastsignal: TCP Tahoe setzt cwnd auf ein Segment zurück und startet Slow Start neu; TCP Reno halbiert ssthresh und aktiviert Fast Recovery. Läuft der Retransmission-Timeout ab, gilt das als schweres Signal, und cwnd fällt auf ein Segment zurück. Referenz ist RFC 5681; moderne Implementierungen wie CUBIC oder BBR von Google verändern den Anstieg gezielt.
Zusammenhang mit Sliding Window
Das Congestion Window setzt das Prinzip des Sliding Window auf TCP-Ebene um: Damit eine Leitung voll ausgelastet ist, muss cwnd mindestens das Bandbreite-Latenz-Produkt abdecken — also Bandbreite mal Latenz.
Verwandte Grundlagen: Sliding Window, TCP, Netzwerkpaket.