HTTP/1.1, HTTP/2 e HTTP/3: as diferenças que um operador percebe

O que é

O HTTP/1.1 (RFC 9112) estrutura as mensagens como texto: uma linha de requisição, linhas de cabeçalho e um corpo opcional delimitado por Content-Length ou por chunked transfer coding. As conexões são persistentes por padrão, mas as respostas precisam voltar na ordem das requisições, então os clientes esperam ou abrem várias conexões. O HTTP/2 (RFC 9113) mantém a mesma semântica, mas usa frames binários, vários streams concorrentes em uma única conexão, compressão de cabeçalhos HPACK e controle de fluxo por stream. Ele é negociado via ALPN como h2 sobre TLS; o h2c em texto puro só existe com conhecimento prévio, já que a RFC descontinua o caminho via Upgrade. O HTTP/3 (RFC 9114) transporta a mesma semântica sobre QUIC, um transporte baseado em UDP com TLS 1.3 integrado; cada stream de requisição é entregue de forma independente, de modo que um pacote perdido atrasa apenas o próprio stream, e os cabeçalhos usam QPACK, que limita o head-of-line blocking que a compressão poderia causar. Os clientes descobrem um endpoint HTTP/3 por um cabeçalho Alt-Svc (RFC 9114) ou por um registro DNS HTTPS (RFC 9460) e devem recorrer ao HTTP sobre TCP se a conexão QUIC falhar, por exemplo porque o UDP está bloqueado.

Por que importa

A versão do protocolo muda o que o operador precisa configurar e o que consegue observar. O HTTP/2 concentra o tráfego de um navegador em uma única conexão; assim, um reset de conexão ou uma retransmissão TCP lenta trava todos os streams ao mesmo tempo, e os limites de conexões por cliente passam a ter outro significado em relação ao HTTP/1.1. O HTTP/3 exige que a porta UDP anunciada (a RFC 9114 permite qualquer porta; o Alt-Svc sempre a indica explicitamente) esteja aberta em firewalls, security groups e load balancers, e as capturas de pacotes mostram UDP criptografado em vez de registros TLS legíveis.

Como aplicar

• Termine o HTTP/2 e o HTTP/3 na borda (reverse proxy ou load balancer) e use HTTP/1.1 com os servidores de aplicação, a menos que eles se beneficiem da multiplexação; isso mantém simples o tratamento de conexões na aplicação.
• Anuncie o HTTP/3 somente depois de testar, de fora da rede, a acessibilidade via UDP; um Alt-Svc incorreto faz os clientes sofrerem uma tentativa fracassada antes de recorrerem ao fallback.
• Mantenha no proxy os limites por stream (SETTINGS_MAX_CONCURRENT_STREAMS) e os limites de tamanho do corpo da requisição; com a multiplexação, um único cliente consegue abrir muitas requisições a baixo custo.
• Registre em log o protocolo negociado em cada requisição, para separar no access log os problemas específicos de cada versão.

Armadilhas

Os nomes de cabeçalho são em minúsculas no HTTP/2 e no HTTP/3, e alguns cabeçalhos (Connection, Transfer-Encoding) são proibidos; middlewares que reescrevem cabeçalhos precisam tratar as duas formas. A RFC 9113 observa que o caminho Upgrade em texto puro nunca foi amplamente implantado; os navegadores usam HTTP/2 apenas sobre TLS com ALPN, de modo que o h2c é uma opção para comunicação entre servidores. Os connection IDs do QUIC permitem que um cliente mude de endereço no meio da conexão, o que um balanceamento de carga sem estado baseado na 4-tupla não consegue tratar.