 | Este artigo resulta, no todo ou em parte, de umatradução do artigo«HTTP/2» na Wikipédia em inglês, na versão original. Você podeincluir conceitos culturais lusófonos de fontes emportuguês comreferências einseri-las corretamente no texto ou norodapé. Também podecontinuar traduzindo ou colaborar em outrastraduções.(Data da tradução:2 de maio de2020) —Encontre fontes:ABW • CAPES • Google (notícias • livros • acadêmico) |
| HTTP/2 | |
|---|---|
| Padrão internacional | RFC 7540 |
| Desenvolvido por | IETF |
| Introduzido | 14 de maio de 2015; há 9 anos |
HTTP/2 (originalmente chamadoHTTP/2.0) é uma revisão importante do protocolo de redeHTTP usado pelaWorld Wide Web. Foi derivado do protocolo experimental anteriorSPDY, originalmente desenvolvido peloGoogle.[1][2] O HTTP/2 foi desenvolvido pelo HTTP Working Group (também chamado httpbis, onde "bis" significa "segundo") doInternet Engineering Task Force.[3][4][5] O HTTP/2 é a primeira nova versão do HTTP desde o HTTP 1.1, padronizada naRFC 2068 em 1997. O Working Group apresentou o HTTP/2 ao IESG para consideração como Padrão Proposto em dezembro de 2014,[6] e o IESG aprovou a publicação como Padrão Proposto em 17 de fevereiro de 2015.[7] A especificação HTTP/2 foi publicada comoRFC 7540 em 14 de maio de 2015.[8]
O esforço de padronização foi suportado pelos navegadoresChrome[9],Opera,Firefox,[10]Internet Explorer 11,Safari,Amazon Silk eEdge.[11] A maioria dos principais navegadores adicionou suporte a HTTP/2 até o final de 2015.[12]
De acordo com a W3Techs, em abril de 2020, 43,6% dos 10 milhões de sites mais acessados suportavam o HTTP/2.[13]
Seu sucessor proposto é oHTTP/3, uma revisão importante do protocolo HTTP que se baseia nos conceitos estabelecidos pelo HTTP/2.[14][2] O suporte para HTTP/3 foi adicionado aoChrome (compilação Canary) em setembro de 2019 (e oCloudflare também adicionou suporte para), e embora o HTTP/3 ainda não esteja ativado por padrão em qualquer navegador, em 2020 o HTTP/3 possui suporte não padrão em versões estáveis do Chrome e Firefox e pode ser ativado.[15][16][17]
O estatuto do grupo de trabalho menciona vários objetivos e questões preocupantes:[4]
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, comométodos,códigos de status,campos de cabeçalho eURIs, 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 damultiplexação de solicitações e respostas para evitar alguns dos problemas debloqueio de cabeça de fila no HTTP 1 (mesmo quando opipelining 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 decodificação de transferência em blocos do HTTP 1.1, pois fornece mecanismos próprios e mais eficientes para o fluxo de dados.[22]
OSPDY (pronunciado como "speedy") era um protocolo anterior criado para substituir o HTTP desenvolvido por um projeto de pesquisa liderado peloGoogle.[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çõesFIFO, 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 protocoloHTTP Speed+Mobility proposto pelaMicrosoft (baseado em SPDY)[23] e oNetwork-Friendly HTTP Upgrade.[25] Em julho de 2012, oFacebook 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 umalgoritmo de compressão de cabeçalho baseado emcodificação de Huffman fixo, em vez da compressão dinâmica baseada em fluxo usada pelo SPDY. Isso ajuda a reduzir o potencial paraataques de oráculo de compressão no protocolo, como o ataqueCRIME.[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, semcriptografia) e para URIs HTTPS (sobre TLS usando a extensãoALPN[33] onde oTLS 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 criptografiade facto obrigatória.[37]
O processo de desenvolvimento do HTTP/2 e o próprio protocolo enfrentaram críticas.
O desenvolvedor doFreeBSD 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 daCisco 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 criptografiade 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 oSMTP. Os críticos afirmaram que a proposta do HTTP/2 viola oRFC 7258 da IETF, "Pervasive Monitoring Is an Attack", que também tem o status deBest 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 daRFC 8164 em maio de 2017.
Embora o projeto do HTTP/2 resolva efetivamente o problema debloqueio 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 doQUIC e doHTTP/3 foi dedicado a reduzir os problemas de bloqueio de cabeça de fila.[47][48]
HTTP/2 does not modify the application semantics of HTTP in any way
HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2
Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.
TL;DR: Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped.
