QUIC E HTTP/3: TRANSPORTE MODERNO E ANÁLISE COM CURL/WIRESHARK

O que é o HTTP/3?

HTTP/3 é a evolução mais recente do Hypertext Transfer Protocol — o sistema que move dados entre navegadores, aplicações e APIs pela Internet. O que o distingue das gerações anteriores é a ruptura com o TCP, o protocolo de transporte que sustenta a web desde os primeiros dias.

O TCP é confiável, mas inflexível. Foi projetado para exatidão, não para velocidade: garante que todos os dados cheguem na ordem perfeita, mesmo que isso retenha a conexão inteira. Cada sessão exige um handshake em múltiplas etapas e, se um único pacote atrasa, tudo atrás dele precisa esperar. Isso podia ser aceitável para e-mail — para o tráfego web moderno, de alta velocidade e sensível a latência, é um encaixe ruim.

Para superar essas limitações, o HTTP/3 usa o QUIC (Quick UDP Internet Connections), um protocolo de transporte construído sobre UDP e projetado para uma Internet rápida, móvel e sensível a latência. O QUIC minimiza o custo de handshake, evita o head-of-line blocking e cifra praticamente toda a conexão por padrão — desde o primeiro pacote.

Depois de anos de desenvolvimento, o IETF publicou o HTTP/3 como padrão em junho de 2022, na RFC 9114. Hoje ele é implementado pelos principais navegadores, plataformas de nuvem e um número crescente de servidores web.

O que é o QUIC?

O tráfego web tradicional segue um padrão previsível: o cliente inicia o handshake triplo do TCP, executa o handshake TLS por cima dessa conexão e só então começa a enviar requisições HTTP. O QUIC colapsa esse processo inteiro em um único handshake que combina negociação de transporte e negociação criptográfica. Na primeira conexão a um servidor, o cliente estabelece uma sessão segura em apenas um round trip. Em conexões subsequentes, o QUIC consegue retomada em zero round-trip time: o cliente envia dados de aplicação já cifrados no primeiro pacote.

O protocolo cifra quase tudo, exceto um identificador de conexão mínimo. Diferente do TLS sobre TCP — onde headers TCP, números de sequência e acknowledgments trafegam em texto claro — o QUIC cifra números de pacote, acknowledgments e até os frames de fechamento de conexão. Essa criptografia por padrão reduz drasticamente os metadados disponíveis para análise de tráfego.

O QUIC também implementa migração de conexão: a conexão sobrevive a mudanças de rede. Se o usuário troca Wi-Fi por rede móvel, ou o endereço IP muda numa renovação de DHCP, a conexão QUIC persiste usando Connection IDs em vez do quadruplo tradicional (IP de origem, porta de origem, IP de destino, porta de destino).

A comparação direta entre os dois modelos de estabelecimento de conexão evidencia onde está a economia:

No modelo legado TCP+TLS, o handshake tripro do TCP consome um round trip, o handshake TLS consome outro e os dados de aplicação só começam depois de ambos. No QUIC, o ClientHello do TLS 1.3 já viaja dentro do primeiro pacote Initial, junto com os parâmetros de transporte — a negociação inteira converge para um único round trip, e conexões retomadas eliminam até esse.

Handshake do QUIC em detalhe

O processo começa quando o cliente envia seu pacote Initial. Essa primeira mensagem carrega as versões QUIC suportadas pelo cliente, as cipher suites disponíveis, um número aleatório recém-gerado e um Connection ID — um identificador escolhido aleatoriamente que permanece estável mesmo que o endereço IP do cliente mude. Dentro do pacote Initial, o cliente embute a mensagem ClientHello do TLS 1.3 junto com os parâmetros de transporte QUIC e o material criptográfico inicial para começar a negociação de chaves. Se o cliente já conectou àquele servidor antes, pode incluir até dados antecipados de aplicação — como uma requisição HTTP — para economizar um round trip inteiro.

O servidor responde com seu próprio conjunto de informações: escolhe uma das versões QUIC e cipher suites do cliente, fornece seu próprio número aleatório e um Connection ID do lado do servidor, junto com seus parâmetros de transporte QUIC. Embutida nessa resposta vem a ServerHello do TLS 1.3, com o material criptográfico para derivar as chaves compartilhadas. O servidor também envia a cadeia completa de certificados — o certificado do servidor e as autoridades certificadoras intermediárias que o assinaram — e pode incluir, opcionalmente, dados antecipados de resposta HTTP.

Recebida a resposta, o cliente inicia a verificação do certificado. Ele extrai os dados do certificado e a assinatura que os acompanha, identifica a CA emissora e usa o certificado raiz correspondente da sua trust store para verificar os intermediários e, por fim, o certificado do servidor. Para isso, calcula o hash dos dados recebidos com o algoritmo especificado no certificado e confere se o resultado confere com a assinatura verificável pela chave pública da CA. Se os valores batem e o certificado é válido para o período e para o domínio em uso, o cliente pode confiar que o servidor é legítimo. Nesse momento, seguindo o key schedule do TLS, o cliente deriva as chaves de conexão QUIC e envia sua mensagem Finished dentro de outro pacote QUIC. Com esse intercâmbio completo, a conexão está pronta para dados de aplicação cifrados.

A partir daqui, todo o tráfego entre cliente e servidor é cifrado com as chaves de sessão estabelecidas. Diferente da combinação tradicional de TCP com TLS, o QUIC não exige uma fase separada de handshake TLS — o TLS é integrado ao próprio handshake do QUIC, eliminando round trips extras. Uma das grandes vantagens desse desenho é que servidor e cliente podem incluir dados reais de aplicação — requisições e respostas HTTP — dentro do próprio handshake. Como resultado, validação de certificado e estabelecimento de conexão acontecem em paralelo com o primeiro intercâmbio de dados, tornando o QUIC mais rápido e mais eficiente que o modelo TCP+TLS.

Como a rede QUIC funciona

Vale ver a estrutura de uma conexão QUIC em camadas. Requisições, respostas e demais dados de aplicação HTTP/3 viajam por streams QUIC — e esses streams são encapsulados em várias camadas lógicas antes de irem ao cabo.

A anatomia de um stream QUIC, de fora para dentro:

• O datagrama UDP é o contêiner de transporte externo. Carrega um header com portas de origem e destino, comprimento e checksum, e transporta um ou mais pacotes QUIC — é a unidade fundamental transmitida entre cliente e servidor.
• O pacote QUIC é a unidade contida no datagrama UDP; cada datagrama pode carregar um ou mais deles. Todo pacote QUIC consiste em um header QUIC e um ou mais frames QUIC.
• O header QUIC traz metadados do pacote em dois formatos: o long header, usado durante o estabelecimento da conexão, e o short header, usado depois dela. O short header inclui o Connection ID, o número do pacote e o key phase — o bit que indica quais chaves de cifragem estão em uso e permite a rotação de chaves. Os números de pacote crescem continuamente por conexão e por key phase.
• O frame é a menor unidade estruturada dentro de um pacote QUIC. Contém o tipo de frame, o Stream ID, o offset e um segmento dos dados do stream. Embora os dados de um stream se espalhem por vários frames, a remontagem na ordem correta usa Connection ID, Stream ID e offset.
• O stream é um canal de dados unidirecional ou bidirecional dentro de uma conexão QUIC. Cada conexão suporta múltiplos streams independentes, cada um com seu próprio ID. Se um pacote QUIC se perde, apenas os streams carregados naquele pacote são afetados — todos os outros seguem ininterruptos. Essa independência é o que elimina o head-of-line blocking presente no HTTP/2 sobre TCP. Streams podem ser criados por qualquer endpoint e operar em ambas as direções.

HTTP/3 versus HTTP/2 e HTTP/1.1: o que mudou de fato

Para entender o significado do HTTP/3, ajuda partir das limitações dos antecessores.

O HTTP/1.1, o protocolo original ainda usado por milhões de sites, processa apenas uma requisição por conexão TCP. Isso força o navegador a abrir e fechar múltiplas conexões para carregar uma única página, com ineficiência, desempenho degradado e alta sensibilidade a problemas de rede.

O HTTP/2 trouxe melhorias relevantes: multiplexação — várias requisições compartilhando uma única conexão TCP —, compressão de headers e server push. Os ganhos foram significativos, mas o protocolo ainda depende do TCP, que carrega uma limitação fundamental: se um pacote atrasa, todo o pipeline da conexão trava. Esse fenômeno, o head-of-line blocking, não tem solução dentro do HTTP/2.

O HTTP/3 ataca exatamente essa limitação ao substituir o TCP por uma camada de transporte mais avançada. Construído sobre o QUIC, estabelece sessões cifradas mais rápido — tipicamente um round trip em vez de três ou mais. Elimina o head-of-line blocking dando a cada stream flow control independente: os outros streams continuam mesmo com a perda de um pacote. Mantém sessões através de mudanças de IP e de rede, recupera perda de pacotes com mais elegância e suporta controle de congestionamento customizado por carga de trabalho.

Em resumo, HTTP/3 não é uma versão refinada do HTTP/2. É um protocolo reprojetado desde a base para superar as limitações das gerações anteriores — em especial para usuários móveis, aplicações sensíveis a latência e tráfego globalmente distribuído.

Prática com HTTP/3: curl e Wireshark

Versões modernas do curl (7.66.0 ou posterior, com suporte a HTTP/3 compilado) permitem testar se um alvo suporta QUIC e HTTP/3. O curl 7.66.0, lançado em setembro de 2019, foi a primeira versão com suporte experimental a HTTP/3; nas distribuições atuais do Kali Linux o suporte já vem habilitado por padrão no pacote curl.

A sonda é direta:

Sondando o alvo com curl –http3

curl --http3 -I https://www.exemplo.com

A flag --http3 instrui o curl a tentar a conexão usando HTTP/3 sobre QUIC, com fallback para HTTP/2 ou HTTP/1.1 caso o alvo não suporte QUIC — comportamento documentado no manual oficial do curl como análogo ao happy eyeballing de IPv4/IPv6. O -I busca apenas os headers de resposta.

Na demonstração de referência contra um host com HTTP/3 ativo, a resposta chega com a linha de status HTTP/3 301, seguida dos headers habituais — date, content-type, content-length, location, cache-control, expires, priority e os cookies de proteção do CDN. É a prova direta de que a negociação QUIC aconteceu.

Quando o alvo não fala QUIC, o mesmo comando cai no fallback sem erro: a resposta vem como HTTP/1.1 301, com os headers do servidor legado. Comparar os dois casos lado a lado mostra exatamente o que a flag faz — tenta HTTP/3 primeiro, degrada de forma transparente.

Evidenciando QUIC no Wireshark: filtro de porta

Além da sonda, é útil ver como o tráfego QUIC aparece na rede. O caminho mais simples é o Wireshark, o analisador de pacotes de referência. Embora o QUIC cifre a maior parte do payload, o Wireshark identifica tipos de pacote, versões e metadados da conexão — o suficiente para entender como o estabelecimento acontece.

Para começar, abra o Wireshark e visite um site com suporte a QUIC. A Cloudflare é um bom exemplo por distribuir HTTP/3 amplamente. O QUIC tipicamente roda sobre UDP na porta 443, então o filtro mais simples para confirmar que você está vendo tráfego QUIC é:

udp.port == 443

O filtro exibe todo o tráfego UDP na porta 443 — que, em sites modernos, quase sempre corresponde a QUIC. Na captura de referência, a lista de pacotes mostra a sequência completa de uma conexão: Initial do cliente, Initial de resposta, Handshake e depois os pacotes de aplicação rotulados como Protected Payload — cada um com o DCID visível na coluna Info.

Pacotes Initial no Wireshark

O QUIC usa tipos de pacote diferentes em cada estágio da conexão. Mesmo com o conteúdo cifrado, o Wireshark distingue esses tipos pelos bits do long header.

Para exibir apenas pacotes Initial — os primeiros trocados quando um cliente inicia uma conexão QUIC — use:

quic.long.packet_type == 0

Na captura de referência, o filtro isola os Initial do cliente e as respostas do servidor com o mesmo tipo. Pacotes Initial fazem parte da fase de handshake do QUIC. Guardam semelhança com as mensagens ClientHello e ServerHello do TLS — com a diferença de que o QUIC embute o handshake dentro do próprio protocolo. O campo quic.long.packet_type está documentado na referência oficial de display filters do Wireshark, disponível a partir da versão 2.6.0 do dissecador QUIC IETF.

Pacotes Handshake no Wireshark

Para ver os pacotes Handshake, que continuam a negociação criptográfica depois dos Initial, use:

quic.long.packet_type == 2

Esses pacotes completam o estabelecimento da conexão segura antes que o QUIC troque para os pacotes de short header cifrados que carregam os dados normais — como requisições e respostas HTTP/3. Na captura de referência, os pacotes Handshake aparecem em sequência dos dois lados da conexão, com os DCIDs constantes enquanto o par negocia as chaves.

Versão do QUIC no Wireshark

O QUIC tem múltiplas versões, e servidores costumam suportar mais de uma. Para exibir os pacotes de uma versão específica, use:

quic.version == 0x00000001

O valor corresponde à versão 1 do QUIC, padronizada na RFC 9000. Ao abrir o detalhe de um pacote na captura de referência, o campo Version mostra 1 (0x00000001), com o header form longo, o Fixed Bit ativo, o tipo Handshake e os Connection IDs de origem e destino expostos — e o aviso característico de que os segredos de decifragem não estão disponíveis, já que o payload só se abre com as chaves de sessão.

Checar qual versão aparece no tráfego revela o que o servidor suporta — se ele fala a versão padronizada ou ainda opera com um draft antigo.

Perspectiva defensiva

Para o defensor, o QUIC é uma mudança de paradigma na visibilidade de rede. Toda a telemetria que o TCP expunha em texto claro — números de sequência, acknowledgments, janelas de congestionamento, os internals do TLS — passa a viajar cifrada dentro do payload QUIC. IDS e firewalls que dependem de inspeção do handshake TLS sobre TCP 443 veem apenas datagramas UDP opacos.

O tráfego QUIC legítimo é identificável: UDP 443, pacotes Initial decodificáveis pelo Wireshark com as chaves públicas derivadas da especificação (RFC 9001) e o ALPN h3 na negociação. Política de saída razoável em rede corporativa: permitir QUIC para destinos aprovados com logging de metadados (IP, DCID, versão), ou bloquear UDP 443 para forçar fallback ao TCP 443 inspecionável — o custo é latência e perda de recursos do protocolo, e navegadores recaem de forma transparente.

Também há uso ofensivo do padrão: canal C2 sobre QUIC se beneficia do handshake rápido, da migração de conexão (mudança de IP sem cair) e da cifra por padrão. A resposta defensiva não está em confiar no payload cifrado, e sim no perímetro de metadados que resta: volumes, destinos, horários e a presença de Initial sem Handshake subsequente.

Limitações

Artigo documental: a análise descreve o protocolo conforme as RFCs 9000, 9001 e 9114 e reproduz a demonstração de referência; não houve execução própria dos comandos nesta cobertura, e as saídas apresentadas são as evidenciadas pela referência. O Wireshark decodifica Initial sem chaves por derivação pública da especificação, mas Handshake e 1-RTT exigem o arquivo de key log da sessão — sem ele, o payload permanece opaco. Números de pacote, ACKs e frames de conexão não são observáveis em claro, o que limita qualquer análise forense de tráfego QUIC a metadados.

Considerações éticas

A análise de tráfego QUIC com curl e Wireshark é técnica passiva de caracterização de protocolo: observa pacotes da própria rede ou de alvos públicos com o mesmo rigor de qualquer auditoria de porta. Capturar tráfego de terceiros sem autorização é ilegal em praticamente todas as jurisdições — em laboratório próprio ou em auditoria contratada, os mesmos filtros servem tanto para validação de deploy HTTP/3 quanto para verificação de política de saída.

Conclusão

QUIC não é um upgrade incremental — é uma reimaginação de como a comunicação moderna na Internet deveria funcionar. O stack tradicional de TCP + TLS + HTTP/2 serviu bem por muitos anos, mas nunca foi projetado para as realidades de hoje: latência em escala global, conexões móveis em constante mudança e a demanda simultânea por desempenho e segurança fortes. O QUIC foi construído do zero para esses desafios — handshake em 1 RTT com TLS 1.3 embutido, streams independentes sem head-of-line blocking, Connection ID que sobrevive à troca de rede e criptografia de metadados por padrão. Com curl e Wireshark, qualquer analista evidencia essa arquitetura em minutos: um HTTP/3 301 na sonda, Initial e Handshake separados por tipo de pacote e a versão padronizada confirmada em cada captura.