HTTP/2 versus HTTP/3 O Que realmente mudou (e se seu API se importa)

Resposta curta: se você está atrás de um CDN, provavelmente o HTTP/3 já está sendo tratado para você e não há nada a configurar. Se você está rodando seu próprio servidor, o HTTP/2 cobre o caso de 95% e o HTTP/3 é uma atualização útil, mas não urgente.

Aqui está a versão mais longa, porque a engenharia por trás da diferença é realmente interessante — e saber isso ajuda você a tomar decisões melhores sobre onde a versão do protocolo realmente importa.

O que o HTTP/2 realmente resolveu

O HTTP/1.1 tinha dois problemas que o HTTP/2 resolveu adequadamente.

Muitas conexões TCP para carregar uma única página. Os navegadores abriam 6 a 8 conexões TCP por origem apenas para carregar ativos em paralelo. Cada conexão tem custo de setup (handshake TCP, negociação TLS), e esse método era ineficiente em grande escala. O HTTP/2 substituiu isso com multiplexação: uma conexão TCP, múltiplos fluxos de solicitação/resposta rodando em paralelo. Mais nenhum juggle de conexões.

Cabeçalhos redundantes em cada solicitação. No HTTP/1.1, cada solicitação enviava seus cabeçalhos completos — User-Agent, Accept-Encoding, Authorization, todos eles — mesmo quando nada mudava em relação à solicitação anterior. O compressão HPACK do HTTP/2 deduplica cabeçalhos mantendo uma tabela de busca compartilhada entre cliente e servidor. Em uma API onde você envia o mesmo Authorization: Bearer ... token em cada chamada, isso reduz significativamente o custo em tráfego de alto volume.

O server push era suposto ser um terceiro ganho (enviando recursos que o cliente precisaria antes de pedir), mas nunca funcionou bem na prática. O Chrome eliminou o suporte em 2022. Trate como descontinuado e não construa nada com base nele.

O problema que o HTTP/2 não conseguiu resolver

Aqui está a parte que muitas vezes é ignorada: a multiplexação sobre TCP tem um teto rígido. Quando um pacote TCP é perdido durante a transmissão, o TCP pausa toda a conexão até que o pacote seja retransmitido e reconhecido. Todos os seus fluxos HTTP/2 paralelos — independentemente de qual um o pacote perdido pertencia — ficam inativos esperando. Isso é bloqueio de cabeça de linha (HOL) no nível TCP, e não é um erro no HTTP/2 — é como o TCP funciona.

Em uma conexão com cabo confiável, a taxa de perda de pacotes é baixa o suficiente para que isso raramente cause problemas. Mas em redes móveis, links por satélite ou qualquer caminho com perda significativa de pacotes, a vantagem de multiplexação do HTTP/2 desaparece. Você pode ter 20 fluxos multiplexados em uma conexão, e um único pacote perdido trava todos os 20. 😬

Isso não é uma limitação corrigível. É estrutural ao construir um protocolo de multiplexação de requisições sobre um transporte de byte-stream que não sabe o que é um "fluxo".

O que o HTTP/3 realmente mudou

O HTTP/3 não apenas ajusta o formato de quadros ou adiciona uma nova bandeira de funcionalidade. Ele substitui o TCP pelo QUIC — um protocolo de transporte que opera sobre UDP.

O QUIC trata a multiplexação no nível de transporte, então um pacote perdido só bloqueia o fluxo a que pertence, não todos os outros fluxos na conexão. O problema de bloqueio de cabeça de linha é resolvido no nível certo da pilha. Isso é o essencial.

Alguns outros benefícios que o QUIC traz:

• Migração de conexão. O QUIC identifica conexões por um ID de conexão, e não por uma tupla de 4 elementos: IP de origem, porta de origem, IP de destino, porta de destino. Mude do Wi-Fi para a rede celular durante uma transferência e a conexão sobrevive. Isso importa para aplicações móveis; para chamadas de API entre servidores, é quase irrelevante.
• Negociação 0-RTT. Para conexões com servidores conhecidos, o QUIC pode pular a negociação TLS de um round-trip e enviar dados imediatamente. Ganho real de latência em reestabelecimentos. Observação: a negociação 0-RTT tem uma limitação de ataque de replay — não use para endpoints não idempotentes sem entender os trade-offs.
• TLS 1.3 obrigatório. O QUIC não suporta conexões sem criptografia. Sem TLS, não há HTTP/3, ponto final.

A compressão de cabeçalhos também mudou: o HTTP/3 usa QPACK em vez de HPACK. A diferença é técnica — o QPACK evita um problema de bloqueio no HPACK quando cabeçalhos são comprimidos entre fluxos. Na prática, você não observará diferença; é uma melhoria de infraestrutura.

Comparação de funcionalidades

Recurso	HTTP/1.1	HTTP/2	HTTP/3
Protocolo de transporte	TCP	TCP	QUIC (UDP)
Multiplexação de requisições	Não (várias conexões)	Sim	Sim
Bloqueio de cabeça de linha	Nível de requisição	Nível de TCP (ainda presente)	Nenhum
Compressão de cabeçalhos	Nenhum	HPACK	QPACK
TLS obrigatório	Não	Não (especificação), sim (navegadores)	Sim (obrigatório)
Negociação 0-RTT	Não	Não	Sim
Migração de conexão	Não	Não	Sim
Server push	Não	Sim (descontinuado)	Não (removido)

O que isso significa para a latência de API

O HTTP/3 ajuda principalmente em condições específicas. Ele não melhora universalmente tudo.

Redes com perda de pacotes. Clientes móveis que acessam sua API por LTE ou 5G com cobertura subóptima verão uma melhoria mensurável. Chamadas de API entre datacenters em uma rede privada confiável com perda de pacotes praticamente nula? A diferença é insignificante.

Conexões frias e reestabelecimentos. Se seus clientes de API se reconectarem com frequência — funções serverless de curta duração, reinícios de aplicativos móveis, contêineres temporários — o 0-RTT reduz o custo de setup. Conexões de longa duração que permanecem abertas por minutos não obtêm benefício disso.

O volume de requisições importa. O HTTP/2 e o HTTP/3 brilham quando um cliente faz muitas requisições paralelas. Um navegador carregando 80 ativos em paralelo vê ganhos grandes com multiplexação. Uma API REST fazendo 3 requisições sequenciais vê ganhos muito menores. Quanto mais requisições paralelas seu cliente faz, mais a melhoria do transporte importa.

Como os CDNs lidam com isso

O Cloudflare suporta o HTTP/3 desde 2019 e ativa por padrão. O AWS CloudFront adicionou suporte em 2022. O Fastly, o Akamai, o BunnyCDN — todos os suportam.

A arquitetura importa aqui: seu CDN termina a conexão do cliente em sua borda. Mesmo quando um cliente se conecta ao seu CDN usando HTTP/3 com QUIC, o trecho CDN para origem é quase certamente HTTP/1.1 ou HTTP/2 sobre TCP. Portanto, "ativar o HTTP/3" no seu CDN não exige nenhuma mudança no seu servidor de origem.

Se você estiver no Cloudflare, verifique suas configurações de Speed → Optimization — o HTTP/3 (com QUIC) é um interruptor que está ativo por padrão para a maioria das zonas. Outros CDNs variam. Essa é a mudança de maior impacto que a maioria das equipes pode fazer: sem mudanças no servidor de origem, benefício imediato para clientes em redes móveis ou de alta latência.

Você realmente precisa fazer algo?

Atrás de um CDN: Verifique se o HTTP/3 está ativado e continue. Leva 30 segundos.

Rodando seu próprio nginx: O HTTP/3 exige nginx 1.25+ (a rama principal — a estável está atrás no QUIC). Você precisará do --with-http_v3_module flag de compilação e uma listen 443 quic reuseport directiva ao lado do seu listener TCP existente. Certifique-se de que a porta UDP 443 esteja aberta no seu firewall — algumas configurações de rede bloqueiam isso. Faça isso se você estiver servindo usuários móveis; não vale a pena a interrupção da atualização se você estiver apenas lidando com tráfego entre servidores.

Usando Caddy: O HTTP/3 está ativado por padrão sem configuração. Nada a fazer.

Construindo um cliente que chama APIs de terceiros: Se você conseguir o HTTP/3 depende do servidor que você está chamando, não do seu código. O curl suporta o HTTP/3 a partir da versão 7.86.0 com um backend compatível (nghttp3 ou quiche). A maioria das bibliotecas de cliente HTTP em Python e Node ainda não suporta o HTTP/3 nativamente. O padrão do Go net/http não o suporta; há uma biblioteca separada se você precisar. quic-go Uma observação prática: se você estiver testando qual versão do HTTP o servidor realmente negocia, ou construindo comandos curl com

flags, --http3 no iotools.cloud é útil para construir o comando certo sem precisar procurar a sintaxe exata de cada flag. Construtor de Comandos cURL HTTP/2 versus HTTP/3: O que realmente mudou (e se sua API se importa) 2

Você também pode gostar