7 consejos para un rendimiento HTTP/2 más rápido

Para obtener más información sobre HTTP/2, vea la grabación de nuestro popular seminario web, ¿Qué hay de nuevo en HTTP/2?

El venerable estándar del Protocolo de Transferencia de Hipertexto, o HTTP , ahora ha sido actualizado. El estándar HTTP/2 fue aprobado en mayo de 2015 y ahora se está implementando en navegadores y servidores web (incluidos NGINX Plus y NGINX Open Source ). Actualmente, casi dos tercios de todos los navegadores web en uso admiten HTTP/2 y la proporción crece varios puntos porcentuales cada mes.

HTTP/2 se basa en el protocolo SPDY de Google, y SPDY seguirá siendo una opción hasta que finalice su soporte en el navegador Chrome de Google a principios de 2016 . NGINX fue un partidario pionero de SPDY y ahora desempeña el mismo papel con HTTP/2. Nuestro completo documento técnico, HTTP/2 para desarrolladores de aplicação web (PDF), describe HTTP/2, muestra cómo se basa en SPDY y explica cómo implementarlo.

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

• HTTP/2 es un protocolo binario, en lugar de texto, lo que lo hace más compacto y eficiente.
• Utiliza una única conexión multiplexada por dominio, en lugar de múltiples conexiones que llevan un archivo cada una.
• Los encabezados se comprimen con el protocolo HPACK especialmente diseñado (en lugar de gzip, como en SPDY)
• HTTP/2 tiene un esquema de priorización complejo para ayudar a los navegadores a solicitar primero los archivos más necesarios, lo cual es totalmente compatible con NGINX (SPDY tenía un esquema más simple).

Ahora debe decidir si avanza con HTTP/2, y parte de eso es saber cómo aprovecharlo al máximo. Esta publicación de blog lo guiará a través de los aspectos relacionados con el rendimiento del proceso de toma de decisiones e implementación. Consulte estos 7 consejos para el rendimiento de HTTP/2:

1. Decide si necesitas HTTP/2 hoy
2. Terminar HTTP/2 y TLS
3. Considere comenzar con SPDY
4. Identifique las optimizaciones HTTP/1.x en su código
5. Implementar HTTP/2 o SPDY
6. Revisar las optimizaciones de HTTP/1.x
7. Implementar la fragmentación inteligente

Nota : Ni SPDY ni HTTP/2 requieren TLS, estrictamente hablando, pero ambos son principalmente beneficiosos 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 comentamos en nuestro documento técnico, HTTP/2 para desarrolladores de aplicação web (PDF). Sin embargo, HTTP/2 no es una solución mágica: es útil para algunas aplicações web, pero menos para otras.

Es probable que el uso de HTTP/2 mejore el rendimiento del sitio web si utiliza SSL/TLS (de aquí en adelante denominado TLS). Pero si no lo ha hecho, necesitará agregar soporte TLS antes de poder usar HTTP/2. En ese caso, espere que la pérdida de rendimiento por usar TLS se compense aproximadamente con el beneficio de rendimiento por usar HTTP/2, pero pruebe si esto es realmente cierto para su sitio antes de tomar una decisión de implementación.

A continuación se presentan cinco beneficios potenciales clave de HTTP/2:

1. Utiliza una sola conexión por servidor : HTTP/2 utiliza una conexión por servidor, en lugar de una conexión por solicitud de archivo. Esto significa una necesidad mucho menor de configuraciones de conexión que consumen mucho tiempo, lo que es especialmente beneficioso con TLS, porque las conexiones TLS requieren mucho tiempo para crearse.
2. Ofrece un rendimiento TLS más rápido : HTTP/2 solo necesita un costoso protocolo de enlace TLS, y la multiplexación aprovecha al máximo la conexión única. HTTP/2 también comprime los datos del encabezado y evitar las optimizaciones de rendimiento de HTTP/1.x como la concatenación de archivos permite que el almacenamiento en caché funcione de manera más eficiente.
3. Simplifica sus aplicações web : con HTTP/2 puede alejarse de las “optimizaciones” de HTTP/1.x que hacen que usted, como desarrollador de la aplicación, y el dispositivo cliente trabajen más.
4. Ideal para páginas web mixtas : HTTP/2 brilla con páginas web tradicionales que combinan HTML, CSS, código JavaScript, imágenes y multimedia limitada. Los navegadores pueden priorizar las solicitudes de archivos para que las partes clave de la página aparezcan primero y más rápido.
5. Admite mayor seguridad : al reducir el impacto en el rendimiento de TLS, HTTP/2 permite que más aplicações web lo utilicen, lo que proporciona mayor seguridad para los usuarios.

Y aquí hay cinco desventajas correspondientes que encontrarás:

1. Mayor sobrecarga para la conexión única : el algoritmo de compresión de datos HPACK actualiza una tabla de búsqueda en ambos extremos. Esto hace que la conexión tenga estado y la conexión única requiere memoria adicional.
2. Es posible que no necesite cifrado : si sus datos no necesitan protección o ya están protegidos por DRM u otra codificación, la seguridad TLS probablemente no le ayude mucho.
3. Las optimizaciones de HTTP/1.x son dañinas : las optimizaciones de HTTP/1.x en realidad afectan el rendimiento en los navegadores que admiten HTTP/2, y deshacerlas es un trabajo extra para usted.
4. Las descargas grandes no son beneficiosas : si su aplicação web entrega principalmente archivos grandes y descargables o transmisiones multimedia, probablemente no desee TLS, y la multiplexación no proporciona ningún beneficio cuando solo se usa una transmisión.
5. Puede que a sus clientes no les importe : tal vez usted crea que a sus clientes no les importa si los videos 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 aspecto tenemos buenas y malas noticias.

La buena noticia es que una prueba interna inicial que realizamos aquí en NGINX muestra el resultado que la teoría predeciría: para páginas web de contenido mixto solicitadas a través de conexiones con latencias típicas de Internet, HTTP/2 funciona mejor que HTTP/1.x y HTTPS. Los resultados se dividen en tres grupos según el tiempo de ida y vuelta (RTT) típico de la conexión:

• RTT muy bajos (0–20 ms) : prácticamente no hay diferencia entre HTTP/1.x, HTTP/2 y HTTPS.
• RTT típicos 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. Para ciudades de EE. UU. cercanas entre sí, el RTT es de aproximadamente 30 ms, y de aproximadamente 70 ms de costa a costa (aproximadamente 3000 millas). En la ruta más corta entre Tokio y Londres, el RTT es de unos 240 ms.
• RTT altos (300 ms y más) : HTTP/1.x es más rápido que HTTP/2, que es más rápido que HTTPS.

La figura muestra el tiempo transcurrido hasta la primera pintura, es decir, el tiempo hasta que el usuario ve por primera vez el contenido de la página web aparecer 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 conocer más detalles sobre nuestras pruebas, mire mi presentación de nginx.conf 2015, El módulo HTTP/2 en NGINX .

Sin embargo, cada página web es diferente y, de hecho, cada sesión de usuario es diferente. Si tiene medios de transmisión o archivos descargables de gran tamaño, o si ha extraído científicamente, digamos, el azúcar de sus optimizaciones HTTP/1.x (con disculpas a The Martian ), sus resultados pueden ser diferentes, o incluso opuestos.

El resultado final es que es posible que el equilibrio entre costos y beneficios no esté claro. Si es así, aprende todo lo que puedas, realiza pruebas de rendimiento en tu propio contenido y luego toma una decisión. (Para obtener orientación, mire nuestro seminario web, ¿Qué hay de nuevo en HTTP/2? ).

Consejo 2 – Finalizar HTTP/2 y TLS

Terminar un protocolo significa que los clientes se conectan a un servidor proxy utilizando un protocolo deseado, como TLS o HTTP/2. Luego, el servidor proxy se conecta a servidores de aplicação , servidores de bases de datos, etc., sin utilizar necesariamente el mismo protocolo, como se muestra en la figura.

Utilizar un servidor separado para la terminación significa pasar a una arquitectura multiservidor. Los servidores pueden ser servidores físicos separados, servidores virtuales o instancias de servidor virtual en un entorno de nube como AWS . Esto supone un avance en complejidad en comparación con un solo servidor, o incluso con una combinación de servidor de aplicação y servidor de base de datos. Pero ofrece muchos beneficios y es prácticamente –sin juego de palabras– una necesidad para sitios con mucho trabajo.

Una vez que se coloca un servidor o servidor virtual frente a una configuración existente, muchas cosas son posibles. El nuevo servidor descarga la tarea de las comunicaciones del cliente de los otros servidores y se puede utilizar para equilibrar la carga, almacenar en caché archivos estáticos y otros fines. Resulta fácil agregar y reemplazar servidores de aplicação y otros servidores según sea necesario.

NGINX y NGINX Plus se utilizan a menudo para todos estos propósitos: terminar TLS y HTTP/2, equilibrar la carga y más. No es necesario cambiar en absoluto el entorno existente, excepto “integrarlo” con el servidor NGINX.

Consejo 3 – Considere comenzar con SPDY

Editor: Desde la publicación de esta entrada de blog, SPDY ha llegado al final del soporte de los principales navegadores. Comenzar 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. Debido a que existe desde hace varios años, más navegadores web admiten SPDY que HTTP/2 . Sin embargo, al momento de escribir este artículo, la brecha se está cerrando: aproximadamente dos tercios de los navegadores web admiten HTTP/2, mientras que aproximadamente cuatro de cada cinco admiten SPDY.

Si tiene prisa por implementar el nuevo estilo de protocolo de transporte web y desea brindar soporte al mayor número posible de usuarios hoy, puede comenzar ofreciendo SPDY. Luego, a principios de 2016, cuando comience a eliminarse la compatibilidad con SPDY, podrá migrar a HTTP/2; un cambio rápido, al menos con NGINX. Para entonces, habrá más usuarios en navegadores compatibles con HTTP/2, por lo que habrá hecho lo mejor para la mayor cantidad de usuarios durante esta transición.

Consejo 4: Identifique su uso de optimizaciones HTTP/1.x

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

1. Fragmentación de dominio : es posible que ya haya colocado archivos en diferentes dominios para aumentar el paralelismo en la transferencia de archivos al navegador web; las redes de dominio de contenido (CDN) lo hacen automáticamente. Pero esto no ayuda (y puede perjudicar) el rendimiento bajo HTTP/2. Puede utilizar la fragmentación de dominio compatible con HTTP/2 (consulte el Consejo 7 ) para fragmentar solo para usuarios de HTTP/1.x.
2. Sprites de imágenes : los sprites de imágenes son aglomeraciones de imágenes que se descargan en un solo archivo; luego, un código separado recupera las imágenes a medida que se necesitan. Las ventajas de los sprites de imágenes son menores en HTTP/2, aunque todavía pueden resultarte útiles.
3. Concatenación de archivos de código : de forma similar a los sprites de imágenes, los fragmentos de código que normalmente se mantendrían y transferirían como archivos separados se combinan en uno. Luego, el navegador encuentra y ejecuta el código necesario dentro del archivo concatenado según sea necesario.
4. 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 significa menos transferencias de archivos, a expensas de un archivo HTML inflado para la descarga inicial.

Los últimos tres tipos de optimizaciones combinan archivos pequeños en archivos más grandes para reducir las nuevas conexiones y el protocolo de inicialización, que es especialmente costoso para TLS.

La primera optimización, la fragmentación del dominio, hace lo contrario: fuerza a que se abran más conexiones al involucrar dominios adicionales en la imagen. Juntas, estas técnicas aparentemente contradictorias pueden ser bastante efectivas para aumentar el rendimiento de los sitios HTTP/1.x. Sin embargo, todos ellos requieren tiempo, esfuerzo y recursos para diseñarlos, implementarlos, gestionarlos y ejecutarlos.

Antes de implementar HTTP/2, identifique dónde existen estas optimizaciones y cómo están afectando actualmente el diseño de aplicação y el flujo de trabajo en su organización, para que luego pueda modificarlas o deshacerlas después de la migración a HTTP/2.

Consejo 5 – Implementar HTTP/2 o SPDY

En realidad, implementar HTTP/2 o SPDY no es tan difícil. Si es un usuario de NGINX, simplemente “activa” el protocolo en su configuración de NGINX, como detallamos para HTTP/2 en nuestro documento técnico, HTTP/2 para desarrolladores de aplicação web (PDF). Luego, el navegador y el servidor negociarán para elegir un protocolo y optarán por HTTP/2 si el navegador también lo admite (y si se utiliza TLS).

Una vez que implemente HTTP/2 a nivel de servidor, los usuarios en versiones de navegador compatibles con HTTP/2 tendrán sus sesiones con su aplicación web ejecutadas en HTTP/2. Los usuarios que utilicen versiones de navegador más antiguas tendrán sus sesiones ejecutadas en HTTP/1.x, como se muestra en la figura. Si implementa HTTP/2 o SPDY en un sitio con mucha actividad, deberá contar con procesos establecidos para medir el rendimiento antes y después, y revertir el cambio si tiene impactos negativos significativos.

Nota : Con HTTP/2 y el uso de una única conexión, algunos detalles de la configuración de NGINX se vuelven más importantes. Revise su configuración de NGINX, con especial atención al ajuste y prueba de la configuración 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 obtener consejos más específicos en nuestros blogs "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 con NGINX" , analiza cómo la elección del tamaño de la clave del servidor, el acuerdo del servidor y el cifrado masivo afectan al rendimiento.

Nota : El uso de cifrados que utilice con HTTP/2 puede requerir atención adicional. El RFC para HTTP/2 tiene una larga lista de conjuntos de cifrados que se deben evitar , y es posible que prefiera configurar la lista de cifrados usted mismo. En NGINX y NGINX Plus, considere ajustar la directiva ssl_ciphers y habilitar ssl_prefer_server_ciphers , y probar la configuración con versiones de navegadores populares. La prueba de servidor SSL de Qualys analiza la configuración de los servidores web SSL, pero (a partir de noviembre de 2015) no es confiable para los protocolos de enlace HTTP/2 .

Consejo 6 – Revisar las optimizaciones HTTP/1.x

Sorprendentemente, deshacer o revisar las optimizaciones HTTP/1.x es en realidad la parte más creativa de una implementación HTTP/2. Hay varias cuestiones a considerar y muchos grados de libertad en cuanto a qué hacer.

Antes de comenzar a realizar cambios, considere si los usuarios de navegadores más antiguos los sufrirán. Con esto en mente, existen tres estrategias generales para deshacer o revisar las optimizaciones HTTP/1.x:

• No hay nada que ver aquí, amigos . Si no ha optimizado su(s) aplicação(es) para HTTP/1.x, o ha realizado cambios moderados que no le importa conservar, entonces no tiene trabajo que hacer para soportar HTTP/2 en su aplicación.
• Enfoque mixto : puede decidir reducir la concatenación de archivos y datos, pero no eliminarlos por completo. Por ejemplo, es posible que se mantengan algunas imágenes para grupos cohesivos de imágenes pequeñas, mientras que es posible que no se utilicen datos en línea para aumentar el volumen del archivo HTML inicial.
• Reversión completa de las optimizaciones HTTP/1.x (pero consulte la nota sobre fragmentación del dominio en el Consejo 7 ): es posible que desee deshacerse de estas optimizaciones por completo.

El almacenamiento en caché es un comodín. En teoría, el almacenamiento en caché funciona de forma óptima cuando hay una gran cantidad de archivos pequeños. Sin embargo, eso supone una gran cantidad de E/S de archivos. Puede tener sentido cierta concatenación de archivos estrechamente relacionados, tanto para el flujo de trabajo como para el rendimiento de la aplicação . Considere cuidadosamente su propia experiencia y lo que otros desarrolladores comparten a medida que implementan HTTP/2.

Consejo 7 – Implementar la fragmentación inteligente

La fragmentación de dominios es quizás la estrategia de optimización HTTP/1.x más extrema y posiblemente también la más exitosa. Puede utilizar una versión de fragmentación de dominio que aún mejora el rendimiento para HTTP/1.x pero que básicamente se ignora, y de manera beneficiosa, para HTTP/2. (Que generalmente no se beneficia de la fragmentación del dominio, debido al uso de una única conexión).

Para una fragmentación compatible con HTTP/2, haga que sucedan estas dos cosas:

• Haga que los nombres de dominio de los recursos fragmentados se resuelvan en la misma dirección IP.
• Asegúrese de que su certificado tenga un comodín que lo haga válido para todos los nombres de dominio utilizados para la fragmentación, o que tenga un certificado multidominio apropiado.

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

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

CONCLUSIÓN

Es probable que HTTP/2 y TLS mejoren el rendimiento de su sitio y permitan a los usuarios saber que su interacción con su sitio es segura. Ya sea que sea el primero en su sector en implementar HTTP/2 o que esté poniéndose al día con sus competidores, puede agregar soporte para HTTP/2 de manera rápida y eficaz.

Utilice estos consejos para ayudarle a lograr el mayor rendimiento de HTTP/2 con el mínimo esfuerzo continuo, de modo que pueda concentrarse en crear aplicações rápidas, efectivas y seguras que sean fáciles de mantener y ejecutar.

Recursos

• Para obtener más información sobre HTTP/2, consulte el documento técnico de NGINX ( PDF ).
• El sitio web Can I use muestra la compatibilidad del navegador con una amplia gama de tecnologías web front-end, incluidas SPDY y HTTP/2 .
• En enero de 2016, más del 6% de los sitios web utilizaban HTTP/2.

 

• Para obtener detalles de nuestras pruebas, consulte la presentación HTTP/2 de nginx.conf 2015.
• NGINX tiene un seminario web, ¿Qué hay de nuevo en HTTP/2?, que describe las características clave y brinda consejos de implementación.
• Para obtener una descripción general de los consejos sobre el rendimiento de NGINX, consulte nuestra publicación de blog, 10 consejos para un rendimiento de aplicação 10x .