Nos últimos dias vários amigos vieram me perguntar o que eu pensava sobre o HTTP/2, a versão "2.0" do protocolo HTTP, que é o que faz com que a web como a conhecemos hoje possa existir e funcionar. Para desalento de meus amigos, eu praticamente nunca tinha uma resposta animada a dar, sempre o que eu tinha a dizer era meio permeado de um certo pessimismo.

Assim, resolvi escrever este post, para organizar um pouco melhor as ideias sobre o tema, e ter um link para mandar aos amigos, quando me perguntarem sobre a novidade.

Por uma questão de organização do pensamento vou dividir o texto em duas partes: os problemas potenciais e as soluções potenciais, mas sei que com isso estarei impondo limitações ao desenvolvimento do assunto, e teremos todos de conviver com as implicações de minha decisão.

Parte 1 - Os problemas potenciais do HTTP/2

O HTTP/1 já está em produção há pelo menos uns quinze anos, e um imenso, gigantesco “ecossistema” já se desenvolveu ao seu redor. Não são poucas as gambiarras que as pessoas inventaram para contornar suas limitações (como os CSS Sprites, de que falarei mais abaixo), e mudar o âmago deste ambiente vai ter custos que talvez nem possam ser calculados em dinheiro.

HTTP é Hypertext Transfer Protocol

A mudança mais radical que eu vejo é que o HTTP/2 deixa de ser um protocolo de tráfego de texto e passa a ser um protocolo de transporte de arquivos binários.

Com isso, vejo uma infinidade de aplicações (como firewalls e * proxies*) que simplesmente deixarão de funcionar, ou terão suas funcionalidades reduzidas a nada, pelo menos até que sejam reescritas e passem por adequações (nem sempre fáceis) para passar a "entender" o novo protocolo.

A web é grande demais para ser migrada

Atualmente não são apenas servidores HTTP e navegadores que utilizam e movimentam a web. Seguindo o exemplo que acabei de citar, há muito dispositivos responsáveis por distribuir o tráfego ao redor do mundo, por filtrar o que as pessoas podem ou não podem ver, barrar acessos irregulares, etc.

O esforço de atualização de todos os dispositivos (de hardware, de software, ou de ambos) pode resultar num atraso gigantesco da implementação efetiva do HTTP/2.

HTTP/2 não requer criptografia, mas os navegadores sim

Muito do que o HTTP/2 é tem sua origem no SPDY, protocolo criado pela Google objetivando tornar a web mais rápida e mais segura.

Entretanto, muitas pessoas falharam miseravelmente em implementar o SPDY em seus servidores embora, em teoria, seja questão de meramente habilitar um módulo no Apache ou no Nginx. Ah, sim, claro, e também de instalar um certificado TLS 1.2 válido no servidor, e fazer tudo funcionar ao mesmo tempo.

Pois o HTTP/2 vai ter exatamente a mesma exigência. Não no protocolo, mas devido a limitações impostas pelos fabricantes de navegadores (Mozilla, Google, etc), que só se propuseram a implementar suporte ao novo protocolo para sites com TLS 1.2.

Os servidores web serão muito mais exigidos

Não só pelo uso compulsório de compactação gzip em todo o tráfego HTTP/2, nem só pela força extra para operar com criptografia indo e voltando numa única conexão TCP (já vou falar sobre a multiplexação) o HTTP/2 será mais pesado em termos de servidor.

Mas também porque o HTTP/1 favorece que os objetos que compõem uma página estejam espalhados por diversos servidores (as CDNs), facultando soluções de engenharia que isolem completamente os diversos tipos de requisições, enquanto o HTTP/2 favorece que se tenham todos os ovos na mesma cesta, tudo partindo exatamente do mesmo domínio (ou subdomínio) para que o protocolo em si possa se beneficiar da multiplexação.

Parte 2 - As potenciais soluções

Felizmente, toda crise é carregada de oportunidades, já diria qualquer animador de curso de motivação mequetrefe.

O HTTP/2 não é exceção, e embora só mesmo sites com certificados seguros válidos possam beneficiar-se das novidades, ele tem muitas vantagens, sendo que destaco as principais logo abaixo.

As APIs não mudam

A web que ninguém vê é feita de APIs: sistemas que conversam entre si e permitem níveis altíssimos de automação: rotinas de cobranças, acesso a dados, processamento de imagens, e muito mais que nem me ocorre agora.

A boa notícia é que os códigos que funcionam com HTTP/1 continuarão a funcionar com o HTTP/2, contanto que a API seja suficientemente bem escrita, e o cliente desta esteja preparado para lidar bem com situações imprevistas.

Multiplexação é <3

O protocolo HTTP/1 — o mesmo que é usado em meu site, pelo menos no dia da publicação deste post — requer uma conexão TCP para a página em si, e mais uma para cada objeto referenciado nela. Não é incomum que uma página conte com centenas de requisições TCP (que podem ser "paralelizadas" para diversos servidores).

Com o advento da multiplexação, cada página abrirá uma e somente uma conexão TCP entre o navegador do visitante e o servidor. A eficiência do uso de rede é inegável.

Entretanto, desenvolvedores frontend já estão acostumados desde há muito tempo a usar a técnica do CSS Sprite, que consiste em carregar (idealmente) todas as imagens que serão usadas em um site numa imagem imensa, "mapeada", que vai custar uma conexão HTTP para carregar e depois ficará disponível "para sempre" no cache do navegador.

Para outros tipos de recursos (como CSS e JS) já faz muito tempo que existem recursos de miniaturização (minify), que além de "encolher" o código podem fazer com que a página requeira apenas um objeto de cada tipo.

Caches e proxies reversos

Serviços de cache e proxies reversos (como a CloudFlare) podem aumentar muito sua presença na web, bem como facilitar a vida de quem não tem disposição para adequar seu site para as exigências do HTTP/2.

Atualmente a CloudFlare já oferece HTTPS de graça para todos os seus usuários. Não me parece que seja um esforço tão grande habilitar o HTTP/2 nos mesmos moldes.

Leitura adicional