A nova versão do protocolo HTTP traz mudanças fundamentais para a Web. Recursos fantásticos que vão melhorar muito a performance da Web além de simplificar a vida dos desenvolvedores.
O novo HTTP também é mencionado como HTTP/2, HTTP2, HTTP 2 ou mesmo HTTP 2.0
Vamos às novidades.

Compressão automática

No HTTP 1.1, para melhorar a performance, habilitamos o GZIP no servidor para comprimir os dados das respostas. É uma excelente prática, mas que precisa ser habilitada explicitamente. No HTTP 2.0, o GZIP é padrão e obrigatório.
Mas, se você já olhou como funciona uma requisição HTTP, vai notar que só GZIP as respostas resolve só metade do problema. Tanto o request quanto o response levam vários cabeçalhos (headers) que não são comprimidos no HTTP 1.1 e ainda viajam em texto puro.

No HTTP 2.0, os headers são binários e comprimidos usando um algoritmo chamado HPACK. Isso diminui bastante o volume de dados trafegados nos headers.

Criptografia e segurança

O HTTP/2 obriga o uso de HTTPS e conexões seguras. O resultado é que ganhamos segurança e privacidade automaticamente no protocolo, uma boa coisa nos dias de hoje. Claro, limita um pouco mais porque todos vão precisar usar SSL e conseguir um certificado, mas esse já um movimento natural da Web mesmo sem os protocolos novos. Lembrando que todos os planos de hospedagem e revenda a partir de 2017 da Link Oficial já possuem certificado SSL incluso e gratuito.

Essa obrigatoriedade do SSL na verdade tem origem prática, na forma como a Web vai evoluir. É que o HTTP 2.0 muda radicalmente a forma como os dados são trafegados e isso tem potencial pra quebrar muita coisa na Web. Quer dizer, se simplesmente os servidores passassem a suportar HTTP 2.0 da noite pro dia, navegadores velhos seriam incompatíveis e intermediários (como proxies, CDNs etc) ficariam perdidos. Até que toda a Web seja migrada pra HTTP 2.0, não podemos trafegar o protocolo novo abertamente, senão quebramos compatibilidade.

A solução? Usar SSL. Com ele, o servidor consegue negociar com o browser o uso do novo protocolo sem quebrar browsers antigos. E, por ser tudo criptografado, os intermediários não serão afetados. Ou seja, SSL veio para resolver o problema de navegação do HTTP 2.0 e acabou trazendo a segurança de brinde.

Paralelização de requests com multiplexing

Uma página Web comum hoje inclui dezenas de recursos – imagens, arquivos CSS, JS etc. Cada recurso é um request feito e, para que a página carregue rapidamente, precisamos paralelizar essas requisições, baixar mais de uma coisa por vez. O problema é que o HTTP 1.1 é um protocolo sequencial. Isso quer dizer que, quando abrimos a conexão, podemos fazer 1 pedido por vez. Vai 1 request, esperamos, chega a resposta; só aí podemos disparar outro pedido.

Para tentar diminuir o impacto negativo desse comportamento, os navegadores com HTTP 1.1 abrem mais de uma conexão ao mesmo tempo. Hoje em dia esse número costuma ser de 4 a 8 conexões simultâneas por hostname. Isso quer dizer paralelizar os requests em 4 a 8 requests. Já ajuda mas, se sua página tem 80 requests (objetos), o carregamento ainda vai ser bastante sequencial.

No HTTP 2.0, as requisições e respostas são paralelas automaticamente em uma única conexão. É o chamado multiplexing que deixa que façamos vários requests ao mesmo tempo e recebamos as respostas de volta conforme forem ficando prontas, tudo paralelo e assíncrono. Com isso, 1 conexão só já basta. Fica tudo mais fácil e mais leve, por exigir menos conexões na rede.

Só cabeçalhos que mudam

Cada request e cada response no HTTP manda vários cabeçalhos no topo da requisição. Um famoso que vai a cada request é o User-Agent, que identifica o browser com uma string gigante. (o meu aqui hoje é Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36).

Agora imagine esse e outros headers sendo enviados o tempo todo, a cada requisição, em uma página com centenas de requisições. Perda de tempo. No HTTP 2.0, o protocolo mudou isso. Mandamos apenas os cabeçalhos que mudarem entre requisições.

O caso o User-Agent é ótimo. O primeiro request manda esse cabeçalho gigante pro servidor mas todo request seguinte já assume esse valor e o header não precisa ser repetido. Muito útil se pensar que há vários outros headers que não costumam mudar entre requests.

Priorização de requests

Uma otimização muito importante nas páginas é a de facilitar a renderização inicial. Isso significa priorizar os recursos necessários para o usuário começar a ver a página e interagir e deixar coisas secundárias pra depois.

No HTTP 2.0, o navegador pode indicar nos requests quais deles são mais importantes. Ele prioriza numericamente as requisições para indicar pro servidor quais respostas ele deve mandar antes, se puder. O browser pode, por exemplo, dar prioridade máxima a um arquivo CSS no head que bloqueia a renderização, enquanto deixa prioridade mais baixa para um JS assíncrono no fim da página.

Server-Push

Ainda nessa ideia de priorizar os elementos necessários para a renderização inicial da página, é muito comum no HTTP 1.1 as pessoas fazerem inline de recursos. É, por exemplo, pegar o conteúdo CSS necessário para o início da página e embutir direto no HTML com uma tag <style> – ao invés de jogar num arquivo externo que exige um novo request.

O problema dessa gambiarra tão comum no HTTP 1.1 é que dá trabalho fazer esse inline e, principalmente, anulamos o cache do navegador. Como o CSS tá misturado no HTML, ele não pode ser cacheado independentemente.

No HTTP 2.0 e no SPDY, há uma solução melhor, chamada de server-push. A ideia é que o servidor pode mandar alguns recursos para o navegador sem ele mesmo ter requisitado ainda. Imagine o browser requisitar o index.html e o servidor já responder o index.html, o style.css, alguns ícones etc. O servidor empurra para o navegador recursos que ele sabe que seriam requisitados logo em seguida. Com isso, quando o navegador precisar do recurso, já vai ter em cache e não será preciso fazer um request.

Se pensar bem, é quase a mesma coisa que fazer inline de recursos, mas com a vantagem de serem recursos separados, cacheáveis e já fazer parte do protocolo. Sem gambiarras. E se o navegador já tiver o recurso em cache, ele pode cancelar o push para economizar banda.

Novidades do HTTP 2.0

Nesse artigo, abordamos as principais novidades técnicas do HTTP 2.0. Elas trazem muitas melhorias de performance, facilitam o dia a dia do desenvolvedor e trazem muitas novidades para a Web.

Hoje o HTTP 2.0 já é suportado por todos os navegadores modernos e por poucos servidores web, aqui na Link Oficial todos os planos já possuem suporte ao HTTP 2.0 e Server Push.
Já é usado na prática, com sucesso e ganhos de performance perceptíveis, em vários sites grandes como Google, Facebook e Twitter. Para você usar é muito simples e recomendamos fortemente utilizar uma hospedagem que tenha SSL e suporte completo ao HTTP 2.0

Fonte: blog.caelum.com.br