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 junho de 2019, podemos esperar que o HTTP/3 seja promovido como a nova e terceira geração do padrão HTTP.

Assim como com o HTTP/2, HTTP/3 novamente se baseará nessas conquistas para ajudar a acelerar a web. 🚀 Click to Tweet

HTTP/3 Está Chegando

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.

Em 2016, publicamos um artigo sobre HTTP/2, um padrão que, de acordo com a W3Techs, tem uma taxa de adoção mundial de cerca de 34% atualmente. E de acordo com a Can I use, ele também é suportado por todos os navegadores modernos. Ainda assim, aqui estamos nós escrevendo um artigo sobre a próxima versão do protocolo: HTTP/3.

Uso de HTTP/2

Uso de HTTP/2

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.

Atualmente, a fase ID do HTTP/3 é a última antes que propostas sejam feitas no nível das RFCs (Request for Comments), o que podemos considerar, para todas as intenções e finalidades, como as definições do protocolo de Internet oficial. Na sequência, elas são implementadas por todos os principais players da Internet.

Isso significa que o HTTP/3 se tornará um padrão oficial quando seu rascunho expirar mais adiante neste ano (junho de 2019).

Um Pouco do Histórico – Tudo Começou com HTTP/2

Na Kinsta, somos obcecados em extrair cada milissegundo de nossa pilha, seja tirando vantagem da nova versão de PHP, entregando dados através da rede de camada premium do Google Cloud Platform ou armazenando ativos em cache em nossa CDN 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.

Push HTTP/2

Push HTTP/2

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.

Sem pipelining versus pipelining

Sem pipelining versus pipelining (Fonte da imagem: Wikipedia, Autor: Mwhitlock)

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.

Compressão HPACK HTTP/2

Compressão HPACK HTTP/2

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.

Abaixo está a camada de ligação – a parte do protocolo que é “bare metal”.

Uma observação: um caso convincente para uma inspeção completa pode ser visto na velocidade com a qual os criadores do IPFS (Interplanetary File System) administraram para concluir um levantamento de fundos em um IPO que gerou US$250 milhões em um mês.

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 25% até março de 2019. 

Adoção do IPv6

Adoção do IPv6

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.

Cabeçalho do Datagrama da Internet

Cabeçalho do Datagrama da Internet (Fonte da imagem: RFC791)

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.

Alterar o TCP em qualquer forma substancial não é um esforço direto, pois o protocolo é, como uma parte da pilha de TCP/IP que remonta os anos 70. Ele está profundamente incorporado aos sistemas operacionais, firmware de dispositivos, etc.

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 UDP é bastante difundido como TCP, ele torna possível que melhorias sejam alcançadas sem precisar de uma ampla mudança do firmware em todos os dispositivos conectados à Internet ou alterações 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.

Pilha HTTP/2 versus pilha HTTP/3

Pilha HTTP/2 versus pilha HTTP/3

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:

Lucas Pardue sobre HTTP/3

Lucas Pardue sobre HTTP/3

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 supports TLS 1.3 on aO Kinsta suporta o TLS 1.3 em todos os nossos servidores e no nosso Kinsta CDN.ll of our servers and our 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.

Serviços do Google com QUIC

Serviços do Google com QUIC

Cloudflare recentemente 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 (versão três). 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.

Desde então, outros players se juntaram aos esforços de padronização, como Akamai e Mozilla. No último hackaton da IETF em novembro de 2018, a lista de participantes que mostraram interesse em QUIC contava com empresas como Facebook, Apple, Google, Mozilla, NetApp e LiteSpeed Tech. Houveram testes promissores e tudo aponta que o LiteSpeed Tech seja o primeiro grande fornecedor de servidores a disponibilizar um servidor funcionando em HTTP/3. Cloudflare também está rodando atualmente o QUIC na versão beta.

Um pouco depois disso, QUIC foi renomeado para HTTP/3 no Internet Draft da IETF. Ele expirará em junho de 2019 e podemos esperar ver a RFC ou o padrão final em algum momento em julho.

Esse ano será empolgante, pois podemos esperar ver a movimentação dos principais fornecedores de software para implementar o novo padrão.

Quando o HTTP/3 Estará Disponível na Kinsta?

Nós usamos Nginx em Kinsta e, portanto, temos que esperar até que eles apoiem oficialmente o QUIC. Atualmente, isso está sendo trabalhado e previsto para parte da agência Nginx 1.17. Uma vez que isto seja lançado, você pode garantir que o time do Kinsta estará analisando a possibilidade de adicionar suporte para ele em nossa plataforma.

16
Shares