HTTP/2

 

O estatuto do grupo de trabalho menciona vários objetivos e questões preocupantes:^[4]

• Criar um mecanismo de negociação que permita que clientes e servidores optem por usar HTTP 1.1, 2.0 ou potencialmente outros protocolos não HTTP.
• Manter a compatibilidade de alto nível com o HTTP 1.1 (por exemplo, com métodos, códigos de status, URIs e a maioria dos campos de cabeçalho).
• Diminuir a latência para melhorar a velocidade de carregamento da página nos navegadores web, considerando:
  • comprimir dados de cabeçalhos HTTP
  • HTTP/2 Server Push
  • pipelining de solicitações
  • corrigir o problema do bloqueio de cabeça de fila no HTTP 1.x
  • multiplexar várias solicitações em uma única conexão TCP
• Oferecer suporte a casos de uso comuns existentes do HTTP, como navegadores web para desktop, navegadores web móveis, APIs web, servidores web em várias escalas, servidores proxy, servidores proxy reverso, firewalls e redes de fornecimento de conteúdo.

As alterações propostas não exigem nenhuma mudança no funcionamento dos aplicativos Web existentes, mas os novos aplicativos podem tirar proveito dos novos recursos para aumentar a velocidade.^[18] O HTTP/2 deixa toda a semântica de alto nível do HTTP 1.1, como métodos, códigos de status, campos de cabeçalho e URIs, da mesma forma. A novidade é como os dados são estruturados e transportados entre o cliente e o servidor.^[18]

Os sites que são eficientes minimizam o número de solicitações necessárias para renderizar uma página inteira através da minimização (reduzindo a quantidade de código e empacotando partes menores de código em pacotes grandes, sem reduzir sua capacidade de funcionar) de recursos, como imagens e scripts. No entanto, a minimização não é necessariamente conveniente nem eficiente e ainda pode exigir conexões HTTP separadas para obter a página e os recursos minificados. O HTTP/2 permite que o servidor "envie" conteúdo, ou seja, responda com dados para mais consultas do que o cliente solicitou. Isso permite que o servidor forneça dados que sabe que um navegador precisará renderizar uma página da Web, sem esperar que o navegador examine a primeira resposta e sem a sobrecarga de um ciclo de solicitação adicional.^[19]

Melhorias de desempenho adicionais no primeiro rascunho do HTTP/2 (que era uma cópia do SPDY) vêm da multiplexação de solicitações e respostas para evitar alguns dos problemas de bloqueio de cabeça de fila no HTTP 1 (mesmo quando o pipelining HTTP é usado), compressão de cabeçalho e priorização de solicitações.^[20] No entanto, como o HTTP/2 é executado em cima de uma única conexão TCP, ainda existe o potencial de bloqueio de cabeça de fila se os pacotes TCP forem perdidos ou atrasados na transmissão.^[21] O HTTP/2 não oferece mais suporte ao mecanismo de codificação de transferência em blocos do HTTP 1.1, pois fornece mecanismos próprios e mais eficientes para o fluxo de dados.^[22]

O SPDY (pronunciado como "speedy") era um protocolo anterior criado para substituir o HTTP desenvolvido por um projeto de pesquisa liderado pelo Google.^[23] Principalmente focado na redução da latência, o SPDY usa o mesmo canal TCP, mas diferentes protocolos para realizar essa redução. As mudanças básicas feitas no HTTP 1.1 para criar o SPDY incluíram: "verdadeiro pipelining de solicitação sem restrições FIFO, mecanismo de enquadramento de mensagens para simplificar o desenvolvimento de clientes e servidores, compressão obrigatória (incluindo cabeçalhos), agendamento de prioridades e até comunicação bidirecional".^[24]

O HTTP Working Group considerou o protocolo SPDY do Google, o protocolo HTTP Speed+Mobility proposto pela Microsoft (baseado em SPDY) ^[23] e o Network-Friendly HTTP Upgrade.^[25] Em julho de 2012, o Facebook forneceu feedback sobre cada uma das propostas e recomendou que o HTTP/2 fosse baseado no SPDY.^[26] O rascunho inicial do HTTP/2 foi publicado em novembro de 2012 e foi baseado em uma cópia direta do SPDY.^[27]

A maior diferença entre HTTP/1.1 e SPDY foi que cada ação do usuário no SPDY recebe um "ID de fluxo", significando que há um único canal TCP conectando o usuário ao servidor. O SPDY divide solicitações em controle ou dados, usando um "protocolo binário simples de analisar com dois tipos de quadros".^[24][28] O SPDY mostrou uma melhora evidente em relação ao HTTP, com um aumento da velocidade de carregamento de nova página variando entre 11,81% a 47,7%.^[29]

O desenvolvimento do HTTP/2 usou o SPDY como ponto de partida. Entre as muitas diferenças detalhadas entre os protocolos, a mais notável é que o HTTP/2 usa um algoritmo de compressão de cabeçalho baseado em codificação de Huffman fixo, em vez da compressão dinâmica baseada em fluxo usada pelo SPDY. Isso ajuda a reduzir o potencial para ataques de oráculo de compressão no protocolo, como o ataque CRIME.^[28]

Em 9 de fevereiro de 2015, o Google anunciou planos para remover o suporte ao SPDY no Chrome em favor do suporte ao HTTP/2.^[30][9] Isso entrou em vigor, começando com o Chrome 51.^[31][32]

O HTTP/2 é definido para URIs HTTP (ou seja, sem criptografia) e para URIs HTTPS (sobre TLS usando a extensão ALPN^[33] onde o TLS 1.2 ou mais recente é exigido).^[34]

Embora o padrão em si não exija o uso de criptografia,^[35] todas as principais implementações de clientes (Firefox,^[36] Chrome, Safari, Opera, IE, Edge) declararam que suportam apenas HTTP/2 sobre TLS, o que torna a criptografia de facto obrigatória.^[37]

O processo de desenvolvimento do HTTP/2 e o próprio protocolo enfrentaram críticas.

O desenvolvedor do FreeBSD e do Varnish, Poul-Henning Kamp, afirma que o padrão foi preparado em um cronograma irrealisticamente curto, descartando qualquer base para o novo HTTP/2 que não seja o protocolo SPDY e resultando em outras oportunidades perdidas para fazer melhorias.^[38] Kamp critica o próprio protocolo por ser inconsistente e ter complexidade desnecessária e esmagadora.^[38] Ele também afirma que o protocolo viola o princípio de estratificação de protocolos,^[38] por exemplo, duplicando o controle de fluxo que pertence à camada de transporte (TCP). A maioria das preocupações, no entanto, está relacionada a problemas de criptografia.

Inicialmente, alguns membros^[quem?] do Grupo de Trabalho tentaram introduzir um requisito de criptografia no protocolo. Isso enfrentou críticas.

Os críticos afirmaram que a criptografia tem custos de computação não desprezíveis e que muitos aplicativos HTTP não precisam realmente de criptografia e seus fornecedores não desejam gastar recursos adicionais nela. Os proponentes da criptografia declararam que essa sobrecarga é insignificante na prática.^[39] Poul-Henning Kamp criticou o IETF por seguir uma agenda política específica com o HTTP/2.^[38][40][41] As críticas à agenda da criptografia obrigatória dentro da estrutura de certificado existente não são novas, nem são exclusivas para membros da comunidade de código aberto – um funcionário da Cisco declarou em 2013 que o presente modelo de certificado não é compatível com dispositivos pequenos como roteadores, porque o modelo atual exige não apenas inscrição e remissão anual de taxas não triviais para cada certificado, mas deve ser repetido continuamente anualmente.^[42] O Grupo de Trabalho finalmente não chegou a um consenso sobre a criptografia obrigatória,^[35] embora a maioria das implementações de clientes a exija, o que torna a criptografia de facto um requisito obrigatório.

O protocolo HTTP/2 também enfrentou críticas por não oferecer suporte à criptografia oportunista, uma medida contra o monitoramento passivo semelhante ao mecanismo STARTTLS que está disponível há muito tempo em outros protocolos da Internet, como o SMTP. Os críticos afirmaram que a proposta do HTTP/2 viola o RFC 7258 da IETF, "Pervasive Monitoring Is an Attack", que também tem o status de Best Current Practice 188.^[43] A RFC7258/BCP188 exige que o monitoramento passivo seja considerado um ataque, e os protocolos projetados pelo IETF devem tomar medidas para se protegerem contra o monitoramento passivo (por exemplo, através do uso de criptografia oportunista). Foram fornecidas várias especificações para criptografia oportunista do HTTP/2,^[44][45][46] dos quais draft-nottingham-http2-encryption foi adotado como um item de trabalho oficial do grupo de trabalho, levando à publicação da RFC 8164 em maio de 2017.

Embora o projeto do HTTP/2 resolva efetivamente o problema de bloqueio de cabeça de fila no nível da transação HTTP, permitindo várias transações HTTP simultâneas, todas essas transações são multiplexadas em uma única conexão TCP, o que significa que qualquer bloqueio de cabeça de fila no nível de pacote do fluxo TCP bloqueia simultaneamente todas as transações acessadas por essa conexão. Esse bloqueio de cabeça de fila no HTTP/2 agora é amplamente considerado como uma falha de projeto, e grande parte do esforço por trás do QUIC e do HTTP/3 foi dedicado a reduzir os problemas de bloqueio de cabeça de fila.^[47][48]

• gRPC
• HTTP pipelining
• HTTP/3
• QUIC
• SPDY
• WebSocket