Introducción al protocolo HTTP/2

La velocidad de carga de una web en el navegador es importante, tanto que añadir unos pocos cientos de milisegundos en un sitio de comercio electrónico afecta en un porcentaje significativo el abandono, la conversión y en definitiva las compras que se realizan. Un tiempo de más de 100ms ya es percibido por los usuarios. Por este motivo además Google lo tiene en cuenta a la hora del posicionamiento en su buscador, con lo que mejorar y tener un tiempo de carga bajo de las páginas producirá más compras y más visitas por tráfico orgánico que se traducirá también en más compras.

Desde hace quince años el protocolo usado para la transferencia desde el servidor al navegador del HTML, CSS, JavaScript, imágenes y demás recursos de la página ha sido el protocolo de transferencia de hypertexto o HTTP. Con el cada vez mayor ancho de banda que ofrece mayores velocidades de transferencia de los dispositivos conectados a internet el tiempo de carga de una página ha dejado de estar tan limitado por la velocidad de transferencia a ser la latencia una parte importante del tiempo. Con el objetivo de disminuir la latencia y el tiempo de carga de las páginas se publicó primero el protocolo SPDY y posteriormente basado en él HTTP/2 en mayo de 2015 con varias mejoras.

HTTP/2 no mofidifica la semántica de protocolo HTTP con lo que los conceptos de métodos HTTP, códigos de estado, URIs y cabeceras siguen siendo los mismos. Algunas de las mejoras que ofrece son:

• Multiplexación y concurrencia: solo es necesaria una conexión TCP para enviar todos los recursos de la página, además la transmisión de varios recursos es posible que sea simultánea sin necesidad de que termine una para iniciar otra lo que evita el problema head-of-line blocking de HTTP 1.1 que era ordenado y bloqueante.
• Descarga de dependencias: el cliente puede priorizar los recursos.
• Compresión de cabeceras: para reducir la sobrecarga de las cabeceras en cada petición se consigue de dos formas, usando un algoritmo de compresión y evitando enviarlas según los valores anteriores transmitidos.
• Envío desde el servidor: el servidor proactivamente puede enviar recursos al cliente para que sean cacheados.

Una diferencia que lo hace incompatible hacia atrás es que es binario pero se puede usar junto con la versión anterior y cuando se establezca la conexión negociando el protocolo elegir el mejor según las características de ambas partes, los protocolos binarios son más eficientes de procesar, más compactos e igual de importante menos propensos a errores comparados los los basados en texto.

Establecer una conexión TCP requiere 3 paquetes entre el cliente y servidor reduciendo el número de ellas la latencia baja. Si la distancia entre el cliente y el servidor es lejana simplemente por cuestiones físicas de la velocidad a la que viaja la luz o los impulsos eléctricos, la latencia entre ellos estando situados en las antípodas es de unos 300-400ms (por paquete). Simplemente con la multiplexación y la concurrencia se reduce considerablemente esta sobrecarga en la transmisión al evitar tener que establecer varias conexiones. Además, tiene otras mejoras para los desarrolladores y hace innecesarias algunas de las optimizaciones que se realizaban con HTTP 1.1, como:

• Ya no es necesario concatenar ficheros eliminado el problema head-of-line blocking y pudiendo transmitir varios ficheros simultáneamente.
• Ya no es necesario incluir el contenido de estilos, imágenes y JavaScript junto con el HTML para evitar conexiones TCP adicionales, igual que en la concatenación de ficheros.
• Ya no es necesario usar múltiples dominios para paralelizar la descarga.

Algunas prácticas de optimización siguen siendo utilizables:

• Reducir consultas DNS por la latencia de envío de paquetes.
• Seguir usando redes de descarga de contenido o CDN, cuanto más cercano esté el servidor del cliente menor será la latencia impuesta por las leyes físicas.
• Seguir usando la caché del cliente evitando retransmitir el recurso.
• Minimizar el contenido de los recursos, menor será las cantidad de datos a transmitir y procesar.
• Eliminar redirecciones innecesarias.

Aunque para usar HTTP/2 no es necesario usar cifrado TLS los navegadores Firefox, Microsoft Edge y Google Chrome han anunciado que en sus implementaciones solo lo soportarán si se usa con cifrado TLS.

En un capítulo del libro High Performance Browser Networking, en HTTP/2 explicado y en la sección de referencia del final del artículo se detallan más los conceptos del protocolo HTTP/2.

En definitiva el protocolo HTTP/2 supone una mejora de rendimiento para los clientes y optimización de recursos tanto para los clientes como para los servidores. Ya está implementado por los navegadores más populares y añadiendo el soporte en lado del servidor los clientes compatibles se beneficiarán de él.

En el siguiente artículo comentaré cómo poner esto en práctica y configurar HTTP/2 con el servidor web Nginx, Apache HTTPD y el servidor de aplicaciones Java WildFly o Jetty.