TCP Congestion Control bestimmt, wie Verbindungen bei wechselnder Netzlast die Datenrate anpassen und wie sich Algorithmen in realen Hosting-Setups schlagen. In diesem Vergleich zeige ich konkrete Auswirkungen auf Durchsatz, Verzögerung und Fairness für Webhosting, Streaming und Cloud-Workloads.
Zentrale Punkte
Damit du den Artikel zielgerichtet liest, fasse ich die entscheidenden Aspekte kurz zusammen und setze später alles in Kontext. Ich unterscheide klar zwischen loss‑basierten und modellbasierten Verfahren, weil beide Familien sehr unterschiedlich reagieren. Ich erkläre, warum cwnd, RTT und Pacing über Leistung und Fairness entscheiden. Ich ordne Messergebnisse ein, damit du Entscheidungen nicht aus dem Bauch triffst. Ich schließe mit pragmatischen Empfehlungen für Hosting, Container und globale Nutzer.
- AIMD steuert cwnd und reagiert auf Verluste
- CUBIC liefert konstante Performance bei großen RTTs
- BBR nutzt Modell, reduziert Queues und Latenz
- BIC punktet in Netzen mit Drops
- Hybla beschleunigt lange Leitungen (Satellit)
Was Congestion Control steuert: cwnd, RTT, Verlustsignale
Ich starte mit den Grundlagen, weil sie jede spätere Wahl beeinflussen. Die Congestion Window (cwnd) begrenzt, wie viele Bytes ohne Bestätigung unterwegs sind, und AIMD vergrößert cwnd schrittweise, bis Verluste eintreten. RTT bestimmt, wie schnell Bestätigungen zurückkommen und wie aggressiv ein Algorithmus wachsen kann. Verlustsignale entstanden früher aus Timeouts und Triple-Duplicate-ACKs, heute zählen zusätzlich Queue‑Tiefe, minimaler RTT und gemessene Engpassbandbreite. Wer cwnd, RTT und Verlustdeutung versteht, beurteilt den Einfluss auf Durchsatz, Verzögerung und Jitter sofort besser.
Rückblick: Reno, NewReno und Vegas im Alltag
Reno nutzt Slow Start zu Beginn und geht danach in lineare Zuwächse über, halbiert aber die Fenstergröße nach Verlusten drastisch. NewReno repariert mehrere Verluste pro Fenster effizienter, was gerade bei moderaten Fehlerquoten merklich hilft. Vegas misst erwarteten gegen tatsächlichen Durchsatz über die RTT und bremst früh, um Verluste zu vermeiden. Diese Vorsicht hält Queues klein, kostet aber Durchsatz, wenn loss‑basierte Flüsse parallel aggressiver senden. Wer unerklärte Timeouts oder Duplicate‑ACKs sieht, sollte zunächst Paketverluste analysieren und dann den Algorithmus zur Topologie passend auswählen.
High-BW-RTT: BIC und CUBIC im Vergleich
BIC tastet sich binär an die höchste verlustfreie cwnd heran und hält die Rate auch bei leichten Fehlern erstaunlich konstant. In Laboren mit niedriger Latenz und Drop‑Raten um 10^-4 lieferte BIC Durchsatzwerte oberhalb von 8 Gbit/s, während klassische Algorithmen schwankten. CUBIC ersetzte BIC als Standard, weil es sein cwnd über eine kubische Zeitfunktion steuert und dadurch lange RTTs besser ausnutzt. Die Kurve wächst nach einem Verlustereignis zuerst moderat, beschleunigt dann spürbar und wird nahe der letzten Maximalrate wieder vorsichtig. In Netzen mit langen Wegen erreiche ich mit CUBIC oft höhere Auslastung bei gleichzeitig guter Planbarkeit der Latenzen.
Model-based: BBR, Pacing und Bufferbloat
BBR nutzt ein Modell aus minimaler RTT und gemessener Engpassbandbreite, setzt cwnd auf ungefähr das Doppelte des Bandbreiten‑Verzögerungsprodukts und paced Pakete gleichmäßig. Diese Strategie verhindert übervolle Queues und hält Verzögerungen kurz, selbst wenn leichte Verluste auftreten. In Setups mit schwankender Funkqualität oder gemischten Pfaden bleibt Goodput hoch, weil BBR nicht reflexartig auf jeden Drop reagiert. Version 1 gilt als sehr schnell, kann aber in kleinen Puffern mit CUBIC konkurrieren und dabei etwas unfaire Aufteilung zeigen. Ich kombiniere BBR in BBR CUBIC hosting Landschaften gern für Primärflüsse und lasse CUBIC als kompatiblen Fallback laufen.
Satellit und Funk: Hybla, Westwood und PCC
Hybla gleicht die Nachteile hoher RTTs aus, indem es cwnd so skaliert, als läge eine kurze Referenz‑RTT vor. Dadurch steigen lange Strecken, etwa Satellit, viel schneller auf nutzbare Raten an und bleiben dort auch verlässlich. Westwood schätzt verfügbare Bandbreite an den ACK‑Raten ab und reduziert cwnd nach Verlusten weniger hart, was in Funknetzen mit zufälligen Fehlern hilft. PCC geht einen Schritt weiter und optimiert einen Nutzenwert über kurze Experimente, wodurch es hohe Goodput‑Latenz‑Kombinationen erreichen kann. In heterogenen Netzen mit Mobilität teste ich Hybla und Westwood bevorzugt, bevor ich aufwändige QoS‑Regeln anfasse.
Leistungsvergleich: Messwerte und Fairness
Vergleiche zeigen deutlich unterschiedliche Profile, wenn Latenz und Fehlerquoten variieren. Bei niedriger RTT dominiert BIC häufig das reine Durchsatzrennen, während CUBIC eine verlässliche Mischung aus Rate und Verhalten über Zeit bietet. Bei sehr langen RTTs punktet CUBIC gegenüber Reno und NewReno klar, weil es die Wartezeiten besser in Wachstum übersetzt. BBR hält Queues leer und liefert konstant niedrige Verzögerungen, erzeugt aber je nach Puffergröße mehr Neuübertragungen. Für parallele Flüsse zeigt CUBIC meist eine faire Aufteilung, BIC hält die Leitung gerne nahe an der Kapazität.
| Algorithmus | Prinzip | Stärke | Schwäche | Empfohlen für |
|---|---|---|---|---|
| Reno / NewReno | Loss‑basiert, AIMD | Einfaches Verhalten | Langsam bei hoher RTT | Legacy‑Stacks, Fehlersuche |
| Vegas | RTT‑basiert | Frühe Stauvermeidung | Geringerer Durchsatz | Konstante Latenz |
| BIC | Binäre Suche | Hoher Goodput bei Drops | Aggressiv gegen andere | Niedrige RTT, Fehlerquoten |
| CUBIC | Kubische Zeitfunktion | Gute Fairness | Streuung bei Drops | Lange Pfade, Rechenzentren |
| BBR | Modellbasiert, Pacing | Niedrige Latenz | Unfair in kleinen Puffern | Hosting, globale Nutzer |
| Hybla | RTT‑Kompensation | Schneller Ramp‑up | Spezialfall‑Charakter | Satellit, Maritim |
Praxisleitfaden: Auswahl nach Latenz, Verlust und Ziel
Ich starte jede Entscheidung mit klaren Zielen: niedrige Latenz, maximaler Goodput oder Gleichgewicht für viele Flüsse. Bei hart limitierten Puffergrößen und sensiblen Latenzanforderungen greife ich zuerst zu BBR. Wenn lange Pfade dominieren und mehrere Hosts koexistieren, führt kein Weg an CUBIC vorbei. In Netzen mit gut beobachtbaren Drop‑Mustern liefert BIC weiterhin beeindruckende Raten, sofern Fairness zweitrangig ist. Für Satellit und sehr hohe RTT‑Pfadkosten räumt Hybla typische Ramp‑up‑Nachteile aus dem Weg und sichert schnelle Nutzlast.
Linux, Windows und Container: Aktivierung und Tuning
Unter Linux prüfe ich mit sysctl net.ipv4.tcp_congestion_control den aktiven Algorithmus und setze per sysctl net.ipv4.tcp_congestion_control=bbr gezielt um. Für CUBIC beachte ich Kernel‑Defaults, passe aber net.core.default_qdisc und Pacing‑Parameter an, wenn ich Host‑Queues entschärfe. In Containern übertrage ich Einstellungen auf den Host, weil Namespaces nicht jede Queue isolieren. Unter Windows ab aktuellen Versionen lässt sich BBR in passenden Editionen aktivieren, während ältere Systeme weiterhin CUBIC oder Compound verwenden. Ohne solide System‑ und Queue‑Einstellungen verliert jeder Algorithmus spürbar an Wirkung.
Webhosting-Perspektive: Multi-Flow-Fairness und Goodput
In Hosting‑Clustern zählt die Summe vieler gleichzeitiger Flüsse, nicht der Bestwert eines einzigen Transfers. CUBIC hält Verbindungen berechenbar und teilt Kapazität meist fair auf, was dichte Multi‑Tenant‑Szenarien begünstigt. BBR reduziert Warteschlangen und hält Antwortzeiten für APIs sowie dynamische Websites kurz. Wer Protokoll‑Overhead betrachtet, sollte den Transport mit HTTP‑Versionen testen; mein Ausgangspunkt ist HTTP/3 vs. HTTP/2 im Zusammenspiel mit dem gewählten CC‑Verfahren. Für globale Nutzer ziehe ich geringe Latenzspitzen vor, weil Reaktionszeit unmittelbar die wahrgenommene Schnelligkeit prägt.
QUIC und BBR: Einfluss jenseits von TCP
QUIC bringt eigene Staukontrolle auf UDP‑Basis mit und nutzt ähnliche Prinzipien wie BBR, etwa Pacing und RTT‑Beobachtung. In modernen Stacks verschiebt sich Performance damit schrittweise aus TCP heraus in die Applikationsschicht. Das erhöht die Freiheitsgrade, verlangt aber saubere Messung auf Pfad‑, Host‑ und Applikationsebene. Für Planungen empfehle ich, das QUIC-Protokoll unter realen Lastprofilen gegen CUBIC/BBR‑TCP zu spiegeln. So erkenne ich früh, wo die Queue‑Bildung entsteht und wie ich Engpässe über Pacing oder Shaping glätte.
AQM, ECN und Pufferdisziplin: Zusammenspiel mit den Algorithmen
Staukontrolle entfaltet ihre Wirkung erst richtig im Zusammenspiel mit dem Queue‑Management der Netzgeräte. Klassisches Tail‑Drop füllt Puffer bis zum Rand und verwirft dann schlagartig Pakete – Latenzspitzen und Synchronisationseffekte sind die Folge. Active Queue Management (AQM) wie CoDel oder FQ‑CoDel markiert oder verwirft Pakete frühzeitig und verteilt Kapazität fairer über Flüsse. Das kommt allen Verfahren zugute: CUBIC verliert weniger cwnd durch Burst‑Drops, und BBR hält seine Pacing‑Strategie stabiler, weil Queues nicht „aufplatzen“.
ECN (Explicit Congestion Notification) ergänzt dieses Bild. Statt Pakete zu verwerfen, markieren Router Stau mit einem CE‑Bit; Endpunkte drosseln, ohne dass Retransmits nötig sind. Loss‑basierte Algorithmen reagieren damit früher und sanfter, modellbasierte Verfahren wie BBR interpretieren die Signale im Kontext des minimalen RTT. In Rechenzentren ermöglicht DCTCP mit konsequentem ECN sehr niedrige Queuing‑Delays bei hoher Auslastung. Im WAN setze ich ECN selektiv ein: nur wenn Pfade die Markierungen konsistent durchreichen und Middleboxes nicht eingreifen. In gemischten Public‑Netzen gilt weiterhin, AQM sauber zu konfigurieren, statt bloß Puffer zu vergrößern.
Bursts, Offloads und hostseitiges Pacing
Viele Leistungseinbrüche entstehen durch Sende‑Bursts am Host. Große Offloads (TSO/GSO) bündeln Segmente in sehr große Frames; ohne Pacing entladen sich diese Pakete in kurzen Spitzen und füllen Switch‑Queues. Ich stelle unter Linux daher sch_fq oder FQ‑CoDel als default_qdisc ein und nutze Pacing‑Raten, die der CC‑Algorithmus vorgibt. BBR profitiert davon besonders, aber auch CUBIC wird ruhiger. Zu große NIC‑Ring‑Puffer und eine zu hohe txqueuelen verlängern Warteschlangen im Host – ich wähle moderate Werte und beobachte mit tc -s qdisc, ob Drops oder ECN‑Marks dort entstehen.
Auf Empfangsseite beeinflussen GRO/LRO die Latenz von kleinen Flows. Für API‑lastige Workloads lohnt es sich, diese Offloads je nach NIC und Kernel zu testen oder zu drosseln, damit ACKs schneller verarbeitet werden. In Container‑Setups prüfe ich veth‑Paare und Host‑Qdiscs: die Queue lebt am Host‑Interface, nicht im Namespace. Wer cgroups für Bandbreiten‑Management nutzt, sollte Grenzen konsistent zu CC und AQM setzen, sonst entstehen unvorhersehbare Interferenzen zwischen Flows.
Workload‑Profile: kurze Flüsse, Elephants und Streaming
Nicht jede Anwendung verlangt die gleiche Staukontrolle. „Mice“‑Flows (kleine Transfers) dominieren Web‑APIs und dynamische Seiten. Hier zählt, wie schnell die Verbindung in die Nutzphase kommt und wie niedrig die Tail‑Latenzen bleiben. BBR hält Queues flach und begünstigt kurzerlebige Flüsse, während CUBIC solide Mittelwerte bei fairer Kapazitätsaufteilung liefert. Die initiale Fenstergröße (initcwnd) und Delayed‑ACK‑Einstellungen beeinflussen die ersten RTTs: konservative Defaults schützen vor Bursts, dürfen aber die ersten Kilobytes nicht zu stark bremsen.
„Elephant“‑Flows (Backups, Replikation, große Downloads) verlangen stabile Auslastung über lange Zeiträume. CUBIC skaliert hier robust über unterschiedliche RTTs und teilt mit parallelen Flüssen fair. BIC liefert Maximalraten in kontrollierten Netzen mit bekannten Drop‑Mustern, hat aber Nachteile bei Koexistenz. Für Live‑Streaming und Echtzeit‑Interaktion (VoIP, Gaming) vermeide ich stehende Queues konsequent: BBR bleibt erste Wahl, sofern Puffer klein sind und AQM greift. Nagle‑Interaktionen (TCP_NODELAY) und Anwendungs‑Batching spielen hinein: Wer viele kleine Writes erzeugt, sollte Nagle gezielt abschalten und dem Pacing die Feinkörnung überlassen.
Messmethodik: realistische Tests und aussagekräftige Metriken
Gute Entscheidungen brauchen reproduzierbare Messungen. Ich kombiniere synthetische Last mit realen Pfadbedingungen: kontrollierte Emulation von RTT, Jitter und Verlust (z. B. auf Testlinks) plus echte Zielstandorte. Bandbreite messe ich als Goodput und korreliere sie mit RTT‑Verläufen, Retransmits und Out‑of‑Order‑Anteilen. P50/P95/P99‑Latenzen erzählen mehr als Mittelwerte – besonders bei API‑Antwortzeiten und Interaktivität. Für TCP schaue ich mir cwnd‑Verläufe und pacing_rate an und kontrolliere auf Host‑Seite Qdisc‑Statistiken sowie CPU‑Sättigung, damit ich Engpässe korrekt zuordne.
Einzeltests täuschen leicht: parallele Flüsse pro Host und Cross‑Traffic erzeugen realistische Konkurrenzsituationen. Tageszeit, Peering‑Wege und Funkbedingungen variieren; ich wiederhole Messungen in Zeitserien und prüfe Sensitivität gegenüber kleinen Drop‑Raten. Für QUIC spiegel ich identische Workloads gegen TCP, damit Applikations‑ und Transportebene sauber getrennt bewertet werden. Erst wenn Messungen unter Störung stabil bleiben, committe ich eine Wahl in der Produktion.
Häufige Fehlerbilder und schnelle Abhilfen
Konstant steigende RTT unter Last bei gleichzeitigem Goodput‑Einbruch deutet auf Bufferbloat hin: AQM aktivieren, Host‑Pacing schärfen, gegebenenfalls BBR einsetzen. Viele Retransmits ohne klare Drop‑Muster sprechen für Reordering oder ACK‑Kompression – FQ‑basierte Qdiscs und sauberes Pacing helfen. Plötzliche Hänger mit ausbleibenden ACKs verweisen oft auf Path‑MTU‑Probleme; ich aktiviere MTU‑Probing und setze MSS‑Clamping an relevanten Übergängen.
Unfaire Aufteilung zwischen Flüssen zeigt sich, wenn einzelne Verbindungen dauerhaft im Vorteil sind: CUBIC verbessert RTT‑Fairness gegenüber älteren Loss‑Algorithmen, BBR braucht saubere Pufferdisziplin; bei kleinen Puffern kann eine feinere Pacing‑Justierung oder eine Rückkehr zu CUBIC für Koexistenz sorgen. In Container‑Umgebungen entstehen „versteckte“ Queues an veth‑Enden – ohne abgestimmte Qdisc‑ und cgroup‑Limits verschieben sich Staus in den Host, weit entfernt von der Applikation.
Operative Leitplanken: Team‑ und Plattformentscheidungen
Ich verankere Staukontrolle in Plattformstandards: einheitliche Qdisc‑Defaults, definierte CC‑Profile pro Cluster und Playbooks für Abweichungen. Für globale Nutzer trenne ich Workloads nach Latenzsensitivität: Frontend‑APIs prioritär mit BBR und striktem AQM, Bulk‑Transfer mit CUBIC. Telemetrie ist Pflicht: RTT‑Verteilung, Goodput, Retransmits und ECN‑Quoten als Zeitreihen. Änderungen rollt das Team per Prozent‑Experimenten aus und vergleicht P95/P99, nicht nur Durchschnittswerte. So werden CC‑Entscheidungen wiederholbar und nachvollziehbar – und bleiben kein Bauchgefühl.
Checkliste zur Entscheidung
Ich prüfe zuerst RTT‑Spannen und Fehlerquoten, weil sie das Verhalten dominieren. Danach entscheide ich, ob Latenz oder Durchsatz Priorität hat, und teste gezielt gegen diese Metrik. Im nächsten Schritt messe ich Fairness mit parallelen Flüssen, um Überraschungen im Betrieb zu vermeiden. Anschließend kontrolliere ich Puffergrößen, AQM‑Verfahren und Pacing‑Einstellungen am Host sowie an Gateways. Zum Schluss validiere ich unter Last, ob die Wahl mit echten Nutzern und echten Routen trägt.
Kurzbilanz
Reno und NewReno liefern ein klares Referenzverhalten, wirken aber bei langen Pfaden gebremst. CUBIC gehört als Standard in fast jedes Linux‑Hosting, weil es lange RTTs gut nutzt und sich fair verhält. BIC überzeugt in Netzen mit spürbaren Drops, wenn maximale Auslastung wichtiger ist als Nachbarschaft. BBR ermöglicht niedrige Latenzen und konstante Antwortzeiten, verlangt aber Aufmerksamkeit für Puffer und Koexistenz. Wer Ziele, Pfadcharakteristik und Host‑Queues sauber abgleicht, setzt Staukontrolle als echten Hebel für Nutzererlebnis und Kosten ein.
