Il protocollo QUIC ha ricevuto lo status di standard proposto.

L'Internet Engineering Task Force (IETF), responsabile dello sviluppo dei protocolli e dell'architettura Internet, ha finalizzato la RFC per il protocollo QUIC e pubblicato le relative specifiche con gli identificatori RFC 8999 (proprietà del protocollo indipendente dalla versione), RFC 9000 (proprietà del protocollo indipendente dalla versione) su UDP), RFC 9001 (crittografia TLS del canale di comunicazione QUIC) e RFC 9002 (controllo della congestione e rilevamento della perdita di pacchetti durante la trasmissione dei dati).

Le RFC hanno ricevuto lo status di “Proposed Standard”, dopodiché inizieranno i lavori per conferire alla RFC lo status di bozza di standard (Draft Standard), il che significa in realtà una completa stabilizzazione del protocollo e tenendo conto di tutti i commenti formulati. Il protocollo HTTP/3, che definisce l'utilizzo del protocollo QUIC come trasporto per HTTP/2, è ancora in fase di bozza di specifica, ma presto sarà finalmente standardizzato dall'IETF.

Si prevede che la standardizzazione di QUIC darà impulso ad una più ampia adozione di questo protocollo, nonché allo sviluppo di estensioni basate su di esso, come WebTransport (una tecnologia per inviare e ricevere dati tra un browser e un server) e MASQUE (una tecnologia di proxy di connessione che estende le capacità di SOCKS e HTTP CONNECT e utilizza HTTPS su QUIC come trasporto).

Ricordiamo che il protocollo QUIC (Quick UDP Internet Connections) è stato sviluppato da Google a partire dal 2013 come alternativa alla combinazione TCP+TLS per il Web, risolvendo i problemi legati ai lunghi tempi di installazione e negoziazione delle connessioni in TCP ed eliminando i ritardi quando i pacchetti vengono persi 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. Durante lo sviluppo dello standard IETF sono state apportate modifiche al protocollo, che hanno portato alla nascita di due rami paralleli, uno per HTTP/3 e il secondo supportato da Google (Chrome supporta entrambe le opzioni e Firefox supporta la versione IETF) .

Caratteristiche principali di QUIC:

  • 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);
  • Utilizzo di un numero di sequenza diverso durante la ritrasmissione di un pacchetto, 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;
  • Aumento significativo delle prestazioni e del throughput rispetto al 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

Aggiungi un commento