HTTP / 2 - HTTP/2

HTTP / 2 (originalmente denominado HTTP / 2.0 ) é uma revisão importante do protocolo de rede HTTP usado pela World Wide Web . Ele foi derivado do protocolo SPDY experimental anterior , originalmente desenvolvido pelo Google . HTTP / 2 foi desenvolvido pelo Grupo de Trabalho HTTP (também chamado de httpbis, onde " bis " significa "duas vezes") da Força-Tarefa de Engenharia da Internet (IETF). HTTP / 2 é a primeira nova versão de HTTP desde HTTP / 1.1, que foi padronizado no RFC  2068 em 1997. O Grupo de Trabalho apresentou HTTP / 2 ao Internet Engineering Steering Group (IESG) para consideração como um padrão proposto em dezembro de 2014, e o IESG aprovou a publicação como Proposta de Padrão em 17 de fevereiro de 2015 (e foi atualizado em fevereiro de 2020 em relação ao TLS 1.3 ). A especificação HTTP / 2 foi publicada como RFC  7540 em 14 de maio de 2015.

O esforço de padronização foi apoiado pelos navegadores Chrome , Opera , Firefox , Internet Explorer 11 , Safari , Amazon Silk e Edge . A maioria dos navegadores principais adicionou suporte a HTTP / 2 no final de 2015. Cerca de 97% dos navegadores da web usados ​​têm esse recurso. Em outubro de 2021, 47% (após atingir o máximo com pouco mais de 50%) dos principais 10 milhões de sites da Web suportavam HTTP / 2.

Seu sucessor proposto é o HTTP / 3 , uma revisão importante que se baseia nos conceitos estabelecidos pelo HTTP / 2.

Metas

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

• Crie 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.
• Mantenha a compatibilidade de alto nível com HTTP / 1.1 (por exemplo, com métodos , códigos de status , URIs e a maioria dos campos de cabeçalho ).
• Diminua a latência para melhorar a velocidade de carregamento da página em navegadores da web , considerando:
  • compressão de dados de cabeçalhos HTTP
  • Push de servidor HTTP / 2
  • pipelining de solicitações
  • corrigindo o problema de bloqueio head-of-line em HTTP 1.x
  • multiplexar várias solicitações em uma única conexão TCP
• Comum suporte casos de uso de HTTP, tais como navegadores de desktop web, navegadores móveis, web APIs, existente servidores web em várias escalas, servidores proxy , proxy reverso servidores, firewalls e redes de distribuição de conteúdo .

Diferenças de HTTP / 1.1

As alterações propostas não exigem nenhuma alteração na forma como os aplicativos da web existentes funcionam, mas os novos aplicativos podem tirar proveito dos novos recursos para aumentar a velocidade. O HTTP / 2 mantém todas as semânticas de alto nível do HTTP / 1.1, como métodos , códigos de status , campos de cabeçalho e URIs , iguais. A novidade é como os dados são enquadrados e transportados entre o cliente e o servidor.

Os sites que são eficientes minimizam o número de solicitações necessárias para renderizar uma página inteira, minimizando (reduzindo a quantidade de código e empacotando pedaços menores de código em pacotes, sem reduzir sua capacidade de funcionamento) 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 minimizados. O HTTP / 2 permite que o servidor "empurre" o 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 da web precisará para 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.

Melhorias de desempenho adicionais no primeiro rascunho de 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 direto no HTTP 1 (mesmo quando o pipelining HTTP é usado), compactação de cabeçalho e priorização de solicitações. No entanto, como o HTTP / 2 é executado em uma única conexão TCP, ainda existe a possibilidade de ocorrer um bloqueio direto se os pacotes TCP forem perdidos ou atrasados ​​na transmissão. O HTTP / 2 não oferece mais suporte ao mecanismo de codificação de transferência em partes do HTTP / 1.1 , pois fornece seus próprios mecanismos mais eficientes para streaming de dados.

História

Genesis in e diferenças posteriores de SPDY

SPDY (pronunciado como "speedy") foi um protocolo de substituição de HTTP anterior desenvolvido por um projeto de pesquisa liderado pelo Google . Focado principalmente na redução da latência, o SPDY usa o mesmo canal TCP, mas protocolos diferentes para realizar essa redução. As mudanças básicas feitas no HTTP / 1.1 para criar SPDY incluíam: "true request pipelining sem restrições FIFO, mecanismo de enquadramento de mensagem para simplificar o desenvolvimento de cliente e servidor, compressão obrigatória (incluindo cabeçalhos), agendamento de prioridade e até mesmo comunicação bidirecional".

O Grupo de Trabalho HTTP considerada protocolo do Google SPDY, Microsoft 's HTTP Velocidade + Mobilidade proposta (SPDY base) e de actualização HTTP Network-friendly. Em julho de 2012, o Facebook forneceu feedback sobre cada uma das propostas e recomendou que o HTTP / 2 fosse baseado no SPDY. O rascunho inicial do HTTP / 2 foi publicado em novembro de 2012 e foi baseado em uma cópia direta do SPDY.

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

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 compactação de cabeçalho baseado em código de Huffman fixo , em vez da compactação baseada em fluxo dinâmico do SPDY. Isso ajuda a reduzir o potencial de ataques do oráculo de compactação no protocolo, como o ataque CRIME .

Em 9 de fevereiro de 2015, o Google anunciou planos para remover o suporte para SPDY no Chrome em favor do suporte para HTTP / 2. Isso entrou em vigor a partir do Chrome 51.

Marcos de desenvolvimento

Encriptação

HTTP / 2 é definido para URIs HTTP (ou seja, sem criptografia TLS , uma configuração que é abreviada em h2c ) e para URIs HTTPS (sobre TLS usando extensão ALPN onde TLS 1.2 ou mais recente é necessário, uma configuração que é abreviada em h2 ).

Embora o padrão em si não exija o uso de criptografia, todas as principais implementações de cliente (Firefox, Chrome, Safari, Opera, IE, Edge) declararam que suportarão apenas HTTP / 2 sobre TLS, o que torna a criptografia de fato obrigatória.

Críticas

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

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

Encriptação

Custo computacional de criptografia obrigatória e disponibilidade de certificado

Inicialmente, alguns membros 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 de criptografia e seus provedores não desejam gastar recursos adicionais nela. Os proponentes da criptografia afirmaram que essa sobrecarga de criptografia é insignificante na prática. Poul-Henning Kamp criticou o IETF por padronizar apressadamente o protótipo SPDY do Google como HTTP / 2 devido a considerações políticas. A crítica à agenda de criptografia obrigatória dentro da estrutura de certificado existente não é nova, nem é exclusiva para membros da comunidade de código aberto - um funcionário da Cisco afirmou em 2013 que o modelo de certificado atual não é compatível com pequenos dispositivos como roteadores, porque o modelo atual exige não apenas a inscrição anual e a remissão de taxas não triviais para cada certificado, mas deve ser repetido continuamente em uma base anual. O Grupo de Trabalho finalmente não chegou a um consenso sobre a criptografia obrigatória, embora a maioria das implementações de cliente exija, o que torna a criptografia um requisito de fato .

Falta de criptografia oportunista

O protocolo HTTP / 2 também enfrentou críticas por não suportar 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 HTTP / 2 viola a própria RFC  7258 da IETF "Monitoramento invasivo é um ataque", que também tem um status de Melhor Prática Atual 188. RFC7258 / BCP188 determina que o monitoramento passivo seja considerado um ataque, e os protocolos projetados pela IETF devem tomar medidas para se proteger contra o monitoramento passivo (por exemplo, por meio do uso de criptografia oportunista). Uma série de especificações para criptografia oportunista de HTTP / 2 foram fornecidas, das 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.

Bloqueio TCP head-of-line

Embora o projeto de HTTP / 2 resolva efetivamente o problema de bloqueio de cabeçalho no nível de 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 cabeçalho de nível de pacote o bloqueio de linha do fluxo TCP bloqueia simultaneamente todas as transações acessadas por meio dessa conexão. Esse bloqueio direto no HTTP / 2 agora é amplamente considerado uma falha de design, e muito do esforço por trás do QUIC e HTTP / 3 foi dedicado a reduzir os problemas de bloqueio direto.

Suporte do lado do servidor

Software de servidor

• O Apache 2.4.12 oferece suporte a HTTP / 2 por meio do módulo mod_h2, embora os patches apropriados devam ser aplicados ao código-fonte do servidor para que ele suporte esse módulo. A partir do Apache 2.4.17, todos os patches estão incluídos na árvore de origem principal do Apache, embora o próprio módulo tenha sido renomeado como mod_http2. Versões antigas do SPDY eram suportadas por meio do módulo mod_spdy, no entanto, o desenvolvimento do módulo mod_spdy foi interrompido.
• O Apache Tomcat oferece suporte a HTTP / 2 com a versão 8.5 e mais recente com uma alteração na configuração.
• O Apache Traffic Server oferece suporte a HTTP / 2.
• Caddy suporta HTTP / 2.
• Charles Proxy suporta HTTP / 2 desde a versão Charles 4.
• Citrix NetScaler 11.x oferece suporte a HTTP / 2.
• Sucuri oferece suporte a HTTP / 2.
• F5 BIG-IP Local Traffic Manager 11.6 oferece suporte a HTTP / 2.
• Barracuda Networks WAF (Web Application Firewall) suporta HTTP / 2.
• H2o foi desenvolvido desde o início para suporte HTTP / 2.
• O HAProxy 1.8 é compatível com HTTP / 2.
• Jetty 9.3 oferece suporte a HTTP / 2.
• lighttpd 1.4.56 suporta HTTP / 2.
• O LiteSpeed ​​Web Server 5.0 oferece suporte a HTTP / 2.
• O Microsoft IIS oferece suporte a HTTP / 2 no Windows 10, Windows Server 2016 e Windows Server 2019 .
• Netty 4.1 suporta HTTP / 2.
• O nginx 1.9.5 suporta HTTP / 2, lançado em 22 de setembro de 2015, usando o módulo ngx_http_v2_module e HTTP / 2 Server Push desde a versão 1.13.9 em 20 de fevereiro de 2018.
• Suporte Node.js estável desde 8.13.0. (5.0 suporta HTTP / 2 com um módulo e o Node 8.4 introduziu suporte experimental integrado para HTTP / 2.)
• O servidor da Web Kestrel para ASP.NET Core oferece suporte a HTTP / 2 desde .NET Core 2.2.0-preview 1.
• OpenLiteSpeed ​​1.3.11 e 1.4.8 oferece suporte a HTTP / 2.
• O Proxygen oferece suporte a HTTP / 2.
• O Pulse Secure Virtual Traffic Manager 10.2 oferece suporte a HTTP / 2.
• O Radware Alteon NG oferece suporte a HTTP / 2.
• ShimmerCat oferece suporte a HTTP / 2.
• Vert.x 3.3 oferece suporte a HTTP / 2.
• Warp ( servidor da web Haskell , usado por padrão em Yesod ) oferece suporte a HTTP / 2.
• Wildfly 9 oferece suporte a HTTP / 2.
• O proxy Envoy oferece suporte a HTTP / 2.

Redes de distribuição de conteúdo

• Akamai foi o primeiro grande CDN a suportar HTTP / 2 e HTTP / 2 Server Push .
• O Microsoft Azure oferece suporte a HTTP / 2.
• O PageCDN suporta HTTP / 2 pronto para uso e fornece interface de usuário para configurar o HTTP / 2 Server Push no painel CDN.
• O CDN77 é compatível com HTTP / 2 usando nginx (20 de agosto de 2015) .
• Cloudflare suporta HTTP / 2 usando nginx com SPDY como um fallback para navegadores sem suporte, mantendo todos os serviços de segurança e desempenho. A Cloudflare foi a primeira grande CDN a oferecer suporte a HTTP / 2 Server Push .
• O AWS CloudFront oferece suporte a HTTP / 2 desde 7 de setembro de 2016.
• Suporta rapidamente HTTP / 2 incluindo Server Push.
• Imperva Incapsula CDN suporta HTTP / 2. A implementação inclui suporte para recursos de mitigação WAF e DDoS também.
• KeyCDN oferece suporte a HTTP / 2 usando nginx (6 de outubro de 2015). O teste HTTP / 2 é uma página de teste para verificar se o seu servidor oferece suporte a HTTP / 2.
• Voxility oferece suporte a HTTP / 2 usando nginx desde julho de 2016. A implementação vem com suporte para serviços de mitigação de DDoS em nuvem.
• StackPath oferece suporte a HTTP / 2.

Implementações

• Outras implementações são coletadas no wiki GitHub HTTP / 2 .

Veja também

• gRPC
• Pipelining HTTP
• Solicitação HTTP e mensagens de resposta
• HTTP / 3
• QUIC
• SPDY
• WebSocket
• Servidor web
• Navegador da web
• Comparação de navegadores da web § Suporte de protocolo

Referências

links externos

• Website oficial
• RFC  7540 - Protocolo de transferência de hipertexto versão 2 (HTTP / 2)
• RFC  7541 - HPACK: Compactação de cabeçalho para HTTP / 2
• Protocolo SPDY (draft-mbelshe-httpbis-spdy-00)
• Velocidade + Mobilidade HTTP (draft-Montenegro-httpbis-speed-mobilidade-01)
• Proposta para uma atualização de HTTP compatível com a rede (draft-tarreau-httpbis-network-friendly-00)