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
30 comentarios
Flycow
Pero el servidor tendría que usar HTTP/2 y el cliente también tendría que soportarlo?
lui_l98
Creo que hay una errata. Debajo del ejemplo del globo, dice HTML donde debería decir HTTP.
alons0
¿Como encaja el html5 con el uso del http2?¿Mejoraria el rendiniento de las webs programadas en html 5? ¿Mejorarian los tiempos de carga (aun mas)?
Y sobre todo, ¿como influiría el uso de http2 en las tarifas de datos de los dispositivos moviles y cual seria su impacto?
Buen artículo, pero podría haberse ampliado un poquito mas.
Salu2.
srsuri
Citrix Netscaler y los F5 BigIP (ADC) lo tienen implementado desde hace más de 3 años, esto no es tan nuevo, que se esta masificando es otra cosa, pero todas las paginas que estan detras de estos equipos, son convertidas a SPDY. para que funcionen rapido, el impacto en codificación y creación de web se reduce a 0.
joseavdt4
Imagino que en no mucho tiempo el blog de desarrolladores de Google nos pondrá al tanto de las novedades de cara a implementar esta mejora, que la verdad ya tocaba.
kl0x
Hablas de Chrome, Firefox, Edge.. y Opera y Safari? No es porque los use, es por saber =P
olati
No es lo que digamos "nuevo", ya está funcionando hace mucho. Muchas páginas web que usamos día a día ya lo implementan, si quieren saber quien ya lo implementa pueden instalar para chrome una extensión. hhtp2-and-spdy-indicator.
https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin
Lo de html5 y http2 no tienen relación alguna uno es el protocolo y lo otro es el lenguaje que llega a través de ese protocolo.
dark_god
Interesante. Pero veo más ventajas en el protocolo QUIC de google. Es un protocolo en la capa de transporte (la misma capa que TCP) que usa UDP con un sistema de gestión de paquetes perdidos integrado y soporte para TLS/SSL. He hecho algún análisis comparándolo con TCP con un sniffer y las mejoras son bestiales.
lomaestro
Esto debe ser lo que llaman deja vu
dan1elnole
Muy interesante. Como dato "extra", esto no afectará únicamente a las páginas web, sino a API Restful y demás, que usan protocolos HTTP. Así que, técnicamente, esto no afectará solo a las webs, sino que afectará a un amplio abanico de aplicaciones.
Como ejemplo, tenemos la mayoría de aplicaciones móviles conectadas a internet. La inmensa mayoría usan protocolos HTTP para recibir y enviar información.
Por otro lado, dentro de las propias páginas web existen "sub-aplicaciones", por así llamarlo. Un ejemplo clarísimo sería un chat online.
Ahora bien, entiendo que el usuario final no deberá hacer nada, pero... ¿Y los desarrolladores? ¿Tendremos que cambiar la forma en la que hacemos las peticiones?
hardgo1239
Sería bueno que exista una declaración de los archivos necesarios en html al principio de la pagina. Para una descarga en paralelo
Priyad
Va bien el ritmo de actualización, tal vez ya dentro de 2 años estemos disfrutando en su totalidad de la mejorada forma de cargar los sitios web.
Solo me quedo una duda, ¿El desarrollador web también tiene que actualizar su página?
jonathandiaz4
Genial articulo,solo nos queda aprender las nuevas caracteristicas para implementarlas en los sitios.
christiancárdenas
Existe un error, Safari ya tiene soporte para HTTP/2.
christiancárdenas
HTTP/2 solo estará disponible sobre TLS (sobre las páginas que usen un certificado de seguridad, las https), practicamente todos lo navegadores ya lo soportan
http://can iuse.com/#feat=http2
El problema de su implementación viene por el lado del servidor, si la página web no te provee una conexión HTTP/2, simplemente lo mismo que nada. La página de Xataka por ejemplo no podría ofrecer una conexión HTTP/2 porque no usa TLS, en caso de usar TLS tendría que actualizar su servidor de contenidos a una versión con soporte HTTP/2 y habilitarlo.
amadordorante
¿Habrá que mejorar o cambiar los servidores actuales? Seria un dilema!
elalex.g
En Edge ya está soportado el nuevo protocolo.
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/http2
Saludos.