BLOG | NGINX

7 dicas para um desempenho HTTP/2 mais rápido

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Valentin Bartenev Miniatura
Valentin Bartenev
Publicado em 26 de outubro de 2015

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:

  • HTTP/2 é um protocolo binário, em vez de texto, o que o torna mais compacto e eficiente
  • Ele usa uma única conexão multiplexada por domínio, em vez de várias conexões carregando um arquivo cada
  • Os cabeçalhos são compactados com o protocolo HPACK desenvolvido para esse fim (em vez do gzip, como no SPDY)
  • O HTTP/2 tem um esquema de priorização complexo para ajudar os navegadores a solicitar os arquivos mais necessários primeiro, o que é totalmente suportado no NGINX (o SPDY tinha um esquema mais simples)

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:

  1. Decida se você precisa do HTTP/2 hoje
  2. Encerrar HTTP/2 e TLS
  3. Considere começar com SPDY
  4. Identifique otimizações HTTP/1.x em seu código
  5. Implementar HTTP/2 ou SPDY
  6. Revisar otimizações HTTP/1.x
  7. Implementar Smart Sharding

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.

Dica 1 – Decida se você precisa de HTTP/2 hoje

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:

  1. Usa uma única conexão por servidor – HTTP/2 usa uma conexão por servidor, em vez de uma conexão por solicitação de arquivo. Isso significa muito menos necessidade de configuração de conexão demorada, o que é especialmente benéfico com TLS, porque as conexões TLS são particularmente demoradas para serem criadas.
  2. Oferece desempenho TLS mais rápido – o HTTP/2 precisa apenas de um handshake TLS caro, e a multiplexação aproveita ao máximo a conexão única. O HTTP/2 também compacta dados de cabeçalho e evita otimizações de desempenho do HTTP/1.x, como concatenação de arquivos, permitindo que o cache funcione de forma mais eficiente.
  3. Simplifica seus aplicativos da web – Com HTTP/2 você pode se afastar das “otimizações” do HTTP/1.x que fazem você, como desenvolvedor do aplicativo – e o dispositivo cliente trabalharem mais.
  4. Ótimo para páginas da Web mistas – o HTTP/2 brilha com páginas da Web tradicionais que misturam HTML, CSS, código JavaScript, imagens e multimídia limitada. Os navegadores podem priorizar solicitações de arquivos para fazer com que partes importantes da página apareçam primeiro e rapidamente.
  5. Oferece maior segurança – Ao reduzir o impacto no desempenho do TLS, o HTTP/2 permite que mais aplicativos da web o utilizem, proporcionando maior segurança aos usuários.

E aqui estão cinco desvantagens correspondentes que você encontrará:

  1. Maior sobrecarga para a conexão única – O algoritmo de compressão de dados HPACK atualiza uma tabela de consulta em ambas as extremidades. Isso torna a conexão com estado e a conexão única requer memória extra.
  2. Você pode não precisar de criptografia – Se seus dados não precisam de proteção ou já estão protegidos por DRM ou outra codificação, a segurança TLS provavelmente não ajuda muito.
  3. Otimizações de HTTP/1.x prejudicam – As otimizações de HTTP/1.x na verdade prejudicam o desempenho em navegadores que suportam HTTP/2, e desfazê-las é um trabalho extra para você.
  4. Downloads grandes não trazem benefícios – Se seu aplicativo web entrega principalmente arquivos grandes para download ou fluxos de mídia, você provavelmente não quer TLS, e a multiplexação não traz nenhum benefício quando apenas um fluxo está em uso.
  5. Seus clientes podem não se importar – Talvez você acredite que seus clientes não se importam se os vídeos de gatos que eles compartilham em seu site são protegidos com TLS e HTTP/2 – e você pode estar certo.

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:

  • RTTs muito baixos (0–20 ms) – Praticamente não há diferença entre HTTP/1.x, HTTP/2 e HTTPS.
  • RTTs típicos da Internet (30–250 ms) – HTTP/2 é mais rápido que HTTP/1.x, e ambos são mais rápidos que HTTPS. Para cidades dos EUA próximas umas das outras, o RTT é de cerca de 30 ms, e de costa a costa (cerca de 3.000 milhas) é de cerca de 70 ms. Na rota mais curta entre Tóquio e Londres, o RTT é de cerca de 240 ms.
  • RTTs altos (300 ms ou mais) – HTTP/1.x é mais rápido que HTTP/2, que é mais rápido que HTTPS.

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? .)

Dica 2 – Encerre HTTP/2 e TLS

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.

Dica 3 – Considere começar com SPDY

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.

Dica 4 – Identifique seu uso de otimizações HTTP/1.x

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:

  1. Fragmentação de domínio – Você pode já ter colocado arquivos em domínios diferentes para aumentar o paralelismo na transferência de arquivos para o navegador da web; as redes de domínio de conteúdo (CDNs) fazem isso automaticamente. Mas isso não ajuda – e pode prejudicar – o desempenho no HTTP/2. Você pode usar o particionamento de domínio compatível com HTTP/2 (veja a Dica 7 ) para particionar somente para usuários de HTTP/1.x.
  2. Sprites de imagem – Sprites de imagem são aglomerações de imagens que são baixadas em um único arquivo; um código separado recupera as imagens conforme necessário. As vantagens dos sprites de imagens são menores no HTTP/2, embora você ainda possa achá-los úteis.
  3. Concatenando arquivos de código – ;Semelhante aos sprites de imagem, pedaços de código que normalmente seriam mantidos e transferidos como arquivos separados são combinados em um. O navegador então encontra e executa o código necessário dentro do arquivo concatenado, conforme necessário.
  4. Arquivos embutidos – código CSS, código JavaScript e até imagens são inseridos diretamente no arquivo HTML. Isso significa menos transferências de arquivos, às custas de um arquivo HTML inchado para download inicial.

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.

Dica 5 – Implante HTTP/2 ou SPDY

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 .

Dica 6 – Revise as otimizações HTTP/1.x

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:

  • Não há nada para ver aqui, pessoal . Se você não otimizou seu(s) aplicativo(s) para HTTP/1.x, ou fez alterações moderadas que se sente confortável em manter, então não há trabalho a fazer para oferecer suporte ao HTTP/2 em seu aplicativo.
  • Abordagem mista – Você pode decidir reduzir a concatenação de arquivos e dados, mas não eliminá-los completamente. Por exemplo, alguns sprits de imagens para grupos coesos de pequenas imagens podem permanecer, enquanto aumentar o volume do arquivo HTML inicial com dados embutidos pode desaparecer.
  • Reversão completa das otimizações HTTP/1.x (mas veja a nota sobre fragmentação de domínio na Dica 7 ) – Talvez você queira se livrar dessas otimizações completamente.

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.

Dica 7 – Implemente o Smart Sharding

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:

  • Faça com que os nomes de domínio dos recursos fragmentados sejam resolvidos para o mesmo endereço IP.
  • Certifique-se de que seu certificado tenha um curinga que o torne válido para todos os nomes de domínio usados para fragmentação ou que você tenha um certificado multidomínio apropriado.

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.

Conclusão

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.

Recursos


"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."