QUIC: ciò che si nasconde dietro al protocollo sperimentale di Google

Grazie ai sempre più veloci accessi DSL il tempo di caricamento dei siti Internet tende generalmente a ridursi sempre più. L’idea generale che ne consegue è che i siti web si debbano aprire velocemente, il che complica la vita ai progetti web con tempi di caricamento più lunghi. A rincarare la dose è l’importanza sempre maggiore che sta assumendo la codifica dei dati. Sebbene lo standard HTTP Secure (o HTTPS) si dimostri un alleato affidabile nella protezione della privacy degli utenti, registra anche un rallentamento dei tempi di caricamento a causa dell’handshake TLS e dello scambio di chiavi e certificati. Questa situazione dovrebbe essere risolta dal protocollo QUIC di Google.

QUIC è un protocollo di trasporto sperimentale del gigante dei motori di ricerca Google, presentato per la prima volta al pubblico nel 2013. Il nome del protocollo fa riferimento a “Quick UDP Internet Connections“, che a sua volta si rifà all’invio di pacchetti dati semplice e veloce reso possibile dal protocollo connectionless UDP (User Datagram Protocol). L’intenzione dietro a QUIC è il desiderio di sviluppare un’alternativa ai protocolli di sicurezza affermati e basati su TCP, ovvero HTTP/2 e TLS/SSL, che offra la stessa sicurezza, ma che al contempo registri un ritardo di connessione e di trasporto ridotto e che permetta la multiplazione.

È a questo scopo che Google ha progettato QUIC in modo tale che il protocollo regoli automaticamente i controlli di connessione. Al primo contatto tra mittente e destinatario questi si scambiano i certificati e le chiavi necessari per la decodifica dei datagrammi inviati. Tale scambio non avviene invece durante le comunicazioni successive, limitando la latenza. Come protocollo di crittografia viene utilizzato TLS, versione 1.3, ottimizzato per ottenere la maggior velocità di scambio possibile (standardizzato a marzo 2017), che presenta un vantaggio rispetto alla soluzione di Google.

In materia di Multiplexing QUIC si orienta al protocollo SPDY, sempre elaborato da Google, e che è servito da modello per l’HTTP/2. Attraverso una singola connessione client-server possono essere trasmessi diversi flussi di dati, riducendo maggiormente il tempo di caricamento.

Alcune importanti caratteristiche e vantaggi di QUIC sono già stati affrontati, ma vale la pena fare maggior chiarezza. Il protocollo TCP ci servirà a questo scopo da confronto, anche se, nonostante abbia fatto da apripista per l’ideazione di questo ambizioso protocollo di trasporto, è certamente inferiore allo stesso sotto certi aspetti, come dimostrano i vantaggi di QUIC.

Il motivo determinante per il quale QUIC si dimostra migliore di TCP è la connessione significativamente più veloce. Anche senza codifica SSL/TLS, una connessione per mezzo della cosiddetta three-way handshake attraverso il classico protocollo di trasporto prevede più passaggi rispetto alla soluzione proposta da Google e basata su UDP. QUIC avvia una connessione con un singolo pacchetto (due se si tratta di un primo contatto) e comunica tutti i parametri TLS o HTTPS necessari. Nella maggior parte dei casi un client può inviare i dati anche direttamente a un server, anche senza dover dipendere da una risposta, mentre il TCP deve per prima cosa ottenere ed elaborare una conferma del server.

Per identificare una connessione TCP fa affidamento sulle porte TCP e sugli indirizzi IP dei sistemi collegati. Per questo motivo non è possibile che un client comunichi con il server attraverso più porte all’interno di una singola connessione. Il protocollo QUIC risolve la situazione affidandosi a un identificatore di connessione a 64 bit e a vari “stream” per il trasporto di dati all’interno di una connessione. Una connessione QUIC non è quindi collegata a una singola porta (in questo caso una porta UDP), a un indirizzo IP o a un determinato endpoint. I cambi di porta e IP sono possibili come lo sono le connessioni tramite multiplazione.

Ogni segmento di dati di una connessione QUIC contiene un proprio numero di sequenza, indipendentemente dal fatto che si tratti di un segmento originale o di uno inoltrato. TCP al contrario non è solito fare questa differenza, cosicché un host non è in grado di identificare lo stato di una sequenza. Solamente attraverso l’utilizzo dell’estensione delle marche temporali (o timestamp) anche il TCP permette una tale differenziazione. La marcatura progressiva dei pacchetti è perciò un vantaggio poiché permette una valutazione accurata del Round Trip Time (RTT), ovvero il tempo impiegato per tornare indietro.

I pacchetti andati perduti non rappresentano un problema significativo con QUIC. Grazie a un sistema di correzione degli errori basato su XOR non è necessario un rinvio dei dati. Questi possono essere ricostruiti in qualunque momento grazie ai pacchetti FEC (Forward Error Correction), ovvero dei backup dei pacchetti originali per gruppi di dati. Tuttavia la correzione degli errori non può funzionare se mancano più pacchetti di un gruppo di dati.

TCP tenta di inviare i dati con sempre maggiore velocità, il che rappresenta certo un vantaggio per le connessioni di dati veloci, ma che è collegato a un certo tasso di perdita. Se un pacchetto va perduto, viene immediatamente rinviato (TCP Fast Retransmit). Per fare ciò TCP riduce la finestra di coda temporanea, che ha spesso come conseguenza una trasmissione dati a intervalli. Il protocollo QUIC ovvia a questo carico eccessivo grazie al cosiddetto Packet Pacing. Il procedimento fa sì che il tasso di trasmissione venga limitato automaticamente. In questo modo si evita un sovraccarico anche in caso di connessioni non particolarmente buone. Tuttavia questa tecnica non è nuova: alcuni kernel  di Linux utilizzano il procedimento anche per il protocollo TCP.

Sin da principio è stata riposta attenzione sull’aspetto della sicurezza sia durante la fase di concezione che di progettazione di QUIC. In seguito gli sviluppatori si sono dedicati a uno dei più grandi problemi relativi a TCP: l’header dei pacchetti inviati compare sotto forma di testo in chiaro e non può essere letto senza aver prima ricevuto l’autorizzazione. Non è quindi una rarità che vengano condotti degli attacchi man in the middle e delle manipolazioni ai pacchetti (ad esempio al numero sequenziale). Invece i pacchetti QUIC sono sempre autentificati e per la maggior parte crittografati (payload incluso). Le parti dell’header che non sono crittografate, sono protette da infezioni e manipolazioni grazie all’ autenticazione da parte del destinatario.

Un ulteriore vantaggio di QUIC rispetto a TCP è che il protocollo di Google è distaccato dal sistema. Mentre il protocollo TCP deve essere supportato dalle varie piattaforme e dispositivi perché sia possibile una comunicazione (quindi supporto sia hardware che software), con QUIC è sufficiente a livello delle applicazioni. Dunque sta alle aziende di software rendere possibile il funzionamento del protocollo, senza dover dipendere dall’hardware. Fino a ora sono soprattutto le applicazioni di Google, quali Google Server, Chromium o Chrome, a disporre delle implementazioni QUIC. Ci sono però anche applicazioni di terzi che rendono possibili le connessioni attraverso il nuovo protocollo di trasporto, come il browser Opera, il web server Caddy e i prodotti di webserver e di load balancing di LiteSpeed Technologies.

Se QUIC in futuro verrà maggiormente utilizzato dipende principalmente dall’implementazione dell’IETF. Grazie agli adattamenti agli standard generali avvenuti dalla fondazione del gruppo di lavoro nel 2016, egli è passato dall’essere fortemente orientato verso Google all’essere un protocollo di rete generico di sempre maggiore rilevanza. Il processo di ottimizzazione non è ancora stato completato: il team di QUIC continua a confrontarsi con problemi persistenti per i quali vanno ancora trovate le soluzioni più adatte.

In particolare il tema della sicurezza, uno dei più importanti per lo sviluppo del protocollo, è causa di discussioni. Mentre l’ autenticazione e la crittografia contribuiscono a un trasporto sicuro dei dati, sono però anche responsabili di uno dei maggiori svantaggi di QUIC: ovvero che gli header del pacchetto dati contengono meno informazioni in chiaro di quanto non facciano le connessioni TCP. Questo rende decisamente più gravose la risoluzione di eventuali errori, la regolazione del traffico e la gestione della rete nelle connessioni QUIC. Gli operatori di rete così come gli sviluppatori di firewall e altri middlebox (come router o switch) fanno fatica a garantire la qualità dei propri servizi.

Un ulteriore problema del protocollo QUIC è che la gestione dei sovraccarichi nella connessione dati con a disposizione una buona banda può essere controproducente e favorire indirettamente un tasso di trasmissione non eccelso.

Se desiderate disattivare il protocollo scegliete semplicemente “Disabled” e riavviate il browser cliccando su “RELAUNCH NOW” nella finestra a scorrimento che comparirà nella parte inferiore del browser. Chrome verrà chiuso e, una volta riaperto, le nuove impostazioni saranno attive. Se invece volete riattivare il protocollo, procedete allo stesso modo e selezionate “Default” o “Enabled”.