Desempenho HTTP/3 do Curl

Artigo original ↗ Discussão no Hacker News ↗

Benchmarks do novo suporte a HTTP/3/QUIC do curl mostram que ele atualmente fica atrás de HTTP/1.1 e HTTP/2 em throughput bruto em localhost, destacando o maior custo de CPU do QUIC e a maturidade das pilhas TCP altamente otimizadas. Comentadores observam que esses testes medem principalmente eficiência, e não o desempenho no mundo real sob latência e perda de pacotes, onde o HTTP/3 pode se destacar com melhor multiplexação, controle de congestionamento e migração de conexão. O tópico também aborda detalhes de implementação (OpenSSL QUIC, ausência de UDP GSO, empacotamento do Caddy e do Debian), requisitos de segurança e certificados para HTTP/3, e questões mais amplas sobre usar C versus Rust para novo código de protocolo.

Desempenho de HTTP/3 / QUIC vs HTTP/1.1 e HTTP/2

  • Benchmarks mostram HTTP/1.1 com a maior taxa de transferência, HTTP/2 mais lento, e HTTP/3 ainda mais lento em localhost.
  • Alguns leitores ficam surpresos ou alarmados; outros enfatizam que isso mede a eficiência da CPU em loopback, não o desempenho em rede real.
  • Vários comentários destacam que HTTP/2/3 visam latência, multiplexação e comportamento sob perda, e não pura largura de banda.
  • Estudos do mundo real (linkados no tópico) são citados como mostrando melhor taxa de transferência do HTTP/3 do que do HTTP/2 em condições da Internet.

Eficiência de CPU vs Comportamento de Rede

  • Reconhece-se que o QUIC é, por natureza, menos eficiente em CPU do que TCP+TLS.
  • Razões discutidas: criptografia por pacote, muitos pacotes UDP pequenos, trabalho extra em userspace para montagem de pacotes e criptografia, e bookkeeping mais complexo de conexões/streams.
  • A falta de offload de hardware maduro e de otimizações de longa data no kernel/NIC para TCP faz o QUIC ser cerca de uma ordem de grandeza menos eficiente para algumas cargas de servidor de alto throughput, segundo um experimento.

Configuração do Benchmark e Maturidade da Implementação

  • O teste provavelmente roda em localhost e usa uma pilha Caddy / quic-go relativamente antiga, sem GSO e com ajuste subótimo de buffers UDP.
  • Alguns argumentam que isso penaliza injustamente o QUIC e favorece pilhas TCP altamente ajustadas.
  • Outros observam que o HTTP/1.1 recebeu 50 conexões TCP paralelas, ao contrário de navegadores reais, que normalmente usam bem menos.

Trade-offs do Protocolo: Paralelismo, HOL Blocking e Conexões

  • Há debate sobre se o HTTP/1.1 “tem” head-of-line blocking: limite do protocolo vs limites práticos (cap de conexões do navegador, custo de estabelecimento de conexão).
  • A multiplexação do HTTP/2/3 é vista como solução para os problemas de paralelismo e HOL, embora alguns defendam que múltiplas conexões TCP já podem entregar alto desempenho.
  • Discussão sobre os limites de 64k portas/conexões do TCP versus técnicas como múltiplos IPs, DSR e SO_REUSEPORT; dependente do contexto e um tanto controverso.

Problemas de Implantação e Implementações (curl, nginx, Debian, Caddy)

  • Os mantenedores do curl estão avançando para habilitar HTTP/3 (via GnuTLS ou OpenSSL QUIC) e considerando suporte a WebSocket, ainda experimental.
  • Alguns relatam problemas graves de latência com HTTP/2 via nginx (especialmente em Kubernetes), resolvidos ao reverter para HTTP/1.1; outros dizem que o suporte do nginx além de H1 é fraco.
  • A versão do Caddy no Debian é criticada por estar desatualizada e com poucos patches; há tensão entre empacotamento “estável” e correções oportunas de segurança/desempenho.

Segurança, Certificados e a “Web Humana”

  • O TLS obrigatório do HTTP/3 e a ausência de modo cipher null / sem TLS geram preocupações para sites com certificado autoassinado e sites hobbyistas.
  • Alguns temem que a dependência de CAs públicas e de políticas de navegadores marginalize ainda mais sites auto-hospedados e não corporativos, em contraste com fluxos TOFU/autoassinados.

Linguagem e Escolhas de Implementação (C vs Rust)

  • Há decepção expressa pelo fato de novo código QUIC estar sendo escrito em C, apesar de existirem implementações QUIC em Rust e do uso prévio de Rust no curl.
  • Contra-argumentos: toolchains de Rust não estão disponíveis/verificadas para muitas arquiteturas de nicho e embarcadas; Rust tem maior tamanho de binário e custo de build; a maturidade do ecossistema e a cobertura de alvos ainda são restrições práticas.