7 dicas para melhorar o desempenho do HTTP/2

Valentin Bartenev

Para saber mais sobre HTTP/2, assista à gravação do nosso popular webinar, Quais são as novidades do HTTP/2?

O venerável Protocolo de Transferência de Hipertexto, ou HTTP, acaba de ser 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 é compatível com quase dois terços de todos os navegadores web em uso, e essa proporção cresce vários pontos percentuais por mês.

O HTTP/2 é baseado no protocolo SPDY do Google, e o SPDY continuará sendo uma opção até que o suporte a ele no navegador Google Chrome seja encerrado no início de 2016. A NGINX foi pioneira no suporte ao SPDY e agora desempenha o mesmo papel com o HTTP/2. Nosso abrangente white paper, HTTP/2 para desenvolvedores de aplicações 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:

• O HTTP/2 é um protocolo binário, em vez de textual, 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, cada uma transportando um arquivo
• Os cabeçalhos são compactados com o protocolo HPACK, desenvolvido especificamente para essa finalidade (em vez do gzip, como no SPDY)
• O HTTP/2 tem um esquema complexo de priorização para ajudar os navegadores a solicitar primeiro os arquivos mais necessários, com suporte completo no NGINX (o SPDY tinha um esquema mais simples)

Agora você precisa decidir se deve seguir em frente com o HTTP/2 — e parte dessa decisão envolve saber como aproveitar ao máximo seus recursos. Este post do blog orientará você sobre os aspectos relacionados ao desempenho no processo de tomada de decisão e implementação. Confira estas 7 dicas para melhorar o 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 de HTTP/1.x no seu código
5. Implemente HTTP/2 ou SPDY
6. Revise as otimizações do HTTP/1.x
7. Implemente o particionamento inteligente

Observação: Estritamente falando, nem o SPDY nem o HTTP/2 exigem TLS, mas ambos são mais vantajosos quando usados com SSL/TLS, e os navegadores só oferecem suporte a SPDY ou HTTP/2 quando o SSL/TLS está em uso.

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

Implementar o HTTP/2 é fácil, como explicamos em nosso white paper, HTTP/2 para desenvolvedores de aplicações web (PDF). No entanto, o HTTP/2 não é uma solução milagrosa; ele é útil para algumas aplicações web, mas nem tanto para outras.

O uso de HTTP/2 provavelmente melhorará o desempenho do site se você estiver usando SSL/TLS (daqui em diante, chamado de TLS). Caso contrário, será necessário adicionar suporte a TLS antes de poder usar HTTP/2. Nesse caso, é provável que a perda de desempenho causada pelo uso de TLS seja aproximadamente compensada pelo ganho de desempenho proporcionado pelo HTTP/2. No entanto, antes de decidir pela implementação, faça testes para verificar se isso realmente se aplica ao seu site.

Veja cinco dos principais benefícios potenciais do HTTP/2:

1. Usa uma única conexão por servidor – O HTTP/2 usa uma conexão por servidor, em vez de uma conexão para cada solicitação de arquivo. Isso reduz bastante a necessidade de configurar conexões, um processo demorado, o que é especialmente vantajoso com TLS, pois as conexões TLS levam bastante tempo para serem estabelecidas.
2. Oferece um desempenho de TLS mais rápido – O HTTP/2 precisa de apenas um handshake TLS custoso, e a multiplexação aproveita ao máximo a conexão única. O HTTP/2 também compacta os dados do cabeçalho, e evitar otimizações de desempenho do HTTP/1.x, como a concatenação de arquivos, permite que o cache funcione com mais eficiência.
3. Simplifica suas aplicações web – Com o HTTP/2, você pode deixar de lado as “otimizações” do HTTP/1.x que exigem mais esforço de você, como desenvolvedor da aplicação, e do dispositivo cliente.
4. Excelente para páginas da Web com conteúdo diversificado – O HTTP/2 se destaca em páginas da Web tradicionais que combinam HTML, CSS, código JavaScript, imagens e conteúdo multimídia limitado. Os navegadores podem priorizar as solicitações de arquivos para que as partes mais importantes da página sejam exibidas primeiro e rapidamente.
5. Oferece maior segurança – Ao reduzir o impacto do TLS no desempenho, o HTTP/2 permite que mais aplicações 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 compactação de dados HPACK atualiza uma tabela de consulta em ambas as extremidades. Isso faz com que a conexão mantenha estado e exija memória adicional.
2. Talvez você não precise de criptografia – Se os 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 será muito útil.
3. As otimizações do HTTP/1.x prejudicam o desempenho – As otimizações do HTTP/1.x, na verdade, prejudicam o desempenho em navegadores compatíveis com HTTP/2, e desfazê-las gera trabalho extra para você.
4. Downloads grandes não se beneficiam – Se a sua aplicação web fornece principalmente arquivos grandes para download ou transmissões de mídia, provavelmente você não vai querer usar TLS, e a multiplexação não oferece nenhum benefício quando apenas um fluxo está em uso.
5. Talvez seus clientes não se importem – Talvez você acredite que seus clientes não se importem se os vídeos de gatos que compartilham em seu site estão protegidos por TLS e HTTP/2 – e pode ser que você tenha razão.

No fim das contas, tudo se resume ao desempenho – e, nesse aspecto, temos boas e más notícias.

A boa notícia é que um teste interno inicial realizado aqui na NGINX apresentou o resultado previsto pela teoria: para páginas da Web com conteúdo misto solicitadas por conexões com latências típicas da Internet, o HTTP/2 tem um desempenho melhor do que o HTTP/1.x e o HTTPS. Os resultados se dividem 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) – O HTTP/2 é mais rápido que o HTTP/1.x, e ambos são mais rápidos que o HTTPS. Entre cidades próximas nos EUA, o RTT é de cerca de 30 ms, enquanto de uma costa à outra (cerca de 3.000 milhas) é de aproximadamente 70 ms. Na rota mais curta entre Tóquio e Londres, o RTT é de cerca de 240 ms.
• RTTs altos (300 ms ou mais) – O HTTP/1.x é mais rápido que o HTTP/2, que, por sua vez, é mais rápido que o HTTPS.

A figura mostra o tempo até a primeira renderização, ou seja, o tempo decorrido até que o usuário veja pela primeira vez o conteúdo da página da Web aparecer na tela. Essa medição costuma ser considerada fundamental para a percepção dos usuários sobre a capacidade de resposta de um site.

Para saber mais sobre nossos testes, assista à minha apresentação na 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 também é. Se você trabalha com streaming de mídia ou arquivos grandes para download, ou se aplicou ciência até extrair, bem, todo o açúcar das suas otimizações de HTTP/1.x (com desculpas a Perdido em Marte), seus resultados podem ser diferentes ou até mesmo opostos.

Em resumo: talvez você considere que a relação custo-benefício não esteja clara. Nesse caso, informe-se o máximo possível, faça testes de desempenho com seu próprio conteúdo e, então, tome uma decisão. (Para obter orientações, assista ao nosso webinar, Quais são as novidades do HTTP/2?.)

Dica 2 – Encerre o HTTP/2 e o TLS

Encerrar um protocolo significa que os clientes se conectam a um servidor proxy usando o protocolo desejado, como TLS ou HTTP/2. Em seguida, o servidor proxy se conecta a servidores de aplicações, servidores de bancos de dados e assim por diante, sem necessariamente usar o mesmo protocolo, conforme mostrado na figura.

Usar um servidor separado para a terminação significa adotar uma arquitetura com vários servidores. 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 de complexidade em comparação com um único servidor ou até mesmo com uma combinação de servidor de aplicações e servidor de banco de dados. No entanto, oferece muitos benefícios e é praticamente — sem trocadilhos — uma necessidade para sites com muito tráfego.

Depois que um servidor físico ou virtual é colocado à frente de uma configuração existente, muitas possibilidades se abrem. O novo servidor assume a tarefa de comunicação com os clientes, aliviando os demais servidores, e pode ser usado para balanceamento de carga, armazenamento em cache de arquivos estáticos e outras finalidades. Assim, fica fácil adicionar e substituir servidores de aplicativos e outros servidores conforme necessário.

O NGINX e o NGINX Plus são frequentemente usados para todas essas finalidades — terminação de TLS e HTTP/2, balanceamento de carga e muito mais. O ambiente existente não precisa ser alterado, basta colocar o servidor NGINX à frente dele.

Dica 3 – Considere começar com SPDY

Editor – Desde a publicação deste post no blog, o SPDY deixou de ser compatível com os principais navegadores. Começar com o SPDY não é mais uma opção para uma implantação em larga escala.

O SPDY é o protocolo antecessor do HTTP/2, e seu desempenho geral é praticamente o mesmo. Como existe há vários anos, mais navegadores oferecem suporte ao SPDY do que suporte ao HTTP/2. No entanto, no momento em que este texto foi escrito, essa diferença estava diminuindo: cerca de dois terços dos navegadores ofereciam suporte ao HTTP/2, enquanto aproximadamente quatro em cada cinco ofereciam suporte ao SPDY.

Se você estiver com pressa para implementar o novo estilo de protocolo de transporte da Web e quiser oferecer suporte ao maior número possível de usuários hoje, poderá começar oferecendo SPDY. Depois, no início de 2016, quando o suporte a SPDY começar a ser removido, você poderá migrar para HTTP/2 — uma mudança rápida, pelo menos com o NGINX. A essa altura, mais usuários estarão usando navegadores compatíveis com HTTP/2, portanto você terá feito o melhor para o maior número possível de usuários durante essa transição.

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

Antes de decidir implementar o HTTP/2, você precisa identificar quanto da sua base de código está otimizada para o HTTP/1.x. Há quatro tipos de otimização aos quais você deve estar atento:

1. Fragmentação de domínio – Talvez você já tenha colocado arquivos em diferentes domínios para aumentar o paralelismo na transferência de arquivos para o navegador; as redes de distribuição de conteúdo (CDNs) fazem isso automaticamente. No entanto, isso não melhora – e pode até prejudicar – o desempenho com HTTP/2. Você pode usar a fragmentação de domínio compatível com HTTP/2 (consulte a Dica 7) para aplicar a fragmentação apenas aos usuários de HTTP/1.x.
2. Sprites de imagens – Sprites de imagens são conjuntos de imagens baixados em um único arquivo; um código separado recupera cada imagem conforme necessário. As vantagens dos sprites de imagens são menores no HTTP/2, embora eles ainda possam ser úteis.
3. Concatenação de arquivos de código – Assim como ocorre com os sprites de imagem, trechos de código que normalmente seriam mantidos e transferidos como arquivos separados são combinados em um único arquivo. O navegador então localiza e executa o código necessário dentro do arquivo concatenado, conforme necessário.
4. Incorporação de arquivos – Códigos CSS e JavaScript, e até mesmo imagens, são inseridos diretamente no arquivo HTML. Isso reduz o número de transferências de arquivos, mas resulta em um arquivo HTML maior para o download inicial.

Os três últimos tipos de otimização combinam arquivos pequenos em arquivos maiores para reduzir o número de novas conexões e de handshakes de inicialização, que são especialmente custosos para TLS.

A primeira otimização, o particionamento de domínios, faz o oposto: força a abertura de mais conexões ao incluir domínios adicionais. Em conjunto, essas técnicas aparentemente contraditórias podem ser bastante eficazes para melhorar o desempenho de sites HTTP/1.x. No entanto, todas elas exigem tempo, esforço e recursos para serem projetadas, implementadas, gerenciadas e mantidas.

Antes de implementar o HTTP/2, identifique onde essas otimizações estão presentes e como elas afetam atualmente o design dos aplicativos e o fluxo de trabalho da sua organização, para que você possa modificá-las ou desfazê-las após a migração para o HTTP/2.

Dica 5 – Implemente HTTP/2 ou SPDY

Na verdade, implantar HTTP/2 ou SPDY não é tão difícil. Se você usa o NGINX, basta “ativar” o protocolo na configuração do NGINX, conforme explicamos em detalhes sobre o HTTP/2 em nosso white paper, HTTP/2 para desenvolvedores de aplicações web (PDF). Em seguida, o navegador e o servidor negociarão a escolha de um protocolo, optando pelo HTTP/2 se o navegador também for compatível com ele (e se o TLS estiver em uso).

Depois que você implementar o HTTP/2 no servidor, as sessões dos usuários que utilizam versões de navegadores compatíveis com o HTTP/2 serão executadas nesse protocolo em seu aplicativo web. Já as sessões dos usuários que utilizam versões mais antigas de navegadores serão executadas no HTTP/1.x, conforme mostrado na figura. Se e quando você implementar o HTTP/2 ou o SPDY em um site com muito tráfego, será importante contar com processos para medir o desempenho antes e depois da implementação e reverter a alteração caso ela tenha impactos negativos significativos.

Observação: Com o HTTP/2 e o uso de uma única conexão, alguns detalhes da configuração do NGINX se tornam mais importantes. Revise a configuração do NGINX, prestando atenção especial ao ajuste e ao teste das configurações de diretivas como output_buffers, proxy_buffers e ssl_buffer_size. Para obter instruções gerais de configuração, consulte Encerramento de SSL/TLS no NGINX no Guia de Administração do NGINX Plus. Você pode encontrar dicas mais específicas em nossos blogs Descarregamento de SSL, criptografia e certificados com o NGINX e Como melhorar o SEO com HTTPS e NGINX. Nosso white paper, Desempenho de SSL do NGINX, analisa como a escolha do tamanho da chave do servidor, do acordo de chaves do servidor e da cifra de bloco afeta o desempenho.

Observação: o uso de cifras com HTTP/2 pode exigir atenção especial. A RFC do HTTP/2 contém uma longa lista de conjuntos de cifras que devem ser evitados, e talvez seja melhor configurar a lista de cifras por conta própria. No NGINX e no NGINX Plus, considere ajustar a diretiva ssl_ciphers e habilitar ssl_prefer_server_ciphers, além de testar a configuração com versões populares de navegadores. O Qualys SSL Server Test 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 do HTTP/1.x

Surpreendentemente, desfazer ou revisar suas otimizações para HTTP/1.x é, na verdade, a parte mais criativa de uma implementação de HTTP/2. Há várias questões a considerar e muita liberdade para decidir o que fazer.

Antes de começar a fazer alterações, considere se elas prejudicarão os usuários de navegadores mais antigos. Tendo isso em mente, há três estratégias gerais para desfazer ou revisar as otimizações de HTTP/1.x:

• Nada para ver aqui, pessoal – Se você não otimizou seus aplicativos para HTTP/1.x ou fez alterações moderadas que não se importa em manter, não precisa fazer nada para oferecer suporte a HTTP/2 no seu aplicativo.
• Abordagem mista – Você pode optar por reduzir a concatenação de arquivos e dados, mas sem eliminá-la por completo. Por exemplo, alguns sprites de imagens para grupos coesos de imagens pequenas podem ser mantidos, enquanto o aumento do arquivo HTML inicial com dados incorporados pode ser descartado.
• Reversão completa das otimizações do HTTP/1.x (mas consulte a observação sobre fragmentação de domínio na Dica 7) – Talvez seja melhor eliminar completamente essas otimizações.

O cache é um tanto imprevisível. Em teoria, ele funciona de forma ideal quando há uma grande quantidade de arquivos pequenos. No entanto, isso gera muitas operações de E/S de arquivos. Pode fazer sentido concatenar alguns arquivos estreitamente relacionados, tanto para o fluxo de trabalho quanto para o desempenho da aplicação. Avalie cuidadosamente sua própria experiência e o que outros desenvolvedores compartilham à medida que implementam o HTTP/2.

Dica 7 – Implemente o sharding inteligente

O particionamento de domínios talvez seja a estratégia de otimização mais extrema e, possivelmente, também a mais bem-sucedida para HTTP/1.x. Você pode usar uma versão do particionamento de domínios que ainda melhore o desempenho no HTTP/1.x, mas que seja basicamente ignorada — o que é vantajoso — pelo HTTP/2. (Em geral, o HTTP/2 não se beneficia do particionamento de domínios, pois utiliza uma única conexão.)

Para que o sharding seja compatível com HTTP/2, faça estas duas coisas:

• Faça com que os nomes de domínio dos recursos distribuídos entre shards sejam resolvidos para o mesmo endereço IP.
• Verifique se o seu certificado contém um curinga que o torne válido para todos os nomes de domínio usados no sharding ou se você possui um certificado multidomínio adequado.

Para obter detalhes, consulte a RFC 7540, Protocolo de Transferência de Hipertexto Versão 2 (HTTP/2).

Se essas condições forem atendidas, o particionamento ocorrerá no HTTP/1.x — os domínios são diferentes o suficiente para fazer com que os navegadores criem conjuntos adicionais de conexões —, mas não no HTTP/2; os domínios separados são tratados como um único domínio, e uma única conexão pode acessar todos eles.

Conclusão

O HTTP/2 e o TLS provavelmente melhorarão o desempenho do seu site e mostrarão aos usuários que a interação deles com o site é segura. Seja você o primeiro do seu setor a implementar o HTTP/2 ou esteja tentando alcançar a concorrência, é possível adicionar suporte ao HTTP/2 de forma rápida e eficiente.

Use estas dicas para obter o máximo desempenho do HTTP/2 com o mínimo de esforço contínuo, para que você possa se concentrar na criação de aplicações rápidas, eficazes, seguras e fáceis de manter e executar.

Recursos

• Para saber tudo sobre HTTP/2, consulte o white paper da NGINX (PDF).
• O site Can I use mostra a compatibilidade dos navegadores com uma ampla variedade de tecnologias de front-end para a web, incluindo SPDY e HTTP/2.
• Em janeiro de 2016, mais de 6% dos sites usavam HTTP/2.

• Para obter detalhes sobre nossos testes, consulte a apresentação sobre HTTP/2 da nginx.conf 2015.
• A NGINX oferece um webinar, Quais são as novidades do HTTP/2?, que descreve os principais recursos e fornece orientações de implementação.
• Para ter uma visão geral das dicas de desempenho do NGINX, confira nossa publicação no blog, 10 dicas para aumentar em 10 vezes o desempenho de aplicações.

Sobre o autor

Valentin Bartenev

Mais publicações de Valentin Bartenev