O módulo HTTP/2 no NGINX

Valentin Bartenev

Esta publicação no blog foi adaptada de uma apresentação de Valentin V. Bartenev na nginx.conf 2015, realizada em São Francisco em setembro.

Sumário

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

0:20 Visão geral do protocolo

Antes de mais nada, quero desmistificar algumas ideias equivocadas sobre o novo protocolo.

Muitas pessoas consideram o HTTP/2 um sucessor moderno e superior ao HTTP/1. Não compartilho dessa opinião, e vou explicar o motivo. Na verdade, o HTTP/2 é apenas mais uma camada de transporte para o HTTP/1, o que não é ruim, pois permite usar o HTTP/2 sem precisar alterar sua aplicação — ele funciona com os mesmos cabeçalhos. Basta habilitar o HTTP/2 no NGINX, e o NGINX cuidará de todos os detalhes do protocolo para você.

Mas o HTTP/2 não faz milagres. Ele tem suas vantagens e desvantagens. Há casos de uso em que funciona bem e também cenários em que apresenta um desempenho ruim.

1:40 Principais recursos do HTTP/2

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

O NGINX já 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. Esses pontos também se aplicam ao HTTP/2, pois eles são basicamente o mesmo protocolo, com algumas diferenças nos detalhes.

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

3:08 Por dentro do HTTP/2 – Binário

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

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

Felizmente, na maioria das vezes, basta habilitar o HTTP/2 no NGINX e você nunca precisará lidar com sua natureza binária. E, felizmente, a maioria das requisições será processada por máquinas. Máquinas são muito melhores do que humanos para interpretar protocolos binários.

4:26 Por dentro do HTTP/2 – 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 de dados separados por meio de várias conexões, o HTTP/2 os multiplexa em um único fluxo de bytes ou de dados. Ele divide os dados de diferentes solicitações e respostas em partes, e cada parte tem sua própria identificação e um campo de tamanho, permitindo que o endpoint determine quais dados pertencem a cada solicitação.

A desvantagem aqui é que, como cada bloco de dados tem sua própria identificação e seus próprios campos, alguns metadados são transferidos além dos dados propriamente ditos. Portanto, há uma certa sobrecarga. Consequentemente, se você tiver apenas um fluxo de dados — por exemplo, ao assistir a um filme —, o HTTP/2 não será um bom protocolo, pois tudo o que você terá será uma 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ê economiza todo o tempo que gastaria com o handshake no HTTP/1.x ao precisar criar uma nova solicitação.

Esses atrasos são especialmente problemáticos quando se trabalha com TLS. É por isso que a maioria dos clientes agora oferece suporte a HTTP/2 somente sobre TLS. Até onde sei, não há planos para oferecer suporte a HTTP/2 sobre TCP sem criptografia, pois isso não traz muitos benefícios. Isso ocorre porque os handshakes de TCP não são tão custosos quanto os de TLS, portanto, evitar várias conexões não proporciona uma economia significativa nesse caso.

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

O próximo ponto importante sobre o HTTP/2 é a compactação de cabeçalhos. Se você tiver cookies muito grandes, isso poderá economizar centenas de bytes por solicitação ou resposta, mas, em geral, na maioria das vezes, a compactação de cabeçalhos não trará muitos benefícios. Isso porque, mesmo considerando solicitações separadas, no fim das contas você estará lidando com uma camada de pacotes na rede, e não fará muita diferença enviar cem bytes ou cento e cinquenta bytes, pois, de qualquer forma, isso ainda resultará em um único pacote.

A desvantagem da compactação de cabeçalhos do HTTP/2 é que ela mantém estado [Editor – Nas tabelas usadas para armazenar informações de compactação/descompactação]. Por isso, a cada conexão, servidores e clientes precisam manter algum tipo de estado, o que consome muito mais memória do que manter o estado de conexões HTTP/1. Consequentemente, 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 é seu mecanismo de priorização. Isso resolve o problema introduzido pela multiplexação. Quando há apenas uma conexão, há apenas um canal, e é preciso decidir cuidadosamente qual resposta será enviada por esse canal em seguida.

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

10:06 História do HTTP/2

Este é um slide simples que apresenta a história do HTTP/2. É bem fácil de entender. Agora, vamos ver como o HTTP/2 funciona na prática.

10:16 Página de teste

Para entender como o HTTP/2 funciona em diferentes condições de rede, fiz alguns testes de desempenho em uma página da web típica. Trata-se apenas de uma página HTTP/2 que encontrei no Github. É possível ver quantos recursos ela contém e o tamanho de cada um deles. Acredito que ela seja bastante representativa de um site típico.

10:52 Ambiente de teste

Este é o meu ambiente de teste, caso você queira reproduzir o teste.

11:02 Carregamento do DOM

E este foi o resultado que obtive. Como você pode ver, simulei diferentes latências de rede no eixo X, representadas como tempos de ida e volta (RTT) em milissegundos, e medi o tempo de download no eixo Y, também em milissegundos. Este teste mede o tempo de carregamento da página até que todos os seus recursos estejam totalmente carregados.

No gráfico, é possível observar uma tendência clara: com latências baixas, não há diferença significativa entre HTTP, HTTPS e HTTP/2. Com latências mais altas, o HTTP/1.x sem criptografia é a opção mais rápida. O HTTP/2 fica em segundo lugar, e o HTTPS é o mais lento.

11:48 Primeira renderização

E quanto ao tempo até a “primeira renderização”? Em muitos casos, essa é a métrica mais importante do ponto de vista do usuário, pois é nesse momento que ele realmente vê algo na tela. Muitas vezes, o tempo necessário para carregar a página por completo não é tão relevante quanto o tempo que o usuário precisa esperar para começar a ver algum conteúdo.

Aqui vemos a mesma tendência, mas o aspecto interessante do nosso teste é que, para latências na faixa intermediária, de 30 ms a 250 ms, o HTTP/2 é um pouco mais rápido que o HTTP convencional, embora a diferença seja muito pequena.

Configuração das 12:45

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

Na verdade, é muito simples. Basta adicionar o parâmetro http2 à diretiva listen. Provavelmente, a etapa mais complicada aqui seja obter a versão mais recente do OpenSSL, pois o HTTP/2 requer a extensão ALPN [Negociação de Protocolo da Camada de Aplicação], que só é compatível com o OpenSSL 1.0.2.

Também implementamos o NPN [Negociação do Próximo Protocolo] para HTTP/2, que atualmente funciona com a maioria dos clientes, mas eles removerão o suporte ao NPN quando o SPDY for descontinuado no início de 2016. Isso significa que, por enquanto, você pode usar HTTP/2 com a versão do OpenSSL incluída em muitas distribuições Linux, mas precisa ter em mente que isso deixará de funcionar em breve.

Então, isso é tudo sobre a configuração do NGINX para HTTP/2, e assim encerro minha apresentação. Obrigado.

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

Perguntas e respostas

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

R: No momento, oferecemos suporte a HTTP/2 apenas no lado do cliente. Não é possível configurar HTTP/2 com proxy_pass. [Editor – Na versão original desta publicação, esta frase foi transcrita incorretamente como “É possível configurar HTTP/2 com proxy_pass”. Pedimos desculpas por qualquer confusão que isso possa ter causado.]

Mas qual é a vantagem do HTTP/2 no backend? Como você pode ver nos benchmarks, o HTTP/2 não oferece muitos benefícios em redes de baixa latência, como as conexões com servidores upstream.

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

Mais recursos sobre HTTP/2

• HTTP/2 para desenvolvedores de aplicações web – White paper (PDF) com tudo o que você precisa saber sobre HTTP/2
• Redes de Navegadores de Alto Desempenho – Edição especial do e-book de Ilya Grigorik, do Google
• Quais são as novidades do HTTP/2? – Webinar da NGINX que descreve os principais recursos e oferece orientações de implementação
• 7 dicas para melhorar o desempenho do HTTP/2 – Artigo do blog
• Lista de navegadores compatíveis com HTTP/2 – site Can I Use?

Pronto para experimentar o HTTP/2 com o NGINX Plus em seu ambiente? Comece sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso.

Sobre o autor

Valentin Bartenev

Mais publicações de Valentin Bartenev