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.
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):
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:
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.
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:
En lloc d'HTTP/3 està escrit http2+quic/99, però bàsicament és el mateix.
Altres tecnologies
QUIC també dóna suport LiteSpeed (que es va connectar a Facebook a través de HTTP/3 amb molt de bombo) i progressiu Caddie. Apache encara no ho pot fer, però s'està treballant ple funcionament.
L'altre dia va obrir Microsoft codi d'implementació msquic, en què encara no estan disponibles totes les funcions de l'estàndard IETF, però això ja és un gran avenç.
Conclusió
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.