HTTP/2 é uma versão do HTTP. Ela tem como base o protocolo experimental SPDY, desenvolvido pelo Google para melhorar a experiência na web, tornando as páginas mais rápidas e reduzindo o tempo de ida e volta (RTT), especialmente em páginas da web com uso intensivo de recursos. A Internet Engineering Task Force (IETF) desenvolveu uma segunda versão do protocolo na forma de HTTP/2 no início de 2015.
O que é SPDY?
SPDY é um protocolo experimental desenvolvido pelo Google para aumentar a velocidade e a eficiência da entrega de conteúdo.
Dessa forma, o SPDY melhora o desempenho da rede, reduz a latência de carregamento da página e melhora a segurança da rede por meio de compactação, multiplexação e priorização (dependendo das configurações da rede e do site).
Em 2010, o Google lançou o protocolo SPDY para melhorar a maneira de lidar com solicitações e respostas HTTP. Assim, o SPDY concentrou-se na redução da latência por meio de pipeline TCP e compactação forçada de dados.
Inicialmente, o HTTP/2 estava se desenvolvendo independentemente do SPDY. No entanto, quando ficou claro que o SPDY estava ganhando força dos desenvolvedores (como Mozilla e Nginx) e que o SPDY apresentava melhorias significativas em relação à versão mais antiga do protocolo HTTP. Então decidiram usar o SPDY como base para o HTTP/2.
Por isso, em fevereiro de 2015, após o lançamento do protocolo HTTP/2, o Google anunciou que abandonaria o suporte SPDY em favor do HTTP/2.
O HTTP/2 foi projetado para transporte de conteúdo de baixa latência. Os principais recursos ou diferenças da versão antiga do HTTP/1.1 incluem:
- Binário em vez de Textual
- Multiplexação – Várias solicitações HTTP assíncronas em uma única conexão
- Compressão de cabeçalho usando HPACK
- Servidor Push – Várias respostas para uma única solicitação
- Solicitar priorização
- Segurança
Veja também:
Estrutura Básica Do HTML
Introdução rápida sobre CSS
Introdução rápida sobre Python
Introdução rápida sobre JavaScript
1. Protocolo Binário (Binary Protocol)
O HTTP/2 tende a resolver o problema do aumento da latência que existia no HTTP/1.x, tornando-o um protocolo binário. Sendo um protocolo binário, é mais fácil de analisar, mas ao contrário do HTTP/1.x não é mais legível pelo olho humano. Os principais blocos de construção do HTTP/2 são Frames e Streams
Quadros e fluxos (Frames and Streams)
As mensagens HTTP agora são compostas por um ou mais quadros. Existe um frame HEADERS para os metadados e um frame DATA para o payload e existem vários outros tipos de frames (HEADERS, DATA, RST_STREAM, SETTINGS, PRIORITY etc.) que você pode verificar através das especificações HTTP/2.
Dessa maneira, Cada solicitação e resposta HTTP/2 recebe um ID de fluxo exclusivo e dividido em quadros. Assim, os quadros nada mais são do que pedaços binários de dados. Uma coleção de quadros é chamada de Stream.
Cada quadro possui um ID de fluxo que identifica o fluxo ao qual pertence e cada quadro possui um cabeçalho comum. Além disso, além do stream ID ser único, vale ressaltar que, qualquer requisição iniciada pelo cliente utiliza números ímpares e a resposta do servidor possui stream IDs de números pares.
Além dos HEADERS e DATA, outro tipo de frame que acho que vale a pena mencionar aqui é o RST_STREAM, que é um tipo de frame especial que que tem como caracterisca abortar algum fluxo, ou seja, o cliente pode enviar esse frame para informar ao servidor que eu não preciso desse fluxo não mais.
No HTTP/1.1, a única maneira de fazer o servidor parar de enviar a resposta ao cliente era fechar a conexão, o que resultava em aumento da latência, pois uma nova conexão precisava ser aberta para quaisquer solicitações consecutivas.
Enquanto estiver em HTTP/2, o cliente pode usar RST_STREAM e parar de receber um fluxo específico enquanto a conexão ainda estiver aberta e os outros fluxos ainda estiverem em jogo.
2. Multiplexação (Multiplexing)
Como o HTTP/2 agora é um protocolo binário e como eu disse acima ele usa frames e streams para requisições e respostas, uma vez que uma conexão TCP é aberta, todos os streams são enviados de forma assíncrona pela mesma conexão sem abrir nenhuma conexão adicional.
E, por sua vez, o servidor responde da mesma maneira assíncrona, ou seja, a resposta não tem ordem e o cliente usa o ID de fluxo atribuído para identificar o fluxo ao qual um pacote específico pertence.
Isso também resolve o problema de bloqueio de cabeçalho que existia no HTTP/1.x, ou seja, o cliente não terá que esperar pela solicitação que está demorando e outras solicitações ainda serão processadas.
3. Compressão de Cabeçalho HPACK (HPACK Header Compression)
O HTTP/2 pode compactar cabeçalhos e reduzir a sobrecarga causada pelo mecanismo de início lento do TCP.
O mecanismo de início lento do TCP limita o número de pacotes enviados durante as primeiras viagens de ida e volta. A compactação de cabeçalho permite que as solicitações atinjam a rede em uma única passagem e, às vezes, em um único pacote.
Certamente, a sobrecarga causada por cabeçalhos grandes pode ser significativa, especialmente para clientes móveis que normalmente apresentam latência de ida e volta de várias centenas de milissegundos, mesmo em boas condições.
4. Envio de servidor (Server push)
O push do servidor é outro recurso tremendo do HTTP/2, onde o servidor, sabendo que o cliente solicitará um determinado recurso, pode enviá-lo ao cliente sem que o cliente o solicite.
Por exemplo, digamos que um navegador carregue uma página da Web, ele analisa a página inteira para descobrir o conteúdo remoto que deve carregar do servidor e, em seguida, envia solicitações consequentes ao servidor para obter esse conteúdo.
5. Solicitar priorização (Request Prioritization)
Um cliente pode atribuir uma prioridade a um fluxo incluindo as informações de priorização no quadro HEADERS pelo qual um fluxo é aberto.
Em qualquer outro momento, o cliente pode enviar um quadro PRIORITY para alterar a prioridade de um fluxo.
Sem nenhuma informação de prioridade, o servidor processa as solicitações de forma assíncrona, ou seja, sem qualquer ordem.
Se houver prioridade atribuída a um fluxo, com base nessas informações de priorização, o servidor decide quanto dos recursos precisam reservar para processar qual solicitação.
6. Segurança (Security)
Houve uma extensa discussão sobre se a segurança (através de TLS) deveria ser obrigatória para HTTP/2 ou não.
No final, decidiu-se não o tornar obrigatório. No entanto, a maioria dos fornecedores afirmou que só oferecerá suporte a HTTP/2 quando usado em TLS.
Portanto, embora o HTTP/2 não exija criptografia por especificações, ele se tornou obrigatório por padrão.
Com isso fora do caminho, o HTTP/2, quando implementado em TLS, impõe alguns requisitos, ou seja, TLS versão 1.2 ou superior deve ser usado, deve haver um certo nível de tamanhos mínimos de chave, chaves efêmeras são necessárias etc.
inegavelmente, o HTTP/2 está aqui e já superou o SPDY em adaptação, que está aumentando gradualmente. Dessa forma, o HTTP/2 tem muito a oferecer em termos de ganho de desempenho e já é hora de começarmos a usá-lo.
Veja o primeiro artigo do Roadmap: Passo a passo de como funciona a internet
Perguntas frequentes
HTTP/2 é uma versão do HTTP. Que usa como base o protocolo SPDY criando pelo o Google.
SPDY é um protocolo experimental desenvolvido pelo Google para aumentar a velocidade e a eficiência da entrega de conteúdo.
Os principais recursos ou diferenças da versão antiga do HTTP/1.1 incluem:
– Binário em vez de Textual
– Multiplexação – Várias solicitações HTTP assíncronas em uma única conexão
– Compressão de cabeçalho usando HPACK
– Servidor Push – Várias respostas para uma única solicitação
– Solicitar priorização
– Segurança
