Google: HTTP/3 e QUIC sono il futuro della Rete

Google è una delle aziende più importati del web e grazie al suo "soft power" può influenzare l'introduzione e l'implementazione dei nuovi standard Web. Anni fa il team di ingegneri dell'azienda ha sviluppato SPDY, un nuovo protocollo a livello applicativo per il trasporto di contenuti, i principi base di SPDY sono stati sfruttati ed integrati su HTTP/2 che oggi è supportato da tutti i principali browser.

Ecco perché Google, a partire da Chrome 40, ha deciso di migrare completamente ad HTTP/2. SPDY però non è stato pensato per sostituire completamente il protocollo HTTP ma per veicolare HTTP al suo interno in modo da ridurre la latenza delle pagine web senza perdere compatibilità con le applicazioni preesistenti. Questo risultato è ottenuto garantendo priorità e selezionando i diversi file durante il trasferimento, in modo da richiedere una sola connessione TCP per client.

Inoltre le trasmissioni di SDPY sono sempre criptate con SSL e compresse tramite gzip. Per l'epoca dunque era un sistema all'avanguardia ed è normale che i suoi principi siano stati integrati in HTTP/2.

Ora Mountain View è all'opera sul protocollo QUIC che dovrebbe essere implementato in HTTP/3. QUIC è qualcosa di simile ad un'evoluzione del TCP (Transmission Control Protocol), il protocollo di rete che si occupa del controllo di trasmissione in modo da rendere affidabile la comunicazione tra mittente e destinatario.

Una delle caratteristiche più richieste durante le operazioni di rete è una bassa latenza della connessione. TCP richiede che un numero di pacchetti venga inviato bidirezionalmente prima di stabilire la connessione. Lo stesso vale per il protocollo SSL che richiede un certo numero di pacchetti inviati e ricevuti per eseguire la crittografia. Se il ritardo di rete è elevato, ad esempio nel caso di connessioni satellitari che hanno tempi di ping di mezzo secondo, può essere necessario attendere a lungo prima che venga stabilita una connessione.

Altro punto critico riguarda la bandwidth. C'è sempre un certo limite di bandwidth tra l'origine e la destinazione di una connessione, quasi sempre dovuto alla congestione delle rete Internet. Entrambe le parti devono rilevare la larghezza di banda cosi da inviare i pacchetti in modo sincrono. L'invio di pacchetti troppo rapido causa infatti una congestione ancora maggiore. L'invio di pacchetti troppo lento porta invece ad un uso non ottimale della rete.

Attualmente il protocollo HTTP gestisce questi due aspetti in modo poco efficiente. Per comunicare con i siti Web una singola connessione TCP non basta perché sono previste richieste multiple sopratutto se servono delle trasmissioni simultanee (i browser generalmente ne aprono ben 6 alla volta), tuttavia ciò va ad inficiare le stime di bandwidth perché ciascuna delle connessioni TCP tenta di eseguire connessioni in modo indipendente senza tenere conto delle altre. Già con SDPY gli ingegneri Google avevano affrontato tale problema grazie alla funzionalità di multiplexing, che combinava più interazioni tra browser e server con un singolo calcolo della larghezza di banda.

Con QUIC tale feature è stata estesa, rendendo ancora più semplice la gestione di più interazioni tra browser e server, senza che nessuna interazione ne blocchi un'altra, ma con una stima della larghezza di banda comune.

Ciò renderà le interazioni più agevoli dal punto di vista dell'utente, mentre allo stesso tempo ridurrà la congestione della rete. QUIC inoltre ha un supporto nativo per i device mobile. Mentre ci si sposta con il proprio smartphone o con un portatile, l'indirizzo IP può cambiare. Il sistema operativo e i protocolli non chiudono le vecchie connessioni in modo netto e diretto e ne aprono di nuove, ma impiegano sempre un po di tempo. Su QUIC invece l'identificatore di connessione non sfrutta il concetto tradizionale di "socket" (la combinazione del protocollo di porta / indirizzo di origine / destinazione), perché Google ha progettato direttamente un nuovo tipo di identificatore a 64 bit.

Questo vuole dire che anche se si cambia IP i servizi di rete e le connessioni non vengono interrotte, ma ripristinate quasi istantaneamente.

Un' altro problema col protocollo TCP sta nel fatto che le sue connessioni vengono gestite direttamente dal kernel del sistema operativo e il servizio stesso viene eseguito in usermode (user-mode stack). Questa transizioni tra kernel e usermode genera spesso problemi di prestazioni, infatti tenere traccia di un numero elevato di connessioni TCP causa problemi di scalabilità. La soluzione più sicura sta nell'usare un driver usermode per l'hardware, ottenere pacchetti dal chip di rete direttamente nel processo usermode, bypassando quindi il kernel. Questa feature si ottiene sfruttando un kit chiamato DPDK.

Via Erratasec