Mozilla ha annunciato la sua intenzione di iniziare l'implementazione graduale di HTTP/3 e QUIC con il rilascio di Firefox 88, previsto per il 19 aprile (originariamente previsto per il 20 aprile, ma a giudicare dal programma, verrà posticipato di un giorno). Il supporto HTTP/3 sarà inizialmente abilitato solo per una piccola percentuale di utenti e, salvo eventuali problemi imprevisti, sarà distribuito a tutti entro la fine di maggio. Nelle build notturne e nelle versioni beta, HTTP/3 era abilitato per impostazione predefinita alla fine di marzo.
Ricordiamo che l'implementazione di HTTP/3 in Firefox si basa sul progetto neqo sviluppato da Mozilla, che prevede un'implementazione client e server per il protocollo QUIC. Il codice del componente per il supporto HTTP/3 e QUIC è scritto in Rust. Per controllare se HTTP/3 è abilitato, about:config fornisce l'opzione "network.http.http3.enabled". Dal software client a Chrome e curl è stato aggiunto anche il supporto sperimentale per HTTP/3, mentre per i server è disponibile in nginx, nonché sotto forma di modulo nginx e server di prova di Cloudflare. Lato sito web, il supporto HTTP/3 è già fornito sui server di Google e Facebook.
Il protocollo HTTP/3 è ancora in fase di bozza delle specifiche e non è stato ancora completamente standardizzato dall'IETF. HTTP/3 richiede il supporto client e server per la stessa versione della bozza dello standard QUIC e HTTP/3, che è specificato nell'intestazione Alt-Svc (Firefox supporta le bozze delle specifiche da 27 a 32).
HTTP/3 definisce l'uso del protocollo QUIC come trasporto per HTTP/2. Il protocollo QUIC (Quick UDP Internet Connections) è stato sviluppato da Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo problemi di lunghi tempi di setup e negoziazione per le connessioni in TCP ed eliminando ritardi quando si perdono pacchetti durante la trasmissione dati trasferimento. QUIC è un'estensione del protocollo UDP che supporta il multiplexing di connessioni multiple e fornisce metodi di crittografia equivalenti a TLS/SSL. Durante lo sviluppo dello standard IETF sono state apportate modifiche al protocollo, che hanno portato alla nascita di due rami paralleli, uno per HTTP/3 e il secondo supportato da Google (Chrome supporta entrambe le opzioni).
Caratteristiche principali di QUIC:
- Sicurezza elevata simile a TLS (sostanzialmente QUIC offre la possibilità di utilizzare TLS su UDP);
- Controllo dell'integrità del flusso, prevenendo la perdita di pacchetti;
- La capacità di stabilire istantaneamente una connessione (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di configurazione della connessione) e di garantire ritardi minimi tra l'invio di una richiesta e la ricezione di una risposta (RTT, Round Trip Time);
- Utilizzo di un numero di sequenza diverso durante la ritrasmissione di un pacchetto, che evita ambiguità nell'identificazione dei pacchetti ricevuti ed elimina i timeout;
- La perdita di un pacchetto influisce solo sulla consegna del flusso ad esso associato e non interrompe la consegna dei dati nei flussi paralleli trasmessi attraverso la connessione corrente;
- Funzionalità di correzione degli errori che riducono al minimo i ritardi dovuti alla ritrasmissione di pacchetti persi. Utilizzo di codici speciali di correzione degli errori a livello di pacchetto per ridurre le situazioni che richiedono la ritrasmissione dei dati del pacchetto persi.
- I confini dei blocchi crittografici sono allineati ai confini dei pacchetti QUIC, il che riduce l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
- Nessun problema con il blocco della coda TCP;
- Supporto per l'identificatore di connessione, che riduce il tempo necessario per stabilire una riconnessione per i client mobili;
- Possibilità di collegare meccanismi avanzati di controllo della congestione delle connessioni;
- Utilizza tecniche di previsione del throughput per direzione per garantire che i pacchetti vengano inviati a velocità ottimali, evitando che si congestionino e causino la perdita di pacchetti;
- Aumento significativo delle prestazioni e del throughput rispetto al TCP. Per i servizi video come YouTube, è stato dimostrato che QUIC riduce le operazioni di rebuffering durante la visione di video del 30%.
Fonte: opennet.ru