🥇HTTP sobre UDP - usando o protocolo QUIC para beneficiarse

QUIC (Quick UDP Internet Connections) é un protocolo enriba de UDP que admite todas as funcións de TCP, TLS e HTTP/2 e resolve a maioría dos seus problemas. Adoita chamarse protocolo novo ou "experimental", pero sobreviviu hai moito tempo á etapa experimental: o desenvolvemento leva máis de 7 anos. Durante este tempo, o protocolo non conseguiu converterse nun estándar, pero aínda así se estendeu. Por exemplo, QUIC é usado por xigantes como Google e Facebook para acelerar o tráfico e reducir os atrasos nas redes móbiles, e o IETF declarou a súa bifurcación do protocolo a base do estándar HTTP/3 (a pesar de que HTTP/2 utiliza só o 44.8% sitios).

Concepto

QUIC foi desenvolvido como un substituto para o legado TCP, que foi deseñado orixinalmente para redes con cable de baixa perda. TCP entrega os paquetes en orde, polo que se se perde un paquete, detense toda a cola (bloqueo de cabeza de liña), o que afecta negativamente á calidade e estabilidade da conexión. Para evitar perdas masivas, as redes móbiles recorren ao uso de grandes búfers, o que á súa vez leva á redundancia e á resposta falsa negativa do protocolo (bufferbloat). Ademais, TCP dedica moito tempo a establecer unha conexión: as solicitudes SYN/ACK e TLS son procesadas por separado, o que require tres viaxes de ida e volta en lugar dun, como fai QUIC.

Dado que QUIC combina unha substitución de TCP e unha implementación de TLS 1.3, todas as conexións están sempre cifradas e descifrar ese tráfico non é máis fácil que se fose a través de HTTPS. Ademais, QUIC está implementado a nivel de aplicación, xa que sería necesario unha substitución completa da pila TCP para sempre.

A pesar do soporte para a multiplexación en HTTP/2, o problema do bloqueo de cabeceira de liña permaneceu aí debido á necesidade de entregar os paquetes en orde. QUIC está implementado enriba de UDP, polo que non ten bloqueo en principio, e para evitar que os paquetes se perdan para sempre, están numerados e poden conter partes de "veciños", proporcionando redundancia. Ademais, QUIC divide a cola monolítica en varios fíos para diferentes tipos de solicitudes dentro dunha única conexión. Así, se se perde un paquete, só poden xurdir problemas para unha cola (por exemplo, para transferir un ficheiro específico):

Usar

Inicialmente, QUIC desenvolveuse dentro de Google e foi adaptado en gran medida para o seu uso dentro da empresa. En 2013, foi transferido ao IETF para a normalización (que aínda está en curso), e agora todos poden participar no desenvolvemento do protocolo propoñendo o que lles falta. O grupo de traballo IETF organiza reunións anuais durante as cales se aproba un novo estándar e se discuten as innovacións. Esta implementación de QUIC considérase a principal e é na súa base que se certifica o estándar HTTP/3.

Ata agora, non se fala de incluír HTTP/3 como protocolo principal, porque aínda non está rematado e case non é compatible:

Pero QUIC pódese implementar como un transporte entre a aplicación e o servidor, que se fixo con éxito en Uber:

Comentario de Uber sobre a introdución de QUIC

Para integrar con éxito QUIC e mellorar o rendemento das aplicacións en ambientes de conectividade pobres, substituímos a pila antiga (HTTP/2 sobre TLS/TCP) polo protocolo QUIC. Usamos a biblioteca da rede Cronet de Proxectos Chromium, que contén a versión orixinal de Google do protocolo - gQUIC. Esta implementación tamén se mellora constantemente para seguir a última especificación IETF.

Primeiro integramos Cronet nas nosas aplicacións de Android para engadir compatibilidade con QUIC. A integración levouse a cabo de xeito que se reducira ao máximo os custos migratorios. En lugar de substituír completamente a antiga pila de rede que usaba a biblioteca Ok Http, integramos Cronet BAIXO o marco da API OkHttp. Ao facer a integración deste xeito, evitamos cambios nas nosas chamadas de rede (que son utilizadas por Reformar) a nivel de API.

De xeito semellante ao enfoque dos dispositivos Android, implementamos Cronet nas aplicacións de Uber en iOS, interceptando o tráfico HTTP da rede. APIusando Protocolo NSURL. Esta abstracción, proporcionada pola Fundación iOS, xestiona os datos URL específicos do protocolo e garante que podemos integrar Cronet nas nosas aplicacións iOS sen custos de migración significativos.

tirado de esta tradución Artigos de Uber

No backend capturaron conexións QUIC a través de Google Cloud lb, que admite protocolo desde mediados de 2018.

Non é de estrañar que Google Cloud funcione moi ben co protocolo desenvolvido por Google, pero cales son as alternativas?

Nginx

Non hai moito CloudFlare Tentei cruzar nginx (que non admite HTTP/3 por defecto) coa súa ferramenta Quiche. A implementación está dispoñible como un único ficheiro .patch, que inclúe un tutorial de instalación:

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í podes conectar os teus módulos se é necesario

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

Todo o que queda é activar o soporte 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';
    }
}

Aínda non é posible conectarse a través de HTTP/3 nos navegadores habituais, pero pode usar Chrome Canary e executalo coa bandeira --enable-quic, vai ao teu servidor ou, por exemplo, ao sitio quic.rocks e mira o tipo de conexión en Ferramentas para programadores:

En lugar de HTTP/3 está escrito http2+quic/99, pero é esencialmente o mesmo.

Outras tecnoloxías

QUIC tamén admite LiteSpeed (que se conectou a Facebook a través de HTTP/3 con gran alarde) e progresivo Caddie. Apache aínda non pode facelo, pero o traballo está en marcha a tope.
21 de xaneiro actualizado borrador de estándar para WebRTC
Xusto o outro día abriu Microsoft código de implementación msquic, no que aínda non están dispoñibles todas as funcións do estándar IETF, pero este xa é un gran avance.

Conclusión

O interese polo QUIC é inestable, pero crece, e trabállase para estandarizalo. Case cada mes aparecen novas implementacións do protocolo e cada ano son máis os desenvolvedores convencidos de que QUIC é o futuro. Mesmo é posible incluír o protocolo en futuras versións da pila TCP, o que significa que tarde ou cedo toda Internet pasará a conexións máis estables e rápidas.

Agora xa podes configurar a interacción QUIC para a túa infraestrutura ou incluso entregala aos navegadores: todos eles están a planear engadir soporte para o protocolo e as tristes estatísticas con caniuse volveranse máis alegres.

Fonte: www.habr.com

HTTP sobre UDP - facendo bo uso do protocolo QUIC

Concepto

Usar

Comentario de Uber sobre a introdución de QUIC

Nginx

Outras tecnoloxías

Conclusión

Engadir un comentario Cancelar resposta