Sólo unos pocos lo siguen escribiendo al introducir las URL en el navegador, y esos pocos reciben miradas de incredulidad: puede que el estándar HTTP, o Hypertext Transfer Protocol pase cada vez más desapercibido porque lo damos por hecho en todas partes, pero lleva en marcha desde 1997 y sigue siendo el pilar central de las comunicaciones web.
Y ahora, este protocolo va camino de modernizarse con su segunda gran versión: HTTP/2. Llevamos años anticipándolo, sabiendo que su principal ventaja va a ser la velocidad con la que podremos cargar las páginas web, pero ¿cómo va a funcionar exactamente y cuál va a ser la mejora de velocidad real?
El estándar HTTP: lección express
Vamos a hacer un repaso rápido de cómo funciona el estándar HTTP, ya que es "el átomo" indivisible de la web: un cliente (tú, con tu navegador web abierto) solicita a un servidor la carga de una página web mediante la escritura de una dirección web en ese navegador. El servidor recibe esa petición HTTP, y emite una respuesta que consiste en la carga de los ficheros HTML de esa web junto con cualquier otra ejecución que dicha carga comporte.
Además de la carga de esa web, el servidor también responde con un mensaje de estado que indica si todo ha ido bien o si ha habido un error. Seguro que reconocerás el mensaje de estado 404 que indica un error de carga por no haber encontrado nada, o la polémica reciente del mensaje de error con el nuevo código 451 que quieren atribuir al fallo de carga "por razones legales", rodeado de críticas de censura.
Si al estándar HTTP le añadimos una capa de seguridad mediante el protocolo SSL obtendremos HTTPS, que no es más que el estándar HTTP con un cifrado que hace que nadie pueda leer los datos que circulen entre las peticiones que manda el usuario con su navegador y las respuestas del servidor. En Genbeta lo detallamos a fondo, y es una medida de seguridad que la gran mayoría de servicios online consideran ya esencial.
HTTP vs HTTP/2: ¿qué es lo que cambia?
La respuesta rápida es la velocidad a la que trabaja. Vamos con la respuesta más elaborada: HTTP/2 se basa en SPDY, un protocolo presentado en 2009 por Google con la intención de acelerar las webs. En ese entonces se hablaba de un aumento del 22-60% de la velocidad de carga de las webs convencionales y un aumento del 39-55% en el caso de las webs con SSL. Aquí podéis ver las especificaciones finales del nuevo estándar.
¿Cómo se consigue ese aumento de velocidad tan significativo? Pues multiplexando las peticiones que reciben los servidores por parte de los usuarios y sus navegadores web. Es decir: que esos servidores puedan atender varias peticiones al mismo tiempo. Eso también ahorra en cantidad de conexiones, liberando de trabajo a los servidores. Este gráfico lo explica bien:
Además los servidores podrán ser proactivos: reconocerán qué tipo de cliente (navegador web) ha enviado una petición y, además de enviar la respuesta que necesita, enviará también respuestas con datos que ya sabe que el navegador va a necesitar antes de que éste los pida en una nueva petición. Por ejemplo: mientras que con HTML tenemos que cargar primero todo el HTML de la web para después cargar su contenido (CSS, imágenes), con HTTP/2 podemos cargar todo ese contenido al mismo tiempo que el mismo HTML base.
Para los desarrolladores, quizás la novedad que más van a notar es la de los frames. Pasamos de la estructura de header y body en HTML a dividirlo todo en "frames" binarios, que vienen a ser porciones de código identificables como esos header y body que se pueden enviar antes de que el servidor envíe la respuesta del elemento HTML que se ha enviado anteriormente. Esto también ayuda a comprimir mejor el contenido de los headers, que a su vez facilita todavía más una carga rápida de todos los datos.
El cifrado es quizás la novedad que ha traído más debate: HTTP/2 está preparado para aceptar solicitudes cifradas (de la misma forma que ya hace HTTPS), pero no será algo completamente obligatorio tal y como pedían muchos usuarios. Lo que sí que ocurrirá es que la mayoría de navegadores modernos (entre ellos Safari, Firefox, Chrome, Edge, Internet Explorer y Opera) sólo aceptarán comunicaciones HTTP/2 si están cifradas, de modo que aunque no va a ser algo estrictamente obligatorio sí que prácticamente hará que todos los desarrolladores apliquen ese cifrado quieran o no. La EFF ya está haciendo pasos para que hacerlo no sea demasiado complicado.
Vale, ¿y esto cuánto tiempo ahorra?
He aquí una demostración en vivo desde Besthostnews:
Mientras que el globo terráqueo cargado con HTML 1.1 ha tardado 20,8 segundos en cargar con una latencia de 271 milisegundos, el mismo globo ha tardado 6,67 segundos en cargar con HTML/2 con una latencia de 0 milisegundos.
Esta otra demo de Cloudflare (que podéis probar vosotros mismos aquí) va variando en sus resultados, pero la carga en segundos de un pequeño módulo web que lista los servidores de esa compañía tarda como 3,5 veces menos en cargar si lo hacemos con HTTP/2.
Finalmente, esta otra demo algo más compleja de HTTPWatch nos detalla en qué aspectos de HTTP/2 es donde encontramos la mejora: mientras que la cantidad de conexiones es más o menos la misma en HTTP, HTTPS y HTTP/2, el tiempo de carga es de algunos milisegundos menos en HTTP/2: de 988 a 772:
¿Cuando va a empezar a funcionar HTTP/2?
Pues ya mismo, porque empiezan a haber algunos servicios de optimización de tráfico web que ya implementan algunas (sólo algunas) de las novedades del estándar HTTP/2 como por ejemplo la capacidad de poder responder a peticiones de clientes antes incluso de que éstos las envíen. Chrome y Firefox, los navegadores de escritorio más usados, ya están preparados para aceptar el estándar en su totalidad. Safari y Edge de Microsoft están trabajando para hacerlo en el futuro.
Sólo ese cambio, según el CEO de CloudFlare Matthew Prince, puede hacer que dentro de un año veamos cómo nos ahorramos un segundo cada vez que carguemos una web. ¿Crees que es poco? En términos de descargar archivos puede representar una diferencia muy grande. En beneficio acumulado podríamos estar hablando de 31.000 años ahorrados cada mes.
HTTP/2 en pleno 2017
Un año después de la publicación de este artículo, HTTP/2 sigue su camino no sin sufrir algunos baches. En agosto del año pasado se descubrían algunas vulnerabilidades en el protocolo abriendo posibilidades de ataques de denegación de servicio de varios tipos. Este es el informe completo, redactado por la compañía de seguridad Imperva.
Estas vulnerabilidades ya se están resolviendo, pero como bien apuntaban en NetworkWorld a finales del año eso no resuelve totalmente el problema. Falta que plataformas para servidores web ampliamente utilizados como Nginx, Apache o Jetty implementen la resolución de esas vulnerabilidades, y hasta que no se haga no se va a ganar seguridad por mucho que utilicen el protocolo HTTP2 con cifrado.
Pero aún con esto, un 14,6% de todos los sitios web de la red ya está usando el protocolo HTTP/2 según cifras de W3Techs. Los análisis de ese sitio web nos revelan también que recientemente se han añadido al procolo webs como el Huffington Post o Rakuten. Paso a paso, HTTP/2 sigue avanzando.
HTTP/2 en pleno 2018
Nos vamos un año más adelante en la línea temporal de HTTP/2 para comprobar que no ha habido ningún cambio importante en cuanto a este estándar. La adopción sigue a buen ritmo, pasando de un 14,6% el año pasado a un 27,4% mientras escribo estas líneas a finales de junio de 2018. Plataformas como Java EE también se han integrado.
Algunos portales como HTTP/2 Dashboard matizan ese ritmo de adopción diferenciando entre lo que hace cada web, diferenciando entre lo que consideran un soporte completo del nuevo protocolo o un soporte parcial si el portal acepta peticiones HTTP/2 pero devuelve datos usando HTTP 1.1. Aún así, cada vez más portales abrazan HTTP/2 sin prisa pero sin pausa.
Imágenes | Christiaan Colen, Kiran Foster
En Xataka | HTTP/2 llega 16 años después para traernos una Web más rápida, eficiente y segura
Ver 30 comentarios