Funcionamento - Headers Stateful

O HTTP 2.0 e o SPDY deixam as requisições em si mais baratas. Por exemplo, antes precisávamos habilitar o GZIP explicitamente no servidor para comprimir as respostas trafegadas. Agora, GZIP é padrão no protocolo, uma coisa a menos pra se preocupar.

Mais que isso: um alto custo de se fazer vários requests no HTTP 1.1 era o tráfego dos cabeçalhos (headers). Eles não era comprimidos mas enviados em texto puro. E, pra piorar, cabeçalhos tinham que ser mandados novamente a toda requisição.

No HTTP 2.0, os cabeçalhos são binários e compactados. Além disso, com os header tables, o navegador e o servidor podem mandar um certo header uma vez só e reaproveitar para as requisições seguintes. Só é preciso mandar os cabeçalhos que mudam. Isso deixa as requisições ainda mais baratas e justificam ainda mais a prática de usar vários requests ao invés de concatenar as coisas como fazíamos antigamente.

Aliás, uma prática que era recomendada no HTTP 1.1 de usar domínios sem cookies para servir imagens, CSS e JS, passa a ser irrelevante. Como os cookies são enviados em um header, sabemos que agora serão enviados uma vez só na conexão. Sim, o protocolo agora é statefull. Mas detalhe é que é statefull na connection, não na requisição. Requisições em conexões paralelas não compartilham estado. Mas a mesma connection sim, pode compartilhar.

Isso vai exigir recursos do servidor, memória pra manter o estado e tal. Mas não vejo como grave. E não é um limitante para escalabilidade, pois não há estado compartilhado entre conexões.

Já a semântica do protocolo HTTP em si continua stateless. Só otimizaram o transporte e aí o statefull foi um grande ganho.

E se pensar bem, hoje usar HTTPS mesmo no 1.1 é de certa forma manter uma connection stateful já. Feito o handshake TLS, o estado das chaves/certificados é mantido na conexão toda, ocupando memória no cliente e no servidor.