HTTP/2 e HTTP/3 explicados

Artigo original ↗ Discussão no Hacker News ↗

Pipelining do HTTP/1.1 e Middleboxes

  • Em termos de especificação, o HTTP/1.1 permite enviar múltiplas requisições em uma conexão TCP antes que as respostas anteriores cheguem.
  • Vários comentaristas dizem que isso “nunca realmente funcionou” na prática: proxies quebrados, MITM de antivírus e middleboxes corrompem ou intercalam respostas.
  • Por causa disso, os navegadores em grande parte abandonaram o pipelining, apesar da correção teórica.

Head-of-Line Blocking, Multiplexação e Desempenho

  • Esclarecimento: no HTTP/1.1, você pode enviar múltiplas requisições, mas muitas vezes precisa esperar respostas anteriores antes que as posteriores possam ser usadas.
  • Os navegadores limitam conexões TCP simultâneas por origem (historicamente poucas, depois cerca de ~6–10), o que pode causar bloqueio.
  • Alguns argumentam que a multiplexação de conexão única do HTTP/2 cria head-of-line em nível de TCP: perda de pacote em um fluxo pode travar os outros.
  • Outros contrapõem que múltiplas conexões HTTP/1.1 têm suas próprias desvantagens (handshakes, slow start, limites do kernel).

HTTP/2 na Prática

  • As opiniões se dividem:
    • Positivo: geralmente mais rápido em conexões típicas; design mais limpo (todos os metadados como headers, streams, HPACK); funciona bem para RPC e muitas cargas de trabalho web.
    • Negativo: alguns relatam tempos de carregamento mobile 5–25% piores, especialmente com alta latência/perda e casos de uso interativos + lazy-loading. Há dados mencionados, mas não compartilhados, o que leva a acusações de anedota versus evidência.
  • Server push é amplamente visto como um recurso fracassado; os principais navegadores o removeram.

HTTP/3 / QUIC e UDP

  • HTTP/3/QUIC é elogiado para redes instáveis/móveis por meio de migração de conexão e melhor tratamento de perdas.
  • Um comentarista diz que HTTP/3 tem desempenho pior que HTTP/1.1 + satélite “PEP” em links via satélite.
  • Levantam-se preocupações sobre as implicações de DDoS do QUIC sobre UDP e sobre propostas de “QUIC over TCP” como sinal de atrito no mundo real.
  • Há discussão sobre por que o UDP é menos otimizado: offloads de TCP em hardware e no SO (segmentação, coalescência) não se traduzem facilmente para UDP.

Complexidade vs. Benefícios

  • Alguns argumentam que, se HTTP/2/3 forem mais complexos e caros de implementar do que HTTP/1.1, então são um erro.
  • Outros respondem que a complexidade é justificável quando um pequeno número de implementações atende bilhões de usuários, e que o HTTP/3 efetivamente junta TCP+TLS+HTTP em uma única pilha com complexidade geral semelhante.
  • Para desenvolvedores de apps em plataformas modernas de nuvem, HTTP/3 pode ser “de graça” via balanceadores de carga gerenciados.

TLS, CAs e Longevidade / Censura

  • Há forte discordância sobre TLS obrigatório baseado em CA para HTTP/3:
    • Pró: implantações inseguras/em texto puro ou com certificado autoassinado não deveriam ser expostas publicamente; segurança e privacidade do usuário superam a conveniência.
    • Contra: a dependência de CAs prejudica a longevidade (expiração de certificados, fragilidade do ACME), centraliza poder para censura e bloqueia sites pessoais simples; autoassinado ou texto puro deveriam continuar possíveis (com avisos).
  • Debate sobre se criptografia é sempre necessária para conteúdo apenas de leitura; opositores citam vigilância em jurisdições hostis como motivo de que ela é.

Casos de Uso e “Para Quem HTTP/2/3 Servem”

  • Um comentarista argumenta que HTTP/2/3 resolvem principalmente problemas de páginas pesadas de anúncios, com vários domínios, impulsionadas por grandes empresas de anúncios e CDN, e não de simples recuperação de texto.
  • Eles afirmam que, para busca de texto em um único domínio, o pipelining do HTTP/1.1 continua superior; outros discordam, mas não apresentam contra-benchmarks.
  • Um pequeno teste de carregamento de muitas imagens em diferentes navegadores/versões de HTTP mostra paralelismo e ordenação diferentes, destacando variações de implementação.

Multiplexação em Camadas Superiores vs. SCTP

  • Uma questão em aberto: por que a multiplexação do HTTP/2/3 foi feita na camada de aplicação (sobre TCP/UDP) em vez de usar SCTP diretamente.
  • O tópico levanta a questão, mas não oferece uma resposta clara.