Cada requisição HTTP que sua API atende se apoia em uma camada de transporte na qual a maioria dos desenvolvedores nunca pensa. Por 25 anos, a resposta foi TCP. Então o Google se cansou de esperar o TCP melhorar, construiu o protocolo QUIC sobre o UDP, e o IETF o transformou em um padrão. HTTP/3 é a versão do HTTP construída para rodar sobre ele.
Isso parece encanamento. E, na maior parte, é. Mas esse encanamento muda a velocidade com que sua API se conecta, como ela se comporta em redes móveis instáveis e como requisições paralelas compartilham uma conexão. Se você projeta ou opera APIs, você deve saber o que mudou, o que não mudou e como verificar o que seus próprios endpoints utilizam hoje.
Uma coisa permanece constante em tudo isso: suas requisições, respostas, códigos de status e payloads JSON parecem idênticos em HTTP/1.1, HTTP/2 e HTTP/3. Ferramentas como Apidog testam e depuram na camada da API, então tudo o que você valida sobre o comportamento de um endpoint permanece verdadeiro, independentemente da versão de transporte que sua infraestrutura negocie por baixo. Se você já leu nossa análise sobre o que é HTTP/2 e como testar APIs HTTP/2, este artigo continua de onde aquele terminou.
O que é o protocolo QUIC?
QUIC é um protocolo de transporte padronizado na RFC 9000. Ele roda sobre UDP em vez de TCP, e reconstrói as funcionalidades que o TCP oferece (confiabilidade, ordenação, controle de congestionamento) no espaço do usuário, por stream, com criptografia integrada desde o primeiro pacote.
Quatro decisões de design o definem:
Ele roda sobre UDP. TCP é implementado em kernels de sistemas operacionais e middleboxes por toda a internet, o que o torna quase impossível de evoluir. UDP é um envelope fino sem garantias de entrega, então o QUIC constrói sua própria camada de confiabilidade por cima e pode entregar melhorias como atualizações de biblioteca em vez de atualizações de SO.
TLS 1.3 é integrado, não anexado. Com TCP, você completa um handshake TCP, e então um handshake TLS separado por cima. QUIC os mescla. A configuração criptográfica ocorre dentro do próprio handshake de transporte, então uma nova conexão segura está pronta após uma única viagem de ida e volta (round trip). Não existe QUIC não criptografado.
Os streams são independentes. Uma conexão QUIC transporta muitos streams, e cada um é entregue de forma independente. Um pacote perdido apenas atrasa o stream ao qual ele pertence. Esta é a solução para o bloqueio head-of-line do TCP, ao qual chegaremos em um momento.
As conexões sobrevivem a mudanças de rede. TCP identifica uma conexão por endereço IP e porta. Mude qualquer um (saia do alcance do Wi-Fi, mude para 5G) e a conexão morre. QUIC identifica as conexões por um ID de conexão em vez disso, então um cliente pode se mover para uma nova rede e manter a mesma conexão lógica ativa. Sem reconexão, sem novo handshake.
HTTP/3, definido na RFC 9114, é o mapeamento da semântica HTTP para os streams QUIC. Mesmos métodos, mesmos cabeçalhos, mesmos códigos de status. Formato de wire diferente, transporte diferente.
HTTP/3 vs HTTP/2: o que mudou na prática
HTTP/2 foi um grande avanço em relação ao HTTP/1.1. Ele introduziu o multiplexing, para que muitas requisições pudessem compartilhar uma única conexão TCP em vez de enfileirar ou abrir seis sockets paralelos. Mas ele manteve o TCP por baixo, e isso criou um problema que o HTTP/2 não conseguiu resolver sozinho.
TCP garante a entrega ordenada de um único stream de bytes. Quando um pacote é perdido, o TCP retém todos os bytes seguintes até que a retransmissão chegue, mesmo bytes pertencentes a streams HTTP/2 completamente não relacionados. Um pacote perdido paralisa todas as 20 requisições multiplexadas na conexão. Isso é bloqueio head-of-line em nível de transporte, e em uma rede com perda de pacotes, pode tornar o HTTP/2 mais lento que o HTTP/1.1 com suas múltiplas conexões.
HTTP/3 remove o stream de bytes compartilhado. Cada requisição mapeia para seu próprio stream QUIC com sua própria ordenação de entrega. Perda um pacote que transporta o stream 5, e os streams 6 a 24 continuam fluindo. O multiplexing finalmente funciona da maneira que os diagramas HTTP/2 sempre afirmaram.
A matemática do handshake também mudou:
| HTTP/2 sobre TCP+TLS 1.3 | HTTP/3 sobre QUIC | |
|---|---|---|
| Configuração de nova conexão | 2 viagens de ida e volta (TCP + TLS) | 1 viagem de ida e volta |
| Conexão retomada | 1 viagem de ida e volta | 0 viagens de ida e volta (0-RTT) |
| Impacto de pacote perdido | Bloqueia todos os streams | Bloqueia um stream |
| Troca de rede (Wi-Fi para 5G) | Conexão morre, reconexão completa | Conexão migra, continua |
| Criptografia | Opcional na teoria, camada separada | Obrigatório, TLS 1.3 integrado |
A linha 0-RTT merece uma ressalva. Quando um cliente se reconecta a um servidor que já viu antes, o QUIC permite que ele envie dados da aplicação no primeiro pacote, antes que o handshake seja concluído. Ótimo para latência. Mas dados 0-RTT podem ser capturados e repetidos por um atacante, então os servidores devem aceitar apenas requisições idempotentes em 0-RTT. Um GET repetido é inofensivo. Um POST repetido que cobra um cartão de crédito não é. Se você habilitar 0-RTT em sua borda, certifique-se de que chamadas de API não-idempotentes sejam excluídas, ou confirme se seu CDN faz isso por você.
O que HTTP/3 significa para suas APIs
Atualizações de protocolo só importam se mudam algo que você pode medir. Aqui está onde o HTTP/3 move a agulha para o tráfego de API, e onde não move.
Configuração de conexão fica mais barata
Um cliente móvel típico em uma conexão com 60 ms de RTT gasta cerca de 120 ms na configuração de TCP+TLS antes mesmo da primeira requisição de API sair do dispositivo. HTTP/3 reduz isso para cerca de 60 ms, e quase zero na retomada. Para uma API chamada de um aplicativo móvel que abre novas conexões frequentemente (inicializações a frio, ativações em segundo plano, sessões de curta duração), a economia se aplica a cada uma dessas primeiras requisições. Para uma integração server-to-server mantendo um pool de conexões 'quente', o handshake é amortizado até a irrelevância e você não notará nada.
Clientes móveis param de perder conexões
A migração de conexão é a funcionalidade 'adormecida' para as equipes de API. Um usuário inicia uma requisição no Wi-Fi do escritório, anda até o elevador, e o telefone muda para a rede celular. Sobre TCP, essa requisição em andamento falha e sua lógica de repetição no cliente (você tem lógica de repetição, certo?) entra em ação com uma reconexão completa. Sobre QUIC, a conexão segue o dispositivo para a nova rede. Menos erros de timeout em seus logs de cliente, menos gravações pela metade para analisar.
Multiplexing sem o modo de falha
Para APIs REST, a correção do bloqueio HOL importa mais quando um cliente dispara muitas requisições em paralelo: um painel atualizando 15 widgets, um motor de sincronização enviando um lote de atualizações. Em uma rede limpa, HTTP/2 e HTTP/3 se comportam de forma semelhante. Adicione 1-2% de perda de pacotes (Wi-Fi de conferência lotada, celular no metrô), e HTTP/3 mantém as requisições paralelas independentes enquanto HTTP/2 as paralisa em sincronia.
gRPC permanece majoritariamente em HTTP/2 por enquanto
gRPC é vinculado ao HTTP/2 por design; seu contrato de wire depende da estrutura e dos trailers do HTTP/2. O ecossistema gRPC não padronizou um mapeamento para HTTP/3, e as implementações principais (Go, Java, Python, Node) não o fornecem. O servidor Kestrel do .NET pode servir gRPC sobre HTTP/3 como uma capacidade experimental, mas considere isso uma exceção. Se sua arquitetura depende de gRPC e HTTP/2 para o desempenho de APIs internas, uma migração para HTTP/3 não é algo que você precise planejar este ano.
Tráfego de streaming e em tempo real
Server-Sent Events (SSE) funcionam sobre HTTP/3 inalterados, já que SSE é uma resposta HTTP comum de longa duração. WebSockets são mais complicados: a atualização do WebSocket foi projetada para TCP, e seu equivalente HTTP/3 (RFC 9220, além da emergente API WebTransport) tem suporte inconsistente. Se você está ponderando WebSockets versus HTTP puro para uma funcionalidade em tempo real, a disponibilidade do HTTP/3 ainda não deve ser o fator decisivo.
A parte honesta: quando HTTP/3 não vai ajudar
A maioria dos problemas de latência de API não tem nada a ver com o protocolo de transporte. Se seu endpoint leva 400 ms por causa de uma consulta de banco de dados sem índice, o HTTP/3 entregará essa resposta lenta 60 ms mais cedo. Cache, design de payload, consultas N+1 e reutilização de conexão dominam o desempenho real de APIs, e você deve esgotar essas opções antes de pensar no transporte. Um teste de desempenho de API estruturado geralmente revelará ganhos 10 vezes maiores do que uma atualização de protocolo.
HTTP/3 brilha em condições específicas:
- Links de alta latência, onde economizar viagens de ida e volta é um ganho percentual fixo
- Redes com perda de pacotes, onde a eliminação do bloqueio HOL se acentua
- Clientes móveis trocando de rede durante a sessão
- Muitas conexões curtas em vez de poucas longas
Para uma API JSON típica consumida por servidores na mesma região em redes confiáveis, a diferença é mensurável em benchmarks e invisível para os usuários. Duas outras notas práticas: a porta UDP 443 é bloqueada em algumas redes corporativas (os clientes automaticamente retornam ao HTTP/2, então nada quebra), e a criptografia em espaço de usuário do QUIC atualmente custa mais CPU de servidor por conexão do que o TCP de kernel ajustado.
Suporte atual: quem fala HTTP/3 hoje
A adoção está mais avançada do que a maioria dos desenvolvedores backend supõe:
- Navegadores: Chrome, Edge, Firefox e Safari vêm com HTTP/3 habilitado por padrão.
- CDNs e edges: Cloudflare, Fastly, Akamai e CloudFront o suportam; na Cloudflare, é um switch. Para a maioria das equipes, este é o caminho prático: encerrar HTTP/3 na borda, manter HTTP/1.1 ou HTTP/2 da borda para a origem.
- Servidores: Nginx adicionou HTTP/3 experimental na versão 1.25 com
listen 443 quic;. Caddy o habilita por padrão. LiteSpeed e HAProxy o suportam. Apache httpd não. - Runtimes: Node.js não tem suporte estável para servidor HTTP/3 embutido, o que é outra razão pela qual o encerramento na borda é a implantação comum.
- curl: o suporta com a flag
--http3quando compilado com uma pilha TLS compatível com HTTP/3; veja a documentação do curl HTTP/3 para saber quais builds o incluem.
Como verificar se sua API serve HTTP/3
A descoberta funciona através do cabeçalho de resposta Alt-Svc. Um servidor anunciando HTTP/3 responde à sua primeira requisição (HTTP/2) com algo como:
alt-svc: h3=":443"; ma=86400
Isso diz ao cliente: este mesmo serviço está disponível via HTTP/3 na porta UDP 443 pelas próximas 24 horas. Verifique com curl:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Para fazer a requisição diretamente via HTTP/3 (requer um build do curl com HTTP/3 habilitado):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
A linha de status reporta HTTP/3 em vez de HTTP/2. Nas Ferramentas do Desenvolvedor do Chrome, abra a aba Rede, clique com o botão direito no cabeçalho da coluna, habilite a coluna Protocolo e procure por h3 ao lado das suas chamadas de API. Em produção, adicione o protocolo negociado aos seus logs de acesso; a divisão entre o tráfego h2 e h3 informa quantos de seus clientes obtêm o benefício.
Enquanto você verifica o transporte, verifique também o comportamento. Aponte Apidog para os mesmos endpoints e verifique códigos de status, esquemas de resposta e orçamentos de latência. Ganhos em nível de transporte são inúteis se o contrato da API subjacente estiver quebrado, e as verificações de contrato são exatamente a camada onde uma mudança de protocolo não pode salvá-lo. Baixe o Apidog gratuitamente e execute o mesmo conjunto de testes antes e depois de ativar o HTTP/3 em sua borda; a diferença nos tempos de resposta em redes móveis é sua resposta do mundo real, não as manchetes de benchmark.
FAQ
HTTP/3 é mais rápido que HTTP/2?
Em redes limpas e de baixa latência: quase nada. Em redes com perda de pacotes ou de alta latência: sim, muitas vezes notavelmente, porque o HTTP/3 economiza uma viagem de ida e volta do handshake e um único pacote perdido não paralisa mais cada requisição multiplexada. Meça com seu próprio perfil de tráfego antes de reivindicar a vitória. E lembre-se, o HTTP/2 continua excelente; se você encontrar erros de conexão nele, eles geralmente são problemas da camada TLS, como o problema SSLV3_ALERT_HANDSHAKE_FAILURE, e não limites do protocolo.
HTTP/3 usa TCP?
Não. HTTP/3 roda sobre QUIC, que roda sobre UDP, tipicamente na porta 443. QUIC reimplementa a confiabilidade, ordenação e controle de congestionamento que o TCP costumava fornecer, mas por stream e no espaço do usuário. Se a porta UDP 443 estiver bloqueada em uma rede, os clientes automaticamente retornam ao HTTP/2 sobre TCP.
Preciso mudar meu código de API para HTTP/3?
Quase nunca. A semântica HTTP permanece inalterada: mesmos métodos, cabeçalhos, códigos de status e corpos. O trabalho reside na infraestrutura (habilitá-lo em seu CDN, balanceador de carga ou servidor) mais uma verificação de design: certifique-se de que os dados iniciais 0-RTT sejam restritos a requisições idempotentes.
Posso usar gRPC sobre HTTP/3?
Na maioria das vezes não, por enquanto. O formato de wire do gRPC está ligado ao HTTP/2, e as bibliotecas gRPC convencionais não fornecem transportes HTTP/3. O .NET tem suporte experimental. Mantenha os serviços gRPC em HTTP/2 e adote HTTP/3 onde ele compensa primeiro: endpoints REST públicos, voltados para navegadores e para dispositivos móveis.