Come abilitare BBR su Ubuntu 24.04

BBR su Ubuntu 24.04 non è un interruttore magico: funziona bene quando il problema è la coda TCP, la latenza sotto carico o un link con bandwidth-delay product alto. Se il tuo server è già limitato da CPU, disco, applicazione o saturazione upstream, BBR non risolve e può solo spostare il collo di bottiglia. La regola pratica è semplice: prima misuri, poi abiliti, poi confronti.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Quando BBR ha senso su Ubuntu 24.04

BBR è un congestion control per TCP. Non cambia il routing, non aumenta la banda contrattuale e non rende più veloce un applicativo lento. Interviene sul modo in cui il kernel decide quanta finestra tenere aperta, cercando di mantenere la pipe piena senza accumulare code inutili. In pratica, è interessante su server che servono traffico HTTP, backup, replica, download o stream verso client distribuiti geograficamente.

Su Ubuntu 24.04 il kernel è abbastanza recente da avere BBR disponibile senza patch particolari. Quello che cambia davvero è il contesto: se hai RTT più alti, perdita sporadica o code che si riempiono facilmente, BBR può abbassare la latenza percepita e stabilizzare il throughput. Se invece il server regge poche centinaia di connessioni perché il worker web è saturo, il guadagno sarà marginale.

Verifica preliminare: kernel e stato attuale

Prima di toccare la configurazione, controlla due cose: versione del kernel e algoritmo TCP in uso. Su un sistema sano, devi vedere un kernel supportato e un congestion control diverso da BBR, così hai un prima/dopo misurabile.

Esegui questi comandi:

uname -r
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

Risultato atteso: il kernel è della serie 6.x tipica di Ubuntu 24.04 e tra gli algoritmi disponibili compare bbr. Se bbr non compare in tcp_available_congestion_control, il problema non è la configurazione ma il kernel o un modulo non presente: va verificato il pacchetto installato e, se necessario, la presenza di un kernel generico Ubuntu aggiornato.

Controlla anche se stai già usando una configurazione custom in /etc/sysctl.conf o in /etc/sysctl.d/. Su macchine gestite bene, il settaggio non dovrebbe vivere solo in un file unico e sporco, ma in uno snippet dedicato, così lo puoi versionare e rimuovere senza effetti collaterali.

Che cosa cambia davvero con BBR

Con i TCP classici, la crescita della finestra è molto influenzata da perdita e ACK ricevuti. BBR usa una logica diversa: stima bandwidth e RTT minimo, poi cerca di lavorare vicino al punto in cui il link è pieno ma non congestionato. Questo è utile soprattutto quando il problema è la latenza da coda, non la capacità fisica del collegamento.

Il punto da non perdere è questo: BBR non è sempre migliore in assoluto. Su alcuni profili di traffico può aumentare aggressività o cambiare il comportamento in modo che il beneficio non sia evidente. Per questo conviene misurare almeno TTFB, p95 latency o throughput prima e dopo, non solo “se il ping sembra meglio”.

Se il tuo obiettivo è ridurre error rate sotto carico, osserva anche:

• latenza p95/p99 delle richieste;
• numero di retransmission TCP;
• coda NIC o saturazione interfaccia;
• timeout lato proxy o bilanciatore;
• CPU softirq se il traffico è alto.

Abilitazione corretta: snippet dedicato e rollback semplice

La modifica minima e reversibile su Ubuntu 24.04 è un file dedicato in /etc/sysctl.d/. Evita di editare a mano il file globale se non hai una ragione precisa. Così puoi ripristinare in un colpo solo e sai esattamente quale change hai introdotto.

1. Crea uno snippet dedicato, per esempio /etc/sysctl.d/99-bbr.conf:

sudo tee /etc/sysctl.d/99-bbr.conf > /dev/null <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

Il dettaglio importante è doppio: tcp_congestion_control=bbr abilita l’algoritmo, mentre default_qdisc=fq è la coppia raccomandata nella pratica con BBR su Linux moderno. Senza una coda coerente, il comportamento può essere meno pulito e perdi parte del beneficio atteso.

2. Applica la configurazione senza reboot:

sudo sysctl --system

3. Verifica subito che i valori siano stati caricati:

sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control

Atteso: fq e bbr. Se vedi ancora un valore vecchio, il file non è stato letto, c’è un conflitto in un altro snippet o hai un errore di sintassi. In quel caso controlla i log del reload e il contenuto dei file in /etc/sysctl.d/.

Conflitti tipici: chi vince tra sysctl, cloud-init e hardening

Su server cloud o ambienti gestiti, la configurazione può essere riscritta da strumenti automatici. Il caso classico è il file corretto che viene sovrascritto da un altro snippet con priorità diversa, oppure un template di hardening che imposta un congestion control differente. In questi casi non serve “riprovare” a caso: devi trovare chi impone il valore finale.

Per fare troubleshooting veloce, elenca i file letti dal sistema e cerca il parametro:

grep -R --line-number -E 'tcp_congestion_control|default_qdisc' /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/ 2>/dev/null

Se trovi più occorrenze, l’ultima applicata vince. In ambienti con configurazione gestita, conviene documentare il file “owner” del parametro, così il rollback è banale: elimini o commenti lo snippet dedicato e ricarichi sysctl --system.

Verifica funzionale: non basta il sysctl

Un errore comune è fermarsi alla verifica del parametro. Quello ti dice solo che il kernel sta usando BBR, non che la tua applicazione ne stia beneficiando. Serve almeno un test sintetico e uno reale.

Per il test sintetico puoi osservare connessioni attive e statistiche TCP durante un trasferimento:

ss -tin state established
nstat -az | grep -E 'TcpRetransSegs|TcpExtTCPSynRetrans|TcpExtTCPTimeouts'

Per un test reale, usa il tuo caso d’uso: download di un file statico, replica, sync o benchmark HTTP. Se hai un front-end web, confronta TTFB e p95 prima e dopo. Se hai un reverse proxy, osserva anche i timeout upstream e il numero di retry. Il criterio utile non è “sembra più veloce”, ma “la distribuzione delle latenze è migliorata senza alzare gli errori”.

Un esempio pratico: su una VM con traffico internazionale e molte risposte piccole, il beneficio può essere minimo sul throughput ma evidente sulla coda di richieste sotto burst. Invece su una macchina che serve poco traffico ma ha database lento, BBR non cambierà il tempo totale della pagina, perché il collo di bottiglia è altrove.

Rollback pulito se qualcosa non torna

Il rollback è immediato e non distruttivo: rimuovi lo snippet e ripristini il valore precedente. Prima però annota lo stato iniziale, così puoi tornare esattamente al comportamento precedente e non a un presunto default.

1. Registra i valori attuali:

sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control

2. Rimuovi o rinomina lo snippet:

sudo mv /etc/sysctl.d/99-bbr.conf /etc/sysctl.d/99-bbr.conf.disabled

3. Ricarica la configurazione:

sudo sysctl --system

Se vuoi tornare a uno stato noto, imposta esplicitamente il congestion control precedente invece di affidarti a un default implicito, soprattutto su server con immagini custom o baseline non standard. Questo riduce l’ambiguità quando fai audit o confronti prestazionali.

BBR e firewall, CDN, proxy: dove intervenire prima

Se il servizio è dietro CDN o reverse proxy, BBR va valutato sul tratto giusto. Non ha senso misurarlo solo dal browser se l’edge assorbe già la latenza o se il proxy termina le connessioni e parla con l’origin su un traffico poco rilevante. In altre parole, misura sul server che gestisce il collo di bottiglia reale.

Per esempio, su un origin Nginx con molte connessioni keep-alive, può essere utile guardare:

ss -s
journalctl -u nginx -n 100 --no-pager

Se noti errori upstream, timeout o code in saturazione, BBR da solo non basta. Prima va ridotto il traffico inutile, poi va verificato che il proxy non stia introducendo limiti più stretti del kernel. Quando il layer applicativo è il problema, la metrica utile resta quella applicativa, non il singolo parametro TCP.

Buone pratiche operative su Ubuntu 24.04

Su un server in produzione, tratta BBR come un change controllato. Documenta il motivo, la finestra di osservazione e il rollback. Se hai monitoring, salva almeno una baseline di latenza e retransmission prima dell’attivazione. Se non hai monitoring, almeno conserva l’output dei comandi di stato.

• Usa uno snippet dedicato in /etc/sysctl.d/ e non un edit casuale del file globale.
• Confronta sempre il comportamento prima/dopo con una metrica concreta.
• Se hai sistemi eterogenei, valida che il kernel sia effettivamente quello atteso su ogni nodo.
• Non confondere una riduzione del ping con un miglioramento della latenza applicativa.

Se gestisci più host, conviene standardizzare il controllo con un comando rapido in inventory o Ansible, così trovi subito i nodi fuori policy. Il punto non è solo “abilitare BBR”, ma sapere dove è attivo, dove è stato escluso e perché.

Checklist finale prima di dare il change per buono

1. sysctl net.ipv4.tcp_congestion_control restituisce bbr.

2. sysctl net.core.default_qdisc restituisce fq.

3. Il workload giusto mostra un miglioramento misurabile su TTFB, p95 o throughput, non solo una sensazione soggettiva.

4. Hai un rollback pronto: rimozione dello snippet e reload di sysctl --system.

5. Hai escluso conflitti con altri snippet o strumenti di gestione configurazione.

In sostanza, BBR su Ubuntu 24.04 è una modifica semplice solo sulla carta. La parte utile è la disciplina operativa: capire dove sta il collo di bottiglia, applicare la change in modo reversibile e misurare il risultato con numeri, non con impressioni.