RAPIDO - QUIC

QUIC
Protocollo di comunicazione
Scopo scopo generale
Sviluppatore/i IETF
Introdotto 12 ottobre 2012 ; 9 anni fa ( 2012-10-12 )
livello OSI Livello di trasporto
RFC RFC 8999, RFC 9000
Sito web quicwg .org

QUIC (pronunciato "quick") è un protocollo di rete a livello di trasporto generico inizialmente progettato da Jim Roskind presso Google , implementato e distribuito nel 2012, annunciato pubblicamente nel 2013 come sperimentazione ampliata e descritto in una riunione IETF . QUIC è utilizzato da più della metà di tutte le connessioni dal browser web Chrome ai server di Google. Microsoft Edge (un derivato di Chrome) e Firefox lo supportano. Safari implementa il protocollo, tuttavia non è abilitato per impostazione predefinita.

Sebbene il suo nome sia stato inizialmente proposto come acronimo di "Quick UDP Internet Connections", l'uso della parola QUIC da parte di IETF non è un acronimo; è semplicemente il nome del protocollo. QUIC migliora le prestazioni delle applicazioni Web orientate alla connessione che attualmente utilizzano TCP . Lo fa stabilendo un numero di connessioni multiplex tra due endpoint utilizzando User Datagram Protocol (UDP) ed è progettato per rendere obsoleto il TCP a livello di trasporto per molte applicazioni, guadagnando così al protocollo il soprannome occasionale "TCP/2".

QUIC funziona di pari passo con le connessioni multiplex di HTTP/2 , consentendo a più flussi di dati di raggiungere tutti gli endpoint in modo indipendente e quindi indipendente dalle perdite di pacchetti che coinvolgono altri flussi. Al contrario, HTTP/2 ospitato su Transmission Control Protocol (TCP) può subire ritardi di blocco della testa di linea di tutti i flussi multiplexati se uno qualsiasi dei pacchetti TCP viene ritardato o perso.

Gli obiettivi secondari di Quic includono connessione ridotta e il trasporto di latenza e larghezza di banda di stima in ogni direzione per evitare di congestione . Sposta anche gli algoritmi di controllo della congestione nello spazio utente in entrambi gli endpoint, piuttosto che nello spazio del kernel , che si afferma consentirà a questi algoritmi di migliorare più rapidamente. Inoltre, il protocollo può essere esteso con la correzione degli errori in avanti (FEC) per migliorare ulteriormente le prestazioni quando sono previsti errori, e questo è visto come il passo successivo nell'evoluzione del protocollo.

Nel giugno 2015, una bozza Internet di una specifica per QUIC è stata presentata all'IETF per la standardizzazione. Un gruppo di lavoro QUIC è stato istituito nel 2016. Nell'ottobre 2018, i gruppi di lavoro HTTP e QUIC di IETF hanno deciso congiuntamente di chiamare la mappatura HTTP su QUIC " HTTP/3 " prima di renderlo uno standard mondiale. Nel maggio 2021, l'IETF ha standardizzato QUIC in RFC  9000 , supportato da RFC  8999 , RFC  9001 e RFC  9002 .

Sfondo

Il protocollo di controllo della trasmissione , o TCP, mira a fornire un'interfaccia per l'invio di flussi di dati tra due endpoint. I dati vengono passati al sistema TCP, che garantisce che i dati arrivino all'altra estremità esattamente nella stessa forma, o la connessione indicherà che esiste una condizione di errore.

Per fare ciò, TCP suddivide i dati in pacchetti di rete e aggiunge piccole quantità di dati a ciascun pacchetto. Questi dati aggiuntivi includono un numero di sequenza utilizzato per rilevare i pacchetti persi o arrivati ​​fuori servizio e un checksum che consente di rilevare gli errori all'interno dei dati del pacchetto. Quando si verifica uno dei problemi, TCP utilizza la richiesta di ripetizione automatica (ARQ) per indicare al mittente di inviare nuovamente il pacchetto perso o danneggiato.

Nella maggior parte delle implementazioni, TCP vedrà qualsiasi errore su una connessione come un'operazione di blocco, interrompendo ulteriori trasferimenti fino a quando l'errore non viene risolto o la connessione non viene considerata fallita. Se viene utilizzata una singola connessione per inviare più flussi di dati, come nel caso del protocollo HTTP/2 , tutti questi flussi vengono bloccati anche se solo uno di essi potrebbe avere un problema. Ad esempio, se si verifica un singolo errore durante il download di un'immagine GIF utilizzata per una favicon , l'intero resto della pagina attenderà che il problema venga risolto.

Poiché il sistema TCP è progettato per assomigliare a un "tubo di dati", o flusso, contiene deliberatamente una scarsa comprensione dei dati che trasmette. Se quei dati hanno requisiti aggiuntivi, come la crittografia tramite TLS , questo deve essere impostato dai sistemi in esecuzione su TCP, utilizzando TCP per comunicare con software simile all'altra estremità della connessione. Ciascuno di questi tipi di attività di configurazione richiede il proprio processo di stretta di mano . Ciò richiede spesso diversi round trip di richieste e risposte fino a quando non viene stabilita la connessione. A causa della latenza intrinseca delle comunicazioni a lunga distanza, ciò può aggiungere un sovraccarico significativo alla trasmissione complessiva.

Caratteristiche

QUIC mira ad essere quasi equivalente a una connessione TCP ma con una latenza molto ridotta. Lo fa principalmente attraverso due modifiche che si basano sulla comprensione del comportamento del traffico HTTP .

La prima modifica consiste nel ridurre notevolmente il sovraccarico durante l'impostazione della connessione. Poiché la maggior parte delle connessioni HTTP richiederà TLS , QUIC rende lo scambio delle chiavi di configurazione e dei protocolli supportati parte del processo di handshake iniziale. Quando un client apre una connessione, il pacchetto di risposta include i dati necessari affinché i pacchetti futuri utilizzino la crittografia. Ciò elimina la necessità di impostare la connessione TCP e quindi negoziare il protocollo di sicurezza tramite pacchetti aggiuntivi. Altri protocolli possono essere serviti allo stesso modo, combinando più passaggi in un'unica richiesta-risposta. Questi dati possono quindi essere utilizzati sia per richieste successive nella configurazione iniziale, sia per richieste future che altrimenti verrebbero negoziate come connessioni separate.

La seconda modifica consiste nell'utilizzare come base UDP anziché TCP, che non include il ripristino delle perdite. Invece, ogni flusso QUIC è controllato separatamente dal flusso e i dati persi vengono ritrasmessi a livello di QUIC, non di UDP. Ciò significa che se si verifica un errore in un flusso, come nell'esempio favicon sopra, lo stack di protocollo può continuare a servire altri flussi in modo indipendente. Questo può essere molto utile per migliorare le prestazioni sui collegamenti soggetti a errori, poiché nella maggior parte dei casi è possibile ricevere dati aggiuntivi considerevoli prima che TCP si accorga che un pacchetto è mancante o interrotto e tutti questi dati vengono bloccati o addirittura cancellati mentre l'errore viene corretto. In QUIC, questi dati possono essere elaborati liberamente mentre il singolo flusso multiplexato viene riparato.

QUIC include una serie di altre modifiche più banali che migliorano anche la latenza e il throughput complessivi. Ad esempio, i pacchetti vengono crittografati individualmente, in modo che non risultino nei dati crittografati in attesa di pacchetti parziali. Ciò non è generalmente possibile in TCP, dove i record di crittografia si trovano in un flusso di byte e lo stack di protocollo non è a conoscenza dei limiti di livello superiore all'interno di questo flusso. Questi possono essere negoziati dai livelli in esecuzione in alto, ma QUIC mira a fare tutto questo in un unico processo di stretta di mano.

Un altro obiettivo del sistema QUIC era migliorare le prestazioni durante gli eventi di commutazione di rete, come accade quando un utente di un dispositivo mobile si sposta da un hotspot WiFi locale a una rete mobile . Quando ciò si verifica su TCP, inizia un lungo processo in cui ogni connessione esistente scade una alla volta e viene quindi ristabilita su richiesta. Per risolvere questo problema, QUIC include un identificatore di connessione che identifica in modo univoco la connessione al server indipendentemente dall'origine. Ciò consente di ristabilire la connessione semplicemente inviando un pacchetto, che contiene sempre questo ID, poiché l'ID di connessione originale sarà ancora valido anche se l' indirizzo IP dell'utente cambia.

QUIC può essere implementato nello spazio dell'applicazione, invece di essere nel kernel del sistema operativo . Questo generalmente richiama un sovraccarico aggiuntivo dovuto ai cambi di contesto quando i dati vengono spostati tra le applicazioni. Tuttavia, nel caso di QUIC, lo stack di protocollo deve essere utilizzato da una singola applicazione, con ogni applicazione che utilizza QUIC con le proprie connessioni ospitate su UDP. In definitiva, la differenza potrebbe essere molto piccola perché gran parte dello stack HTTP/2 complessivo è già nelle applicazioni (o nelle loro librerie, più comunemente). Il posizionamento delle parti rimanenti in quelle librerie, essenzialmente la correzione degli errori, ha scarso effetto sulla dimensione dello stack HTTP/2 o sulla complessità complessiva.

Questa organizzazione consente di apportare più facilmente modifiche future in quanto non richiede modifiche al kernel per gli aggiornamenti. Uno degli obiettivi a lungo termine di QUIC è aggiungere nuovi sistemi per la correzione degli errori in avanti (FEC) e un migliore controllo della congestione.

Una preoccupazione per il passaggio da TCP a UDP è che TCP è ampiamente adottato e molte delle "caselle intermedie" nell'infrastruttura Internet sono sintonizzate per TCP e limite di velocità o addirittura bloccano UDP. Google ha effettuato una serie di esperimenti esplorativi per caratterizzare questo e ha scoperto che solo un piccolo numero di connessioni è stato bloccato in questo modo. Ciò ha portato all'uso di un rapido sistema di fallback-to-TCP; Lo stack di rete di Chromium apre contemporaneamente sia una connessione QUIC che una connessione TCP tradizionale, il che consente di eseguire il fallback con una latenza trascurabile.

Google QUIC (gQUIC)

Il protocollo che è stato creato da Google e portato all'IETF con il nome QUIC (già nel 2012 intorno a QUIC versione 20) è abbastanza diverso dal QUIC che ha continuato ad evolversi e ad essere perfezionato all'interno dell'IETF. Il Google QUIC originale è stato progettato per essere un protocollo per scopi generici, sebbene inizialmente sia stato implementato come protocollo per supportare HTTP(S) in Chromium. L'attuale evoluzione del protocollo IETF QUIC è un protocollo di trasporto di uso generale. Gli sviluppatori di Chromium hanno continuato a monitorare l'evoluzione degli sforzi di standardizzazione di IETF QUIC per adottare e rispettare pienamente gli standard Internet più recenti per QUIC in Chromium.

Adozione

Supporto browser

Il codice QUIC è stato sviluppato sperimentalmente in Google Chrome a partire dal 2012 ed è stato annunciato come parte della versione 29 di Chromium (rilasciata il 20 agosto 2013). Attualmente è abilitato per impostazione predefinita in Chromium e Chrome.

Il supporto in Firefox è arrivato a maggio 2021.

Apple ha aggiunto il supporto sperimentale nel motore WebKit tramite Safari Technology Preview 104 nell'aprile 2020. Il supporto ufficiale è stato aggiunto in Safari 14, incluso in macOS Big Sur e iOS 14 , ma la funzione deve essere attivata manualmente.

Assistenza clienti

La libreria cronet per QUIC e altri protocolli è disponibile per le applicazioni Android come modulo caricabile tramite Google Play Services .

cURL 7.66, rilasciato l'11 settembre 2019, supporta HTTP/3 (e quindi QUIC).

Nell'ottobre 2020, Facebook ha annunciato di aver migrato con successo le sue app, incluso Instagram , e l'infrastruttura del server su QUIC, con già il 75% del suo traffico Internet utilizzando QUIC. Tutte le app per dispositivi mobili di Google supportano QUIC, inclusi YouTube e Gmail . Anche l'app mobile di Uber utilizza QUIC.

Supporto server

A partire dal 2017, ci sono diverse implementazioni mantenute attivamente. I server di Google supportano QUIC e Google ha pubblicato un prototipo di server. Akamai Technologies supporta QUIC da luglio 2016. È inoltre disponibile un'implementazione Go chiamata quic-go che supporta il supporto QUIC sperimentale nel server Caddy . L'11 luglio 2017, LiteSpeed ​​Technologies ha iniziato ufficialmente a supportare QUIC nei propri prodotti di bilanciamento del carico (WebADC) e LiteSpeed ​​Web Server . A ottobre 2019, l'88,6% dei siti Web QUIC utilizzava LiteSpeed ​​e il 10,8% utilizzava Nginx . Sebbene inizialmente solo i server di Google supportassero le connessioni HTTP-over-QUIC, anche Facebook ha lanciato la tecnologia nel 2018 e Cloudflare offre supporto QUIC su base beta dal 2018. A marzo 2021, il 5,0% di tutti i siti Web utilizza QUIC. Microsoft Windows Server 2022 supporta i protocolli HTTP/3 e SMB su QUIC tramite MsQuic .

Inoltre, ci sono diversi progetti di comunità obsoleti: libquic è stato creato estraendo l'implementazione Chromium di QUIC e modificandola per ridurre al minimo i requisiti di dipendenza e goquic fornisce i collegamenti Go di libquic. Infine, quic-reverse-proxy è un'immagine Docker che funge da server proxy inverso , traducendo le richieste QUIC in un semplice HTTP che può essere compreso dal server di origine.

.NET 5 introduce il supporto sperimentale per QUIC utilizzando la libreria MsQuic .

Codice sorgente

Le seguenti implementazioni di QUIC o gQUIC sono disponibili in formato sorgente:
Implementazione Licenza Lingua Descrizione
Cromo Gratuito C++ Questo è il codice sorgente del browser web Chrome e l'implementazione gQUIC di riferimento. Contiene programmi client e server gQUIC e QUIC autonomi che possono essere utilizzati per i test. Codice sorgente sfogliabile . Questa versione è anche la base della LINEA s' stellite e Cronet di Google.
Libreria QUIC (mvfst) Licenza MIT C++ mvfst (pronunciato move fast) è un'implementazione client e server del protocollo IETF QUIC in C++ di Facebook.
Libreria LiteSpeed ​​QUIC (lsquic) Licenza MIT C Questa è l' implementazione QUIC e HTTP/3 utilizzata da LiteSpeed ​​Web Server e OpenLiteSpeed .
ngtcp2 Licenza MIT C Questa è una libreria QUIC indipendente dalla libreria crittografica e funziona con OpenSSL o GnuTLS. Per HTTP/3, necessita di una libreria separata come nghttp3 .
quiche Licenza con clausola BSD-2 Ruggine Indipendente dal socket ed espone un'API C da utilizzare nelle applicazioni C/C++.
rapidamente Licenza MIT C Questa libreria è l'implementazione QUIC per il server web H2O .
veloce Licenza MIT andare Questa libreria fornisce supporto QUIC nel server web Caddy . È disponibile anche la funzionalità client.
Quinn Licenza Apache 2.0 Ruggine
Neqo Licenza Apache 2.0 Ruggine Questa implementazione di Mozilla è pianificata per essere integrata in Necko, una libreria di rete utilizzata nel browser web Firefox
aioquico Licenza con clausola BSD-3 Pitone Questa libreria dispone di un'API senza I/O adatta per l'incorporamento sia nei client che nei server.
picoquic Licenza con clausola BSD-3 C Un'implementazione minima di QUIC allineata con le specifiche IETF
pquic Licenza MIT C Un'implementazione QUIC estensibile che include una macchina virtuale eBPF in grado di caricare dinamicamente le estensioni come plugin
MsQuic Licenza MIT C Un'implementazione QUIC multipiattaforma di Microsoft progettata per essere una libreria QUIC di uso generale.
QUANT Licenza con clausola BSD-2 C Quant supporta piattaforme POSIX tradizionali (Linux, MacOS, FreeBSD, ecc.) e sistemi embedded.
veloce Licenza con clausola BSD-3 Haskell Questo pacchetto implementa QUIC basato su thread leggeri Haskell.
netty-incubatore-codec-quic Licenza Apache 2.0 Giava Questo pacchetto implementa QUIC in netty basato sull'implementazione di Quiche .

Guarda anche

Riferimenti

link esterno