HTTP sobre UDP — aproveitando o protocolo QUIC

QUIC (Quick UDP Internet Connections) é um protocolo sobre UDP que suporta todas as funcionalidades do TCP, TLS e HTTP/2 e resolve a maioria de seus problemas. É frequentemente chamado de novo ou "experimental", mas já passou há muito tempo da fase de experimento: o desenvolvimento está em andamento há mais de 7 anos. Durante esse tempo, o protocolo não se tornou um padrão, mas ainda assim ganhou uma ampla adoção. Por exemplo, QUIC é utilizado para acelerar o tráfego e reduzir a latência em redes móveis por gigantes como Google e Facebook, e o IETF anunciou seu fork como a base para o padrão HTTP/3 (considerando que o HTTP/2 utiliza apenas 44,8% dos sites).

Conceito

QUIC foi desenvolvido como uma alternativa ao antigo TCP, que foi originalmente projetado para redes com fio com uma baixa taxa de perda. O TCP entrega pacotes em ordem, portanto, quando um pacote é perdido, toda a fila (head-of-line blocking) é interrompida, o que impacta negativamente a qualidade e a estabilidade da conexão. Para evitar perdas massivas, as redes celulares fazem uso de grandes buffers, o que, por sua vez, leva a redundância e reações false negative do protocolo (bufferbloat). Além disso, o TCP gasta muito tempo estabelecendo a conexão: as solicitações SYN/ACK e TLS ocorrem separadamente, exigindo três roundtrips em vez de um, como faz o QUIC.

Como o QUIC combina a substituição do TCP e a implementação do TLS 1.3, todas as conexões são sempre criptografadas, e descriptografar esse tráfego não é mais fácil do que se estivesse passando por HTTPS. Além disso, o QUIC é implementado em nível aplicativo, pois uma substituição completa da pilha TCP levaria uma eternidade..

Apesar do suporte a multiplexação no HTTP/2, o problema de head-of-line blocking persiste devido à necessidade de entregar pacotes em ordem. O QUIC é implementado sobre UDP, portanto, não apresenta bloqueios nesse sentido, e para garantir que os pacotes não sejam perdidos irreversivelmente, eles são numerados e podem conter partes de "vizinhos", garantindo redundância. Além disso, o QUIC divide a fila monolítica em vários streams para diferentes tipos de solicitações dentro de uma única conexão. Assim, em caso de perda de um pacote, os problemas podem ocorrer apenas em uma fila (por exemplo, na transmissão de um arquivo específico):

Uso

Inicialmente, o QUIC foi desenvolvido internamente no Google e foi muito adaptado para uso na empresa. Em 2013, ele foi transferido para a IETF para padronização (que ainda está em andamento), e agora qualquer um pode participar do desenvolvimento do protocolo, sugerindo o que lhe falta. O grupo de trabalho da IETF organiza anualmente reuniões nas quais um novo padrão é aprovado e as novidades são discutidas. Esta implementação do QUIC é considerada a principal e é com base nela que o padrão HTTP/3 é certificado.

Até agora, não se fala em incluir o HTTP/3 como protocolo principal, pois ele ainda não está concluído e quase não é suportado:

Mas o QUIC pode ser implementado como transporte entre o aplicativo e o servidor, algo que a Uber fez com sucesso:

Comentário da Uber sobre a implementação do QUIC

Para integrar com sucesso o QUIC e melhorar o desempenho do aplicativo em condições de conexão ruim, substituímos a pilha antiga (HTTP/2 sobre TLS/TCP) pelo protocolo QUIC. Utilizamos a biblioteca de rede Cronet do Chromium Projects, que contém a versão original do protocolo desenvolvida pelo Google – gQUIC. Esta implementação também está sempre sendo aprimorada para seguir a última especificação da IETF.

Primeiro, integramos o Cronet em nossos aplicativos Android para adicionar suporte ao QUIC. A integração foi feita de tal forma a minimizar os custos de migração. Em vez de substituir completamente a pilha de rede antiga, que usava a biblioteca OkHttp, integramos o Cronet SOB o framework OkHttp API. Ao realizar a integração dessa forma, evitamos mudanças em nossas chamadas de rede (que usam Retrofit) no nível da API.

Semelhante à abordagem em dispositivos Android, implementamos o Cronet em aplicativos da Uber para iOS, interceptando o tráfego HTTP das redes API, usando NSURLProtocol. Esta abstração, fornecida pela iOS Foundation, lida com dados de URL específicos do protocolo e garante que possamos integrar o Cronet em nossos aplicativos iOS sem custos de migração significativos.

retirado de esta tradução do artigo da Uber

No backend, eles capturavam conexões QUIC através do Google Cloud lb, que suporta o protocolo desde meados de 2018.

Não é surpreendente que o Google Cloud funcione perfeitamente com um protocolo desenvolvido pelo Google, mas quais são as alternativas?

Nginx

Não muito tempo atrás, a CloudFlare tentou cruzar nginx (que por padrão não suporta HTTP/3) com sua ferramenta Quiche. A implementação está disponível como um único arquivo .patch, que vem com um tutorial de instalação:

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

Aqui você pode adicionar seus módulos, se necessário

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

Resta apenas habilitar o suporte ao HTTP/3

events {
    worker_connections  1024;
}

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

        # Ative HTTP/2 (opcional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Habilite todas as versões do TLS (TLSv1.3 é necessário para QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # O buffer de solicitação está atualmente desabilitado para HTTP/3.
        proxy_request_buffering off;

        # Adicione cabeçalho Alt-Svc para negociar HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

Comum em navegadores, não será possível se conectar via HTTP/3 por enquanto, mas você pode usar Chrome Canary e executá-lo com a flag --enable-quic, conectando-se ao seu servidor ou, por exemplo, ao site quic.rocks e verificar o tipo de conexão nas Ferramentas de Desenvolvedor:

Em vez de HTTP/3, aparece http2+quic/99, mas na verdade é a mesma coisa.

Outras tecnologias

• QUIC também é suportado por LiteSpeed (que se conectaram de forma grandiosa ao Facebook via HTTP/3) e o progressivo Caddy. O Apache ainda não suporta, mas o trabalho está em andamento.
• Em 21 de janeiro, foi atualizado o rascunho do padrão para WebRTC
• Recentemente, a Microsoft abriu o código de sua implementação msquic, que ainda não oferece todos os recursos do padrão IETF, mas já é um grande avanço.

Conclusão

O interesse por QUIC é instável, mas crescente, e o trabalho em sua padronização está em andamento. Novas implementações do protocolo estão surgindo quase todos os meses, e a cada ano mais desenvolvedores se convencem de que o futuro pertence ao QUIC. Há até a possibilidade de incluir o protocolo nas futuras versões do stack TCP, o que significa que, cedo ou tarde, toda a internet migrará para conexões mais estáveis e rápidas.

Já é possível configurar a interação QUIC para sua infraestrutura ou até mesmo entregá-la aos navegadores — todos planejam adicionar suporte ao protocolo, e a triste estatística de caniuse se tornará mais animadora.

Fonte: habr.com