Alle build sperimentali supporto per il protocollo HTTP/3, che implementa un componente aggiuntivo per consentire a HTTP di funzionare sul protocollo QUIC. Il protocollo QUIC stesso è stato aggiunto al browser cinque anni fa e da allora viene utilizzato per ottimizzare il lavoro con i servizi Google. Allo stesso tempo, la versione QUIC di Google utilizzata in Chrome differiva in alcuni dettagli dalla versione di IETF, ma ora le implementazioni sono sincronizzate.
HTTP/3 standardizza l'uso di QUIC come trasporto per HTTP/2. Per abilitare l'opzione HTTP/3 e QUIC da Le specifiche IETF richiedono che Chrome venga avviato con le opzioni "-enable-quic -quic-version=h3-23" e poi all'apertura del sito di test Nella modalità di ispezione della rete negli strumenti per sviluppatori, l'attività HTTP/3 verrà visualizzata come "http/2+quic/99".
Ricordiamo che il protocollo (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 protocollo in questione è già integrato nell'infrastruttura dei server di Google e fa parte di Chrome. per l'inclusione in Firefox e viene utilizzato attivamente per servire le richieste dei clienti sui server di Google.
Il principale 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 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