O que é HTTP/3 (QUIC) e qual seu impacto nas suas APIs

HTTP/3 para APIs: o que muda com QUIC e como verificar

Cada requisição HTTP depende de uma camada de transporte que muitos desenvolvedores não acompanham. Por 25 anos, essa camada foi o TCP. Depois, o Google criou o QUIC sobre UDP, e o IETF o padronizou. O HTTP/3 é a versão do HTTP construída para rodar sobre QUIC.

Experimente o Apidog hoje

Isso pode parecer apenas infraestrutura, mas afeta:

• A velocidade de conexão da sua API.
• O comportamento em redes móveis instáveis.
• A forma como requisições paralelas compartilham uma conexão.
• A recuperação após a troca entre Wi-Fi e rede celular.

A semântica da API permanece igual em HTTP/1.1, HTTP/2 e HTTP/3: requisições, respostas, códigos de status e payloads JSON não mudam. Ferramentas como o Apidog continuam testando a API na mesma camada, independentemente do protocolo de transporte negociado.

Se você já conhece HTTP/2 e como testar APIs HTTP/2, este artigo mostra o que o HTTP/3 muda na prática.

O que é QUIC?

QUIC é um protocolo de transporte padronizado na RFC 9000. Ele roda sobre UDP e reimplementa, no espaço do usuário, recursos tradicionalmente fornecidos pelo TCP: confiabilidade, ordenação e controle de congestionamento.

O QUIC também oferece esses recursos por stream e inclui criptografia desde o primeiro pacote.

1. QUIC roda sobre UDP

O TCP é implementado nos kernels dos sistemas operacionais e em middleboxes espalhados pela internet, o que dificulta sua evolução. O UDP é um envelope simples, sem garantia de entrega. O QUIC constrói sua própria camada de confiabilidade sobre ele e pode evoluir por meio de atualizações de bibliotecas, sem depender de atualizações do sistema operacional.

2. TLS 1.3 é integrado

Com TCP, o cliente conclui primeiro o handshake TCP e depois executa um handshake TLS. O QUIC combina essas etapas.

Uma nova conexão segura normalmente fica pronta após uma viagem de ida e volta (round trip). Não existe QUIC não criptografado.

3. Os streams são independentes

Uma conexão QUIC pode transportar vários streams, cada um com entrega independente. Se um pacote for perdido, apenas o stream ao qual ele pertence precisa aguardar a retransmissão.

Essa característica elimina o bloqueio head-of-line (HOL) no nível do transporte.

4. As conexões sobrevivem à troca de rede

O TCP identifica uma conexão pelo endereço IP e pela porta. Quando o dispositivo troca de Wi-Fi para 5G, a conexão morre e precisa ser refeita.

O QUIC usa um ID de conexão. Assim, o cliente pode mudar de rede e manter a mesma conexão lógica ativa, sem reconexão nem novo handshake.

O HTTP/3, definido na RFC 9114, mapeia a semântica HTTP para os streams QUIC:

• Mesmos métodos.
• Mesmos cabeçalhos.
• Mesmos códigos de status.
• Formato de transmissão e transporte diferentes.

HTTP/3 versus HTTP/2: o que mudou?

O HTTP/2 introduziu multiplexing: várias requisições passaram a compartilhar uma conexão TCP, em vez de ficarem enfileiradas ou abrirem vários sockets paralelos.

O problema é que o TCP mantém um único stream ordenado de bytes. Quando um pacote é perdido, todos os bytes seguintes ficam retidos até a retransmissão, mesmo que pertençam a streams HTTP/2 não relacionados.

Consequentemente, um pacote perdido pode paralisar todas as requisições multiplexadas na conexão. Em redes com perda de pacotes, o HTTP/2 pode até ser mais lento que o HTTP/1.1 usando várias conexões.

O HTTP/3 remove esse stream de bytes compartilhado. Cada requisição é associada a um stream QUIC independente. Se um pacote do stream 5 for perdido, os streams 6 a 24 continuam fluindo.

Comparação prática

Aspecto	HTTP/2 sobre TCP + TLS 1.3	HTTP/3 sobre QUIC
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 com 0-RTT
Pacote perdido	Bloqueia todos os streams	Bloqueia apenas um stream
Troca de Wi-Fi para 5G	Conexão morre e precisa ser refeita	Conexão migra e continua
Criptografia	Camada separada, opcional na teoria	TLS 1.3 integrado e obrigatório

Atenção ao 0-RTT

Quando um cliente se reconecta a um servidor conhecido, o QUIC pode permitir que dados da aplicação sejam enviados no primeiro pacote, antes do handshake terminar.

Isso reduz a latência, mas dados 0-RTT podem ser capturados e repetidos por um atacante. Por isso, servidores devem aceitar apenas requisições idempotentes nesse modo.

• Repetir um GET normalmente é seguro.
• Repetir um POST que cobra um cartão pode gerar uma operação duplicada.

Se você habilitar 0-RTT na borda:

1. Restrinja dados iniciais a operações idempotentes.
2. Exclua chamadas não idempotentes.
3. Confirme se o seu CDN aplica essa política automaticamente.

O que o HTTP/3 muda para suas APIs?

A atualização só importa quando produz um ganho mensurável. Estes são os cenários em que o HTTP/3 pode fazer diferença.

Conexões ficam mais baratas

Em uma conexão móvel com 60 ms de RTT, TCP + TLS consome cerca de 120 ms antes que a primeira requisição da API saia do dispositivo.

O HTTP/3 reduz essa configuração para aproximadamente 60 ms e pode se aproximar de zero em conexões retomadas.

Isso é relevante para:

• Inicializações a frio de aplicativos móveis.
• Aplicativos que acordam em segundo plano.
• Sessões curtas.
• Clientes que abrem conexões com frequência.

Em integrações servidor a servidor que mantêm um pool de conexões aquecido, o handshake é amortizado e o ganho tende a ser irrelevante.

Clientes móveis perdem menos conexões

Considere este fluxo:

1. O usuário inicia uma requisição no Wi-Fi.
2. Entra no elevador.
3. O dispositivo muda para a rede celular.
4. A requisição ainda está em andamento.

Com TCP, a requisição pode falhar e o cliente precisa reconectar. Com QUIC, a conexão pode migrar para a nova rede.

O resultado esperado é menos timeouts no cliente e menos operações parcialmente gravadas para investigar.

Multiplexing sem o mesmo modo de falha

A eliminação do bloqueio HOL é especialmente útil quando o cliente dispara várias requisições em paralelo:

• Um painel atualizando 15 widgets.
• Um mecanismo de sincronização enviando um lote de atualizações.
• Uma aplicação móvel carregando vários recursos simultaneamente.

Em uma rede estável, HTTP/2 e HTTP/3 têm comportamento semelhante. Com 1% ou 2% de perda de pacotes — por exemplo, em um Wi-Fi congestionado ou no metrô — o HTTP/3 mantém as requisições independentes, enquanto o HTTP/2 pode paralisá-las em conjunto.

gRPC continua majoritariamente no HTTP/2

O gRPC foi projetado em torno do HTTP/2. Seu contrato de transmissão depende da estrutura e dos trailers do HTTP/2.

O ecossistema gRPC ainda não padronizou um mapeamento para HTTP/3, e as principais implementações — Go, Java, Python e Node — não oferecem esse transporte de forma convencional.

O Kestrel do .NET pode servir gRPC sobre HTTP/3 experimentalmente, mas isso ainda é uma exceção. Se sua arquitetura usa gRPC e HTTP/2 para APIs internas, uma migração para HTTP/3 provavelmente não é prioridade imediata. Consulte também esta análise sobre gRPC e HTTP/2 para desempenho de APIs internas.

Streaming e tempo real

Server-Sent Events (SSE) funcionam sobre HTTP/3 sem alterações, porque são respostas HTTP comuns de longa duração.

WebSockets são mais complicados. A atualização tradicional do WebSocket foi projetada para TCP, e o equivalente para HTTP/3 — RFC 9220, além da emergente API WebTransport — ainda tem suporte inconsistente.

Ao avaliar WebSockets versus HTTP puro, a disponibilidade do HTTP/3 não deve ser o fator decisivo.

Quando o HTTP/3 não vai ajudar

A maioria dos problemas de latência de uma API não está no transporte.

Se um endpoint leva 400 ms por causa de uma consulta sem índice, o HTTP/3 apenas entregará a mesma resposta lenta cerca de 60 ms mais cedo. Antes de trocar o protocolo, priorize:

• Cache.
• Reutilização de conexões.
• Consultas SQL eficientes.
• Eliminação de consultas N+1.
• Payloads menores.
• Compressão.
• Um teste estruturado de desempenho de API.

O HTTP/3 tende a brilhar em:

• Links de alta latência.
• Redes com perda de pacotes.
• Clientes móveis que trocam de rede.
• Muitas conexões curtas.
• Requisições paralelas em redes instáveis.

Para uma API JSON consumida por servidores na mesma região, em redes confiáveis, a diferença pode aparecer em benchmarks, mas ser imperceptível para os usuários.

Também considere:

• Algumas redes corporativas bloqueiam a porta UDP 443. Os clientes normalmente retornam automaticamente ao HTTP/2, sem quebrar a aplicação.
• A criptografia em espaço de usuário do QUIC pode consumir mais CPU por conexão do que um TCP de kernel ajustado.

Suporte atual: quem usa HTTP/3?

A adoção está mais avançada do que muitos times de backend imaginam.

• Navegadores: Chrome, Edge, Firefox e Safari oferecem HTTP/3 habilitado por padrão.
• CDNs e edges: Cloudflare, Fastly, Akamai e CloudFront oferecem suporte. Na Cloudflare, a ativação é feita por um switch.
• Arquitetura mais comum: encerrar HTTP/3 na borda e manter HTTP/1.1 ou HTTP/2 entre a borda e a origem.
• Nginx: oferece suporte experimental desde a versão 1.25, com listen 443 quic;.
• Caddy: habilita HTTP/3 por padrão.
• LiteSpeed e HAProxy: oferecem suporte.
• Apache httpd: não oferece suporte nativo.
• Node.js: ainda não possui suporte estável embutido para servidor HTTP/3, outro motivo para preferir o encerramento na borda.
• curl: oferece HTTP/3 com --http3, quando compilado com uma pilha TLS compatível. Consulte a documentação do curl para HTTP/3.

A Cloudflare também explica o funcionamento do protocolo e o modelo de implantação na borda.

Como verificar se sua API serve HTTP/3

A descoberta normalmente ocorre por meio do cabeçalho Alt-Svc. Um servidor que anuncia HTTP/3 pode responder inicialmente via HTTP/2 com:

alt-svc: h3=":443"; ma=86400

Isso informa ao cliente que o mesmo serviço está disponível via HTTP/3 na porta UDP 443 pelas próximas 24 horas.

Verifique o cabeçalho com:

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

Para fazer uma requisição diretamente via HTTP/3 — usando um build do curl com suporte habilitado:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200

A linha de status deve informar HTTP/3 em vez de HTTP/2.

No Chrome DevTools:

1. Abra a aba Network.
2. Clique com o botão direito no cabeçalho de uma coluna.
3. Habilite a coluna Protocol.
4. Procure por h3 nas chamadas da API.

Em produção, registre o protocolo negociado nos logs de acesso. A proporção entre tráfego h2 e h3 mostra quantos clientes estão usando HTTP/3.

Valide o comportamento da API, não apenas o transporte

Depois de verificar o protocolo, teste os mesmos endpoints com o Apidog. Compare:

• Códigos de status.
• Esquemas de resposta.
• Headers.
• Payloads.
• Orçamentos de latência.
• Comportamento em redes móveis.

Ative o HTTP/3 na borda e execute o mesmo conjunto de testes antes e depois. A diferença nos tempos de resposta em redes reais é mais relevante que um benchmark isolado.

Você pode baixar o Apidog gratuitamente para executar essa comparação.

FAQ

HTTP/3 é mais rápido que HTTP/2?

Em redes limpas e de baixa latência, a diferença costuma ser pequena. Em redes com perda de pacotes ou alta latência, o HTTP/3 pode ser significativamente mais rápido porque:

• Economiza uma viagem de ida e volta no handshake.
• Evita que um pacote perdido paralise todas as requisições multiplexadas.
• Mantém a conexão durante trocas de rede.

Meça o seu próprio perfil de tráfego antes de concluir. O HTTP/2 continua sendo uma excelente opção. Erros de conexão geralmente estão relacionados à camada TLS — como o problema SSLV3_ALERT_HANDSHAKE_FAILURE — e não a uma limitação do protocolo HTTP/2.

HTTP/3 usa TCP?

Não. O HTTP/3 roda sobre QUIC, que roda sobre UDP, normalmente na porta 443.

O QUIC reimplementa confiabilidade, ordenação e controle de congestionamento, mas por stream e no espaço do usuário. Se a porta UDP 443 estiver bloqueada, os clientes normalmente retornam ao HTTP/2 sobre TCP.

Preciso mudar meu código de API para HTTP/3?

Quase nunca. A semântica HTTP permanece igual: métodos, cabeçalhos, códigos de status e corpos não mudam.

O trabalho principal fica na infraestrutura:

1. Habilite HTTP/3 no CDN, balanceador ou servidor.
2. Verifique o suporte a UDP 443.
3. Restrinja dados 0-RTT a requisições idempotentes.
4. Monitore o protocolo negociado e a latência real.

Posso usar gRPC sobre HTTP/3?

Na maioria dos casos, ainda não. O formato de transmissão do gRPC está ligado ao HTTP/2, e as bibliotecas convencionais não oferecem transporte HTTP/3.

O .NET possui suporte experimental. Para começar, mantenha serviços gRPC em HTTP/2 e adote HTTP/3 onde o ganho é mais provável: endpoints REST públicos, aplicações web e clientes móveis.

Comments

[Kane Lim]

Hello Lucas, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.

Your explanation of HTTP/3 correctly focuses on transport behavior rather than treating it as an application layer rewrite. One area I would extend is production observability. Protocol adoption alone does not prove performance improvement.

I would instrument the edge with negotiated protocol, RTT, packet loss, handshake duration, connection migration events, request latency percentiles, retransmission behavior, and fallback from h3 to h2. Then correlate these metrics by ASN, geography, network type, device class, and endpoint.

For performance validation, I would run controlled experiments using identical API workloads and compare p50, p95, p99 latency and error rates under injected packet loss and variable RTT. This exposes the environments where QUIC actually changes the tail latency profile.

There is also an important architectural opportunity with HTTP/3 at the edge. Terminate QUIC close to the client while retaining HTTP/2 or HTTP/1.1 toward origin services. This isolates transport complexity from application services while still providing mobile clients with connection migration and stream level isolation.

I particularly liked the emphasis on measuring before migrating. The next logical step is treating protocol selection as an adaptive edge capability rather than a binary infrastructure switch.

Great networking focused article. I would enjoy exchanging ideas around QUIC observability, controlled network impairment testing, and edge architecture.