El módulo HTTP/2 de NGINX

Valentin Bartenev

Esta entrada de blog es una adaptación de una presentación de Valentin V. Bartenev en nginx.conf 2015, celebrada en San Francisco en septiembre.

Índice

Hace un par de días, lanzamos el módulo HTTP/2 de NGINX. En esta charla, voy a ofreceros una breve descripción general del nuevo módulo.

0:20 Descripción general del protocolo

Antes que nada, quiero desmentir algunos mitos en torno al nuevo protocolo.

Mucha gente considera HTTP/2 un sucesor moderno y superior de HTTP/1. No comparto esta opinión, y este es el motivo. En realidad, HTTP/2 no es más que otra capa de transporte para HTTP/1, lo cual no está mal, ya que permite utilizar HTTP/2 sin tener que modificar la aplicación: funciona con las mismas cabeceras. Basta con activar HTTP/2 en NGINX y NGINX se encargará de gestionar por ti todos los aspectos relacionados con el protocolo.

Pero HTTP/2 no es mágico. Tiene sus ventajas y sus inconvenientes. Hay casos de uso en los que funciona bien y otros escenarios en los que funciona mal.

1:40 Características principales de HTTP/2

Puedes considerar HTTP/2 como una nueva versión de SPDY, ya que se basó en este y es un protocolo muy similar. SPDY es un protocolo desarrollado por Google hace un par de años y diseñado para acelerar la entrega de contenido web.

NGINX ya es compatible con SPDY desde hace dos años, por lo que puede comprobar las ventajas de HTTP/2 utilizando el módulo SPDY. Algunos dirían que HTTP/2 no es más que una versión perfeccionada de SPDY 3.1.

Si no está familiarizado con SPDY, voy a repasar algunos puntos clave. Estos puntos también son válidos para HTTP/2, ya que, en esencia, se trata del mismo protocolo, aunque con algunas diferencias en los detalles.

El primer punto clave es que el protocolo en sí es binario. Me gustan los protocolos binarios: son más fáciles de programar y los buenos protocolos binarios ofrecen algunas ventajas de rendimiento. Sin embargo, también entiendo los inconvenientes de este enfoque.

3:08 HTTP/2 por dentro – Binario

Aquí tenemos una solicitud HTTP/2. Tiene muy buena pinta y, como podéis ver, es muy fácil de depurar. No, es broma. Es difícil de depurar. Y esa es una de las desventajas de los protocolos binarios.

Puede que tengas que usar una herramienta para descodificar la solicitud o… bueno, a veces puede que tengas que depurar manualmente los datos binarios porque la herramienta puede fallar o no mostrarte todos los detalles ocultos en los bits.

Afortunadamente, la mayoría de las veces basta con habilitar HTTP/2 en NGINX y olvidarse de su naturaleza binaria. Y, por suerte, la mayoría de las solicitudes serán procesadas por máquinas, que son mucho mejores que los humanos a la hora de interpretar protocolos binarios.

4:26 HTTP/2 por dentro – Multiplexación

El siguiente aspecto clave de HTTP/2 es la multiplexación. En lugar de enviar y recibir solicitudes y respuestas como flujos de datos independientes a través de varias conexiones, HTTP/2 los multiplexa en un único flujo de bytes o de datos. Divide los datos de las distintas solicitudes y respuestas en fragmentos, cada uno con su propio identificador y un campo de tamaño, lo que permite al extremo determinar qué datos corresponden a cada solicitud.

La desventaja en este caso es que, como cada fragmento de datos tiene su propio identificador y sus propios campos, además de los datos propiamente dichos se transfieren también ciertos metadatos. Por tanto, existe cierta sobrecarga. En consecuencia, si solo se dispone de un flujo de datos, por ejemplo al ver una película, HTTP/2 no es un protocolo adecuado, ya que lo único que aportará será una sobrecarga adicional.

¿Cuáles son las ventajas de la multiplexación? La principal ventaja es que, al utilizar una única conexión, se ahorra todo el tiempo que se dedicaría con HTTP/1.x al proceso de negociación necesario para crear una nueva solicitud.

Estos retrasos resultan especialmente problemáticos cuando se utiliza TLS. Por eso, actualmente la mayoría de los clientes solo admiten HTTP/2 sobre TLS. Por lo que sé, no hay planes para admitir HTTP/2 sobre TCP sin cifrar, ya que no ofrece grandes ventajas. Esto se debe a que los procesos de negociación de TCP no son tan costosos como los de TLS, por lo que evitar varias conexiones no supone un gran ahorro.

7:09 Características principales de HTTP/2 – Compresión de cabeceras

El siguiente aspecto clave de HTTP/2 es la compresión de cabeceras. Si tienes cookies muy grandes, esto puede ahorrarte cientos de bytes por solicitud o respuesta, pero, por lo general, la mayoría de las veces no obtendrás grandes ventajas de la compresión de cabeceras. Esto se debe a que, aunque pienses en solicitudes independientes, al final tendrás que lidiar con la capa de paquetes de la red, y no importa demasiado si envías cien bytes o ciento cincuenta, ya que, en última instancia, seguirá siendo un solo paquete.

El inconveniente de la compresión de cabeceras de HTTP/2 es que mantiene un estado [Editor – En las tablas utilizadas para almacenar la información de compresión y descompresión]. Por tanto, los servidores y los clientes deben mantener algún tipo de estado para cada conexión, lo que consume mucha más memoria que mantener el estado de las conexiones HTTP/1. En consecuencia, cada conexión HTTP/2 utilizará mucha más memoria.

8:40 Características principales de HTTP/2 – Priorización

El último aspecto clave de HTTP/2 es su mecanismo de priorización. Este resuelve el problema que introdujo la multiplexación. Cuando solo se dispone de una conexión, solo hay un canal, por lo que se debe decidir cuidadosamente qué respuesta se enviará a continuación por dicho canal.

La priorización es opcional en HTTP/2, pero sin ella no se obtienen grandes mejoras de rendimiento. El módulo HTTP/2 de NGINX es totalmente compatible con la priorización, tanto la basada en pesos como la basada en dependencias. Por lo que hemos visto hasta ahora, contamos actualmente con la implementación de HTTP/2 más rápida. Estos son los aspectos clave de HTTP/2.

10:06 Historia de HTTP/2

Esta es una diapositiva sencilla que repasa la historia de HTTP/2. Es bastante clara. Veamos ahora cómo funciona HTTP/2 en la práctica.

10:16 Página de prueba

Para entender cómo funciona HTTP/2 en distintas condiciones de red, he realizado algunas pruebas de rendimiento en una página web típica. Se trata simplemente de una página HTTP/2 que encontré en Github. Se puede ver cuántos recursos contiene y qué tamaño tiene cada uno. Creo que es bastante representativa de un sitio web típico.

10:52 Entorno de pruebas

Este es mi entorno de pruebas, por si quieres reproducir la prueba.

11:02 Carga del DOM

Y este es el resultado que obtuve. Como puede verse, he simulado distintas latencias de red en el eje X, expresadas como tiempos de ida y vuelta (RTT) en milisegundos, y después he medido el tiempo de descarga en el eje Y, también en milisegundos. Esta prueba mide el tiempo de carga de la página hasta que todos sus recursos se han cargado por completo.

En el gráfico se observa una tendencia clara: con latencias bajas, no hay diferencias significativas entre HTTP, HTTPS y HTTP/2. Con latencias más altas, se puede ver que HTTP/1.x sin cifrar es la opción más rápida. HTTP/2 ocupa el segundo lugar y HTTPS es la opción más lenta.

11:48 Primer renderizado

¿Y qué hay del tiempo hasta el «primer renderizado»? En muchos casos, es la métrica más importante desde la perspectiva del usuario, porque es el momento en el que realmente ve algo en la pantalla. A menudo, el tiempo que tarda la página en cargarse por completo no es tan importante como el tiempo que tarda el usuario en empezar a ver algo.

Aquí observamos la misma tendencia, pero lo interesante de nuestra prueba es que, para latencias situadas en la zona media del intervalo, de 30 ms a 250 ms, HTTP/2 es un poco más rápido que HTTP convencional, aunque la diferencia es muy pequeña.

Configuración de las 12:45

Bien, esos han sido nuestros benchmarks; ahora hablemos de cómo configurar HTTP/2 y NGINX.

En realidad, es muy sencillo. Lo único que hay que hacer es añadir el parámetro http2 a la directiva listen. Probablemente, el paso más complicado sea obtener la versión más reciente de OpenSSL, ya que HTTP/2 requiere la extensión ALPN [negociación de protocolos en la capa de aplicación], y esta extensión solo es compatible con OpenSSL 1.0.2.

También hemos implementado NPN [Negociación del siguiente protocolo] para HTTP/2, que actualmente funciona con la mayoría de los clientes, pero estos dejarán de admitir NPN cuando SPDY quede obsoleto a principios de 2016. Esto significa que, por ahora, puedes usar HTTP/2 con la versión de OpenSSL incluida en muchas distribuciones de Linux, pero debes tener en cuenta que dejará de funcionar en un futuro próximo.

Y eso es todo sobre la configuración de NGINX para HTTP/2. Con esto concluye mi presentación. Gracias.

[Documentación de referencia del módulo HTTP/2]

Preguntas y respuestas

P: ¿También será compatible con HTTP/2 en el lado del servidor de origen o solo en el lado del cliente?

R: Por el momento, solo admitimos HTTP/2 en el lado del cliente. No se puede configurar HTTP/2 con proxy_pass. [Nota del editor: En la versión original de esta publicación, esta frase se transcribió incorrectamente como «Se puede configurar HTTP/2 con proxy_pass». Lamentamos cualquier confusión que esto haya podido causar.]

Pero ¿qué sentido tiene HTTP/2 en el backend? Como se puede ver en las pruebas de rendimiento, HTTP/2 no aporta grandes ventajas en redes de baja latencia, como las conexiones con servidores upstream.

Además, en NGINX está disponible el módulo keepalive, que permite configurar una caché de conexiones persistentes. La principal ventaja de HTTP/2 en cuanto a rendimiento es que elimina los intercambios de conexión adicionales, pero si ya los evita mediante una caché de conexiones persistentes, no necesita HTTP/2 en el lado del servidor de origen.

Más recursos sobre HTTP/2

• HTTP/2 para desarrolladores de aplicaciones web – Libro blanco (PDF) que explica todo lo que necesitas saber sobre HTTP/2
• Redes de alto rendimiento en navegadores – Edición especial del libro electrónico de Ilya Grigorik, de Google
• ¿Qué novedades hay en HTTP/2? – Seminario web de NGINX que describe las principales características y ofrece consejos para su implementación
• 7 consejos para mejorar el rendimiento de HTTP/2 – Entrada de blog
• Lista de navegadores compatibles con HTTP/2 – sitio web Can I Use?

¿Está listo para probar HTTP/2 con NGINX Plus en su entorno? Inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Valentin Bartenev

Más artículos de Valentin Bartenev