" />
ZOOM
GALERÍA
0 COMENTARIOS

Chrome lo incorporará por defecto a principios de 2016

2015, ¿el año del despliegue de HTTP2?

Los protocolos sobre los que se fundamenta Internet son bastante longevos. Tanto los protocolos de nivel de red (IP), como los de transporte (TCP y UDP), así como otros auxiliares llevan muchos años funcionando. Incluso el esperado IPv6 se resiste a implantarse: aunque llevamos años anunciando que se acaban las direcciones IP y que la Internet de las Cosas necesita multiplicar la cantidad de direcciones posibles, gran parte de la red mantiene IPv4 hasta ahora.

Los protocolos de aplicación, sin embargo, son algo más cambiantes. Tanto por modificaciones o extensiones en los protocolos que nos permiten tener correo, leer una página web o transmitir archivos de gran tamaño, como por la aparición de nuevos protocolos que van dando respuesta a nuevas necesidades. Por ejemplo, telnet ha dado paso a ssh en la mayoría de situaciones.

En el caso de HTTP/1.1, el protocolo a través del que se hacen todas las transferencias de una página web, se trata de un protocolo que llevamos utilizando desde el año 1999. Entonces, ni las conexiones ni los usos que hacíamos de la web eran los actuales. Las páginas eran sencillas y con pocos elementos. Fundamentalmente, un archivo de texto (HTML) y algunas imágenes bastante pequeñas para que la página pudiese descargarse con rapidez.

En la actualidad las webs son aplicaciones que establecen conexiones en segundo plano para actualizar información sin recargar la página o, en el caso de las webs que muestran información, están plagadas de elementos, grandes imágenes, vídeos, etc. Cada vez que abres una página se cargan, además del HTML que da forma a la página, archivos de código javascript, hojas de estilo CSS, etc.

Esa tendencia se ha hecho más importante en los últimos años. De hecho, el tamaño medio de una página completa a finales de 2010 era de unos 700 kB y actualmente son 1.977 kB, casi 2 Mb, según los datos de httparchive.org. De seguir esta tendencia, a finales de este año se habrá triplicado el tamaño de las páginas en sólo cinco años. La omnipresencia del vídeo y la complejidad de las aplicaciones web da que pensar que la tendencia seguirá en aumento.

evolucion_tamano_pagina_web

No se trata sólo de que tengamos archivos javascript que son más grandes o imágenes de mayor calidad. También el número de elementos cargados por página ha aumentado: tipografías, librerías javascript, múltiples CSS, contenidos procedentes de otros dominios (redes sociales, plataformas publicitarias, servicios de Google etc.). La solución habitual para la carga de estos elementos en paralelo ha sido abrir varias conexiones TCP. Solución que se convierte en un problema cuando obligamos al sistema a abrir demasiadas conexiones simultáneas y que terminan por ralentizar tanto la carga de la página como el resto de operaciones de red.

Ese es uno de los principales motivos que hacen necesario renovar el protocolo HTTP. HTTP/2 está ya en fase de borrador y para adaptarse será necesario modificar tanto los servidores como los clientes. Por eso ya son varios los navegadores que están experimentando con este nuevo protocolo. Google fue el creador de SPDY, un protocolo que ha sido la base sobre la que se ha construido HTTP/2 y acaba de anunciar que dejará de soportar ese protocolo y Chrome será compatible con HTTP/2 de forma predeterminada a principios del año que viene. Mozilla Foundation lleva tiempo desarrollando HTTP/2 y hace tiempo que ya tiene habilitada la implementación del borrador actual en Firefox, así como Safari o Internet Explorer 11.

Entre las novedades, se eliminan las transferencias en modo texto. Hasta ahora, era sencillo conectarse mediante una herramienta tipo telnet al puerto http de un servidor y pedir una URL con comandos comprensibles tipo «GET /index.html HTTP/1.1». Ahora, la información irá codificada en binario para hacer el proceso más rápido. Para hacer pruebas será necesario utilizar alguna herramienta capaz de codificar las peticiones a HTTP/2.

Otro de los problemas en la versión actual es que hay elementos que retrasan la carga de otros elementos. Hasta que el contenido HTML no está en el navegador del usuario, éste no solicitará las imágenes, hojas de estilo, documentos en Javascript. En HTTP/2 el servidor es capaz de enviar los recursos que crea necesarios sin petición previa del cliente (push). De este modo, la página puede estar lista para ser mostrada antes. Especialmente se evitarán las esperas por recursos que tardan en cargarse o que no están disponible y que bloquean la carga durante un lapso de tiempo que puede llegar a ser muy largo.

Pero el gran cambio es el paso del modelo de múltiples conexiones TCP a una sola conexión. Actualmente cada página que cargamos supone, como media, abrir unas 40 conexiones TCP (según las estadísticas de httparchive.org). De esas conexiones, algunas implican una transferencia grande (digamos, una imagen de 1 Mb), mientras que otras son una pérdida de recursos (por ejemplo, una hoja de estilo CSS para un pequeño elemento de nuestra web que sólo ocupa 1Kb).

Para que el uso de una conexión única sea efectivo, no se pueden transferir todos los recursos en orden: primero el documento solicitado, luego los recursos que carga ese documento y después, por riguroso orden de llegada, los recursos que cargan esos recursos. Para evitar que estas colas de descarga ralenticen todo el proceso, esos contenidos se multiplexan. Es decir, a través de la conexión TCP abierta por el navegador los diferentes recursos se trocean y se van intercalando, de modo que el navegador recibirá normalmente los recursos que le permiten renderizar la página.

De este modo se persigue que la velocidad de carga de las páginas se reduzca y, a la vez, que el uso de recursos de los navegadores y de los servidores web se gestione de forma más eficiente. El usuario no tiene que hacer nada nuevo para aprovecharse de estas ventajas. Basta con tener el navegador al día para que, automáticamente, utilice la versión de HTTP más adecuada para cada servidor.

Así, nos encontraremos a finales de 2015 y principios del próximo año con una base de navegadores instalada que hace interesante para los administradores de sistemas empezar a habilitar este protocolo. Los más utilizados, Apache y nginx, disponen ya de módulos a tal efecto, así como Microsoft IIS. Para los administradores supone una ventaja en dos sentidos: sus usuarios cargarán las páginas de forma más ágil, mejorando la experiencia de usuario, y sus servidores necesitarán menos conexiones TCP para servir información, por lo que en casos de alta demanda el ahorro en recursos puede ser interesante.

No comments yet.

Deja un comentario