Uma vez que estamos sempre na vanguarda das novas tecnologias, certificamo-nos de que todo o site e administra\u00e7\u00e3o da Kinsta \u00e9 executado em HTTP\/2 e o nosso novo Google Cloud infrastructure supports<\/a> HTTP\/2 para todos os nossos clientes. Este amplo recurso de informa\u00e7\u00e3o explica o HTTP\/2 para usu\u00e1rios finais, desenvolvedores e empresas que buscam inova\u00e7\u00e3o. Desde informa\u00e7\u00f5es b\u00e1sicas at\u00e9 t\u00f3picos mais avan\u00e7ados, voc\u00ea aprender\u00e1 tudo o que precisa saber sobre o HTTP\/2.<\/p>\n O HTTP<\/a> foi originalmente proposto por Tim Berners-Lee<\/a>, o pioneiro da World Wide Web que projetou o protocolo aplicativo com a simplicidade em mente para realizar fun\u00e7\u00f5es de comunica\u00e7\u00e3o de dados de alto n\u00edvel entre os servidores Web e os clientes.<\/p>\n A primeira vers\u00e3o documentada do HTTP foi lan\u00e7ada em 1991 como HTTP0.9, o que mais tarde levou \u00e0 introdu\u00e7\u00e3o e reconhecimento oficial do HTTP1.0 em 1996. O HTTP1.1 foi seguido em 1997 e desde ent\u00e3o tem recebido poucas melhorias iterativas.<\/p>\n Em fevereiro de 2015, o Grupo de Trabalho HTTP da Internet Engineering Task Force (IETF<\/a>) revisou o HTTP e desenvolveu a segunda vers\u00e3o principal do protocolo aplicativo na forma do HTTP\/2. Em maio de 2015, a especifica\u00e7\u00e3o da implementa\u00e7\u00e3o do HTTP\/2 foi oficialmente padronizada em resposta ao protocolo SPDY<\/a> compat\u00edvel com HTTP do Google. O argumento HTTP\/2 vs SPDY continua ao longo de todo o guia.<\/p>\n O debate HTTP\/2 vs HTTP1 deve prosseguir com uma cartilha curta sobre o termo Protocolo frequentemente utilizado neste recurso. Um protocolo \u00e9 um conjunto de regras que governam os mecanismos de comunica\u00e7\u00e3o de dados entre clientes (por exemplo, navegadores usados pelos usu\u00e1rios da Internet para solicitar informa\u00e7\u00f5es) e servidores (as m\u00e1quinas que cont\u00eam as informa\u00e7\u00f5es solicitadas).<\/p>\n Os protocolos geralmente consistem em tr\u00eas partes principais: Cabe\u00e7alho, Carga \u00fatil e Rodap\u00e9. O cabe\u00e7alho colocado antes do Payload cont\u00e9m informa\u00e7\u00f5es como os endere\u00e7os de origem e destino, bem como outros detalhes (como tamanho e tipo) relativos ao Payload. A carga \u00fatil \u00e9 a informa\u00e7\u00e3o real transmitida usando o protocolo. O Rodap\u00e9 segue o Payload e funciona como um campo de controle para encaminhar os pedidos cliente-servidor para os destinat\u00e1rios pretendidos juntamente com o Cabe\u00e7alho para garantir que os dados de Payload sejam transmitidos sem erros.<\/p>\n O sistema \u00e9 semelhante ao servi\u00e7o de correio postal. A carta (Payload) \u00e9 inserida num envelope (Cabe\u00e7alho) com o endere\u00e7o de destino escrito nele e selado com cola e selo postal (Rodap\u00e9) antes de ser despachada. S\u00f3 que transmitir informa\u00e7\u00e3o digital sob a forma de 0s e 1s n\u00e3o \u00e9 t\u00e3o simples e requer uma nova dimens\u00e3o de inova\u00e7\u00e3o em resposta aos avan\u00e7os tecnol\u00f3gicos crescentes que surgem com o crescimento explosivo do uso da Internet.<\/p>\n Protocolo HTTP originalmente composto de comandos b\u00e1sicos: GET, para recuperar informa\u00e7\u00f5es do servidor e do POST, para entregar as informa\u00e7\u00f5es solicitadas ao cliente. Este simples e aparentemente chato conjunto de poucos comandos para GET data e POST uma resposta formou essencialmente a base para construir outros protocolos de rede tamb\u00e9m. O protocolo \u00e9 mais um passo para melhorar a experi\u00eancia e efic\u00e1cia dos utilizadores da Internet, necessitando da implementa\u00e7\u00e3o do HTTP\/2 para melhorar a presen\u00e7a online.<\/p>\n Desde a sua cria\u00e7\u00e3o, no in\u00edcio dos anos 90, o HTTP tem visto apenas algumas grandes revis\u00f5es. A vers\u00e3o mais recente, HTTP1.1 tem servido o mundo cibern\u00e9tico h\u00e1 mais de 15 anos. As p\u00e1ginas web na era atual de atualiza\u00e7\u00f5es din\u00e2micas de informa\u00e7\u00f5es, formatos de conte\u00fado multim\u00eddia com uso intensivo de recursos e inclina\u00e7\u00e3o excessiva para o desempenho web colocaram as antigas tecnologias de protocolo na categoria de legado. Estas tend\u00eancias necessitam de mudan\u00e7as significativas no HTTP\/2 para melhorar a experi\u00eancia da Internet.<\/p>\n \u00a0<\/p>\n O objetivo principal com a pesquisa e desenvolvimento de uma nova vers\u00e3o de centros HTTP em torno de tr\u00eas qualidades raramente associadas a um \u00fanico protocolo de rede sem necessidade de tecnologias de rede adicionais – simplicidade, alto desempenho e robustez. Estes objetivos s\u00e3o alcan\u00e7ados atrav\u00e9s da introdu\u00e7\u00e3o de capacidades que reduzem a lat\u00eancia no processamento de pedidos de browser com t\u00e9cnicas como multiplexagem, compress\u00e3o, prioriza\u00e7\u00e3o de pedidos e push de servidor.<\/p>\n Mecanismos como controle de fluxo, atualiza\u00e7\u00e3o e tratamento de erros funcionam como aprimoramentos do protocolo HTTP para que os desenvolvedores garantam alto desempenho e resili\u00eancia das aplica\u00e7\u00f5es baseadas na web.<\/p>\n O sistema coletivo permite que os servidores respondam eficientemente com mais conte\u00fado do que o originalmente solicitado pelos clientes, eliminando a interven\u00e7\u00e3o do usu\u00e1rio para solicitar informa\u00e7\u00f5es continuamente at\u00e9 que o site seja totalmente carregado no navegador da web. Por exemplo, a capacidade do Server Push com HTTP\/2 permite que os servidores respondam com o conte\u00fado completo de uma p\u00e1gina, al\u00e9m das informa\u00e7\u00f5es j\u00e1 dispon\u00edveis no cache do navegador. A compress\u00e3o eficiente de arquivos de cabe\u00e7alho HTTP minimiza a sobrecarga do protocolo para melhorar o desempenho com cada solicita\u00e7\u00e3o do navegador e resposta do servidor.<\/p>\n As altera\u00e7\u00f5es ao HTTP\/2 s\u00e3o projetadas para manter a interoperabilidade e compatibilidade com o HTTP1.1. Espera-se que as vantagens do HTTP\/2 aumentem ao longo do tempo com base em experimentos no mundo real e sua capacidade de abordar quest\u00f5es relacionadas ao desempenho em compara\u00e7\u00e3o com o HTTP1.1 ter\u00e1 grande impacto em sua evolu\u00e7\u00e3o a longo prazo.<\/p>\n “…n\u00f3s n\u00e3o estamos substituindo todo o HTTP – os m\u00e9todos, c\u00f3digos de status e a maioria dos cabe\u00e7alhos que voc\u00ea usa hoje ser\u00e3o os mesmos. Em vez disso, estamos a redefinir como se usa “no fio” para ser mais eficiente, e para que seja mais suave para a pr\u00f3pria Internet”… Mark Nottingham<\/a>, presidente do Grupo de Trabalho HTTP da IETF e membro do TAG do W3C.\u00a0 Fonte<\/a><\/p><\/blockquote>\n \u00c9 importante notar que a nova vers\u00e3o HTTP vem como uma extens\u00e3o da sua antecessora e n\u00e3o se espera que substitua o HTTP1.1 em breve. A implementa\u00e7\u00e3o do HTTP\/2 n\u00e3o permitir\u00e1 suporte autom\u00e1tico para todos os tipos de criptografia dispon\u00edveis com HTTP1.1, mas definitivamente abre a porta para melhores alternativas ou atualiza\u00e7\u00f5es adicionais de compatibilidade de criptografia em um futuro pr\u00f3ximo. Contudo, compara\u00e7\u00f5es de recursos como HTTP\/2 vs HTTP1 e SPDY vs HTTP\/2 apresentam apenas o mais recente protocolo de aplica\u00e7\u00e3o como o vencedor em termos de desempenho, seguran\u00e7a e confiabilidade.<\/p>\n O HTTP1.1 foi limitado ao processamento de apenas uma solicita\u00e7\u00e3o pendente por conex\u00e3o TCP, for\u00e7ando os navegadores a usar m\u00faltiplas conex\u00f5es TCP para processar v\u00e1rias solicita\u00e7\u00f5es simultaneamente.<\/p>\n Entretanto, o uso de muitas conex\u00f5es TCP em paralelo leva a um congestionamento TCP que causa uma monopoliza\u00e7\u00e3o injusta dos recursos da rede. Os navegadores Web que utilizam m\u00faltiplas conex\u00f5es para processar solicita\u00e7\u00f5es adicionais ocupam uma parcela maior dos recursos de rede dispon\u00edveis, o que faz com que o desempenho da rede seja inferior ao de outros usu\u00e1rios.<\/p>\n A emiss\u00e3o de v\u00e1rios pedidos do navegador tamb\u00e9m causa duplica\u00e7\u00e3o de dados nos fios de transmiss\u00e3o de dados, o que, por sua vez, requer protocolos adicionais para extrair a informa\u00e7\u00e3o desejada livre de erros nos n\u00f3s finais.<\/p>\n A ind\u00fastria da internet foi naturalmente for\u00e7ada a invadir estas restri\u00e7\u00f5es com pr\u00e1ticas como a fragmenta\u00e7\u00e3o de dom\u00ednios, concatena\u00e7\u00e3o, inlining de dados e spriting, entre outras. O uso ineficaz das conex\u00f5es TCP subjacentes com HTTP1.1 tamb\u00e9m leva a uma m\u00e1 prioriza\u00e7\u00e3o de recursos, causando degrada\u00e7\u00e3o exponencial do desempenho \u00e0 medida que as aplica\u00e7\u00f5es web crescem em termos de complexidade, funcionalidade e escopo.<\/p>\n A web evoluiu muito al\u00e9m da capacidade das tecnologias de rede baseadas em HTTP legadas. As qualidades essenciais do HTTP1.1 desenvolvidas h\u00e1 mais de uma d\u00e9cada abriram as portas para v\u00e1rias falhas embara\u00e7osas de desempenho e seguran\u00e7a.<\/p>\n O Cookie Hack, por exemplo, permite que os criminosos virtuais reutilizem uma sess\u00e3o de trabalho anterior para comprometer as senhas de contas, pois o HTTP1.1 n\u00e3o oferece facilidades de identifica\u00e7\u00e3o do ponto final da sess\u00e3o. Enquanto as preocupa\u00e7\u00f5es de seguran\u00e7a similares continuar\u00e3o a assombrar o HTTP\/2, o novo protocolo aplicativo foi projetado com melhores capacidades de seguran\u00e7a, como a melhor implementa\u00e7\u00e3o de novos TLS features<\/a>.<\/p>\n A sequ\u00eancia bidirecional de frames de formato de texto enviados atrav\u00e9s do protocolo HTTP\/2 trocados entre o servidor e o cliente s\u00e3o conhecidos como “streams”. As itera\u00e7\u00f5es anteriores do protocolo HTTP eram capazes de transmitir apenas um fluxo de cada vez, juntamente com algum atraso entre cada transmiss\u00e3o de fluxo.<\/p>\n Receber toneladas de conte\u00fado de m\u00eddia atrav\u00e9s de fluxos individuais enviados um a um \u00e9 ineficiente e consome recursos. As altera\u00e7\u00f5es do HTTP\/2 ajudaram a estabelecer uma nova camada de enquadramento bin\u00e1rio para responder a estas preocupa\u00e7\u00f5es.<\/p>\n Esta camada permite ao cliente e ao servidor desintegrar a carga \u00fatil do HTTP em sequ\u00eancia de frames pequenos, independentes e manej\u00e1veis entre si. Esta informa\u00e7\u00e3o \u00e9 ent\u00e3o remontada no outro extremo.<\/p>\n Os formatos de quadros bin\u00e1rios permitem a troca de m\u00faltiplas sequ\u00eancias bi-direcionais, simultaneamente abertas e independentes, sem lat\u00eancia entre fluxos sucessivos. Esta abordagem apresenta um conjunto de benef\u00edcios do HTTP\/2 explicado abaixo:<\/p>\n Com esta capacidade, os pacotes de dados de v\u00e1rios fluxos s\u00e3o essencialmente mistos e transmitidos atrav\u00e9s de uma \u00fanica liga\u00e7\u00e3o TCP. Estes pacotes s\u00e3o ent\u00e3o divididos na extremidade receptora e apresentados como fluxos de dados individuais. A transmiss\u00e3o de v\u00e1rias solicita\u00e7\u00f5es paralelas simultaneamente usando HTTP vers\u00e3o 1.1 ou anterior exigia m\u00faltiplas conex\u00f5es TCP, o que inerentemente estrangula o desempenho geral da rede, apesar de transmitir mais fluxos de dados a taxas mais r\u00e1pidas.<\/p>\n\n Esta capacidade permite que o servidor envie ao cliente informa\u00e7\u00f5es adicionais em cache que n\u00e3o s\u00e3o solicitadas, mas que s\u00e3o antecipadas em pedidos futuros. Por exemplo, se o cliente solicitar o recurso X e for entendido que o recurso Y \u00e9 referenciado com o arquivo solicitado, o servidor pode optar por empurrar Y junto com X em vez de esperar por um pedido de cliente apropriado.<\/p>\n O cliente coloca o recurso Y empurrado para o seu cache para uso futuro. Este mecanismo poupa uma viagem de ida e volta correspondente a um pedido e reduz a lat\u00eancia da rede. O Server Push foi originalmente introduzido no protocolo SPDY do Google. Os identificadores de fluxo contendo pseudo cabe\u00e7alhos como :path permitem ao servidor iniciar o Push para informa\u00e7\u00f5es que devem ser armazen\u00e1veis. O cliente deve permitir explicitamente que o servidor Empurre recursos em cache com HTTP\/2 ou termine fluxos empurrados com um identificador de fluxo espec\u00edfico.<\/p>\n Outras altera\u00e7\u00f5es do HTTP\/2 como o Server Push atualiza ou invalida proativamente o cache do cliente e tamb\u00e9m \u00e9 conhecido como “Cache Push”. As consequ\u00eancias a longo prazo centram-se na capacidade dos servidores para identificar poss\u00edveis recursos que o cliente realmente n\u00e3o quer.<\/p>\n A implementa\u00e7\u00e3o do HTTP\/2 apresenta um desempenho significativo para recursos empurrados, com outros benef\u00edcios do HTTP\/2 explicados abaixo:<\/p>\n Recursos Push similares j\u00e1 est\u00e3o dispon\u00edveis com t\u00e9cnicas sub-\u00f3timas como Inlining to Push server responses, enquanto o Server Push apresenta uma solu\u00e7\u00e3o em n\u00edvel de protocolo para evitar complexidades com hacks de otimiza\u00e7\u00e3o secund\u00e1rios \u00e0s capacidades de base do pr\u00f3prio protocolo da aplica\u00e7\u00e3o.<\/p>\n O HTTP\/2 multiplexa e prioriza o fluxo de dados empurrado para garantir um melhor desempenho de transmiss\u00e3o, como visto com outros fluxos de dados de resposta a solicita\u00e7\u00f5es. Como mecanismo de seguran\u00e7a integrado, o servidor deve ser autorizado a Empurrar os recursos de antem\u00e3o.<\/p>\n A \u00faltima vers\u00e3o HTTP evoluiu significativamente em termos de capacidades, e atributos como a transforma\u00e7\u00e3o de um protocolo de texto para um protocolo bin\u00e1rio. HTTP1.x usado para processar comandos de texto para completar ciclos de resposta de solicita\u00e7\u00f5es. HTTP\/2 utilizar\u00e1 comandos bin\u00e1rios (em 1s e 0s) para executar as mesmas tarefas. Este atributo facilita as complica\u00e7\u00f5es com o enquadramento e simplifica a implementa\u00e7\u00e3o de comandos que foram misturados de forma confusa devido a comandos contendo texto e espa\u00e7os opcionais.<\/p>\n Embora provavelmente seja necess\u00e1rio mais esfor\u00e7os para ler comandos bin\u00e1rios em compara\u00e7\u00e3o com comandos de texto, \u00e9 mais f\u00e1cil para a rede gerar e analisar frames dispon\u00edveis em bin\u00e1rio. A sem\u00e2ntica real permanece inalterada.<\/p>\n Os navegadores que utilizam a implementa\u00e7\u00e3o do HTTP\/2 converter\u00e3o os mesmos comandos de texto em bin\u00e1rio antes de transmiti-lo pela rede. A camada de enquadramento bin\u00e1rio n\u00e3o \u00e9 retrocompat\u00edvel com clientes e servidores HTTP1.x e um facilitador chave para benef\u00edcios significativos de desempenho sobre SPDY e HTTP1.x. Usando comandos bin\u00e1rios para permitir vantagens comerciais chave para empresas de Internet e neg\u00f3cios on-line como detalhado com os benef\u00edcios do HTTP\/2 explicado abaixo:<\/p>\n A implementa\u00e7\u00e3o do HTTP\/2 permite que o cliente d\u00ea prefer\u00eancia a determinados fluxos de dados. Embora o servidor n\u00e3o seja obrigado a seguir estas instru\u00e7\u00f5es do cliente, o mecanismo permite ao servidor otimizar a aloca\u00e7\u00e3o de recursos da rede com base nos requisitos do usu\u00e1rio final.<\/p>\n A prioriza\u00e7\u00e3o do fluxo funciona com Depend\u00eancias e Peso atribu\u00eddos a cada fluxo. Embora todos os fluxos sejam intrinsecamente dependentes uns dos outros, com excep\u00e7\u00e3o dos fluxos dependentes, tamb\u00e9m s\u00e3o atribu\u00eddos pesos entre 1 e 256. Os detalhes dos mecanismos de prioriza\u00e7\u00e3o de fluxo ainda s\u00e3o debatidos.<\/p>\n No mundo real, por\u00e9m, o servidor raramente tem controle sobre recursos como CPU e conex\u00f5es de banco de dados. A pr\u00f3pria complexidade da implementa\u00e7\u00e3o impede que os servidores acomodem os pedidos priorit\u00e1rios do fluxo. A investiga\u00e7\u00e3o e desenvolvimento nesta \u00e1rea \u00e9 particularmente importante para o sucesso a longo prazo do HTTP\/2, uma vez que o protocolo \u00e9 capaz de processar m\u00faltiplos fluxos de dados com uma \u00fanica liga\u00e7\u00e3o TCP.<\/p>\n Esta capacidade pode levar \u00e0 chegada simult\u00e2nea de pedidos de servidor que realmente diferem em termos de prioridade do ponto de vista do usu\u00e1rio final. A reten\u00e7\u00e3o de pedidos de processamento de fluxo de dados de forma aleat\u00f3ria mina a efici\u00eancia e a experi\u00eancia do usu\u00e1rio final prometida pelas mudan\u00e7as do HTTP\/2. Ao mesmo tempo, um mecanismo de prioriza\u00e7\u00e3o de fluxo inteligente e amplamente adotado apresenta os benef\u00edcios do HTTP\/2 explicados a seguir:<\/p>\n Proporcionar experi\u00eancia de usu\u00e1rio de alta qualidade na web requer sites ricos em conte\u00fado e gr\u00e1ficos. O protocolo de aplica\u00e7\u00e3o HTTP \u00e9 state-less, o que significa que cada pedido de cliente deve incluir tanta informa\u00e7\u00e3o quanto o servidor necessita para realizar a opera\u00e7\u00e3o desejada. Este mecanismo faz com que os fluxos de dados carreguem m\u00faltiplos quadros repetitivos de informa\u00e7\u00e3o, de tal forma que o pr\u00f3prio servidor n\u00e3o tem que armazenar informa\u00e7\u00f5es de pedidos anteriores do cliente.<\/p>\n No caso de sites que servem conte\u00fados ricos em m\u00eddia, os clientes empurram v\u00e1rios cabe\u00e7alhos quase id\u00eanticos levando \u00e0 lat\u00eancia e ao consumo desnecess\u00e1rio de recursos de rede limitados. Uma mistura priorit\u00e1ria de fluxos de dados n\u00e3o pode alcan\u00e7ar os padr\u00f5es de desempenho desejados de paralelismo sem otimizar este mecanismo.<\/p>\n A implementa\u00e7\u00e3o do HTTP\/2 atende a essas preocupa\u00e7\u00f5es com a capacidade de comprimir um grande n\u00famero de quadros de cabe\u00e7alho redundantes. Ele usa a especifica\u00e7\u00e3o HPACK como uma abordagem simples e segura para a compress\u00e3o de cabe\u00e7otes. Tanto o cliente como o servidor mant\u00eam uma lista de cabe\u00e7alhos utilizados em solicita\u00e7\u00f5es cliente-servidor anteriores.<\/p>\n HPACK comprime o valor individual de cada cabe\u00e7alho antes de ser transferido para o servidor, que ent\u00e3o procura as informa\u00e7\u00f5es codificadas na lista de valores de cabe\u00e7alho previamente transferidos para reconstruir as informa\u00e7\u00f5es completas do cabe\u00e7alho. A compress\u00e3o de cabe\u00e7alho HPACK para implementa\u00e7\u00e3o do HTTP\/2 apresenta imensas vantagens de desempenho, incluindo alguns benef\u00edcios do HTTP\/2 explicados abaixo:<\/p>\n A sem\u00e2ntica subjacente da aplica\u00e7\u00e3o HTTP, incluindo c\u00f3digos de status HTTP, URIs, metodologias e arquivos de cabe\u00e7alho permanecem os mesmos na \u00faltima itera\u00e7\u00e3o do HTTP\/2. O HTTP\/2 \u00e9 baseado no SPDY, a alternativa do Google ao HTTP1.x. As verdadeiras diferen\u00e7as residem nos mecanismos utilizados para processar as solicita\u00e7\u00f5es cliente-servidor. O gr\u00e1fico seguinte identifica algumas \u00e1reas de semelhan\u00e7as e melhorias entre HTTP1.x, SPDY e HTTP\/2:<\/p>\nEste Guia destaca os seguintes aspectos-chave do HTTP\/2:<\/h3>\n
\n
<\/a>O que \u00e9 HTTP\/2?<\/h2>\n
![\"Linha](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-timeline.png\")
O que \u00e9 um Protocolo?<\/h3>\n
![\"Correio](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mail-http2.png\")
<\/a>Objetivo de Criar HTTP\/2<\/h2>\n
![\"Experi\u00eancia](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/website-basic.png\" "\\"Internet")
![\"Encripta\u00e7\u00e3o](\"https:\/\/kinsta.com\/wp-content\/themes\/kinsta\/images\/learn\/what-is-http2\/encryption.png\" "\\"HTTP\/2")
<\/a>O que estava errado com o HTTP1.1?<\/h2>\n
![\"Solicita\u00e7\u00f5es](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http-requests.png\")
![\"Desmembramento](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-domain-sharding.png\" "\\"HTTP\/2")
<\/a>Atualiza\u00e7\u00f5es de caracter\u00edsticas do HTTP\/2<\/h2>\n
Fluxos multiplexados<\/h3>\n
![\"Flux](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-streams.png\")
\n
Push do Servidor HTTP\/2<\/h3>\n
![\"Push](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-push.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-authorized.png\")
Protocolos Bin\u00e1rios<\/h3>\n
![\"Protocolos](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/binary-protocols-2.png\")
\n
Prioriza\u00e7\u00e3o do fluxo<\/h3>\n
![\"Peso](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-weight.png\")
\n
![\"Carga](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-page-load.png\")
Compress\u00e3o de Cabe\u00e7alho Estatal<\/h3>\n
![\"Compress\u00e3o](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-hpack-compression.png\")
\n
<\/a>Semelhan\u00e7as com HTTP1.x e SPDY<\/h2>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-https.png\")
![\"Encripta\u00e7\u00e3o](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-encryption.png\")
![\"Velocidade](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-speed.jpg\")
![\"Melhorias](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-performance-improvements.jpg\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2_mobile.png\")
![\"Queda](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/internet-price-drop.png\")
![\"Mapa](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/bandwidth-map.png\")
![\"Primeiro](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/mobile-first.png\")
![\"Seguran\u00e7a](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-security.png\")
![\"Vantagens](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-seo-advantages.png\")
![\"Compara\u00e7\u00e3o](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-comparison.png\")
![\"Suporte](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-browser-support.png\")
![\"Suporte](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-nginx-apache-support.png\")
![\"Adicione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2015\/04\/add-lets-encrypt-certificate.png\" "\\"Add")