Google QUIC, nuovo protocollo per una rete più veloce

Potreste non averne mai sentito parlare ma se usate Chrome è probabile che abbiate già usato il protocollo di Google chiamato QUIC (Quick UDP Internet Connection, connessione internet UDP veloce). Circa la metà delle richieste da Chrome ai server di Google sono ora gestite usando QUIC, come ha rivelato l’azienda stessa.

Perché è importante? Google QUIC è un protocollo sperimentale di trasferimento internet a bassa latenza attraverso UDP, un protocollo spesso usato per i giochi, lo streaming multimediale e i servizi VOIP. La controparte di UDP (e di QUIC) nel mondo dei protocolli è essenzialmente TCP (il quale, unitamente ad IP, costituisce il linguaggio di comunicazione di base in internet).

UDP è molto più leggero di TCP; tuttavia, al suo confronto, ha significativamente minori servizi di correzione d’errore. Ciò significa che il server di partenza non comunica costantemente col server di destinazione per controllare se i pacchetti sono arrivati tutti e nell’ordine corretto. Ecco perché UDP è ottimo per i servizi di gioco.

In questo caso è necessario un basso overhead (traffico di dati accessori) per ridurre la latenza; se il server non riceve il più recente movimento del mouse, non serve spendere un secondo o più per correggere questa situazione, poiché l’azione è già passata oltre. Invece non sarebbe consigliabile usarlo per richiedere l’accesso ad un sito web, dato che non potrebbe garantire che tutti i dati arriverebbero a destinazione.

Con QUIC Google mira a combinare alcune delle migliori caratteristiche di UDP e TCP con i moderni strumenti di sicurezza. In una tipica connessione TCP generalmente ci vogliono due o tre percorsi andata e ritorno prima che il browser cominci effettivamente a ricevere dati. Usando Google QUIC, un browser può cominciare immediatamente a parlare ad un server col quale ha comunicato prima.

QUIC introduce anche un paio di nuove funzioni come il controllo di congestione e la ritrasmissione automatica, rendendolo più affidabile che il puro UDP.

Attraverso SPDY, diventato successivamente la base per lo standard HTTP/2, Google aveva già sviluppato un altro protocollo alternativo dai molti obiettivi in comune con QUIC. Ma HTTP/2 funziona ancora sotto TCP ed incorre nello stesso costo di latenza.

E’ ragionevole chiedersi perché Google non cerchi invece di migliorare solo TCP. Il problema, puntualizzano dalla compagnia, è che il supporto a TCP è spesso costruito direttamente nel kernel dei sistemi operativi; e questo è qualcosa su cui Google non può avere alcun controllo.

“QUIC ci permette di sperimentare nuove idee e ottenere risultati molto prima” – scrive il team di sviluppo – “Auspichiamo che le caratteristiche di QUIC migrino in TCP e TLS se si dimostreranno efficaci“. Considerando quante installazioni di Windows XP siano ancora operative, è ovvio che non si tratta di qualcosa che accadrà dalla sera alla mattina.

Google QUIC, cosa si prospetta?

Se Google QUIC disegna un intero nuovo protocollo, allora tutte le macchine che costituiscono la spina dorsale di internet dovranno comprenderlo. Ma comprendono già UDP. Da Google affermano che con QUIC c’è stato un miglioramento del 3% nel tempo medio di caricamento pagina su Google Search. Può non sembrare un gran che, ma bisogna ricordare che Google Search ha già la massima ottimizzazione possibile.

Altri siti, specialmente le applicazioni web ad alta latenza, vedranno probabilmente miglioramenti maggiori. Utenti che si connettono a YouTube con QUIC riportano circa il 30% in meno di rebuffering durante la visualizzazione; inoltre, grazie al migliorato controllo congestione ed il recupero di pacchetti persi su UDP, anche gli utenti con le connessioni più lente notano tempi di caricamento migliori con QUIC.

Google afferma che ha in progetto di proporre in futuro all’IETF (Internet Engineering Task Force) HTTP/2 su QUIC come nuovo standard di internet. Sotto certi aspetti, tutto ciò riflette il lavoro con SPDY. Anche in quel caso la società aveva prima usato il protocollo come prototipo su Chrome e i propri servers e successivamente lo aveva proposto come base per la nuova versione di HTTP.