TCP Congestion Control bepaalt hoe verbindingen bij wisselende netbelasting de gegevenssnelheid aanpassen en hoe algoritmen presteren in echte hostingopstellingen. In deze vergelijking laat ik concrete effecten zien op doorvoer, vertraging en eerlijkheid voor Webhosting, streaming en cloudworkloads.
Centrale punten
Om ervoor te zorgen dat je het artikel doelgericht leest, vat ik de belangrijkste aspecten kort samen en plaats ik alles later in de juiste context. Ik maak een duidelijk onderscheid tussen op verlies gebaseerde en op modellen gebaseerde methoden, omdat beide families heel verschillend reageren. Ik leg uit waarom cwnd, RTT en pacing van invloed zijn op de prestaties en Eerlijkheid beslissen. Ik rangschik meetresultaten, zodat je geen beslissingen op basis van je gevoel hoeft te nemen. Ik sluit af met pragmatische aanbevelingen voor hosting, containers en wereldwijde Gebruikers.
- AIMD stuurt cwnd aan en reageert op verliezen
- CUBIC levert constante prestaties bij grote RTT's
- BBR maakt gebruik van model, vermindert wachtrijen en latentie
- BIC scoort in netwerken met drops
- Hybla versnelt lange verbindingen (satelliet)
Wat congestiecontrole regelt: cwnd, RTT, verlies signalen
Ik begin met de basisprincipes, omdat deze van invloed zijn op elke latere keuze. Het congestievenster (cwnd) beperkt hoeveel bytes zonder bevestiging onderweg zijn, en AIMD vergroot cwnd stapsgewijs totdat er verliezen optreden. RTT bepaalt hoe snel bevestigingen terugkomen en hoe agressief een algoritme kan groeien. Verliesignalen ontstonden vroeger door time-outs en triple-duplicate-ACK's, tegenwoordig tellen ook queue-diepte, minimale RTT en gemeten bottleneck-bandbreedte mee. Wie cwnd, RTT en verliesinterpretatie begrijpt, kan de invloed op doorvoer, vertraging en Jitter meteen beter.
Terugblik: Reno, NewReno en Vegas in het dagelijks leven
Reno maakt in het begin gebruik van Slow Start en gaat daarna over op lineaire toenames, maar halveert de venstergrootte drastisch na verliezen. NewReno herstelt meerdere verliezen per venster efficiënter, wat vooral bij gematigde foutpercentages merkbaar helpt. Vegas meet de verwachte versus de werkelijke doorvoer via de RTT en remt vroeg af om verliezen te voorkomen. Deze voorzichtigheid houdt wachtrijen klein, maar kost doorvoer wanneer op verlies gebaseerde stromen agressiever parallel verzenden. Wie onverklaarbare time-outs of dubbele ACK's ziet, moet eerst Pakketverlies analyseren en vervolgens het algoritme voor de Topologie passend selecteren.
High-BW-RTT: BIC en CUBIC in vergelijking
BIC tast binair de hoogste verliesvrije cwnd af en houdt de snelheid zelfs bij kleine fouten verbazingwekkend constant. In laboratoria met lage latentie en drop-rates rond 10^-4 leverde BIC doorvoersnelheden van meer dan 8 Gbit/s, terwijl klassieke algoritmen schommelden. CUBIC verving BIC als standaard omdat het zijn cwnd via een kubieke tijdfunctie regelt en daardoor beter gebruikmaakt van lange RTT's. De curve groeit na een verliesgebeurtenis eerst matig, versnelt dan merkbaar en wordt weer voorzichtig in de buurt van de laatste maximale snelheid. In netwerken met lange afstanden bereik ik met CUBIC vaak een hogere bezettingsgraad en tegelijkertijd een goede Planbaarheid de latenties.
Modelgebaseerd: BBR, pacing en bufferbloat
BBR gebruikt een model van minimale RTT en gemeten bottleneckbandbreedte, stelt cwnd in op ongeveer het dubbele van het bandbreedte-vertragingsproduct en verdeelt pakketten gelijkmatig. Deze strategie voorkomt overvolle wachtrijen en houdt vertragingen kort, zelfs als er lichte verliezen optreden. In opstellingen met wisselende radiokwaliteit of gemengde paden blijft de goodput hoog, omdat BBR niet reflexmatig op elke drop reageert. Versie 1 wordt als zeer snel beschouwd, maar kan in kleine buffers concurreren met CUBIC en daarbij een enigszins oneerlijke verdeling vertonen. Ik combineer BBR in BBR CUBIC hosting Ik gebruik Landschaften graag voor primaire stromen en laat CUBIC draaien als compatibele fallback.
Satelliet en radio: Hybla, Westwood en PCC
Hybla compenseert de nadelen van hoge RTT's door cwnd te schalen alsof er een korte referentie-RTT is. Hierdoor stijgen lange afstanden, zoals satelliet, veel sneller naar bruikbare snelheden en blijven ze daar ook betrouwbaar. Westwood schat de beschikbare bandbreedte op basis van de ACK-snelheden en vermindert cwnd na verliezen minder sterk, wat helpt in radiocommunicatienetwerken met willekeurige fouten. PCC gaat nog een stap verder en optimaliseert een gebruikswaarde via korte experimenten, waardoor het hoge goodput-latentiecombinaties kan bereiken. In heterogene netwerken met Mobiliteit Ik test Hybla en Westwood bij voorkeur voordat ik uitgebreide QoS-regels toepas.
Prestatievergelijking: meetwaarden en eerlijkheid
Vergelijkingen laten duidelijk verschillende profielen zien wanneer latentie en foutpercentages variëren. Bij een lage RTT domineert BIC vaak de pure doorvoersnelheid, terwijl CUBIC een betrouwbare mix van snelheid en gedrag in de loop van de tijd biedt. Bij zeer lange RTT's scoort CUBIC duidelijk beter dan Reno en NewReno, omdat het de wachttijden beter vertaalt in groei. BBR houdt wachtrijen leeg en levert constant lage vertragingen, maar genereert, afhankelijk van de buffergrootte, meer hertransmissies. Voor parallelle stromen laat CUBIC meestal een eerlijke verdeling zien, BIC houdt de lijn graag dicht bij de Capaciteit.
| Algoritme | Principe | Sterkte | zwakte | Aanbevolen voor |
|---|---|---|---|---|
| Reno / NewReno | Op verlies gebaseerd, AIMD | Eenvoudig gedrag | Langzaam bij hoge RTT | Legacy-stacks, Problemen oplossen |
| Vegas | Op RTT gebaseerd | Vroegtijdige vermijding van files | Lagere doorvoer | Constante latentie |
| BIC | Binaire zoekopdracht | Hoge goodput bij drops | Agressief tegen anderen | Lage RTT, foutpercentages |
| CUBIC | Kubische tijdfunctie | Goede eerlijkheid | Verspreiding bij Drops | Lange paden, datacenters |
| BBR | Modelgebaseerd, pacing | Lage latentie | Oneerlijk in kleine buffers | Hosting, wereldwijde gebruikers |
| Hybla | RTT-compensatie | Snelle opstart | Speciaal geval | Satelliet, Maritiem |
Praktische gids: selectie op basis van latentie, verlies en doel
Ik begin elke beslissing met duidelijke doelstellingen: lage latentie, maximale goodput of evenwicht voor veel stromen. Bij strikt beperkte buffergroottes en gevoelige latentie-eisen kies ik eerst voor BBR. Als lange paden domineren en meerdere hosts naast elkaar bestaan, is CUBIC onontkoombaar. In netwerken met goed waarneembare drop-patronen levert BIC nog steeds indrukwekkende snelheden, mits eerlijkheid van ondergeschikt belang is. Voor satelliet en zeer hoge RTT-padkosten neemt Hybla typische ramp-up-nadelen weg en zorgt het voor snelle laadvermogen.
Linux, Windows en containers: activering en afstemming
Onder Linux controleer ik met sysctl net.ipv4.tcp_congestion_control het actieve algoritme en pas ik dit gericht toe met sysctl net.ipv4.tcp_congestion_control=bbr. Voor CUBIC houd ik rekening met kernel-standaardinstellingen, maar pas ik net.core.default_qdisc en pacing-parameters aan wanneer ik host-queues ontlast. In containers breng ik instellingen over naar de host, omdat namespaces niet elke wachtrij isoleren. Onder Windows vanaf de huidige versies kan BBR in geschikte edities worden geactiveerd, terwijl oudere systemen CUBIC of Compound blijven gebruiken. Zonder solide systeem- en Wachtrij-instellingen verliest elk algoritme merkbaar aan effectiviteit.
Webhostingperspectief: multi-flow-fairness en goodput
In hostingclusters telt het totaal van vele gelijktijdige stromen, niet de beste waarde van een enkele overdracht. CUBIC houdt verbindingen voorspelbaar en verdeelt de capaciteit meestal eerlijk, wat gunstig is voor dichte multi-tenant-scenario's. BBR vermindert wachtrijen en houdt de responstijden voor API's en dynamische websites kort. Wie kijkt naar protocol-overhead, moet het transport testen met HTTP-versies; mijn uitgangspunt is HTTP/3 vs. HTTP/2 in combinatie met de gekozen CC-methode. Voor wereldwijde gebruikers geef ik de voorkeur aan lage latentiepieken, omdat de reactietijd direct invloed heeft op de waargenomen Snelheid beïnvloedt.
QUIC en BBR: invloed buiten TCP
QUIC heeft zijn eigen UDP-gebaseerde congestiecontrole en maakt gebruik van vergelijkbare principes als BBR, zoals pacing en RTT-observatie. In moderne stacks verschuift de prestatie daarmee geleidelijk van TCP naar de applicatielaag. Dat vergroot de vrijheid, maar vereist wel nauwkeurige metingen op pad-, host- en applicatieniveau. Voor de planning raad ik aan om de QUIC-protocol te vergelijken met CUBIC/BBR‑TCP onder reële belastingsprofielen. Zo kan ik vroegtijdig zien waar er wachtrijen ontstaan en hoe ik knelpunten kan oplossen door middel van pacing of Vormgeven gladheid.
AQM, ECN en bufferdiscipline: interactie met de algoritmen
Congestiecontrole komt pas echt tot zijn recht in combinatie met het wachtrijbeheer van de netwerkapparaten. Bij klassieke tail drop worden buffers tot de rand gevuld en worden vervolgens pakketten abrupt verwijderd, met latentiepieken en synchronisatie-effecten tot gevolg. Active Queue Management (AQM) zoals CoDel of FQ-CoDel markeert of verwerpt pakketten vroegtijdig en verdeelt de capaciteit eerlijker over stromen. Dat komt alle processen ten goede: CUBIC verliest minder cwnd door burst-drops en BBR behoudt zijn PacingStrategie stabieler, omdat wachtrijen niet „openbarsten“.
ECN (Explicit Congestion Notification) vult dit beeld aan. In plaats van pakketten te verwijderen, markeren routers congestie met een CE-bit; eindpunten vertragen zonder dat hertransmissies nodig zijn. Op verlies gebaseerde algoritmen reageren hierdoor eerder en soepeler, terwijl op modellen gebaseerde methoden zoals BBR de signalen interpreteren in de context van de minimale RTT. In datacenters maakt DCTCP met consistente ECN zeer lage wachtrijvertragingen mogelijk bij hoge bezettingsgraad. In het WAN gebruik ik ECN selectief: alleen als paden de markeringen consistent doorgeven en middleboxes niet ingrijpen. In gemengde openbare netwerken blijft het belangrijk om AQM correct te configureren in plaats van alleen de buffers te vergroten.
Bursts, offloads en host-side pacing
Veel prestatieverlies wordt veroorzaakt door verzendbursts op de host. Grote offloads (TSO/GSO) bundelen segmenten in zeer grote frames; zonder Pacing Deze pakketten worden in korte pieken gelost en vullen switch-wachtrijen. Daarom stel ik onder Linux sch_fq of FQ-CoDel in als default_qdisc en gebruik ik pacing-snelheden die door het CC-algoritme worden voorgeschreven. BBR profiteert hier bijzonder van, maar ook CUBIC wordt rustiger. Te grote NIC-ringbuffers en een te hoge txqueuelen verlengen wachtrijen in de host – ik kies gematigde waarden en kijk met tc -s qdisc of er drops of ECN-marks ontstaan.
Aan de ontvangstzijde beïnvloeden GRO/LRO de latentie van kleine flows. Voor API-intensieve workloads is het de moeite waard om deze offloads te testen of te beperken, afhankelijk van de NIC en kernel, zodat ACK's sneller worden verwerkt. In containeropstellingen controleer ik veth-paren en host-Qdiscs: de wachtrij bevindt zich op de hostinterface, niet in de naamruimte. Wie cgroups gebruikt voor bandbreedtebeheer, moet consistent grenzen instellen voor CC en AQM, anders ontstaat er onvoorspelbare interferentie tussen flows.
Werkbelastingsprofielen: korte stromen, elephants en streaming
Niet elke toepassing vereist dezelfde congestiecontrole. „Mice“-stromen (kleine overdrachten) domineren web-API's en dynamische pagina's. Hier telt hoe snel de verbinding in de gebruiksfase komt en hoe laag de tail-latenties blijven. BBR houdt wachtrijen plat en bevordert kortstondige stromen, terwijl CUBIC solide gemiddelden levert bij een eerlijke capaciteitsverdeling. De initiële venstergrootte (initcwnd) en Delayed-ACK-instellingen beïnvloeden de eerste RTT's: conservatieve standaardinstellingen beschermen tegen bursts, maar mogen de eerste kilobytes niet te sterk vertragen.
„Elephant“-stromen (back-ups, replicatie, grote downloads) vereisen een stabiele belasting gedurende lange perioden. CUBIC schaalt hier robuust over verschillende RTT's en deelt eerlijk met parallelle stromen. BIC levert maximale snelheden in gecontroleerde netwerken met bekende drop-patronen, maar heeft nadelen bij co-existentie. Voor livestreaming en realtime interactie (VoIP, gaming) vermijd ik consequent wachtrijen: BBR blijft de eerste keuze, mits de buffers klein zijn en AQM werkt. Nagle-interacties (TCP_NODELAY) en applicatie-batching spelen een rol: wie veel kleine writes genereert, moet Nagle doelgericht uitschakelen en de pacing aan de fijne korrel overlaten.
Meetmethodologie: realistische tests en betekenisvolle statistieken
Goede beslissingen vereisen reproduceerbare metingen. Ik combineer synthetische belasting met echte padcondities: gecontroleerde emulatie van RTT, jitter en verlies (bijvoorbeeld op testlinks) plus echte doeladressen. Ik meet bandbreedte als goodput en correleer deze met RTT-verloop, hertransmissies en out-of-order-percentages. P50/P95/P99-latenties zeggen meer dan gemiddelden, vooral bij API-responstijden en interactiviteit. Voor TCP bekijk ik cwnd-verloop en pacing_rate en controleer ik aan de hostzijde Qdisc-statistieken en CPU-verzadiging, zodat ik knelpunten correct kan toewijzen.
Afzonderlijke tests kunnen misleidend zijn: parallelle stromen per host en cross-traffic creëren realistische concurrentiesituaties. Het tijdstip van de dag, peering-routes en radio-omstandigheden variëren; ik herhaal metingen in tijdreeksen en controleer de gevoeligheid voor kleine drop-rates. Voor QUIC vergelijk ik identieke workloads met TCP, zodat het applicatie- en transportniveau duidelijk gescheiden worden beoordeeld. Pas als de metingen stabiel blijven onder storingen, neem ik een beslissing over de productie.
Veelvoorkomende fouten en snelle oplossingen
Een constant stijgende RTT onder belasting in combinatie met een daling van de goodput duidt op Bufferbloat hin: AQM activeren, host-pacing aanscherpen, indien nodig BBR gebruiken. Veel retransmissies zonder duidelijke drop-patronen pleiten voor reordering of ACK-compressie – FQ-gebaseerde Qdiscs en nette pacing helpen. Plotselinge vertragingen met ontbrekende ACK's duiden vaak op Path-MTU-problemen; ik activeer MTU-probing en stel MSS-clamping in op relevante overgangen.
Oneerlijke verdeling tussen streams komt tot uiting wanneer individuele verbindingen permanent in het voordeel zijn: CUBIC verbetert RTT-eerlijkheid ten opzichte van oudere Loss-algoritmen, BBR vereist een strikte bufferdiscipline; bij kleine buffers kan een fijnere aanpassing van de pacing of een terugkeer naar CUBIC zorgen voor coëxistentie. In containeromgevingen ontstaan „verborgen“ wachtrijen aan veth-uiteinden – zonder afgestemde Qdisc- en cgroup-limieten verschuiven congesties naar de host, ver weg van de applicatie.
Operationele richtlijnen: beslissingen over teams en platforms
Ik veranker congestiecontrole in platformstandaarden: uniforme Qdisc-standaardinstellingen, gedefinieerde CC-profielen per cluster en playbooks voor afwijkingen. Voor wereldwijde Gebruikers Ik scheid workloads op basis van latentiegevoeligheid: frontend-API's krijgen prioriteit met BBR en strikte AQM, bulktransfers met CUBIC. Telemetrie is verplicht: RTT-distributie, goodput, retransmissies en ECN-quota als tijdreeksen. Het team implementeert wijzigingen via procentuele experimenten en vergelijkt P95/P99, niet alleen gemiddelde waarden. Zo worden CC-beslissingen herhaalbaar en traceerbaar – en blijven ze geen onderbuikgevoel.
Checklist voor de beslissing
Ik controleer eerst RTT-spannen en foutpercentages, omdat deze het gedrag domineren. Vervolgens besluit ik of latentie of doorvoer prioriteit heeft en test ik gericht op basis van deze metriek. In de volgende stap meet ik de eerlijkheid met parallelle stromen om verrassingen tijdens het gebruik te voorkomen. Vervolgens controleer ik de buffergroottes, AQM-procedures en pacing-instellingen op de host en op gateways. Ten slotte valideer ik onder belasting of de keuze met echte gebruikers en echte Routes draagt.
Korte balans
Reno en NewReno leveren een duidelijk referentiegedrag, maar werken bij lange paden vertragend. CUBIC behoort standaard tot bijna elke Linux-hosting, omdat het goed gebruikmaakt van lange RTT's en zich eerlijk gedraagt. BIC overtuigt in netwerken met merkbare drops, wanneer maximale benutting belangrijker is dan nabijheid. BBR maakt lage latenties en constante responstijden mogelijk, maar vereist aandacht voor buffers en coëxistentie. Wie doelen, padkenmerken en hostwachtrijen goed op elkaar afstemt, zet congestiecontrole in als echte Hendel voor gebruikerservaring en kosten.
