Mozilla ha annunciato la sua intenzione di avviare l'implementazione graduale dei protocolli HTTP/3 e QUIC nella versione di Firefox 88, prevista per il 19 aprile (inizialmente, il rilascio era atteso per il 20 aprile, ma, a quanto pare, è stato posticipato di un giorno). Inizialmente, il supporto per HTTP/3 sarà attivato solo per una piccola percentuale di utenti e, se non ci saranno problemi imprevisti, verrà esteso a tutti entro la fine di maggio. Nelle versioni notturne e beta, HTTP/3 è stato 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 fornisce l'implementazione del client e server per il protocollo QUIC. Il codice dei componenti per il supporto di HTTP/3 e QUIC è scritto in Rust. Per gestire l'attivazione di HTTP/3, è disponibile in about:config l'opzione «network.http.http3.enabled». Nel software client, il supporto sperimentale per HTTP/3 è stato aggiunto anche in Chrome e curl, mentre per server è disponibile in nginx, così come sotto forma di modulo nginx e server di test dalla società Cloudflare. Sul lato dei siti, il supporto per HTTP/3 è già garantito sui server di Google e Facebook.
Il protocollo HTTP/3 è ancora in fase di bozza e non è stato ancora standardizzato dall'IETF. Per utilizzare HTTP/3 è necessaria la compatibilità, sia dal lato client che server, con la stessa versione della bozza standard di QUIC e HTTP/3, indicata nell'intestazione Alt-Svc (Firefox supporta le bozze delle specifiche dalla 27 alla 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 i problemi legati ai lunghi tempi di stabilimento e negoziazione delle connessioni in TCP e eliminando i ritardi causati dalla perdita di pacchetti durante la trasmissione dei dati. QUIC è un'estensione del protocollo UDP che supporta il multiplexing di più connessioni e fornisce metodi di crittografia equivalenti a TLS/SSL. Durante lo sviluppo dello standard in IETF, sono state apportate modifiche al protocollo, creando due rami esistenti parallelamente, uno per HTTP/3 e l'altro supportato da Google (Chrome supporta entrambe le varianti).
Caratteristiche principali di QUIC:
- Elevata sicurezza, simile a TLS (essenzialmente QUIC offre la possibilità di utilizzare TLS sopra UDP);
- Controllo dell'integrità del flusso, che previene la perdita di pacchetti;
- Possibilità di stabilire una connessione istantaneamente (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di stabilimento della connessione) e garantire minimi ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Utilizzo di un numero di sequenza diverso per la ritrasmissione di pacchetti, il che consente di evitare ambiguità nella determinazione dei pacchetti ricevuti e di eliminare i timeout;
- La perdita di pacchetti influisce solo sulla consegna del flusso a essi associato e non interrompe la consegna dei dati nei flussi trasmessi parallelamente attraverso l'attuale connessione;
- Strumenti di correzione degli errori, che minimizzano i ritardi dovuti alla ritrasmissione dei 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 perso.
- I confini dei blocchi crittografici sono allineati con i confini dei pacchetti QUIC, riducendo l'impatto delle perdite di pacchetti sulla decodifica del contenuto dei pacchetti successivi;
- Assenza di problemi di blocco della coda TCP;
- Supporto per l'identificatore di connessione, che consente di ridurre i tempi per stabilire una nuova connessione per i clienti mobili;
- Possibilità di connettere meccanismi avanzati di controllo del sovraccarico della connessione;
- Utilizzo di tecniche di previsione della larghezza di banda in entrambe le direzioni per garantire un'intensità ottimale di invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico, caratterizzato dalla perdita di pacchetti;
- Un notevole incremento delle prestazioni e della capacità di throughput rispetto a TCP. Per i servizi video, come YouTube, l'adozione di QUIC ha mostrato una riduzione delle operazioni di buffering durante la visione dei video del 30%.
Fonte: opennet.ru
