HTTP/3 já é quase um padrão

23 Jun 2021

Resumão para você se situar

O caminho percorrido em uma comunicação na web passa por algumas camadas, pra ser mais preciso sete ou quatro dependendo da sua religião. Independente do modelo implementado temos na primeira camada a Camada de Aplicação que é a mais próxima de você. Ela reúne protocolos como NTP para manter o seu relógio sincronizado; FTP para para fazer download e upload de arquivos; o BitTorrent que é muito utilizado para fazer download de filmes… distribuições Linux; e muitos outros.

Junto dessa turminha da pesada temos o protocolo HTTP, ele é um protocolo que foi desenvolvido originalmente para distribuir conteúdo hipertexto — ou seja, textos com hiperlinks que conseguem levar você a outros textos com hiperlinks.

A primeira versão definitiva foi o HTTP/0.9 publicado em 1991, que servia apenas para transferir texto de um servidor para um computador. Em 1996 veio o HTTP/1.0 que contava agora com a possibilidade de incluir outros tipos de arquivos numa página, como imagens, e o novo método POST para permitir que os usuários também pudessem enviar informações para um servidor: criando o que conhecemos hoje como os buscadores, mensagens em redes sociais e etc.

Já o HTTP/1.1 foi lançado em 1999 (por coincidência, o ano em que nasci) e com ele as páginas poderiam ser comprimidas no lado do servidor, e descomprimida no lado do cliente fazendo com que as páginas carregassem mais rápido e houvesse um consumo menor no tráfego de rede. Essa foi a versão usada por muito tempo, mais de uma década até a chegada do HTTP/2 em 2015 que surgiu dado ao avanço que a web teve: as páginas ficaram muito mais pesadas contendo muito mais imagens, vídeos, e recursos externos como fontes, CSS e JavaScript.

Parece que foi ontem que palestrei sobre performance de carregamento de página na comunidade WordPress Fortaleza e acabei falando do HTTP/2 e do recurso muito legal que vinha consigo que foi o Server Push que básicamente consistia em o servidor poder enviar para o cliente já na primeira requisição alguns assets para o client. O HTTP/1.1 é um protocolo sequencial, ou seja, ele primeiro irá requistar o index.html, após o client receber o documento e começar a ler, ele irá ver que na tag head possui um link rel stylesheet para um .css, entao o navegador irá solicitar o devido .css e esperar pelo retorno. Após o .css baixado, lido e parseado o browser continua com a leitura do HTML e encontra logo em seguida um script src para um .js, então o browser irá requisitar o devido .js e assim você já deve ter entendido o problema.

A versão 2 junto com Server Push veio para resolver esse tipo de problema, no momento que o client chega no servidor requisitando o index.html você poderia configurar o sevidor para que no momento de devolver o index.html ele falar: “Olha cliente, aproveita que você já ta aqui e leva também esses dois arquivos css e esse javascript aqui 😄”. Aproveitando a janela inicial de conexão e já enviando para o client em uma única ida esses dois .css e o .js, assim o cliente não precise ficar indo e voltando no servidor o que faz com que tenhamos um carregamento inicial da página mais veloz.

Outra grande novidade dele foi o uso de multiplexação, que de forma simplificada serve para dizer que o navegador abre uma única conexão para baixar múltiplos arquivos, as requisições e respostas agora são paralelas e assíncronas.

Chegamos então no HTTP/3

Lá em meados de 2018 quando eu estava usando o HTTP/2 eu lembro de notar que na aba Network do DevTools, específicamente do Chrome constava algo como ‘HTTP/2+quic/39’ e na época fui atrás de informações sobre esse tal QUIC e descobri que era um protocolo criado pela google mas não tinha dado muita atenção por ser exclusivo da Google e não rodar em outros browsers. Então o HTTP/3 funciona com base no QUIC e ganhou o apoio de gigantes na época como Cloudflare, Google e Mozilla e isso me deixou curioso e então vim explicar para vocês a nova geração do protocolo HTTP/3.

Anunciado em 2019 e atualmente (estou escrevendo esse post em junho de 2021) ele já é oficialmente um Internet Draft, porém ele já está ativado por padrão no Chrome desde abril de 2020 na versão 87 e no Firefox desde abril desse ano (2021) na sua versão 88. O Edge por ser baseado no Chromium seguiu o mesmo exemplo do Chrome também habilitando na mesma data e no mesmo núnero de versão. Já o Safari havia adicionado o suporte experimental ao Safari Technology Preview em 8 de abril de 2020 e foi programado para ser lançado oficialmente com o Safari 14 que vem com o macOS 11 Big Sur mas ele ainda está desabilitado por padrão.

“Blá blá blá… mas e o QUIC Gabriel?”
Então, o QUIC ele é um protocolo da Camada de Transporte e usa o UDP o que gerou algumas polêmicas pois a web sempre utilizou o TCP.

Então o HTTP/3 não garante a entrega do pacote?

Geralmente na faculdade (ou em algum curso que você tenha feito) nas aulas téoricas aprendemos que o TCP garante a entrega do pacote porém é mais lento, e o UDP é muito mais rápido porém ele não garante a entrega do pacote.

Já reparou que quando estamos em uma chamada de voz as vezes não conseguimos escutar em alguns momentos a voz da pessoa por completo e temos que falar: “Poderia repetir? Pois não consegui ouvir direito, sua voz cortou no final”. Esse tipo de aplicação utiliza o UDP pois nesse caso não precisamos garantir a entrega e sim a velocidade para conseguir propor a experiência de uma comunição em tempo real. Já o HTTP sempre utilizou o TCP pois precisamos garantir que todos os dados sejam recebidos (a web é lenta de nascença 😂).

Então é aí que entra o QUIC, ele adiciona umas camadas extra ao UDP com algumas características do TCP como retransmissão de pacotes, controle de congestionamento e outras, mantendo a velocidade. Com isso, um pacote enviado através do QUIC será sempre recebido pela outra ponta, cedo ou tarde, desde que a conexão permaneça ativa. Então o QUIC usa o UDP para ter mais velocidade e junta algumas funcionalidades do TCP para que se possa ter garantia da entrega do pacote.

No TCP todos os pacotes precisam ser entregues na ordem, já passou pela situação de abrir uma página da web e de repente, o carregamento trava por alguns segundos? Uma possível causa é que um dos pacotes enviados pelo TCP chegou corrompido e, como o TCP precisa fornecer os dados na ordem exata, os pacotes em seguida ficam aguardando até que o problemático seja entregue corretamente, atrasando assim toda a conexão.

Além do mais a forma antiga de transmissão de dados do HTTP, que consistia em enviar informações em texto puro, não existe mais com o QUIC. Todas as conexões em HTTP/3 serão feitas por meio do HTTPS e sempre criptografadas com TLS 1.3. Requisições para endereços http:// não serão mais atendidas pelo novo protocolo, garantindo assim segurança.

Você pode ver no Can I Use como está o suporte atual do HTTP/3 nos browsers.