HTTP su UDP — utilizziamo il protocollo QUIC con saggezza

QUIC (Quick UDP Internet Connections) è un protocollo basato su UDP che supporta tutte le funzionalità di TCP, TLS e HTTP/2, risolvendo la maggior parte dei loro problemi. Spesso viene definito un protocollo nuovo o "sperimentale", ma è in fase di sviluppo da oltre 7 anni. Sebbene non sia ancora diventato uno standard, ha già guadagnato una vasta diffusione. Ad esempio, QUIC viene utilizzato per velocizzare il traffico e ridurre la latenza nelle reti mobili da giganti come Google e Facebook, e l'IETF ha dichiarato il suo fork come base per lo standard HTTP/3 (mentre HTTP/2 è usato solo sul 44.8% dei siti web).

Concetto

QUIC è stato sviluppato come sostituto del obsoleto TCP, originariamente progettato per reti cablate con basse percentuali di perdita. TCP consegna i pacchetti in ordine, quindi, in caso di perdita di un pacchetto, l'intera coda si ferma (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 buffer grandi, il che porta a ridondanza e false reazioni negative del protocollo (bufferbloat). Inoltre, TCP richiede molto tempo per stabilire la connessione: le richieste SYN/ACK e TLS viaggiano separatamente, richiedendo tre roundtrip anziché uno, come fa QUIC.

Poiché QUIC combina la sostituzione di TCP con l'implementazione di TLS 1.3, tutte le connessioni sono sempre crittografate; decifrare questo traffico non è più semplice che se viaggiasse su HTTPS. Inoltre, QUIC è implementato a livello applicativo, poiché una sostituzione totale dello stack TCP richiederebbe un'eternità.

Nonostante il supporto al multiplexing in HTTP/2, il problema del blocco head-of-line rimane a causa della necessità di consegnare i pacchetti in ordine. QUIC è implementato sopra UDP, quindi non ha blocchi in linea di principio. Per garantire che i pacchetti non vengano persi irrimediabilmente, vengono numerati e possono contenere parti di "vicini", fornendo ridondanza. Inoltre, QUIC divide 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):

L'utilizzo di

Originariamente, QUIC è stato sviluppato all'interno di Google ed era in gran parte progettato 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, proponendo ciò di cui ha bisogno. Il gruppo di lavoro dell'IETF organizza annualmente incontri in cui viene approvato il nuovo standard e si discute delle innovazioni. Questa implementazione di QUIC è considerata principale e sulla sua base viene certificato lo standard HTTP/3.

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

Tuttavia, QUIC può essere implementato come mezzo di trasporto tra l'applicazione e il server, come fatto con successo da Uber:

Commento di Uber sull'implementazione di QUIC

Per integrare con successo QUIC e migliorare le prestazioni dell'applicazione in condizioni di connessione scadente, abbiamo sostituito il vecchio stack (HTTP/2 sopra TLS/TCP) con il protocollo QUIC. Abbiamo utilizzato la libreria di rete Cronet di Chromium Projects, che contiene la versione originale del protocollo Google – gQUIC. Questa implementazione è costantemente migliorata per seguire l'ultima specifica IETF.

Inizialmente, abbiamo integrato Cronet nelle nostre applicazioni Android per aggiungere il supporto per QUIC. L'integrazione è stata effettuata in modo da ridurre al minimo i costi di migrazione. Invece di sostituire completamente lo stack di rete esistente che utilizzava la libreria OkHttp, abbiamo integrato Cronet SOTTO il framework OkHttp API. Effettuando l'integrazione in questo modo, abbiamo evitato modifiche alle nostre chiamate di rete (utilizzate da Retrofit) a livello API.

Analogamente all'approccio per i dispositivi Android, abbiamo implementato Cronet nelle applicazioni Uber per iOS, intercettando il traffico HTTP dalle reti API, utilizzando NSURLProtocol. Questa astrazione, fornita da 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 questa traduzione articolo di Uber

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

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

Nginx

Non molto tempo fa, CloudFlare ha provato a incrociare nginx (che di default non supporta HTTP/3) con il suo strumento Quiche. L'implementazione è disponibile come un singolo file .patch, corredato da un tutorial all'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 connettere 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 è richiesta per QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # La richiesta di buffering non è attualmente supportata 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 browser normali, non sarà possibile connettersi tramite HTTP/3, ma puoi prendere Chrome Canary e avviare con il flag --enable-quic, accedi al tuo server o, ad esempio, al sito quic.rocks e controlla il tipo di connessione negli Strumenti per sviluppatori:

Al posto di HTTP/3 viene indicato http2+quic/99, ma in sostanza è la stessa cosa.

Alte tecnologie

• QUIC è supportato anche da LiteSpeed (che si sono collegati con grande pompa a Facebook tramite HTTP/3) e dal più innovativo Caddy. Apache ancora non lo supporta, ma il lavoro è in pieno svolgimento.
• Il 21 gennaio è stato aggiornato il bozza degli standard per WebRTC
• Appena qualche giorno fa Microsoft ha rilasciato il codice della sua implementazione msquic, in cui non tutte le funzioni dello standard IETF sono ancora disponibili, ma è già un grande passo avanti.

Conclusione

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

Puoi già configurare il protocollo QUIC per la tua infrastruttura o persino fornirlo ai browser — tutti stanno pianificando di aggiungere il supporto per questo protocollo, e le tristi statistiche di caniuse diventeranno più ottimiste.

Fonte: habr.com