Para mais informações sobre HTTP/2, assista à gravação do nosso popular webinar, O que há de novo em HTTP/2?
O venerável padrão HyperText Transfer Protocol, ou HTTP , foi atualizado. O padrão HTTP/2 foi aprovado em maio de 2015 e agora está sendo implementado em navegadores e servidores web (incluindo NGINX Plus e NGINX Open Source ). Atualmente, o HTTP/2 é suportado por quase dois terços de todos os navegadores da web em uso, e a proporção cresce vários pontos percentuais por mês.
O HTTP/2 é baseado no protocolo SPDY do Google, e o SPDY ainda é uma opção até que o suporte a ele no navegador Chrome do Google termine no início de 2016 . O NGINX foi um pioneiro no suporte ao SPDY e agora desempenha o mesmo papel com o HTTP/2. Nosso abrangente white paper, HTTP/2 para desenvolvedores de aplicativos da Web (PDF), descreve o HTTP/2, mostra como ele se baseia no SPDY e explica como implementá-lo.
Os principais recursos do HTTP/2 são os mesmos do SPDY:
Agora você precisa decidir se deseja prosseguir com o HTTP/2 – e parte disso é saber como tirar o máximo proveito dele. Esta postagem do blog guiará você pelos aspectos relacionados ao desempenho do processo de tomada de decisão e implementação. Confira estas 7 dicas para desempenho do HTTP/2:
Observação : Nem SPDY nem HTTP/2 exigem TLS, estritamente falando, mas ambos são benéficos principalmente quando usados com SSL/TLS, e os navegadores só oferecem suporte a SPDY ou HTTP/2 quando SSL/TLS está em uso.
Implementar HTTP/2 é fácil, como discutimos em nosso white paper, HTTP/2 para desenvolvedores de aplicativos da Web (PDF). No entanto, o HTTP/2 não é uma solução mágica; ele é útil para alguns aplicativos web, mas nem tanto para outros.
Usar HTTP/2 provavelmente melhorará o desempenho do site se você estiver usando SSL/TLS (chamado de TLS daqui em diante). Mas se você não tiver feito isso, precisará adicionar suporte a TLS antes de poder usar HTTP/2. Nesse caso, espere que a perda de desempenho pelo uso de TLS seja compensada aproximadamente pelo benefício de desempenho pelo uso de HTTP/2, mas teste se isso é realmente verdade para seu site antes de tomar uma decisão de implementação.
Aqui estão cinco principais benefícios potenciais do HTTP/2:
E aqui estão cinco desvantagens correspondentes que você encontrará:
Tudo se resume ao desempenho – e nesse aspecto, temos boas e más notícias.
A boa notícia é que um teste interno inicial que realizamos aqui na NGINX mostra o resultado que a teoria preveria: para páginas da web de conteúdo misto solicitadas por conexões com latências típicas da Internet, o HTTP/2 tem melhor desempenho do que o HTTP/1.x e o HTTPS. Os resultados são divididos em três grupos, dependendo do tempo típico de ida e volta (RTT) da conexão:
A figura mostra o tempo até a primeira pintura – ou seja, o tempo até que o usuário veja pela primeira vez o conteúdo da página da Web aparecer na tela. Essa medição é frequentemente considerada crítica para a percepção dos usuários sobre a capacidade de resposta de um site.
Para detalhes sobre nossos testes, assista à minha apresentação no nginx.conf 2015, O módulo HTTP/2 no NGINX .
No entanto, cada página da web é diferente e, de fato, cada sessão de usuário é diferente. Se você tiver mídia de streaming ou arquivos grandes para download, ou se você tiver explorado ao máximo suas otimizações HTTP/1.x (com desculpas ao Perdido em Marte ), seus resultados podem ser diferentes, ou até mesmo opostos.
O ponto principal é: você pode achar que a relação custo-benefício não é clara. Se sim, aprenda o máximo que puder, faça testes de desempenho em seu próprio conteúdo e depois tome uma decisão. (Para orientação, assista ao nosso webinar, O que há de novo no HTTP/2? .)
Encerrar um protocolo significa que os clientes se conectam a um servidor proxy usando um protocolo desejado, como TLS ou HTTP/2. O servidor proxy então se conecta a servidores de aplicativos, servidores de banco de dados e assim por diante, sem necessariamente usar o mesmo protocolo, conforme mostrado na figura.
Usar um servidor separado para terminação significa mudar para uma arquitetura multisservidor. Os servidores podem ser servidores físicos separados, servidores virtuais ou instâncias de servidores virtuais em um ambiente de nuvem, como a AWS . Isso representa um aumento na complexidade em comparação a um único servidor ou mesmo a uma combinação de servidor de aplicativos/servidor de banco de dados. Mas ele oferece muitos benefícios e é praticamente – sem trocadilhos – uma necessidade para sites movimentados.
Quando um servidor ou servidor virtual é colocado na frente de uma configuração existente, muitas coisas são possíveis. O novo servidor transfere a tarefa de comunicação com o cliente dos outros servidores e pode ser usado para balanceamento de carga, armazenamento em cache de arquivos estáticos e outros propósitos. Fica fácil adicionar e substituir servidores de aplicativos e outros servidores conforme necessário.
NGINX e NGINX Plus são frequentemente usados para todos esses propósitos: encerrar TLS e HTTP/2, balanceamento de carga e muito mais. O ambiente existente não precisa ser alterado em nada, exceto para "frontendizá-lo" com o servidor NGINX.
Editor – Desde a publicação deste post no blog, o SPDY chegou ao fim do suporte dos principais navegadores. Começar com SPDY não é mais uma opção para implantação generalizada.
SPDY é o protocolo predecessor do HTTP/2 e seu desempenho geral é praticamente o mesmo. Como ele já existe há vários anos, mais navegadores da web oferecem suporte ao SPDY do que ao HTTP/2 . No entanto, no momento em que este artigo foi escrito, a lacuna estava diminuindo; cerca de dois terços dos navegadores da web oferecem suporte a HTTP/2, enquanto cerca de quatro em cada cinco oferecem suporte a SPDY.
Se você tem pressa em implementar o novo estilo de protocolo de transporte da Web e deseja oferecer suporte ao maior número possível de usuários hoje, pode começar oferecendo o SPDY. Então, no início de 2016, quando o suporte SPDY começar a ser removido, você poderá mudar para HTTP/2 – uma mudança rápida, pelo menos com NGINX. Nesse ponto, mais usuários estarão em navegadores que suportam HTTP/2, então você terá feito a melhor coisa para o maior número de seus usuários durante essa transição.
Antes de decidir implementar o HTTP/2, você precisa identificar quanto da sua base de código é otimizada para HTTP/1.x. Há quatro tipos de otimizações a serem observados:
Os três últimos tipos de otimizações combinam arquivos pequenos em arquivos maiores para reduzir novas conexões e handshake de inicialização, o que é especialmente caro para TLS.
A primeira otimização, fragmentação de domínio, faz o oposto – força a abertura de mais conexões ao envolver domínios adicionais na imagem. Juntas, essas técnicas aparentemente contraditórias podem ser bastante eficazes para aumentar o desempenho de sites HTTP/1.x. No entanto, todos eles exigem tempo, esforço e recursos para serem projetados, implementados, gerenciados e executados.
Antes de implementar o HTTP/2, identifique onde essas otimizações existem e como elas estão afetando atualmente o design do aplicativo e o fluxo de trabalho na sua organização, para que você possa modificá-las ou desfazê-las após a mudança para o HTTP/2.
Na verdade, implantar HTTP/2 ou SPDY não é tão difícil. Se você for um usuário do NGINX, basta “ativar” o protocolo na sua configuração do NGINX, conforme detalhamos para HTTP/2 em nosso white paper, HTTP/2 para desenvolvedores de aplicativos da Web (PDF). O navegador e o servidor negociarão para escolher um protocolo, escolhendo HTTP/2 se o navegador também o suportar (e se o TLS estiver em uso).
Depois de implementar o HTTP/2 no nível do servidor, as sessões dos usuários em versões de navegador que suportam HTTP/2 com seu aplicativo web serão executadas em HTTP/2. Usuários em versões mais antigas do navegador terão suas sessões executadas em HTTP/1.x, conforme mostrado na figura. Se e quando você implementar HTTP/2 ou SPDY para um site movimentado, você vai querer ter processos em vigor para medir o desempenho antes e depois, e reverter a mudança se ela tiver impactos negativos significativos.
Observação : Com o HTTP/2 e seu uso de uma única conexão, alguns detalhes da configuração do NGINX se tornam mais importantes. Revise sua configuração do NGINX, com atenção especial ao ajuste e teste das configurações de diretivas como output_buffers
, proxy_buffers
e ssl_buffer_size
. Para obter instruções gerais de configuração, consulte Terminação NGINX SSL/TLS no Guia de administração do NGINX Plus. Você pode obter dicas mais específicas em nossos blogs SSL Offloading, Encryption, and Certificates with NGINX e How to Improve SEO with HTTPS and NGINX . Nosso white paper, NGINX SSL Performance , explora como a escolha do tamanho da chave do servidor, acordo do servidor e cifra em massa afeta o desempenho.
Observação : O uso de cifras que você usa com HTTP/2 pode exigir atenção extra. O RFC para HTTP/2 tem uma longa lista de conjuntos de cifras a serem evitados , e você pode preferir configurar a lista de cifras você mesmo. No NGINX e no NGINX Plus, considere ajustar a diretiva ssl_ciphers
e habilitar ssl_prefer_server_ciphers
e testar a configuração com versões populares de navegadores. O Teste de Servidor SSL Qualys analisa a configuração de servidores web SSL, mas (desde novembro de 2015) não é confiável para handshakes HTTP/2 .
Surpreendentemente, desfazer ou revisar suas otimizações HTTP/1.x é, na verdade, a parte mais criativa de uma implementação HTTP/2. Há várias questões a serem consideradas e muitos graus de liberdade quanto ao que fazer.
Antes de começar a fazer alterações, considere se os usuários de navegadores mais antigos sofrerão com elas. Com isso em mente, existem três estratégias amplas para desfazer ou revisar otimizações HTTP/1.x:
O cache é um pouco imprevisível. Teoricamente, o cache funciona melhor quando há uma grande quantidade de arquivos pequenos. No entanto, isso é muita E/S de arquivo. Pode fazer sentido alguma concatenação de arquivos intimamente relacionados, tanto para o fluxo de trabalho quanto para o desempenho do aplicativo. Considere cuidadosamente sua própria experiência e o que outros desenvolvedores compartilham ao implementar o HTTP/2.
A fragmentação de domínio é talvez a estratégia de otimização HTTP/1.x mais extrema e possivelmente a mais bem-sucedida. Você pode usar uma versão de fragmentação de domínio que ainda melhora o desempenho do HTTP/1.x, mas é basicamente ignorada, e de forma benéfica, para o HTTP/2. (Que geralmente não se beneficia do sharding de domínio, devido ao uso de uma única conexão.)
Para fragmentação compatível com HTTP/2, faça estas duas coisas acontecerem:
Para obter detalhes, consulte RFC 7540 , Hypertext Transfer Protocol versão 2 (HTTP/2) .
Se essas condições estiverem presentes, a fragmentação ocorrerá para HTTP/1.x – os domínios são diferentes o suficiente para fazer com que os navegadores criem conjuntos adicionais de conexões – e não para HTTP/2; os domínios separados são tratados como um domínio, e uma única conexão pode acessar todos eles.
HTTP/2 e TLS provavelmente melhorarão o desempenho do seu site e permitirão que os usuários saibam que a interação com seu site é segura. Não importa se você é o primeiro no seu bairro a implementar HTTP/2 ou está alcançando os concorrentes, você pode adicionar suporte a HTTP/2 de forma rápida e eficiente.
Use essas dicas para ajudar você a atingir o mais alto desempenho do HTTP/2 com o mínimo de esforço contínuo, para que você possa se concentrar na criação de aplicativos rápidos, eficazes e seguros, que sejam fáceis de manter e executar.
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."