Prestazioni di TLS: QUIC e HTTP/3

HTTP/2 multiplexa più stream su un'unica connessione TCP, risolvendo l'head-of-line blocking per connessione di HTTP/1.1. Tuttavia, TCP causa head-of-line blocking a livello di trasporto: se un segmento TCP va perso, tutti i dati che lo seguono nella coda devono attendere la ritrasmissione, bloccando contemporaneamente tutti gli stream HTTP/2. Una perdita di pacchetti dell'1% può ridurre le prestazioni di HTTP/2 al di sotto di quelle di HTTP/1.1 con più connessioni. QUIC (Quick UDP Internet Connections) risolve il problema implementando stream multiplexati su UDP, dove il recupero delle perdite a livello di stream non blocca gli altri stream.

QUIC è un protocollo di trasporto basato su UDP, sviluppato da Google (2012-2015) e standardizzato dall'IETF come RFC 9000 (2021). QUIC integra TLS 1.3 a livello di trasporto: non esiste un handshake TLS separato sopra QUIC; TLS è integrato direttamente nell'handshake di QUIC. QUIC offre: stream multiplexati senza head-of-line blocking, migrazione della connessione (mantenimento della connessione quando si cambia rete, ad esempio da WiFi a LTE), instaurazione della connessione 0-RTT per le connessioni successive e rilevamento delle perdite e controllo della congestione integrati. HTTP/3 (RFC 9114) definisce la semantica HTTP sugli stream QUIC.

L'handshake di QUIC combina l'instaurazione della connessione e la negoziazione TLS. Nel primo invio (0 RTT nella terminologia QUIC), il client invia pacchetti Initial contenenti TLS ClientHello. Il server risponde con il proprio Initial (ServerHello) e con pacchetti Handshake (encrypted extensions, certificate, Finished). Il client invia Handshake Finished e può quindi iniziare a inviare dati applicativi: questo corrisponde a 1-RTT. Per le connessioni 0-RTT, il client invia pacchetti 0-RTT (dati applicativi) insieme a ClientHello, utilizzando una chiave derivata dal segreto di ripresa della sessione precedente, ottenendo zero round trip aggiuntivi per le sessioni memorizzate nella cache.

QUIC utilizza quattro livelli di cifratura distinti, corrispondenti alle fasi della derivazione delle chiavi TLS: Initial (AEAD derivato da QUIC che utilizza una chiave costante nota: garantisce l'integrità, ma non la riservatezza contro attaccanti sofisticati), Handshake (derivato da TLS handshake_secret: garantisce la riservatezza dei messaggi dell'handshake TLS), 0-RTT (derivato da early_secret della sessione precedente: cifra i dati applicativi 0-RTT) e 1-RTT (derivato da TLS master_secret: cifra tutti i dati applicativi). Gli header QUIC sono parzialmente cifrati: il numero del pacchetto e il payload sono cifrati, ma alcune informazioni di instradamento (Connection ID) rimangono visibili ai load balancer.

Le connessioni QUIC sono identificate da un Connection ID (CID), anziché da una 4-tuple (IP sorgente, porta sorgente, IP destinazione, porta destinazione). Questo consente alle connessioni di sopravvivere ai cambiamenti di rete: quando un client mobile passa dal WiFi a LTE, l'indirizzo IP cambia, ma il CID rimane invariato. Il client invia un frame PATH_CHALLENGE sul nuovo percorso; il server risponde con PATH_RESPONSE, convalidando il nuovo indirizzo. La connessione prosegue senza interruzioni e senza rinegoziazione. TCP non supporta questo meccanismo: una connessione TCP è associata alla propria 4-tuple e deve essere ristabilita quando cambia la rete, richiedendo un nuovo handshake TLS. La migrazione QUIC migliora notevolmente le prestazioni percepite dagli utenti mobili.

HTTP/3 mappa la semantica HTTP sugli stream QUIC. Ogni coppia richiesta-risposta HTTP occupa uno stream QUIC bidirezionale separato. Gli stream QUIC sono indipendenti: una perdita sullo stream 3 non blocca lo stream 7. HTTP/3 utilizza QPACK per la compressione degli header, in sostituzione di HPACK di HTTP/2; QPACK è stato riprogettato per funzionare senza richiedere la consegna in ordine. Due stream unidirezionali di controllo dedicati trasportano le impostazioni e le istruzioni del decoder/encoder. Il server push in HTTP/3 utilizza push stream unidirezionali. L'effetto complessivo è che HTTP/3 supera HTTP/2 soprattutto in presenza di perdite di pacchetti, come nelle reti mobili o sui percorsi congestionati, dove l'head-of-line blocking di TCP è più dannoso.

Le misurazioni delle prestazioni di QUIC e HTTP/3 nel mondo reale mostrano risultati variabili in base alle condizioni di rete. Sulle reti di buona qualità, con bassa latenza e poche perdite di pacchetti, HTTP/3 e HTTP/2 offrono prestazioni simili; l'overhead di QUIC, dovuto a header più grandi e all'elaborazione di UDP, può persino rendere HTTP/3 leggermente più lento. Sulle reti soggette a perdite, con oltre l'1% di pacchetti persi, comuni nelle reti mobili e satellitari, HTTP/3 supera significativamente HTTP/2. Google ha riportato una riduzione del 7-8% del rebuffering su YouTube passando a QUIC. Facebook (Meta) ha riportato un miglioramento del 7-15% nella latenza delle richieste per i feed di Instagram tramite QUIC. I vantaggi sono più evidenti nella tail latency (p95, p99), dove gli stalli causati dalle ritrasmissioni TCP hanno l'impatto maggiore.

Il bilanciamento del carico QUIC è più complesso di quello TCP perché QUIC è basato su UDP e i load balancer UDP stateless non possono mantenere l'affinità delle connessioni. IETF draft-ietf-quic-load-balancers definisce un approccio in cui i server codificano le informazioni di instradamento nel Connection ID, consentendo ai load balancer di inoltrare i pacchetti della stessa connessione allo stesso server senza mantenere lo stato delle singole connessioni. Il Connection ID contiene un identificatore del server cifrato con una chiave condivisa tra il load balancer e i server. Cloudflare, Fastly e Nginx implementano varianti di questo approccio. Anche l'attraversamento del NAT è una preoccupazione: le connessioni QUIC devono sopravvivere alla riassegnazione del NAT, gestita dal meccanismo di migrazione della connessione.

Le principali CDN hanno implementato QUIC e HTTP/3 su larga scala. Cloudflare fornisce HTTP/3 dal 2019 e riporta che circa il 20% del traffico utilizza QUIC quando il protocollo è supportato sia dal client sia dal server. Fastly, Akamai e AWS CloudFront supportano HTTP/3 sui rispettivi nodi edge. L'infrastruttura di Google, inclusi Search, YouTube e Gmail, utilizza QUIC internamente dal 2013 e rende disponibile HTTP/3 al pubblico. Le implementazioni nelle CDN traggono vantaggio dalla ripresa 0-RTT di QUIC: i visitatori abituali instaurano le connessioni più rapidamente e la migrazione della connessione migliora le prestazioni per gli utenti mobili che passano da un access point all'altro durante la distribuzione dei contenuti.

La progettazione di QUIC basata su UDP introduce specifiche considerazioni sulla sicurezza. Attacchi di amplificazione: un attaccante può falsificare un IP sorgente e inviare piccoli pacchetti Initial, inducendo il server a inviare grandi risposte Handshake alla vittima. QUIC mitiga il problema limitando le risposte del server a tre volte i dati ricevuti finché non viene completata la convalida dell'indirizzo, tramite il meccanismo RETRY. Per contrastare il flooding delle connessioni, i server QUIC devono limitare la frequenza dei nuovi tentativi di connessione provenienti dallo stesso IP. Gli attacchi alla negoziazione della versione sono impediti includendo la versione nell'handshake protetto crittograficamente. La cifratura integrata di QUIC impedisce agli apparati di ispezione di analizzare il payload QUIC senza trovarsi sul percorso e disporre del certificato del server, migliorando la privacy rispetto al traffico TCP ispezionabile.

La distribuzione di HTTP/3 richiede: (1) un server compatibile con QUIC, come nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed, oppure un'implementazione a livello applicativo tramite le librerie quic-go, aioquic o ngtcp2; (2) la porta UDP 443 aperta nei firewall: molti firewall aziendali bloccano UDP 443, causando il fallback di QUIC a TCP/TLS; (3) la pubblicizzazione del supporto HTTP/3 tramite l'header di risposta Alt-Svc: Alt-Svc: h3=":443"; ma=86400, che invita i client HTTP/2 a eseguire l'upgrade; (4) load balancer compatibili con QUIC o pass-through UDP a livello L4; (5) il monitoraggio di metriche specifiche di QUIC: eventi di migrazione della connessione, tasso di accettazione 0-RTT e tasso di fallback del protocollo. Un rilascio graduale con fallback a HTTPS è trasparente per i client che non supportano QUIC.

In che modo QUIC risolve il problema dell'head-of-line blocking che interessa HTTP/2 su TCP?

QUIC integra TLS 1.3 a livello di trasporto su UDP, eliminando l'head-of-line blocking di TCP grazie al recupero delle perdite indipendente per ogni stream. I Connection ID consentono la migrazione attraverso i cambiamenti di rete senza rinegoziazione. HTTP/3 mappa HTTP sugli stream QUIC utilizzando la compressione degli header QPACK. La ripresa della connessione 0-RTT riutilizza i segreti della sessione TLS. QUIC supera HTTP/2 soprattutto in presenza di perdite di pacchetti, come nelle reti mobili o congestionate. Il bilanciamento del carico QUIC richiede la codifica delle informazioni di instradamento del server nei Connection ID. La distribuzione richiede UDP 443, server compatibili con QUIC e header Alt-Svc per pubblicizzare il protocollo.