HTTP/2 - Perguntas Frequentes (saiba tudo sobre as mudanças no funcionamento da web!)


O HTTP 1.1 estava aí há mais de 15 anos e nem me dei conta.

Acho que você também não, né ?

Eis que chega o HTTP/2 pra mostrar que mudanças eram necessárias.

Adaptei a excelente FAQ do HTTP/2 no Github pra trazer informação útil e de qualidade pra você. Enjoy!

Questões gerais

Por que revisar o HTTP?

O HTTP 1.1 tem servido bem a web há mais de quinze anos, mas a sua idade começa a transparecer.

Carregar uma página web é uma tarefa mais intensiva do que nunca, e carregar todos esses ativos de forma eficiente é difícil, porque HTTP praticamente só permite uma solicitação por conexão TCP.

No passado, os navegadores usavam múltiplas conexões TCP para emitir solicitações paralelas. No entanto, há um limite para isso; se muitas conexões são usadas, isso é igualmente improdutivo (o controle de congestionamento de TCP é efetivamente negado, levando a eventuais congestionamentos que prejudicam não só o desempenho, como também a rede), e isso é fundamentalmente injusto (porque os navegadores estão pegando mais do que a parte que lhes cabe dos recursos da rede).

Ao mesmo tempo, o grande número de pedidos significa um monte de dados duplicados “no cabeamento”.

Estes fatores significam que os pedidos HTTP 1.1 acabam tendo muita sobrecarga; então se muitas solicitações são feitas, pior é o desempenho.

Isso tem levado a indústria a um lugar em que a melhor forma de fazer as coisas como spriting, dados inline, domain sharding (dados em vários domínios paralelizando conexões) e concatenação (concatenar arquivos pra fazer requisição única).

Estes hacks são indicações de problemas ocultos no próprio protocolo, e causam um número de problemas por conta própria quando utilizados.

Quem fez o HTTP/2?

HTTP/2 foi desenvolvido pelo Grupo de Trabalho do IETF, o qual mantém o protocolo HTTP. Ele é composto por uma série de implementadores HTTP, usuários, operadores de rede e especialistas em HTTP.

Note que enquanto a nossa mailing list está hospedada no site W3C, ela não é um esforço do W3C. Apesar disso, Tim Berners-Lee e a W3C TAG são mantidos atualizados de em relação ao progresso do grupo.

Um grande número de pessoas contribuiu para o esforço, mas os participantes mais ativos incluem engenheiros de projetos “grandes”, como Firefox, Chrome, Twitter, pilha HTTP da Microsoft, Curl e Akamai, assim como uma série de implementadores HTTP em linguagens como Python, Ruby e NodeJS.

Para saber mais sobre como participar no IETF, consulte o Tao da IETF; você também pode ter uma noção do que está contribuindo para a especificação no gráfico de colaborador do Github, e quem está colaborando na nossa lista de implementações.

Qual a relação com o SPDY?

O HTTP/2 foi discutido pela primeira vez quando se tornou evidente que o SPDY foi ganhando força com os implementadores (como Mozilla e ngnix), e foi mostrando melhorias significativas sobre HTTP/1.x..

Depois de um convite à apresentação de propostas e de um processo de seleção, SPDY/2 foi escolhido como base para HTTP/2. Desde então, houve uma série de mudanças, com base na discussão do Grupo de Trabalho e feedback dos implementadores.

Ao longo do processo, o núcleo de desenvolvedores do SPDY tem sido envolvido no desenvolvimento de HTTP/2, incluindo também Mike Belshe e Roberto Peon.

Em fevereiro de 2015, o Google anunciou seus planos para remover o suporte para SPDY em favor de HTTP/2.

É HTTP/2.0 OU HTTP/2?

O Grupo de Trabalho decidiu abandonar a versão secundária (".0"), porque ela tem causado muita confusão no HTTP/1.x.

Em outras palavras, a versão HTTP apenas indica compatibilidade de conexão, e não conjuntos de funcionalidades ou "marketing".

Quais as principais diferenças para o HTTP/1.x?

De forma simplificada, o HTTP/2:
  • É binário, em vez de textual;
  • É totalmente multiplexado, em vez de ordenado e bloqueante;
  • Pode, portanto, usar uma conexão para o paralelismo;
  • Usa compressão de cabeçalho para reduzir a sobrecarga;
  • Permite que os servidores façam “push” das respostas de forma proativa em caches de cliente.

Por que HTTP/2 é binário?

Protocolos binários são mais eficientes para analisar, mais compactos “no cabeamento”, e mais importante, são muito menos propensos a erros, em comparação com protocolos textuais, como HTTP/1.x, porque muitas vezes eles têm uma série de recursos intuitivos para "ajudar" com coisas como manipulação de espaços em branco, capitalização, finais de linha, links em branco e assim por diante.

Por exemplo, HTTP/1.1 define quatro formas diferentes de analisar uma mensagem; em HTTP/2, há apenas um código pra lidar com isso.

É verdade que o HTTP/2 não é utilizável através de telnet, mas nós já temos algumas ferramentas de apoio, como o plug-in do Wireshark.

Por que o HTTP/2 é multiplexado?

HTTP/1.x tem um problema chamado "bloqueio de cabeçalho-de-linha", onde efetivamente apenas uma solicitação pode ser destacada a cada conexão.

HTTP/1.1 tentou corrigir isso com pipelining, mas não abordou completamente o problema (uma resposta grande ou lenta ainda pode bloquear outras depois dela).

Além disso, o pipelining se verificou muito difícil de implementar, por conta de muitos intermediários e servidores não processarem corretamente a funcionalidade.

Isto obriga os clientes a usar um número de heurísticas (muitas vezes adivinhando) para determinar quais pedidos colocar em uma conexão de origem; uma vez que é comum para uma página carregar 10 vezes (ou mais) o número de conexões disponíveis, isso pode afetar severamente o desempenho, muitas vezes resultando num "efeito cascata" de solicitações bloqueadas.

A multiplexação trata desses problemas, permitindo que várias mensagens de solicitação e resposta estejam em transição ao mesmo tempo; é possível até mesmo se misturar partes de uma mensagem com outra na conexão.

Isto, por sua vez, permite a um cliente utilizar apenas uma conexão por origem para carregar uma página.

Por que só uma conexão TCP?

Com o HTTP/1, os navegadores abriam entre quatro e oito conexões por origem. Uma vez que muitos sites usam múltiplas origens, isso pode significar que um único carregamento de página abre mais de trinta conexões.

Uma aplicação abre tantas conexões simultaneamente que rompe uma série de premissas sobre as quais o TCP foi construído; já que cada conexão irá iniciar uma enxurrada de dados na resposta, há um risco real de que os buffers da rede estourem, causando congestionamento e retransmissões.

Além disso, o uso de tantas conexões monopoliza injustamente os recursos de rede, "roubando" de outras aplicações mais bem comportadas (por exemplo, VoIP).

Qual a vantagem do Servidor Push?

Quando um navegador solicita uma página, o servidor envia o HTML na resposta, e depois precisa esperar para que o navegador analise o HTML e emita os pedidos de todos os ativos incorporados antes que se possa começar a enviar as imagens, JavaScript e CSS.

O servidor push permite que o servidor, para evitar esse atraso na viagem, possa "empurrar" as respostas que ele acha que o cliente terá em seu cache.

Por que precisamos de compressão do cabeçalho?

Patrick McManus da Mozilla mostrou isso claramente calculando o efeito dos cabeçalhos em uma carga média da página.

Se você assumir que a página tem cerca de 80 ativos (que é conservador na web de hoje), e cada pedido tem 1.400 bytes de cabeçalhos (de novo, não é incomum, graças aos cookies, referer, etc.), é preciso pelo menos 7 a 8 idas e vindas para colocar os cabeçalhos "no cabeamento". Isso sem contar o tempo de resposta - esse tempo é apenas para obtê-los do cliente.

Isso é por causa do mecanismo Slow Start do TCP, que encaminha os pacotes em novas conexões com base em quantos pacotes foram reconhecidos (ack) - efetivamente limitando o número de pacotes que podem ser enviados para as primeiras transmissões.

Em comparação, até mesmo uma compressão suave em cabeçalhos permite que esses pedidos cheguem até a conexão dentro da mesma roundtrip – talvez até no mesmo pacote.

Essa sobrecarga é considerável, especialmente quando você leva em conta o impacto sobre os clientes móveis, que normalmente têm latência de várias centenas de milissegundos, mesmo em boas condições.

Por que HPACK?

O SPDY/2 propôs a utilização de um contexto GZIP único em cada sentido para a compressão de cabeçalho, que era simples de implementar, bem como eficiente.

Desde então, um grande ataque foi documentado contra o uso de compressão de fluxo (como GZIP) dentro de criptografia; CRIME.

Com CRIME, é possível para um atacante que tem a habilidade de injetar dados no fluxo criptografado, "sondar" o texto simples e recuperá-lo. Como se trata da web, JavaScript torna isso possível, e houve demonstrações da recuperação de cookies e tokens de autenticação usando CRIME para recursos HTTP protegidos por TLS.

Como resultado, não poderíamos usar a compressão GZIP. Não encontrando outros algoritmos adequados para este caso de uso, bem como seguros, criamos um esquema de compressão novo, específico para o cabeçalho e que opera em uma granularidade menor; uma vez que os cabeçalhos HTTP, muitas vezes não mudam entre as mensagens, isso ainda dá eficiência de compressão razoável, e é muito mais seguro.

O HTTP/2 pode tornar cookies (ou outros cabeçalhos) melhores?

Este esforço foi constituído para trabalhar em uma revisão do protocolo de conexão - ou seja, como os cabeçalhos HTTP, métodos, etc. são colocados "no cabeamento", para não mudar a semântica do HTTP.

Isso porque HTTP é tão amplamente utilizado. Se usássemos esta versão do HTTP para introduzir um novo mecanismo de estado (um exemplo que tem sido discutido) ou alterar os métodos de núcleo (felizmente, isso ainda não foi proposto), isso significaria que o novo protocolo seria incompatível com a web existente.

Em particular, queremos ser capazes de traduzir a partir de HTTP/1 para HTTP/2 e vice-versa, sem perda de informação. Se começássemos a "limpar" os cabeçalhos (e a maioria vai concordar que os cabeçalhos HTTP são bastante confusos), teríamos problemas de interoperabilidade com grande parte da web existente.

Fazer isso seria apenas criar atrito contra a adoção do novo protocolo.

Dito isto, o Grupo de Trabalho HTTP é responsável por todas as versões do HTTP, não apenas HTTP/2. Como tal, podemos trabalhar em novos mecanismos que sejam independentes de versão, desde que eles sejam compatíveis com versões anteriores à da web existente.

E quanto ao uso do HTTP "fora do navegador"?

Aplicações não navegadoras devem ser capazes de usar o HTTP/2 tão bem quanto já usam o  HTTP.

O feedback inicial foi de que HTTP/2 tem boas características de desempenho para "APIs" HTTP, porque as APIs não precisam considerar coisas como pedidos sobrecarregados em seu design.

Tendo dito isso, o foco principal das melhorias que estamos considerando são os casos de uso típicos para navegação, uma vez que este é o caso de uso de núcleo para o protocolo.

Nosso comunicado diz o seguinte sobre isso:

A(s) especificação(ões) resultante(s) pretendem atender aos seguintes objetivos para implantações comuns existentes para o uso do HTTP; em particular, a navegação na web (desktop e móvel), não navegadores ("APIs" HTTP), serviços web (em uma variedade de escalas), e intermediários (proxies, firewalls corporativos, proxies "reversos" e redes CDN). Da mesma forma, extensões semânticas atuais e futuras para HTTP/1.x (por exemplo, cabeçalhos, métodos, códigos de estado, diretivas de cache) devem ser suportadas no novo protocolo.

Note que isso não inclui usos de HTTP onde se confia em comportamentos não especificados (por exemplo, estados de conexão tais como limites de tempo ou afinidade de cliente, e  proxies de“interceptação”); esses usos podem ou não ser habilitados no produto final.

O HTTP/2 exige criptografia?

Não. Depois de uma ampla discussão, o Grupo de Trabalho não teve consenso para exigir o uso de criptografia (por exemplo, TLS) para o novo protocolo.

No entanto, algumas implementações afirmaram que só irão apoiar HTTP/2 quando ele for usado por uma conexão criptografada.

O que HTTP/2 fez para melhorar a segurança?

HTTP/2 define um perfil de TLS que é requerido; isso inclui a versão, uma lista negra "ciphersuite" e extensões usadas.

Veja as especificações para obter mais detalhes.

Há também a discussão de mecanismos adicionais, como o uso de TLS para URLs http:// (a chamada "criptografia oportunista"); veja o draft da respectiva especificação.

Posso usar HTTP/2 agora?

HTTP/2 está atualmente disponível no Firefox e no Chrome para teste, utilizando o identificador de protocolo "h2-14".

Existem também vários servidores disponíveis (incluindo um servidor de teste de Akamai, Google e site principal do Twitter), e uma série de implementações de código aberto que você pode implementar e testar.

Veja a lista de implementações para mais detalhes.

HTTP/2 substituirá HTTP/1.x?

O objetivo do Grupo de Trabalho é que os usos típicos de HTTP/1.x possam usar HTTP/2 e ver algum benefício. Dito isto, não podemos forçar o mundo a migrar, e por causa da maneira que as pessoas implantam proxies e servidores, é provável que HTTP/1.x ainda esteja em uso por algum tempo.

Haverá um HTTP/3 ?

Se o mecanismo de negociação introduzido pelo HTTP/2 funcionar bem, deve ser possível que suporte novas versões do HTTP muito mais facilmente do que no passado.

Questões de Implementação

Por que as regras em torno da continuação dos quadros HEADERS?

A continuação existe pelo fato de que um único valor (por exemplo, Set-Cookie) pode exceder 16KiB - 1, o que significa que ele não cabe em um único quadro. Decidiu-se que a maneira de lidar com isso menos propensa a erros era exigir que todos os dados de cabeçalhos fossem em quadros back to back, o que tornou a decodificação e gerenciamento do buffer mais fácil.

Qual é a quantidade de memória mínima ou máxima para o estado do HPACK?

O receptor sempre controla a quantidade de memória utilizada no HPACK, e pode definí-la zero, no mínimo, com um máximo relacionado com o inteiro máximo representável em um quadro SETTINGS, atualmente 2^32-1.

Como posso evitar manter o estado de HPACK?

Enviar um quadro SETTINGS ajustando a quantidade de memória (SETTINGS_HEADER_TABLE_SIZE) para zero, então fazendo reset (RST) de todos os fluxos de conexão até que um quadro de definições com o bit ACK setado seja recebido.

Por que há um único contexto de compressão/controle de fluxo?

Simplicidade.

As propostas originais tinham grupos de fluxo, os quais compartilhavam contexto, controle de fluxo, etc. Embora isso beneficiasse proxies (e a experiência de utilização dos usuários através deles), isso acrescentou um pouco de complexidade. Foi decidido que iríamos começar com a coisa simples, ver o quão doloroso seria, e enfrentar a dor (se houver) em uma futura revisão do protocolo.

Por que há um símbolo EOS em HPACK?

A codificação Huffman do HPACK, por razões de eficiência de CPU e segurança, aloca cadeias codificadas em Huffman para o próximo limite de bytes; pode ser necessário entre 0 e 7 bits de preenchimento para qualquer sequência de caracteres.

Se considerarmos a decodificação Huffman isoladamente, qualquer símbolo que seja mais longo do que o necessário para preenchimento iria funcionar; no entanto, o projeto do HPACK permite a comparação inteligente de bytes em strings codificadas com Huffman. Ao exigir que os bits do símbolo EOS sejam utilizados para preenchimento, podemos garantir que os usuários possam fazer comparação de sequências codificadas Huffman para determinar a igualdade. Isto por sua vez significa que muitos dos cabeçalhos podem ser interpretados sem ser decodificados.

Posso implementar HTTP/2 sem implementar HTTP/1.1?

Sim, em grande parte.

Para HTTP/2 sobre TLS (h2), não é necessário implementar o identificador ALPN do HTTP1.1, não sendo requerida qualquer característica do HTTP/1.1.

Para HTTP/2 sobre TCP (h2c), é necessário para implementar uma solicitação de atualização inicial.

Clientes h2c precisarão gerar uma solicitação OPTIONS para "*" ou uma solicitação HEAD para "/", que são relativamente seguros e fáceis de construir. Os clientes que procuram implementar apenas HTTP/2 vão precisar tratar respostas HTTP/1.1 sem um código 101 como erros.

Servidores h2c podem aceitar um pedido que contém o campo de cabeçalho de atualização com uma resposta fixa 101. Pedidos sem o token de atualização h2c podem ser rejeitados com um código de status 505 (versão HTTP sem suporte), que contém o campo de cabeçalho de atualização. Os servidores que não desejam processar resposta HTTP/1.1 devem rejeitar o fluxo 1 com um código de erro REFUSED_STREAM imediatamente após o envio do prefácio de conexão para incentivar o cliente a repetir o pedido via HTTP/2.

Questões de Implantação

Como depurar HTTP/2 se ele é criptografado?

Há muitas maneiras de obter acesso aos dados da aplicação, mas o mais fácil é usar NSS keylogging em combinação com o plug-in Wireshark (incluído nas últimas versões de desenvolvimento). Isso funciona tanto com o Firefox quanto com o Chrome.

Conclusão

Demorou mas chegou.

Refletindo após a leitura da especificação do HTTP/2, ficou claro pra mim que o trabalho do protocolo estava sendo feito pelos navegadores, como registramos no caso do Chrome e Firefox aqui no blog (embora sem a noção que descrevo agora).

Entendo que isso significa que os navegadores terão condição de evoluir para áreas anteriormente não priorizadas, como interface com usuário, integração com serviços (redes sociais, por exemplo) e outras coisas muito legais que não dava pra fazer porque a prioridade era entregar um desempenho satisfatório pro usuário e fazer malabarismos pra lidar bem com áudio, imagem, vídeo e texto da melhor maneira possível.

E você, o que achou da nova versão do HTTP ? Diz aí!

Christian Guerreiro

Professor por vocação, blogueiro e servidor público por opção, amante da tecnologia e viciado em informação.


Ensino a distância em Tecnologia da Informação: Virtualização com VMware, Big Data com Hadoop, Certificação ITIL 2011 Foundations e muito mais.


Suporte o Tecnologia que Interessa!

Você acha que as informações compartilhadas aqui são úteis?
Então me ajude a produzir ainda mais e melhores conteúdos!


É muito fácil. Basta divulgar nossos treinamentos pra alguém que conheça!


E se for de Salvador, podemos estruturar um curso presencial para sua empresa!

Eu vou ficar muito grato (e quem fizer os curso também :)!