QUIC: ciò che si nasconde dietro al pro­to­col­lo spe­ri­men­ta­le di Google

Grazie ai sempre più veloci accessi DSL il tempo di ca­ri­ca­men­to dei siti Internet tende ge­ne­ral­men­te a ridursi sempre più. L’idea generale che ne consegue è che i siti web si debbano aprire ve­lo­ce­men­te, il che complica la vita ai progetti web con tempi di ca­ri­ca­men­to più lunghi. A rincarare la dose è l’im­por­tan­za sempre maggiore che sta assumendo la codifica dei dati. Sebbene lo standard HTTP Secure (o HTTPS) si dimostri un alleato af­fi­da­bi­le nella pro­te­zio­ne della privacy degli utenti, registra anche un ral­len­ta­men­to dei tempi di ca­ri­ca­men­to a causa dell’handshake TLS e dello scambio di chiavi e cer­ti­fi­ca­ti. Questa si­tua­zio­ne dovrebbe essere risolta dal pro­to­col­lo QUIC di Google.

QUIC è un pro­to­col­lo di trasporto spe­ri­men­ta­le del gigante dei motori di ricerca Google, pre­sen­ta­to per la prima volta al pubblico nel 2013. Il nome del pro­to­col­lo fa ri­fe­ri­men­to a “Quick UDP Internet Con­nec­tions“, che a sua volta si rifà all’invio di pacchetti dati semplice e veloce reso possibile dal pro­to­col­lo con­nec­tion­less UDP (User Datagram Protocol). L’in­ten­zio­ne dietro a QUIC è il desiderio di svi­lup­pa­re un’al­ter­na­ti­va ai pro­to­col­li 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 con­nes­sio­ne e di trasporto ridotto e che permetta la mul­ti­pla­zio­ne.

È a questo scopo che Google ha pro­get­ta­to QUIC in modo tale che il pro­to­col­lo regoli au­to­ma­ti­ca­men­te i controlli di con­nes­sio­ne. Al primo contatto tra mittente e de­sti­na­ta­rio questi si scambiano i cer­ti­fi­ca­ti e le chiavi necessari per la de­co­di­fi­ca dei da­ta­gram­mi inviati. Tale scambio non avviene invece durante le co­mu­ni­ca­zio­ni suc­ces­si­ve, limitando la latenza. Come pro­to­col­lo di crit­to­gra­fia viene uti­liz­za­to TLS, versione 1.3, ot­ti­miz­za­to per ottenere la maggior velocità di scambio possibile (stan­dar­diz­za­to a marzo 2017), che presenta un vantaggio rispetto alla soluzione di Google.

In materia di Mul­ti­ple­xing QUIC si orienta al pro­to­col­lo SPDY, sempre elaborato da Google, e che è servito da modello per l’HTTP/2. At­tra­ver­so una singola con­nes­sio­ne client-server possono essere trasmessi diversi flussi di dati, riducendo mag­gior­men­te il tempo di ca­ri­ca­men­to.

Alcune im­por­tan­ti ca­rat­te­ri­sti­che e vantaggi di QUIC sono già stati af­fron­ta­ti, ma vale la pena fare maggior chiarezza. Il pro­to­col­lo TCP ci servirà a questo scopo da confronto, anche se, no­no­stan­te abbia fatto da apripista per l’ideazione di questo ambizioso pro­to­col­lo di trasporto, è cer­ta­men­te inferiore allo stesso sotto certi aspetti, come di­mo­stra­no i vantaggi di QUIC.

Il motivo de­ter­mi­nan­te per il quale QUIC si dimostra migliore di TCP è la con­nes­sio­ne si­gni­fi­ca­ti­va­men­te più veloce. Anche senza codifica SSL/TLS, una con­nes­sio­ne per mezzo della co­sid­det­ta three-way handshake at­tra­ver­so il classico pro­to­col­lo di trasporto prevede più passaggi rispetto alla soluzione proposta da Google e basata su UDP. QUIC avvia una con­nes­sio­ne 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 di­ret­ta­men­te 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 iden­ti­fi­ca­re una con­nes­sio­ne TCP fa af­fi­da­men­to sulle porte TCP e sugli indirizzi IP dei sistemi collegati. Per questo motivo non è possibile che un client comunichi con il server at­tra­ver­so più porte all’interno di una singola con­nes­sio­ne. Il pro­to­col­lo QUIC risolve la si­tua­zio­ne af­fi­dan­do­si a un iden­ti­fi­ca­to­re di con­nes­sio­ne a 64 bit e a vari “stream” per il trasporto di dati all’interno di una con­nes­sio­ne. Una con­nes­sio­ne QUIC non è quindi collegata a una singola porta (in questo caso una porta UDP), a un indirizzo IP o a un de­ter­mi­na­to endpoint. I cambi di porta e IP sono possibili come lo sono le con­nes­sio­ni tramite mul­ti­pla­zio­ne.

Ogni segmento di dati di una con­nes­sio­ne QUIC contiene un proprio numero di sequenza, in­di­pen­den­te­men­te dal fatto che si tratti di un segmento originale o di uno inoltrato. TCP al contrario non è solito fare questa dif­fe­ren­za, cosicché un host non è in grado di iden­ti­fi­ca­re lo stato di una sequenza. Solamente at­tra­ver­so l’utilizzo dell’esten­sio­ne delle marche temporali (o timestamp) anche il TCP permette una tale dif­fe­ren­zia­zio­ne. La marcatura pro­gres­si­va dei pacchetti è perciò un vantaggio poiché permette una va­lu­ta­zio­ne accurata del Round Trip Time (RTT), ovvero il tempo impiegato per tornare indietro.

I pacchetti andati perduti non rap­pre­sen­ta­no un problema si­gni­fi­ca­ti­vo con QUIC. Grazie a un sistema di cor­re­zio­ne degli errori basato su XOR non è ne­ces­sa­rio un rinvio dei dati. Questi possono essere ri­co­strui­ti in qualunque momento grazie ai pacchetti FEC (Forward Error Cor­rec­tion), ovvero dei backup dei pacchetti originali per gruppi di dati. Tuttavia la cor­re­zio­ne degli errori non può fun­zio­na­re se mancano più pacchetti di un gruppo di dati.

TCP tenta di inviare i dati con sempre maggiore velocità, il che rap­pre­sen­ta certo un vantaggio per le con­nes­sio­ni di dati veloci, ma che è collegato a un certo tasso di perdita. Se un pacchetto va perduto, viene im­me­dia­ta­men­te rinviato (TCP Fast Re­tran­smit). Per fare ciò TCP riduce la finestra di coda tem­po­ra­nea, che ha spesso come con­se­guen­za una tra­smis­sio­ne dati a in­ter­val­li. Il pro­to­col­lo QUIC ovvia a questo carico eccessivo grazie al co­sid­det­to Packet Pacing. Il pro­ce­di­men­to fa sì che il tasso di tra­smis­sio­ne venga limitato au­to­ma­ti­ca­men­te. In questo modo si evita un so­vrac­ca­ri­co anche in caso di con­nes­sio­ni non par­ti­co­lar­men­te buone. Tuttavia questa tecnica non è nuova: alcuni kernel  di Linux uti­liz­za­no il pro­ce­di­men­to anche per il pro­to­col­lo TCP.

Sin da principio è stata riposta at­ten­zio­ne sull’aspetto della sicurezza sia durante la fase di con­ce­zio­ne che di pro­get­ta­zio­ne di QUIC. In seguito gli svi­lup­pa­to­ri 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’au­to­riz­za­zio­ne. Non è quindi una rarità che vengano condotti degli attacchi man in the middle e delle ma­ni­po­la­zio­ni ai pacchetti (ad esempio al numero se­quen­zia­le). Invece i pacchetti QUIC sono sempre au­ten­ti­fi­ca­ti e per la maggior parte crit­to­gra­fa­ti (payload incluso). Le parti dell’header che non sono crit­to­gra­fa­te, sono protette da infezioni e ma­ni­po­la­zio­ni grazie all’ au­ten­ti­ca­zio­ne da parte del de­sti­na­ta­rio.

Un ulteriore vantaggio di QUIC rispetto a TCP è che il pro­to­col­lo di Google è di­stac­ca­to dal sistema. Mentre il pro­to­col­lo TCP deve essere sup­por­ta­to dalle varie piat­ta­for­me e di­spo­si­ti­vi perché sia possibile una co­mu­ni­ca­zio­ne (quindi supporto sia hardware che software), con QUIC è suf­fi­cien­te a livello delle ap­pli­ca­zio­ni. Dunque sta alle aziende di software rendere possibile il fun­zio­na­men­to del pro­to­col­lo, senza dover dipendere dall’hardware. Fino a ora sono so­prat­tut­to le ap­pli­ca­zio­ni di Google, quali Google Server, Chromium o Chrome, a disporre delle im­ple­men­ta­zio­ni QUIC. Ci sono però anche ap­pli­ca­zio­ni di terzi che rendono possibili le con­nes­sio­ni at­tra­ver­so il nuovo pro­to­col­lo di trasporto, come il browser Opera, il web server Caddy e i prodotti di webserver e di load balancing di LiteSpeed Tech­no­lo­gies.

Se QUIC in futuro verrà mag­gior­men­te uti­liz­za­to dipende prin­ci­pal­men­te dall’im­ple­men­ta­zio­ne dell’IETF. Grazie agli adat­ta­men­ti agli standard generali avvenuti dalla fon­da­zio­ne del gruppo di lavoro nel 2016, egli è passato dall’essere for­te­men­te orientato verso Google all’essere un pro­to­col­lo di rete generico di sempre maggiore rilevanza. Il processo di ot­ti­miz­za­zio­ne non è ancora stato com­ple­ta­to: il team di QUIC continua a con­fron­tar­si con problemi per­si­sten­ti per i quali vanno ancora trovate le soluzioni più adatte.

In par­ti­co­la­re il tema della sicurezza, uno dei più im­por­tan­ti per lo sviluppo del pro­to­col­lo, è causa di di­scus­sio­ni. Mentre l’ au­ten­ti­ca­zio­ne e la crit­to­gra­fia con­tri­bui­sco­no a un trasporto sicuro dei dati, sono però anche re­spon­sa­bi­li di uno dei maggiori svantaggi di QUIC: ovvero che gli header del pacchetto dati con­ten­go­no meno in­for­ma­zio­ni in chiaro di quanto non facciano le con­nes­sio­ni TCP. Questo rende de­ci­sa­men­te più gravose la ri­so­lu­zio­ne di eventuali errori, la re­go­la­zio­ne del traffico e la gestione della rete nelle con­nes­sio­ni QUIC. Gli operatori di rete così come gli svi­lup­pa­to­ri di firewall e altri middlebox (come router o switch) fanno fatica a garantire la qualità dei propri servizi.

Un ulteriore problema del pro­to­col­lo QUIC è che la gestione dei so­vrac­ca­ri­chi nella con­nes­sio­ne dati con a di­spo­si­zio­ne una buona banda può essere con­tro­pro­du­cen­te e favorire in­di­ret­ta­men­te un tasso di tra­smis­sio­ne non eccelso.

Se de­si­de­ra­te di­sat­ti­va­re il pro­to­col­lo scegliete sem­pli­ce­men­te “Disabled” e riavviate il browser cliccando su “RELAUNCH NOW” nella finestra a scor­ri­men­to che comparirà nella parte inferiore del browser. Chrome verrà chiuso e, una volta riaperto, le nuove im­po­sta­zio­ni saranno attive. Se invece volete riat­ti­va­re il pro­to­col­lo, procedete allo stesso modo e se­le­zio­na­te “Default” o “Enabled”.