Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
QUIC sta emergendo come un protocollo chiave di Internet, che sta potenzialmente superando TCP e UDP. Integra la sicurezza TLS e riduce la latenza e introduce dei flussi multipli indipendenti, migliorando drasticamente le prestazioni web. La sua architettura, permette delle connessioni più rapide ed elimina i limiti storici dei protocolli legacy. La crescente adozione di QUIC, indica una lenta ma efficace trasformazione strutturale dello stack di rete, con miglioramenti per i servizi e le applicazioni distribuite.
Internet si è basato per quasi mezzo secolo su due pilastri consolidati: TCP per il trasporto dei dati e UDP laddove la velocità era più importante dell’affidabilità.
Ora, lo stack di rete ha un terzo serio contendente per il ruolo di protocollo centrale. QUIC è da tempo al centro del web, ma con l’aumento del carico e la crescente complessità dei servizi, sta diventando chiaro che non si tratta solo di un miglioramento tecnico di HTTP, bensì di una profonda ristrutturazione della logica di comunicazione di rete.
Gli autori della nuova edizione di Computer Networks: A Systems Approach hanno deciso di ampliare significativamente la sezione dedicata a QUIC.
Il motivo è semplice: nei prossimi anni, l’importanza del protocollo potrebbe diventare paragonabile a quella di TCP. Per supportare questo aggiornamento, uno degli autori, Bruce Davie, ha rivisto gli RFC, le prime specifiche di QUIC e le pubblicazioni sullo sviluppo di SPDY e HTTP/2 per fornire un quadro più completo e accurato.
Una delle prime sfide è stata quasi banale, ma illuminante. Le specifiche QUIC si estendono per centinaia di pagine, eppure non forniscono quasi nessun diagramma visivo delle intestazioni dei pacchetti. Per gli ingegneri di rete e gli sviluppatori abituati ad analizzare i protocolli bit per bit, questo approccio complica la lettura. QUIC fa ampio uso di campi a lunghezza variabile, molti dei quali non sono allineati su limiti a 32 bit, il che rende difficile disegnare diagrammi tradizionali e ordinati.
Questa architettura rispecchia la filosofia stessa di QUIC. Il protocollo si propone di risolvere simultaneamente due problemi: evitare di sprecare byte non necessari e non incorrere in vecchie limitazioni, come accaduto con TCP e IP. Nelle precedenti generazioni di protocolli di rete, gli sviluppatori spesso implementavano campi a lunghezza fissa, per poi scoprire anni dopo che tali lunghezze non erano più sufficienti. QUIC evita questo problema utilizzando campi di lunghezza variabile.
Anche il risparmio di spazio gioca un ruolo significativo. Quando si trasmettono piccoli oggetti in HTTP, le intestazioni rappresentano una parte considerevole dell’overhead. Pertanto, QUIC cerca di mantenere i campi brevi quando un record lungo non è necessario. Per l’hardware più vecchio, la gestione di campi non allineati potrebbe essere un problema, ma per i sistemi moderni questo compromesso sembra già ragionevole: è meglio risparmiare byte nel canale piuttosto che aggrapparsi a tutti i costi a un perfetto allineamento a 32 bit.
QUIC modifica anche il modo in cui vengono identificate le connessioni. TCP associa una sessione agli indirizzi IP e ai numeri di porta di origine e destinazione. Utilizza un singolo identificatore di connessione, univoco dal punto di vista del destinatario. Questo schema consente di gestire i cambiamenti di indirizzo IP senza interrompere la sessione, ad esempio quando un dispositivo si sposta da una rete all’altra.
Ma il cambiamento principale avviene a un livello più profondo, quello dell’interazione con il TLS . Nel modello classico, HTTP si basava su TLS, che a sua volta si fondava su TCP. Prima veniva stabilita una connessione TCP, poi veniva creato un canale sicuro e solo successivamente iniziava lo scambio di dati tra le applicazioni. QUIC internalizza alcune funzionalità di TLS e ricostruisce lo stack. L’handshake TLS crea ancora un canale sicuro, ma ora HTTP viene eseguito direttamente sopra il QUIC sicuro.
In pratica, questa integrazione riduce il numero di scambi di dati di rete necessari per stabilire una connessione. Laddove in precedenza erano necessari diversi RTT, QUIC può raggiungere lo stesso risultato con un solo RTT.
In alcuni casi, i dati dell’applicazione possono essere trasmessi entro il primo RTT. Anche senza la modalità 0-RTT, che velocizza l’avvio della connessione a costo di maggiori rischi per la sicurezza, il nuovo schema offre un notevole risparmio in termini di latenza.
Gli autori considerano particolarmente importante un altro meccanismo di QUIC: i flussi all’interno di una singola connessione. È qui che, a loro avviso, il protocollo diventa un mezzo di trasporto a lungo atteso per i sistemi che operano secondo un modello richiesta-risposta. Gli autori sostengono da anni che il flusso di byte affidabile di TCP sia poco adatto per RPC e attività simili. In tali sistemi, è importante non solo consegnare i byte in ordine, ma anche restituire rapidamente le risposte a molteplici richieste indipendenti.
Il problema è ben noto sul web. Quando un browser richiede più oggetti, l’ordine di risposta rigoroso è meno importante della velocità di consegna complessiva. Quando HTTP viene eseguito su TCP, è necessario aprire più connessioni parallele o accettare i limiti di un singolo canale. La prima opzione crea una contesa non necessaria tra i diversi circuiti di controllo della congestione. La seconda porta al ben noto problema del blocco in testa alla coda : la perdita di un singolo pacchetto rallenta l’avanzamento di tutte le richieste già in corso.
QUIC elimina alcune di queste limitazioni. Un singolo canale può contenere più flussi indipendenti, e ciascun flusso continua a operare autonomamente. Se un pacchetto viene perso, il ritardo influisce solo sui flussi i cui dati erano contenuti nel pacchetto perso. Allo stesso tempo, il protocollo è in grado di monitorare la congestione complessiva e reagire in modo appropriato alla perdita. Creare un nuovo flusso è semplice: una delle due parti seleziona un nuovo identificatore e invia un frame con i primi dati.
Il meccanismo di controllo della congestione e di recupero delle perdite in QUIC è descritto in un documento RFC separato, il numero 9002. L’approccio è generalmente simile a TCP NewReno, ma presenta alcune importanti differenze.
La numerazione è per pacchetto, non per byte, e i numeri non vengono riutilizzati nemmeno durante le ritrasmissioni. Le conferme di consegna sono più flessibili e consentono una segnalazione più accurata delle lacune tra i pacchetti già ricevuti.
Gli autori del testo riconoscono che condensare centinaia di pagine di specifiche in un capitolo di un libro di testo senza perdita di informazioni è pressoché impossibile. Tuttavia, la loro conclusione generale è piuttosto chiara.
Dopo decenni di discussioni su un terzo protocollo di trasporto di massa, non riducibile né a TCP né a UDP, Internet ha finalmente un candidato valido per tale ruolo. In passato erano già stati fatti tentativi di espandere lo stack di protocolli esistente, tra cui SCTP, ma è stato QUIC a riuscire a combinare una solida base tecnica con una concreta possibilità di adozione su larga scala.
Gran parte del suo successo è dovuto al pragmatismo. Il team di QUIC ha considerato fin dall’inizio le sfide legate all’implementazione su una rete reale, pertanto il protocollo funziona su UDP e aggira le limitazioni dei dispositivi intermedi.
Di conseguenza, Internet si è evoluto da un esperimento di laboratorio a uno strumento funzionante che già accelera il web ed è più adatto a servizi in cui la richiesta e la risposta sono più importanti di un flusso continuo di byte.
