7 consejos para mejorar el rendimiento de HTTP/2

NGINX | 26 de octubre de 2015

Para obtener más información sobre HTTP/2, vea la grabación de nuestro popular seminario web: «¿Qué novedades presenta HTTP/2?»

El venerable protocolo de transferencia de hipertexto, o HTTP, acaba de actualizarse. El estándar HTTP/2 se aprobó en mayo de 2015 y ya se está implementando en navegadores y servidores web (incluidos NGINX Plus y NGINX Open Source). Actualmente, HTTP/2 es compatible con casi dos tercios de todos los navegadores web en uso, y esta proporción aumenta varios puntos porcentuales al mes.

HTTP/2 se basa en el protocolo SPDY de Google, y SPDY seguirá siendo una opción hasta que deje de ser compatible con el navegador Chrome de Google a principios de 2016. NGINX fue pionero en la adopción de SPDY y ahora desempeña el mismo papel con HTTP/2. Nuestro exhaustivo libro blanco, «HTTP/2 para desarrolladores de aplicaciones web» (PDF), describe HTTP/2, muestra cómo se basa en SPDY y explica cómo implementarlo.

Las principales características de HTTP/2 son las mismas que las de SPDY:

HTTP/2 es un protocolo binario, en lugar de textual, lo que lo hace más compacto y eficiente
Utiliza una única conexión multiplexada por dominio, en lugar de varias conexiones que transportan un archivo cada una
Las cabeceras se comprimen con el protocolo HPACK, diseñado específicamente para este fin (en lugar de gzip, como en SPDY)
HTTP/2 cuenta con un complejo sistema de priorización que ayuda a los navegadores a solicitar primero los archivos más necesarios y que es totalmente compatible con NGINX (SPDY tenía un sistema más sencillo)

Ahora debe decidir si seguir adelante con HTTP/2, y para ello es fundamental saber cómo sacarle el máximo partido. Esta entrada del blog le guiará por los aspectos relacionados con el rendimiento durante el proceso de toma de decisiones e implementación. Consulte estos 7 consejos para mejorar el rendimiento de HTTP/2:

Decide si necesita HTTP/2 hoy
Finalizar HTTP/2 y TLS
Considere empezar con SPDY
Identifique las optimizaciones de HTTP/1.x en su código
Implementar HTTP/2 o SPDY
Revisar las optimizaciones de HTTP/1.x
Implementar la fragmentación inteligente

Nota: En sentido estricto, ni SPDY ni HTTP/2 requieren TLS, pero ambos resultan especialmente útiles cuando se utilizan con SSL/TLS, y los navegadores solo admiten SPDY o HTTP/2 cuando se utiliza SSL/TLS.

Consejo 1 – Decide si necesitas HTTP/2 hoy

Implementar HTTP/2 es fácil, como explicamos en nuestro libro blanco, «HTTP/2 para desarrolladores de aplicaciones web» (PDF). Sin embargo, HTTP/2 no es una solución mágica: resulta útil para algunas aplicaciones web, pero no tanto para otras.

Es probable que el uso de HTTP/2 mejore el rendimiento del sitio web si utiliza SSL/TLS (en adelante, TLS). Sin embargo, si aún no lo utiliza, deberá añadir compatibilidad con TLS antes de poder usar HTTP/2. En ese caso, cabe esperar que la pérdida de rendimiento derivada del uso de TLS se vea compensada, aproximadamente, por la mejora de rendimiento que aporta HTTP/2. No obstante, antes de tomar una decisión sobre su implementación, compruebe si esto se cumple realmente en su sitio web.

Estas son cinco posibles ventajas clave de HTTP/2:

Utiliza una única conexión por servidor – HTTP/2 utiliza una conexión por servidor, en lugar de una conexión por cada solicitud de archivo. Esto reduce considerablemente la necesidad de establecer conexiones, un proceso que requiere mucho tiempo, lo que resulta especialmente beneficioso con TLS, ya que las conexiones TLS tardan bastante en establecerse.
Ofrece un rendimiento TLS más rápido – HTTP/2 solo necesita un costoso protocolo de enlace TLS, y la multiplexación permite aprovechar al máximo la conexión única. HTTP/2 también comprime los datos de las cabeceras, y evitar optimizaciones de rendimiento de HTTP/1.x, como la concatenación de archivos, permite que el almacenamiento en caché funcione de forma más eficiente.
Simplifica tus aplicaciones web – Con HTTP/2 puedes prescindir de las «optimizaciones» de HTTP/1.x que os obligan tanto a ti, como desarrollador de la aplicación, como al dispositivo cliente a trabajar más.
Ideal para páginas web con contenido mixto – HTTP/2 destaca en las páginas web tradicionales que combinan HTML, CSS, código JavaScript, imágenes y contenido multimedia limitado. Los navegadores pueden priorizar las solicitudes de archivos para que las partes clave de la página aparezcan antes y con rapidez.
Ofrece mayor seguridad – Al reducir el impacto de TLS en el rendimiento, HTTP/2 permite que más aplicaciones web lo utilicen, lo que proporciona una mayor seguridad a los usuarios.

Y estas son las cinco desventajas correspondientes con las que te encontrarás:

Mayor sobrecarga para la conexión única – El algoritmo de compresión de datos HPACK actualiza una tabla de consulta en ambos extremos. Esto hace que la conexión mantenga un estado y que la conexión única requiera memoria adicional.
Puede que no necesite cifrado – Si sus datos no necesitan protección o ya están protegidos mediante DRM u otro tipo de codificación, es probable que la seguridad TLS no le aporte demasiado.
Las optimizaciones de HTTP/1.x son perjudiciales – Las optimizaciones de HTTP/1.x reducen el rendimiento en los navegadores compatibles con HTTP/2, y deshacerlas supone trabajo adicional.
Las descargas grandes no se benefician – Si su aplicación web sirve principalmente archivos grandes descargables o transmisiones multimedia, probablemente no le interese usar TLS, y la multiplexación no aporta ninguna ventaja cuando solo se utiliza un flujo.
Puede que a sus clientes no les importe – Quizá crea que a sus clientes no les importa si los vídeos de gatos que comparten en su sitio están protegidos con TLS y HTTP/2 – y puede que tenga razón.

Todo se reduce al rendimiento y, en ese sentido, tenemos buenas y malas noticias.

La buena noticia es que una prueba interna inicial que realizamos en NGINX arroja el resultado que cabría esperar según la teoría: en el caso de páginas web con contenido mixto solicitadas a través de conexiones con las latencias habituales de Internet, HTTP/2 ofrece un mejor rendimiento que HTTP/1.x y HTTPS. Los resultados se dividen en tres grupos en función del tiempo de ida y vuelta (RTT) habitual de la conexión:

RTT muy bajos (0–20 ms) – Prácticamente no hay diferencias entre HTTP/1.x, HTTP/2 y HTTPS.
RTT habituales de Internet (30–250 ms) – HTTP/2 es más rápido que HTTP/1.x, y ambos son más rápidos que HTTPS. Entre ciudades estadounidenses cercanas, el RTT es de unos 30 ms, mientras que de costa a costa (unos 4800 kilómetros) es de unos 70 ms. En la ruta más corta entre Tokio y Londres, el RTT es de unos 240 ms.
RTT altos (300 ms o más) – HTTP/1.x es más rápido que HTTP/2, que a su vez es más rápido que HTTPS.

La figura muestra el tiempo hasta el primer renderizado, es decir, el tiempo que transcurre hasta que el usuario ve por primera vez el contenido de la página web en la pantalla. Esta medición suele considerarse fundamental para la percepción que tienen los usuarios de la capacidad de respuesta de un sitio web.

Para obtener más información sobre nuestras pruebas, vea mi presentación de nginx.conf 2015, «El módulo HTTP/2 de NGINX».

Sin embargo, cada página web es diferente y, de hecho, cada sesión de usuario también lo es. Si ofrece contenido multimedia en streaming o archivos grandes para descargar, o si ha exprimido, esto... científicamente al máximo sus optimizaciones de HTTP/1.x (con disculpas a «Marte»), sus resultados pueden ser diferentes o incluso opuestos.

En definitiva, puede que la relación entre costes y beneficios no le resulte clara. Si es así, infórmese todo lo posible, realice pruebas de rendimiento con su propio contenido y, después, tome una decisión. (Para obtener orientación, vea nuestro seminario web, «¿Qué novedades ofrece HTTP/2?»).

Consejo 2 – Termina HTTP/2 y TLS

Terminar un protocolo significa que los clientes se conectan a un servidor proxy mediante el protocolo deseado, como TLS o HTTP/2. A continuación, el servidor proxy se conecta a los servidores de aplicaciones, los servidores de bases de datos, etc., sin utilizar necesariamente el mismo protocolo, como se muestra en la figura.

Usar un servidor independiente para la terminación implica adoptar una arquitectura con varios servidores. Estos pueden ser servidores físicos independientes, servidores virtuales o instancias de servidores virtuales en un entorno de nube como AWS. Esto supone un aumento de la complejidad con respecto a un único servidor, o incluso a una combinación de servidor de aplicaciones y servidor de bases de datos. Sin embargo, ofrece muchas ventajas y es prácticamente —nunca mejor dicho— imprescindible para los sitios con mucho tráfico.

Una vez que se coloca un servidor físico o virtual delante de una configuración existente, se abren muchas posibilidades. El nuevo servidor libera a los demás servidores de la tarea de gestionar las comunicaciones con los clientes y puede utilizarse para equilibrar la carga, almacenar en caché archivos estáticos y otros fines. Así, resulta sencillo añadir y sustituir servidores de aplicaciones y otros servidores según sea necesario.

NGINX y NGINX Plus se utilizan a menudo para todos estos fines: terminación de TLS y HTTP/2, balanceo de carga y mucho más. No es necesario modificar en absoluto el entorno existente, salvo para colocar el servidor NGINX delante de él.

Consejo 3 – Plantéate empezar con SPDY

Nota del editor: Desde la publicación de esta entrada de blog, los principales navegadores han dejado de ofrecer compatibilidad con SPDY. Empezar con SPDY ya no es una opción para una implementación generalizada.

SPDY es el protocolo predecesor de HTTP/2 y su rendimiento general es prácticamente el mismo. Como existe desde hace varios años, hay más navegadores web que son compatibles con SPDY que navegadores que son compatibles con HTTP/2. Sin embargo, en el momento de escribir estas líneas, la diferencia se está reduciendo: aproximadamente dos tercios de los navegadores web son compatibles con HTTP/2, mientras que alrededor de cuatro de cada cinco son compatibles con SPDY.

Si tiene prisa por implementar el nuevo tipo de protocolo de transporte web y quiere ofrecer compatibilidad al mayor número posible de usuarios en la actualidad, puede empezar ofreciendo SPDY. Después, a principios de 2016, cuando empiece a retirarse la compatibilidad con SPDY, podrá pasarse a HTTP/2, un cambio rápido, al menos con NGINX. Para entonces, habrá más usuarios que utilicen navegadores compatibles con HTTP/2, por lo que habrá hecho lo mejor para el mayor número posible de usuarios durante esta transición.

Consejo 4 – Identifique el uso que hace de las optimizaciones de HTTP/1.x

Antes de decidir implementar HTTP/2, debe determinar qué parte de su código está optimizada para HTTP/1.x. Hay cuatro tipos de optimizaciones que debe tener en cuenta:

Fragmentación de dominios – Es posible que ya haya colocado archivos en distintos dominios para aumentar el paralelismo en la transferencia de archivos al navegador web; las redes de distribución de contenidos (CDN) lo hacen automáticamente. Sin embargo, esto no mejora el rendimiento con HTTP/2 e incluso puede perjudicarlo. Puede usar una fragmentación de dominios compatible con HTTP/2 (consulte el Consejo 7) para aplicarla únicamente a los usuarios de HTTP/1.x.
Sprites de imágenes – Los sprites de imágenes son conjuntos de imágenes que se descargan en un único archivo; después, un código independiente recupera las imágenes a medida que se necesitan. Las ventajas de los sprites de imágenes son menores con HTTP/2, aunque pueden seguir resultando útiles.
Concatenación de archivos de código – Al igual que ocurre con los sprites de imágenes, los fragmentos de código que normalmente se mantendrían y transferirían como archivos independientes se combinan en uno solo. A continuación, el navegador busca y ejecuta el código necesario dentro del archivo concatenado cuando corresponde.
Inserción de archivos en línea – El código CSS, el código JavaScript e incluso las imágenes se insertan directamente en el archivo HTML. Esto reduce el número de transferencias de archivos, aunque a costa de aumentar el tamaño del archivo HTML que se descarga inicialmente.

Los tres últimos tipos de optimización combinan archivos pequeños en otros más grandes para reducir el número de conexiones nuevas y los intercambios de inicialización, que resultan especialmente costosos con TLS.

La primera optimización, la fragmentación de dominios, hace justo lo contrario: obliga a abrir más conexiones al incorporar dominios adicionales. En conjunto, estas técnicas aparentemente contradictorias pueden ser bastante eficaces para mejorar el rendimiento de los sitios HTTP/1.x. Sin embargo, diseñarlas, implementarlas, gestionarlas y mantenerlas en funcionamiento requiere tiempo, esfuerzo y recursos.

Antes de implementar HTTP/2, identifique dónde se aplican estas optimizaciones y cómo afectan actualmente al diseño de las aplicaciones y al flujo de trabajo de su organización, para poder modificarlas o deshacerlas tras la migración a HTTP/2.

Consejo 5 – Implemente HTTP/2 o SPDY

En realidad, implementar HTTP/2 o SPDY no es tan difícil. Si utiliza NGINX, solo tiene que «activar» el protocolo en la configuración de NGINX, tal como explicamos para HTTP/2 en nuestro libro blanco, HTTP/2 para desarrolladores de aplicaciones web (PDF). A continuación, el navegador y el servidor negociarán qué protocolo utilizar y optarán por HTTP/2 si el navegador también lo admite (y si se utiliza TLS).

Una vez que implemente HTTP/2 en el servidor, las sesiones de los usuarios que utilicen versiones de navegadores compatibles con HTTP/2 se ejecutarán en su aplicación web mediante HTTP/2. Las sesiones de los usuarios que utilicen versiones anteriores de los navegadores se ejecutarán mediante HTTP/1.x, como se muestra en la figura. Si decide implementar HTTP/2 o SPDY en un sitio con mucho tráfico, deberá contar con procesos para medir el rendimiento antes y después, así como para revertir el cambio si tiene efectos negativos significativos.

Nota: Con HTTP/2 y el uso de una única conexión, algunos detalles de la configuración de NGINX cobran mayor importancia. Revise la configuración de NGINX y preste especial atención al ajuste y la comprobación de los valores de directivas como output_buffers, proxy_buffers y ssl_buffer_size. Para obtener instrucciones generales de configuración, consulte Terminación SSL/TLS de NGINX en la Guía de administración de NGINX Plus. Puede encontrar consejos más específicos en nuestros artículos Descarga de SSL, cifrado y certificados con NGINX y Cómo mejorar el SEO con HTTPS y NGINX. Nuestro informe técnico, Rendimiento de SSL en NGINX, analiza cómo afectan al rendimiento la elección del tamaño de la clave del servidor, el acuerdo del servidor y el cifrado masivo.

Nota: El uso de cifrados con HTTP/2 puede requerir especial atención. El RFC de HTTP/2 contiene una larga lista de conjuntos de cifrado que deben evitarse, por lo que quizá prefiera configurar personalmente la lista de cifrados. En NGINX y NGINX Plus, considere ajustar la directiva ssl_ciphers y habilitar ssl_prefer_server_ciphers, así como probar la configuración con versiones populares de los navegadores. La herramienta Qualys SSL Server Test analiza la configuración de los servidores web SSL, pero (a fecha de noviembre de 2015) no es fiable para los protocolos de enlace de HTTP/2.

Consejo 6 – Revise las optimizaciones de HTTP/1.x

Aunque resulte sorprendente, deshacer o revisar las optimizaciones para HTTP/1.x es, en realidad, la parte más creativa de una implementación de HTTP/2. Hay varias cuestiones que tener en cuenta y un amplio margen para decidir qué hacer.

Antes de empezar a realizar cambios, considere si estos perjudicarán a los usuarios de navegadores antiguos. Teniendo esto en cuenta, existen tres estrategias generales para deshacer o revisar las optimizaciones de HTTP/1.x:

Aquí no hay nada que ver – Si no ha optimizado sus aplicaciones para HTTP/1.x, o ha realizado cambios moderados que no le importa conservar, no tiene que hacer nada para que su aplicación sea compatible con HTTP/2.
Enfoque mixto – Puede optar por reducir la concatenación de archivos y datos, pero sin eliminarla por completo. Por ejemplo, podría mantener algunas hojas de sprites para grupos homogéneos de imágenes pequeñas, pero prescindir de engrosar el archivo HTML inicial con datos insertados.
Reversión completa de las optimizaciones de HTTP/1.x (pero consulte la nota sobre la fragmentación de dominios en el Consejo 7) – Puede que le interese eliminar por completo estas optimizaciones.

El almacenamiento en caché es un tanto impredecible. En teoría, funciona de forma óptima cuando hay una gran cantidad de archivos pequeños. Sin embargo, esto implica muchas operaciones de E/S de archivos. Puede tener sentido concatenar algunos archivos estrechamente relacionados, tanto para mejorar el flujo de trabajo como el rendimiento de la aplicación. Valore detenidamente su propia experiencia y lo que compartan otros desarrolladores a medida que implementen HTTP/2.

Consejo 7 – Implemente una fragmentación inteligente

La fragmentación de dominios es quizá la estrategia de optimización de HTTP/1.x más extrema y, posiblemente, también la más eficaz. Puede utilizar una variante de la fragmentación de dominios que siga mejorando el rendimiento de HTTP/1.x, pero que HTTP/2 básicamente ignore, lo cual resulta beneficioso. (Por lo general, HTTP/2 no se beneficia de la fragmentación de dominios, ya que utiliza una única conexión).

Para que la fragmentación de dominios sea compatible con HTTP/2, asegúrate de que se cumplan estas dos condiciones:

Haz que los nombres de dominio de los recursos fragmentados se resuelvan en la misma dirección IP.
Asegúrate de que tu certificado incluya un comodín que lo haga válido para todos los nombres de dominio utilizados para la fragmentación, o de que dispongas de un certificado multidominio adecuado.

Para obtener más información, consulte RFC 7540, Protocolo de transferencia de hipertexto versión 2 (HTTP/2).

Si se cumplen estas condiciones, la fragmentación se producirá con HTTP/1.x —los dominios son lo suficientemente diferentes como para que los navegadores creen conjuntos adicionales de conexiones—, pero no con HTTP/2; los distintos dominios se tratan como uno solo y una única conexión puede acceder a todos ellos.

Conclusión

HTTP/2 y TLS probablemente mejorarán el rendimiento de tu sitio y permitirán a los usuarios saber que su interacción con él es segura. Tanto si eres el primero de tu entorno en implementar HTTP/2 como si estás poniéndote al día con la competencia, puedes añadir compatibilidad con HTTP/2 de forma rápida y eficaz.

Sigue estos consejos para obtener el máximo rendimiento de HTTP/2 con el mínimo esfuerzo continuado, de modo que puedas centrarte en crear aplicaciones rápidas, eficaces y seguras que sean fáciles de mantener y ejecutar.

Recursos

Para conocer todos los detalles sobre HTTP/2, consulte el libro blanco de NGINX (PDF).
El sitio web Can I use muestra la compatibilidad de los navegadores con una amplia gama de tecnologías web de front-end, entre ellas SPDY y HTTP/2.
En enero de 2016, más del 6 % de los sitios web utilizaban HTTP/2.

Para obtener más información sobre nuestras pruebas, consulte la presentación sobre HTTP/2 de nginx.conf 2015.
NGINX ofrece un seminario web, «¿Qué novedades hay en HTTP/2?», en el que se describen las principales funciones y se ofrecen consejos para su implementación.
Para obtener una visión general de los consejos de rendimiento de NGINX, consulte nuestra entrada del blog «10 consejos para multiplicar por 10 el rendimiento de las aplicaciones».