Nelle versioni sperimentali supporto per il protocollo HTTP/3, che implementa un'astrazione per permettere il funzionamento di HTTP sul protocollo QUIC. Il protocollo QUIC è stato integrato nel browser cinque anni fa e da allora viene utilizzato per ottimizzare l'interazione con i servizi Google. Tuttavia, la variante di QUIC utilizzata in Chrome differiva in alcuni dettagli rispetto a quella delle IETF, ma ora le implementazioni sono sincronizzate.
HTTP/3 standardizza l'uso di QUIC come trasporto per HTTP/2. Per abilitare HTTP/3 e la variante QUIC di delle specifiche IETF è necessario avviare Chrome con le opzioni «—enable-quic —quic-version=h3-23», dopodiché, aprendo il sito di test in modalità di ispezione della rete negli strumenti per sviluppatori, le attività relative a HTTP/3 saranno visualizzate come «http/2+quic/99».
Ricordiamo che il protocollo (Quick UDP Internet Connections) sviluppato da Google dal 2013 come alternativa alla combinazione TCP+TLS per il web, affronta i problemi di lungo tempo di inizializzazione e negoziazione delle connessioni in TCP, eliminando anche i ritardi causati dalla 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. Questo protocollo è già integrato nell'infrastruttura server di Google ed è parte di Chrome, per la sua attivazione in Firefox ed è ampiamente utilizzato per gestire le richieste dei clienti sui server di Google.
Principali 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);
- Non utilizzare lo stesso numero di sequenza nella ritrasmissione dei pacchetti, per evitare ambiguità nella determinazione dei pacchetti ricevuti e 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 confini crittografici dei blocchi 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 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;
- Notevole prestazioni e capacità rispetto a TCP. Per i servizi video, come YouTube, l'applicazione di QUIC ha mostrato una riduzione delle operazioni di buffering durante la visione dei video del 30%.
Fonte: opennet.ru
