Nelle versioni notturne di Firefox e nella beta è abilitato di default il supporto per il protocollo HTTP/3. L'attivazione di HTTP/3 nella versione stabile è 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 sul progetto neqo, sviluppato da Mozilla, che fornisce un'implementazione del client e server del protocollo QUIC. Il codice dei componenti per supportare HTTP/3 e QUIC è scritto in Rust. Per gestire l'attivazione di HTTP/3 in about:config è prevista l'opzione «network.http.http3.enabled». Il supporto sperimentale per HTTP/3 è già stato aggiunto anche in Chrome e curl, e per server è disponibile in nginx, oltre che in forma di modulo nginx e server di test da parte di Cloudflare. Sono stati avviati diversi siti di test per verificare il funzionamento dei client HTTP/3.
Il protocollo HTTP/3 è attualmente in fase di bozza e non è ancora standardizzato dall'IETF. HTTP/3 definisce l'uso del protocollo QUIC come trasporto per HTTP/2. Il protocollo QUIC (Quick UDP Internet Connections) è in sviluppo da parte di Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo i problemi di alto tempo di stabilimento e negoziazione delle connessioni in TCP e eliminando le attese dovute alla perdita di pacchetti durante la trasmissione dei dati. QUIC è un'estensione del protocollo UDP, supporta il multiplexing di più connessioni e fornisce metodi di crittografia equivalenti a TLS/SSL. Durante lo sviluppo dello standard da parte dell'IETF, sono state apportate modifiche al protocollo, portando alla creazione di due rami esistenti parallelamente: uno per HTTP/3 e l'altro supportato da Google (Chrome supporta entrambi i formati).
Caratteristiche principali di QUIC:
- Elevata sicurezza, simile a TLS (in sostanza, QUIC offre la possibilità di utilizzare TLS sopra UDP);
- Controllo dell'integrità del flusso, prevenendo la perdita di pacchetti;
- Possibilità di stabilire una connessione istantaneamente (0-RTT, in circa il 75% dei casi è possibile trasmettere dati subito dopo l'invio del pacchetto di inizializzazione) e garantire latenze minime tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Uso di un numero di sequenza diverso per la ritrasmissione di un pacchetto, consentendo di evitare ambiguità nella definizione dei pacchetti ricevuti e di eliminare i timeout;
- La perdita di pacchetti influisce solo sulla consegna del flusso correlato e non interrompe la consegna dei dati nei flussi trasmessi in parallelo attraverso la connessione attuale;
- Strumenti di correzione degli errori che minimizzano i ritardi causati dalla ritrasmissione dei pacchetti persi. Utilizzo di codici di correzione degli errori a livello di pacchetto per ridurre le situazioni che richiedono la ritrasmissione dei dati del pacchetto perso.
- I limiti dei blocchi crittografici sono allineati con i limiti 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 dell'identificatore della connessione, che consente di ridurre il tempo per stabilire una connessione di ripristino per i clienti mobili;
- Possibilità di collegare meccanismi avanzati di controllo della congestione della connessione;
- L'uso di tecniche di previsione della capacità in ogni direzione per garantire un'intensità ottimale nell'invio dei pacchetti, evitando di scivolare in uno stato di sovraccarico in cui si verifica la perdita di pacchetti;
- Un notevole aumento delle prestazioni e della capacità rispetto a TCP. Per i servizi video come YouTube, l'uso di QUIC ha mostrato una riduzione delle operazioni di buffering del 30% durante la visione dei video.
Fonte: opennet.ru
