Prestazioni ed efficienza: utilizzo di HTTP/3

HTTP/3 è all'orizzonte, sulla scia di HTTP/2, che probabilmente è ancora molto giovane. Dato che ci sono voluti 16 anni per passare da HTTP/1.1 a HTTP/2, qualcuno dovrebbe davvero preoccuparsi di HTTP/3?

La risposta breve: Sì, è importante e dovresti essere al passo con esso. È proprio come HTTP/2 ha apportato modifiche significative da HTTP/1.1 passando da ASCII a binario. HTTP/3 apporta nuovamente modifiche significative, questa volta cambiando il trasporto sottostante da TCP a UDP.

Sebbene HTTP/3 sia ancora in fase di progettazione con le specifiche ufficiali in bozza, è già in fase di distribuzione e ci sono buone probabilità che ne troverai una versione in esecuzione sulla tua rete oggi.

Ma ci sono alcuni nuovi dilemmi posti da come funziona HTTP/3. Inoltre, qual è il vantaggio? E cosa devono sapere gli ingegneri di rete, gli amministratori di sistema e gli sviluppatori?

Il problema principale: prestazioni ed efficienza

Gli sviluppatori di siti e app generalmente creano con l'intento che le loro creazioni vengano effettivamente utilizzate. A volte la base del pubblico è limitata, ma spesso l'idea è solo quella di ottenere il maggior numero possibile di utenti. Naturalmente, più un sito web diventa popolare, maggiori sono le entrate che può realizzare.

Un ritardo di 100 millisecondi nel tempo di caricamento del sito Web può danneggiare i tassi di conversione del 7%.

Report sulla performance del retail online di Akamai: i millisecondi sono critici (2017)

In altre parole, un sito di eCommerce con vendite di $ 40.000 al giorno perderebbe un milione di dollari all'anno a causa di un tale ritardo.

Inoltre, non è un segreto che le prestazioni di un sito siano assolutamente fondamentali affinché un sito diventi più popolare. La ricerca sugli acquisti online continua a trovare collegamenti tra l'aumento delle frequenze di rimbalzo e tempi di caricamento più lunghi e tra la fedeltà degli acquirenti e le prestazioni del sito Web durante l'esperienza di acquisto.

La ricerca ha anche scoperto che:

• Il 47% dei consumatori si aspetta che una pagina Web venga caricata in 2 secondi o meno.
• Il 40% delle persone abbandona un sito Web che impiega più di 3 secondi per caricarsi.

E questo era lo stato della pazienza degli acquirenti online di oltre un decennio fa . Quindi le prestazioni sono fondamentali e HTTP/2 e HTTP/3 significano entrambi prestazioni del sito Web migliori.

HTTP/2? …Cos'è quello?

Una buona comprensione del protocollo HTTP/2 è fondamentale per comprendere HTTP/3. Prima di tutto, perché c'era bisogno di HTTP/2?

HTTP/2 è nato come un progetto Google chiamato SPDY, risultato di uno studio che riportava che il più grande problema di prestazioni sul web era la latenza . L'autore ha concluso che "più larghezza di banda non ha importanza (molto)":

Se facciamo un'analogia tra l'impianto idraulico e Internet, possiamo considerare la larghezza di banda di Internet come il diametro del tubo dell'acqua. Un tubo più grande trasporta un volume d'acqua maggiore e quindi puoi fornire più acqua tra due punti.

Allo stesso tempo, non importa quanto sia grande la tua pipa, se la pipa è vuota e vuoi portare l'acqua da un punto all'altro, ci vuole tempo prima che l'acqua viaggi attraverso la pipa. Nel gergo di Internet, il tempo impiegato dall'acqua per viaggiare da un'estremità all'altra del tubo e viceversa è chiamato tempo di andata e ritorno o RTT .

Mike Belshe

Nello studio, l'obiettivo era ridurre il tempo di caricamento della pagina. Ha dimostrato che l'aumento della larghezza di banda aiuta inizialmente, poiché passare da 1 Mbps a 2 Mbps dimezza il tempo di caricamento della pagina. Tuttavia, i vantaggi si stabilizzano molto rapidamente.

Al contrario, la riduzione della latenza ha un vantaggio costante e consente di ottenere i migliori risultati.

HTTP HOL: il problema del blocco dell'intestazione

La principale causa di latenza all'interno del protocollo HTTP/1 è il problema del blocco dell'intestazione. Le pagine Web (quasi sempre) richiedono più risorse: CSS, JavaScript, font, immagini, AJAX/XMR, ecc. Ciò significa che il browser Web deve effettuare più richieste al server. Tuttavia, non tutte le risorse sono necessarie affinché la pagina diventi utile.

Con HTTP/1.0 era necessario che il browser completasse completamente una richiesta, inclusa la ricezione completa della risposta, prima di avviare la richiesta successiva. Tutto doveva essere fatto in sequenza. Ogni richiesta bloccherebbe la linea di richieste, da cui il nome.

Nel tentativo di compensare il problema del blocco HOL, i browser Web effettuano più connessioni simultanee a un singolo server. Ma hanno dovuto limitare arbitrariamente questo comportamento: server, workstation e reti possono sovraccaricarsi con troppe connessioni.

HTTP/1.1 ha introdotto diversi miglioramenti per aiutare ad affrontare il problema. Il principale è il pipelining , che consente ai browser Web di avviare nuove richieste senza dover attendere il completamento delle richieste precedenti. Ciò ha notevolmente migliorato i tempi di caricamento in ambienti a bassa latenza.

Ma è comunque necessario che tutte le risposte arrivino in sequenza nell'ordine in cui sono state fatte, quindi l'inizio della linea è ancora bloccato. Sorprendentemente, molti server continuano a non sfruttare questa funzionalità.

È interessante notare che HTTP/1.1 ha anche introdotto keep-alive , che ha consentito ai browser di evitare il sovraccarico della creazione di una nuova connessione TCP per ogni richiesta HTTP. Questo è stato un primo tentativo di risolvere un problema di prestazioni derivato da TCP. Era così inefficace che la maggior parte degli esperti di prestazioni in realtà lo scoraggia perché impantana il server con troppe connessioni inattive. Daremo un'occhiata più da vicino a TCP di seguito, oltre a come questo problema è stato risolto da HTTP/2.

Soluzione di blocco HOL HTTP di HTTP/2

HTTP/2 ha introdotto il multiplexing richiesta-risposta su una singola connessione. Non solo un browser può avviare una nuova richiesta in qualsiasi momento, ma le risposte possono essere ricevute in qualsiasi ordine : il blocco viene completamente eliminato a livello di applicazione.

Di conseguenza, ciò significa che i server Web esperti di HTTP/2 possono massimizzare l'efficienza, ne parleremo più avanti.

Sebbene il multiplexing richiesta-risposta sia la caratteristica principale di HTTP/2, include molte altre caratteristiche significative. I lettori potrebbero notare che sono tutti in qualche modo correlati.

Framing binario HTTP/2

HTTP/2 cambia lo standard del protocollo HTTP da un modello di richiesta-risposta ASCII leggibile dall'uomo inefficiente a un framing binario efficiente. Non è più solo una richiesta e una risposta:

Con HTTP/2, i browser comunicano con i server su flussi bidirezionali con più messaggi, ciascuno costituito da più frame.

HTTP/2 HPACK (compressione intestazione)

La nuova compressione dell'intestazione di HTTP/2, utilizzando il formato HPACK, consente di risparmiare un sacco di larghezza di banda per la maggior parte dei siti. Questo perché la maggior parte delle intestazioni sono le stesse per le richieste inviate all'interno di una connessione.

Cloudflare segnala notevoli risparmi di larghezza di banda grazie al solo HPACK:

• Compressione del 76% per le intestazioni di ingresso
• Riduzione del 53% del traffico totale in ingresso
• Compressione del 69% per le intestazioni di uscita
• Riduzione dall'1,4% al 15% del traffico in uscita totale

Naturalmente, l'utilizzo di una larghezza di banda inferiore generalmente significa un sito Web più veloce.

Priorità del flusso HTTP/2 e push del server

Ecco dove il multiplexing di HTTP/2 consente davvero al server di massimizzare l'efficienza. Il multiplexing aiuta a fornire risorse più veloci (ad esempio, JavaScript memorizzato nella cache) prima di quelle più lente (ad esempio, immagini di grandi dimensioni, JSON generato da database, ecc.). Ma consente anche un ulteriore aumento delle prestazioni tramite la prioritizzazione del flusso di HTTP/2.

La definizione delle priorità del flusso aiuta a garantire che gli aspetti quasi pronti di una pagina vengano completati completamente senza dover attendere il completamento di altre richieste ad alta intensità di risorse. Ciò si ottiene attraverso un albero delle dipendenze ponderato. Questo albero viene utilizzato per informare il server quali risposte dovrebbe allocare la maggior parte delle risorse di sistema al servizio.

Ciò è particolarmente importante per le applicazioni Web progressive (PWA). Ad esempio, supponiamo che una pagina abbia quattro file JavaScript. Due sono per la funzionalità della pagina e due sono per gli annunci. Lo scenario peggiore è caricare metà del JS funzionale e metà del JS pubblicitario e quindi continuare a caricare immagini di grandi dimensioni, prima di caricare uno qualsiasi dei restanti JS. In tal caso, nulla nella pagina funziona inizialmente, perché tutto deve attendere la risorsa più lenta.

Con la prioritizzazione del flusso, i browser Web possono indicare al server di inviare entrambi i file JS delle funzionalità della pagina prima di inviare qualsiasi file JavaScript pubblicitario. In questo modo gli utenti non devono attendere il caricamento completo degli annunci prima di utilizzare la funzionalità della pagina. Sebbene il tempo di caricamento complessivo non sia migliorato, le prestazioni percepite sono state notevolmente aumentate. Sfortunatamente, questo comportamento all'interno del browser web è ancora principalmente una questione di algoritmi, piuttosto che essere qualcosa specificato dagli sviluppatori web.

Sulla stessa linea, la funzione di push del server di HTTP/2 consente al server di inviare risposte al browser per richieste che non ha ancora fatto! Il server può sfruttare le lacune nella trasmissione, utilizzando in modo efficiente la larghezza di banda precaricando nel browser le risorse che il server sa che richiederà presto. Parte della speranza qui è eliminare la pratica dell'integrazione delle risorse, che semplicemente gonfia le risorse e richiede più tempo per il caricamento.

Sfortunatamente, entrambe queste funzionalità richiedono un'attenta configurazione da parte degli sviluppatori web per avere davvero successo. Abilitarli semplicemente non è abbastanza.

HTTP/2 offre chiaramente molti potenziali vantaggi, alcuni dei quali meno costosi da sfruttare rispetto ad altri. Come stanno andando nel mondo reale?

Adozione HTTP vs HTTP/2

SPDY è stato creato nel 2009. HTTP/2 è stato standardizzato nel 2015. SPDY è diventato il nome di un ramo di sviluppo instabile del codice, con HTTP/2 che è diventata la versione finale. Il risultato è che SPDY è diventato obsoleto e HTTP/2 è comunemente lo standard seguito da tutti.

Dopo la standardizzazione, l'adozione di HTTP/2 (o "h2") è cresciuta rapidamente fino a raggiungere circa il 40% dei primi 1.000 siti Web. Ciò è stato principalmente determinato da grandi provider di hosting e cloud che hanno implementato il supporto per conto dei loro clienti. Sfortunatamente, diversi anni dopo, l'adozione di HTTP/2 è rallentata e la maggior parte di Internet è ancora su HTTP/1.

Mancanza di supporto del browser per la modalità testo chiaro HTTP/2

Ci sono state molte richieste per HTTP/2 per rendere la crittografia una parte richiesta dello standard. Invece, lo standard ha definito sia la modalità crittografata (h2) che quella con testo in chiaro (h2c). In quanto tale, HTTP/2 potrebbe sostituire interamente HTTP/1.

Nonostante lo standard, tutti i browser Web attuali supportano solo HTTP/2 su connessioni crittografate e intenzionalmente non implementano la modalità testo in chiaro. Invece, i browser si basano sulla modalità di compatibilità con le versioni precedenti HTTP/1 per accedere a server non sicuri. Questo è il risultato diretto di una spinta ideologica verso la sicurezza del web di default.

Perché HTTP/3? E come è diverso?

Con il problema di blocco dell'head-of-line HTTP ora risolto da HTTP/2, gli sviluppatori di protocolli hanno rivolto la loro attenzione al successivo più grande driver di latenza: il problema del blocco dell'head-of-line TCP .

Protocollo di controllo della trasmissione (TCP)

Le reti IP (protocollo Internet) si basano sull'idea che i computer si scambiano pacchetti. Un pacchetto è solo dati con alcune informazioni di indirizzamento allegate in alto.

Ma le applicazioni di solito devono gestire flussi di dati. Per realizzare questa illusione, il protocollo di controllo della trasmissione (TCP) presenta alle applicazioni un tubo attraverso il quale può fluire un flusso di dati. Come con la maggior parte delle pipe, vi è la garanzia che i dati usciranno dalla pipe nello stesso ordine in cui entrano, noto anche come "first in, first out" (FIFO). Queste caratteristiche hanno reso il TCP molto utile e ampiamente adottato.

Come parte delle garanzie di consegna dei dati fornite da TCP, deve essere in grado di gestire un'ampia varietà di situazioni. Uno dei problemi più complessi è come fornire tutti i dati quando una rete è sovraccarica, senza peggiorare la situazione per tutti. L'algoritmo per questo è chiamato controllo della congestione ed è una parte in continua evoluzione delle specifiche di Internet. Senza un sufficiente controllo della congestione, Internet si ferma.

Nell'ottobre dell'86, Internet ebbe il primo di quella che divenne una serie di "crolli di congestione". Durante questo periodo, il throughput di dati da LBL a UC Berkeley (siti separati da 400 iarde e tre salti IMP) è sceso da 32 Kbps a 40 bps.

V. Jacobson (1988)

È qui che entra in gioco il problema del blocco dell'intestazione TCP.

Problema di blocco TCP HOL

Il controllo della congestione TCP funziona implementando meccanismi di backoff e ritrasmissione per i pacchetti, utilizzati ogni volta che viene rilevata una perdita di pacchetti. Backoff ha lo scopo di aiutare a calmare la rete. La ritrasmissione garantisce che i dati vengano eventualmente consegnati.

Ciò significa che i dati TCP possono arrivare alla destinazione fuori servizio ed è responsabilità della parte ricevente riordinare i pacchetti prima di rimontarli nel flusso. Sfortunatamente, ciò significa che un singolo pacchetto perso può causare la sospensione dell'intero flusso TCP mentre il server attende la sua ritrasmissione. Quindi, la testa della linea è bloccata.

Un altro progetto di Google mirava a risolvere questo problema introducendo un protocollo chiamato QUIC.

Il protocollo QUIC è basato su UDP anziché su TCP e QUIC costituisce la base per HTTP/3.

Cos'è l'UDP?

Il protocollo UDP (User Datagram Protocol) è un'alternativa al TCP. Non fornisce l'illusione di un flusso o le stesse garanzie offerte da TCP. Invece, fornisce semplicemente un modo semplice per inserire i dati in un pacchetto, indirizzarlo a un altro computer e inviarlo. È inaffidabile , disordinato e non prevede alcuna forma di controllo della congestione.

Il suo scopo è essere leggero e fornire le caratteristiche minime necessarie per consentire la comunicazione. In questo modo l'applicazione può implementare le proprie garanzie. Questo è spesso molto utile nelle applicazioni in tempo reale. Ad esempio, nelle telefonate, gli utenti generalmente preferiscono ricevere il 90% dei dati immediatamente, piuttosto che il 100% dei dati alla fine.

Soluzione TCP HOL di HTTP/3

Risolvere il problema del blocco TCP HOL ha richiesto più del semplice passaggio a UDP, poiché è ancora necessario garantire la consegna di tutti i dati ed evitare il collasso della congestione della rete. Il protocollo QUIC è progettato per fare tutto questo fornendo un'esperienza di tipo HTTP su UDP ottimizzata.

Poiché QUIC assume il controllo della gestione del flusso, del framing binario, ecc., non resta molto da fare per HTTP/2 quando viene eseguito su QUIC. Questo fa parte del fattore trainante verso la standardizzazione di questa nuova combinazione di QUIC + HTTP come HTTP/3.

Nota: esistono molte versioni di QUIC, poiché il protocollo è in fase di sviluppo e distribuito negli ambienti di produzione da anni. C'è anche una versione specifica di Google chiamata GQUIC. Pertanto, è importante fare una distinzione tra i vecchi protocolli QUIC e il nuovo standard HTTP/3.

Sempre crittografato

HTTP/3 include la crittografia che prende in prestito pesantemente da TLS ma non la utilizza direttamente. Una delle principali sfide di implementazione per HTTP/3 è che le librerie TLS/SSL devono essere modificate per aggiungere le nuove funzionalità richieste.

Questa modifica è dovuta al fatto che HTTP/3 differisce da HTTPS in termini di crittografia. Con il vecchio protocollo HTTPS, solo i dati stessi sono protetti da TLS, lasciando visibili molti dei metadati di trasporto. In HTTP/3 sia i dati che il protocollo di trasporto sono protetti. Potrebbe sembrare una funzionalità di sicurezza, e lo è. Ma è fatto in questo modo per evitare gran parte del sovraccarico presente in HTTP/2. Pertanto, la crittografia del protocollo di trasporto e dei dati rende effettivamente il protocollo più performante.

Impatto di HTTP/3 sull'infrastruttura di rete

HTTP/3 non è esente da controversie. Le preoccupazioni principali riguardano l'infrastruttura di rete.

HTTP/3 lato client

Sul lato client, è abbastanza comune che il traffico UDP sia fortemente limitato e/o bloccato. L'applicazione di queste restrizioni a HTTP/3 annulla il punto del protocollo.

In secondo luogo, è abbastanza comune che HTTP venga monitorato e/o intercettato. Anche con il traffico HTTPS, le reti controllano regolarmente gli elementi di trasporto del testo in chiaro del protocollo per determinare se devono interrompere la connessione allo scopo di impedire l'accesso a determinati siti Web da reti specifiche o all'interno di regioni specifiche. In alcuni paesi, questo è addirittura obbligatorio per legge per alcuni fornitori di servizi. La crittografia obbligatoria in HTTP/3 lo rende impossibile.

Non è solo un filtraggio a livello di governo. Molte università, biblioteche pubbliche, scuole e famiglie con genitori preoccupati scelgono attivamente di bloccare l'accesso a determinati siti Web o almeno di tenere un registro di quali siti sono stati visitati. La crittografia obbligatoria in HTTP/3 lo rende impossibile.

Vale la pena notare che attualmente è possibile un filtraggio limitato. Questo perché il campo dell'indicazione del nome del server (SNI), che contiene il nome host del sito Web ma non il percorso, i parametri della query, ecc., non è ancora crittografato. Ma questo è destinato a cambiare nel prossimo futuro con l'introduzione di ESNI (encrypted SNI), che è stato recentemente aggiunto allo standard TLS.

HTTP/3 lato server

Sul lato server, è consigliabile bloccare tutte le porte e i protocolli che non prevedono traffico, il che significa che gli amministratori del server ora devono aprire UDP 443 per HTTP/3, anziché fare affidamento sulle regole TCP 443 esistenti.

In secondo luogo, l'infrastruttura di rete può rendere persistenti le sessioni TCP , il che significa che verranno sempre instradate allo stesso server anche se le priorità di routing cambiano. Poiché HTTP/3 viene eseguito su UDP, che è senza sessione, l'infrastruttura di rete deve essere aggiornata per tenere traccia degli ID di connessione specifici di HTTP/3, che sono stati lasciati non crittografati specificamente per facilitare il routing permanente.

In terzo luogo, è abbastanza comune che HTTP venga ispezionato per rilevare abusi, monitorare problemi di sicurezza comuni, rilevare e prevenire la diffusione di malware e virus, ecc. Ciò non è possibile con HTTP/3 a causa della sua crittografia. Tuttavia, sono ancora possibili opzioni in cui il dispositivo di intercettazione ha una copia delle chiavi di sicurezza, supponendo che i dispositivi implementino il supporto HTTP/3.

Infine, molti amministratori si oppongono alla necessità di gestire ancora più certificati SSL, anche se ora questo è un problema minore con la disponibilità di servizi come Let's Encrypt.

Fino a quando non ci saranno soluzioni ampiamente accettate e ben note per affrontare queste preoccupazioni, penso che è probabile che molte grandi reti bloccheranno semplicemente HTTP/3.

Impatto di HTTP/3 sullo sviluppo Web

Non c'è molto di cui preoccuparsi su questo fronte. La prioritizzazione del flusso di HTTP/2 e le funzionalità di push del server sono ancora presenti in HTTP/3. Vale la pena che gli sviluppatori web acquisiscano familiarità con queste funzionalità se vogliono ottimizzare davvero le prestazioni del proprio sito.

Utilizzo di HTTP/3 in questo momento

Gli utenti di Google Chrome, o del browser Chromium open source, sono già impostati per l'utilizzo di HTTP/3. Le versioni di qualità di produzione dei server HTTP/3 sono ancora un po' lontane: le specifiche non sono del tutto finalizzate al momento della stesura di questo articolo. Ma nel frattempo ci sono molti strumenti con cui giocare e sia Google che Cloudflare hanno già spinto il supporto nei loro ambienti di produzione.

Il modo più semplice per provarlo è utilizzare Caddy in Docker. Per questo è necessario un certificato SSL, quindi un indirizzo IP accessibile pubblicamente semplifica le cose. I passaggi sono:

1. Configurazione DNS. Ottieni un hostname funzionante che è attivo su Internet, ad esempio yourhostname.example.com IN A 192.0.2.1 .
2. Creazione di un caddyfile. Dovrebbe contenere queste righe:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Esecuzione di Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —o esterno Docker, caddy --quic .
2. Esecuzione di chromium con QUIC abilitato: chromium --enable-quic
3. (Facoltativo) Installazione di un'estensione dell'indicatore di protocollo.
4. Passare al server abilitato per QUIC , dove dovrebbe essere visibile un browser di file.

Gli sviluppatori possono anche testare i loro server con i seguenti strumenti utili:

• Test HTTP/2 di Keycdn
• HTTP3Check di LiteSpeed
• Test del server SSL di Qualys

Grazie per aver letto!