QUIC (Quick UDP Internet Connections) è un protocollo sopra UDP che supporta tutte le funzionalità di TCP, TLS e HTTP/2 e risolve la maggior parte dei loro problemi. Viene spesso definito un protocollo nuovo o “sperimentale”, ma è sopravvissuto da tempo alla fase sperimentale: lo sviluppo è in corso da più di 7 anni. Durante questo periodo, il protocollo non è riuscito a diventare uno standard, ma si è comunque diffuso. Ad esempio, QUIC viene utilizzato da giganti come Google e Facebook per accelerare il traffico e ridurre i ritardi nelle reti mobili, e l’IETF ha dichiarato che il suo fork del protocollo costituisce la base per lo standard HTTP/3 (anche se HTTP/2 utilizza siti).
Concetto
QUIC è stato sviluppato in sostituzione del vecchio TCP, originariamente progettato per reti cablate a bassa perdita. TCP consegna i pacchetti in ordine, quindi se un pacchetto viene perso, l'intera coda viene interrotta (), che influisce negativamente sulla qualità e sulla stabilità della connessione. Per evitare perdite massicce, le reti cellulari ricorrono all’utilizzo di buffer di grandi dimensioni, che a loro volta portano alla ridondanza e alla risposta falsa negativa del protocollo (). Inoltre, TCP impiega molto tempo a stabilire una connessione: le richieste SYN/ACK e TLS vengono elaborate separatamente, richiedendo tre roundtrip invece di uno, come fa QUIC.
Poiché QUIC combina una sostituzione TCP e un'implementazione di TLS 1.3, tutte le connessioni sono sempre crittografate e decrittografare tale traffico non è più semplice che se passasse su HTTPS. Inoltre, QUIC viene implementato a livello di applicazione, poiché ciò richiederebbe una sostituzione completa dello stack TCP eternità.
Nonostante il supporto per il multiplexing in HTTP/2, il problema del blocco head-of-line rimaneva a causa della necessità di consegnare i pacchetti in ordine. QUIC è implementato sopra UDP, quindi in linea di principio non ha alcun blocco e, per evitare che i pacchetti vadano persi per sempre, sono numerati e possono contenere parti di "vicini", fornendo ridondanza. Inoltre, QUIC suddivide la coda monolitica in più thread per diversi tipi di richieste all'interno di una singola connessione. Pertanto, se un pacchetto viene perso, potrebbero verificarsi problemi solo per una coda (ad esempio per il trasferimento di un file specifico):
l'uso di
Inizialmente, QUIC è stato sviluppato all’interno di Google ed era in gran parte adattato per l’utilizzo all’interno dell’azienda. Nel 2013 è stato trasferito all’IETF per la standardizzazione (che è ancora in corso) e ora tutti possono partecipare allo sviluppo del protocollo proponendo ciò che gli manca. Il gruppo di lavoro IETF organizza riunioni annuali durante le quali viene approvato un nuovo standard e si discutono le innovazioni. Questa implementazione di QUIC è considerata la principale ed è sulla base di essa che viene certificato lo standard HTTP/3.
Finora non si parla di includere HTTP/3 come protocollo principale, perché non è ancora finito e non è quasi supportato:
Ma QUIC può essere implementato come trasporto tra l'applicazione e il server, cosa che è stata eseguita con successo da Uber:
Il commento di Uber sull'introduzione di QUIC
Per incorporare con successo QUIC e migliorare le prestazioni delle applicazioni in ambienti con scarsa connettività, abbiamo sostituito il vecchio stack (HTTP/2 su TLS/TCP) con il protocollo QUIC. Abbiamo utilizzato la libreria di rete di , che contiene la versione originale del protocollo Google: gQUIC. Anche questa implementazione viene costantemente migliorata per seguire le ultime specifiche IETF.
Per prima cosa abbiamo integrato Cronet nelle nostre app Android per aggiungere il supporto per QUIC. L’integrazione è stata effettuata in modo tale da ridurre il più possibile i costi di migrazione. Invece di sostituire completamente il vecchio stack di rete che utilizzava la libreria , abbiamo integrato Cronet SOTTO il framework API OkHttp. Eseguendo l'integrazione in questo modo, abbiamo evitato modifiche alle nostre chiamate di rete (utilizzate da ) a livello API.
Analogamente all'approccio per i dispositivi Android, abbiamo implementato Cronet nelle app Uber su iOS, intercettando il traffico HTTP dalla rete utilizzando . Questa astrazione, fornita dalla iOS Foundation, gestisce i dati URL specifici del protocollo e garantisce che possiamo integrare Cronet nelle nostre applicazioni iOS senza costi di migrazione significativi.
preso da Articoli Uber
Sul back-end hanno rilevato connessioni QUIC tramite Google Cloud lb, che dalla metà del 2018.
Non sorprende che Google Cloud funzioni perfettamente con il protocollo sviluppato da Google, ma quali sono le alternative?
Nginx
Non molto tempo fa CloudFlare nginx (che non supporta HTTP/3 per impostazione predefinita) con il suo strumento Quiche. L'implementazione è disponibile come singolo file .patch, che viene fornito con un tutorial di installazione:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchQui puoi collegare i tuoi moduli se necessario
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeNon resta che abilitare il supporto HTTP/3
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
Non è ancora possibile connettersi tramite HTTP/3 nei browser normali, ma è possibile utilizzare ed eseguilo con la bandiera --enable-quic, vai al tuo server o, ad esempio, al sito quic.rocks e guarda il tipo di connessione in Strumenti per sviluppatori:
Invece di HTTP/3 è scritto http2+quic/99, ma essenzialmente è la stessa cosa.
Altre tecnologie
- Anche QUIC supporta (che si è connesso a Facebook tramite HTTP/3 con grande clamore) e progressivo . Apache non può ancora farlo, ma il lavoro è in corso .
- 21 gennaio aggiornato
- Proprio l'altro giorno Microsoft ha aperto , in cui non sono ancora disponibili tutte le funzioni dello standard IETF, ma questo è già un grande passo avanti.
conclusione
L'interesse per QUIC è instabile, ma in crescita, e si sta lavorando per standardizzarlo. Quasi ogni mese compaiono nuove implementazioni del protocollo e ogni anno sempre più sviluppatori sono convinti che QUIC sia il futuro. È anche possibile includere il protocollo nelle future versioni dello stack TCP, il che significa che prima o poi l’intera Internet passerà a connessioni più stabili e veloci.
Già ora puoi configurare l'interazione QUIC per la tua infrastruttura o addirittura fornirla ai browser: tutti stanno pianificando di aggiungere il supporto per il protocollo e le tristi statistiche con caniuse diventeranno più allegre.
Fonte: habr.com