Il Comitato IETF (Internet Engineering Task Force), responsabile dello sviluppo dei protocolli e dell'architettura di Internet, ha completato la stesura degli 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 per il canale di comunicazione QUIC) e RFC 9002 (gestione della congestione e determinazione della perdita di pacchetti durante la trasmissione dei dati).
Gli RFC hanno ottenuto lo status di «Standard Proposto», dopodiché inizierà il lavoro per conferire agli RFC lo status di Standard Bozza (Draft Standard), che significa di fatto la completa stabilizzazione del protocollo e la considerazione di tutti i commenti espressi. Il protocollo HTTP/3, che definisce l'uso del protocollo QUIC come trasporto per HTTP/2, è attualmente in fase di bozza, ma prossimamente sarà standardizzato definitivamente in IETF.
Ci si aspetta che la standardizzazione di QUIC dia impulso a una maggiore diffusione di questo protocollo, oltre a promuovere lo sviluppo di estensioni basate su di esso, come WebTransport (tecnologia per l'invio e la ricezione di dati tra browser e server) e MASQUE (tecnologia di proxying delle connessioni, che amplia le funzionalità di SOCKS e HTTP CONNECT, utilizzando HTTPS sopra QUIC come trasporto).
Ricordiamo che il protocollo QUIC (Quick UDP Internet Connections) è in fase di sviluppo da Google dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo i problemi relativi ai lunghi tempi di stabilimento e accordo delle connessioni in TCP e eliminando 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. Durante lo sviluppo dello standard IETF, sono state apportate modifiche al protocollo che hanno portato alla creazione di due rami esistenti in parallelo, uno per HTTP/3 e l'altro supportato da Google (Chrome supporta entrambe le varianti, mentre Firefox supporta la variante IETF).
Caratteristiche principali di 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;
- La possibilità di stabilire una connessione in modo istantaneo (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 latenze minime tra l'invio della richiesta e la ricezione della risposta (RTT, Round Trip Time);
- Uso di un numero di sequenza diverso per la ritrasmissione di un pacchetto, consentendo di evitare ambiguità nella definizione dei pacchetti ricevuti e di 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 limiti dei blocchi crittografici sono allineati con i limiti 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;
- Un notevole aumento delle prestazioni e della larghezza di banda rispetto al TCP. Per i servizi video, come YouTube, l'uso di QUIC ha mostrato una riduzione del 30% delle operazioni di buffering durante la visione di video.
Fonte: opennet.ru
