{"id":20348,"date":"2026-08-05T11:52:51","date_gmt":"2026-08-05T09:52:51","guid":{"rendered":"https:\/\/webhosting.de\/tcp-bbr-congestion-control-webserver-optimierung-bandbreite\/"},"modified":"2026-08-05T11:52:51","modified_gmt":"2026-08-05T09:52:51","slug":"tcp-bbr-congestiebeheersing-webserveroptimalisatie-bandbreedte","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/tcp-bbr-congestion-control-webserver-optimierung-bandbreite\/","title":{"rendered":"TCP BBR: moderne congestiebeheersing voor snellere webservers"},"content":{"rendered":"<p>TCP BBR versnelt webservers door de beschikbare bandbreedte en de minimale RTT te modelleren en de gegevensstroom dynamisch aan te passen. Ik gebruik <strong>TCP BBR<\/strong> om een hoge benuttingsgraad te combineren met een lage latentie en de laadtijden onder re\u00eble belasting merkbaar te verkorten.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Modelgebaseerd<\/strong>: BBR regelt op basis van bandbreedte en minimale RTT in plaats van op basis van pakketverlies.<\/li>\n  <li><strong>Minder latentie<\/strong>: Actieve pacing zorgt ervoor dat wachtrijen klein blijven en reactietijden laag zijn.<\/li>\n  <li><strong>Hogere doorvoer<\/strong>: Hoge verzendfrequentie bij een gelijkmatig verzendprofiel.<\/li>\n  <li><strong>HTTP\/2\/3<\/strong>: Multiplexing profiteert van korte wachtrijen en weinig jitter.<\/li>\n  <li><strong>Geschikt voor Linux<\/strong>: Vanaf kernel 4.9 eenvoudig in te schakelen en goed meetbaar.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-rechenzentrum-4392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat is TCP BBR? De basisprincipes in het kort uitgelegd<\/h2>\n\n<p>Ik werk met BBR als congestiecontrole-algoritme, dat de <strong>Knelpuntbandbreedte<\/strong> (BtlBw) en de minimale round-trip propagation time (RTprop) schat, om de juiste hoeveelheid gegevens tijdens de vlucht te behouden. In plaats van te wachten op pakketverlies, meet BBR continu de leveringssnelheden en werkt het zijn padmodel in korte cycli bij. Hieruit bereken ik effectief het bandbreedte-vertragingsproduct, dat wil zeggen hoeveel bytes er tegelijkertijd onderweg zouden moeten zijn om de verbinding volledig te benutten zonder te lange wachtrijen. Het resultaat heeft direct invloed op de data die in de pijplijn zit en op de pacing, zodat pakketten met regelmatige tussenpozen en volgens de beoogde snelheid worden verzonden. Zo bereik ik in typische webomgevingen een hoge benutting, korte wachtrijen en betrouwbaardere responstijden met <strong>lager<\/strong> Variantie.<\/p>\n\n<h2>BBR versus CUBIC: waarom het gedrag verandert<\/h2>\n\n<p>In tegenstelling tot CUBIC of Reno beschouwt BBR verliezen niet als een centraal stuursignaal, maar hanteert het een <strong>modellen<\/strong> Een bedrijfsdoelstelling die dicht bij het optimum ligt wat betreft doorvoer en latentie. Op verlies gebaseerde methoden vullen vaak grote buffers, wat latentiepieken en \u201ebufferbloat\u201c in de hand werkt, terwijl BBR met actieve pacing de wachtrij aan de BDP koppelt. Hierdoor zie ik bij HTTP-workloads met veel gelijktijdig geopende verbindingen een gelijkmatiger leveringssnelheid en een snellere TTFB. Zelfs op lange afstanden met een hoge RTT houdt BBR de wachtrijen doorgaans korter, omdat het algoritme doelgericht op de RTprop-drempel werkt. Waar CUBIC cyclisch overschrijdt en door verliezen afremt, zoekt BBR een stabiel punt met <strong>kleine<\/strong> schommelingen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_bbr_besprechung_webserver_2847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zo werkt BBR intern: statussen en cycli<\/h2>\n\n<p>In het begin verhoogt BBR tijdens het opstarten het zendvermogen sterk, totdat de gemeten doorvoersnelheid stagneert en het knelpunt zichtbaar wordt, wat de <strong>BtlBw<\/strong>-schatting verfijnt. Daarna volgt een \u2018drain\u2019, waarbij het algoritme de vluchtcapaciteit vermindert om overvolle wachtrijen leeg te maken en dicht bij de BDP uit te komen. Bij continu gebruik maakt ProbeBW gebruik van een cyclisch gain-plan, waarbij kortstondig iets boven de schatting wordt verzonden en vervolgens iets eronder, om nieuwe maxima te vinden. ProbeRTT dwingt regelmatig een kleine in-flight-hoeveelheid af om nieuwe minimale RTT-waarden te verkrijgen en drift te voorkomen. Deze reeks houdt de verbinding bezet zonder wachtrijen onnodig te vullen, wat <strong>Latency<\/strong> en jitter zichtbaar kan verminderen.<\/p>\n\n<h2>Concrete gevolgen voor webservers en API's<\/h2>\n\n<p>In webomgevingen verminder ik met BBR de latentie bij hoge belasting, omdat inflight-gegevens en pacing de wachtrijen klein houden en de time-to-first-byte daalt, vooral bij veel gelijktijdige verzoeken met <strong>middelgrote<\/strong> Antwoorden. Grote downloads en streamingverkeer profiteren van een hoge overdrachtssnelheid, die zich zelfs bij wisselende routes sneller stabiliseert. HTTP\/2 multiplexeert meerdere streams per verbinding, waardoor een gelijkmatige congestiecontrole onmiddellijk effect heeft op alle deelstromen. Voor HTTP\/3 via QUIC gelden vergelijkbare principes, aangezien veel implementaties eveneens bandbreedte en RTT modelleren. Wie de verschillen beter wil begrijpen, kan mijn korte <a href=\"https:\/\/webhosting.de\/nl\/tcp-congestiecontrole-effecten-vergelijking-latentie\/\">Vergelijking van de latentie<\/a> tussen procedures, waarbij aandacht wordt besteed aan het p95- en p99-gedrag onder <strong>Druk<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-bbr-speedy-web-servers-3548.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eerlijkheid, bijwerkingen en waar ik op let<\/h2>\n\n<p>BBR kan in gemengde omgevingen dominanter lijken dan op verlies gebaseerde flows, vooral wanneer de buffers diep zijn en de <strong>Verkenning<\/strong> op een krachtige manier plaatsvindt. Daarom houd ik bij migraties de bandbreedteverdeling tussen CUBIC- en BBR-stromen in de gaten en pas ik deze indien nodig aan. Onjuist gekozen parameters en ongeschikte buffering verhogen in uitzonderlijke gevallen de latentie en jitter, hoewel de doorvoersnelheid hoog blijft. De monitoring moet daarom tegelijkertijd de leveringssnelheid, RTT-spanningen en staartlatenties evalueren, en niet alleen megabit per seconde. Wie fairness-problemen constateert, test BBRv2-varianten of beperkt de <strong>Versterking<\/strong>-pieken zijn gematigd.<\/p>\n\n<h2>TCP BBR onder Linux inschakelen<\/h2>\n\n<p>In moderne Linux-kernels vanaf versie 4.9 schakel ik BBR zonder veel moeite in, controleer ik de beschikbare algoritmen met \u201enet.ipv4.tcp_available_congestion_control\u201c en laad ik indien nodig de module \u201etcp_bbr\u201c voordat ik \u201enet.ipv4.tcp_congestion_control = bbr\u201c instel en \u201efq\u201c als standaard-Qdisc activeer, om een soepele <strong>Pacing<\/strong> vast te leggen. Ik sla de waarden permanent op in sysctl-configuraties en controleer na een herstart of de kernel ze overneemt. Voor HTTP\/2 verlaag ik vaak \u201enet.ipv4.tcp_notsent_lowat\u201c, zodat prioritering en pacing snel ingrijpen zonder dat er grote hoeveelheden niet-verzonden gegevens worden opgestapeld. Daarnaast houd ik rekening met de offloading-functies van de NIC\u2019s en stel ik de pacing-timers nauwkeurig genoeg in, zodat de doelsnelheid in kleine intervallen stabiel blijft. Wie de end-to-end-doorvoer nog verder wil verhogen, houdt bovendien rekening met <a href=\"https:\/\/webhosting.de\/nl\/server-tcp-window-schaling-doorvoer-optimalisatie-netwerk-tuning\/\">TCP Venster Schalen<\/a> voor producten met een hoge bandbreedte-looptijd in <strong>Langeafstandsverkeer<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Schakelaar\/module<\/th>\n      <th>Doel<\/th>\n      <th>Typische waarde<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.ipv4.tcp_congestion_control<\/td>\n      <td>Actief algoritme voor TCP<\/td>\n      <td>bbr<\/td>\n    <\/tr>\n    <tr>\n      <td>net.core.default_qdisc<\/td>\n      <td>Pacing-vriendelijke wachtrijdiscipline<\/td>\n      <td>fq<\/td>\n    <\/tr>\n    <tr>\n      <td>tcp_bbr (kernelmodule)<\/td>\n      <td>BBR-implementatie laden<\/td>\n      <td>modprobe tcp_bbr<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_notsent_lowat<\/td>\n      <td>Het aantal niet-verzonden bytes beperken<\/td>\n      <td>bijv. 16 KB<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Webserver-optimalisatie: Nginx, Apache en prioritering<\/h2>\n\n<p>Ik combineer BBR met \u201efq\u201c, geef op een zinvolle manier prioriteit aan HTTP\/2-streams en houd de outputbuffers klein, zodat de <strong>Server<\/strong>-Het antwoord komt snel binnen. In Nginx pas ik gematigde `sendfile`- en `tcp_nodelay`-strategie\u00ebn toe die goed samengaan met `pacing`, en test ik tegelijkertijd de grootte van TLS-records op segmentatie-effecten. Apache profiteert eveneens van kleine buffergroottes, een nette keepalive en een rustig schrijfpatroon dat de BBR-doelsnelheid niet verstoort. Voor het opbouwen van verbindingen en vroege bytes kan ik <a href=\"https:\/\/webhosting.de\/nl\/tcp-fast-open-verminderde-latentie-hosting-netwerkoptimalisatie-snelheid\/\">TCP Fast Open<\/a> inzetten om de TTFB in geschikte scenario\u2019s te verlagen. Cachehi\u00ebrarchie\u00ebn vangen pieken op, terwijl BBR de beschikbare capaciteit op een gecontroleerde manier benut en <strong>Latency<\/strong> in de stroom houdt.<\/p>\n\n<h2>HTTP\/2 en HTTP\/3: multiplexing en pacing<\/h2>\n\n<p>Door multiplexing leidt een opstopping in een TCP-verbinding onmiddellijk tot wachttijden voor alle streams, en daarom is gecontroleerde <strong>Pacing<\/strong> zo waardevol is. BBR zorgt hier voor een gelijkmatige snelheid, waardoor \u2018head-of-line\u2019-vertragingen minder snel escaleren. Bij HTTP\/3 verplaatsen QUIC-stacks de besturing naar de gebruikersruimte, maar veel daarvan maken gebruik van vergelijkbare meet- en modelconcepten. Bij QUIC-implementaties controleer ik de parameters voor bandbreedte-inschatting en idle-time-outs, zodat de padmodellen actueel blijven. Wie protocollen combineert, meet afzonderlijk per protokolfamilie om interferenties en specifieke <strong>Afstemmen<\/strong>-Behoeften zichtbaar maken.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_bbr_webserver_3052.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BBR-varianten: v1 versus v2 in de praktijk<\/h2>\n\n<p>In de praktijk maak ik onderscheid tussen BBRv1 (vroege kernelgeneraties) en BBRv2 (nieuwere backports en hoofdtakken). BBRv2 reageert beter op verliezen en gemarkeerde congestiesignalen, en komt bij concurrentie dichterbij <strong>eerlijker<\/strong> aan CUBIC en vermindert de inflight-hoeveelheid agressiever wanneer het pad tekenen van overbelasting vertoont. Bij paden met policing of willekeurige drops blijft v2 vaak stabieler, omdat de probing-pieken gerichter worden gedoseerd. Als ik overmatige dominantie ten opzichte van op verlies gebaseerde flows zie, test ik eerst v2-varianten voordat ik de gain-parameters handmatig aanpas. In datacenters met homogene paden en duidelijke SLO\u2019s werkt v1 nog steeds goed; in gemengde WAN-omgevingen verwacht ik met v2 een <strong>zachter<\/strong> Co\u00ebxistentie.<\/p>\n\n<h2>ECN, AQM en wachtrijdisciplines: de onderlinge samenhang begrijpen<\/h2>\n\n<p>Ik zie BBR graag in combinatie met \u201efq\u201c op de host, omdat de per-flow-pacingklok stabiel werkt. Op upstream-routers pas ik, waar mogelijk, Active Queue Management (bijv. CoDel\/PIE) toe om stilstaande wachtrijen te beperken. Als de infrastructuur ECN markeert, kan BBRv2 deze signalen gebruiken en het aantal pakketten in de lucht verminderen zonder te wachten op harde verliezen. Een zuivere end-to-end-configuratie is belangrijk: Halfslachtige ECN-activering of asymmetrische paden veroorzaken tegenstrijdige signalen en verhogen de jitter. Ik controleer daarom of de paden ECN-pakketten doorlaten en vergelijk de latentiebandbreedtes bij identieke belasting met en zonder ECN. Op de server blijft \u201efq\u201c mijn standaard-Qdisc; \u201efq_codel\u201c gebruik ik doelgericht op knelpunten waar actieve AQM-logica pakketten kort moet vasthouden en flow-fairness buiten de host-pacing moet ondersteunen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcpbbr-techoffice-6298.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Offloads, timers en CPU-kosten: een soepele pacing in de praktijk<\/h2>\n\n<p>Pacing vereist een nauwkeurige tijdsregeling. Daarom stel ik de pacing-timers nauwkeurig genoeg in en controleer ik of de netwerkkaart multiqueue ondersteunt en of de IRQ\u2019s\/queues op een zinvolle manier over de CPU-kernen zijn verdeeld. GSO\/TSO\/GRO blijven <strong>actief<\/strong>, BBR regelt het tempo toch correct, omdat \u201efq\u201c grote segmenten in de tijd spreidt. Problematisch zijn echter te grove tijdquanta, die tot bursts leiden, of sterke coalescing in de NIC, die jitter veroorzaakt. Ik schakel offloading-functies niet zomaar uit, maar meet of ze de doelsnelheid verstoren. Bij een hoge verbindingsbelasting let ik op de CPU-kosten van de pacing: veel kleine verzendgebeurtenissen verhogen de PPS. Ik gebruik XPS\/RPS, stel irqbalance of vaste affiniteiten in om de cache-localiteit te behouden, en let op \u201esoftirq\u201c-pieken. Als de host CPU-beperkt raakt, schakel ik over op iets grotere TLS-records en bundel ik schrijfbewerkingen, zonder de <strong>Reactietijd<\/strong> de app te verslechteren.<\/p>\n\n<h2>Containers, Kubernetes en cloudomgevingen<\/h2>\n\n<p>In Kubernetes beheer ik BBR en Qdiscs <strong>op de hele host<\/strong>. Pod-lokale \u201etc\u201c-regels zijn pas van kracht als het onderliggende apparaat ze ook gebruikt; bij veth-paren moet ik de juiste kant kiezen. \u201ehostNetwork\u201c-pods profiteren direct van de host-Qdisc. In multi-tenant-opstellingen botst BBR met egress-policers of traffic-shapers die burst-groottes beperken. Daarom controleer ik de snelheidslimieten van cloud-instanties (bijv. per NIC-type) en kijk ik of de piekwaarden van BBR tegen policers aanlopen en hertransmissies activeren. Load-balancers en proxys segmenteren verbindingen; ik controleer telkens aan de serverzijde de TCP-stack achter de laatste hop, omdat de congestiecontrole daar daadwerkelijk werkt. Cross-AZ\/regio-paden met een langere RTT laten het voordeel van BBR bijzonder goed zien, mits de CPU- en NIC-reserves op peil zijn.<\/p>\n\n<h2>Testmethodiek en hulpmiddelen: betrouwbare vergelijkingen<\/h2>\n\n<p>Ik vergelijk BBR met CUBIC aan de hand van reproduceerbare workloads. A\/B-Canaries leveren re\u00eble responstijden op, terwijl synthetische tests grenswaarden aangeven. \u201eh2load\u201c en \u201ewrk2\u201c belasten HTTP\/2\/1.1 op deterministische wijze; \u201eiperf3\u201c toont de ruwe doorvoer en kan bidirectioneel meten. Met \u201etc netem\u201c simuleer ik extra RTT en willekeurige verliezen om gedragsveranderingen in een vroeg stadium te signaleren. Op de host controleer ik met \u201ess -ti\u201c of BBR actief is en hoe cwnd\/inflight zich gedragen, en met \u201etc -s qdisc\u201c of \u201efq\u201c pakketten zoals verwacht pacet. eBPF-gebaseerde tools tonen hertransmissies, RTT-verdelingen en pacing-snelheden zonder hoge overhead. Cruciaal is de <strong>Correlatie<\/strong> van netwerkstatistieken met app-KPI's: p95\/p99-latentie, foutpercentages en TTFB. Alleen zo kan ik vaststellen of een toename van de doorvoer daadwerkelijk de gebruikerservaring en de SLO's verbetert.<\/p>\n\n<h2>Checklist voor probleemoplossing en veelvoorkomende valkuilen<\/h2>\n\n<ul>\n  <li>Qdisc controleren: Is \u201enet.core.default_qdisc = fq\u201c ingeschakeld en aan het juiste apparaat gekoppeld? Komen de \u201etc\u201c-tellers overeen met het verkeer?<\/li>\n  <li>BBR daadwerkelijk in gebruik: geeft \u201enet.ipv4.tcp_congestion_control\u201c \u201ebbr\u201c weer en vertonen verbindingen in \u201ess -ti\u201c de juiste cwnd\/inflight-patronen?<\/li>\n  <li>Pacing-bursts: leiden grove timers of sterke coalescing tot jitter? Controleer dit met kleinere offload-bursts en een fijnere pacing-granulariteit.<\/li>\n  <li>Policer\/rate-limits: wanneer er pieken in het verzoekverkeer tegen krappe tokenbuckets aanlopen, ontstaan er drops en retransmissies. Stel de inflight- en gain-parameters conservatiever in.<\/li>\n  <li>Bufferbloat in de upstream: wanneer wachtrijen buiten de host groeien, hebben host-tuningmaatregelen slechts een beperkt effect. Pas AQM\/ECN toe op het knelpunt.<\/li>\n  <li>HTTP\/2-prioritering: te grote outputbuffers ondermijnen de pacing. Pas \u201enet.ipv4.tcp_notsent_lowat\u201c aan en verklein de serverbuffers.<\/li>\n  <li>Kernel-\/stuurprogramma-versies: Afzonderlijke kernelreleases wijzigen de BBR-gegevens. Documenteer de wijzigingen en controleer deze aan de hand van meetwaarden.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-bbr-webserver-4672.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uitrolstrategie, SLO\u2019s en beveiliging<\/h2>\n\n<p>Ik stel duidelijke streefwaarden vast: p95\/99-latentie, doorvoer per kern, foutpercentages en eerlijkheid ten opzichte van het bestaande verkeer. Een pilot begint op een klein aantal hosts met identieke workloads en een zuivere controlegroep. Ik observeer de statistieken over meerdere belastingpatronen (piek, inactiviteit, back-ups) en gedurende meerdere dagen om dagelijkse cycli en randgevallen in kaart te brengen. Daarna verhoog ik het aandeel stapsgewijs, zorg ik dat er een snelle rollback klaarstaat en zet ik kernel-\/moduleversies vast totdat het effect stabiel is aangetoond. Ik sla configuraties op met versienummers en controleer ze regelmatig, zodat latere updates de <strong>kwaliteit<\/strong> niet onopgemerkt doorvoeren. In Teams stem ik BBR-wijzigingen af met de verantwoordelijken voor apps, platforms en netwerken, omdat pacing, prioritering en caches met elkaar verweven zijn.<\/p>\n\n<h2>Wanneer BBR uitblinkt \u2013 en wanneer ik voorzichtig test<\/h2>\n\n<p>In datacenters met up-to-date kernels, wereldwijde gebruikersbestanden en veel parallelle HTTP\/2-verbindingen levert BBR regelmatig een hoge effici\u00ebntie bij <strong>lager<\/strong> Latentie. Lange RTT\u2019s en diepe buffers bezorgen CUBIC vaak problemen, terwijl BBR met gematigde wachtrijen soepeler werkt. Gevoelige realtime-workloads of sterk gemengde algoritmische omgevingen test ik daarentegen voorzichtig. Hier meet ik fairness, staartlatenties en reactiegedrag bij pakketverlies afzonderlijk en pas ik de parameters iteratief aan. Pas wanneer de statistieken stabiel lijken, verhoog ik het uitrolpercentage en bescherm ik daarbij de <strong>Voorraad<\/strong>-werklasten.<\/p>\n\n<h2>Praktijkgids: proefprojecten opzetten, opschalen, veiligstellen<\/h2>\n\n<p>Ik start een proefproject met geselecteerde hosts, schakel BBR in, neem \u201efq\u201c in gebruik en stel duidelijke <strong>Doelen<\/strong> voor doorvoer en p95-latentie. Vervolgens vergelijk ik identieke workloads met controlegroepen die CUBIC gebruiken, om daadwerkelijke verbeteringen te kwantificeren. Ik voer de uitrol stapsgewijs door en documenteer kernelversies, sysctl-profielen en waargenomen drempelwaarden voor de statistieken. Bij afwijkingen maak ik gebruik van vooraf geteste parametersets, zoals conservatievere gains of strengere \u201enotsent_lowat\u201c-waarden. Na succesvolle schaalvergroting voer ik audits uit, zodat kernel-updates, stuurprogramma\u2019s en firmware de <strong>kwaliteit<\/strong> niet stiekem verplaatsen.<\/p>\n\n<h2>Korte versie voor admins<\/h2>\n\n<p>BBR modelleert de bandbreedte en de minimale RTT, houdt de vluchtcapaciteit dicht bij de BDP en regelt het tempo nauwkeurig, waardoor de doorvoer en <strong>Latency<\/strong> tegelijkertijd profiteren. Webservers met veel parallelle verbindingen reageren sneller, grote overdrachten verlopen soepeler en HTTP\/2\/3-stromen delen de capaciteit effici\u00ebnt. Onder Linux activeer ik BBR met een paar sysctl-schakelaars, stel ik \u201efq\u201c in en let ik op een nette prioritering en slanke outputbuffers. De monitoring richt zich op de leveringssnelheid, p95\/p99-RTT en fairness, niet alleen op megabits of gigabits. Wie stapsgewijs te werk gaat, meet, bijstelt en consequent documenteert, haalt met BBR merkbare <strong>Prestaties<\/strong>-Voordelen zonder extra hardware.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP BBR is een modern algoritme voor congestiebeheer dat bandbreedte en RTT modelleert om webservers effici\u00ebnter te maken. Ontdek hoe TCP BBR werkt, welke voordelen het biedt en hoe je het onder Linux kunt inschakelen.<\/p>","protected":false},"author":1,"featured_media":20341,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"79","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP BBR","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20341","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20348","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20348"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20348\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20341"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20348"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20348"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20348"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}