HTTP-2 e HTTP-3 (QUIC)

1. Definição e Histórico

HTTP/2 e HTTP/3 são as duas grandes revisões do protocolo HTTP após o HTTP/1.1 (1997). HTTP/2 foi publicado em 2015 (RFC 7540, obsoleto por RFC 9113 em 2022) e introduziu multiplexação binária sobre TCP. HTTP/3 foi publicado em 2022 (RFC 9114) e roda sobre QUIC, um protocolo de transporte sobre UDP, eliminando o head-of-line blocking do TCP.

Linha do Tempo

2. HTTP/1.1 — Limitações

Problemas do HTTP/1.1

• Head-of-line blocking: se um pacote TCP se perde, todas as requisições em pipeline esperam.
• Conexões paralelas limitadas: browsers abrem ~6 conexões TCP por domínio (HTTP/1.1).
• Headers verbosos: texto puro, repetidos em cada requisição (cookies, User-Agent).
• Sem server push: cliente precisa pedir cada recurso explicitamente.
• Sem priorização: cliente não pode ordenar downloads de CSS vs JS vs imagens.

3. HTTP/2 — Conceitos Principais

HTTP/2 é binário, não texto. Cada frame tem tipo, comprimento, flags e stream ID. Substitui o formato ASCII delimitado por CRLF do HTTP/1.1.

Stream, Message, Frame

• Stream: fluxo bidirecional lógico dentro de uma conexão TCP (ID ímpar 1, 3, 5... para cliente→servidor).
• Message: sequência completa de frames que compõem uma requisição ou resposta HTTP.
• Frame: unidade mínima de comunicação (HEADERS, DATA, RST_STREAM, SETTINGS, PING, GOAWAY).

Multiplexação

Várias requisições/respostas trafegam simultaneamente na mesma conexão TCP, cada uma em seu stream. Elimina a necessidade de múltiplas conexões por domínio.

Conexão TCP única (443)
├── Stream 1: GET /index.html
├── Stream 3: GET /styles.css
├── Stream 5: GET /app.js
└── Stream 7: GET /logo.png

HPACK (Header Compression)

Compressão de headers inspirada em zlib. Mantém tabelas estáticas (61 headers comuns) e dinâmicas (negociadas) no cliente e servidor, referenciando índices em vez de reenviar strings. Após warm-up, headers são substituídos por índices ou codificados via Huffman — economia de 80-90% de bytes em headers repetidos.

Server Push (deprecado)

Servidor podia enviar recursos antes de o cliente pedir (ex: envia CSS junto com HTML). Problemático em prática — browsers frequentemente tinham cópias cacheadas, gerando desperdício. Deprecado em Chrome 106+ (2022). Substituído por 103 Early Hints.

Priorização e Flow Control

Cliente indica prioridade de cada stream (peso, dependência). Permite baixar CSS crítico antes de imagens decorativas. Em HTTP/2 original era complexo; RFC 9113 simplificou com Extensible Prioritization Scheme. Cada stream tem janela de controle de fluxo independente, similar ao TCP window mas em nível de aplicação.

4. HTTP/2 — Handshake

HTTP/2 usa ALPN para negociar h2 durante handshake TLS. Requer TLS 1.2+. Não há texto plano HTTP/2 — sempre TLS.

Cliente                         Servidor
  | --- TLS ClientHello ------->  |
  | <-- TLS ServerHello --------- |  (ALPN: h2)
  | === HTTP/2 sobre TLS ======== |
  | --- SETTINGS frame -------->  |
  | <-- SETTINGS frame --------- |
  | --- HEADERS (stream 1) ----> |
  | <-- DATA (stream 1) -------- |

5. Limitações do HTTP/2

Mesmo com multiplexação, HTTP/2 roda sobre uma única conexão TCP. Se um pacote TCP se perde, todos os streams HTTP/2 são pausados até a retransmissão. Em redes com perda (mobile, Wi-Fi congestionado), isso anula boa parte do ganho de multiplexação. Exemplo: 6 streams HTTP/2 numa conexão TCP; se pacote nº 100 se perde, servidor pára de enviar frames até retransmissão do pacote 100 — pacotes 101-200 já chegados ficam buffered.

6. HTTP/3 e QUIC

QUIC (Quick UDP Internet Connections)

Protocolo de transporte sobre UDP, desenvolvido pelo Google (2012) e padronizado pelo IETF (RFC 9000-9002). Combina features de TCP, TLS e HTTP/2 em uma única camada:

• Confiabilidade como TCP (ACK, retransmissão).
• Multiplexação com streams independentes (sem HOL blocking entre streams).
• TLS 1.3 embutido (criptografia integrada ao handshake).
• 0-RTT em conexões de retorno.
• Connection Migration: cliente muda IP (ex: Wi-Fi → 4G) sem reconexão.

Handshake HTTP/3

Cliente                         Servidor
  |                               |
  | --- QUIC Initial ---------->  |
  |     (ClientHello, 0-RTT)     |
  | <-- QUIC Initial ----------- |
  |     (ServerHello, cert)      |
  | === HTTP/3 frames =========== |

Handshake QUIC + TLS 1.3 = 1-RTT. Em reconexões, 0-RTT.

Eliminação do HOL Blocking

Em HTTP/3, cada stream é independente em nível de transporte. Se um pacote UDP carregando dados do stream 3 se perde, apenas o stream 3 pausa. Streams 1, 5, 7 continuam recebendo dados normalmente.

Connection Migration

QUIC identifica conexões por um Connection ID (CID) aleatório, não por IP+porta. Se cliente troca de rede (Wi-Fi → 4G), o IP muda mas o CID permanece — conexão continua. Em TCP, isso seria impossível (TCP usa 4-tupla IP+porta).

7. Comparativo HTTP/1.1 vs HTTP/2 vs HTTP/3

8. QPACK (Header Compression no HTTP/3)

QPACK é similar ao HPACK, mas adaptado para transporte sobre QUIC. A diferença:

• HPACK assume ordem de entrega (TCP garante isso).
• QPACK opera sobre UDP, então precisa lidar com reordenação e perda.

Usa referências dinâmicas com acknowledgment de insertion. Garante que cliente e servidor concordem sobre o estado da tabela dinâmica mesmo sob perda.

9. Alt-Svc e Descoberta HTTP/3

Servidor anuncia suporte a HTTP/3 via header Alt-Svc na resposta HTTP/2 ou HTTP/1.1:

HTTP/2 200 OK
Alt-Svc: h3=":443"; ma=86400

Cliente (browser) armazena essa info por ma segundos (max-age) e faz próxima requisição via HTTP/3 sobre UDP. Se UDP estiver bloqueado, fallback automático para HTTP/2.

10. Suporte em Servidores

• Nginx: HTTP/2 desde 1.9.5. HTTP/3 experimental desde 1.25.0. Configuração: listen 443 ssl http2; listen 443 quic reuseport; ssl_protocols TLSv1.3; http2 on; http3 on;
• Caddy: HTTP/3 habilitado por padrão desde 2020 (sem configuração extra).
• Apache: HTTP/2 via mod_http2. HTTP/3 experimental em 2.4.x.
• Cloud CDN: Cloudflare, AWS CloudFront, Google Cloud CDN, Akamai — todos suportam HTTP/3 na edge.

11. Boas Práticas

• Habilitar HTTP/2 onde possível: Praticamente obrigatório em 2024. Reduz número de conexões TCP e economiza banda em headers.
• Adotar HTTP/3 em apps mobile: Em redes móveis com perda, HTTP/3 tem vantagem significativa por eliminar HOL blocking e suportar connection migration.
• Garantir UDP liberado em firewalls: Alguns firewalls corporativos bloqueiam UDP não-DNS. HTTP/3 falha nesses casos (fallback automático para HTTP/2).
• Priorizar recursos críticos: Com Extensible Prioritization (RFC 9218), cliente indica que CSS crítico tem prioridade maior que imagens abaixo da dobra.
• Evitar Server Push: Server push HTTP/2 está deprecado. Em vez disso, usar 103 Early Hints para preload de assets.

12. Diagnóstico

curl --http2 -v https://www.exemplo.com/
curl --http3 -v https://www.exemplo.com/

Em browsers: DevTools → Network → Protocol column mostra h2 (HTTP/2) ou h3 (HTTP/3). Wireshark: filtro http2 para HTTP/2; filtro quic (UDP porta 443) para HTTP/3.

13. Resumo Técnico

14. Conclusão

HTTP/2 e HTTP/3 representam a evolução natural do protocolo HTTP em resposta às limitações do HTTP/1.1. HTTP/2 introduziu multiplexação binária, compressão de headers (HPACK) e priorização, mas herdou o head-of-line blocking do TCP. HTTP/3, ao migrar para QUIC sobre UDP, elimina esse problema, oferece handshakes mais rápidos (1-RTT e 0-RTT), connection migration e melhor performance em redes com perda. A transição de HTTP/2 para HTTP/3 é gradual e paralela — servidores expõem ambos, com Alt-Svc permitindo ao cliente escolher o melhor disponível. Para 2024 e além, HTTP/3 deve se consolidar como padrão para aplicações web modernas, especialmente mobile e real-time, enquanto HTTP/2 permanece como fallback robusto em ambientes onde UDP ainda é restrito.