Origini di HTTP/3
Il protoccolo HTTP (Hypertext Transfer Protocol 1.0) nacque nel 1996, ma quasi subito ci si accorse di alcuni problemi e sue limitazioni. Nel 1997 fu così ufficializzato HTTP/1.1. Da allora passarono ben 18 anni prima che si raggiungesse un nuovo aggiornamento dello standard con HTTP/2, che fu ufficializzato nel 2015.
Il problema di HTTP/1.1
Quando una pagina web richiede 10 file javascript, il browser deve procedere a scaricare sequenzialmente questi file e il caricamento della pagina risulta bloccato fino a che tutti i file non siano stati ricevuti. Inoltre, qualsiasi problema di caricamento di uno dei file si riflette sui file successivi impedendone la ricezione. Questo processo sequenziale è dovuto al fatto che il browser deve accedere al server attraverso un’unica connessione TCP. Il fenomeno è noto con il nome di Head-of-line blocking ed è responsabile di un pesante degrado delle prestazioni.
In teoria il problema potrebbe essere ovviato procedendo in parallelo su più connessioni TCP contemporanee, ma tale soluzioni richiede eccessive risorse sia al client che al server, a maggior ragione se viene utilizzato anche il protocollo di sicurezza TLS/SSL.
La soluzione HTTP/2
La nuova versione del protocollo risolse il problema, ma solo parzialmente. Esso, a livello Applicazione, è in grado – con riferimento all’esempio iniziale – di richiedere simultaneamente tutti i 10 file necessari e di scaricarli in parallelo su una singola connessione TCP (multiplexing).
Tuttavia il problema del Head-of-line blocking permaneva a livello più basso, ovvero il livello TCP. Un flusso di dati nel quale un pacchetto venisse perso, veniva interrotto nell’attesa che il pacchetto venisse ritrasmesso. In ambienti rumorosi ad alta perdita di pacchetti, HTTP/1.1 aveva prestazioni migliori in virtù delle molteplici connessioni TCP parallele che il browser apre.
Arrivano HTTP/3 e QUIC
La principale differenza tra HTTP/2 e HTTP/3 è il protocollo di trasporto utilizzato. Invece di TCP, HTTP/3 utilizza un nuovo protocollo chiamato QUIC. QUIC è un protocollo di trasporto generico destinato a risolvere proprio i problemi di blocco head-of-line che HTTP/2 ha con TCP. Esso consente di creare una serie di flussi paralleli (simili a TCP) su UDP.
Google ha annunciato per la prima volta la disponibilità di Google QUIC otto anni fa, utilizzandolo tra Google Chrome e i servizi Google. Ciò ha permesso loro di apportare miglioramenti indipendentemente dal sistema operativo o dalla pianificazione degli aggiornamenti del sistema operativo. Google ha portato QUIC all’attenzione di IETF sei anni fa per iniziare il processo di standardizzazione. I contributori dell’IETF hanno espresso interesse per lo sviluppo di un nuovo trasporto a partire da tale protocollo sperimentale. Questa versione proprietaria è spesso chiamata “Google QUIC” o “gQUIC”.
L’IETF ha formato un gruppo di lavoro QUIC nel 2016. Il loro obiettivo è stato quello di prendere l’implementazione specifica di Google e adattarla in modo da farne un protocollo di trasporto generico. Il codice di Google QUIC assomigliava molto a HTTP/2, ma mescolato a nuove idee nel trasporto e nella crittografia. La creazione di “IETF QUIC”, si è concentrata sulla divisione delle funzionalità in componenti separati.
Evoluzione di IETF QUIC
Come spiega Mike Bishop – editor delle specifiche HTTP/3 e già contributor della RFC HTTP/2 – in un suo articolo, lo IETF ha sviluppato il protocollo proprietario di Google per diversi aspetti:
- Separazione del protocollo a livello di applicazione dal livello di trasporto. IETF QUIC è un protocollo di trasporto generico, paragonabile a TCP. HTTP/3 è la mappatura di HTTP che utilizza IETF QUIC come trasporto.
- Creazione di un set di primitive di trasporto utilizzabili da qualsiasi applicazione. I gruppi di lavoro IETF stanno già esplorando QUIC come trasporto per DNS, SSH, BGP, RTP e molti altri.
- Sostituzione della crittografia personalizzata con TLS 1.3. QUIC Crypto ha scelto il progetto TLS 1.3, che è diventato uno standard proposto nel 2018. Alcune delle idee sperimentate per la prima volta da QUIC Crypto sono ora estensioni proposte per TLS. La transizione dalla crittografia custom a TLS 1.3 standard consente di eliminare le ambiguità normative e di conformità che i siti potevano riscontrare nell’implementare gQUIC.
Le specifiche fondamentali di IETF QUIC sono state già pubblicate negli ultimi mesi:
- RFC 8999. Version-Independent Properties of QUIC, descrive la parte di QUIC che la rete può osservare. Questo non può cambiare tra le versioni QUIC di IETF.
- RFC 9000. QUIC: A UDP-Based Multiplexed and Secure Transport, è la versione 1 di IETF QUIC, il protocollo di trasporto principale. Descrive come client e server comunicano tra loro in questa versione.
- RFC 9001. Using TLS to Secure QUIC, descrive l’integrazione di TLS 1.3 e QUIC versione 1. TLS non è né sopra né sotto QUIC; la relazione è più complicata. QUIC fornisce a TLS un flusso affidabile in ordine, mentre TLS fornisce chiavi di crittografia QUIC e convalida dell’handshake.
- RFC 9002. QUIC Loss Detection and Congestion Control, fornisce un esempio di algoritmi di rilevamento delle perdite e di controllo della congestione per IETF QUIC. Come per TCP, ci sono molte strategie che un endpoint potrebbe utilizzare sia per il rilevamento delle perdite che per il controllo della congestione, ed è prevedibile che questa continuerà ad essere un’area di sperimentazione attiva.
Con le specifiche complete, la versione IETF del trasporto è stabile e pronta per l’uso in produzione. Google ha già ritirato tutte le versioni di Google QUIC che non sono conformi a RFC 8999 e presto ritirerà tutte le versioni rimanenti di Google QUIC.
E HTTP/3 ?
L’insieme di RFC viste sopra non include HTTP/3 (o il suo documento complementare, QPACK). Ciò potrebbe sorprendere molti, dal momento che la specifica è stata codificata nel gruppo di lavoro QUIC e presentata per la pubblicazione allo stesso tempo.
La semantica HTTP di base non cambia tra le versioni: il protocollo HTTP ha essenzialmente la stessa funzionalità, che si tratti di HTTP/1.1, HTTP/2 o HTTP/3. Tuttavia, la specifica della semantica HTTP è attualmente mescolata con la definizione di HTTP/1.1. Il gruppo di lavoro HTTP IETF sta estraendo queste semantiche, indipendenti dalla versione, in due nuovi documenti: HTTP Semantics e HTTP caching.
Da questi due documenti, nasce un nuovo trio di specifiche che stabiliscono la relazione tra la semantica HTTP e i vari protocolli di trasporto:
- HTTP/1.1 è tipicamente usato su TCP e spesso impiega TLS;
- HTTP/2 che utilizza sia TLS 1.2 che TCP;
- HTTP/3 che utilizza IETF QUIC versione 1 e incorpora TLS 1.3.
Da notare che nessuna di queste versioni di HTTP depreca le altre, perché ognuna è indicata per diversi casi d’uso. Esistono reti che bloccano UDP, il che significa che HTTP/3 non può essere utilizzato; la specifica consiglia di utilizzare su tali reti una versione di HTTP basata su TCP. HTTP/1.1 e HTTP/2 stanno ancora ricevendo attenzione dall’IETF.
Poiché tutti questi nuovi documenti si basano sul documento HTTP Semantics, nessuno di essi può essere pubblicato fino al completamento di tale documento. Questo dovrebbe accadere nei prossimi mesi. L’editor RFC pubblicherà la specifica aggiornata HTTP/1.1 e la specifica HTTP/3 circa nello stesso momento, poiché sono state sviluppate in collaborazione rispettivamente con HTTP Semantics e QUIC. Il gruppo di lavoro HTTP ha adottato la corrispondente specifica HTTP/2 aggiornata, che è quasi completa.
Anteprima delle prestazioni
Request Metrics in un suo articolo ha presentato un benchmark preliminare delle prestazioni di HTTP/3.
I grafici sono stati ottenuti utilizzando lo stesso browser per richiedere lo stesso sito, sulla stessa rete, variando solo il protocollo HTTP in uso. Ogni sito è stato recuperato 20 volte e il tempo di risposta misurato. Si vede chiaramente il miglioramento delle prestazioni a ogni nuova versione del protocollo HTTP. I miglioramenti diventano ancora più importanti quando si richiedono risorse su distanze geografiche maggiori e reti meno affidabili.
In conclusione
HTTP/3 potrà fare una grande differenza nel modo in cui gli utenti accedono al web. In generale, più risorse richiede un sito, maggiore sarà il miglioramento delle prestazioni ottenuto con HTTP/3 e QUIC. Mentre lo standard continua ad avvicinarsi alla sua finalizzazione, potrebbe essere il momento di iniziare a cercare fornitori in grado di abilitarlo per i tuoi siti.
Foto di Nastya Dulhiier
