O Que é HTTP/3 – A Verdade Sobre o Novo Protocolo Baseado em UDP

TL;DR

Em novembro de 2018, a Internet Engineering Task Force (IETF) se reuniu em Bangkok e um novo Internet Draft foi adotado. O protocolo de transporte QUIC, sucessor do HTTP/2, foi renomeado para HTTP/3.

O HTTP/3 é baseado em UDP e já está sendo usado por empresas importantes na Internet, como Google e Facebook. Se você está usando o Chrome e se conectando a um serviço Google, provavelmente já está utilizando QUIC.

A nova versão do protocolo HTTP se beneficia de um protocolo bare-metal e de UDP de baixo nível, e define muitos dos novos recursos que estavam, em versões prévias do HTTP, na camada TCP. Isso oferece uma forma de resolver restrições dentro da infraestrutura de Internet existente.

Os primeiros resultados são promissores e quanto a Internet Draft da IETF expirar, em agosto 2021, podemos esperar que o HTTP/3 seja promovido como a nova e terceira geração do padrão HTTP.

Progresso HTTP/3

Alguns dizem que a fome da indústria da web por mais velocidade e menor latência só é correspondida pela fome do Google Chrome por memória RAM.

Há alguns anos, publicamos um artigo sobre HTTP/2, um padrão que, de acordo com a W3Techs, atingiu agora uma taxa de adoção mundial de cerca de 45%. E de acordo com o Can I Use, ele também é suportado por todos os navegadores modernos da web. No entanto, aqui estamos nós, escrevendo um artigo sobre a próxima versão do protocolo, HTTP/3.

HTTP/3 até o momento em que esse artigo é escrito, a Internet Draft ou ID da IETF, o que significa que atualmente está sendo considerado para ser o próximo padrão da Internet pela Internet Engineering Task Force – um corpo de padrões de Internet internacional encarregado de definir e promover um acordo sobre padrões de protocolo de Internet, como TCP, IPv6, VoIP, Internet das Coisas, etc.

É um corpo aberto que une a indústria web e facilita a discussão sobre a direção da internet. Atualmente, a fase “Internet Draft” do HTTP/3 é a última fase antes das propostas serem promovidas ao nível de Request-for-Comments (ou RFCs), que podemos considerar, para todos os efeitos, as definições oficiais do protocolo da Internet.

Mesmo que o HTTP/3 ainda não seja um protocolo oficial da Internet, muitas empresas e projetos já começaram a adicionar suporte ao HTTP/3 em seus produtos.

Suporte de navegador web para HTTP/3

Na frente do navegador web, Chrome v87, Firefox v88 e Edge v87 têm HTTP/3 habilitado por padrão. Para usuários Safari, a opção de habilitar HTTP/3 foi adicionada ao Safari Technology Preview v104. Entretanto, o suporte a HTTP/3 não está atualmente disponível na versão estável do Safari.

Suporte de biblioteca para HTTP/3

Para desenvolvedores que buscam alavancar as tecnologias HTTP/3, muitas bibliotecas populares já adicionaram suporte ao HTTP/3. Como o HTTP/3 ainda está na fase de elaboração da Internet, você vai querer ter certeza de que está sintonizado com as últimas atualizações ao trabalhar com uma das bibliotecas abaixo.

• Python – http3 e aioquic
• Rust – quiche, neqo, e quinn
• C – nghttp3 e lsquic
• Go – quicgo
• JavaScript – Node.js

Suporte de infraestrutura para HTTP/3

No lado da infraestrutura, o Cloudflare tem liderado o caminho com suporte para HTTP/3 em toda a sua rede de fronteira. Isto significa que os sites com Cloudflare habilitado podem tirar proveito das melhorias de segurança e desempenho do HTTP/3 sem nenhum trabalho adicional.

Na Kinsta, todos os sites que hospedamos são protegidos por nossa integração gratuita com o Cloudflare. Além de um firewall de nível empresarial e proteção DDoS, os clientes da Kinsta também têm acesso ao HTTP/3!

Para testar se seu site suporta HTTP/3, você pode usar a ferramenta de teste HTTP/3 da Geekflare. Basta digitar em seu domínio e pressionar o botão “Check HTTP/3”, e a ferramenta lhe avisará se seu site está habilitado para HTTP/3.

Se o seu site suporta HTTP/3, você deve ver uma mensagem como a que está abaixo. Como o kinstalife.com está hospedado na Kinsta, o HTTP/3 é totalmente suportado graças a nossa integração com o Cloudflare.

Você também pode usar o inspetor do seu navegador para verificar o suporte ao HTTP/3. Para este exemplo, estaremos usando a última versão do Google Chrome que suporta o HTTP/3.

Para abrir o inspetor, clique com o botão direito do mouse na página e clique em “Inspecionar” e navegue até a aba “Rede”. Na coluna “Protocolo”, você pode ver o protocolo HTTP utilizado para a conexão. As conexões HTTP/2 aparecem como “h2”, enquanto as conexões HTTP/3 aparecem como “h3-XX” (XX refere-se a um rascunho HTTP/3 específico). Como você pode ver na imagem abaixo, o kinstalife.com suporta conexões sobre “h3-29”, que significa “HTTP/3 Draft 29”.

Agora que revisamos o status atual do HTTP/3, vamos mergulhar fundo em algumas das diferenças entre HTTP/2 e HTTP/3!

Um pouco do histórico – Tudo começou com o HTTP/2

HTTP/2 trouxe diversas séries de melhorias com downloads non-blocking, pipelining e push de servidor que nos ajudaram a superar algumas limitações do protocolo TCP subjacente. Isso nos permitiu minimizar o número de ciclos de solicitação-resposta e handshakes.

HTTP/2 tornou possível impulsionar mais de um recurso em uma única conexão TCP – multiplexação. Nós também recebemos mais flexibilidade na ordem de downloads estáticos e nossas páginas agora não estão mais limitadas por uma progressão linear de downloads.

Na prática, isso significa que agora um grande recurso Javascript não necessariamente cria um gargalo para todos os outros recursos estáticos que aguardam sua vez para serem carregados.

Adicione a esses elementos a compressão HPACK do cabeçalho HTTP/2 e o formato binário padrão de transferência de dados e temos, em muitos casos, um protocolo significativamente mais eficiente.

Implementações de grandes navegadores tornaram um requisito para os websites implantar criptografia – SSL – para que fossem capazes de colher os benefícios do HTTP/2 e em algumas situações, isso incorreu em uma sobrecarga computacional que deixou as melhorias na velocidade imperceptíveis. Em alguns casos, os usuários até mesmo relataram lentidão após a transição para HTTP/2.

Digamos apenas que os primeiros dias da adoção dessa versão não foram ideais para quem tinha o coração fraco.

A implementação Nginx também não apresentava o recurso push do servidor, dependendo de um módulo. E os módulos Nginx não são seus módulos drop-in Apache usuais que podem ser copiados – o Nginx precisa ser recompilado com eles.

Embora alguns problemas tenham sido resolvidos, se olharmos para a pilha de protocolos, veremos que a limitação primária está em um nível mais baixo do que o HTTP/2 ousou se aventurar.

Para elaborar melhor, vamos dissecar a pilha do protocolo de Internet atual de sua camada inferior até a superior. Se você quer saber mais sobre o histórico do HTTP/2, dê uma olhada em nosso guia definitivo do HTTP/2.

Protocolo de Internet (IP)

O Protocolo de Internet (IP) define a parte inferior da topologia inteira da Internet. É a parte da pilha da Internet que, podemos afirmar com segurança, não é negociável a menos que se altere tudo, o que inclui substituir a infraestrutura inteira de hardware, desde roteadores a servidores, e até mesmo as máquinas dos usuários finais.

Portanto, embora a inspeção do protocolo possa estar pendente, tal esforço de longo alcance não está no horizonte desta vez, principalmente porque não criamos uma alternativa viável, inovadora e ainda assim retrocompatível.

Podemos traçar o início do protocolo IP em 1974, em um artigo publicado pelo Instituto de Engenheiros Eletricistas e Eletrônicos e de autoria de Vint Cerf e Bob Cahn. Ele detalhou pacotes sendo enviados através de uma rede, encaminhados por endereços IP e endereços definidos numericamente por nós em uma rede ou redes. O protocolo definiu o formato desses pacotes ou datagramas – seus cabeçalhos e payload.

Após a definição RFC 760 de 1980, a IETF estabeleceu a definição amplamente usada até hoje, em sua Request for Comments 791. Essa é a quarta versão do protocolo, mas poderíamos dizer que se trata da primeira versão de produção.

Ele usa endereços de 32-bits, o que limita o número de possibilidades de endereços em torno de quatro bilhões. Essa limitação é a explicação do mistério do porquê usuários não comerciais na Internet recebem “endereços IP dinâmicos” de seus ISPs, enquanto um IP estático é considerado um “valor adicional” e frequentemente fica sujeito a cobranças extras.

Eles estão raciocinando.

Não demorou muito para se perceber que tais endereços de 32-bits eram insuficientes e sua escassez era iminente, por isso muitas RFCs foram publicadas tentando lidar com a situação. Embora essas soluções sejam amplamente usadas hoje e façam parte de nossas vidas diariamente, é possível afirmar com segurança que elas correspondem a hacks.

O Protocolo de Internet versão 6 ou IPv6 surgiu como uma forma de endereçar essas limitações, incluindo ser adotado gradualmente no lugar de sua versão anterior. Um documento de Rascunho Padrão foi criado para a IETF em 1998 e foi promovido a um Padrão da Internet em 2017.

Enquanto o espaço de endereços IPv4 era limitado pelo comprimento de 32-bits, ao padrão IPv6 foram atribuídos 128 bits ou 3,4 * 10 ^ 38 endereços possíveis. Isso deverá ser suficiente por um bom tempo.

De acordo com o Google e a conectividade do IPv6 entre seus usuários, a adoção do IPv6 era de pouco mais de 35% até junho de 2021.

IP é uma camada rudimentar da pilha da Internet e define os detalhes mais básicos sem garantias de entrega, integridade de dados ou pedidos de pacotes transmitidos. Ele sozinho não é confiável. O formato do cabeçalho do IPv4 oferece uma soma de verificação, que os nós de transmissão usam para conferir a integridade do cabeçalho. Isso o torna diferente da versão IPv6, que depende da camada de links inferior, permitindo que seja mais veloz.

Entendendo o Papel de TCP e UDP

Agora é hora de explorar onde o HTTP/3 se encaixa com TCP e UDP.

TCP

Enquanto o IP é a camada subjacente de todas as nossas comunicações online hoje, o TCP (Protocolo de Controle de Transmissão) é uma parte de nível elevado do conjunto do protocolo de Internet, oferecendo a confiabilidade que é necessária para a rede, e-mails, transferência de arquivos (FTP) – para camadas/protocolos de aplicações da Internet.

Isso inclui o estabelecimento de conexão de passos múltiplos, com handshakes, organização de pacotes garantida e retransmissão de pacotes perdidos. Isso oferece feedbacks (ACKs) de entrega para o remetente e assim por diante. Também há soma de verificação de computação para detectar erros.

Tudo isso indica muitos passos que fazem do TCP um protocolo confiável, tornando-o a fundação para os serviços de Internet mais notáveis que usamos atualmente.

Sua especificação, que retoma 1974 (RFC 675) e 1981 (RFC 793), não foi alterada substancialmente até hoje.

No entanto, a confiabilidade que o TCP oferece não vem sem um custo. A sobrecarga de todas as idas e voltas requeridas pelos handshakes, feedbacks de entrega, garantias de pedidos e somas de verificação que poderiam ser consideradas fracas e redundantes tornou TCP um gargalo da pilha do protocolo moderno. HTTP/2 atingiu uma plenitude de melhorias de velocidade que só podem ser conquistadas com TCP.

UDP

(UDP) Protocolo de Datagrama de Usuário também é uma das partes do Conjunto de Protocolo de Internet, com sua especificação estabelecida em 1980 (RFC 768).

Ele é conforme seu nome sugere, um protocolo sem conexões baseado em datagrama. O que significa que não há handshakes e garantias de pedidos ou entrega. Isso quer dizer que quaisquer passos possíveis para garantir entrega, integridade de dados e outros fatores ficam a cargo da camada da aplicação. Assim, uma aplicação que seja formada sobre UDP pode escolher estratégias para implementar, dependendo do caso concreto, ou pode possivelmente impulsionar elementos como camada de links, como somas de verificação até evitar sobrecargas.

Como o UDP está difundido como o TCP, ele possibilita alcançar melhorias sem exigir atualizações de firmware em uma ampla gama de dispositivos conectados à Internet, ou mudanças significativas nos sistemas operacionais.

A implementação de novos protocolos é dificultada por muitos firewalls, NATs, roteadores e outros dispositivos de rede que permitem apenas que TCP ou UDP sejam implantados entre os usuários e os servidores que eles precisam atingir.
– Explicação sobre HTTP/3

Essa publicação na Hacker News pode nos ajudar a começar a entender a razão por trás do desenvolvimento da nova versão HTTP sobre a pilha de rede existente, ao invés de reinventá-la (embora exista mais do que simplesmente isso).

A especificação do formato de pacote UDP é mínima, seu cabeçalho consiste da porta de origem, porta de destino, comprimento em bytes do cabeçalho do pacote e dados do pacote, além da soma de verificação. Ela pode ser usada para verificar a integridade de dados tanto para o cabeçalho quando para a parte de dados do pacote.

A soma de verificação é opcional quando a camada de protocolo subjacente é o IPv4 e mandatória para o IPv6. Até agora, o UDP tem sido usado para coisas como a sincronização de relógio de sistemas de computador (NTP), aplicações VoIP, transmissão de vídeos, sistema DNS e protocolo DHCP.

QUIC e HTTP/3

QUIC (Quick UDP Internet Connections) foi implementado primeiramente pelo Google em 2012. Ele redefiniu limites das camadas de rede, dependendo do protocolo UDP de baixo nível, redefinindo handshakes, recursos de confiabilidade e de segurança no “espaço do usuário”, evitando a necessidade de upgrade de kernels dos sistemas em toda a Internet.

Assim como ocorreu com HTTP/2, um avanço que foi impulsionado pelo SPDY do Google, o HTTP/3 será desenvolvido novamente sobre essas conquistas.

Embora o HTTP/2 tenha nos dado multiplexação e mitigado o bloqueio de head-of-line, ele é limitado por TCP. Você pode usar uma conexão única de TCP para múltiplas correntes multiplexadas em conjunto para transferir dados, mas quando uma delas sofre a perda de um pacote, a conexão inteira (e todas as suas correntes) é mantida refém, até que TCP faça seu papel (retransmitir o pacote perdido).

Isso significa que todos os pacotes, mesmo que já tenham sido transmitidos e estejam aguardando no buffer do nó de destino, são bloqueados até que o pacote perdido seja retransmitido. Daniel Stenberg, em seu livro sobre htttp/3, dá a isso o nome de “bloqueio de head-of-line baseado em TCP”. Ele afirma que, com uma perda de 2% de pacote, os usuários se sairão melhor com o HTTP/1, com seis conexões para se proteger contra o risco.

QUIC não é limitado por isso. Com QUIC desenvolvido sobre um protocolo UDP sem conexão, o conceito de conexão não carrega as limitações de TCP e falhas que ocorram em uma corrente não têm influência sobre o restante.

Como Lucas Pardue da Cloudflare aponta:

Com um foco em correntes UDP, QUIC alcança multiplexação sem ter que ficar sobre uma conexão TCP. QUIC desenvolve sua conexão em um nível mais alto que TCP. Novas correntes dentro de conexões QUIC não são forçadas a aguardar até que as outras sejam finalizadas. Conexões QUIC também se beneficiam ao eliminar a sobrecarga do handshake do TCP, o que reduz a latência.

O pessoal da Cisco criou um vídeo interessante explicando o handshake de três vias do TCP.

Embora o QUIC acabe com os recursos de confiabilidade do TCP, ele compensa com a camada UDP, oferecendo retransmissão de pacotes, pedidos e assim por diante. Google Cloud Platform introduziu suporte QUIC para seus balanceamentos de carga em 2018 e viu uma melhoria no tempo médio de carregamento de página em 8% globalmente e de até 13% em regiões onde a latência é maior.

Entre Google Chrome, YouTube, Gmail, pesquisas no Google e outros serviços, o Google foi capaz de implementar QUIC em uma boa parte da Internet, sem esperar pela IETF. Os engenheiros do Google alegam que, em 2017, 7% do tráfego na Internet já era conduzido por QUIC.

A versão do Google do QUIC era focada apenas no transporte de HTTP, usando sintaxe do HTTP/2. Pessoas da IETF (que estão encarregadas de padronizar o QUIC) decidirão se a versão IETF do QUIC deveria ser capaz de transportar mais que apenas HTTP. Até o momento, no entanto, todo trabalho de protocolos não-HTTP sobre QUIC estão em modo de espera.

Mais um fator decidido pelo grupo que trabalha na IETF é que a versão padronizada utilizará criptografia TLS 1.3 ao invés da solução personalizada do Google. TLS 1.3. Quando comparado às versões mais antigas, ele também contribui para a velocidade do protocolo, uma vez que seus handshakes exigem menos idas e voltas. Kinsta suporta TLS 1.3 em todos os nossos servidores e nosso Kinsta CDN.

Neste momento, o Google continua usando sua própria versão do QUIC em seus produtos, ao mesmo tempo em que volta seus esforços de desenvolvimento em direção aos padrões IETF. A maioria dos demais players da Internet estão fazendo seus desenvolvimentos sobre a versão da IETF (os dois diferem em alguns aspectos que vão além da criptografia).

Se abrirmos o Chrome Dev Tools e carregarmos alguns produtos do Google, como Gmail, veremos na coluna Protocolo da aba Rede que diversos recursos sendo carregados pela versão do Google do protocolo QUIC. Esse também é o caso com outros produtos, como Analytics, Google Tag Manager, etc.

Cloudflare publicou uma extensa atualização sobre o progresso da padronização.

Embora UDP ofereça ao QUIC e HTTP/3 algumas vantagens inerentes, ele também traz alguns desafios.

TCP tem sido o protocolo convencional por anos, enquanto o UDP não, assim os sistemas operacionais e pilhas de softwares para ele não são tão otimizados de forma geral. Consequentemente, há cargas/requisitos de CPU muito mais altos com QUIC que, de acordo com algumas estimativas, são o dobro do HTTP/2.

As otimizações se aprofundam até o kernel dos sistemas operacionais, diferentes roteadores e firmware de dispositivos. Esse guia de ajustes do Red Hat pode iluminar um pouco o tópico para aqueles que possuem uma inclinação mais técnica.

Poderíamos dizer que QUIC tenta reconfigurar recursos TCP sobre um protocolo minimizado e mais flexível.

Conexões QUIC, que mencionamos anteriormente, combinam TLS e handshakes de transporte. Uma vez estabelecidas, elas são identificadas por CIDs únicas (IDs de conexão). Esses IDs persistem ao longo das mudanças de IP e podem ajudar a garantir downloads ininterruptos em, por exemplo, uma mudança de 4G para WiFi. Isso é relevante, principalmente porque cada vez mais o tráfego da Internet é conduzido em dispositivos móveis. Questões podem surgir se o elemento é concebido pelo Google para facilitar melhor monitoramento de usuário em diferentes conexões e provedores de Internet.

TLS é obrigatório e destina-se a dificultar a falsificação de dispositivos no meio ou perda de tráfego. É por isso que não é raro ver provedores de firewall e fornecedores, como a Cisco, encarando o protocolo UDP como um problema e oferecendo formas de desativá-lo. É mais difícil para intermediários inspecionar e supervisionar ou filtrar o tráfego do QUIC.

Correntes QUIC são enviadas através de conexões QUIC, unidirecionais ou bidirecionais. Correntes têm IDs que identificam o iniciador e se ele é unidirecional ou bidirecional, além de servir como controle de fluxo na corrente.

Embora o QUIC seja um protocolo de camada de transporte, HTTP é a camada acima dele, um protocolo de camada de aplicação ou o protocolo de aplicação em si.

Como a compatibilidade com versões anteriores é de extrema importância, a IETF divulgou que a implementação do HTTP/3 incluirá a versão antiga (HTTP/1 ou HTTP/2) na resposta. Ele incluirá um cabeçalho que informa ao cliente que HTTP/3 está disponível, juntamente com informações de porta/host, conforme descrito na RFC 7838.

Isso é diferente do HTTP/2, no qual o transporte pode ser negociado no handshake de TLS. Mas como a IETF adotou o HTTP/3 baseado em QUIC como o próximo padrão, podemos esperar que os clientes web antecipem cada vez mais o suporte para HTTP/3. É possível que os clientes armazenem em cache os dados de conexões HTTP/3 anteriores e se conectem diretamente (sem ida e volta ou 0-RTT) em visitas subsequentes ao mesmo host.

Resumo

Existem aqueles que acreditam que, com o padrão HTTP/2 ainda não sendo adotado completamente, pode ser cedo demais para promover o HTTP/3. Esse é um ponto válido, mas como mencionamos, esse protocolo já passou por testes e implementações em grande escala. O Google começou a testá-lo em 2015, enquanto o Facebook em 2017.

Temos suporte HTTP/3 dos principais navegadores como Google Chrome e Brave. Na frente da infraestrutura, servidores web como Litespeed e Nginx têm ambas implementações de HTTP/3 em funcionamento, enquanto provedores de rede como o Cloudflare já implantaram suporte total ao HTTP/3.

Neste momento, o HTTP/3 ainda está na fase de rascunho da Internet, e a revisão mais recente está prevista para expirar em agosto de 2021. Este ano será emocionante, pois podemos esperar ver a mudança dos principais fornecedores de software para implementar o novo padrão.

Tonino Jankov

Tonino is an entrepreneur, Linux & OSS enthusiast, developer, and tech educator. He has over ten years of experience in development and has been in the blockchain space for 3+ years. When he's not coding, he writes for SitePoint and Alibaba Cloud, binge-watches the newest works of fiction on Netflix, and explores new travel destinations.

• Twitter