Conheça o protocolo HTTP/2

Pouco se comenta, mas em Maio de 2015 foi publicada a especificação do protocolo HTTP/2, que visa substituir o HTTP/1.x. O principal objetivo do novo protocolo é tratar problemas de performance do seu predecessor, tais como:

  • excessiva latência percebida pelo usuário;
  • utilização demasiada de recursos de rede e servidores;

A história do HTTP/2

O HTTP/2 foi inspirado no protocolo SPDY, desenvolvido por um time do Google, justamente objetivando resolver problemas de performance do HTTP/1.x. Tal time, juntamente com outras equipes formaram o HTTP Working Group (que pertence ao IETF), que  propuseram então a implementação do HTTP/2, descrita na RFC 7540.

Os principais contribuidores do protocolo apresentado nesse artigo são membros de importantes projetos, tais como: Firefox, Chrome, Opera, Safari, Amazon Silk, Twitter e Microsoft’s HTTP stack, podendo-se então perceber a relevância do HTTP/2.

De acordo com W3Techs, dados aferidos em fevereiro de 2016 mostram que 6,7% dos maiores sites em um ranking de 10 milhões, suportam HTTP/2.

O principal problema do protocolo HTTP/1.x

No protocolo HTTP/1.x, para cada requisição HTTP, uma conexão TCP é aberta. No caso de páginas HTML que possuem várias imagens, arquivos Javascript e CSS, inúmeras conexões são abertas, causando uma lentidão no carregamento dessas páginas devido a abertura de várias conexões TCP, pois para cada arquivo Javascript, CSS ou imagem, é feita uma nova requisição e, consequentemente, uma nova conexão TCP. Perceba que, a abertura dessas conexões implica no estabelecimento de handshakes para cada uma delas, o que adiciona mais dados ao já pesado tráfego de informações na rede, bem como uma maior latência inicial para se começar o transporte dos elementos para criação de páginas HTML.

Soluções para problemas de performance no HTTP/1.x

Os problemas de performance do protocolo HTTP/1.x resultam numa experiência do usuário pouco agradável, devido a demora em carregar páginas e executar ações. Para resolver isso, as seguintes soluções são adotadas afim de transmitir menos dados e criar uma quantidade menor de conexões TCP:

  • A utilização de CSS Image Sprites.  Nessa abordagem, uma coleção de imagens é confeccionada como um arquivo de imagem, recuperado de uma só vez do servidor. Cada imagem é então acessada a partir de uma posição conhecida de de um arquivo de imagem baixado anteriormente por uma única requisição HTTP e portanto uma conexão TCP. Caso várias imagens fossem baixadas para compor a página, várias requisições seriam necessárias, culminando na necessidade a abertura e manutenção de várias conexões TCP, o que se deseja evitar.
  • Minificar arquivos CSSs e Javascripts, além de compactar imagens sem perda de informação, para que uma menor quantidade de dados seja trafegada na rede.
  • Unificar arquivos CSSs e Javascripts em apenas um e assim fazer o seu download. Novamente, isso faz com que apenas uma requisição seja feita, exigindo apenas uma conexão TCP, evitando o maior problema já mencionado do protocolo HTTP/1.x.
  • Utilizar diferentes CDNs para armazenar e servir conteúdos estáticos. Isso evita a carga excessiva em servidores de aplicação, que já são sobrecarregados com outras demandas.

CDN, ou em português, Rede de Fornecimento de Conteúdos, é um sistema de servidores integrados através da internet que objetiva servir conteúdo estático massivamente para usuários (navegadores, telefones celulares, tablets, etc). Esse conteúdo geralmente refere-se a arquivos de mídia, tais como imagens, vídeos, músicas e tudo que não seja gerado dinamicamente (como páginas HTML, por exemplo). CDNs são bastante úteis em aplicativos de acesso massivo de usuários, porque conteúdos imutáveis, ou seja, que não são criados ou modificados de acordo com eventos disparados por usuários, são armazenados e servidos aos clientes de uma fonte que não é o servidor de aplicação. Isso faz com que grande parte dos dados servidos ao usuário de aplicações web, por exemplo, seja gerenciado fora do servidor de aplicação, provendo uma flexibilidade maior na escalabilidade dessas aplicações.

Modificações feitas no protocolo HTTP/2

Nesse tópico são descritas as principais modificações e benefícios no protocolo HTTP/2:

1- Os dados são binários

Ao contrário do protocolo HTTP/1.x, onde as requisições eram montadas de forma textual, agora tudo é feito de forma binária. Isso resulta nas seguintes vantagens:

  • Dados binários são mais compactos do que textuais.
  • Dados binários são mais fáceis de parsear já que não há necessidade de tratar espaços em branco, letras maiúsculas/minúsculas e finais de linha.

2 – A transmissão de dados é multiplexada

Dizer que a transmissão de dados é multiplexada significa falar que apenas uma conexão TCP é aberta para todas as requisições necessárias para mostrar-se uma página. Isso resolve o principal problema mencionado do protocolo HTTP/1.x, que é a abertura excessiva de conexões TCP.

3- Possibilita fazer-se Server Push

Server Push significa o servidor enviar dados para o cliente diretamente ao invés de simplesmente responder a uma requisição HTTP. A figura abaixo exemplifica tal conceito. Ao lado esquerdo é mostrado o funcionamento do protocolo HTTP sem Server Push, ou seja, duas requisições HTTP GET são feitas, seguidas de duas respostas com status 200 OK. Já no lado direito, Sever Push é utilizado e percebe-se bem a diferença: uma requisição GET é feita, fazendo com que que o servidor envie um resposta com código 200 OK. Em seguida, ao invés de outra requisição HTTP, uma nova resposta com código 200 OK é enviada ao cliente, sem uma prévia requisição. Em outras palavras, foi feito um Server Push: uma resposta fora enviada pelo servidor sem uma requisição prévia.

No exemplo descrito aqui, o objetivo é obter uma página HTML e o arquivo de estilos (style.css) através de apenas uma requisição HTTP, e não duas como seria feito sem o uso de Server Push.

Exemplo de Server Push

Programadores acostumados com o mundo do desenvolvimento web entendem o quanto Server Push é necessário. Inúmeras situações aparecem onde tal solução é necessária, mas não existia, como por exemplo:

  • Quando uma requisição para uma tarefa de longa duração é feita, necessita-se avisar o cliente, ou seja, o navegador (ou um smartphone), que tal tarefa terminara.
  • Um servidor necessita notificar vários clientes que um evento ocorreu: uma nova publicação pode ser baixada, uma nova promoção acabou de ser anunciada, entre outros exemplos.
  • Ao carregar-se uma página HTML a ser exibida, é necessária uma requisição para cada elemento da mesma: página HTML, imagens, arquivos CSSs, arquivos Javascript, medias, etc.

Infelizmente, para resolver esse problemas algumas soluções custosas em termos de consumo de largura de banda e servidores eram utilizadas, tais como:

  • Pooling – o ato de fazer requisições continuamente para verificar se ações ou eventos sinalizados pelo servidor devem ser anunciados aos clientes. Note que essa técnica exige um número enorme de requisições HTTP e conexões TCP, algo que deve ser evitado ao máximo.
  • Comunicação via socket – Navegadores modernos permitem a abertura de sockets para a comunicação com servidores. Para interações de curta duração, essa é uma excelente solução, entretanto, para atividades que demorem muito, manter um socket aberto é custoso para o navegador, rede e servidor.

Note que, com a funcionalidade de Server Push, as soluções descritas acima não são mais necessárias, e faz-se uso de apenas uma requisição HTTP e conexão TCP.

Uma outra vantagem ainda não citada sobre Server Push, é que com essa funcionalidade, o cache pode ser alimentado sem que antes haja requisições HTTP que carreguem páginas e daí alimentem o cache. Note que, quanto maior o número de páginas e de acessos, tal benefício torna-se cada vez mais relevante.

4 – Compressão de Cabeçalhos (Headers) HTTP utilizando HPACK

A compressão de Headers diminui consideravelmente o tamanho de dados trafegados na rede, já que toda requisição HTTP possui um Header. O protocolo HPACK, desenvolvido especificamente para compressão de Headers HTTP, é utilizado para compactação ao invés do GZIP, pois descobriu-se que o mesmo não é seguro.

Compatibilidade com o protocolo HTTP/1.x

A primeira questão que provavelmente aparece na cabeça de desenvolvedores de aplicação web é: “O que eu devo mudar na minha aplicação para que a mesma seja compatível com o protocolo HTTP/2?”

A resposta, felizmente é: “Nada”. Isso porque, os códigos de retorno de requisições HTTP não mudam, nem a maneira de se chamar métodos HTTP (GET, POST, PUT, etc).

Outro ponto interessante é que a maioria dos navegadores modernos já suportam tal protocolo. São eles: Google Chrome, Mozilla Firefox, Safari 8 e Microsoft Edge.

Servidores de aplicações web, por outro lado, precisam sim ser modificados para suportar o protocolo HTTP/2. Felizmente, já existe aderência de vários deles, tais como:

  • Internet Information Server (IIS) para Windows 10.
  • Desde 2015, Nginx.
  • Apache HTTP Server – 2.4.17+.

Uma lista completa pode ser encontrada na referência [2].

Impacto no desenvolvimento de aplicações web

Minificar CSSs e Javascripts, unificar uma coleção de imagens em apenas uma, além de compactá-la, provavelmente não sejam necessárias quando se utiliza o protocolo HTTP/2, já que ele trata justamente o problema atacado por essas soluções: a criação excessiva de conexões TCP. Pelo menos, é que se espera. Contudo, até que haja estudos e casos de sucesso (ou fracasso) de aplicações web que não se preocupam com essas questões, não se pode ter certeza da eficácia do novo protocolo perante os desafios mencionados nesse artigo.

É importante observar que, com a resolução dos problemas do protocolo HTTP/1.x, novos podem aparecer, já que os primeiros não são mais gargalos de performance. Além disso, como há mudanças significativas no protocolo HTTP/2, as novas características do mesmo podem causar novos problemas ainda não pensados. Isso tudo, claro, ainda é especulação.

Mesmo com as ressalvas mencionadas, vale a pena mostrar indícios promissores sobre o HTTP/2, como descrito em [9]. Essa referência indica que um website típico tem melhora de 30% de performance, utilizando o protocolo discutido. Claro, esse blog é da Google, portanto faz-se necessário que outras fontes façam pesquisas similares mostrando resultados de mesma grandeza para se ter uma maior confiabilidade no que é dito.

Semelhanças e diferenças entre HTTP/1.x e HTTP/2 em uma imagem

Veja na figura abaixo, como as diferenças e semelhanças dos dois protocolos são bem ilustradas. No lado esquerdo da imagem, é possível observar que, o protocolo HTTP/2 com apenas uma conexão TCP faz várias requisições HTTP, ao passo que, seu predecessor necessita de uma conexão por requisição.

No meio da imagem (letra N), onde as requisições HTTP são recebidas e tratadas, os dois protocolos comportam-se de maneira igual, pois o funcionamento dos métodos HTTP (GET, PUT, POST, etc) são idênticos, bem como as respostas enviadas aos clientes. Isso significa que aplicações web já desenvolvidas não precisam ser modificadas para atender a nova versão do protocolo HTTP.

Já no lado direito da figura, onde existem os servidores, exige-se que os mesmos saibam como interpretar e responder requisições segundo o novo protocolo HTTP/2. É importante enfatizar, que os servidores devem atender ao novo protocolo e não as aplicações web já desenvolvidas.

Semelhanças e diferenças do HTTP/1.x e HTTP/2

Palavras finais

O protocolo HTTP/2 tem grandes chances de ser um sucesso, pelas seguintes razões:

  • resolve problemas de performance tão conhecidos no HTTP/1.x;
  • as milhões de aplicações web desenvolvidas pelo mundo, não necessitam de modificação alguma para continuar funcionando no novo protocolo;
  • os vários frameworks de desenvolvimento relacionados a protocolos HTTP que dão imenso suporte aos desenvolvedores também não necessitam de manutenção;
  • os navegadores mais usados já suportam o protocolo descrito nesse artigo;
  • já existem aplicações de peso utizando HTTP/2, tais como: google.com, facebook.com, yahoo.com e youtube.com. Uma lista mais detalhadas de adeptos ao protocolo pode ser encontrada em [10];

Referências

[1] – Página do protocolo HTTP/2 – https://http2.github.io/

[2] – Link do Github com referências de servidores que implementam o protocolo HTTP/2 – https://github.com/http2/http2-spec/wiki/Implementations

[3] – Link da Wikipedia que fala sobre o protocolo HTTP/2 – https://en.wikipedia.org/wiki/HTTP/2

[4] – FAQ do site do protocolo HTTP/2 – https://http2.github.io/faq/

[5] – Link da Wikipedia referente ao protocolo SPDY – https://pt.wikipedia.org/wiki/SPDY

[6] – Link para a RFC do protocolo SPDY – http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00

[7] – Blog com comentários interessantes sobre o protocolo HTTP/2 – https://dzone.com/articles/say-hello-to-http2?edition=157263&utm_source=Spotlight&utm_medium=email&utm_content=queue&utm_campaign=web%20dev%202016-03-31

[8] – RFC do protocolo HTTP/2 – http://httpwg.org/specs/rfc7540.html

[9] – Chromium blog: post que fala sobre a performance de SPDY e HTTP2 – http://blog.chromium.org/2013/11/making-web-faster-with-spdy-and-http2.html

[10] – Site que mostra a utilização do protocolo HTTP/2 – http://w3techs.com/technologies/details/ce-http2/all/all

[11] – Blog que discute HTTP/2 – https://blog.cloudflare.com/http-2-for-web-developers/

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s