HTTP/2
Este artigo resulta, no todo ou em parte, de uma tradução do artigo «HTTP/2» na Wikipédia em inglês, na versão original. |
HTTP/2 | |
---|---|
Padrão internacional | RFC 7540 |
Desenvolvido por | IETF |
Introduzido | 14 de maio de 2015 |
HTTP/2 (originalmente chamado HTTP/2.0) é uma revisão importante do protocolo de rede HTTP usado pela World Wide Web. Foi derivado do protocolo experimental anterior SPDY, originalmente desenvolvido pelo Google.[1][2] O HTTP/2 foi desenvolvido pelo HTTP Working Group (também chamado httpbis, onde "bis" significa "segundo") do Internet Engineering Task Force.[3][4][5] O HTTP/2 é a primeira nova versão do HTTP desde o HTTP 1.1, padronizada na RFC 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 como RFC 7540 em 14 de maio de 2015.[8]
O esforço de padronização foi suportado pelos navegadores Chrome[9], Opera, Firefox,[10] Internet Explorer 11, Safari, Amazon Silk e Edge.[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 é o HTTP/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 ao Chrome (compilação Canary) em setembro de 2019 (e o Cloudflare 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]
Objetivos
[editar | editar código-fonte]![](https://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Http2-explained-en.pdf/page1-220px-Http2-explained-en.pdf.jpg)
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.
Diferenças do HTTP 1.1
[editar | editar código-fonte]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]
Gênese e diferenças posteriores ao SPDY
[editar | editar código-fonte]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]
Encriptação
[editar | editar código-fonte]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]
Críticas
[editar | editar código-fonte]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.
Encriptação
[editar | editar código-fonte]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.
Bloqueio de cabeça de fila no TCP
[editar | editar código-fonte]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]
Ver também
[editar | editar código-fonte]Referências
- ↑ Bright, Peter (18 de fevereiro de 2015). «HTTP/2 finished, coming to browsers within weeks». Ars Technica
- ↑ a b Cimpanu, Catalin. «HTTP-over-QUIC to be renamed HTTP/3 | ZDNet». ZDNet. Consultado em 2 de maio de 2020
- ↑ Thomson, M. (ed.), Belshe M. and R. Peon. «Hypertext Transfer Protocol version 2: draft-ietf-httpbis-http2-16». ietf.org. HTTPbis Working Group. Consultado em 2 de maio de 2020
- ↑ a b «Hypertext Transfer Protocol Bis (httpbis)». Internet Engineering Task Force. 2012
- ↑ «IETF HTTP Working Group». IETF HTTP Working Group. Consultado em 2 de maio de 2020
- ↑ Raymor, Brian (6 de agosto de 2014). «Wait for it – HTTP/2 begins Working Group Last Call!». Microsoft Open Technologies. Consultado em 2 de maio de 2020. Cópia arquivada em 6 de outubro de 2014
- ↑ Mark Nottingham (18 de fevereiro de 2015). «HTTP/2 Approved». ietf.org. Internet Engineering Task Force. Consultado em 2 de maio de 2020
- ↑ «RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)». IETF. 14 de maio de 2015. Consultado em 2 de maio de 2020
- ↑ a b Emerson Alecrim (10 de fevereiro de 2015). «Google anuncia suporte ao HTTP/2 no Chrome». Tecnoblog. Consultado em 23 de maio de 2020
- ↑ «See what's new in Firefox!». www.mozilla.org. Mozilla Foundation. 24 de fevereiro de 2015
- ↑ «Can the rise of SPDY threaten HTTP?». blog.restlet.com. Restlet, Inc. 6 de outubro de 2011. Consultado em 2 de maio de 2020. Arquivado do original em 6 de janeiro de 2014
- ↑ «HTTP2 browser support». Consultado em 2 de maio de 2020
- ↑ «Usage of HTTP/2 for websites». World Wide Web Technology Surveys. W3Techs. Consultado em 2 de maio de 2020
- ↑ Bishop, Mike (9 de julho de 2019). «Hypertext Transfer Protocol Version 3 (HTTP/3)». tools.ietf.org. Consultado em 2 de maio de 2020
- ↑ «Can I use... Support tables for HTML5, CSS3, etc». caniuse.com. Consultado em 2 de maio de 2020
- ↑ Stenberg, Daniel. «Daniel Stenberg announces HTTP/3 support in Firefox Nightly». Twitter. Consultado em 2 de maio de 2020
- ↑ Cimpanu, Catalin (26 de setembro de 2019). «Cloudflare, Google Chrome, and Firefox add HTTP/3 support». ZDNet. Consultado em 2 de maio de 2020
- ↑ a b Ilya Grigorik. «Chapter 12: HTTP 2.0». High Performance Browser Networking. [S.l.]: O'Reilly Media, Inc.
HTTP/2 does not modify the application semantics of HTTP in any way
- ↑ Pratt, Michael. «Apiux». apiux.com. Consultado em 22 de maio de 2020
- ↑ Dio Synodinos (Novembro de 2012). «HTTP 2.0 First Draft Published». InfoQ.com. C4Media Inc.
- ↑ Javier Garza (Outubro de 2017). «How does HTTP/2 solve the Head of Line blocking (HOL) issue»
- ↑ Belshe, Mike; Thomson, Martin; Peon, Roberto (Maio de 2015). «Hypertext Transfer Protocol Version 2 (HTTP/2)». tools.ietf.org (em inglês). Consultado em 22 de maio de 2020.
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
- ↑ a b Sebastian Anthony (28 de março de 2012). «S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0». ExtremeTech
- ↑ a b Grigorik, Ilya. «Life beyond HTTP 1.1: Google's SPDY»
- ↑ Willy Tarreau; Amos Jeffries; Adrien de Croy; Poul-Henning Kamp (29 de março de 2012). «Proposal for a Network-Friendly HTTP Upgrade». Network Working Group. Internet Engineering Task Force
- ↑ Doug Beaver (15 de julho de 2012). «HTTP2 Expression of Interest». W3C
- ↑ Dio Synodinos (30 de novembro de 2012). «HTTP/2 First Draft Published». InfoQ
- ↑ a b Grigorik, Ilya (2015). HTTP/2 : a new excerpt from high performance browser networking 1ª ed. Sebastopol, Calif.: O'Reilly Media. pp. 211–224. ISBN 9781491932483. OCLC 1039459460
- ↑ «SPDY: An experimental protocol for a faster web». The Chromium Projects
- ↑ Chris Bentzel; Bence Béky (9 de fevereiro de 2015). «Hello HTTP/2, Goodbye SPDY». Chromium Blog.
Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.
- ↑ «API Deprecations and Removals in Chrome 51».
TL;DR: Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped.
- ↑ Shadrin, Nick (7 de junho de 2016). «Supporting HTTP/2 for Google Chrome Users | NGINX». NGINX. Consultado em 23 de maio de 2020
- ↑ «RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension». IETF. Julho de 2014
- ↑ Belshe, M.; Peon, R.; Thomson, M. «Hypertext Transfer Protocol Version 2, Use of TLS Features». Consultado em 22 de maio de 2020
- ↑ a b «HTTP/2 Frequently Asked Questions». IETF HTTP Working Group. Consultado em 22 de maio de 2020
- ↑ «Networking/http2». MozillaWiki. Consultado em 22 de maio de 2020
- ↑ «HTTP/2 Implementation Status». mnot’s blog
- ↑ a b c d Kamp, Poul-Henning (6 de janeiro de 2015). «HTTP/2.0 – The IETF is Phoning It In (Bad protocol, bad politics)». ACM Queue
- ↑ Grigorik, Ilya. «Is TLS Fast Yet?». Consultado em 24 de maio de 2020
- ↑ Kamp, P. H. (2015). «Http/2.0». Communications of the ACM. 58 (3): 40. doi:10.1145/2717515
- ↑ Kamp, Poul-Henning (7 de janeiro de 2015). «Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard». [email protected] (Lista de grupo de correio). Consultado em 24 de maio de 2020
- ↑ Lear, Eliot (25 de agosto de 2013). «Mandatory encryption *is* theater». [email protected] (Lista de grupo de correio). Consultado em 24 de maio de 2020
- ↑ Murenin, Constantine A. (9 de janeiro de 2015). «Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard». [email protected] (Lista de grupo de correio). Consultado em 24 de maio de 2020
- ↑ Paul Hoffman. «Minimal Unauthenticated Encryption (MUE) for HTTP-2: draft-hoffman-httpbis-minimal-unauth-enc-01». Internet Engineering Task Force
- ↑ Mark Nottingham; Martin Thomson. «Opportunistic Encryption for HTTP URIs: draft-nottingham-http2-encryption-03». Internet Engineering Task Force
- ↑ Mark Nottingham; Martin Thomson. «Opportunistic Security for HTTP: draft-ietf-httpbis-http2-encryption-01». Internet Engineering Task Force
- ↑ Huston, Geoff (4 de março de 2019). «A Quick Look at QUIC». www.circleid.com (em inglês). Consultado em 24 de maio de 2020
- ↑ Gal, Shauli (22 de junho de 2017). «The Full Picture on HTTP/2 and HOL Blocking». Medium (em inglês). Consultado em 24 de maio de 2020
Ligações externas
[editar | editar código-fonte]- Sítio oficial
- RFC 7540 – Hypertext Transfer Protocol version 2 (HTTP/2)