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.
Tabla de contenido
Hace un par de días, lanzamos el módulo HTTP/2 de NGINX. En esta charla, les daré una breve descripción general del nuevo módulo.
En primer lugar, quiero desmentir algunos mitos en torno al nuevo protocolo.
Mucha gente piensa que HTTP/2 es un sucesor brillante y superior de HTTP/1. No comparto esta opinión y aquí explico por qué. En realidad, HTTP/2 es simplemente otra capa de transporte para HTTP/1, lo que no está mal porque, como resultado, puedes usar HTTP/2 sin tener que cambiar tu aplicação : funciona con los mismos encabezados. Puede simplemente activar HTTP/2 en NGINX y NGINX se encargará gentilmente de todo el asunto del protocolo por usted.
Pero HTTP/2 no es magia. Tiene sus ventajas y desventajas. Hay casos de uso en los que se comporta bien y también escenarios en los que se comporta mal.
Puedes pensar en HTTP/2 como una nueva versión de SPDY porque se basó en SPDY y es un protocolo muy similar. SPDY es un protocolo desarrollado por Google hace un par de años diseñado para acelerar la entrega de contenido web.
NGINX ya soporta SPDY desde hace dos años, por lo que puedes comprobar las ventajas de HTTP/2 utilizando el módulo SPDY. Algunas personas dirían que HTTP/2 es simplemente una versión pulida de SPDY 3.1.
Si no está familiarizado con SPDY, repasaré algunos puntos clave. Y estos puntos clave también son válidos para HTTP/2, porque son básicamente el mismo protocolo 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 codificar y los buenos protocolos binarios tienen algunas ventajas de rendimiento. Sin embargo, también entiendo los inconvenientes de este enfoque.
Aquí hay una solicitud HTTP/2. Se ve bastante bien y, como puedes ver, es muy fácil de depurar. No, sólo estoy bromeando. Es difícil de depurar. Y esa es una de las desventajas de los protocolos binarios.
Es posible que tengas que usar una herramienta para decodificar la solicitud o... bueno, a veces, es posible que tengas que depurar el binario manualmente porque la herramienta puede estar rota o puede que no te muestre todos los detalles ocultos en los bits.
Afortunadamente, la mayoría de las veces puedes simplemente lanzar HTTP/2 en NGINX y nunca lidiar con su naturaleza binaria. Y afortunadamente la mayoría de las solicitudes serán procesadas por máquinas. Las máquinas son mucho mejores que los humanos leyendo protocolos binarios.
El siguiente punto clave de HTTP/2 es la multiplexación. En lugar de enviar y recibir respuestas y solicitudes como flujos de datos separados a través de múltiples conexiones, HTTP/2 las multiplexa en un flujo de bytes o un flujo de datos. Divide datos para diferentes solicitudes y para diferentes respuestas, y cada porción tiene su propia identificación y su campo de tamaño, que está allí para que el punto final pueda determinar qué datos pertenecen a qué solicitud.
La desventaja aquí es que, dado que cada fragmento de datos tiene su propia identificación, sus propios campos, hay algunos metadatos que se transfieren además de los datos reales. Entonces, tiene algunos gastos generales. Como resultado, si solo tienes un flujo de datos, por ejemplo si estás viendo una película, entonces HTTP/2 no es un buen protocolo porque lo único que obtendrás es una sobrecarga adicional.
¿Cuáles son los beneficios de la multiplexación? El principal beneficio de la multiplexación es que al usar una única conexión puedes ahorrar todo el tiempo que dedicarías con HTTP/1.x al protocolo de enlace cuando necesitas crear una nueva solicitud.
Estos retrasos son especialmente dolorosos cuando se trata de TLS. Es por eso que la mayoría de los clientes ahora sólo admiten HTTP/2 mediante TLS. Hasta donde yo sé, no hay planes para soportar HTTP/2 sobre TCP simple porque no trae muchos beneficios. Esto se debe a que los protocolos de enlace TCP no son tan costosos como los protocolos de enlace TLS, por lo que no se ahorra mucho al evitar conexiones múltiples.
El siguiente punto clave sobre HTTP/2 es su compresión de encabezado. Si tiene cookies muy grandes, esto puede ahorrarle cientos de bytes por solicitud o respuesta, pero en general la mayoría de las veces no se beneficiará mucho de la compresión del encabezado. Porque, incluso si piensas en solicitudes separadas, al final tendrás que lidiar con una capa de paquetes en la red y no importa mucho si envías cien bytes o cien bytes y medio, ya que al final todavía resultará en un paquete.
La desventaja de la compresión del encabezado HTTP/2 es que es con estado [ Editor : para las tablas utilizadas para almacenar información de compresión/descompresión]. Como resultado, para cada conexión, los servidores y los clientes deben mantener algún tipo de estado y esto consume mucha más memoria que mantener el estado para las conexiones HTTP/1. Como resultado, cada conexión HTTP/2 utilizará mucha más memoria.
El último punto clave sobre HTTP/2 es su mecánica de priorización. Esto resuelve el problema que se introdujo con la multiplexación. Cuando tienes una sola conexión, tienes una sola tubería y debes decidir con cuidado qué respuesta vas a colocar en esta tubería a continuación.
La priorización es opcional en HTTP/2, pero sin ella no obtendrá muchos beneficios en el rendimiento. El módulo HTTP/2 en NGINX admite totalmente la priorización, y admite la prioridad basada en pesos y la prioridad basada en dependencias. Por lo que hemos visto hasta ahora, actualmente tenemos la implementación más rápida de HTTP/2 en este momento. Éstos son los puntos clave sobre HTTP/2.
A continuación se muestra una diapositiva sencilla que repasa la historia de HTTP/2. Bastante sencillo. Veamos cómo funciona HTTP/2 en la práctica.
Para entender cómo funciona HTTP/2 en diferentes condiciones de red, realicé algunas pruebas de rendimiento en una página web típica. Esta es solo una página HTTP/2 que encontré en Github. Puedes ver cuántos recursos tiene y qué tan grande es cada recurso. Creo que es bastante representativo de un sitio típico.
Aquí está mi entorno de prueba, en caso de que quieras reproducir la prueba.
Y aquí está el resultado que obtuve. Puedes ver que he simulado diferentes latencias de red en el eje X como tiempos de ida y vuelta (RTT) en milisegundos, y luego medí el tiempo de descarga en el eje Y, también en milisegundos. Y esta prueba mide el tiempo de carga de la página cuando todos los recursos de la página están completamente cargados.
En el gráfico se puede observar una tendencia obvia: para latencias bajas, no hay una diferencia significativa entre HTTP, HTTPS y HTTP/2. Para latencias más altas, puedes ver que HTTP/1.x simple es la opción más rápida. HTTP/2 viene en segundo lugar y HTTPS es el más lento.
¿Qué pasa con el momento de “pintar por primera vez”? En muchos casos, es la métrica más significativa desde la perspectiva del usuario porque es cuando realmente ve algo en su pantalla. En muchos casos, no importa tanto el tiempo que tarda la página en cargarse por completo, sino el tiempo que tarda el usuario en ver algo.
Aquí vemos la misma tendencia, pero lo interesante de nuestra prueba es que para latencias en el medio del rango, de 30 ms a 250 ms, HTTP/2 es un poco más rápido que HTTP simple, aunque la diferencia es muy pequeña.
Entonces, esos fueron nuestros puntos de referencia, ahora hablemos sobre cómo configurar HTTP/2 y NGINX.
En realidad es muy sencillo. Todo lo que necesitas hacer es agregar el parámetro http2
a la directiva listen
. Probablemente el paso más complicado aquí es obtener la última versión de OpenSSL porque HTTP/2 requiere la extensión ALPN [ Aplicação-Layer Protocol Negotiation ], y la extensión ALPN solo es compatible con OpenSSL 1.0.2.
También hemos implementado NPN [ Next Protocol Negotiation ] para HTTP/2, que funciona con la mayoría de los clientes en este momento, pero van a eliminar el soporte para NPN ya que SPDY quedará obsoleto a principios de 2016. Esto significa que puedes usar HTTP/2 con la versión OpenSSL, que forma parte de muchas distribuciones de Linux en este momento, pero debes tener en cuenta que dejará de funcionar en un futuro cercano.
Bueno, eso es todo acerca de la configuración de NGINX para HTTP/2 y con eso concluye mi presentación. Gracias.
[ Documentación de referencia para el módulo HTTP/2 ]
P: ¿También soportarán HTTP/2 en el lado ascendente, o sólo soportarán HTTP/2 en el lado del cliente?
A: Por el momento, solo admitimos HTTP/2 en el lado del cliente. No se puede configurar HTTP/2 con proxy_pass
. [ Editor: En la versión original de esta publicación, esta frase se transcribió incorrectamente como “Se puede configurar HTTP/2 con proxy_pass
”.] Pedimos disculpas por cualquier confusión que esto pueda haber causado. ]
Pero ¿qué sentido tiene el HTTP/2 en el backend? Porque, como se puede observar en los puntos de referencia, no hay mucho beneficio en HTTP/2 para redes de baja latencia, como las conexiones ascendentes.
Además, en NGINX tienes el módulo keepalive y puedes configurar un caché keepalive. El principal beneficio de rendimiento de HTTP/2 es eliminar los protocolos de enlace adicionales, pero si ya lo hace con un caché keepalive, no necesita HTTP/2 en el lado ascendente.
¿Está listo para probar HTTP/2 con NGINX Plus en su entorno? Comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.