Indice dei contenuti dell'articolo:
A detta di molti, Internet di oggi non sposta i dati come dovrebbe. La maggior parte degli utenti di telefoni cellulari del mondo presenta ritardi da secondi a minuti; il Wi-Fi pubblico negli aeroporti e nei luoghi di conferenza è spesso peggiore.
I ricercatori scientifici universitari di dipartimenti di fisica o climatologia hanno bisogno ad esempio di scambiare petabyte di dati al giorno con collaboratori globali ma trovano che la loro infrastruttura multi-Gbps accuratamente progettata spesso fornisce solo pochi Mbps su distanze intercontinentali.
Questi problemi derivano da una scelta progettuale fatta quando il controllo della congestione TCP è stato creato nell’ nterpretazione degli anni ’80 della perdita di pacchetti come “congestione”.
Questa equivalenza era vera al momento, ma era a causa dei limiti tecnologici, non dei primi principi. Poiché i NIC (controller di interfaccia di rete) si sono evoluti da Mbps a Gbps e chip di memoria da KB a GB, la relazione tra perdita di pacchetti e congestione è diventata più tenue.
Oggi il controllo della congestione basato sulla perdita di TCP, anche con l’attuale best of breed, CUBIC11, è la causa principale di questi problemi.
Quando i buffer del collo di bottiglia sono grandi, il controllo della congestione basato sulla perdita li mantiene pieni, causando il bufferbloat.
Quando i buffer del collo di bottiglia sono piccoli, il controllo della congestione basato sulla perdita interpreta erroneamente la perdita come segnale di congestione, portando a un basso throughput. La risoluzione di questi problemi richiede un’alternativa al controllo della congestione basato sulla perdita.
Trovare questa alternativa richiede una comprensione di dove e come ha origine la congestione della rete.
È qui che entra in gioco TCP BBR. È un algoritmo di controllo della congestione TCP creato per la congestione di Internet moderna.
TCP: la condivisione della banda è importante.
TCP cerca di bilanciare la necessità di essere veloci (trasmissione rapida dei dati) e bilanciati (condividere la banda per più utenti), con molto più peso sull’essere bilanciati.
La maggior parte delle implementazioni TCP utilizza un algoritmo di backoff che porta a ottenere circa ½ larghezza di banda.
Se insomma hai una banda in uscita di 1 gigabit per secondo sul tuo server, stai abbastanza certo che il traffico in uscita per il tuo server Web che gira su TCP difficilmente supererà i 500 o 600 megabit al secondo.
Questo è il problema principale con TCP, il suo utilizzo porta a sprecare (o meglio inutilizzare) banda.
BBR TCP: i concetti importanti
Puoi leggere il documento per ulteriori dettagli, ma il succo del discorso è che BBR è una tecnologia di controllo della congestione che:
È progettato per rispondere alla congestione effettiva, piuttosto che alla perdita di pacchetti. Il team di BBR ha progettato l’algoritmo con il desiderio di avere qualcosa che risponda alla congestione effettiva, piuttosto che alla perdita di pacchetti. BBR modella la rete per inviare alla velocità della larghezza di banda disponibile ed è 2700 volte più veloce dei precedenti TCP su un collegamento da 10 Gb, 100 ms con perdita dell’1%
Incentrato sul miglioramento delle prestazioni della rete quando la rete non è molto buona. TCP BBR bilancia più accuratamente equità e utilizzo, con conseguente migliore velocità di download sulla stessa rete. È più evidente in situazioni in cui la rete è danneggiata (tuttavia, non ti fa male se sei su una rete pulita e cigolante)
Non richiede al cliente di implementare BBR . Questa è la vera ricetta magica. Algoritmi precedenti come QUIC richiedevano che client e server avessero entrambi implementato l’algoritmo. BBR non richiede che il client utilizzi anche BBR. Ciò è particolarmente rilevante nei paesi in via di sviluppo che utilizzano piattaforme mobili meno recenti e hanno una larghezza di banda limitata, o aree in cui siti e servizi non hanno ancora effettuato il passaggio. Insomma se il tuo browser non supporta QUIC non c’era modo di migliorare nulla.
Vediamo meglio BBR da vicino su strada.
Tutto ciò suona bene, ma vediamo quanto è buona questa tecnologia nella pratica e non solo nella teoria. Per testare le cose, ho impostato due VM in due regioni diverse e ho eseguito un rapido test Iperf per verificare le loro prestazioni:
[4] 0.0-10.0 sec 9.97 GBytes 8.55 Gbits / sec
Per simulare le condizioni ideali in cui BBR è utile (perdita di pacchetti elevata) eseguiamo il seguente comando tc, che simula la perdita di pacchetti ad una certa percentuale.
sudo tc qdisc add dev eth0 root netem loss 1.5%
Quando le macchine virtuali esistenti si connettono, vediamo un calo significativo delle prestazioni (che ci aspetteremmo):
[3] 0.0-10.3 sec 1.10 GByte 921 Mbits / sec
Quindi, abbiamo attivato BBR, sul lato server solo utilizzando il seguente comando (disponibile solo su Kernel Linux Maggiore al 4.10):
sysctl -w net.ipv4.tcp_congestion_control = bbr
Abbiamo eseguito lo stesso test Iperf e
[3] 0.0-10.0 sec 2.90 GBytes 2.49 Gbits / sec
Vediamo quasi 2 volte un utilizzo della larghezza di banda della connessione raw solo dopo aver impostato un semplice flag nel server.
Dove usare TCP BBR? Dappertutto.
Di base non esiste un reale motivo per non usare una tecnologia come TCP BBR e ragionare dove andrebbe usata e dove no sarebbe tempo sprecato e forse anche stupido.
Certamente, la maggior parte del vantaggio si vedrà sugli endpoint client in aree con cattive condizioni di traffico . Quindi, se lo cambi tra le VM, non allarmarti se le cose non sono significativamente migliori. Detto questo, non c’è nessun svantaggio nell’usarlo, anche nelle aree di buona connessione.
Va detto che tra i suoi usi non standard che ad esempio l’implementazione di BBR può aiutare a gestire un attacco DDOS di tipo volumetrico basato su TCP o effetti di Slashdotting in cui un sito Web viene raggiunto da centinaia di migliaia di visitatori al minuto.
In fondo si tratta solo di abilitare un Kernel Linux maggiore del 4.10 e abilitare un flag, con un semplice comando da riga di comando.
Perchè non farlo ?
