8 min read

HTTP/3 é rápido

HTTP/3 é rápido
Photo by Chris Liverani / Unsplash

HTTP/3 está ai, e é um grande negócio para o desempenho da web. Veja o quanto ele torna os sites mais rápidos!

O HTTP/3 realmente torna as coisas mais rápidas? Com certeza, e temos os benchmarks para provar isso.

Uma visualização rápida

Antes de nos aprofundarmos nos detalhes, vamos dar uma olhada rápida nos resultados do benchmark. Nos gráficos abaixo o mesmo navegador foi utilizado para solicitar o mesmo site, na mesma rede, variando apenas o protocolo HTTP em uso. Cada site foi recuperado 20 vezes e o tempo de resposta medido por meio da API de desempenho.

Você pode ver claramente a melhoria de desempenho à medida que cada nova versão do protocolo HTTP é usada:

Comparando as três versões do protocolo HTTP ao carregar páginas de NY

E as mudanças se tornam ainda mais claras ao solicitar recursos em distâncias geográficas maiores e redes menos confiáveis.

Mas antes que possamos entrar totalmente em todas as minúcias do benchmark HTTP/3, é necessário um pouco de contexto.

Uma Breve História do HTTP

A primeira versão oficial do HTTP (Hypertext Transfer Protocol 1.0) foi finalizada em 1996. Havia alguns problemas práticos e partes do padrão que precisavam ser atualizadas, então o HTTP/1.1 foi lançado um ano depois, em 1997.

De acordo com os autores:

No entanto, o HTTP/1.0 não leva em consideração suficientemente os efeitos de proxies hierárquicos, armazenamento em cache, a necessidade de conexões persistentes e hosts virtuais. Além disso, a proliferação de aplicativos implementados de forma incompleta que se autodenominam “HTTP/1.0” exigiu uma mudança na versão do protocolo para que dois aplicativos comunicantes determinassem as verdadeiras capacidades um do outro.

Levaria mais 18 anos até que uma nova versão do HTTP fosse lançada. Em 2015, e com muito alarde, o RFC 7540 padronizaria o HTTP/2 como a próxima versão principal do protocolo.

Um arquivo de cada vez

Se uma página da Web requer 10 arquivos javascript, o navegador da Web precisa recuperar esses 10 arquivos antes que a página possa terminar de carregar.

Em HTTP/1.1-land, o navegador da web só pode baixar um único arquivo por vez em uma conexão TCP com o servidor. Isso significa que os arquivos são baixados sequencialmente, e qualquer atraso em um arquivo bloquearia todo o resto por trás dele. Isso é chamado de bloqueio de cabeça de linha e não é bom para o desempenho.

Para contornar isso, os navegadores podem abrir várias conexões TCP com o servidor para paralelizar a recuperação de dados. Mas essa abordagem consome muitos recursos. Cada nova conexão TCP requer recursos de cliente e servidor, e quando você adiciona TLS na mistura, há muitas requisições de SSL acontecendo também. Uma maneira melhor era necessária.

Multiplexação com HTTP/2

O grande ponto do HTTP/2 era a multiplexação. Ele corrigiu problemas de bloqueio de cabeçalho de linha no nível do aplicativo, alternando para um formato binário over-the-wire que permitia downloads de arquivos multiplexados. Ou seja, um cliente pode solicitar todos os 10 arquivos de uma vez e começar a baixá-los todos em paralelo em uma única conexão TCP.

Infelizmente, o HTTP/2 ainda sofre de um problema de bloqueio de cabeçalho, apenas uma camada abaixo. O próprio TCP torna-se o elo fraco da cadeia. Qualquer fluxo de dados que perca um pacote deve esperar até que o pacote seja retransmitido para continuar.

No entanto, como a natureza paralela da multiplexação do HTTP/2 não é visível para os mecanismos de recuperação de perda do TCP, um pacote perdido ou reordenado faz com que todas as transações ativas sofram uma parada, independentemente de essa transação ter sido diretamente impactada pelo pacote perdido.

Na verdade, em ambientes de alta perda de pacotes, o HTTP/1.1 funciona melhor por causa das múltiplas conexões TCP paralelas que o navegador abre!

True Multiplexação com HTTP/3 e QUIC

Digite HTTP/3. A principal diferença entre HTTP/2 e HTTP/3 é qual protocolo de transporte eles usam.

Em vez de TCP, HTTP/3 usa um novo protocolo chamado QUIC.

O QUIC é um protocolo de transporte de uso geral destinado a resolver os problemas de bloqueio de cabeçalho que o HTTP/2 tem com o TCP.

Ele permite que você crie uma série de fluxos com estado (semelhante ao TCP) sobre UDP.

O protocolo de transporte QUIC incorpora multiplexação de fluxo e controle de fluxo por fluxo, semelhante ao fornecido pela camada de enquadramento HTTP/2. Ao fornecer confiabilidade no nível do fluxo e controle de congestionamento em toda a conexão, o QUIC tem a capacidade de melhorar o desempenho do HTTP em comparação com um mapeamento TCP

E melhore o desempenho do HTTP!

Comparativo HTTP/3

Para ver que tipo de diferença de desempenho o HTTP/3 faz, era necessária uma configuração de teste de benchmarking.

O HTML

Para aproximar mais de perto o uso real, a configuração do teste consistiu em três cenários - um site pequeno, um site com conteúdo pesado (muitas imagens e alguns JS) e um aplicativo de página única (pesado no JS).

Foi analisado vários sites do mundo real e calculado a média do número de imagens e arquivos JS para cada um, depois foram codificados alguns sites de demonstração que correspondiam a essas contagens (e tamanhos) de recursos.

  • Local Pequeno
  • 10 arquivos JS de 2kb a 100kb
  • 10 imagens de 1kb a 50kb
  • Tamanho total da carga útil 600 KB , total de 20 recursos de bloqueio
  • Site de conteúdo
  • 50 arquivos JS de 2kb a 1mb
  • 55 imagens que variam em tamanho de 1kb a 1mb.
  • Tamanho total da carga útil 10 MB , total de 105 recursos (veja cnn.com em algum momento nas ferramentas de desenvolvimento e você verá por que isso é tão grande)
  • Aplicativo de página única
  • 85 arquivos JS de 2kb a 1mb
  • 30 imagens que variam em tamanho de 1kb a 50kb.
  • Tamanho total da carga útil 15 MB , total de 115 recursos (veja JIRA em algum momento nas ferramentas de desenvolvimento)

O servidor

Caddy foi usado para servir todos os ativos e HTML.

  • Todas as respostas foram veiculadas Cache-Control: "no-store"para garantir que o navegador baixasse novamente todas as vezes.
  • TLS 1.2 foi usado para HTTP/1.1 e HTTP/2
  • O TLS 1.3 foi usado para HTTP/3.
  • 0-RTT foi habilitado para todas as conexões HTTP/3

Os locais

Os testes foram conduzidos do computador em Minnesota, para três datacenters separados hospedados pela Digital Ocean:

  • Nova York, EUA
  • Londres, Inglaterra
  • Bangalore, Índia

O cliente

Foi automatizado o navegador para solicitar a mesma página 20 vezes seguidas, aguardando 3 segundos após o carregamento da página para iniciar a próxima solicitação.

A conexão com a internet é avaliada em 200mbps. Nenhum outro aplicativo estava sendo executado no computador no momento da captura de dados.

Então, quão rápido é o HTTP/3?

Nova York, EUA

Aqui estão os tempos de resposta de HTTP/2 vs. HTTP/3 ao solicitar os três sites diferentes do datacenter de NY:

Comparando as versões dos protocolos HTTP/2 e HTTP/3 ao carregar páginas de NY

HTTP/3 é:

  • 200ms mais rápido para o Small Site
  • 325ms mais rápido para o site de conteúdo
  • 300ms mais rápido para o aplicativo de página única

A distância de Minnesota a Nova York é de 1.600 milhas, o que é bem pequeno para os padrões de rede. É significativo que, mesmo a uma distância relativamente curta, o HTTP/3 tenha conseguido melhorar tanto o desempenho.

Londres, Inglaterra

Veja a execução de benchmarking HTTP/1.1 para Londres nos resultados. Para mostrar o quanto HTTP/2 e HTTP/3 são mais rápidos, foi mantido os gráficos na mesma escala. Você pode ver que para o Site de Conteúdo, os tempos são tão lentos que nem cabem inteiramente no gráfico!

Comparando as três versões do protocolo HTTP ao carregar páginas de Londres

Como você pode ver, o aumento de velocidade é ainda mais pronunciado quando distâncias maiores na rede estão em jogo. HTTP/3 é:

  • 600ms mais rápido para o Small Site ( 3x a aceleração em comparação com Nova York)
  • 1200ms mais rápido para o site de conteúdo (mais de 3,5x a velocidade em comparação com Nova York)
  • 1000ms mais rápido para o aplicativo de página única (mais de 3x a velocidade em comparação com Nova York)

Bangalore, Índia

A melhoria de desempenho com HTTP/3 é extremamente pronunciada ao carregar páginas do servidor na Índia. Nem foi executadoum teste HTTP/1.1 porque era muito lento. Aqui estão os resultados de HTTP/2 vs. HTTP/3:

Comparando as três versões do protocolo HTTP ao carregar páginas da Índia

O HTTP/3 continua avançando quando geografias maiores e mais saltos de rede estão envolvidos. O que talvez seja mais impressionante é o quão bem agrupados são os tempos de resposta para HTTP/3.

O QUIC está tendo um grande impacto quando os pacotes estão viajando milhares de quilômetros.

Em todos os casos, o HTTP/3 foi mais rápido que seu antecessor!

Por que o HTTP/3 é muito mais rápido?

Multiplexação Real

A verdadeira natureza multiplexada do HTTP/3 significa que não há bloqueio de Head-of-line acontecendo em qualquer lugar da stack. Ao solicitar recursos de mais longe, geograficamente, há uma chance muito maior de perda de pacotes e a necessidade de o TCP retransmitir esses pacotes.

0-RTT é um divisor de águas

Além disso, o HTTP/3 suporta conexões O-RTT QUIC, o que reduz o número de viagens de ida e volta necessárias para estabelecer uma conexão TLS segura com o servidor.

O recurso 0-RTT no QUIC permite que um cliente envie dados do aplicativo antes que o handshake seja concluído. Isso é possível reutilizando parâmetros negociados de uma conexão anterior. Para habilitar isso, o 0-RTT depende do cliente lembrar de parâmetros críticos e fornecer ao servidor um tíquete de sessão TLS que permite ao servidor recuperar as mesmas informações.

No entanto, 0-RTT não deve ser ativado cegamente. Existem algumas possíveis preocupações de segurança, dependendo do seu modelo de ameaça.

As propriedades de segurança para dados 0-RTT são mais fracas do que para outros tipos de dados TLS. Especificamente:
  1. Esses dados não são secretos de encaminhamento, pois são criptografados exclusivamente sob chaves derivadas do PSK oferecido.
  2. Não há garantias de não repetição entre as conexões.

Posso usar HTTP/3 hoje?

Pode! Embora o protocolo esteja atualmente no status de rascunho da Internet , existem muitas implementações existentes .

O Caddy foi escolhido para esses benchmarks porque o HTTP/3 pode ser ativado com um valor de configuração simples noCaddyfile

O NGINX também tem suporte experimental e está trabalhando para um lançamento oficial do HTTP/3 em um futuro próximo.

Os grandes players de tecnologia como Google e Facebook já estão servindo seu tráfego por HTTP/3. O Google.com é totalmente servido por HTTP/3 para navegadores modernos.

Para aquelas pessoas presas no ecossistema do Windows, supostamente o Windows Server 2022 suportará HTTP/3, com algumas etapas bastante esotéricas necessárias para habilitá-lo.

Conclusão

O HTTP/3 pode fazer uma grande diferença na forma como os usuários experimentam seu site.

Em geral, quanto mais recursos seu site exigir, maior será a melhoria de desempenho que você verá com HTTP/3 e QUIC.

À medida que o padrão continua cada vez mais próximo da finalização, talvez seja hora de começar a ativá-lo para seus sites.🤟

Deixei sua opinião! É importante! 🥰