HTTP su UDP — utilizziamo utilmente il protocollo QUIC

QUIC (Quick UDP Internet Connections) è un protocollo sopra UDP che supporta tutte le funzionalità di TCP, TLS e HTTP/2, risolvendo la maggior parte dei loro problemi. È spesso definito un protocollo nuovo o "sperimentale", ma è già da tempo al di là della fase di esperimento: lo sviluppo è in corso da oltre 7 anni. Durante questo periodo, il protocollo non è ancora diventato uno standard, ma ha comunque ottenuto una diffusione significativa. Ad esempio, QUIC è utilizzato per accelerare il traffico e ridurre la latenza nelle reti mobili da giganti come Google e Facebook, mentre l'IETF ha dichiarato il suo fork del protocollo come base per lo standard HTTP/3 (considerando che HTTP/2 utilizza solo il 44.8% dei siti).

Concetto

QUIC è stato sviluppato come sostituto del TCP obsoleto, che era originariamente progettato per reti cablate con una bassa percentuale di perdite. TCP consegna i pacchetti in ordine; pertanto, in caso di perdita di un pacchetto, l'intera coda si arresta (head-of-line blocking), il che influisce negativamente sulla qualità e stabilità della connessione. Per evitare perdite massicce, le reti cellulari ricorrono all'uso di ampi buffer, il che porta a ridondanza e false reazioni negative del protocollo (bufferbloat). Inoltre, TCP impiega molto tempo per stabilire una connessione: le richieste SYN/ACK e TLS vanno separate, richiedendo tre roundtrip invece di uno, come fa QUIC.

Poiché QUIC combina una sostituzione del TCP e l'implementazione di TLS 1.3, tutte le connessioni sono sempre crittografate, e decifrare tale traffico non è più semplice di quanto non lo sia se passasse attraverso HTTPS. Inoltre, QUIC è implementato a livello applicativo, poiché una sostituzione completa dello stack TCP richiederebbe un'eternità..

Nonostante il supporto per il multiplexing in HTTP/2, il problema dell'head-of-line blocking è rimasto a causa della necessità di consegnare i pacchetti in ordine. QUIC, essendo implementato su UDP, non ha mai questi blocchi e, affinché i pacchetti non vengano persi definitivamente, vengono numerati e possono contenere parti di "vicini", garantendo la ridondanza. Inoltre, QUIC suddivide la coda monolitica in più flussi per diversi tipi di richieste all'interno di una singola connessione. In questo modo, in caso di perdita di un pacchetto, i problemi possono sorgere solo in una coda (ad esempio, per la trasmissione di un file specifico):

Utilizzo

Inizialmente QUIC è stato sviluppato all'interno di Google ed era in gran parte adattato per l'uso interno dell'azienda. Nel 2013 è stato trasferito all'IETF per la standardizzazione (che è ancora in corso) e ora chiunque può partecipare allo sviluppo del protocollo, suggerendo ciò che manca per le proprie esigenze. Il gruppo di lavoro dell'IETF organizza annualmente incontri in cui vengono approvati nuovi standard e si discute di novità. Questa implementazione di QUIC è considerata quella principale ed è proprio su di essa che viene certificato lo standard HTTP/3.

Per ora non si parla di includere HTTP/3 come protocollo principale, poiché non è ancora concluso e quasi non è supportato:

Tuttavia, QUIC può essere implementato come trasporto tra applicazione e server, cosa che è stata già realizzata con successo in Uber:

Commento di Uber sull'implementazione di QUIC

Per integrare con successo QUIC e migliorare le prestazioni dell'app in condizioni di scarsa connettività, abbiamo sostituito il vecchio stack (HTTP/2 sopra TLS/TCP) con il protocollo QUIC. Abbiamo utilizzato la libreria di rete Cronet da Progetti Chromium, che contiene la versione originale e di Google del protocollo – gQUIC. Questa implementazione è inoltre costantemente migliorata per seguire le ultime specifiche dell'IETF.

Per prima cosa abbiamo integrato Cronet nelle nostre applicazioni Android per aggiungere supporto a QUIC. L'integrazione è stata realizzata in modo da ridurre al minimo i costi di migrazione. Invece di sostituire completamente il vecchio stack di rete, che utilizzava la libreria OkHttp, abbiamo integrato Cronet ALL'INTERNO del framework OkHttp API. Rendendo l'integrazione in questo modo, abbiamo evitato modifiche alle nostre chiamate di rete (che utilizzano Retrofit) a livello di API.

Simile all'approccio per i dispositivi Android, abbiamo implementato Cronet nelle app Uber su iOS, intercettando il traffico HTTP dalle reti API, utilizzando NSURLProtocol. Questa astrazione fornita da iOS Foundation gestisce dati URL specifici del protocollo e garantisce che possiamo integrare Cronet nelle nostre app iOS senza costi significativi di migrazione.

tratto da questa traduzione dell'articolo Uber

Sul backend, catturavano le connessioni QUIC attraverso Google Cloud lb, che supporta il protocollo sin dal 2018.

Non sorprende che Google Cloud funzioni bene con un protocollo sviluppato da Google, ma quali sono le alternative?

Nginx

Non molto tempo fa, CloudFlare ha provato a ibridare nginx (che di default non supporta HTTP/3) con il suo strumento Quiche. L'implementazione è disponibile come unico file .patch, a cui è allegato un tutorial per l'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.patch

Qui 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
 make

Rimane solo da abilitare il supporto per HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Abilita QUIC e HTTP/3.
        listen 443 quic reuseport;

        # Abilita HTTP/2 (opzionale).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Abilita tutte le versioni TLS (TLSv1.3 è necessario per QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Il buffering delle richieste proxied non è attualmente supportato per HTTP/3.
        proxy_request_buffering off;

        # Aggiungi l'intestazione Alt-Svc per negoziare HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

Nei normali browser non è possibile connettersi tramite HTTP/3, ma puoi prendere Chrome Canary e avviarlo con il flag --enable-quic, collegarti al tuo server oppure, ad esempio, al sito quic.rocks e controllare il tipo di connessione negli Strumenti per sviluppatori:

Invece di HTTP/3 viene scritto http2+quic/99, ma in sostanza è la stessa cosa.

Altre tecnologie

• QUIC supporta anche LiteSpeed (che si sono connessi con grande pompa a Facebook tramite HTTP/3) e progressivo Caddy. Apache per il momento non lo supporta, ma il lavoro è in corso a pieno ritmo.
• Il 21 gennaio è stato aggiornato il bozza di standard per WebRTC
• Recentemente Microsoft ha aperto il codice della sua implementazione msquic, nella quale non sono ancora disponibili tutte le funzionalità dello standard IETF, ma già rappresenta un grande passo avanti.

Conclusione

L'interesse per QUIC è instabile, ma in crescita, e si sta lavorando alla sua standardizzazione. Nuove implementazioni del protocollo appaiono quasi ogni mese, e ogni anno sempre più sviluppatori si rendono conto che il futuro appartiene a QUIC. È anche possibile l'inclusione del protocollo nelle future versioni dello stack TCP, il che significa che prima o poi tutto l'internet passerà a connessioni più stabili e veloci.

Già adesso puoi configurare l'interazione QUIC per la tua infrastruttura o persino fornirla ai browser: tutti pianificano di aggiungere il supporto per il protocollo, e la triste statistica di caniuse diventerà più allegra.

Fonte: habr.com