HTTP/3 já carrega um terço da web — e o QUIC está só começando

Cerca de 30% de todo o tráfego web agora flui sobre HTTP/3, de acordo com dados do HTTP Archive e do relatório anual Year in Review da Cloudflare. O Google atende mais de 90% de suas próprias requisições — Search, YouTube, Gmail — via QUIC. A Meta roteia a maior parte do tráfego da sua CDN da mesma forma. Fastly, Cloudflare e AWS CloudFront têm HTTP/3 habilitado por padrão. Isso não é mais um protocolo experimental. É o transporte padrão para as maiores propriedades da web, e a fatia de tráfego que ele carrega cresce cerca de 3 a 5 pontos percentuais por ano.

O Problema Que o HTTP/2 Deixou Sem Solução

O HTTP/2 chegou em 2015 e resolveu um problema real: o head-of-line blocking do HTTP/1.1 na camada de aplicação, em que uma resposta lenta travava tudo que vinha atrás na mesma conexão. O HTTP/2 introduziu multiplexação — múltiplos fluxos lógicos sobre uma única conexão TCP — e compressão de cabeçalhos via HPACK. Os tempos de carregamento de página melhoraram de forma mensurável, especialmente em links de alta latência.

Mas o HTTP/2 manteve o TCP como camada de transporte, e o TCP tem seu próprio problema de head-of-line blocking que a multiplexação não consegue corrigir. O TCP garante entrega ordenada: se um segmento é perdido, todos os segmentos subsequentes — mesmo aqueles pertencentes a fluxos HTTP/2 completamente independentes — precisam esperar a retransmissão do segmento perdido antes que o TCP os entregue à aplicação. Em uma conexão com 1% de perda de pacotes, isso pode travar múltiplos fluxos de recursos independentes simultaneamente. Em uma rede móvel com 2–3% de perda de pacotes (típico para LTE na borda da cobertura), o impacto de latência se agrava severamente.

Os handshakes TLS eram o segundo problema. HTTP/2 sobre TLS 1.2 exigia 2 round trips (RTTs) antes que qualquer dado de aplicação pudesse fluir — um para o SYN/SYN-ACK/ACK do TCP, outro para a negociação TLS. Em uma conexão móvel com 80ms de RTT, são 160ms de overhead de configuração antes do primeiro byte de conteúdo. O TLS 1.3 reduziu isso para 1-RTT, mas o handshake triplo do TCP permaneceu inevitável. A migração de conexão — o que acontece quando você sai do Wi-Fi para o celular — significava que as conexões TCP quebravam e precisavam recomeçar do zero.

O Que o QUIC Realmente É

O QUIC é um protocolo de transporte que roda sobre UDP. Foi projetado pelo Google em 2012, implantado internamente por volta de 2013 e padronizado pela IETF como RFC 9000 em maio de 2021. O HTTP/3 (RFC 9114) é simplesmente a semântica do HTTP sobre o QUIC, em vez do TCP.

As principais decisões arquiteturais no QUIC:

• Multiplexação baseada em UDP com fluxos independentes: O QUIC implementa multiplexação de fluxos na camada de transporte, não na camada de aplicação. Cada fluxo tem seu próprio controle de fluxo e recuperação de perdas. Um pacote perdido afeta apenas o fluxo ao qual pertence — outros fluxos continuam entregando dados sem interrupção. Isso elimina o head-of-line blocking do TCP no nível de transporte.
• TLS 1.3 embutido: O QUIC não coloca TLS sobre o transporte; o TLS 1.3 é parte integrante do protocolo. O handshake e a negociação de criptografia acontecem simultaneamente com o estabelecimento da conexão. Uma nova conexão QUIC requer 1-RTT antes que os dados da aplicação fluam — um round trip a menos que TLS 1.2 sobre TCP.
• Retomada de conexão 0-RTT: Quando um cliente se reconecta a um servidor com o qual já se comunicou antes, o QUIC pode enviar dados de aplicação com o primeiro pacote usando o modo 0-RTT. O cliente usa os dados do ticket de sessão da conexão anterior para criptografar a requisição imediatamente. Em uma reconexão móvel típica — alternando entre Wi-Fi e celular — isso significa que a primeira requisição HTTP pode sair antes que o handshake seja concluído, reduzindo a latência percebida para perto de zero em visitas repetidas.
• Migração de conexão: O QUIC identifica conexões com um Connection ID de 64 bits, não com uma tupla de 4 endereços IP e portas. Quando seu dispositivo muda de endereço IP — saindo do Wi-Fi para o 5G, ou alternando entre torres de celular — a conexão QUIC continua sem interrupção. Nenhum reset TCP, nenhum novo handshake, nenhum fluxo descartado. O servidor recebe pacotes do novo endereço IP referenciando o mesmo Connection ID e continua perfeitamente.

Evidências de Performance: O Que os Números Mostram

Os ganhos de performance do QUIC são mais pronunciados sob duas condições: alta perda de pacotes e transições frequentes de rede. O Google publicou resultados internos de testes A/B mostrando que o QUIC reduziu a latência de busca em 8% na mediana e em até 28% no percentil 99 (latência de cauda) em comparação com HTTPS sobre TCP. Os dados do QUIC no YouTube mostraram uma redução de 15% nos eventos de rebuffering.

Os benchmarks de 2023 da Cloudflare em HTTP/3 vs HTTP/2 em uma rede simulada com 1% de perda de pacotes mostraram melhorias medianas no tempo de carregamento de página de 12 a 18% para páginas com muitos recursos. Com 3% de perda de pacotes — realista para redes móveis congestionadas — a melhoria cresceu para 25 a 35%. Em uma conexão limpa e de baixa latência com 0% de perda de pacotes, a diferença de performance entre HTTP/2 e HTTP/3 é pequena (abaixo de 5%), porque o head-of-line blocking do TCP só se manifesta quando segmentos são perdidos.

O benefício da retomada 0-RTT é mais difícil de isolar, mas mensurável. A Meta relatou que habilitar 0-RTT para visitantes recorrentes em sua CDN reduziu o time-to-first-byte (TTFB) em 30 a 60ms em conexões móveis, o que se traduz diretamente em pontuações mais rápidas de Largest Contentful Paint (LCP) — o Core Web Vital mais correlacionado com a experiência do usuário e o ranking de busca do Google.

Uma ressalva: o 0-RTT carrega uma vulnerabilidade de replay. Um invasor que capture dados 0-RTT pode reproduzi-los para enviar requisições duplicadas. É por isso que o 0-RTT é seguro para requisições idempotentes (GET, HEAD), mas deve ser desabilitado ou tratado com cuidado para operações que alteram estado (POST, pagamentos). Implementações modernas de servidor lidam com isso automaticamente, mas vale a pena saber que a restrição existe.

Quem Roda HTTP/3 Hoje

O cenário de adoção em meados de 2026 é substancial:

• Cloudflare: HTTP/3 habilitado por padrão para todos os clientes desde 2020. A Cloudflare também opera uma das implementações QUIC mais usadas (quiche), que é open-source e usada pelo Firefox e outros projetos.
• Google: Roda QUIC internamente para Search, YouTube, Gmail, Google Drive e Maps. O navegador Chrome oferece suporte QUIC desde 2015. A implementação QUIC do Google (quic-go e o cronet em C++) é a implementação de referência para grande parte do ecossistema.
• Meta: Roda HTTP/3 para Facebook, Instagram e tráfego CDN do WhatsApp. A Meta mantém sua própria implementação QUIC (mvfst), com código aberto em 2019, usada em produção na escala de bilhões de usuários.
• Fastly, Akamai, AWS CloudFront: Todos oferecem HTTP/3 como opção de CDN, com a Fastly habilitando por padrão desde 2022.

No lado do software de servidor: nginx adicionou suporte a QUIC/HTTP/3 na v1.25.0 (lançada em junho de 2023) como um recurso estável. Caddy tem HTTP/3 habilitado por padrão desde a v2.4. LiteSpeed e sua variante open-source OpenLiteSpeed têm suporte a HTTP/3 desde 2020. Apache httpd oferece HTTP/3 via módulo mod_quic, ainda experimental no Apache 2.4.55. O servidor H2O tem suporte QUIC. Node.js possui uma API QUIC experimental. O runtime Deno suporta HTTP/3 nativamente.

O Que os Desenvolvedores Web Precisam Fazer

Para a maioria dos desenvolvedores que usam uma CDN ou balanceador de carga em nuvem, o HTTP/3 já está ativo — verifique, não habilite. Se você gerencia sua própria infraestrutura de servidor, aqui está o caminho prático:

Verifique se HTTP/3 está ativo:

• Use curl --http3 https://seudominio.com -I e verifique se HTTP/3 aparece na linha de resposta. Requer curl compilado com suporte QUIC (curl --version | grep HTTP3).
• No Chrome DevTools: abra o painel Network, clique com o botão direito nos cabeçalhos das colunas, habilite "Protocol". Conexões HTTP/3 aparecem como h3. HTTP/2 aparece como h2.
• O Firefox DevTools mostra o mesmo na coluna Protocol do painel Network.
• O verificador quic.cloud da Cloudflare e a ferramenta http3check.net fornecem verificação externa rápida.

Habilite HTTP/3 no nginx (1.25+): Adicione listen 443 quic reuseport; junto com sua diretiva listen 443 ssl; existente, depois adicione add_header Alt-Svc 'h3=":443"; ma=86400'; para anunciar QUIC aos navegadores. O cabeçalho Alt-Svc é como os clientes descobrem que HTTP/3 está disponível — a primeira conexão usará HTTP/2, e as conexões subsequentes farão upgrade para HTTP/3.

Habilite HTTP/3 no Caddy: Nada para configurar — o Caddy ativa HTTP/3 por padrão quando TLS está ativo. Confirme pela coluna Protocol do DevTools.

A configuração de firewall é um bloqueio comum: O QUIC roda na porta UDP 443. Muitos firewalls corporativos bloqueiam ou limitam o tráfego UDP. Se HTTP/3 falhar na negociação, os navegadores voltam automaticamente para HTTP/2 — os usuários finais não veem erros, mas também não obtêm QUIC. Se você estiver depurando por que HTTP/3 não está sendo usado em uma rede específica, verifique se UDP/443 está aberto.

Não ajuste manualmente o controle de congestionamento para QUIC ainda. As implementações QUIC usam BBR (Bottleneck Bandwidth and RTT) como controle de congestionamento padrão, que supera o CUBIC (padrão do TCP) na maioria das redes modernas. A menos que você tenha problemas de performance específicos e medidos, os padrões estão corretos.

0-RTT: A maioria das implementações de servidor ativa 0-RTT para requisições GET automaticamente. Se sua aplicação emite operações de mudança de estado no carregamento da página (incomum, mas possível), audite esses tipos de requisição. A orientação padrão é tratar dados 0-RTT como potencialmente reproduzidos e projetar de acordo — use tokens idempotentes ou verifique o estado na camada de aplicação.

O Caminho à Frente

HTTP/3 e QUIC não pararam de evoluir. A versão 2 do QUIC (RFC 9369, publicada em 2023) adiciona melhorias na migração de conexão e introduz um novo mecanismo de negociação de versão. O WebTransport — uma API de navegador que expõe fluxos e datagramas QUIC diretamente ao JavaScript — está sendo lançado no Chrome e Firefox, possibilitando comunicação bidirecional de baixa latência sem o overhead do WebSocket. O MASQUE (Multiplexed Application Substrate over QUIC Encryption), um protocolo do grupo de trabalho da IETF, constrói tunelamento similar a VPN sobre QUIC e já está implantado no iCloud Private Relay.

Para o desenvolvedor web que entende TCP e HTTP, o QUIC é o mesmo problema resolvido corretamente: entrega confiável e ordenada onde é necessária (por fluxo), sem a restrição de ordenação global que torna o TCP patológico em links com perda. O protocolo é estável, as ferramentas existem e as evidências de performance são inequívocas. Se seu tráfego passa por uma CDN moderna, seus usuários já estão se beneficiando. Se não passa, o caminho de upgrade é uma única linha de configuração do nginx.