Hoje a gente vai falar sobre o HTTP/3, que foi proposto pelo Google e que está sendo implementado, mas antes a gente precisa falar das versões anteriores.
Quem entende um pouco da história da Web, sabe que o criador do protocolo HTTP é o Tim Berners-Lee, que é conhecido como o pai da internet, e que, além do HTTP, criou o WWW [World Wide Web] e também o HTML. Na primeira versão da Web, o protocolo HTTP foi fundamentado num sistema TCP/IP. Então, na base, nós temos o IP como um serviço de identificação, o TCP como um sistema de sockets e, por cima dessa implementação, nós temos uma camada a mais de comunicação. Nessa camada de comunicação nós temos basicamente dois escopos diferentes: um header [cabeçalho] de requisição e um payload.
O cabeçalho de requisição, tanto pode ser mandado pelo servidor como pelo client. Então, assim que se acessa um site, a gente manda essa requisição para o servidor Web, que manda uma resposta que também tem um cabeçalho. Normalmente esse cabeçalho, por mais que seja livre para poder mandar qualquer tipo de informação, tem alguns padrões de tipos de informações que nós mandamos por ele. Você vai falar algumas coisas como, por exemplo, que tipo de codificação essa mensagem vai ter, qual é o método dessa mensagem, se é uma mensagem que está compactada, qual o tipo de compactação está sendo utilizada, e por aí vai. O cabeçalho serve não só pra saber que é o destinatário daquela mensagem, mas também para poder falar como o conteúdo se comporta.
O segundo escopo do HTTP é justamente o payload, que é a parte de dados que são trafegados dentro dessa mensagem que está sendo enviada. Nós temos vários tipos de payload diferentes, podemos mandar simplesmente um texto cru, um JSON, um XML, ou qualquer outro tipo, e aí esse .TYPE também é informado no cabeçalho de requisição e resposta. Em todo navegador, quando você digita uma URL ou vai pelo Google mesmo, você faz uma requisição HTTP. Primeiro essa requisição bate num DNS, que retorna qual é o IP que pertence àquele endereço e, assim você faz uma conexão TCP/IP no servidor com esse IP e uma porta, no caso do protocolo HTTP, ele utiliza como padrão a porta 80.
O protocolo sempre foi baseado num sistema de pergunta e resposta, então o client manda um pergunta e o servidor emite uma resposta. Pelos anos de 2004/2005, percebeu-se que esse protocolo não seria suficiente para conseguir comportar todas as inovações que estavam acontecendo na Web, então foi propostas as alterações do protocolo para a versão 1.1. Não vou entrar muito em detalhes, mas essa atualização 1.1 foi significativa pro protocolo, já foi a primeira grande modificação do protocolo desde a sua criação, e ela é utilizada até hoje em vários sites e servidores Web.
Em 2015, quando houve a conferencia do ECMA, a ES5, empresas como Google, FaceBook, Yahoo, Amazon, Microsoft e várias outras, se reuniram para definir os padrões que iriam ser utilizados ba Web daquele período em diante. Então a gente tem a criação do HTTP/2.0. Até então o HTTP era um protocolo direcional, o client manda uma requisição para o servidor, o servidor manda uma resposta pro client. No HTTP/2, a gente já começa a ver o comportamento de bidirecionalidade, isso é, o servidor pode mandar para o client uma informação que não teve requisição. Além disso, o HTTP/2 tem o intuito de reduzir as verificações que o protocolo demanda numa requisição. Se você consegue manter uma conexão persistente, como é o caso do HTTP/2 fazendo stream, não tem a necessidade de todas as validações que são necessárias pro retorno da requisição.
Se a gente abrir qualquer página na internet, a gente vai conseguir ver um pouco como é o funcionamento do protocolo HTTP na prática, olhando o Dev Tools, aqui o que é importante de se entender é justamente a parte do tempo de resposta. O protocolo HTTP segue etapas para fazer essa requisição, então a primeira coisa que o navegador precisa fazer é procurar o local no DNS, isso é, o navegador vai perguntar qual é o IP do endereço informado, existem vários servidores de DNS espalhados pelo mundo inteiro, caso esse DNS não esteja armazenado em algum servidor de cash, que as próprias operadoras que fornecem internet tem, ele vai até quem faz a gestão do “.com” pra conseguir o IP do servidor. Esse processo normalmente é feito uma vez só, depois o navegador vai fazer um cash.
Em seguida ele começa a estabelecer ums conexão TCP/IP. Quando a gente está falando de protocolo HTTP puro, a gente não tem um cara muito importante chamado SSL Checker, que é o processo de validação o certificado de segurança. Depois que é feita a primeira conexão com o servidor, é validado esse certificado, no caso de um HTTPS, aí sim vai ser enviada a requisição. Então o servidor vai ter o waiting TTFB, que é o tempo entre o servidor receber o request e terminar o processamento, que vai depender a infra-estrutura de servidor: se o servidor tiver uma escala que consiga suportar uma série de requisições, a tendência é que elas sejam mais rápida, consequentemente vai ter um retorno desse waiting mais rápido. Só então o browser vai começar a fazer o download desse payload via chuncks [caso seja um arquivo muito grande, vai ser picotado] ou, se é um arquivo relativamente pequeno, ele baixa de uma vez só. O protocolo TCP/IP tem um limite máximo de caracteres que ele pode trafegar, então às vezes essa requisição é feita várias e várias vezes.
O que tem de diferente no protocolo HTTP/2 é essa questão do servidor poder se comunicar com o client mantendo uma conexão aberta, uma conexão de socket bidirecional. A gente vê muito isso em servidores de jogos, MMORPGs usam sockets bidirecionais e isso não é novo, isso é bem antigo. A Web atualizou, no ES5, o websocket que tem esse mesmo comportamento de manter uma conexão aberta. Percebam que criar gerenciar essas conexões tem um peso dentro do servidor, então é melhor ter conexões persistentes do que ficar criando e finalizando novas conexões.
O HTTP/3, proposto pelo Google, tenta justamente fazer com que vários conteúdos que são do mesmo servidor Web sejam passados pela mesma conexão. Quando a gente está fazendo download, tem várias outras coisas que são baixadas junto: imagens, CSS, JavaScript, fontes, e por aí vai; se esses caras todos tiverem no mesmo servidor, uma única conexão consegue fazer download de tudo ao mesmo tempo e ainda é possível concatenar todos esses arquivos e enviar de uma vez só, isso é muito mais rápido pro carregamento da página.
Esse é o princípio básico do HTTP/3 e, pra isso, ele usa um sistema QUIC, a ideia é utilizar protocolo UDP em vez de TCP/IP. E qual é a diferença? O TCP/IP tem a necessidade de uma confirmação de entrega do pacote. Quando você tem o protocolo TCP/IP de base, toda mensagem enviada tem um remetente e tem uma assinatura e, quando esse remetente recebe um pacote, ele manda uma resposta pro servidor, avisando que recebeu. Caso esse pacote não chegue ao destinatário, o servido reenvia esse pacote de forma automática. No caso do UDP, não há o envio de resposta pro servidor de origem, isso faz, inclusive, com que o pacote fique menor, porque não tem um cabeçalho de retorno de mensagem, mas pode haver perda de pacotes. A tecnologia QUIC vai fazer justamente essa persistência da conexão entre o client e o servidor e vai falar para o servidor quando precisa reenviar algum pacote caso ele não tenha recebido. Então o servidor informa para ele quais os conteúdos que ele precisa receber, ele entende o conteúdo e aí, caso ele não receba algum pacote, ele reporta pro servidor, e isso representa uma otimização na transferência de payload.
Outro ponto que eu achei interessante: como são enviados vários arquivos em paralelo, você acaba não segurando o IO do servidor Web. Para quem já teve problema de sobrecarga de acessos, sabe o que é isso. O servidor tende a se manter conectado até o envio da resposta e, dependendo da forma que você escreve o HTML, um arquivo só é carregado depois que o outro é finalizado e isso pode causar uma lentidão no carregamento da página. Desse forma aqui, as coisas são todas carregadas de forma assíncrona, então tem menos latência nesse carregamento da página.
Entender o protocolo HTTP para quem desenvolve pra Web é extremamente importante, porque quando a gente está falando em ter um site performático, bem indexado no Google, latência é um fator crítico para qualquer website. Quem estudou um pouco de SEO, sabe o quanto o Google leva e consideração o tempo de carregamento de uma página, por isso a gente usa CDN, por isso a gente tem boas práticas para construção de sites, para tentar se adequar aos padrões considerados ideais.
Existem vários estudos, tanto da Amazon quando do Google, sobre o quanto a latência faz com que aumente o bouncing do site, os usuários vão perder o interesse por aquele site porque ele é demorado pra carregar. Outro estudo que a Amazon fez, que eu acho super interessante, é que a cada 100ms de latência que tem no site deles, 1% das vendas é perdido e isso é bastante coisa. Se a gente for pensar os resultados financeiros, perder 1% das vendas é muita coisa, por isso que a Amazon investiu em AWS, pra justamente tentar reduzir ao máximo a latência nos serviços dela.
Se você é da área de programação Web ou está pensando em entrar na área, eu recomendo fortemente que estude sobre o protocolo HTTP, porque ele é a fundação, é a base para desenvolver boas aplicações, se você não entender o funcionamento dele, pode cometer vários erros primários, que muitos desenvolvedores comentem. O que eu mais vejo são sites que tem a performance baixíssima, eu até fiz uma postagem brincando que provavelmente meu blog em WordPress é mais rápido que a maioria dos sites em React feitos em casa, porque o WordPress é uma ferramenta que já passou por muitos anos de mercado e utiliza práticas que tornam o carregamento dessas páginas mais rápido. Não é todo template, obviamente, mas tem como comprar templates que são page speed 100, que têm alta performance para motores de busca e isso ajuda bastante na hora de indexar no Google, ajuda no SEO da página. Enfim, se você está pensando em desenvolver aplicações públicas, Websites e mexer com SEO, entender do protocolo HTTP é fundamental.
Vamos acompanhando como vai ser essa questão do HTTP/3 que, se não me engano, ainda está em versão de teste, não está 100% ainda. A gente nem passou direito pelo HTTP/2, muitos sites ainda utilizam HTTP/1.1, então é um processo, não é porque o Google lança uma versão que todo mundo vai se adaptar correndo, mas eu acredito que, em algum momento, o Google vai pedir que os servidores Web sejam atualizados para as novas versões, embora seja muito improvável que as versões anteriores percam suporte.
Para quem se interessa em começar a desenvolver, vou deixar uma sugestão de leitura aqui:
O conteúdo deste post foi retirado do vídeo “HTTP/3”:
