Cada fluxo tem uma prioridade (também conhecido como "peso") que é utilizada para dizer ao par (peer) quais são os fluxos mais importantes, no caso de existirem restrições de recursos que forçam o servidor a selecionar quais fluxos enviar primeiro.
Utilizando o quadro PRIORITY, um cliente também pode dizer ao servidor qual outro fluxo este fluxo atual depende. Ele permite que o cliente construa uma árvore de prioridades onde vários "fluxos filho" podem depender da conclusão de "fluxos pai".
A prioridade dos pesos e as dependências podem ser modificadas dinamicamente em tempo de execução, o que pode permitir que os navegadores especifiquem, numa página cheia de imagens e o usuário utiliza a barra de rolagem, quais são as imagens mais importantes para serem carregadas, ou se você alterna as abas ele pode priorizar um novo grupo de fluxos que, de repente, entram em foco.
HTTP is a stateless protocol. Em suma, isso significa que cada requisição necessita enviar ao servidor todos os detalhes necessários para atender essa solicitação, sem que o servidor necessite armazenar uma grande quantidade de informações e metadados de requisições anteriores. Como o http2 não muda esse paradigma, ele tem que funcionar da mesma forma.
Isso torna o HTTP repetitivo. Quando um cliente solicita muitos recursos do mesmo servidor, como imagens de uma página web, haverá uma série de requisições e todas parecerão idênticas. Uma séria de coisas quase idênticas implora por compressão.
Enquanto o número de objetos por página web tem aumentado (como mencionado anteriormente), o uso de cookies e o tamanho das requisições também tem aumentado ao longo do tempo. Cookies também precisam ser incluídos em todas as requisições, muitas vezes os mesmos em várias requisições.
As requisições HTTP 1.1 tem realmente crescido tanto de tamanho que às vezes elas acabam ficando maior que a janela TCP inicial, o que as torna muito lentas para enviar, pois elas necessitam de um round-trip completo para obter um ACK de volta do servidor antes que a requisição completa seja enviada. Esse é um outro argumento para compressão.
A compressão de HTTPS e SPDY foi descoberta vulnerável aos ataques BREACH e CRIME. Inserindo um texto conhecido no fluxo e descobrindo como isso altera a saída, um invasor pode descobrir o que está sendo enviado em uma carga criptografada.
Realizando compressão em conteúdo dinâmico para um protocolo - sem se tornar vulnerável a um destes ataques - exige um pouco de reflexão e análise cuidadosa. Isto é o que o time HTTPbis tentou fazer.
Entra o HPACK, compressão de cabeçalho para HTTP/2, que - como o nome sugere - é um formato de compressão especialmente concebido para cabeçalhos http2, e está sendo especificado em um projeto separado. O novo formato, juntamente com outras medidas (como alguns pedem a intermediários que não comprimam cabeçalhos específicos e preenchimento opcional de quadros), deve torná-lo mais difícil de explorar a compressão.
"HPACK" foi projetado para tornar o vazamento de informações mais difícil em uma implementação de acordo, realizar a codificação e decodificação mais rápida e barata, fornecer para o receptor controle sobre a compressão do tamanho do contexto, permitir a reindexação por parte do proxy (ou seja, estado compartilhado) entre frontend e backend dentro de um proxy), e comparações rápidas de strings utilizando a codificação de Huffman".
Uma das desvantagens do HTTP 1.1 é que, quando uma mensagem é enviada com o cabeçalho Content-Length com um certo tamanho, não é possível cancelá-lo facilmente. Você pode (mas nem sempre) cancelar a conexão TCP, mas isso vem com o custo de negociar um handshake TCP novo.
Uma solução melhor seria apenas parar a mensagem e enviar uma nova. Isto pode ser feito com o quadro RST_STREAM do http2 que ajudará a previnir desperdícios e a necessidade de cancelar conexões.
Esta funcionalidade também é conhecida como "cache push". A ideia é que, se o cliente solicita o recurso X, o servidor pode determinar que o cliente também solicitará o recurso Z e enviará sem que o cliente o solicite. Isso ajudará o cliente colocando o recurso Z em cache de forma que ele estará lá quando for solicitado.