Le build notturne di Firefox ora supportano HTTP/3

В costruzioni notturne Firefox, che costituirà la base per il rilascio di Firefox 72, previsto per il 7 gennaio, aggiunto Supporto del protocollo HTTP/3. Per impostazione predefinita, HTTP/3 è disabilitato e richiede l'attivazione dell'opzione "network.http.http3.enabled" in about:config.

Il supporto HTTP/3 in Firefox si basa su un progetto sviluppato da Mozilla neqo, che fornisce un'implementazione client e server per il protocollo QUIC. Il codice del componente per il supporto HTTP/3 e QUIC è scritto in Rust.
Dal software client è già disponibile anche il supporto sperimentale per HTTP/3 aggiunto in Chrome e curl e per i server è disponibile nel modulo модуля per nginx e server di prova basato sulla biblioteca quiche (implementazione QUIC e HTTP/3 in Rust di Cloudflare). Per testare il funzionamento dei client HTTP/3 lanciato diversi siti di prova, la maggior parte dei quali non si aprono ancora correttamente in Firefox (HTTP/3 è in fase bozza di specifica e non è completamente standardizzato).

Ricordiamo che HTTP/3 standardizza l'uso del protocollo QUIC come trasporto per HTTP/2. Protocollo QUIC (Quick UDP Internet Connections) è stato sviluppato da Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo problemi legati ai lunghi tempi di setup e negoziazione delle connessioni in TCP ed eliminando i ritardi dovuti alla perdita di pacchetti durante il trasferimento dei dati. QUIC è un'estensione del protocollo UDP che supporta il multiplexing di connessioni multiple e fornisce metodi di crittografia equivalenti a TLS/SSL.

Il principale caratteristiche VELOCE:

• 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);
• Non utilizzare lo stesso numero di sequenza durante la ritrasmissione di un pacchetto, il 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;
• Percettibile crescita prestazioni e throughput rispetto a 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