HTTP/3: opzioni pratiche di implementazione (parte 3)

Ciao e benvenuto alla puntata finale di questa serie in tre parti sui nuovi protocolli HTTP/3 e QUIC! Se dopo le due parti precedenti — cronologia e concetti fondamentali di HTTP/3 e funzionalità di prestazioni di HTTP/3 — sei convinto che iniziare a utilizzare i nuovi protocolli sia una buona idea (e dovresti esserlo!), allora questo pezzo finale include tutto devi sapere per iniziare!

Per prima cosa, discuteremo quali modifiche devi apportare alle tue pagine e risorse per utilizzare in modo ottimale i nuovi protocolli (questa è la parte facile). Successivamente, esamineremo come configurare server e client (questa è la parte difficile a meno che tu non stia utilizzando una rete di distribuzione dei contenuti (CDN)). Infine, vedremo quali strumenti è possibile utilizzare per valutare l'impatto sulle prestazioni dei nuovi protocolli (questa è la parte quasi impossibile, almeno per ora).

Modifiche a pagine e risorse

Cominciamo con una buona notizia: se sei già su HTTP/2, probabilmente non dovrai modificare nulla alle tue pagine o risorse quando passi a HTTP/3! . Questo perché, come abbiamo spiegato nella parte 1 e nella parte 2, HTTP/3 è molto più simile a HTTP/2-over-QUIC e le funzionalità di alto livello delle due versioni sono rimaste le stesse. Pertanto, qualsiasi modifica o ottimizzazione apportata per HTTP/2 funzionerà comunque per HTTP/3 e viceversa.

Tuttavia, se sei ancora su HTTP/1.1, o ti sei dimenticato della tua transizione a HTTP/2, o non hai mai effettivamente ottimizzato le cose per HTTP/2, allora potresti chiederti quali fossero queste modifiche e perché erano necessarie. Tuttavia, anche oggi sarebbe difficile trovare un buon articolo che descriva in dettaglio le migliori pratiche sfumate . Questo perché, come ho affermato nell'introduzione alla parte 1, gran parte dei primi contenuti HTTP/2 erano eccessivamente ottimisti su quanto bene avrebbe funzionato in pratica e alcuni di essi, francamente, presentavano gravi errori e cattivi consigli. Purtroppo, gran parte di questa disinformazione persiste oggi. Questa è una delle mie principali motivazioni nello scrivere questa serie su HTTP/3, per evitare che accada di nuovo.

La migliore fonte completa di sfumature per HTTP/2 che posso consigliare in questo momento è il libro HTTP/2 in Action di Barry Pollard. Tuttavia, poiché si tratta di una risorsa a pagamento e non voglio che tu rimanga qui a indovinare, ho elencato alcuni dei punti principali di seguito, insieme a come si riferiscono a HTTP/3:

1. Collegamento singolo

La più grande differenza tra HTTP/1.1 e HTTP/2 era il passaggio da 6 a 30 connessioni TCP parallele a una singola connessione TCP sottostante. Abbiamo discusso un po' nella parte 2 di come una singola connessione può essere ancora veloce quanto più connessioni, a causa di come il controllo della congestione può causare una perdita di pacchetti maggiore o anticipata con più connessioni (il che annulla i vantaggi del loro avvio più veloce aggregato). HTTP/3 continua questo approccio, ma "solo" passa da una connessione TCP a una QUIC. Questa differenza di per sé non fa molto (riduce principalmente l'overhead sul lato server), ma porta alla maggior parte dei punti seguenti.

2. Sharding del server e coalescenza delle connessioni

Il passaggio alla configurazione della connessione singola è stato piuttosto difficile in pratica perché molte pagine sono state suddivise in diversi hostname e persino server (come img1.example.com e img2.example.com ). Questo perché i browser aprivano solo fino a sei connessioni per ogni singolo nome host, quindi avere più connessioni consentiva più connessioni! Senza modifiche a questa configurazione HTTP/1.1, HTTP/2 aprirebbe comunque più connessioni, riducendo il modo in cui altre funzionalità, come la definizione delle priorità (vedi sotto), potrebbero effettivamente funzionare.

Pertanto, la raccomandazione originale era di annullare il partizionamento orizzontale del server e di consolidare il più possibile le risorse su un singolo server. HTTP/2 ha anche fornito una funzionalità per rendere più semplice la transizione da una configurazione HTTP/1.1, chiamata coalescenza della connessione. In parole povere, se due nomi host si risolvono sullo stesso IP del server (usando DNS) e utilizzano un certificato TLS simile, il browser può riutilizzare una singola connessione anche tra i due nomi host .

In pratica, la coalescenza delle connessioni può essere difficile da ottenere, ad esempio a causa di diversi sottili problemi di sicurezza che coinvolgono CORS. Anche se lo configuri correttamente, potresti comunque facilmente ritrovarti con due connessioni separate. Il fatto è che non è sempre un male . Innanzitutto, a causa della definizione delle priorità e del multiplexing implementati male (vedi sotto), la singola connessione potrebbe essere facilmente più lenta rispetto all'utilizzo di due o più. In secondo luogo, l'utilizzo di troppe connessioni potrebbe causare la perdita anticipata di pacchetti a causa di controller di congestione concorrenti. Usarne solo alcuni (ma comunque più di uno), tuttavia, potrebbe bilanciare bene la crescita della congestione con prestazioni migliori, specialmente sulle reti ad alta velocità. Per questi motivi, credo che un po ' di sharding sia ancora una buona idea (diciamo, da due a quattro connessioni), anche con HTTP/2. In effetti, penso che la maggior parte delle moderne configurazioni HTTP/2 funzioni bene come fanno perché hanno ancora alcune connessioni extra o carichi di terze parti nel loro percorso critico.

3. Raggruppamento e integrazione delle risorse

In HTTP/1.1, potresti avere solo una singola risorsa attiva per connessione, portando al blocco dell'head-of-line (HoL) a livello HTTP. Poiché il numero di connessioni era limitato a un misero 6-30, il raggruppamento di risorse (in cui le sottorisorse più piccole vengono combinate in un'unica risorsa più grande) è stata una best practice di lunga data. Lo vediamo ancora oggi in bundler come Webpack. Allo stesso modo, le risorse erano spesso integrate in altre risorse (ad esempio, i CSS critici erano incorporati nell'HTML).

Con HTTP/2, invece, la singola connessione effettua il multiplexing delle risorse, quindi puoi avere molte più richieste di file in sospeso (in altre parole, una singola richiesta non occupa più una delle tue preziose poche connessioni). Questo è stato originariamente interpretato come " Non abbiamo più bisogno di raggruppare o integrare le nostre risorse per HTTP/2 ". Questo approccio è stato propagandato per essere migliore per la memorizzazione nella cache a grana fine perché ogni sottorisorsa può essere memorizzata nella cache individualmente e non è necessario scaricare nuovamente l'intero bundle se una di esse viene modificata. Questo è vero, ma solo in misura relativamente limitata.

Ad esempio, potresti ridurre l'efficienza della compressione, perché funziona meglio con più dati. Inoltre, ogni richiesta o file aggiuntivo ha un sovraccarico intrinseco perché deve essere gestito dal browser e dal server. Questi costi possono sommarsi, ad esempio, per centinaia di file di piccole dimensioni rispetto a pochi file di grandi dimensioni. Nei nostri primi test, ho riscontrato rendimenti notevolmente decrescenti a circa 40 file. Sebbene questi numeri siano probabilmente un po' più alti ora, le richieste di file non sono ancora così economiche in HTTP/2 come originariamente previsto . Infine, la mancata integrazione delle risorse ha un costo di latenza aggiuntivo perché il file deve essere richiesto. Questo, combinato con la definizione delle priorità e i problemi di push del server (vedi sotto), significa che anche oggi è ancora meglio incorporare alcuni dei tuoi CSS critici. Forse un giorno la proposta dei pacchetti di risorse aiuterà in questo, ma non ancora.

Tutto ciò, ovviamente, vale anche per HTTP/3. Tuttavia, ho letto che le persone affermano che molti file di piccole dimensioni sarebbero migliori rispetto a QUIC perché flussi indipendenti più attivi contemporaneamente significano maggiori profitti dalla rimozione del blocco HoL (come discusso nella parte 2). Penso che potrebbe esserci del vero in questo, ma, come abbiamo visto anche nella parte 2, questo è un problema molto complesso con molti parametri in movimento. Non credo che i vantaggi supererebbero gli altri costi discussi, ma sono necessarie ulteriori ricerche. (Un pensiero scandaloso sarebbe quello di avere ogni file esattamente dimensionato per adattarsi a un singolo pacchetto QUIC, bypassando completamente il blocco HoL. Accetterò i diritti d'autore da qualsiasi startup che implementa un bundler di risorse che fa questo. ;))

4. Priorità

Per poter scaricare più file su una singola connessione, devi in ​​qualche modo multiplexarli. Come discusso nella parte 2, in HTTP/2, questo multiplexing viene gestito utilizzando il suo sistema di prioritizzazione. Questo è il motivo per cui è importante avere quante più risorse possibili richieste anche sulla stessa connessione, per poterle assegnare correttamente la priorità l'una all'altra! Come abbiamo anche visto, però, questo sistema era molto complesso , tanto da essere spesso mal utilizzato e implementato nella pratica (vedi immagine sotto). Questo, a sua volta, ha significato che alcuni altri consigli per HTTP/2, come la riduzione del raggruppamento, perché le richieste sono economiche, e il ridotto sharding del server, per utilizzare in modo ottimale la singola connessione (vedi sopra), si sono rivelati sottoperformanti in la pratica.

Purtroppo, questo è qualcosa su cui tu, come sviluppatore web medio, non puoi fare molto, perché è principalmente un problema nei browser e nei server stessi. Puoi, tuttavia, provare a mitigare il problema non utilizzando troppi singoli file (il che ridurrà le possibilità di priorità concorrenti) e continuando a utilizzare lo sharding (limitato). Un'altra opzione consiste nell'usare varie tecniche che influenzano la priorità, come il caricamento lento, JavaScript async e defer e suggerimenti per le risorse come preload . Internamente, questi cambiano principalmente le priorità delle risorse in modo che vengano inviate prima o dopo. Tuttavia, questi meccanismi possono (e lo fanno) soffrire di bug. Inoltre, non aspettarti di caricare un preload su un mucchio di risorse e rendere le cose più veloci: se tutto è improvvisamente una priorità alta, allora niente lo è! È anche molto facile ritardare le risorse effettivamente critiche utilizzando cose come preload .

Come spiegato anche nella parte 2, HTTP/3 cambia radicalmente gli interni di questo sistema di prioritizzazione. Ci auguriamo che ciò significhi che ci saranno molti meno bug e problemi con la sua distribuzione pratica, quindi almeno alcuni di questi dovrebbero essere risolti. Non possiamo ancora esserne sicuri, tuttavia, perché pochi server e client HTTP/3 implementano completamente questo sistema oggi. Tuttavia, i concetti fondamentali della definizione delle priorità non cambieranno . Non sarai ancora in grado di utilizzare tecniche come il preload senza capire davvero cosa accade internamente, perché potrebbe comunque assegnare una priorità errata alle tue risorse.

5. Push del server e primo volo

Il push del server consente a un server di inviare dati di risposta senza prima attendere una richiesta dal client. Ancora una volta, questo suona alla grande in teoria e potrebbe essere usato invece di incorporare risorse (vedi sopra). Tuttavia, come discusso nella parte 2, il push è molto difficile da usare correttamente a causa di problemi con il controllo della congestione, la memorizzazione nella cache, la definizione delle priorità e il buffering. Nel complesso, è meglio non usarlo per il caricamento generale delle pagine Web a meno che tu non sappia davvero cosa stai facendo, e anche in questo caso sarebbe probabilmente una micro-ottimizzazione. Credo ancora che potrebbe avere un posto con le API (REST), tuttavia, dove puoi inviare sottorisorse collegate nella risposta (JSON) su una connessione riscaldata. Questo vale sia per HTTP/2 che per HTTP/3.

Per generalizzare un po', ritengo che si possano fare osservazioni simili per la ripresa della sessione TLS e 0-RTT, sia su TCP + TLS che tramite QUIC. Come discusso nella parte 2, 0-RTT è simile al server push (come viene generalmente utilizzato) in quanto tenta di accelerare le primissime fasi del caricamento di una pagina. Tuttavia, ciò significa che è ugualmente limitato in ciò che può ottenere in quel momento (ancora di più in QUIC, a causa di problemi di sicurezza). In quanto tale, una micro-ottimizzazione è, ancora una volta, il modo in cui probabilmente hai bisogno di mettere a punto le cose a un livello basso per trarne davvero vantaggio. E pensare che una volta ero molto entusiasta di provare a combinare il push del server con 0-RTT.

Che cosa significa tutto questo?

Tutto quanto sopra si riduce a una semplice regola pratica: applica la maggior parte dei tipici consigli HTTP/2 che trovi online, ma non portarli all'estremo .

Ecco alcuni punti concreti che valgono principalmente sia per HTTP/2 che per HTTP/3:

1. Shard risorse su circa una o tre connessioni sul percorso critico (a meno che gli utenti non si trovino principalmente su reti a larghezza di banda ridotta), utilizzando preconnect e dns-prefetch dove necessario.
2. Raggruppare le sottorisorse logicamente per percorso o funzionalità o per frequenza di modifica. Da cinque a dieci risorse JavaScript e da cinque a dieci CSS per pagina dovrebbero andare bene. L'integrazione di CSS critici può comunque essere una buona ottimizzazione.
3. Usa funzionalità complesse, come il preload , con parsimonia.
4. Utilizzare un server che supporti correttamente la definizione delle priorità HTTP/2. Per HTTP/2, consiglio H2O. Apache e NGINX sono per lo più OK (anche se potrebbero fare di meglio), mentre Node.js è da evitare per HTTP/2. Per HTTP/3, le cose sono meno chiare in questo momento (vedi sotto).
5. Assicurati che TLS 1.3 sia abilitato sul tuo server web HTTP/2.

Come puoi vedere, sebbene tutt'altro che semplice, l'ottimizzazione delle pagine per HTTP/3 (e HTTP/2) non è una scienza missilistica. Ciò che sarà più difficile, tuttavia, sarà configurare correttamente server, client e strumenti HTTP/3.

Server e reti

Come probabilmente avrai capito ormai, QUIC e HTTP/3 sono protocolli piuttosto complessi. La loro implementazione da zero comporterebbe la lettura (e la comprensione!) di centinaia di pagine distribuite su più di sette documenti. Fortunatamente, più aziende stanno lavorando su implementazioni QUIC e HTTP/3 open source da oltre cinque anni, quindi abbiamo diverse opzioni mature e stabili tra cui scegliere.

Alcuni dei più importanti e stabili includono quanto segue:

Tuttavia, molte (forse la maggior parte) di queste implementazioni si occupano principalmente di HTTP/3 e QUIC; non sono server web a tutti gli effetti da soli . Quando si tratta dei tuoi server tipici (pensa a NGINX, Apache, Node.js), le cose sono state un po' più lente, per diversi motivi. In primo luogo, pochi dei loro sviluppatori sono stati coinvolti con HTTP/3 dall'inizio e ora devono recuperare il ritardo. Molti lo aggirano utilizzando una delle implementazioni sopra elencate internamente come librerie, ma anche quell'integrazione è difficile.

In secondo luogo, molti server dipendono da librerie TLS di terze parti come OpenSSL. Questo, ancora una volta, perché TLS è molto complesso e deve essere sicuro, quindi è meglio riutilizzare il lavoro esistente e verificato. Tuttavia, sebbene QUIC si integri con TLS 1.3, lo utilizza in modi molto diversi da come interagiscono TLS e TCP . Ciò significa che le librerie TLS devono fornire API specifiche per QUIC, cosa che i loro sviluppatori sono stati a lungo riluttanti o lenti a fare. Il problema qui in particolare è OpenSSL, che ha posticipato il supporto QUIC, ma è utilizzato anche da molti server. Questo problema è diventato così grave che Akamai ha deciso di avviare un fork di OpenSSL specifico per QUIC, chiamato quictls. Sebbene esistano altre opzioni e soluzioni alternative, il supporto TLS 1.3 per QUIC è ancora un blocco per molti server e dovrebbe rimanere tale per qualche tempo.

Di seguito è riportato un elenco parziale di server Web completi che dovresti essere in grado di utilizzare immediatamente, insieme al loro attuale supporto HTTP/3:

• Apache
  Il supporto non è chiaro in questo momento. Nulla è stato annunciato. Probabilmente ha anche bisogno di OpenSSL. (Si noti che esiste un'implementazione di Apache Traffic Server, però.)
• NGINX
  Questa è un'implementazione personalizzata. Questo è relativamente nuovo e ancora altamente sperimentale. Si prevede che sarà unito alla linea principale NGINX entro la fine del 2021. Questo è relativamente nuovo e ancora altamente sperimentale. Nota che esiste anche una patch per eseguire la libreria quiche di Cloudflare su NGINX, che per ora è probabilmente più stabile.
• Node.js
  Questo utilizza la libreria ngtcp2 internamente. È bloccato dai progressi di OpenSSL, anche se hanno in programma di passare al fork QUIC-TLS per far funzionare qualcosa prima.
• IIS
  Il supporto non è chiaro al momento e non è stato annunciato nulla. Tuttavia, probabilmente utilizzerà la libreria MsQuic internamente.
• Ipermais
  Questo integra aioquic, con il supporto sperimentale.
• Caddy
  Questo utilizza quic-go, con pieno supporto.
• H2O
  Questo utilizza rapidamente, con il pieno supporto.
• Litespeed
  Questo utilizza LSQUIC, con pieno supporto.

Nota alcune sfumature importanti:

• Anche "pieno supporto" significa "buono come arriva al momento", non necessariamente "pronto per la produzione". Ad esempio, molte implementazioni non supportano ancora completamente la migrazione della connessione, 0-RTT, server push o la definizione delle priorità HTTP/3 .
• Altri server non elencati, come Tomcat, (a mia conoscenza) non hanno ancora fatto annunci.
• Dei server Web elencati, solo Litespeed, la patch NGINX di Cloudflare e H2O sono stati realizzati da persone intimamente coinvolte nella standardizzazione QUIC e HTTP/3, quindi è molto probabile che funzionino meglio all'inizio.
  

Come puoi vedere, il panorama del server non è ancora completamente disponibile, ma ci sono sicuramente già opzioni per configurare un server HTTP/3. Tuttavia, eseguire semplicemente il server è solo il primo passo. Configurarlo e il resto della tua rete è più difficile.

Configurazione di rete

Come spiegato nella parte 1, QUIC si basa sul protocollo UDP per semplificarne l'implementazione. Ciò, tuttavia, significa principalmente che la maggior parte dei dispositivi di rete può analizzare e comprendere UDP. Purtroppo, ciò non significa che l'UDP sia universalmente consentito . Poiché l'UDP viene spesso utilizzato per gli attacchi e non è fondamentale per il normale lavoro quotidiano oltre al DNS, molte reti (aziendali) e firewall bloccano quasi completamente il protocollo. In quanto tale, probabilmente UDP deve essere esplicitamente autorizzato da/verso i tuoi server HTTP/3 . QUIC può essere eseguito su qualsiasi porta UDP ma si aspetta che la porta 443 (che in genere viene utilizzata anche per HTTPS su TCP) sia la più comune.

Tuttavia, molti amministratori di rete non vorranno solo consentire la vendita all'ingrosso di UDP. Invece, vorranno specificamente consentire QUIC su UDP. Il problema è che, come abbiamo visto, QUIC è quasi interamente crittografato. Ciò include metadati di livello QUIC come i numeri di pacchetto, ma anche, ad esempio, segnali che indicano la chiusura di una connessione. Per TCP, i firewall tengono traccia attivamente di tutti questi metadati per verificare il comportamento previsto. (Abbiamo visto una stretta di mano completa prima dei pacchetti che trasportano dati? I pacchetti seguono gli schemi previsti? Quante connessioni aperte ci sono?) Come abbiamo visto nella parte 1, questo è esattamente uno dei motivi per cui TCP non è più praticamente evolvibile. Tuttavia, grazie alla crittografia di QUIC, i firewall possono eseguire molto meno di questa logica di tracciamento a livello di connessione e i pochi bit che possono ispezionare sono relativamente complessi.

Pertanto, molti fornitori di firewall attualmente consigliano di bloccare QUIC fino a quando non possono aggiornare il proprio software. Anche in seguito, tuttavia, molte aziende potrebbero non volerlo consentire, perché il supporto QUIC del firewall sarà sempre molto inferiore alle funzionalità TCP a cui sono abituate.

Tutto ciò è ulteriormente complicato dalla funzione di migrazione della connessione. Come abbiamo visto, questa funzionalità consente di continuare la connessione da un nuovo indirizzo IP senza dover eseguire un nuovo handshake, utilizzando gli ID di connessione (CID). Tuttavia, per il firewall, sembrerà che venga utilizzata una nuova connessione senza prima utilizzare un handshake, che potrebbe benissimo essere un utente malintenzionato che invia traffico dannoso. I firewall non possono solo utilizzare i CID QUIC, perché cambiano anche nel tempo per proteggere la privacy degli utenti! Pertanto, sarà necessario che i server comunichino con il firewall su cui sono previsti i CID , ma nessuna di queste cose esiste ancora.

Esistono problemi simili per i sistemi di bilanciamento del carico per le configurazioni su larga scala. Queste macchine distribuiscono le connessioni in entrata su un gran numero di server back-end. Il traffico per una connessione deve, ovviamente, essere sempre instradato allo stesso server back-end (gli altri non saprebbero cosa farne!). Per TCP, questo potrebbe essere fatto semplicemente in base alla tupla a 4, perché non cambia mai. Con la migrazione della connessione QUIC, tuttavia, questa non è più un'opzione. Anche in questo caso, i server e i sistemi di bilanciamento del carico dovranno in qualche modo concordare quali CID scegliere per consentire l'instradamento deterministico . A differenza della configurazione del firewall, tuttavia, esiste già una proposta per configurarlo (sebbene sia tutt'altro che ampiamente implementato).

Infine, ci sono altre considerazioni sulla sicurezza di livello superiore, principalmente sugli attacchi 0-RTT e DDoS (Distributed Denial-of-Service). Come discusso nella parte 2, QUIC include già alcune mitigazioni per questi problemi, ma idealmente utilizzerà anche linee di difesa aggiuntive sulla rete. Ad esempio, i server proxy o perimetrali potrebbero impedire a determinate richieste 0-RTT di raggiungere i back-end effettivi per prevenire attacchi di riproduzione. In alternativa, per prevenire attacchi di riflessione o attacchi DDoS che inviano solo il primo pacchetto di handshake e quindi smettono di rispondere (chiamato SYN flood in TCP), QUIC include la funzione di ripetizione. Ciò consente al server di convalidare che si tratta di un client ben educato, senza dover mantenere alcuno stato nel frattempo (l'equivalente dei cookie TCP SYN). Questo processo di ripetizione si verifica meglio, ovviamente, da qualche parte prima del server back-end, ad esempio nel sistema di bilanciamento del carico. Anche in questo caso, tuttavia, ciò richiede una configurazione e una comunicazione aggiuntive da configurare.

Questi sono solo i problemi più importanti che gli amministratori di rete e di sistema avranno con QUIC e HTTP/3. Ce ne sono molti altri, alcuni dei quali ho parlato. Ci sono anche due documenti di accompagnamento separati per le RFC QUIC che discutono di questi problemi e delle loro possibili (parziali) mitigazioni.

Che cosa significa tutto questo?

HTTP/3 e QUIC sono protocolli complessi che si basano su molti macchinari interni. Non tutto questo è ancora pronto per la prima serata , anche se hai già alcune opzioni per implementare i nuovi protocolli sul tuo back-end. Tuttavia, probabilmente ci vorranno da alcuni mesi a addirittura anni prima che i server e le librerie sottostanti più importanti (come OpenSSL) vengano aggiornati.

Anche in questo caso, configurare correttamente i server e gli altri intermediari di rete, in modo che i protocolli possano essere utilizzati in modo sicuro e ottimale, non sarà banale in configurazioni su larga scala. Avrai bisogno di un buon team di sviluppo e operativo per effettuare correttamente questa transizione.

Pertanto, soprattutto all'inizio, è probabilmente meglio affidarsi a una grande società di hosting o CDN per impostare e configurare i protocolli per te. Come discusso nella parte 2, è qui che è più probabile che QUIC ripaghi comunque e l'utilizzo di un CDN è una delle ottimizzazioni chiave delle prestazioni che puoi fare. Personalmente consiglierei di utilizzare Cloudflare o Fastly perché sono stati intimamente coinvolti nel processo di standardizzazione e disporranno delle implementazioni più avanzate e ben sintonizzate disponibili.

Clienti e QUIC Discovery

Finora abbiamo considerato il supporto lato server e in rete per i nuovi protocolli. Tuttavia, diversi problemi devono essere superati anche dal lato del cliente.

Prima di arrivare a questo, iniziamo con alcune buone notizie: la maggior parte dei browser più diffusi ha già il supporto (sperimentale) HTTP/3! Nello specifico, nel momento in cui scriviamo, ecco lo stato del supporto (vedi anche caniuse.com):

• Google Chrome (versione 91+) : abilitato per impostazione predefinita.
• Mozilla Firefox (versione 89+) : abilitato per impostazione predefinita.
• Microsoft Edge (versione 90+) : abilitato per impostazione predefinita (usa Chromium internamente).
• Opera (versione 77+) : abilitato per impostazione predefinita (utilizza Chromium internamente).
• Apple Safari (versione 14) : dietro una bandiera manuale. Sarà abilitato per impostazione predefinita nella versione 15, che è attualmente in anteprima tecnologica.
• Altri browser : ancora nessun segnale di cui sono a conoscenza (sebbene altri browser che utilizzano Chromium internamente, come Brave, potrebbero, in teoria, iniziare ad abilitarlo).

Nota alcune sfumature:

• La maggior parte dei browser viene implementata gradualmente, per cui non tutti gli utenti riceveranno il supporto HTTP/3 abilitato per impostazione predefinita dall'inizio. Questo viene fatto per limitare i rischi che un singolo bug trascurato possa interessare molti utenti o che le distribuzioni del server vengano sovraccaricate. Pertanto, c'è una piccola possibilità che, anche nelle versioni recenti del browser, non otterrai HTTP/3 per impostazione predefinita e dovrai abilitarlo manualmente.
• Come per i server, il supporto HTTP/3 non significa che tutte le funzionalità siano state implementate o siano utilizzate in questo momento. In particolare, 0-RTT, migrazione della connessione, push del server, compressione dell'intestazione QPACK dinamica e priorità HTTP/3 potrebbero essere ancora mancanti, disabilitati, utilizzati con moderazione o configurati in modo errato.
• Se desideri utilizzare HTTP/3 lato client al di fuori del browser (ad esempio, nella tua app nativa), dovresti integrare una delle librerie elencate sopra o utilizzare cURL. Apple porterà presto il supporto nativo HTTP/3 e QUIC nelle sue librerie di rete integrate su macOS e iOS, e Microsoft sta aggiungendo QUIC al kernel di Windows e al loro ambiente .NET, ma un supporto nativo simile (a mia conoscenza) non è stato annunciato per altri sistemi come Android.

Alt-Svc

Anche se hai configurato un server compatibile con HTTP/3 e stai utilizzando un browser aggiornato, potresti essere sorpreso di scoprire che HTTP/3 non viene effettivamente utilizzato in modo coerente . Per capire perché, supponiamo che tu sia il browser per un momento. Il tuo utente ha richiesto di accedere a example.com (un sito Web che non hai mai visitato prima) e hai utilizzato il DNS per risolverlo in un IP. Invii uno o più pacchetti di handshake QUIC a quell'IP. Ora diverse cose possono andare storte:

1. Il server potrebbe non supportare QUIC.
2. Una delle reti o firewall intermedi potrebbe bloccare completamente QUIC e/o UDP.
3. I pacchetti di handshake potrebbero andare persi durante il trasporto.

Tuttavia, come faresti a sapere (quale) si è verificato uno di questi problemi ? In tutti e tre i casi, non riceverai mai una risposta ai tuoi pacchetti di handshake. L'unica cosa che puoi fare è aspettare, sperando che una risposta possa ancora arrivare. Quindi, dopo un po' di tempo di attesa (il timeout), potresti decidere che c'è davvero un problema con HTTP/3. A quel punto, proveresti ad aprire una connessione TCP al server, sperando che HTTP/2 o HTTP/1.1 funzionino.

Come puoi vedere, questo tipo di approccio potrebbe introdurre grossi ritardi, specialmente negli anni iniziali, quando molti server e reti non supporteranno ancora QUIC. Una soluzione semplice ma ingenua sarebbe semplicemente quella di aprire una connessione QUIC e TCP contemporaneamente e quindi utilizzare l'handshake completato per primo . Questo metodo è chiamato "corsa di connessione" o "occhi felici". Anche se questo è certamente possibile, ha un sovraccarico considerevole. Anche se la connessione persa viene chiusa quasi immediatamente, occupa comunque memoria e tempo CPU sia sul client che sul server (soprattutto quando si utilizza TLS). Inoltre, ci sono anche altri problemi con questo metodo che coinvolgono le reti IPv4 rispetto a IPv6 e gli attacchi di riproduzione discussi in precedenza (che il mio discorso copre in modo più dettagliato).

Pertanto, per QUIC e HTTP/3, i browser preferiscono giocare in modo sicuro e provare QUIC solo se sanno che il server lo supporta . Pertanto, la prima volta che viene contattato un nuovo server, il browser utilizzerà solo HTTP/2 o HTTP/1.1 su una connessione TCP. Il server può quindi far sapere al browser che supporta anche HTTP/3 per le connessioni successive. Questo viene fatto impostando un'intestazione HTTP speciale sulle risposte inviate tramite HTTP/2 o HTTP/1.1. Questa intestazione si chiama Alt-Svc , che sta per "servizi alternativi". Alt-Svc può essere utilizzato per far sapere a un browser che un determinato servizio è raggiungibile anche tramite un altro server (IP e/o porta), ma consente anche di indicare protocolli alternativi. Questo può essere visto di seguito nella figura 1.

Dopo aver ricevuto un'intestazione Alt-Svc valida che indica il supporto HTTP/3, il browser la memorizzerà nella cache e proverà a configurare una connessione QUIC da quel momento in poi. Alcuni client lo faranno il prima possibile (anche durante il caricamento iniziale della pagina - vedi sotto), mentre altri attenderanno fino alla chiusura delle connessioni TCP esistenti. Ciò significa che il browser utilizzerà HTTP/3 solo dopo aver scaricato prima almeno alcune risorse tramite HTTP/2 o HTTP/1.1 . Anche allora, non è una navigazione tranquilla. Il browser ora sa che il server supporta HTTP/3, ma ciò non significa che la rete intermedia non lo bloccherà. In quanto tale, nella pratica è ancora necessaria la corsa alla connessione. Quindi, potresti comunque finire con HTTP/2 se la rete in qualche modo ritarda abbastanza l'handshake QUIC. Inoltre, se la connessione QUIC non riesce a stabilirsi alcune volte di seguito, alcuni browser inseriranno la voce della cache Alt-Svc in una lista di negazione per un po' di tempo, senza provare HTTP/3 per un po'. Pertanto, può essere utile svuotare manualmente la cache del browser se le cose non funzionano perché ciò dovrebbe anche svuotare i collegamenti Alt-Svc . Infine, Alt-Svc ha dimostrato di porre alcuni seri rischi per la sicurezza. Per questo motivo, alcuni browser pongono restrizioni aggiuntive, ad esempio, su quali porte possono essere utilizzate (in Chrome, i tuoi server HTTP/2 e HTTP/3 devono essere entrambi su una porta inferiore a 1024 o entrambi su una porta superiore o uguale a 1024, altrimenti Alt-Svc verrà ignorato). Tutta questa logica varia e si evolve enormemente tra i browser, il che significa che può essere difficile ottenere connessioni HTTP/3 coerenti , il che rende anche difficile testare nuove configurazioni.

È in corso un lavoro per migliorare in qualche modo questo processo Alt-Svc in due fasi. L'idea è di utilizzare nuovi record DNS chiamati SVCB e HTTPS, che conterranno informazioni simili a quelle di Alt-Svc . In quanto tale, il client può scoprire che un server supporta HTTP/3 durante la fase di risoluzione DNS, il che significa che può provare QUIC dal primo caricamento della pagina invece di dover prima passare tramite HTTP/2 o HTTP/1.1. Per ulteriori informazioni su questo e su Alt-Svc , vedere il capitolo Web Almanac dell'anno scorso su HTTP/2.

Come puoi vedere, Alt-Svc e il processo di rilevamento HTTP/3 aggiungono un livello di complessità alla tua già impegnativa distribuzione del server QUIC, perché:

• dovrai sempre distribuire il tuo server HTTP/3 accanto a un server HTTP/2 e/o HTTP/1.1;
• dovrai configurare i tuoi server HTTP/2 e HTTP/1.1 per impostare le intestazioni Alt-Svc corrette sulle loro risposte.

Anche se dovrebbe essere gestibile nelle configurazioni a livello di produzione (perché, ad esempio, una singola istanza di Apache o NGINX probabilmente supporterà tutte e tre le versioni HTTP contemporaneamente), potrebbe essere molto più fastidioso in una serie di test (locali). ups (posso già vedermi dimenticare di aggiungere le intestazioni Alt-Svc o rovinarle). Questo problema è aggravato da una (attuale) mancanza di registri degli errori del browser e indicatori DevTools, il che significa che capire perché esattamente l'installazione non funziona può essere difficile.

Problemi aggiuntivi

Come se ciò non bastasse, un altro problema renderà più difficili i test locali: Chrome rende molto difficile l'utilizzo di certificati TLS autofirmati per QUIC . Questo perché i certificati TLS non ufficiali vengono spesso utilizzati dalle aziende per decrittografare il traffico TLS dei propri dipendenti (in modo che possano, ad esempio, eseguire la scansione dei firewall all'interno del traffico crittografato). Tuttavia, se le aziende iniziassero a farlo con QUIC, avremmo di nuovo implementazioni middlebox personalizzate che fanno le proprie ipotesi sul protocollo. Ciò potrebbe portare loro a interrompere potenzialmente il supporto del protocollo in futuro, che è esattamente ciò che abbiamo cercato di prevenire crittografando QUIC in modo così esteso in primo luogo! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

Che cosa significa tutto questo?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Faro di Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog e qvis

Come mostra la discussione sopra, può essere complicato analizzare il comportamento di HTTP/3 semplicemente usando Lighthouse o WebPageTest a questo punto. Fortunatamente, sono disponibili altri strumenti di livello inferiore per aiutare con questo. Innanzitutto, l'eccellente strumento Wireshark ha un supporto avanzato per QUIC e può anche sezionare sperimentalmente HTTP/3. Ciò consente di osservare quali pacchetti QUIC e HTTP/3 stanno effettivamente passando attraverso il cavo. Tuttavia, affinché funzioni, è necessario ottenere le chiavi di decrittazione TLS per una determinata connessione, che la maggior parte delle implementazioni (inclusi Chrome e Firefox) consentono di estrarre utilizzando la variabile di ambiente SSLKEYLOGFILE . Anche se questo può essere utile per alcune cose, capire davvero cosa sta succedendo, specialmente per connessioni più lunghe, potrebbe richiedere molto lavoro manuale. Avresti anche bisogno di una comprensione piuttosto avanzata del funzionamento interno dei protocolli.

Fortunatamente, c'è una seconda opzione, qlog e qvis. qlog è un formato di registrazione basato su JSON specifico per QUIC e HTTP/3 supportato dalla maggior parte delle implementazioni QUIC. Invece di guardare i pacchetti che passano attraverso il cavo, qlog acquisisce queste informazioni direttamente sul client e sul server, il che gli consente di includere alcune informazioni aggiuntive (ad esempio, dettagli sul controllo della congestione). In genere, è possibile attivare l'output di qlog all'avvio di server e client con la variabile di ambiente QLOGDIR . (Nota che in Firefox, devi impostare la preferenza network.http.http3.enable_qlog . I dispositivi Apple e Safari usano invece QUIC_LOG_DIRECTORY . Chrome non supporta ancora qlog.)

Questi file qlog possono quindi essere caricati nella suite di strumenti qvis su qvis.quictools.info. Lì otterrai una serie di visualizzazioni interattive avanzate che semplificano l'interpretazione del traffico QUIC e HTTP/3 . qvis ha anche il supporto per il caricamento di acquisizioni di pacchetti Wireshark (file .pcap ) e ha un supporto sperimentale per i file netlog di Chrome, quindi puoi anche analizzare il comportamento di Chrome. Un tutorial completo su qlog e qvis va oltre lo scopo di questo articolo, ma è possibile trovare maggiori dettagli in forma di tutorial, come documento e persino in formato talk-show. Puoi anche chiedermeli direttamente perché sono il principale implementatore di qlog e qvis. ;)

Tuttavia, non mi illudo che la maggior parte dei lettori qui dovrebbe mai usare Wireshark o qvis, perché questi sono strumenti di livello piuttosto basso. Tuttavia, poiché al momento abbiamo poche alternative, consiglio vivamente di non testare in modo approfondito le prestazioni HTTP/3 senza utilizzare questo tipo di strumento , per assicurarti di sapere davvero cosa sta succedendo sul cavo e se ciò che stai vedendo è davvero spiegato da interni del protocollo e non da altri fattori.

Che cosa significa tutto questo?

Come abbiamo visto, la configurazione e l'utilizzo di HTTP/3 su QUIC può essere una faccenda complessa e molte cose possono andare storte. Purtroppo, non è disponibile alcun buon strumento o visualizzazione che esponga i dettagli necessari a un livello di astrazione appropriato. Ciò rende molto difficile per la maggior parte degli sviluppatori valutare i potenziali vantaggi che HTTP/3 può apportare al proprio sito Web in questo momento o addirittura convalidare che la configurazione funzioni come previsto.

Affidarsi solo a metriche di alto livello è molto pericoloso perché queste potrebbero essere distorte da una miriade di fattori (come l'emulazione di rete non realistica, la mancanza di funzionalità su client o server, solo un utilizzo parziale di HTTP/3, ecc.). Anche se tutto ha funzionato meglio, come abbiamo visto nella parte 2, le differenze tra HTTP/2 e HTTP/3 saranno probabilmente relativamente piccole nella maggior parte dei casi, il che rende ancora più difficile ottenere le informazioni necessarie da strumenti senza supporto HTTP/3 mirato.

Pertanto, consiglio di lasciare da sole le misurazioni delle prestazioni HTTP/2 rispetto a HTTP/3 per qualche altro mese e di concentrarmi invece sull'assicurarci che le nostre configurazioni lato server funzionino come previsto . Per questo, è più semplice utilizzare WebPageTest in combinazione con i parametri della riga di comando di Google Chrome, con un fallback per arricciare potenziali problemi: questa è attualmente la configurazione più coerente che riesco a trovare.

Conclusione e Takeaway

Caro lettore, se hai letto la serie completa in tre parti e sei arrivato qui, ti saluto ! Anche se hai letto solo alcune sezioni, ti ringrazio per il tuo interesse per questi nuovi ed entusiasmanti protocolli. Ora riassumerò i punti chiave di questa serie, fornirò alcuni consigli chiave per i prossimi mesi e anni e infine ti fornirò alcune risorse aggiuntive, nel caso desideri saperne di più.

Sommario

Innanzitutto, nella parte 1, abbiamo discusso del fatto che HTTP/3 era necessario principalmente a causa del nuovo protocollo di trasporto QUIC sottostante . QUIC è il successore spirituale di TCP e integra tutte le sue migliori pratiche, oltre a TLS 1.3. Ciò era necessario principalmente perché TCP, a causa della sua onnipresente implementazione e integrazione nei middlebox, è diventato troppo rigido per evolversi. L'utilizzo da parte di QUIC di UDP e della crittografia quasi completa significa che (si spera) dovremo solo aggiornare gli endpoint in futuro per aggiungere nuove funzionalità, il che dovrebbe essere più semplice. QUIC, tuttavia, aggiunge anche alcune nuove interessanti funzionalità. Innanzitutto, il trasporto combinato e l'handshake crittografico di QUIC sono più veloci di TCP + TLS e possono sfruttare al meglio la funzione 0-RTT. In secondo luogo, QUIC sa che sta trasportando più flussi di byte indipendenti e può essere più intelligente su come gestisce le perdite e i ritardi, mitigando il problema del blocco dell'head-of-line. In terzo luogo, le connessioni QUIC possono sopravvivere agli utenti che si spostano su una rete diversa (chiamata migrazione della connessione) contrassegnando ogni pacchetto con un ID di connessione. Infine, la struttura flessibile dei pacchetti di QUIC (impiegando frame) lo rende più efficiente ma anche più flessibile ed estensibile in futuro. In conclusione, è chiaro che QUIC è il protocollo di trasporto di nuova generazione e sarà utilizzato ed esteso per molti anni a venire .

In secondo luogo, nella parte 2, abbiamo dato un'occhiata critica a queste nuove funzionalità, in particolare alle loro implicazioni sulle prestazioni . Innanzitutto, abbiamo visto che l'uso di UDP da parte di QUIC non lo rende magicamente più veloce (né più lento) perché QUIC utilizza meccanismi di controllo della congestione molto simili a TCP per prevenire il sovraccarico della rete. In secondo luogo, l'handshake più veloce e lo 0-RTT sono più micro-ottimizzazioni, perché in realtà sono solo un viaggio di andata e ritorno più veloci di uno stack TCP + TLS ottimizzato e il vero 0-RTT di QUIC è ulteriormente influenzato da una serie di problemi di sicurezza che possono limitare la sua utilità. In terzo luogo, la migrazione della connessione è davvero necessaria solo in alcuni casi specifici e significa comunque reimpostare le velocità di invio perché il controllo della congestione non sa quanti dati può gestire la nuova rete. In quarto luogo, l'efficacia della rimozione del blocco dell'head-of-line da parte di QUIC dipende fortemente dal modo in cui i dati del flusso vengono multiplexati e assegnati alla priorità. Gli approcci ottimali per recuperare dalla perdita di pacchetti sembrano dannosi per i casi d'uso generali delle prestazioni di caricamento delle pagine Web e viceversa, sebbene siano necessarie ulteriori ricerche. In quinto luogo, QUIC potrebbe facilmente essere più lento nell'invio di pacchetti rispetto a TCP + TLS, perché le API UDP sono meno mature e QUIC crittografa ogni pacchetto individualmente, sebbene ciò possa essere ampiamente mitigato nel tempo. Sesto, HTTP/3 di per sé non introduce in realtà nessuna nuova importante funzionalità per le prestazioni, ma principalmente rielabora e semplifica l'interno delle funzionalità HTTP/2 note. Infine, alcune delle più interessanti funzionalità relative alle prestazioni consentite da QUIC (multipath, dati inaffidabili, WebTransport, correzione degli errori in avanti, ecc.) non fanno parte degli standard QUIC e HTTP/3 di base, ma piuttosto sono estensioni proposte che prenderanno ancora un po' di tempo per essere disponibile. In conclusione, questo significa che QUIC probabilmente non migliorerà molto le prestazioni per gli utenti su reti ad alta velocità, ma sarà importante principalmente per quelli su reti lente e meno stabili .

Infine, in questa parte 3, abbiamo esaminato come utilizzare e distribuire praticamente QUIC e HTTP/3 . Innanzitutto, abbiamo visto che la maggior parte delle migliori pratiche e delle lezioni apprese da HTTP/2 dovrebbero essere trasferite su HTTP/3. Non è necessario modificare la strategia di raggruppamento o inlining, né di consolidare o frammentare la server farm. Il push del server non è ancora la migliore funzionalità da utilizzare e il preload può essere similmente una potente arma da fuoco. In secondo luogo, abbiamo discusso del fatto che potrebbe volerci un po' prima che i pacchetti di server Web standard forniscano il supporto completo HTTP/3 (in parte a causa di problemi di supporto della libreria TLS), sebbene siano disponibili molte opzioni open source per i primi utenti e molti dei principali CDN hanno un'offerta matura. In terzo luogo, è chiaro che la maggior parte dei principali browser ha il supporto HTTP/3 (di base), anche abilitato per impostazione predefinita. Tuttavia, esistono grandi differenze su come e quando utilizzano praticamente HTTP/3 e le sue nuove funzionalità, quindi comprenderne il comportamento può essere difficile. In quarto luogo, abbiamo discusso del fatto che ciò è aggravato dalla mancanza di supporto HTTP/3 esplicito in strumenti popolari come Lighthouse e WebPageTest, rendendo particolarmente difficile confrontare le prestazioni di HTTP/3 con HTTP/2 e HTTP/1.1 in questo momento. In conclusione, HTTP/3 e QUIC probabilmente non sono ancora pronti per la prima serata, ma presto lo saranno .

Raccomandazioni

Dal riassunto sopra, potrebbe sembrare che sto adducendo forti argomentazioni contro l'uso di QUIC o HTTP/3. Tuttavia, questo è del tutto opposto al punto che voglio sottolineare.

In primo luogo, come discusso alla fine della parte 2, anche se il tuo utente "medio" potrebbe non riscontrare grandi guadagni in termini di prestazioni (a seconda del mercato di destinazione), una parte significativa del tuo pubblico vedrà probabilmente miglioramenti impressionanti . 0-RTT potrebbe salvare solo un singolo viaggio di andata e ritorno, ma ciò può comunque significare diverse centinaia di millisecondi per alcuni utenti. La migrazione della connessione potrebbe non supportare download costantemente veloci, ma aiuterà sicuramente le persone che cercano di recuperare quel PDF su un treno ad alta velocità. La perdita di pacchetti sul cavo potrebbe essere eccessiva, ma i collegamenti wireless potrebbero trarre maggiori benefici dalla rimozione del blocco dell'head-of-line di QUIC. Inoltre, questi utenti sono quelli che in genere incontrerebbero le peggiori prestazioni del tuo prodotto e, di conseguenza, ne sarebbero maggiormente colpiti. Se ti chiedi perché è importante, leggi il famoso aneddoto di performance web di Chris Zacharias.

In secondo luogo, QUIC e HTTP/3 miglioreranno e saranno solo più veloci nel tempo . La versione 1 si è concentrata sull'esecuzione del protocollo di base, mantenendo funzionalità di prestazioni più avanzate per dopo. Pertanto, ritengo che valga la pena iniziare a investire nei protocolli ora, per assicurarti di poterli utilizzare e le nuove funzionalità con un effetto ottimale quando saranno disponibili in futuro. Data la complessità dei protocolli e dei loro aspetti di implementazione, sarebbe bene concedersi un po' di tempo per familiarizzare con le loro stranezze. Anche se non vuoi ancora sporcarti le mani, molti dei principali fornitori di CDN offrono un supporto HTTP/3 "flip the switch" maturo (in particolare, Cloudflare e Fastly). Faccio fatica a trovare un motivo per non provarlo se stai usando un CDN (che, se ti interessano le prestazioni, dovresti davvero esserlo).

Pertanto, anche se non direi che è fondamentale iniziare a utilizzare QUIC e HTTP/3 il prima possibile, ritengo che ci siano già molti vantaggi da ottenere e che aumenteranno solo in futuro .

Ulteriori letture

Sebbene questo sia stato un lungo corpo di testo, purtroppo, in realtà graffia solo la superficie tecnica dei complessi protocolli che sono QUIC e HTTP/3.

Di seguito troverai un elenco di risorse aggiuntive per l'apprendimento continuo, più o meno in ordine crescente di profondità tecnica:

• "HTTP/3 spiegato", Daniel Stenberg
  Questo e-book, del creatore di cURL, riassume il protocollo.
• "HTTP/2 in azione", Barry Pollard
  Questo eccellente libro completo su HTTP/2 contiene consigli riutilizzabili e una sezione su HTTP/3.
• @programmingart, Twitter
  I miei tweet sono per lo più dedicati a QUIC, HTTP/3 e alle prestazioni web (incluse le notizie) in generale. Vedi ad esempio i miei recenti thread sulle funzionalità QUIC.
• "YouTube", Robin Marx
  I miei oltre 10 colloqui approfonditi coprono vari aspetti dei protocolli.
• “Il blog di Cloudlare”
  Questo è il prodotto principale di un'azienda che gestisce anche una CDN laterale.
• “Il blog veloce”
  Questo blog ha eccellenti discussioni sugli aspetti tecnici, inseriti nel contesto più ampio.
• QUIC, le effettive RFC
  Troverai collegamenti ai documenti IETF QUIC e HTTP/3 RFC e altre estensioni ufficiali.
• Blog degli ingegneri IIJ: eccellenti spiegazioni tecniche approfondite dei dettagli delle funzionalità QUIC.
• Articoli accademici HTTP/3 e QUIC, Robin Marx
  I miei documenti di ricerca riguardano il multiplexing del flusso e la definizione delle priorità, gli strumenti e le differenze di implementazione.
• QUIPS, EPIQ 2018 ed EPIQ 2020
  Questi documenti di seminari accademici contengono ricerche approfondite su sicurezza, prestazioni ed estensioni dei protocolli.

Con questo, ti lascio, caro lettore, con una comprensione, si spera, molto migliorata di questo nuovo mondo coraggioso. Sono sempre aperto ai feedback, quindi per favore fatemi sapere cosa ne pensate di questa serie!