1 19/05/2026 10 min

BBR significa Bottleneck Bandwidth and Round-trip propagation time. È un algoritmo di controllo della congestione TCP progettato per usare meglio la banda disponibile senza comportarsi come i classici algoritmi “a perdita”. In pratica, prova a stimare quanta capacità ha il collo di bottiglia e qual è il tempo di propagazione minimo della rete, poi regola il ritmo di invio dei pacchetti su quei due valori.

Il punto chiave è questo: nei TCP tradizionali la congestione viene interpretata soprattutto attraverso gli scarti, cioè perdita di pacchetti o segnali indiretti di code piene. BBR ragiona invece in modo più proattivo. Non aspetta che la rete si riempia per capire che sta andando troppo veloce; cerca di scoprire in anticipo il punto in cui la rete rende meglio, con meno accumulo di latenza.

Perché BBR interessa a chi gestisce server, hosting e reti

Per un webmaster o per chi amministra un’infrastruttura web, BBR conta perché tocca tre aspetti che si vedono subito in produzione: latenza, stabilità del throughput e comportamento sotto carico. Su un server web, su un proxy, su una macchina che serve download pesanti o su un endpoint API con traffico costante, un controllo di congestione più moderno può ridurre il tempo in cui la coda di rete si gonfia inutilmente.

Questo non significa che BBR sia una bacchetta magica. Se il problema sta altrove — applicazione lenta, disco saturo, database in sofferenza, DNS mal configurato, CPU al limite — cambiare algoritmo TCP non risolve nulla. Però, quando la rete è davvero il collo di bottiglia, BBR può evitare i classici effetti collaterali delle code piene: latenza che cresce a spirale, pacchetti ritardati e sensazione di “rete lenta” anche quando la banda nominale non è esaurita.

Come funziona in termini semplici

BBR cerca due numeri:

  • Bottleneck bandwidth: la banda effettivamente disponibile nel punto più stretto del percorso.
  • Round-trip propagation time: il tempo di andata e ritorno minimo, cioè il RTT “pulito” senza code aggiunte.

Con questi dati, BBR tenta di mantenere nel percorso una quantità di dati adeguata, senza svuotare la pipeline ma anche senza far crescere code eccessive. In sostanza lavora per tenere il canale “pieno ma non intasato”.

Un modo pratico per immaginarlo: i TCP classici sono spesso guidati dal segnale “hai esagerato, rallenta”. BBR invece prova a dire “questa strada regge questo volume, quindi invio a quel ritmo”. È una differenza importante, perché cambia il modo in cui la connessione reagisce a congestione, buffer e perdita di pacchetti.

La differenza rispetto a Reno, Cubic e simili

Reno, NewReno, Cubic e altri algoritmi storicamente diffusi hanno un comportamento fortemente legato alla perdita. Funzionano bene in molti scenari, ma quando la rete ha buffer grandi o code lunghe possono accumulare ritardo prima di reagire. Questo è il classico caso in cui il throughput sembra buono, ma la latenza si impennna e le applicazioni interattive ne risentono.

BBR cambia prospettiva: usa misure di bandwidth e RTT per regolare la finestra di invio. L’obiettivo non è solo “non perdere pacchetti”, ma anche evitare che la rete venga caricata oltre il punto utile. In ambienti dove i buffer sono generosi o il traffico è misto, questo può tradursi in risposte più rapide e code meno profonde.

Detto in modo molto concreto: se hai un server che serve file, stream o API dietro una connessione dove la latenza conta, BBR può offrire una percezione più stabile. Se invece il traffico è già ben gestito da queue discipline, shaping o policy di rete ben tarate, il guadagno può essere modesto o nullo.

BBR non elimina la congestione: la gestisce in modo diverso

Qui vale la pena essere precisi. BBR non “buca” il limite fisico della rete e non fa sparire il collo di bottiglia. Se la linea è da 100 Mbit/s, non diventa da 1 Gbit/s. Quello che cambia è la strategia con cui il TCP decide quanto spingere e quanto tenere in coda.

Il vantaggio principale è la riduzione del bufferbloat, cioè l’accumulo eccessivo di pacchetti nei buffer intermedi. Quando i buffer si gonfiano, il traffico interattivo paga il prezzo: SSH, VoIP, dashboard, backend admin, chiamate API brevi. BBR cerca di mantenere il flusso efficiente senza trasformare la rete in una sala d’attesa.

C’è però un rovescio della medaglia: in alcune reti BBR può interagire in modo non ideale con altri flussi TCP o con apparati che si aspettano comportamenti più tradizionali. Per questo il suo impiego va valutato sul contesto reale, non sul solo entusiasmo da benchmark.

BBR v1 e BBR v2: non sono la stessa cosa

Quando si parla di BBR spesso si mescolano versioni diverse. La prima implementazione ha reso popolare l’idea di controllo “model-based”, ma nel tempo sono emersi casi limite: fairness con altri flussi, comportamento in reti con perdita non banale, e interazioni non sempre perfette con alcune topologie.

BBR v2 nasce per correggere parte di questi problemi, introducendo un approccio più prudente nella gestione della congestione e della loss. In pratica cerca di essere più equilibrato nei confronti del resto del traffico e più robusto quando la rete non è pulita come in laboratorio.

Per chi amministra sistemi, il messaggio operativo è semplice: non basta sapere “abbiamo BBR”. Bisogna sapere quale versione è attiva, su quale kernel, e con quali parametri o distribuzioni si sta lavorando. Su Linux recente la disponibilità dipende dalla versione del kernel e dalla distribuzione adottata.

Dove può dare benefici reali

BBR tende a essere interessante in questi casi:

  1. Link con banda elevata e latenza non trascurabile: ad esempio tratte WAN, backup remoti, replica tra datacenter, trasferimenti su VPN.
  2. Server che servono grandi quantità di dati: download, media, repository, oggetti statici, distribuzione di pacchetti.
  3. Ambienti dove la latenza percepita è importante: applicazioni web con molte richieste brevi, pannelli amministrativi, API sensibili ai tempi di risposta.

In questi scenari BBR può migliorare la qualità del traffico perché evita di farsi guidare soltanto dalla perdita. La rete resta più vicina al suo punto utile e i tempi di risposta possono risultare più regolari.

Un esempio pratico: un server di backup notturno che satura il link e rende lenta la navigazione degli utenti interni. Con un controllo congestionale più attento alla latenza, il trasferimento può continuare a buon ritmo senza “schiacciare” tutto il resto del traffico nello stesso momento.

Quando invece non aspettarsi miracoli

Se il collo di bottiglia è l’applicazione, BBR non aiuta. Se PHP è bloccato su I/O, MySQL ha query lente, il disco è pieno o la CPU è satura, il controllo TCP non cambia il quadro. Lo stesso vale per problemi di DNS, certificati, reverse proxy o configurazioni WAF che introducono ritardi a monte della rete TCP.

BBR può anche non essere la scelta ideale su link molto piccoli, su reti con caratteristiche anomale o in contesti dove la fairness tra flussi è critica e va verificata con cura. In breve: se il traffico è eterogeneo, va testato con numeri reali e non con impressioni a occhio.

Un errore comune è leggere un miglioramento in un singolo benchmark e dedurre che tutto il resto ne beneficerà allo stesso modo. In produzione conviene guardare almeno latency p95, error rate e saturazione del link, non solo il picco di throughput. Se il tempo di risposta migliora ma la coda resta instabile sotto carico misto, il guadagno potrebbe essere meno solido di quanto sembri.

Come verificare se BBR è attivo su Linux

Su molti sistemi Linux puoi verificare il controllo di congestione corrente con un comando semplice:

sysctl net.ipv4.tcp_congestion_control

Il risultato atteso, se BBR è in uso, è qualcosa di simile a:

net.ipv4.tcp_congestion_control = bbr

Puoi anche controllare quali algoritmi sono disponibili nel kernel:

sysctl net.ipv4.tcp_available_congestion_control

Se bbr non compare, non forzare conclusioni: significa che il kernel in uso non lo espone oppure che il modulo non è disponibile. In quel caso la chiusura del gap passa da kernel, distribuzione e policy di aggiornamento, non da un tweak improvvisato.

Attivazione: il punto non è solo il comando

Impostare BBR è spesso semplice a livello di sysctl, ma il lavoro vero è prima: capire l’impatto e predisporre una via di ritorno. In un cambio controllato conviene sempre avere un backup del file di configurazione e sapere come tornare al valore precedente.

Su sistemi recenti, il passaggio tipico è impostare il controllo di congestione e poi renderlo persistente nella configurazione di sistema. Un esempio comune è:

sysctl -w net.ipv4.tcp_congestion_control=bbr

Questo però è solo un test temporaneo. Per la persistenza serve il file di configurazione, ad esempio sotto /etc/sysctl.d/ o /etc/sysctl.conf, a seconda della distribuzione e della policy locale. Prima di toccarlo, meglio salvare lo stato attuale e verificare che non ci siano override nascosti.

Regola pratica: modifica minima, verifica immediata, e solo dopo estensione al resto del parco macchine. Su un nodo di frontiera o su un server con traffico critico, il blast radius va trattato come reale anche se la modifica sembra banale.

Osservabilità: cosa guardare dopo l’attivazione

Se attivi BBR, non fermarti al “sembra andare”. Le metriche utili sono quelle che raccontano il comportamento della rete e dell’applicazione insieme. In pratica, osserva:

  • p95 latency delle richieste HTTP o delle chiamate API.
  • Error rate e timeout lato applicazione.
  • Utilizzo banda sul link interessato.
  • RTT medio e variazione sotto carico.
  • Code depth o segnali di bufferbloat, se hai strumenti di monitoraggio di rete.

Se la banda sale ma anche la latenza cresce, il tuning non sta ottenendo il risultato atteso. Se invece il throughput resta stabile e i tempi di risposta calano o diventano più regolari, hai un segnale più credibile che l’algoritmo sta aiutando davvero.

Un caso d’uso tipico: traffico web e backup sullo stesso uplink

Scenario classico: una macchina o un piccolo cluster serve siti web e, nella stessa finestra temporale, esegue backup verso storage remoto. Senza un controllo congestionale adatto, il backup può saturare la coda e rendere più lenti i siti, anche se il link non è formalmente “rotto”.

Con BBR, a parità di condizioni, il backup tende a usare meglio la banda senza trasformare la latenza in un problema cronico. Il risultato non è tanto “più velocità” in assoluto, quanto una distribuzione più sensata del carico. Per un amministratore, questa differenza vale molto più di qualche megabit in più su un test isolato.

Se però il backup gira su una finestra dedicata, con shaping, priorità QoS e limiti ben definiti, il contributo di BBR può diventare marginale. Anche qui vale la logica operativa: prima capire come è costruita la rete, poi decidere se il controllo TCP aggiunge valore oppure no.

Limiti e cautela operativa

BBR va trattato come una scelta tecnica, non come un default universale. In ambienti misti, con apparati datati, tunnel particolari, VPN, peering non omogenei o policy di rete molto rigide, è sensato fare una prova controllata prima di estenderlo. Il rischio non è un disastro immediato, ma un comportamento meno prevedibile del previsto.

La prudenza è ancora più importante se gestisci più server con ruoli diversi. Non ha senso usare la stessa impostazione ovunque solo per uniformità estetica. Un nodo backend, un reverse proxy e un server di backup non hanno gli stessi obiettivi di rete. Il primo può privilegiare reattività, il secondo stabilità, il terzo throughput sostenuto.

In altre parole: BBR è uno strumento da mettere in cassetta, non un interruttore da accendere alla cieca. Se ti serve, lo testi, misuri e consolidi. Se non ti serve, non forzi la mano solo perché è “più moderno”.

In sintesi tecnica

BBR è un algoritmo TCP che cerca di stimare banda disponibile e RTT minimo per inviare dati in modo più efficiente, con meno code e meno latenza inutile. È utile soprattutto quando il collo di bottiglia è davvero la rete e quando il costo di una coda piena si vede nelle applicazioni.

Per chi gestisce siti, server e infrastrutture, il valore sta nel comportamento sotto carico, non nel nome dell’algoritmo. Se hai bisogno di più reattività su link saturabili, BBR merita una prova. Se il problema è altrove, conviene prima misurare e correggere la causa vera. L’ordine giusto resta sempre quello: osservare, verificare, cambiare poco, e solo dopo estendere.