El protocolo HTTP se inventó en el año 1991 en un terminal NeXTcube con una CPU de 25 MHz y varios MB de RAM. En aquellos años, las páginas web no eran precisamente como las de ahora. Entonces, ¿por qué seguimos usándolo?
Según Daniel Sternberg en http2 explained, la cantidad de datos que se necesita hoy día para cargar la página de inicio de una web normal es 1,9 MB y más de cien recursos (desde una foto a un tipo de letra o un fichero CSS). Pese a lo cual el principal protocolo de la WWW sigue siendo el HTTP/1.1.
Mientras que otros protocolos se han ido actualizando con los años (por ejemplo, el FTP pasó a ser SFTP, POP3 evolucionó a IMAP y telnet dejó paso a SSH), HTTP/1.1 no había cambiado desde la última revisión en 1999, con lo que ha acumulado problemas de velocidad, seguridad y usabilidad. Por eso en 2015 apareció el HTTP/2, la segunda gran versión del protocolo de internet más útil, basada en SPDY.
SPDY: el precursor del HTTP/2
Google se lanzó antes que nadie a investigar los problemas del HTTP/1.1. A mediados de la década del 2000, la empresa gastaba millones de dólares al año en mantener sus centros de datos y el protocolo HTTP/1.1 suponía un gran coste en recursos de CPU y capacidad de conexión a internet. Por eso, como alternativa experimental al HTTP/1.1, en 2009 lanzaron SPDY, un protocolo diseñado para mejorar la seguridad y la velocidad de carga de las páginas que se convertiría en el precursor de HTTP/2.
Novedades del HTTP/2
La gran mejora que introduce el HTTP/2 es la velocidad, que se logra mediante diversas novedades. Todo esto repercutirá optimizando el tiempo de carga de una página sin tener que hacer nada por nuestra parte.
- Estructura binaria.
La estructura de cabeceras y datos en texto plano se sustituye por frames binarios que encapsulan la información. El uso de este tipo de estructura permite habilitar la compresión y la reutilización de una misma conexión TCP, lo que comporta una optimización de los recursos de red, el tiempo de carga y la latencia. - Proactividad (Server push)
Los servidores pueden enviar respuestas por iniciativa propia, adelantándose a la petición del cliente. Por ejemplo, si hasta ahora se tenía que cargar todo el HTML de una página web antes de cargar el contenido en sí (CSS, fotos…), con HTTP/2 el servidor puede enviar elementos que componen la página como CSS, Javascript u otros de manera que cuando el cliente recibe el documento ya dispone de los recursos que éste precisa.El cliente además puede guardar en cache estos elementos para reusarlos en otros documentos y así reducir la carga de red. - Multiplexado
Dado que en HTTP/1.1 resulta mucho más eficiente recuperar una imagen grande que hacer muchas peticiones de imágenes pequeñas, se nos ha venido recomendado condensar todos los iconos en un solo fichero sprite (que los devuelve todos en una sola petición HTTP). No obstante, esto comporta que en ocasiones el usuario reciba un archivo mucho más grande de lo necesario. En cambio, el protocolo HTTP/2 permite atender varios pedidos a la vez, realizando peticiones paralelas mediante una única conexión TCP, lo que se conoce como multiplexado.Por otro lado, el sharding de dominios y la concatenación ya no son necesarios. Puesto que con el protocolo HTTP/2 se pueden solicitar tantos recursos como sean necesarios —a diferencia del HTTP/1.1, que limita el número de conexiones abiertas—, no hace falta repartir los recursos de gran tamaño en varios dominios.Asimismo, muchos desarrolladores concatenan todos los pequeños ficheros CSS y JavaScript de la página web con la intención de limitar las peticiones HTTP. Con HTTP/2, es preferible organizar los recursos en función de las páginas en las que se emplearán o teniendo en cuenta la frecuencia de cambio. Así se consigue enviar únicamente el código que el usuario necesita.
Algunas críticas a HTTP/2
Si bien en la actualidad no hay alternativa superior al HTTP/2, muchos especialistas esperaban funciones más novedosas, como la sustitución de las cookies por nuevas tecnologías; sin embargo, no se llegaron a incluir en la versión final. Además, algunas de las funciones nuevas, como la compresión de encabezados, son vulnerables a ataques BREACH y CRIME. Aunque sin duda el cifrado es el punto que más controversia ha causado, ya que no es obligatorio; sin embargo, los navegadores principales solo aceptarán comunicaciones HTTP/2 si están cifradas.
¿Tenemos que cambiar nuestras páginas web?
HTTP/2 solo cambia la forma en que se transmiten los datos, no afecta a la especificación HTML. Así, HTTP/2 es compatible retroactivamente con HTTP/1.1 respecto a los contenidos y aplicaciones web.
Debido a las técnicas de optimización para HTTP/1.x descritas en el apartado “Multiplexado” con las que se tiende a usar código inline (incrustado en vez de referenciado) o ficheros sprite, a medida que los servidores se vayan actualizando para utilizar HTTP/2 y más usuarios empleen navegadores compatibles con HTTP/2, una página web que había estado bien optimizada empezará a parecer más lenta que las optimizadas para el nuevo protocolo.
¿Cuándo nos cambiamos a HTTP/2?
Para poder usar HTTP/2 tanto el servidor como el cliente web deben ser compatibles con este protocolo.
Si nuestros visitantes no tienen un cliente web (Firefox, Chrome, IE, …) compatible con HTTP/2 y actualizamos nel servidor para que sirva las páginas con el nuevo protocolo, simplemente no podrán acceder a nuestras webs. Es un factor importante a tener en cuenta.
En el caso de los diseñadores y los desarrolladores que no controlan los servidores en los que trabajan, el paso no podrá darse hasta que los servidores y clientes web se actualicen.
Si gestionas tu propio servidor, el proceso de actualización a HTTP/2 requiere ciertos pasos técnicos y puede resultar conveniente dejarlo en manos de ingenieros cualificados.
Una vez que la página esté alojada en un servidor compatible con HTTP/2, la decisión de continuar optimizando para HTTP/1.1 o para HTTP/2 dependerá del protocolo que utilicen la mayoría de nuestros usuarios.
