Il Comitato IETF (Internet Engineering Task Force), che si occupa dello sviluppo dei protocolli e dell'architettura di Internet, ha completato la redazione del RFC per il protocollo QUIC e ha pubblicato le specifiche correlate con gli identificativi RFC 8999 (proprietà del protocollo indipendenti dalla versione), RFC 9000 (trasporto su UDP), RFC 9001 (crittografia TLS del canale di comunicazione QUIC) e RFC 9002 (gestione del sovraccarico e determinazione della perdita di pacchetti durante la trasmissione dei dati).
Gli RFC hanno ricevuto lo status di "Standard Proposto", dopo di che inizierà il lavoro per conferire agli RFC lo status di Standard Bozza (Draft Standard), che significa sostanzialmente la completa stabilizzazione del protocollo e la considerazione di tutti i commenti espressi. Il protocollo HTTP/3, che definisce l'utilizzo del protocollo QUIC come trasporto per HTTP/2, è ancora in fase di bozza, ma a breve sarà definitivamente standardizzato nell'IETF.
Si prevede che la standardizzazione di QUIC dia uno slancio per un'adozione più ampia di questo protocollo, nonché per lo sviluppo di estensioni basate su di esso, come WebTransport (tecnologia per l'invio e la ricezione di dati tra il browser e server) e MASQUE (tecnologia di proxying delle connessioni, che espande le capacità di SOCKS e HTTP CONNECT, utilizzando HTTPS su QUIC come trasporto).
Ricordiamo che il protocollo QUIC (Quick UDP Internet Connections) è in fase di sviluppo da parte di 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 le latenze in caso di perdita di pacchetti durante la trasmissione dei dati. QUIC è una sovrastruttura sul protocollo UDP, che supporta il multiplexing di più connessioni e offre metodi di crittografia equivalenti a TLS/SSL. Durante lo sviluppo dello standard IETF, il protocollo ha subito modifiche, portando alla creazione di due branche esistenti parallelamente, una per HTTP/3 e l'altra supportata da Google (Chrome supporta entrambe le versioni, mentre Firefox la versione IETF).
Caratteristiche principali di 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 una connessione istantaneamente (0-RTT, in circa il 75% dei casi i dati possono essere trasmessi immediatamente dopo l'invio del pacchetto di stabilimento della connessione) e garantire minimi ritardi tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Utilizzo di un numero di sequenza diverso per la ritrasmissione di pacchetti, 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 dei blocchi crittografici 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 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;
- Un notevole incremento delle prestazioni e della capacità di throughput rispetto a TCP. Per i servizi video, come YouTube, l'adozione di QUIC ha mostrato una riduzione delle operazioni di buffering durante la visione dei video del 30%.
Fonte: opennet.ru
