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.

Che cos’è QUIC (Quick UDP Internet Connections)?

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 trasportoridotto 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.

N.B.

A partire dal 2016 un team di lavoro dell’IETF si occupa dell’ottimizzazione del protocollo QUIC. Circa 50 sviluppatori di Google, Mozilla, Microsoft e altre aziende si sono impegnate a collaborare per lo sviluppo e la diffusione di questa specifica sotto la guida di Lars Eggert e Mark Nottingham. Sui server di Google il protocollo è utilizzato già da diversi anni, esattamente dal 2013. Inoltre QUIC è stato implementato anche nel browser di Google Chrome, facendo sì che già una parte non irrilevante del traffico di Internet (ad esempio YouTube) giri attorno all’avanzato protocollo di trasporto.

Quali vantaggi offre QUIC?

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.

Connessione più veloce

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.

Opzione multiplazione

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.

Assegnazione di numeri sequenziali unici

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.

Forward Error Correction

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.

Gestione del sovraccarico

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.

Autenticazione e crittografia

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.

Non dipendente dall’hardware

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.

Gli svantaggi del protocollo QUIC

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.

Attivare e disattivare QUIC

Anche se lo sviluppo del protocollo QUIC ha fatto grandi passi in avanti, specialmente negli ultimi anni, attualmente viene utilizzato solamente a livello sperimentale nei browser Google Chrome e Opera. Di base lo trovate già attivato nel primo e disattivato nel secondo. Gli utenti Opera devono attivare manualmente il protocollo per beneficiare del cosiddetto performance boost. Qui di seguito vi spieghiamo come fare esattamente per attivare e disattivare QUIC in entrambi i web client.

Configurare QUIC con Chrome

Innanzitutto è necessario aprire il menu di configurazione delle funzioni sperimentali per poter modificare le impostazioni relative al protocollo QUIC all’interno di Chrome. Per farlo inserite il seguente comando nella barra degli indirizzi:

chrome://flags

A questo punto cercate la voce “Experimental QUIC protocol” attraverso la funzione di ricerca, attivabile con la combinazione di tasti [CTRL] + [F]. Se non avete precedentemente modificato le impostazioni di base allora per quanto riguarda il protocollo dovrebbe essere settato su “Default”. La configurazione standard di Chrome prevede che il protocollo QUIC sia già attivo.

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”.

N.B.

Chrome offre la possibilità di vedere il funzionamento di una sessione attiva di trasmissione dati con QUIC. Tutto ciò che dovete fare è dare il comando chrome://net-internals/#quic nella barra degli indirizzi.

Configurare QUIC con Opera

Opera, basato su Chromium, ha integrato un’edizione sperimentale del protocollo QUIC già nella sua versione 16, rilasciata ad agosto 2013. La differenza con Google Chrome sta nel fatto che in Opera il protocollo è disattivato di default. È dunque necessario che prima di tutto siate voi ad attivarvi per poter sfruttare la nuova tecnologia di trasporto dei dati con Opera. Similarmente al browser di Google trovate le opzioni apposite nel menu di configurazione delle funzionalità sperimentali, che si apre dalla barra degli indirizzi con il seguente comando:

opera://flags

Nell’elenco delle varie funzioni testabili trovate quella relativa al protocollo alla voce “Experimental QUIC protocol”. Per attivare QUIC cambiate lo stato a “Enabled” e quindi riavviate il browser. Esattamente come per Chrome, se desiderate disattivare il protocollo vi basterà selezionare “Disabled” e riavviare. Opera tuttavia mette in guardia dalle modifiche e quindi dall’utilizzo delle funzionalità sperimentali e consiglia di effettuare un backup del computer prima di procedere.

N.B.

Anche con Opera potete verificare il funzionamento delle connessioni dati attive attraverso il protocollo QUIC. Una volta attivato il protocollo inserite il comando opera://net-internals/#quic nella barra degli indirizzi.

Quale sito web ha già implementato il protocollo QUIC?

Al fine di dare vita a QUIC, già a partire dal 2013 Google ha integrato il protocollo nei propri server, perciò tra le applicazioni web che permettono il trasporto dati attraverso quello che sarà probabilmente il protocollo del futuro, ci sono proprio diversi servizi di Google. Prima di qualunque altro va menzionato chiaramente il motore di ricerca, da sempre il servizio centrale dell’azienda. Ma tramite il protocollo QUIC è possibile accedere anche al servizio di mappe Google Maps, al social network Google+, al servizio e-mail Google Mail, alla soluzione per l’ufficio Google Docs o al portale video YouTube; l’unico requisito è che l’utente utilizzi il client adatto.

Gli utenti Chrome possono inoltre verificare quali altri offerte web supportano QUIC grazie all'estensione HTTP/2 and SPDY indicator. L’estensione aggiunge un piccolo simbolo a forma di fulmine accanto alla barra degli indirizzi, che si colorerà di verde ogni qual volta vi troviate su di un sito che supporta il protocollo. Posizionando il cursore del mouse sul simbolo, il tooltip vi fornisce il numero di versione.


Abbiamo una proposta per te:
Web hosting a partire da 1 €/mese!

Dominio gratis
Certificato SSL Wildcard incluso
Assistenza clienti 24/7
A partire da 1 €/mese IVA escl. per un anno,
poi 8 €/ mese IVA escl.