Casi todo lo que visitas en la web utiliza en algún momento un protocolo especial conocido como Protocolo de Transferencia de Hipertexto (HTTP). Desde el año 1999, se utiliza la versión 1.1 de HTTP. Este ha sido el estándar actual durante muchos años hasta que Google hizo un anuncio el 10 de febrero de 2015 de que su navegador añadirá soporte completo de lo que ahora se conoce como HTTP/2. Esto suena como un completo galimatías para algunos, pero eso es porque no hay una descripción de lo que HTTP/2 hace de manera diferente. Para entenderlo, tenemos que explorar exactamente lo que hace esta nueva versión del protocolo, y en qué se parece a la versión de HTTP que hemos estado utilizando durante casi dos décadas.

¿Qué consigue HTTP/2?

Siempre que se desarrolla una nueva versión del protocolo, se necesitan objetivos concretos reales. El objetivo más obvio es la compatibilidad con su predecesor, HTTP 1.1. Sin esa capacidad, todos los servidores del mundo tendrán que cambiar a HTTP/2 para que puedas navegar por sus sitios web.

Aunque mantiene la compatibilidad con la versión anterior, este nuevo protocolo hará uso de técnicas avanzadas como medidas contra la latencia, haciendo que las páginas se carguen más rápido. Este es el objetivo principal, el problema que HTTP/2 planea abordar de forma más agresiva.

Otras mejoras son el aumento de la seguridad y la compatibilidad con los proxies inversos.

A grandes rasgos, HTTP/2 no va a ser muy diferente de HTTP 1.1. Cuando navegue por Internet, el efecto más fuerte que sentirá es que las páginas web se cargarán significativamente más rápido siempre que sean compatibles con la nueva versión.

¿Cómo hace HTTP/2 que la web sea más rápida?

Decir que “HTTP/2 hace que todo sea más rápido” es un flaco favor a la cantidad de trabajo que realmente tiene lugar entre bastidores para conseguirlo. El protocolo HTTP 1.1 está plagado de una serie de problemas que eran aceptables en los primeros años del siglo XXI, pero que ya no tienen sentido seguir viviendo en una época en la que el ancho de banda es más barato y se espera que los servidores carguen las páginas a un ritmo mucho más rápido.

La principal forma en la que HTTP/2 pretende abordar los tiempos de carga de las páginas es comprimiendo la cabecera (un fragmento de datos que envía el cliente para solicitar a un servidor que le proporcione los datos dentro de una página web que está visitando). Esto minimiza el tiempo que su ordenador “se da la mano” con el servidor de destino al reducir la cantidad de datos que hay que enviar. Hoy en día, los procesadores son lo suficientemente potentes como para manejar millones de descompresiones en poco tiempo. Tiene más sentido hacer esto ahora.

Aunque lo anterior sólo se ocupará de la latencia en la petición inicial, también hay formas en las que HTTP/2 planea ocuparse de toda la interacción con un sitio web. Implementará directamente las tecnologías server push, que permiten a los servidores ser más activos en el proceso de comunicación. Hasta hace poco, había que enviar peticiones periódicamente al servidor, haciendo que éste interpretara las cabeceras que se le entregaban cada vez que pedía información. Con HTTP/2, el servidor te enviará nuevos datos cuando aparezcan.

Por último, HTTP/2 hará algo llamado “multiplexación” cuando envíe peticiones. En HTTP 1.1, había un problema: cada nuevo paquete tenía prioridad sobre el anterior. Todos se procesaban de forma lineal, lo que provocaba un problema llamado “bloqueo de cabecera”. Básicamente, el rendimiento de un servidor estaba limitado por el hecho de que tenía que procesar el primer paquete que le llegaba mientras dejaba el resto en una cola. Si el paquete tardaba mucho en procesarse, todos los demás paquetes tenían que esperar su turno en la cola. Con HTTP/2, se procesarán varios paquetes al mismo tiempo.

Con esta combinación de diferentes “curas”, HTTP/2 hará todo lo posible para evitar ralentizaciones debidas a problemas específicos de HTTP. Esto será especialmente ventajoso para los sitios web con servidores más pequeños que no están conectados a tanto ancho de banda como los de Facebook y Google.