Como funciona o HTTP/2 e o que ele muda na sua vida

Os detalhes da nova versão do protocolo que vai acelerar o carregamento das páginas

Paulo Higa
Por
• Atualizado há 1 ano
tecnoblog-http2

Quando você começou a acessar a internet? Se foi depois de 1999, você está usando o mesmo protocolo que usa atualmente para acessar páginas da web, o HTTP/1.1. Após 16 anos sem grandes atualizações, o Internet Engineering Steering Group (IESG), órgão responsável por revisões técnicas nos padrões da internet, aprovou o HTTP/2 no último dia 18 de fevereiro. Mas o que é isso? E que diferença ele vai fazer na sua vida?

A gente explica.

O que é HTTP? Como se alimenta? Como se reproduz?

A internet é formada por algumas camadas (quatro ou sete, dependendo da sua religião). A mais próxima de você é a camada de aplicação, que reúne protocolos para funções específicas. Tem o IMAP, que seu cliente de email usa para baixar suas mensagens; o NTP, que mantém o relógio do seu computador sincronizado; o FTP, para baixar e enviar arquivos; o BitTorrent, usado para fazer download de… distribuições Linux; e muitos outros.

O HTTP é um protocolo desenvolvido originalmente para distribuir conteúdo hipertexto — ou seja, textos com hiperlinks que conseguem levar você a outros textos com hiperlinks. Você usa o HTTP todos os dias para acessar páginas da web, e ele está tão onipresente que seu navegador provavelmente já nem exibe mais o https:// na barra de endereços como fazia antigamente.

A primeira versão do HTTP que conhecemos é o HTTP/0.9, publicado em 1991, que servia apenas para transferir texto de um servidor para o seu computador. Em 1996, quando a internet comercial engatinhava no Brasil, foi finalizado o HTTP/1.0. Entre as novidades estavam a possibilidade de incluir outros tipos de arquivos numa página, como imagens (uau!) e o novo método POST, para permitir que os usuários não apenas recebessem, mas também enviassem informações para um servidor, como termos de pesquisa num buscador e mensagens em redes sociais.

A primeira página da web era assim, meio sem graça
A primeira página da web era assim, meio sem graça

O protocolo que a maioria dos sites usa atualmente é o HTTP/1.1, lançado em 1999. Ele permitiu que a web continuasse crescendo ao resolver alguns problemas do HTTP/1.0, como o alto uso de dados. Com o novo HTTP/1.1, as páginas poderiam ser comprimidas pelos servidores e descomprimidas pelo computador do usuário. Dessa forma, seria possível baixar de maneira mais rápida uma página com um incrível modem de 28.800 bits por segundo de última geração.

Se o HTTP/1.1 está funcionando, por que inventaram outra versão?

Na verdade, assim como aconteceu na transição do HTTP/1.0 para o HTTP/1.1, a versão atual do protocolo está começando a mostrar sinais de cansaço. As páginas da web ficaram muito mais pesadas nos últimos anos, incorporando cada vez mais imagens, vídeos e outros elementos externos, como fontes personalizadas e arquivos CSS e JavaScript.

O problema de uma página ter muitos elementos é que o HTTP/1.1 é um protocolo sequencial: seu navegador abre uma conexão, solicita um arquivo ao servidor do site, recebe o arquivo e só depois pede outro arquivo. Para minimizar essa perda de tempo, os navegadores normalmente abrem múltiplas conexões (algo entre quatro e oito) por servidor. Assim, o browser pode baixar vários elementos ao mesmo tempo e acelerar o carregamento da página.

Mas, como boa parte das páginas incorporam elementos de vários servidores (vídeos no YouTube, fontes no Google e imagens num servidor de cache, por exemplo), isso significa que seu navegador pode acabar abrindo dezenas de conexões só para carregar uma página. Obviamente, isso congestiona e monopoliza o uso da rede, prejudicando outras aplicações, como ligações VoIP — é por isso que você configura um limite de conexões no seu cliente torrent.

Além disso, abrir novas conexões a todo momento significa que seu navegador precisa fazer negociações a todo momento. Para cada solicitação de arquivo, o servidor do site e seu navegador trocam cabeçalhos, que incluem o user-agent, com a versão do seu navegador e sistema operacional, por exemplo. Algumas dessas informações não mudam a todo momento, então está havendo um grande desperdício de tráfego em páginas com muitos elementos no HTTP/1.1.

Portanto, o principal problema que o HTTP/2 tenta resolver é o das múltiplas conexões.

O que mudou em relação ao HTTP/1.1? E por que os sites vão ficar mais rápidos?

“Muda bastante coisa, mas permanece tudo igual”, brinca Alex Soares, arquiteto sênior de inovação da Exceda, empresa que oferece serviços de aceleração e distribuição de conteúdo na internet. “O protocolo HTTP/1.1 é totalmente textual. Você consegue conectar ao servidor manualmente, digitar texto e fazer o que quiser. Ele foi desenvolvido para uma web antiga. Já o HTTP/2 é um protocolo binário, feito para ser entendido por máquinas, não mais por pessoas. Por isso, é mais eficiente e traz alguns benefícios que consertam os problemas atuais da web”.

No HTTP/1.1, o navegador abre uma conexão para baixar um único arquivo. Se essa conexão ficar ocupada por muito tempo, seja porque o arquivo é muito grande ou porque o servidor está lento para responder, o carregamento da página simplesmente trava no meio do processo. Há como amenizar esse problema abrindo múltiplas conexões, mas isso é apenas uma gambiarra, não uma solução.

loader-larger

Já o HTTP/2 usa multiplexação, um nome complicado para dizer que o navegador abre uma única conexão para baixar múltiplos arquivos. As requisições e respostas são paralelas e assíncronas: seu navegador pede vários arquivos ao mesmo tempo e recebe-os assim que eles estiverem prontos, na mesma conexão. Mas e se uma imagem na página, por exemplo, for pesada demais? Não tem problema: na mesma conexão, é possível misturar os dados, recebendo parte da imagem, depois um arquivo totalmente diferente e por fim o resto da imagem que faltava. Sensacional, não?

Outra novidade do HTTP/2 é o que está sendo chamado de server push. Se você der uma olhada no código-fonte do Tecnoblog, verá que há uma série de chamadas para elementos externos, como arquivos CSS e JS. No HTTP/1.1, seu navegador precisa primeiro solicitar a página, ler o código-fonte em HTML, interpretar que ali há chamadas para elementos externos e então solicitar esses tais elementos.

Só que, com HTTP/2, o servidor poderá mandar esses elementos antes do seu navegador pedi-los. Dessa forma, assim que seu navegador solicitar nosso index.html, o servidor poderá responder com o index.html, o style.css, o tb.css, o jquery.js e o favicon.png. Quando seu navegador se der conta de que precisa usar esses arquivos para renderizar a página, eles já estarão no seu computador, prontinhos para uso. Isso é mais eficiente e todo mundo fica feliz.

Mas o server push não poderia causar brechas de segurança nos navegadores, devido ao fato de baixar arquivos com antecedência, alguns potencialmente perigosos? “Não, porque vai ser uma conexão pré-estabelecida. Todas as requisições partem do cliente. O server push tem apenas o intuito de agilizar a renderização da página”, diz Soares.

Além disso, no HTTP/2, os cabeçalhos serão comprimidos com um formato chamado HPACK. Sempre que seu navegador solicita um arquivo, ele precisa baixar o cabeçalho desse arquivo, que pode conter o tamanho do arquivo, as informações do servidor e um cookie. Geralmente, um cabeçalho não passa de 1 KB, mas imagine isso se multiplicando por dezenas de arquivos? Com a compressão nos cabeçalhos, o uso de dados será menor — e as páginas carregarão mais rapidamente, claro.

Do lado das empresas

Além de melhorar a experiência para o usuário, o HTTP/2 também deverá trazer benefícios para as companhias. “Com todas as novas otimizações técnicas, as empresas conseguirão uma melhor utilização da infraestrutura em geral. Isso vai trazer melhor ROI [retorno sobre investimento, na sigla em inglês] sobre o equipamento atual e irá gerar uma sobrevida para os aparelhos em uso”.

“É interessante eles [os profissionais que trabalham na web] começarem a pesquisar se os provedores deles já têm planos para suportar HTTP/2. Verificar se a aplicação vai precisar de alguma alteração e se os fornecedores já estão suportando a tecnologia. Isso vai permitir que o site suporte o HTTP/2 quando o protocolo estiver ratificado, o que acredito que vá acontecer em abril ou maio”.

E quando vou poder usar isso?

As especificações do HTTP/2 foram finalizadas em fevereiro e estão sendo encaminhadas para se tornarem um padrão.

O Internet Explorer do Windows 10 Technical Preview já está pronto para o HTTP/2. O Google anunciou que o Chrome ganhará suporte ao HTTP/2 nas próximas semanas — o HTTP/2 traz algumas ideias do SPDY, protocolo que o Google começou a desenvolver em 2009 para acelerar a web; por causa do novo padrão, o SPDY será descontinuado. A Mozilla está testando o HTTP/2 no Firefox desde a versão 34.

Do lado dos servidores, a coisa também está andando bem. Tanto o Apache quanto o nginx já incluem suporte experimental para o HTTP/2 com base nos rascunhos da especificação lançados em 2014. O IIS, da Microsoft, possui suporte ao HTTP/2 no Windows 10 Technical Preview.

A adoção da nova versão do protocolo deverá acontecer ao longo dos próximos meses e anos — a migração acontecerá aos poucos, e certamente conviveremos com sites HTTP/1.1 e HTTP/2 lado a lado durante um bom tempo. Como os principais navegadores e servidores já estão preparados ou se preparando para o HTTP/2, ele não deve demorar para dominar a internet. Nossas conexões agradecem.

Publicado originalmente em 18 de fevereiro. Atualizado em 19 de março com informações adicionais.

Receba mais sobre HTTP/2 na sua caixa de entrada

* ao se inscrever você aceita a nossa política de privacidade
Newsletter
Paulo Higa

Paulo Higa

Ex-editor executivo

Paulo Higa é jornalista com MBA em Gestão pela FGV e uma década de experiência na cobertura de tecnologia. No Tecnoblog, atuou como editor-executivo e head de operações entre 2012 e 2023. Viajou para mais de 10 países para acompanhar eventos da indústria e já publicou 400 reviews de celulares, TVs e computadores. Foi coapresentador do Tecnocast e usa a desculpa de ser maratonista para testar wearables que ainda nem chegaram ao Brasil.

Relacionados