Por que o HTTP/3 é amplamente suportado, mas quase não é usado na prática

 (httptoolkit.com)
2 pontos por GN⁺ 2025-03-18 | 1 comentários | Compartilhar no WhatsApp
  • O HTTP/3 vem sendo desenvolvido desde 2016, e o QUIC, protocolo no qual ele se baseia, foi introduzido pela primeira vez pelo Google em 2013
  • Hoje ele está padronizado e conta com amplo suporte, como por exemplo:
    • suporte em 95% dos navegadores
    • 32% das requisições HTTP da Cloudflare usam HTTP/3
    • 35% dos sites indicam suporte a HTTP/3 (via alt-svc ou DNS)
  • No entanto, falta suporte a QUIC e HTTP/3 nas bibliotecas padrão das principais linguagens
    • Não está incluído nas bibliotecas padrão de Node.js, Go, Rust, Python, Ruby etc.
    • O Curl adicionou suporte a HTTP/3 recentemente, mas ele ainda é experimental e vem desativado por padrão
    • O popular servidor Nginx está com suporte experimental e desativado por padrão
    • O Apache não tem planos de suportar HTTP/3
    • O Ingress-Nginx do Kubernetes abandonou os planos de suporte a HTTP/3

A necessidade após o HTTP/1.1

  • O HTTP/3 é útil para navegadores web e tráfego de CDN com alta latência
  • Principais benefícios oferecidos por HTTP/2 e HTTP/3:
    • multiplexação para reduzir a latência de resposta
    • compressão de cabeçalhos HTTP para reduzir o tráfego (usando HPACK e QPACK)
    • streaming bidirecional para troca de dados em tempo real entre cliente e servidor
    • priorização para processar primeiro as requisições mais importantes
  • Benefícios adicionais do HTTP/3:
    • processamento independente de streams para que a perda de pacotes não afete outros streams
    • handshake TLS 0-RTT para melhorar a velocidade de inicialização da conexão
    • migração de conexão para manter a conexão mesmo quando o endereço IP muda
    • melhor controle de congestionamento para aumentar desempenho e estabilidade

Ganhos de desempenho do HTTP/3

  • Resultado dos benchmarks da RequestMetric:
    • O HTTP/3 oferece tempos de resposta mais rápidos do que HTTP/1.1 e HTTP/2
  • Caso real da Fastly:
    • No HTTP/3, o tempo até o primeiro byte foi 18% menor

O problema da falta de suporte ao HTTP/3

  • O HTTP/3 é amplamente suportado em navegadores e CDNs, mas continua difícil de usar para desenvolvedores em geral
  • Hoje existem dois tipos de tráfego web:
    • web hyperscale: baseada em grandes navegadores e grandes servidores (Google, Meta, Amazon etc.)
    • web long tail: baseada em servidores e clientes de pequeno e médio porte (APIs de backend, apps móveis, IoT etc.)
  • Principais diferenças:
    • O tráfego long tail representa 67% do tráfego total
    • O hyperscale consegue desenvolver e adotar rapidamente, enquanto o long tail sofre com falta de recursos e prioriza estabilidade
    • Há alta dependência de ferramentas open source

OpenSSL e o problema do QUIC

  • O OpenSSL é a base da maioria das ferramentas de rede open source
  • O BoringSSL lançou uma API com suporte a QUIC em 2018, mas o OpenSSL introduziu sua própria API de QUIC
  • Principais problemas:
    • não é compatível com implementações existentes baseadas em BoringSSL
    • Curl e as principais linguagens têm dificuldade para mudar sua dependência de OpenSSL
    • O Node.js chegou a considerar usar BoringSSL no lugar de OpenSSL, mas isso não se concretizou

Perspectivas futuras

  • À medida que a web hyperscale adota o HTTP/3, pode surgir uma diferença de desempenho em relação à web long tail
  • A falta de suporte a HTTP/3 pode gerar problemas como:
    • fortalecimento da vantagem de velocidade e estabilidade dos sites hyperscale
    • se frameworks baseados em HTTP/3 se tornarem comuns, a web long tail pode ter dificuldade de acesso
    • a falta de suporte a HTTP/3 pode passar a ser usada como critério para bloquear clientes
  • Caminhos para resolver:
    • é necessário resolver os problemas da API de QUIC do OpenSSL
    • é preciso desenvolver ferramentas e adaptadores que aumentem a compatibilidade com implementações existentes de QUIC e HTTP/3
    • são necessários esforços para ampliar o suporte a HTTP/3 nas ferramentas open source

Conclusão

  • O HTTP/3 claramente oferece vantagens de desempenho e estabilidade, mas hoje continua sendo algo que só empresas hyperscale conseguem usar com facilidade
  • São necessárias melhorias em ferramentas e padrões para que a web long tail também consiga usar HTTP/3 com facilidade

Leituras relacionadas

1 comentários

 
GN⁺ 2025-03-18
Comentários do Hacker News

  • Há quem diga que é difícil encontrar ferramentas populares de código aberto com suporte completo a HTTP/3

    • Administradores de TI e engenheiros de DevOps normalmente encerram conexões HTTP/3 no load balancer e, após encerrar o SSL, encaminham HTTP 1.1 para os serviços de backend
    • HTTP/3 e IPv6 são tecnologias mais voltadas para dispositivos móveis e são mais úteis em conexões temporárias e instáveis do que em data centers

  • QUIC e HTTP/3 não estão incluídos nas bibliotecas padrão das principais linguagens

    • O .NET oferece um suporte razoável a HTTP/3
    • Como a maioria das equipes de desenvolvimento não constrói produtos centrados em rede, HTTP/3 tem baixa prioridade

  • O maior problema na implantação em larga escala do HTTP/3 é o aumento da superfície de código potencialmente vulnerável

    • É mais desejável que o sistema operacional forneça uma camada de sockets segura e bibliotecas SSL vinculadas dinamicamente
    • Em grande parte das aplicações cliente, alguns milissegundos de latência nas requisições não fazem grande diferença

  • A adoção lenta do QUIC se deve ao fato de o OpenSSL não ter fornecido os componentes básicos necessários para implementações QUIC existentes

    • Recentemente, o OpenSSL 3.5 passou a oferecer APIs para stacks QUIC de terceiros

  • HTTP/2 e HTTP/3 já não são mais vistos como protocolos da camada de aplicação, mas sim no nível de TCP e TLS

    • Os desenvolvedores ainda vivem no mundo do "HTTP 1.1 em texto puro"

  • O nginx ainda não oferece suporte a HTTP/3 pronto para produção

  • Há quem use niquests em Python, com suporte a HTTP/3

    • O ecossistema Python permaneceu no pacote requests por inércia

  • O Node.js publicou uma atualização sobre o estado do QUIC e está enfrentando dificuldades devido ao suporte lento de APIs no OpenSSL

  • Ao usar o load balancer de um provedor de nuvem pública, o HTTP/3 é utilizado por padrão

    • Sites que usam seus próprios servidores não estão se beneficiando das vantagens do HTTP/3

  • Todo projeto é, em algum grau, movido por código aberto e pela comunidade

    • Não se sente urgência em oferecer suporte rápido a HTTP/3