HTTP sobre UDP - fent un bon ús del protocol QUIC

HTTP sobre UDP - fent un bon ús del protocol QUIC

QUIC (Quick UDP Internet Connections) és un protocol superior a UDP que admet totes les funcions de TCP, TLS i HTTP/2 i resol la majoria dels seus problemes. Sovint s'anomena protocol nou o "experimental", però fa temps que ha sobreviscut a l'etapa experimental: el desenvolupament ha estat en curs durant més de 7 anys. Durant aquest temps, el protocol no va aconseguir convertir-se en un estàndard, però tot i així es va generalitzar. Per exemple, QUIC és utilitzat per gegants com Google i Facebook per accelerar el trànsit i reduir els retards a les xarxes mòbils, i l'IETF va declarar que la seva bifurcació del protocol era la base de l'estàndard HTTP/3 (tot i que HTTP/2 utilitza només el 44.8% llocs).

Concepte

QUIC es va desenvolupar com a reemplaçament del TCP heretat, que es va dissenyar originalment per a xarxes cablejades de baixes pèrdues. TCP lliura els paquets en ordre, de manera que si es perd un paquet, s'atura tota la cua (bloqueig de cap de línia), que afecta negativament la qualitat i l'estabilitat de la connexió. Per evitar pèrdues massives, les xarxes cel·lulars recorren a l'ús de grans buffers, que al seu torn condueixen a la redundància i la resposta falsa negativa del protocol (bufferbloat). A més, TCP passa molt de temps establint una connexió: les sol·licituds SYN/ACK i TLS es processen per separat, i requereixen tres viatges d'anada i tornada en lloc d'un, com fa QUIC.

HTTP sobre UDP - fent un bon ús del protocol QUIC

Com que QUIC combina un reemplaçament de TCP i una implementació de TLS 1.3, totes les connexions sempre estan xifrades i desxifrar aquest trànsit no és més fàcil que si passa per HTTPS. A més, QUIC s'implementa a nivell d'aplicació, ja que caldria una substitució completa de la pila TCP l'eternitat.

Malgrat el suport per a la multiplexació a HTTP/2, el problema del bloqueig del cap de línia es va mantenir allà a causa de la necessitat de lliurar els paquets en ordre. QUIC s'implementa a sobre d'UDP, de manera que en principi no té cap bloqueig, i per evitar que els paquets es perdin per sempre, estan numerats i poden contenir parts de "veïns", proporcionant redundància. A més, QUIC divideix la cua monolítica en diversos fils per a diferents tipus de sol·licituds dins d'una única connexió. Així, si es perd un paquet, només poden sorgir problemes per a una cua (per exemple, per transferir un fitxer específic):

HTTP sobre UDP - fent un bon ús del protocol QUIC

Utilitzar

Inicialment, QUIC es va desenvolupar dins de Google i es va adaptar en gran mesura per al seu ús a l'empresa. L'any 2013 es va traslladar a l'IETF per a l'estandardització (que encara està en curs), i ara tothom pot participar en el desenvolupament del protocol proposant allò que li falta. El grup de treball de l'IETF organitza reunions anuals durant les quals s'aprova un nou estàndard i es discuteixen les innovacions. Aquesta implementació de QUIC es considera la principal i és sobre la base que es certifica l'estàndard HTTP/3.

Fins ara, no es parla d'incloure HTTP/3 com a protocol principal, perquè encara no s'ha acabat i gairebé no és compatible:

HTTP sobre UDP - fent un bon ús del protocol QUIC

Però QUIC es pot implementar com a transport entre l'aplicació i el servidor, cosa que es va fer amb èxit a Uber:

Comentari d'Uber sobre la introducció de QUIC

Per integrar QUIC amb èxit i millorar el rendiment de les aplicacions en entorns de connectivitat deficient, hem substituït la pila antiga (HTTP/2 sobre TLS/TCP) pel protocol QUIC. Hem utilitzat la biblioteca de xarxa Cronet d' Projectes Chromium, que conté la versió original de Google del protocol: gQUIC. Aquesta implementació també es millora constantment per seguir l'última especificació de l'IETF.

Primer vam integrar Cronet a les nostres aplicacions d'Android per afegir compatibilitat amb QUIC. La integració es va dur a terme de manera que es reduïssin al màxim els costos de migració. En lloc de substituir completament l'antiga pila de xarxa que utilitzava la biblioteca D'acord Http, hem integrat Cronet SOTA el marc de l'API OkHttp. En fer la integració d'aquesta manera, hem evitat canvis a les nostres trucades de xarxa (que són utilitzades per Reformar) a nivell d'API.

De manera similar a l'enfocament per als dispositius Android, vam implementar Cronet a les aplicacions d'Uber a iOS, interceptant el trànsit HTTP de la xarxa. APIutilitzant NSURLProtocol. Aquesta abstracció, proporcionada per la Fundació iOS, gestiona les dades d'URL específiques del protocol i assegura que podem integrar Cronet a les nostres aplicacions iOS sense costos de migració significatius.

agafat de aquesta traducció Articles d'Uber

Al backend van agafar connexions QUIC a través de Google Cloud lb, que suporta el protocol des de mitjan 2018.

No és d'estranyar que Google Cloud funcioni molt bé amb el protocol desenvolupat per Google, però quines són les alternatives?

Nginx

No fa molt CloudFlare Vaig intentar creuar nginx (que no admet HTTP/3 per defecte) amb la seva eina Quiche. La implementació està disponible com a fitxer .patch únic, que ve amb un tutorial d'instal·lació:

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

Aquí podeu connectar els vostres mòduls si cal

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

Tot el que queda és habilitar el suport 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';
    }
}

Encara no és possible connectar-se mitjançant HTTP/3 als navegadors habituals, però podeu utilitzar-lo Chrome Canari i córrer-lo amb la bandera --enable-quic, aneu al vostre servidor o, per exemple, al lloc quic.rocks i mireu el tipus de connexió a Eines per a desenvolupadors:
HTTP sobre UDP - fent un bon ús del protocol QUIC
En lloc d'HTTP/3 està escrit http2+quic/99, però bàsicament és el mateix.

Altres tecnologies

Conclusió

HTTP sobre UDP - fent un bon ús del protocol QUIC

L'interès per QUIC és inestable, però creix, i s'està treballant per normalitzar-lo. Noves implementacions del protocol apareixen gairebé cada mes, i cada any més desenvolupadors estan convençuts que QUIC és el futur. Fins i tot és possible incloure el protocol en futures versions de la pila TCP, la qual cosa significa que tard o d'hora tota Internet passarà a connexions més estables i ràpides.

Ara ja podeu configurar la interacció QUIC per a la vostra infraestructura o fins i tot donar-la als navegadors: tots tenen previst afegir suport per al protocol i les tristes estadístiques amb caniuse es tornaran més alegres.

HTTP sobre UDP - fent un bon ús del protocol QUIC

Font: www.habr.com

Afegeix comentari