O módulo HTTP/2 no NGINX

Esta postagem do blog é uma adaptação de uma apresentação de Valentin V. Bartenev na nginx.conf 2015, realizada em São Francisco em setembro.

Índice

Há alguns dias, lançamos o módulo HTTP/2 do NGINX. Nesta palestra, darei a vocês uma breve visão geral do novo módulo.

0:20 Visão geral do protocolo

Antes de mais nada, quero desmistificar alguns mitos em torno do novo protocolo.

Muitas pessoas pensam no HTTP/2 como um sucessor brilhante e superior do HTTP/1. Não compartilho dessa opinião e aqui está o porquê. HTTP/2 é na verdade apenas outra camada de transporte para HTTP/1, o que não é ruim porque, como resultado, você pode usar HTTP/2 sem ter que alterar seu aplicativo – ele funciona com os mesmos cabeçalhos. Você pode simplesmente ativar o HTTP/2 no NGINX e o NGINX cuidará cuidadosamente de todas as questões do protocolo para você.

Mas HTTP/2 não é mágica. Ela tem suas vantagens e desvantagens. Há casos de uso em que ele se comporta bem e também cenários em que ele se comporta mal.

1:40 Principais recursos do HTTP/2

Você pode pensar no HTTP/2 como uma nova versão do SPDY porque ele foi baseado no SPDY e é um protocolo muito semelhante. SPDY é um protocolo desenvolvido pelo Google há alguns anos, projetado para acelerar a entrega de conteúdo da web.

O NGINX oferece suporte ao SPDY há dois anos, então você pode conferir as vantagens do HTTP/2 usando o módulo SPDY. Algumas pessoas diriam que o HTTP/2 é apenas uma versão aprimorada do SPDY 3.1.

Se você não conhece o SPDY, vou abordar alguns pontos importantes. E esses pontos-chave também são verdadeiros para o HTTP/2, porque eles são basicamente o mesmo protocolo com algumas diferenças em detalhes.

O primeiro ponto importante é que o protocolo em si é binário. Gosto de protocolos binários – eles são mais fáceis de codificar e bons protocolos binários têm algumas vantagens de desempenho. No entanto, também entendo as desvantagens dessa abordagem.

3:08 HTTP/2 Inside – Binário

Aqui está uma solicitação HTTP/2. Parece muito legal e, como você pode ver, é muito fácil de depurar. Não, estou só brincando. É difícil depurar. E essa é uma das desvantagens dos protocolos binários.

Talvez você precise usar uma ferramenta para decodificar a solicitação ou... bem, às vezes, você pode precisar depurar o binário manualmente porque a ferramenta pode estar quebrada ou pode não mostrar todos os detalhes ocultos nos bits.

Felizmente, na maioria das vezes você pode simplesmente lançar o HTTP/2 no NGINX e nunca lidar com sua natureza binária. E, felizmente, a maioria das solicitações será tratada por máquinas. As máquinas são muito melhores do que os humanos na leitura de protocolos binários.

4:26 HTTP/2 Inside – Multiplexação

O próximo ponto-chave do HTTP/2 é a multiplexação. Em vez de enviar e receber respostas e solicitações como fluxos separados de dados por meio de múltiplas conexões, o HTTP/2 os multiplexa em um fluxo de bytes ou um fluxo de dados. Ele divide os dados para diferentes solicitações e para diferentes respostas, e cada fatia tem sua própria identificação e seu campo de tamanho, que está lá para que o endpoint possa determinar quais dados pertencem a qual solicitação.

A desvantagem aqui é que, como cada bloco de dados tem sua própria identificação, seus próprios campos, há alguns metadados que são transferidos além dos dados reais. Então, tem alguma sobrecarga. Como resultado, se você tiver apenas um fluxo de dados, por exemplo, se estiver assistindo a um filme, o HTTP/2 não é um bom protocolo porque tudo o que você obterá é apenas sobrecarga adicional.

Quais são os benefícios da multiplexação? O principal benefício da multiplexação é que, ao usar apenas uma única conexão, você pode economizar todo o tempo que gastaria com HTTP/1.x em handshake quando precisa criar uma nova solicitação.

Esses atrasos são especialmente dolorosos quando você lida com TLS. É por isso que a maioria dos clientes agora oferece suporte somente a HTTP/2 via TLS. Até onde eu sei, não há planos para oferecer suporte a HTTP/2 em vez de TCP simples porque não há muitos benefícios nisso. Isso ocorre porque os handshakes TCP não são tão caros quanto os handshakes TLS, então você não economiza muito aqui evitando conexões múltiplas.

7:09 Principais recursos do HTTP/2 – Compressão de cabeçalho

O próximo ponto importante sobre o HTTP/2 é a compactação de cabeçalho. Se você tiver cookies muito grandes, isso pode economizar centenas de bytes por solicitação ou resposta, mas, em geral, na maioria das vezes você não se beneficiará muito da compactação de cabeçalho. Porque, mesmo se você pensar em solicitações separadas, eventualmente você lidará com uma camada de pacotes na rede e não importa muito se você envia cem bytes ou cento e meio bytes, pois eventualmente ainda resultará em um pacote.

A desvantagem da compactação de cabeçalho HTTP/2 é que ela é com estado [ Editor – Para as tabelas usadas para armazenar informações de compactação/descompactação]. Como resultado, para cada conexão, servidores e clientes devem manter algum tipo de estado e isso consome muito mais memória do que manter o estado para conexões HTTP/1. Portanto, cada conexão HTTP/2 usará muito mais memória.

8:40 Principais recursos do HTTP/2 – Priorização

O último ponto importante sobre o HTTP/2 é sua mecânica de priorização. Isso resolve o problema introduzido pela multiplexação. Quando você tem apenas uma conexão, você tem apenas um pipe, e você deve decidir cuidadosamente qual resposta você vai colocar nesse pipe em seguida.

A priorização é opcional no HTTP/2, mas sem ela você não obterá muitos benefícios em desempenho. O módulo HTTP/2 no NGINX oferece suporte total à priorização e oferece suporte à prioridade com base em pesos e prioridade com base em dependências. Pelo que vimos até agora, temos atualmente a implementação mais rápida do HTTP/2. Esses são os pontos principais sobre o HTTP/2.

10:06 História do HTTP/2

Aqui está um slide simples que aborda a história do HTTP/2. Bastante direto. Vamos ver como o HTTP/2 funciona na prática.

10:16 Página de teste

Para entender como o HTTP/2 funciona sob diferentes condições de rede, fiz alguns benchmarks em uma página da web típica. Esta é apenas uma página HTTP/2 que encontrei no Github. Você pode ver quantos recursos ele tem e quão grande é cada recurso. Acho que é bastante representativo de um site típico.

10:52 Ambiente de teste

Aqui está meu ambiente de teste, caso você queira reproduzir o teste.

11:02 DOM Carregar

E aqui está o resultado que obtive. Você pode ver que eu simulei diferentes latências de rede no eixo X como tempos de ida e volta (RTT) em milissegundos e, então, medi o tempo de download no eixo Y, também em milissegundos. E este teste mede o tempo de carregamento da página quando todos os recursos da página estão totalmente carregados.

No gráfico, você pode ver uma tendência óbvia de que, para latências baixas, não há diferença significativa entre HTTP, HTTPS e HTTP/2. Para latências mais altas, você pode ver que HTTP/1.x simples é a escolha mais rápida. HTTP/2 vem em segundo lugar e HTTPS é o mais lento.

11:48 Primeira Pintura

E a hora da “primeira pintura”? Em muitos casos, é a métrica mais significativa da perspectiva do usuário porque é quando ele realmente vê algo na tela. Em muitos casos, não importa tanto quanto tempo leva para a página carregar completamente, mas importa muito quanto tempo leva para o usuário ver algo.

Aqui vemos a mesma tendência, mas a parte interessante do nosso teste é que para latências no meio do intervalo, de 30 ms a 250 ms, o HTTP/2 é um pouco mais rápido que o HTTP simples, embora a diferença seja muito pequena.

12:45 Configuração

Então, esses foram nossos benchmarks, agora vamos falar sobre como configurar HTTP/2 e NGINX.

Na verdade é muito simples. Tudo o que você precisa fazer é adicionar o parâmetro http2 à diretiva listen . Provavelmente, o passo mais complicado aqui é obter a versão mais recente do OpenSSL porque o HTTP/2 requer a extensão ALPN [ Application‑Layer Protocol Negotiation ], e a extensão ALPN só é suportada pelo OpenSSL 1.0.2.

Também implementamos o NPN [ Next Protocol Negotiation ] para HTTP/2, que funciona com a maioria dos clientes no momento, mas eles vão remover o suporte para NPN, pois o SPDY será descontinuado no início de 2016. Isso significa que você pode usar HTTP/2 com a versão OpenSSL, que faz parte de muitas distribuições Linux no momento, mas você precisa ter em mente que ela deixará de funcionar em um futuro próximo.

Então, é tudo sobre configurar o NGINX para HTTP/2 e isso encerra minha apresentação. Obrigado.

[ Documentação de referência para o módulo HTTP/2 ]

Perguntas e respostas

P: Vocês também oferecerão suporte a HTTP/2 no lado upstream ou somente no lado do cliente?

UM: No momento, só oferecemos suporte a HTTP/2 no lado do cliente. Você não pode configurar HTTP/2 com proxy_pass . [ Editor – Na versão original deste post, esta frase foi transcrita incorretamente como “Você pode configurar HTTP/2 com proxy_pass .” Pedimos desculpas por qualquer confusão que isso possa ter causado. ]

Mas qual é o objetivo do HTTP/2 no backend? Porque, como você pode ver nos benchmarks, não há muito benefício no HTTP/2 para redes de baixa latência, como conexões upstream.

Além disso, no NGINX você tem o módulo keepalive e pode configurar um cache keepalive. O principal benefício de desempenho do HTTP/2 é eliminar handshakes adicionais, mas se você já fizer isso com um cache keepalive, não precisará do HTTP/2 no lado upstream.

Mais recursos HTTP/2

• HTTP/2 para desenvolvedores de aplicativos da Web – White paper (PDF) cobrindo tudo o que você precisa saber sobre HTTP/2
• Rede de navegador de alto desempenho – Edição especial do e-book de Ilya Grigorik do Google
• O que há de novo no HTTP/2? – Webinar do NGINX descrevendo os principais recursos e dando conselhos de implementação
• 7 dicas para melhorar o desempenho do HTTP/2 – Postagem do blog
• Lista de navegadores que suportam HTTP/2 – Posso usar? site

Pronto para testar HTTP/2 com NGINX Plus em seu ambiente? Comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .