Nei build sperimentali supporto del protocollo HTTP/3, che implementa un'estensione per garantire il funzionamento di HTTP sopra il protocollo QUIC. Il protocollo QUIC è stato aggiunto al browser cinque anni fa ed è stato utilizzato da allora per ottimizzare le prestazioni dei servizi Google. Il variant di QUIC di Google utilizzato 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 attivare HTTP/3 e la variante QUIC di delle specifiche IETF è necessario avviare Chrome con le opzioni «—enable-quic —quic-version=h3-23», dopodiché aprendo un sito di test in modalità di ispezione rete negli strumenti per sviluppatori, l'attività su HTTP/3 verrà visualizzata come «http/2+quic/99».
Ricordiamo che il protocollo (Quick UDP Internet Connections) è in fase di sviluppo da Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo i problemi di lungo tempo di stabilimento e negoziazione delle connessioni in TCP e eliminando i ritardi causati dalla perdita di pacchetti durante la trasmissione dei dati. QUIC rappresenta un'estensione del protocollo UDP, supportando il multiplexing di più connessioni e fornendo metodi di crittografia equivalenti a TLS/SSL. Il protocollo in questione è già integrato nell'infrastruttura server di Google, fa parte di Chrome, può essere attivato in Firefox ed è attivamente utilizzato per gestire le richieste dei clienti sui server Google.
Principali 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);
- Non utilizzo, durante la ritrasmissione, dello stesso numero di sequenza del pacchetto, 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 crittografici dei blocchi sono allineati con i confini dei pacchetti QUIC, il che riduce 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;
- Notevole della performance e della capacità, rispetto a TCP. Per i servizi video, come YouTube, l'applicazione di QUIC ha mostrato una riduzione delle operazioni di ri-buffering durante la visione dei video del 30%.
Fonte: opennet.ru
