O que é HTTP/3 – Informações básicas sobre o novo e rápido protocolo baseado em UDP

Publicados: 2019-03-20

TL;DR

Em novembro de 2018, a Força-Tarefa de Engenharia da Internet (IETF) se reuniu em Bangkok e um novo rascunho da Internet foi adotado. O protocolo de transporte QUIC, um sucessor do HTTP/2, foi renomeado para HTTP/3.

O HTTP/3 baseia-se no User Datagram Protocol (UDP) e já está sendo usado por empresas de internet proeminentes, como Google e Facebook. Se você estiver usando o Chrome e se conectando a um serviço do Google, provavelmente já está usando o QUIC.

A nova versão do protocolo HTTP se beneficia do protocolo UDP de baixo nível e bare-metal e define muitos dos novos recursos que estavam nas versões anteriores do HTTP na camada TCP. Isso fornece uma maneira de resolver restrições dentro da infraestrutura de Internet existente.

Os primeiros resultados são promissores e, quando o Internet Draft by IETF expirar, em agosto de 2021, podemos esperar que o HTTP/3 seja promovido como um novo padrão HTTP de terceira geração.

Assim como no HTTP/2, o HTTP/3 novamente se baseará nessas conquistas para ajudar a acelerar a web. Clique para Tweetar

Progresso HTTP/3 em 2022

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 mais RAM.

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

HTTP/3 é, no momento da redação deste artigo, um IETF Internet-Draft ou ID, o que significa que está atualmente sob consideração para um próximo padrão de internet pela Internet Engineering Task Force – um organismo internacional de padrões de internet , encarregado de definir e promover padrões de protocolo de internet acordados, como TCP, IPv6, VoIP, Internet das Coisas, etc.

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

Embora 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.

O que é HTTP/3 - Nos termos do leigo

HTTP/3 é a terceira versão do Hypertext Transfer Protocol (HTTP), anteriormente conhecido como HTTP-over-QUIC. O QUIC (Quick UDP Internet Connections) foi desenvolvido inicialmente pelo Google e é o sucessor do HTTP/2. Empresas como Google e Facebook já usam o QUIC para acelerar a web.

Suporte de navegador da Web para HTTP/3

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

Suporte de biblioteca para HTTP/3

Para desenvolvedores que desejam aproveitar as tecnologias HTTP/3, muitas bibliotecas populares já adicionaram suporte para HTTP/3. Como o HTTP/3 ainda está no estágio de Rascunho da Internet, convém certificar-se de estar sintonizado com as atualizações mais recentes ao trabalhar com uma das bibliotecas abaixo.

Python – http3 e aioquic
Ferrugem – quiche, neqo e quinn
C – nghttp3 e lsquic
Vai - rápido
JavaScript – Node.js

Suporte de infraestrutura para HTTP/3

No lado da infraestrutura, a Cloudflare tem liderado o caminho com suporte para HTTP/3 em toda a sua rede de borda. Isso significa que os sites habilitados para Cloudflare podem aproveitar os aprimoramentos 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 Cloudflare. Além de um firewall de nível empresarial e proteção contra DDoS, os clientes Kinsta também têm acesso ao HTTP/3!

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

Se o seu site for compatível com HTTP/3, você deverá ver uma mensagem como a abaixo. Como o kinstalife.com está hospedado no Kinsta, o HTTP/3 é totalmente suportado graças à nossa integração com Cloudflare.

Você também pode usar o inspetor do seu navegador para verificar o suporte a HTTP/3. Para este exemplo, usaremos a versão mais recente do Google Chrome compatível com 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 guia “Rede”. Na coluna “Protocolo”, você pode ver o protocolo HTTP usado 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, kinstalife.com suporta conexões em “h3-29”, que significa “HTTP/3 Draft 29”.

O Chrome é compatível com o protocolo h3-29.

Agora que analisamos o status atual do HTTP/3, vamos nos aprofundar em algumas das diferenças entre HTTP/2 e HTTP/3!

Um pouco de fundo – Começou com HTTP/2

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

O HTTP/2 tornou possível enviar mais de um recurso em uma única conexão TCP – multiplexação. Também obtivemos mais flexibilidade na ordenação de downloads estáticos e nossas páginas agora não são mais restritas por uma progressão linear dos downloads.

Na prática, isso significa que agora um grande recurso javascript não é necessariamente igual a um ponto de estrangulamento para todos os outros recursos estáticos aguardando sua vez.

Sem pipeline vs pipeline — Sem pipelining vs pipelining (Fonte da imagem: Wikipedia, Autor Mwhitlock)

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

As principais implementações de navegadores tornaram um requisito para os sites implementarem criptografia – SSL – para poder colher os benefícios do HTTP/2 – e às vezes isso gerava uma sobrecarga de computação que tornava as melhorias de velocidade imperceptíveis. Houve até alguns casos em que os usuários relataram lentidão após a transição para HTTP/2.

Digamos apenas que os primeiros dias de adoção desta versão não foram para os fracos de coração.

A implementação do Nginx também não tinha o recurso de envio de servidor, contando com um módulo. E os módulos Nginx não são os módulos comuns do Apache que você pode simplesmente copiar – o NGINX precisa ser recompilado com eles.

Embora alguns desses problemas estejam resolvidos agora, se observarmos toda a pilha de protocolos, veremos que a principal restrição está em um nível mais baixo do que o HTTP/2 ousou arriscar.

Para elaborar isso, dissecaremos a pilha de protocolos da Internet de hoje, desde a camada inferior até a superior. Se você quiser saber mais sobre os antecedentes do HTTP/2, não deixe de conferir nosso guia HTTP/2 definitivo.

Protocolo de Internet (IP)

O Internet Protocol (IP) define a parte inferior de toda a topologia da Internet. É a parte da pilha da Internet que, podemos dizer com segurança, realmente não é negociável sem mudar tudo, incluindo a substituição de toda a infraestrutura de hardware, de roteadores a servidores e até as máquinas dos usuários finais.

Portanto, embora a revisão do protocolo possa ser necessária, um empreendimento tão abrangente não está no horizonte neste momento, principalmente porque não encontramos uma alternativa viável, inovadora e compatível com versões anteriores.

Podemos traçar os primórdios do protocolo IP até 1974, em um artigo publicado pelo Instituto de Engenheiros Elétricos e Eletrônicos e de autoria de Vint Cerf e Bob Cahn. Detalhou os pacotes sendo enviados por uma rede, roteando-os através de endereços IP e endereços definidos numericamente de nós em uma rede/redes. O protocolo definiu o formato desses pacotes, ou datagramas – seus cabeçalhos e carga útil.

Após a definição da RFC 760 de 1980, o IETF se acomodou com a definição amplamente utilizada até hoje, em seu Request For Comments 791. Esta é a quarta versão do protocolo, mas poderíamos dizer que é a primeira versão de produção.

Protocolo de Internet (RFC791) — Protocolo de Internet (fonte de imagem: RFC791)

Ele usa endereços de 32 bits, o que define uma restrição ao número de endereços para cerca de 4 bilhões. Essa limitação é a explicação para o mistério de por que usuários de Internet não comerciais obtêm “endereços IP dinâmicos” por seus ISPs, e um IP estático é considerado um “valor agregado” e muitas vezes sujeito a cobranças extras.

Eles estão racionando.

Não demorou muito para que se percebesse que os endereços de 32 bits não são suficientes, e a escassez estava se aproximando, então muitos RFCs foram publicados tentando lidar com isso. Embora essas soluções sejam amplamente usadas hoje e façam parte de nossas vidas diárias, provavelmente é seguro dizer que elas equivalem a hacks.

O Internet Protocol versão 6 ou IPv6 veio como forma de suprir essas limitações, inclusive para ser adotado gradativamente em relação à versão anterior. Foi feito um documento Draft Standard para o IETF em 1998 e foi elevado a um padrão da Internet em 2017.

Enquanto o espaço de endereço IPv4 era limitado por seu comprimento de endereço de 32 bits, o padrão IPv6 recebia 128 bits, ou 3,4 * 10 ^ 38 endereços possíveis. Isso deve ser suficiente para durar por algum tempo.

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

O IP é uma camada rudimentar da pilha da internet, definindo as coisas mais básicas, sem garantias de entrega, integridade de dados ou ordenação de pacotes transmitidos. Por si só não é confiável. O formato de cabeçalho do IPv4 fornece uma soma de verificação de cabeçalho, que os nós de transmissão usam para verificar a integridade do cabeçalho. Isso o torna diferente da versão IPv6, que conta com a camada de link abaixo, permitindo que seja mais rápido.

Cabeçalho de datagrama da Internet (fonte de imagem: RFC791)

Entendendo o papel do TCP e UDP

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

TCP

Embora o IP seja a camada subjacente de todas as nossas comunicações online hoje, o TCP (Transmission Control Protocol) é uma parte de nível superior do conjunto de protocolos da Internet, fornecendo a confiabilidade necessária para a web, correio, transferência de arquivos (FTP) – para camadas/protocolos de aplicação da internet.

Isso inclui estabelecimento de conexão em várias etapas, com handshakes, ordem garantida de pacotes e retransmissão de pacotes perdidos. Ele fornece feedback (Acks) de entrega ao remetente e assim por diante. Há também computação de checksum para detectar erros.

Todas essas coisas indicam muitas etapas que tornam o TCP um protocolo confiável, tornando-o uma base dos serviços de Internet mais notórios que usamos hoje.

Sua especificação que data de 1974 (RFC 675) e 1981 (RFC 793) não mudou substancialmente até hoje.

A confiabilidade que o TCP oferece, no entanto, não vem sem um custo. A sobrecarga de todas as viagens de ida e volta exigidas por handshakes, feedback de entrega, garantias de pedidos e somas de verificação que podem ser consideradas fracas e redundantes. Tornou o TCP um gargalo da pilha de protocolos moderna. O HTTP/2 atingiu um patamar de melhorias de velocidade que podem ser alcançadas em cima do TCP.

UDP

O User Datagram Protocol (UDP) também é uma das partes do Internet Protocol Suite, com sua especificação que remonta a 1980 (RFC 768).

É, como o nome sugere, um protocolo sem conexão baseado em datagrama. O que significa que não há apertos de mão e não há garantias de pedido ou entrega. Isso significa que quaisquer etapas possíveis para garantir a entrega, a integridade dos dados e outras coisas são deixadas para a camada do aplicativo. Isso significa que um aplicativo construído em cima do UDP pode escolher as estratégias que irá empregar dependendo do caso concreto, ou pode possivelmente alavancar elementos da camada de link, como somas de verificação, para evitar sobrecarga.

Como o UDP é tão difundido quanto o TCP, é possível obter melhorias sem exigir atualizações de firmware em uma ampla gama de dispositivos conectados à Internet ou alterações significativas nos sistemas operacionais.

A implantação de novos protocolos é dificultada por muitos firewalls, NATs, roteadores e outros middle-boxes que permitem que apenas TCP ou UDP sejam implantados entre usuários e os servidores que eles precisam alcançar. – HTTP/3 explicado

Este tópico no Hacker News pode nos ajudar a entender o raciocínio por trás da construção da nova versão HTTP no topo da pilha de rede existente, em vez de reinventá-la (embora haja mais do que isso).

Lutando com problemas de tempo de inatividade e WordPress? Kinsta é a solução de hospedagem projetada para economizar seu tempo! Confira nossas funcionalidades

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

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

QUIC e HTTP/3

O QUIC (Quick UDP Internet Connections) foi implantado pela primeira vez pelo Google em 2012. Ele redefine os limites das camadas de rede, contando com protocolo UDP de nível inferior, redefinindo handshakes, recursos de confiabilidade e recursos de segurança no "espaço do usuário", evitando a necessidade de atualização de kernels de sistemas de toda a Internet.

Assim como com o HTTP/2, um avanço que foi liderado pelo SPDY ou speedy do Google, o HTTP/3 novamente se baseará nessas conquistas.

Embora o HTTP/2 tenha nos proporcionado multiplexação e mitigado o bloqueio de cabeça de linha, ele é limitado pelo TCP. Você pode usar uma única conexão TCP para vários fluxos multiplexados juntos para transferir dados, mas quando um desses fluxos sofre uma perda de pacote, toda a conexão (e todos os seus fluxos) são mantidos reféns, por assim dizer, até que o TCP faça sua coisa ( retransmite o pacote perdido).

Isso significa que todos os pacotes, mesmo que já estejam transmitidos e aguardando, no buffer do nó de destino, estão sendo bloqueados até que o pacote perdido seja retransmitido. Daniel Stenberg em seu livro sobre http/3 chama isso de “head of line block baseado em TCP”. Ele afirma que, com 2% de perda de pacotes, os usuários se sairão melhor com HTTP/1, com seis conexões para cobrir esse risco.

O QUIC não é limitado por isso. Com o QUIC baseado no protocolo UDP sem conexão, o conceito de conexão não carrega as limitações do TCP e as falhas de um fluxo não precisam influenciar o resto.

Como Lucas Pardue da Cloudflare colocou:

Com foco em fluxos UDP, o QUIC consegue multiplexação sem ter que pegar carona em uma conexão TCP. O QUIC constrói sua conexão em um nível mais alto que o TCP. Novos fluxos dentro de conexões QUIC não são forçados a esperar que os outros terminem. As conexões QUIC também se beneficiam de eliminar a sobrecarga de handshake TCP, o que reduz a latência.

O pessoal da Cisco fez um vídeo interessante explicando o handshake de 3 vias do TCP:

Enquanto o QUIC elimina os recursos de confiabilidade do TCP, ele compensa isso acima da camada UDP, fornecendo retransmissão de pacotes, ordenação e assim por diante. O Google Cloud Platform introduziu o suporte QUIC para seus balanceadores de carga em 2018 e observou uma melhoria no tempo médio de carregamento da página em 8% globalmente e até 13% em regiões onde a latência é maior.

Entre Google Chrome, YouTube, Gmail, busca do Google e outros serviços, o Google conseguiu implantar o QUIC em um bom pedaço da internet, sem esperar pelo IETF. Os engenheiros do Google afirmam que em 2017, 7% do tráfego de internet já era realizado pelo QUIC.

A versão do QUIC do Google foi focada apenas no transporte HTTP, usando a sintaxe HTTP/2. O pessoal do IETF (responsável pela padronização do QUIC), decidiu que a versão IETF do QUIC deveria ser capaz de transportar mais do que apenas HTTP. Por enquanto, no entanto, qualquer trabalho em protocolos não HTTP sobre QUIC está em espera.

Mais uma coisa que o grupo de trabalho da IETF decidiu é que a versão padronizada usará criptografia TLS 1.3 em vez da solução personalizada do Google. O TLS 1.3, comparado às versões mais antigas, também contribui para a velocidade do protocolo, pois seus handshakes exigem menos viagens de ida e volta. Kinsta suporta TLS 1.3 em todos os nossos servidores e nossa Kinsta CDN.

No momento, o Google continua a usar sua própria versão do QUIC em seu produto, enquanto direciona seus esforços de desenvolvimento para os padrões da IETF. A maioria dos outros players da Internet está construindo em cima da versão IETF (os dois diferem em alguns outros aspectos além da criptografia).

Se abrirmos o Chrome Dev Tools e carregarmos alguns produtos do Google, como o Gmail, na coluna Protocolo da guia Rede, veremos muitos recursos sendo carregados por meio da versão do protocolo QUIC do Google. Este também é o caso dos produtos do Google, como Analytics, Google Tag Manager, etc.

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

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

O TCP tem sido o protocolo principal por anos, enquanto o UDP não, então os sistemas operacionais e a pilha de software para ele, em geral, não são tão otimizados. Consequentemente, há muito mais carga/requisitos de CPU com QUIC, segundo algumas estimativas, duas vezes mais do que com HTTP/2.

As otimizações vão até o kernel dos sistemas operacionais e diferentes firmwares de roteadores e dispositivos. Este guia de ajuste do Red Hat pode esclarecer mais sobre o assunto para aqueles mais tecnicamente inclinados.

Poderíamos dizer que o QUIC tenta reprojetar os recursos do TCP em cima de um protocolo mais mínimo e mais flexível.

As conexões QUIC, que mencionamos anteriormente, combinam TLS e handshakes de transporte. Uma vez estabelecidos, eles são identificados por CIDs (IDs de conexão) exclusivos. Esses IDs persistem nas alterações de IP e podem ajudar a proteger downloads ininterruptos em, por exemplo, uma mudança de 4G para WiFi. Isso é relevante, principalmente porque cada vez mais tráfego de internet é realizado em dispositivos móveis. Podem surgir dúvidas se esse elemento foi concebido pelo Google para facilitar um melhor rastreamento de usuários em diferentes conexões e provedores de Internet.

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

Os fluxos QUIC são enviados por conexões QUIC, unidirecionais ou bidirecionais. Os fluxos têm IDs que identificam o iniciador e se o fluxo é unidirecional ou bidirecional e também atendem ao controle de fluxo no fluxo.

Enquanto QUIC é um protocolo de camada de transporte, HTTP é a camada acima disso, um protocolo de camada de aplicação ou protocolo de aplicação.

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

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

Resumo

Há aqueles que pensam que, com o padrão HTTP/2 ainda não sendo totalmente adotado, pode ser muito cedo para fazer um esforço generalizado para o HTTP/3. Este é um ponto válido, mas, como mencionamos, esse protocolo já passou por testes e implementações em larga escala. O Google começou a testá-lo já em 2015, assim como o Facebook em 2017.

Em 2022, teremos suporte HTTP/3 dos principais navegadores, como Google Chrome e Brave. Na frente de infraestrutura, servidores web como Litespeed e Nginx têm implementações funcionais de HTTP/3, enquanto provedores de rede como Cloudflare já implantaram suporte total para HTTP/3.

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