Cosa È HTTP/3 – La Verità sul Nuovo Protocollo Veloce Basato su UDP

TL;DR

Nel novembre 2018, l’Internet Engineering Task Force (IETF) si è riunito a Bangkok per l’adozione di un nuovo Internet Draft. Al protocollo di trasporto QUIC, un successore di HTTP/2, è stato assegnato il nome HTTP/3.

Il protocollo HTTP/3 si basa su UDP ed è già utilizzato da importanti aziende di Internet come Google e Facebook. Se utilizzate Chrome e vi connettete ad un servizio Google, probabilmente state già utilizzando QUIC.

La nuova versione del protocollo HTTP sfrutta il protocollo UDP di basso livello e definisce molte delle nuove funzionalità presenti nelle versioni precedenti di HTTP a livello di TCP. Questo fornisce un modo per risolvere i vincoli all’interno dell’infrastruttura internet esistente.

I primi risultati sono promettenti, e quando l’Internet Draft dell’IETF scadrà nel Agosto 2021, potremo aspettarci che HTTP/3 sia promosso a nuovo standard HTTP di terza generazione.

Progressi di HTTP/3 nel 2024

Alcuni sostengono che nell’industria del web la fame di maggiore velocità e minore latenza è pari solo alla fame di RAM di Google Chrome.

Qualche anno fa abbiamo pubblicato un articolo su HTTP/2, uno standard che, secondo W3Techs, ha ormai raggiunto un tasso di adozione mondiale del 45% circa. E secondo Can I Use, è anche supportato da tutti i moderni browser web. Eppure eccoci qui a scrivere un articolo sulla prossima versione del protocollo: HTTP/3.

Al momento in cui scriviamo, HTTP/3 è un Internet-Draft (o ID) dell’IETF, il che significa che è allo studio un imminente standard Internet da parte della Internet Engineering Task Force – un organismo internazionale degli standard internet, incaricato di definire e promuovere accordi sugli standard dei protocolli internet, come TCP, IPv6, VoIP, Internet of Things, ecc.

È un organismo aperto che riunisce l’industria del web e facilita la discussione sulla direzione che seguirà Internet. Attualmente, la fase “Internet Draft” di HTTP/3 è l’ultima prima che le proposte siano promosse al livello di Request-for-Comments (o RFC), che possiamo considerare, a tutti gli effetti, definizioni ufficiali del protocollo internet.

Anche se HTTP/3 non è ancora un protocollo Internet ufficiale, molte aziende e progetti hanno già iniziato ad aggiungere il supporto HTTP/3 nei loro prodotti.

Supporto dei Browser Web per HTTP/3

Sul fronte dei browser web, Chrome v87, Firefox v88 e Edge v87 hanno tutti HTTP/3 abilitato per impostazione predefinita. Per gli utenti di Safari, l’opzione per abilitare HTTP/3 è stata aggiunta in Safari Technology Preview v104. Tuttavia, il supporto HTTP/3 non è attualmente disponibile nella versione stabile di Safari.

Supporto della Libreria per HTTP/3

Per gli sviluppatori che cercano di sfruttare le tecnologie HTTP/3, molte librerie popolari hanno già aggiunto il supporto per il nuovo protocollo. Poiché HTTP/3 è ancora in fase di Internet Draft, cercate di non perdere gli ultimi aggiornamenti quando lavorate con una delle librerie qui sotto.

• Python – http3 e aioquic
• Rust – quiche, neqo, e quinn
• C – nghttp3 e lsquic
• Go – quicgo
• JavaScript – Node.js

Supporto Infrastruttura per HTTP/3

Dal punto di vista dell’infrastruttura, Cloudflare ha aperto la strada con il supporto per HTTP/3 in tutta la sua rete edge. Questo significa che i siti con Cloudflare abilitato possono trarre vantaggio dai miglioramenti di sicurezza e prestazioni di HTTP/3 senza alcun lavoro aggiuntivo.

In Kinsta, tutti i siti che ospitiamo sono protetti dalla nostra integrazione gratuita con Cloudflare. Oltre a un firewall di livello aziendale e alla protezione DDoS, i clienti Kinsta hanno anche accesso a HTTP/3!

Per testare se il vostro sito supporta HTTP/3, potete usare lo strumento di test HTTP/3 di Geekflare. Basta digitare il vostro dominio e premere il pulsante “Check HTTP/3”. Lo strumento vi farà sapere se il vostro sito è abilitato per HTTP/3.

Se il vostro sito supporta HTTP/3, dovreste vedere un messaggio come quello qui sotto. Poiché kinstalife.com è ospitato su Kinsta, HTTP/3 è pienamente supportato grazie alla nostra integrazione con Cloudflare.

Per verificare il supporto HTTP/3, potete anche usare l’ispettore del vostro browser. Per questo esempio, useremo l’ultima versione di Google Chrome che supporta HTTP/3.

Per aprire l’ispettore, fate clic con il tasto destro del mouse sulla pagina e poi su “Inspect” e navigate fino alla scheda “Network”. Nella colonna “Protocol”, potete vedere il protocollo HTTP utilizzato per la connessione. Le connessioni HTTP/2 appaiono come “h2”, mentre le connessioni HTTP/3 appaiono come “h3-XX” (XX si riferisce a uno specifico progetto HTTP/3). Come potete vedere nell’immagine qui sotto, kinstalife.com supporta connessioni su “h3-29”, che significa “HTTP/3 Draft 29”.

Ora che abbiamo esaminato lo stato attuale di HTTP/3, vediamo più nel dettaglio alcune delle differenze tra HTTP/2 e HTTP/3!

Un Po’ di Background – È Iniziato Con HTTP/2

HTTP/2 ha apportato alcuni seri miglioramenti con download non bloccanti, pipeline e server push che ci hanno aiutato a superare alcune limitazioni del protocollo TCP sottostante. Questo ci ha permesso di ridurre al minimo il numero dei cicli richiesta-risposta e di handshake.

HTTP/2 ha reso possibile il push di più di una risorsa in una singola connessione TCP – multiplexing. Abbiamo anche ottenuto una maggiore flessibilità nell’ordinare i download statici e le nostre pagine non sono più vincolate alla progressione lineare dei download.

In pratica, ciò significa che ora una risorsa javascript di grandi dimensioni non è necessariamente un punto di strozzatura per tutte le altre risorse statiche rimaste in attesa del proprio turno.

Aggiungete a questo la compressione HPACK dell’header HTTP/2 e il formato binario predefinito per il trasferimento dei dati, ed ecco a voi, in molti casi, un protocollo significativamente più efficiente.

Le principali implementazioni dei browser hanno reso obbligatorio per i siti web l’implementazione della crittografia – SSL – per poter sfruttare i benefici di HTTP/2 – e a volte questo ha comportato un sovraccarico di calcolo che ha reso i miglioramenti nella velocità non percepibili. Ci sono stati anche alcuni casi in cui gli utenti hanno segnalato un rallentamento con la transizione a HTTP/2.

Diciamo solo che i primi giorni di adozione di questa versione non sono stati per deboli di cuore.

Inoltre, l’implementazione di Nginx mancava della funzione server-push, basandosi solo su un modulo. E i moduli Nginx non sono i soliti moduli drop-in di Apache che potete semplicemente copiare: Nginx deve essere ricompilato con questi moduli.

Sebbene alcuni di questi problemi ora sono stati risolti, se guardiamo all’intero stack del protocollo, vediamo che il vincolo principale si trova ad un livello inferiore rispetto ad HTTP/2.

Per descriverlo meglio, analizzeremo lo stack del protocollo Internet di oggi a partire dal layer inferiore. Se volete sapere di più sul background di HTTP/2, non perdetevi la nostra guida definitiva ad HTTP/2.

Internet Protocol (IP)

L’IP (Internet Protocol) definisce la parte inferiore dell’intera topologia di Internet. È la parte dello stack di Internet che possiamo dire tranquillamente che non è negoziabile senza dover cambiare tutto, compresa la sostituzione dell’intera infrastruttura hardware, dai router ai server e persino alle macchine degli utenti finali.

Quindi, sebbene la revisione del protocollo possa essere una cosa necessaria, uno sforzo di tale portata non è prevedibile in questo momento, soprattutto perché non abbiamo trovato un’alternativa valida, innovativa ma compatibile con le versioni precedenti.

Possiamo tornare a ritroso all’inizio del protocollo IP fino al 1974, ad un documento pubblicato dall’Institute of Electrical and Electronics Engineers di Vint Cerf e Bob Cahn. Il documento descriveva pacchetti inviati su una rete, instradati attraverso indirizzi IP e indirizzi numerici definiti di nodi in rete/reti. Il protocollo definiva il formato di questi pacchetti, o datagrammi, le sue intestazioni e il carico utile.

Dopo la definizione della RFC 760 del 1980, l’IETF si è fermata alla definizione ampiamente utilizzata fino ad oggi, nella sua Request For Comments 791. Si tratta della quarta versione del protocollo, ma potremmo dire che è la prima versione di produzione.

Il protocollo utilizza indirizzi a 32 bit, cosa che imposta un limite al numero di indirizzi a circa 4 miliardi. Questa limitazione è la spiegazione del mistero del perché gli utenti di Internet non business ricevano dai loro ISP “indirizzi IP dinamici”, e un IP statico è considerato un “valore aggiunto” e spesso soggetto a costi addizionali.

Stanno razionando.

Dopo un po’ ci si è resi conto che gli indirizzi a 32 bit non erano sufficienti e in breve tempo si sarebbero esauriti, così sono state pubblicate molte RFC per cercare di risolvere il problema. Sebbene queste soluzioni siano oggi ampiamente utilizzate, e facciano parte della nostra vita quotidiana, continuano ad accumulare problemi.

L’Internet Protocol versione 6, o IPv6, è nato come soluzione per superare questi limiti e per essere gradualmente adottato al posto della versione precedente. È stato creato un documento Draft Standard per l’IETF nel 1998 ed è stato promosso a Internet Standard nel 2017.

Mentre lo spazio degli indirizzi IPv4 è limitato dalla lunghezza degli indirizzi a 32 bit, allo standard IPv6 sono stati assegnati 128 bit, ossia 3,4 * 10 ^ 38 possibili indirizzi. Dovrebbe essere sufficiente per un bel po’ di tempo.

Secondo quanto afferma Google sulla connettività IPv6 tra i suoi utenti, a giugno 2021 l’adozione di IPv6 è di poco superiore al 35%.

L’IP è uno layer rudimentale dello stack di Internet che definisce la maggior parte delle cose di base, senza garanzie di consegna, integrità dei dati o ordine dei pacchetti trasmessi. Da solo è inaffidabile. Il formato dell’intestazione dell’IPv4 fornisce il checksum dell’header, utilizzato dai nodi di trasmissione per verificare l’integrità dell’intestazione. Questo lo rende diverso dalla versione IPv6, che si basa sul sottostante Livello di accesso alla rete, che gli consente di essere più veloce.

Capire il ruolo di TCP e UDP

È il momento di capire come HTTP/3 si integra con TCP e UDP.

TCP

Mentre IP è il layer sottostante a tutte le nostre comunicazioni online di oggi, TCP (Transmission Control Protocol) è una parte di livello superiore della suite di protocolli Internet, e garantisce l’affidabilità necessaria al web, alla posta, al trasferimento di file (FTP) – all’applicazione dei layer/protocolli di Internet.

Ciò include la creazione di connessioni a più fasi, con handshake, ordine sicuro dei pacchetti e ritrasmissione dei pacchetti persi. Fornisce feedback (Acks) di consegna al mittente e così via. C’è anche il calcolo del checksum per la rilevazione degli errori.

Tutte queste cose stanno ad indicare i molti passaggi che rendono TCP un protocollo affidabile, rendendolo una solida base dei più noti servizi Internet che usiamo oggi.

Fino ad oggi le sue specifiche risalenti al 1974 (RFC 675) e al 1981 (RFC 793) non sono cambiate sostanzialmente.

L’affidabilità fornita da TCP, tuttavia, non è senza costi. Il sovraccarico di tutti i roundtrip richiesti dagli handshake, dai feedback di consegna, dalle garanzie di ordine e dai checksum che potrebbero essere considerati deboli e ridondanti. Questo ha reso il TCP un collo di bottiglia del moderno stack di protocolli. HTTP/2 ha raggiunto un tale miglioramento della velocità che lo stesso può essere raggiunto solo al top di TCP.

UDP

Anche UDP (User Datagram Protocol) è una delle parti dell’Internet Protocol Suite, con le sue specifiche risalenti a l1980 (RFC 768).

È, come suggerisce il nome, un protocollo senza connessione basato su datagramma. Il che significa che non ci sono handshake e non c’è garanzia di ordine o consegna. Questo significa che tutti i possibili passaggi per garantire la consegna, l’integrità dei dati e quant’altro è lasciato al layer dell’applicazione. Ciò significa che un’applicazione che si aggiunge a UDP può scegliere le strategie che impiegherà a seconda del caso concreto, oppure può eventualmente sfruttare elementi del livello di accesso alla rete, come i checksum, per evitare sovraccarichi.

Dato che l’UDP è diffuso proprio come il TCP, consente di ottenere miglioramenti senza richiedere un ampio cambio del firmware su tutti i dispositivi connessi a Internet o cambiamenti significativi nei sistemi operativi.

La distribuzione di nuovi protocolli è ostacolata da molti firewall, NAT, router e altre scatole nel mezzo che consentono solo la distribuzione di TCP o UDP tra gli utenti e i server che devono raggiungere. – HTTP/3 explained

Questo thread su Hacker News può aiutarci a capire il ragionamento alla base della costruzione della nuova versione di HTTP in cima allo stack di rete esistente, piuttosto che reinventarlo da zero (anche se c’è dell’altro oltre a questo).

Le specifiche del formato dei pacchetti UDP sono piuttosto ridotte, l’intestazione è composta dalla porta di origine, dalla porta di destinazione, dalla lunghezza in byte, dall’intestazione e dai dati del pacchetto e dal checksum. Il checksum può essere utilizzato per verificare l’integrità dei dati sia per l’intestazione che per i dati del pacchetto.

Il checksum è facoltativo quando il layer del protocollo sottostante è IPv4 e obbligatorio con IPv6. Finora, UDP è stato utilizzato per cose come la sincronizzazione dell’orologio dei sistemi informatici (NTP), applicazioni VoIP, streaming video, sistema DNS e protocollo DHCP.

QUIC e HTTP/3

QUIC (Quick UDP Internet Connections) è stato implementato per la prima volta da Google nel 2012. Ridefinisce i confini dei livelli di rete, basandosi sul protocollo UDP di livello inferiore, ridefinendo gli handshake, le caratteristiche di affidabilità e le funzionalità di sicurezza nello “spazio utente”, evitando la necessità di aggiornare i kernel dei sistemi su tutta la internet.

Proprio come è successo con HTTP/2, che è stato un avanzamento guidato da SPDY o speedy di Google, HTTP/3 si baserà nuovamente su questi risultati.

Anche se HTTP/2 ci ha fornito il multiplexing e attenuato l’head-of-line-blocking, è limitato dal TCP. È possibile utilizzare una singola connessione TCP per più flussi multiplex insieme per trasferire dati, ma quando uno di quei flussi subisce una perdita di pacchetti, l’intera connessione (e tutti i suoi flussi) sono tenuti in ostaggio, per così dire, fino a quando TCP fa le sue cose (ritrasmette il pacchetto perso).

Ciò significa che tutti i pacchetti, anche se sono già stati trasmessi e in attesa nel buffer del nodo di destinazione, vengono bloccati fino a quando il pacchetto perso viene ritrasmesso. Daniel Stenberg, nel suo libro su http/3 lo chiama “head of line block basato su TCP”. Afferma che, con una perdita di pacchetti del 2%, gli utenti faranno meglio con HTTP/1, con sei connessioni per proteggersi da questo rischio.

QUIC non subisce questo vincolo. Con QUIC in costruzione sul protocollo UDP senza connessione, il concetto di connessione non porta i limiti del TCP e gli errori di un flusso non devono necessariamente avere effetti su tutto il resto.

Come ha detto Lucas Pardue di Cloudflare:

Concentrandosi sugli stream UDP, QUIC raggiunge il multiplexing senza dover ricorrere a una connessione TCP. QUIC crea la sua connessione a un livello superiore rispetto a TCP. Nuovi flussi all’interno delle connessioni QUIC non sono costretti ad aspettare che gli altri terminino. Le connessioni QUIC beneficiano anche del superamento del sovraccarico dell’handshake TCP, il che riduce la latenza.

Quelli di Cisco hanno realizzato un video interessante che spiega l’handshake a 3 vie di TCP.

Sebbene QUIC si allontani dalle caratteristiche di affidabilità TCP, le ripropone al di sopra del livello UDP, provvedendo alla ritrasmissione di pacchetti, all’ordinamento e così via. Google Cloud Platform ha introdotto il supporto di QUIC nel 2018 per i bilanciatori di carico ed ha registrato un miglioramento del tempo medio di caricamento delle pagine dell’8% a livello globale e del 13% nelle regioni in cui la latenza è più elevata.

Tra Google Chrome, YouTube, Gmail, Google Search e altri servizi, Google è stato in grado di implementare QUIC su una bella porzione di Internet, senza attendere l’IETF. Gli ingegneri di Google sostengono che nel 2017 il 7% del traffico Internet era già stato trasmesso tramite QUIC.

La versione di Google di QUIC era centrata solo sul trasporto HTTP, con sintassi HTTP/2. Il gruppo dell’IETF (responsabili della standardizzazione di QUIC) hanno deciso che la versione IETF di QUIC dovrebbe essere in grado di trasportare più del semplice HTTP. Per il momento, tuttavia, qualsiasi lavoro su protocolli non HTTP su QUIC è sospeso.

Un’altra cosa che il gruppo di lavoro dell’IETF ha deciso è che la versione standardizzata utilizzerà la crittografia TLS 1.3 anziché la soluzione personalizzata di Google. TLS 1.3, rispetto alle versioni precedenti, contribuisce anche alla velocità del protocollo, in quanto i suoi handshake richiedono meno roundtrip. Kinsta supports TLS 1.3 on all of our servers and our Kinsta CDN.

Al momento, Google continua a utilizzare la sua versione di QUIC nel suo prodotto, dirigendo al contempo gli sforzi di sviluppo verso gli standard IETF. La maggior parte degli altri attori di Internet sta sviluppando al top della versione IETF (tra i due ci sono altre differenze oltre alla crittografia).

Se apriamo Chrome Dev Tools e cariciamo alcuni prodotti Google, come Gmail, nella colonna Protocollo della scheda Network, vedremo molte risorse caricate tramite la versione di Google del protocollo QUIC. Questo vale anche per altri prodotti Google come Analytics, Google Tag Manager, ecc.

Cloudflare ha pubblicato un aggiornamento molto esteso sui progressi della standardizzazione.

Sebbene UDP fornisca QUIC e HTTP/3 alcuni vantaggi intrinseci, porta con sé anche alcune sfide.

TCP è stato il protocollo mainstream per anni, mentre UDP non lo è, quindi i sistemi operativi e lo stack software che lo riguardano, in generale, non sono ottimizzati. Di conseguenza, con QUIC c’è un carico e requisiti di CPU molto più elevati; secondo alcune stime, il doppio rispetto a HTTP/2.

Le ottimizzazioni scendono in profindità fino al kernel dei sistemi operativi e dei diversi firmware di router e periferiche. Questa guida all’ottimizzazione di Red Hat potrebbe far luce sull’argomento per coloro che sono più inclini agli aspetti tecnologici.

Potremmo dire che QUIC tenta di riprogettare le funzionalità TCP su un protocollo più minimale e flessibile.

Le connessioni QUIC, che abbiamo citato in precedenza, combinano TLS e handshake di trasporto. Una volta stabiliti, vengono identificati da CID univoci (ID di connessione). Questi ID persistono attraverso le modifiche degli IP e possono contribuire a garantire download ininterrotti su, ad esempio, un passaggio da 4G a WiFi. Ciò è rilevante, in particolare perché sempre più traffico internet viene condotto sui dispositivi mobili. Ci si potrebbe chiedere se questo elemento sia concepito da Google per facilitare un migliore tracciamento degli utenti attraverso diverse connessioni e provider internet.

Il TLS è obbligatorio ed è pensato per rendere difficile la manomissione dei dispositivi nel mezzo o per fiutare il traffico. Ecco perché non è raro vedere provider di firewall e vendors come Cisco considerare il protocollo UDP come un problema e spiegare come disabilitarlo. È più difficile per gli operatori intermedi ispezionare e supervisionare o filtrare il traffico QUIC.

I flussi QUIC vengono inviati tramite connessioni QUIC, unidirezionali o bidirezionali. Gli stream hanno ID che identificano l’iniziatore, stabiliscono se lo stream è unidirezionale o bidirezionale e servono anche il controllo del flusso in-stream.

Mentre QUIC è un protocollo a livello di trasporto, HTTP è al livello subito sopra, un protocollo a livello di applicazione, o un protocollo di applicazione.

Dato che la compatibilità con le versioni precedenti è della massima importanza, l’implementazione di HTTP/3 promossa da IETF includerà la versione precedente (HTT1 o HTTP/2) nella risposta. Comprenderà un’intestazione che informa il client che HTTP/3 è disponibile, insieme alle informazioni su porta/host, come descritto nella RFC 7838.

È diverso da HTTP/2, in cui il trasporto può essere negoziato all’interno dell’handshake TLS. Ma poiché IETF ha quasi adottato HTTP/3 su QUIC come prossimo standard, possiamo aspettarci che i client web anticipino sempre di più il supporto di HTTP/3. È possibile che i client memorizzino dati da connessioni HTTP/3 precedenti e connettano direttamente (zero-round-trip o 0-RTT) nelle visite successive allo stesso host.

Riepilogo

C’è chi pensa che, non essendo ancora stato adottato lo standard HTTP/2, potrebbe essere troppo presto per spingere per HTTP/3. È un’obiezione valida, ma, come abbiamo detto, questo protocollo ha già avuto test e implementazioni su larga scala. Google ha iniziato a testarlo già nel 2015, così come Facebook nel 2017.

In 2024, we have HTTP/3 support from major browsers like Google Chrome and Brave. On the infrastructure front, web servers like Litespeed and Nginx both have working implementations of HTTP/3, while network providers like Cloudflare have already deployed full support for HTTP/3.

At this time, HTTP/3 is still in the Internet Draft phase, and the most recent revision is set to expire in August 2021. This year will be exciting, as we can expect to see the move by major software vendors to implement the new standard.

Tonino Jankov

Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.

• Twitter