As fantásticas novidades do HTTP 2.0 e do SPDY

A nova versão do protocolo HTTP e seu irmão SPDY trazem 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.

No post anterior do Luiz Corte Real aqui no blog, apresentamos o SPDY e o HTTP 2.0, o que eles são e porque são importantes. Desde então, eu e ele apresentamos uma palestra com as novidades dos protocolos no QCon SP 2014. 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ó GZIPar 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 SPDY obriga o uso de HTTPS e conexões seguras. O HTTP 2.0 até pensa em permitir uso sem SSL, mas na prática todo mundo vai suportar apenas conexões seguras HTTPS. 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.

Essa obrigatoriedade do SSL na verdade tem origem prática, na forma como a Web vai evoluir. É que tanto o SPDY quanto o HTTP 2.0 mudam 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 deploy do HTTP 2.0 e do SPDY 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 request por vez. Vai 1 request, esperamos, chega a resposta; só aí podemos disparar outro request.

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, o carregamento ainda vai ser bastante sequencial. Ainda no HTTP 1.1, uma gambiarra comum é usar vários hostnames na página (site.com e img.site.com por exemplo), assim ganhamos mais conexões paralelas.

No HTTP 2.0 e no SPDY, 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 e não precisamos de vários hostnames. Fica tudo mais fácil e mais leve, por exigir menos conexões na rede.

multiplexing

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 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1933.0 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 e no SPDY, 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 e no SPDY, 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.

requests priorizados

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.

Server-push

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.

O fantástico mundo do HTTP 2.0 e do SPDY

Nesse artigo, abordamos as principais novidades técnicas do SPDY e 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 SPDY já é suportado em quase todos os navegadores modernos (só o Safari que não) e em muitos servidores. 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, principalmente se seu sistema já for HTTPS.

Para saber mais sobre Web, Front-end e otimizações, não deixe de conhecer nosso curso de HTML, CSS e JavaScript.

18 Comentários

  1. Alexandre Cardoso 02/06/2014 at 14:39 #

    Excelente post, Sérgio.

    O SPDY é um protocolo fantástico e condensa um conjunto de mudanças muito bem vindas à Web. Uma das melhores contribuições do Google já lançadas. Pra quem tem sites com requisitos fortes de segurança e performance, é um ponto forte a ser considerado.

  2. Rafael Gontijo 02/06/2014 at 21:17 #

    Somente para atualizar, na WWDC foi apresentada a nova versão do Safari e o SPDY será suportado, eu imagino que ele seja lançado juntamente com o novo OS X (Yosemite).

  3. Gabriel Wohlfart 04/06/2014 at 02:16 #

    Nossa, não tinha a menor noção que existia o TTP 2.0.
    Muito show o artigo.
    Abraço.

  4. Raphael Lacerda 18/06/2014 at 11:07 #

    Sergio, excelente artigo, parabéns!
    Só não achei tão simples de habilitá-lo, salvo engano o SPDY precisa de TLS 1.2, e na empresa que trabalho, os servidores só suportavam TLS 1.1.
    Foi uma gambi da po@#$@#$# pra fazer isso rodar

    mas excelente artigo, os desenhos ficaram bem didáticos

  5. Sérgio Lopes 18/06/2014 at 15:52 #

    Bom saber do TLS 1.2, não sabia da limitação.

  6. Fred 18/06/2014 at 21:17 #

    Excelente post sobre o assunto.
    Já tinha ouvido falar sobre HTTP 2.0 e SPDY, mas não sabia detalhadamente as vantagens que surgiriam em relação a performance. Esse post me esclareceu tudo.
    Uma coisa que senti falta foi sobre informações de coaptabilidade e disponibilidade dessas tecnologias.
    Abraço!

  7. Daniel 18/12/2014 at 13:33 #

    a questão da obrigatoriedade da conexão segura é um problemão… E não digo isto por conta de precisar de certificados (o que aumenta os custos, principalmente em startups ou de quem só quer fazer um site “de brincadeira”), mas principalmente porque exige IPs específicos para cada site. Nada de ter aquele plano de máquina virtual com IP fixo e trocentos sites dentro. Não, o HTTPS exige um IP específico para cada site. Para usar HTTPS com múltiplos domínios e único IP é necessário usar algo chamado SNI, que nem todos os navegadores suportam ou pagar mais caro por um certificado de múltiplos domínios e usar o mesmo certificado para todos os sites que compartilharem o IP, o que é uma grande gambiarra. No fim cada site vai ter mais 2 custos adicionais: certificado e IP fixo adicional.

  8. Daniel 18/12/2014 at 13:39 #

    outro problema com o HTTPS obrigatório é que os proxys tipo squid não conseguirão mais fazer caché, tendo que sempre baixar tudo de novo ao acessar as mesmas páginas por computadores diferentes. A menos que já tenham pensado em alguma solução para isto, isto pode deixar a internet mais lenta e aumentar o consumo de banda, principalmente em grandes empresas.

  9. Sérgio Lopes 18/12/2014 at 15:19 #

    A gente usa SNI aqui na Caelum. As maiores limitações de suporte são Android 2 e IE no Windows XP. Para nosso cenário, não são um problema. Mas, claro, cada aplicação tem seus requisitos. O bom é que tanto XP quanto Android 2 são plataformas morrendo bem rapidamente.

    Se não precisar de nada muito especial nos certificados, há várias opções free hoje em dia. Usamos aqui o startssl. Bem tranquilo.

    Entendo que o SSL tenha um custo a mais em boa parte dos casos. Mas deixamos a discussão do HTTP2 de lado, acho que é um custo cada vez mais importante de arcarmos. Eu acho importante pra privacidade e segurança que a Web seja toda criptografada. E acho interessante o HTTP2 ajudar a empurrar essa mudança.

  10. Sérgio Lopes 18/12/2014 at 15:26 #

    Criptografia realmente mata os intermediários. Paga-se o preço de não ser possível caches (como squid) mas também acho que não é um problema grande. É até melhor matar intermediários, pra preservar privacidade.

    O cenário que você comentou, de grandes empresas com um squid local, eu acho que já não é tão importante. Maiores sites do mundo (Google, Facebook, YouTube, etc) já são 100% HTTPS. Ou seja, maioria do acesso que as pessoas fazem já é SSL e já não tem cache, e ninguém tá morrendo por causa disso.

    Os sites menores, que demoram a oferecer HTTPS, beneficiariam do cache por serem HTTP. Mas não acho tão importante, visto que a chance de várias pessoas acessarem o mesmo site é pequena. (ex. será que mais alguém na empresa está lendo esse post no blog da caelum agora? acho que não. Mas certamente tem um monte de gente no Facebook)

    Aliás, o Google tem números que mostram que 60% do uso da Internet hoje é via HTTPS já:
    https://plus.google.com/+IlyaGrigorik/posts/7VSuQ66qA3C

  11. Ricardo Carvalho 09/03/2015 at 12:55 #

    Parabéns pelo ótimo post, conseguiu passar de forma clara os principais benefícios do (já querido) HTTP/2…Para quem assim como eu, trabalha com desenvolvimento web, e preza pela integridade e performance de uma aplicação web, esse artigo é um ótimo pontapé para conhecer mais essa novidade no mundo da internet!

    Abs

  12. daniel 12/03/2015 at 09:50 #

    Estava lendo o artigo, achando bem esclarecedor, e no final, percebo que é do Sergio Lopes. Não é a toa que estava tão didático. Parabens!

    Uma dúvida: O Nodejs hoje é usado principalmente para questões de performance justamente para resolver essas deficiências do http 1.1. Com a migração para o HTTP 2, você acha ainda válido usar o node para o desenvolvimento de webapps, ou o HTTP 2 meio que deu uma minimizada na necessidade de usar o node sempre que precisamos de performance (no caso de muitos acessos simultâneos).

    Desde já obrigado

  13. Sérgio Lopes 12/03/2015 at 15:55 #

    Eu não tenho essa visão do node. Acho que ele pode melhorar escalabilidade de certos tipos de aplicação, mas do ponto de vista do server. Performance já nem tanto.

    A vinda do http2 alivia mais o overhead da transmissão dos dados. Melhora bastante o response time pro cliente. Alivia um pouco o server sim mas nada significativo (ele vai ter menos connections abertas), mas o mesmo tempo o protocolo ser binário e exigir ssl vai demandar mais do servidor.

    Resumindo: não vejo relação entre usar ou não node com o lançamento do http2

  14. Davi 27/04/2016 at 10:13 #

    Excelente artigo!! Ainda não conhecia o HTTP 2.0 e esse artigo me apresentou de forma muito objetiva e simples, parabéns!!

  15. Paulo César 13/07/2016 at 16:18 #

    Sergio, você pretende lançar algum livro sobre o assunto?

Deixe uma resposta