Nelle build notturne di Firefox, così come nella versione beta, è inclusa per impostazione predefinita la supporto per il protocollo HTTP/3. Nell'anteprima stabile, l'attivazione di HTTP/3 è prevista per il rilascio di Firefox 88, programmato per il 20 aprile. In Chrome, l'attivazione selettiva di HTTP/3 è iniziata nell'ottobre 2020.
Il supporto per HTTP/3 in Firefox si basa su un progetto sviluppato da Mozilla chiamato neqo, che fornisce un'implementazione cliente 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, in about:config è presente l'opzione "network.http.http3.enabled". Il supporto sperimentale per HTTP/3 è stato già aggiunto anche in Chrome e curl, e per server è disponibile in nginx, sia come modulo nginx che come server di test da parte di Cloudflare. Per testare il funzionamento dei client HTTP/3 sono stati avviati diversi siti di prova.
Il protocollo HTTP/3 è ancora in fase di specifica preliminare e non è stato standardizzato dall'IETF. HTTP/3 definisce l'uso del protocollo QUIC come trasporto per HTTP/2. Il protocollo QUIC (Quick UDP Internet Connections) è sviluppato da Google dal 2013 come alternativa a TCP+TLS per il Web, affrontando problemi di tempi lunghi di stabilizzazione e negoziazione delle connessioni in TCP e riducendo i ritardi in caso di perdita di pacchetti durante la trasmissione di 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 IETF, il protocollo ha subito modifiche, portando alla creazione di due rami esistenti parallelamente, uno per HTTP/3 e l'altro supportato da Google (Chrome supporta entrambe le versioni).
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 immediatamente una connessione (0-RTT, in circa il 75% dei casi i dati possono essere trasferiti subito dopo l'invio del pacchetto di apertura connessione) e garantire latenze minime 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 aumento delle prestazioni e della larghezza di banda rispetto a TCP. Per i servizi video, come YouTube, l'uso di QUIC ha mostrato una riduzione delle operazioni di ri-buffering durante la visione dei video del 30%.
Fonte: opennet.ru
