QUIC (Quick UDP Internet Connections) é um protocolo baseado em UDP que suporta todos os recursos de TCP, TLS e HTTP/2 e resolve a maioria de seus problemas. Muitas vezes é chamado de protocolo novo ou “experimental”, mas sobreviveu há muito tempo à fase experimental: o desenvolvimento está em andamento há mais de 7 anos. Nesse período, o protocolo não conseguiu se tornar um padrão, mas ainda assim se difundiu. Por exemplo, o QUIC é usado por gigantes como Google e Facebook para acelerar o tráfego e reduzir atrasos em redes móveis, e a IETF declarou seu fork do protocolo como base para o padrão HTTP/3 (mesmo que HTTP/2 use locais).
Conceito
O QUIC foi desenvolvido como um substituto para o TCP legado, que foi originalmente projetado para redes com fio de baixa perda. O TCP entrega os pacotes em ordem, portanto, se um pacote for perdido, toda a fila será interrompida (), o que afeta negativamente a qualidade e estabilidade da conexão. Para evitar perdas massivas, as redes celulares recorrem ao uso de grandes buffers, o que por sua vez leva à redundância e à resposta falso negativa do protocolo (). Além disso, o TCP gasta muito tempo estabelecendo uma conexão: as solicitações SYN/ACK e TLS são processadas separadamente, exigindo três viagens de ida e volta em vez de uma, como faz o QUIC.
Como o QUIC combina uma substituição do TCP e uma 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 ele estivesse passando por HTTPS. Além disso, o QUIC é implementado no nível da aplicação, pois uma substituição completa da pilha TCP levaria eternidade.
Apesar do suporte à multiplexação em HTTP/2, o problema do bloqueio head-of-line permaneceu devido à necessidade de entregar os pacotes em ordem. O QUIC é implementado em cima do UDP, portanto, em princípio, não possui bloqueio e, para evitar que os pacotes sejam perdidos para sempre, eles são numerados e podem conter partes de “vizinhos”, proporcionando redundância. Além disso, o QUIC divide a fila monolítica em vários threads para diferentes tipos de solicitações em uma única conexão. Assim, se um pacote for perdido, podem surgir problemas apenas para uma fila (por exemplo, para transferir um arquivo específico):
Usar
Inicialmente, o QUIC foi desenvolvido dentro do Google e amplamente adaptado para uso dentro da empresa. Em 2013, foi transferido para a IETF para padronização (que ainda está em andamento), e agora todos podem participar do desenvolvimento do protocolo propondo o que falta. O grupo de trabalho da IETF organiza reuniões anuais durante as quais um novo padrão é aprovado e as inovações são discutidas. Esta implementação do QUIC é considerada a principal e é com base nela que o padrão HTTP/3 é certificado.
Até o momento não se fala em incluir o HTTP/3 como protocolo principal, pois ele ainda não está finalizado e quase não é suportado:
Mas o QUIC pode ser implementado como um transporte entre a aplicação e o servidor, o que foi feito com sucesso na Uber:
Comentário do Uber sobre a introdução do QUIC
Para incorporar o QUIC com sucesso e melhorar o desempenho do aplicativo em ambientes de baixa conectividade, substituímos a pilha antiga (HTTP/2 sobre TLS/TCP) pelo protocolo QUIC. Usamos a biblioteca de rede de , que contém a versão original do protocolo Google - gQUIC. Esta implementação também está sendo constantemente aprimorada para seguir as especificações mais recentes da IETF.
Primeiro integramos o Cronet em nossos aplicativos Android para adicionar suporte ao QUIC. A integração foi realizada de forma a reduzir ao máximo os custos de migração. Em vez de substituir completamente a antiga pilha de rede que usava a biblioteca , integramos o Cronet SOB a estrutura da API OkHttp. Fazendo a integração desta forma, evitamos alterações em nossas chamadas de rede (que são utilizadas por ) no nível da API.
Semelhante à abordagem para dispositivos Android, implementamos o Cronet em aplicativos Uber no iOS, interceptando o tráfego HTTP da rede usando . Essa 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 significativos de migração.
Tirado de Artigos Uber
No back-end, eles capturaram conexões QUIC por meio do Google Cloud lb, que desde meados de 2018.
Não é nenhuma surpresa que o Google Cloud funcione muito bem com o protocolo desenvolvido pelo Google, mas quais são as alternativas?
nginx
Não faz muito tempo, CloudFlare nginx (que não suporta HTTP/3 por padrão) 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.patchAqui você pode conectar 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
makeTudo o que resta é ativar o suporte 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';
}
}
Ainda não é possível conectar via HTTP/3 em navegadores normais, mas você pode usar e executá-lo com a bandeira --enable-quic, acesse o seu servidor ou, por exemplo, o site quic.rocks e observe o tipo de conexão nas Ferramentas do Desenvolvedor:
Em vez de HTTP/3 está escrito http2+quic/99, mas é essencialmente a mesma coisa.
Outras tecnologias
- QUIC também suporta (que se conectou ao Facebook via HTTP/3 com grande alarde) e progressivo . O Apache ainda não pode fazer isso, mas o trabalho está em andamento .
- 21 de janeiro atualizado
- Outro dia a Microsoft abriu , em que nem todas as funções do padrão IETF ainda estão disponíveis, mas isso já é um grande avanço.
Conclusão
O interesse no QUIC é instável, mas está crescendo, e estão em andamento trabalhos para padronizá-lo. Novas implementações do protocolo aparecem quase todos os meses, e a cada ano mais e mais desenvolvedores estão convencidos de que o QUIC é o futuro. É até possível incluir o protocolo em versões futuras da pilha TCP, o que significa que mais cedo ou mais tarde toda a Internet passará para conexões mais estáveis e rápidas.
Agora você já pode configurar a interação QUIC para sua infraestrutura ou até mesmo fornecê-la aos navegadores - todos estão planejando adicionar suporte ao protocolo, e as tristes estatísticas com caniuse ficarão mais alegres.
Fonte: habr.com