En 2012 se pidieron propuestas para una nueva versión de HTTP. Era muy importante debido al impacto que HTTP tiene en nuestras vidas diarias. De hecho, es probable que para la mayoría de nosotros, nuestras vidas profesionales y privadas actuales no existirían sin HTTP. Por lo tanto, la petición de propuestas fue el inicio de una nueva era para la comunidad de Internet y trataba de cambiar y mejorar este venerable protocolo.
¿Cuál es la razón de este cambio? En 1999 cuando se publicó la especificación HTTP/1.1 los sitios web incluían texto, algunas imágenes, quizá un banner con anuncios. Era sencillo, y nos conectábamos a la velocidad común de un módem de 56k. 16 años más tarde – una eternidad en tiempo Internet – todo ha cambiado, así como nuestras expectativas. Si una página no es instantánea, es demasiado lenta. Además, debería ser responsiva y reproducirse a la perfección en cualquier dispositivo que estemos utilizando en ese momento, y la experiencia debería ser rica. Y móvil – queremos que todo esto funcione en una conexión inalámbrica en diminutos smartphones y tabletas, en cualquier parte del mundo. Es mucho pedir a algo que fue diseñado hace casi dos décadas.
Los objetivos para HTTP/2 eran sencillos: mejorar el rendimiento de HTTP tratando la manera en que se utiliza el protocolo actualmente. En otras palabras, un modo de cargar los sitios web todavía más rápido.
Tres años después y muchas horas de trabajo invertidas, el IETF ha aprobado el estándar HTTP/2 y los navegadores más importantes lo soportan. Cualquiera que utilice una versión actualizada de Firefox o Chrome, o Internet Explorer en una versión temprana de Windows 10, probablemente habrá utilizado HTTP/2 en los últimos dos meses sin saberlo.
¿De qué se trata?
HTTP/2 dispone de toda una gama de características para ayudar a tratar los actuales patrones de uso de la web. Las principales características son:
- Multiplexado
- Compresión de cabecera
- Dependencias y priorización
- Servidor Push
Multiplexado
El multiplexado para HTTP es un modo de solicitar y recibir más de un elemento web a la vez. Es el remedio para el bloqueo de cabeza de línea (head of line blocking – HOL blocking) que es inherente a HTTP/1.1.
Cada solicitud del cliente tiene que esperar hasta que llega la respuesta del servidor a la solicitud previa, lo que puede ser lento ya que una página web media tiene alrededor de 100 objetos. Y cualquiera de estas solicitudes podría detenerse por diferentes razones, lo que causaría que la descarga de toda la página se retrase. Así, un navegador HTTP/1.1 utiliza múltiples conexiones a un servidor para realizar algún atisbo de paralelización, pero presenta problemas y no resuelve del todo el problema del bloqueo de cabeza de línea
HTTP/2 es un protocolo con una estructura binaria. Esto significa que las solicitudes y respuestas están rotas en trozos llamados tramas que contienen meta información que identifica a qué solicitud/respuesta están asociados. Esto permite superponer solicitudes y respuestas para múltiples objetos en la misma conexión sin causar confusión, y pueden recibirse en cualquier orden en que el servidor puede responder. Por ejemplo, una primera solicitud puede tardar más en finalizarse pero no detendrá la entrega de ningún objeto posterior. El resultado: una carga de página y tiempos de reproducción más rápidos.
Compresión de Cabecera
Cabeceras – la meta información que el navegador envía junto con una solicitud para informar mejor al servidor sobre lo que desea y puede aceptar y que se añadía como parte de HTTP/1.1, no era originalmente tan grande. Un navegador, por ejemplo, utilizará una cabecera para indicar a un servidor que es capaz de manejar compresión gzip o una imagen WebP. Asimismo, es donde se comunican las cookies y con el reciente incremento del uso y complejidad, éstas pueden volverse GRANDES. Una de las características de las cabeceras es que no cambian mucho entre solicitudes. Debido a la naturaleza sin estados previos de HTTP/1, un navegador todavía necesita soporte para un formato dado de fichero o lenguaje en cada solicitud. Esto puede crear muchos bytes redundantes.
HTTP/2 ayuda a resolver este problema. Emplear una combinación de tablas de búsquedas y codificación Huffman puede reducir a cero el número de bytes enviado en una solicitud. En la longitud de una sesión web media, las tasas de compresión por encima del 90% son comunes, y para una página media en el lado de la respuesta esto no tiene un gran impacto. Pero en el lado de la solicitud los resultados son importantes. Incluso una página modesta con 75 objetos, por ejemplo, y un tamaño medio de cabecera de solo 500 bytes, podría requerir 4 idas y vueltas TCP solo para solicitar los objetos. Con los mismos parámetros y una compresión del 90% con HTTP/2, un navegador puede enviar todas las solicitudes en una sola ida y vuelta.
Dependencias y Priorización
El Multiplexado y la Compresión de Cabecera marcarán una importante diferencia, pero también plantearán un nuevo reto. Siendo sofisticados, los navegadores han introducido pre-cargadores para asegurar que primero solicitan lo más importante. Por ejemplo, el CSS es crítico para determinar la diagramación de la página, pero un logo al pie de una página no lo es. Si en el nuevo modelo un navegador simplemente solicita todo al mismo tiempo y permite al servidor devolver objetos lo más rápido posible, habrá irónicamente una reducción en el rendimiento de la página, porque aunque todo puede ser más rápido globalmente, los objetos importantes para la reproducción de una página no necesariamente llegan al navegador los primeros. En vez de llevar el problema al navegador, los diseñadores han construido la capacidad para tratarlo en el protocolo. Al comunicar al servidor qué objetos son independientes de qué otros objetos, y haciendo una lista de las prioridades, el servidor puede estar seguro que los datos críticos se entregan al navegador inmediatamente.
Servidor Push
Una manera de resolver la latencia de las idas y venidas de una solicitud y respuesta HTTP es que el servidor envíe al navegador un objeto antes de que se lo pida y aquí es donde interviene el Servidor Push. Superficialmente, la ventaja es obvia – entrega de página instantánea incluso en las peores condiciones. Pero para empujar los objetos correctos sin perder ancho de banda, el servidor tiene que saber lo que el usuario probablemente necesitará luego, y cuál es el estado de la caché del navegador. Es complicado, por ello no existen actualmente aplicaciones generales de push que soporten protocolos como SPDY. Aunque HTTP2 ofrece la herramienta para el Servidor Push hoy en día, estoy seguro de que veremos algunos usos innovadores en los próximos años.
¿Y para el usuario cotidiano?
Nadie tendrá que cambiar su sitio web o aplicaciones para estar seguro de que siguen funcionando adecuadamente. No solo el código de aplicaciones y las APIs HTTP siguen funcionando sin interrupciones, sino que probablemente mejoran el rendimiento y consumen menos recursos tanto del lado cliente como servidor.
A medida que HTTP/2 vaya teniendo más relevancia, las organizaciones que buscan beneficiarse de su rendimiento y características de seguridad deberían empezar a pensar en cómo aprovechar totalmente estas nuevas capacidades. Estas consideraciones incluyen:
- Encriptación: Las aplicaciones que corren sobre HTTP/2 probablemente experimentarán mejoras en el rendimiento sobre conexiones seguras. Esto es una consideración importante para las empresas que están pensando en migrar a TLS.
- Optimizar la capa TCP: Las aplicaciones deberían estar diseñadas con una capa TCP implementada para tener en cuenta el cambio de múltiples conexiones TCP a una única duradera, especialmente cuando se ajusta la ventana de congestión en respuesta a la pérdida de paquetes.
- Olvidar las buenas prácticas de HTTP/1.1: Muchas buenas prácticas asociadas con las aplicaciones entregadas sobre HTTP/1.1 (tales como la compartición del dominio, agrupación de imágenes (image spriting), in-lining y concatenación de recursos) no solo son innecesarias cuando se entrega sobre HTTP/2, sino que en algunos casos pueden causar una falta de optimización.
- Decidir qué y cuándo presionar: Las aplicaciones diseñadas para aprovechar las nuevas capacidades del Servidor Push en HTTP/2 deben estar cuidadosamente diseñadas para equilibrar el rendimiento y la utilidad.
Merece la pena invertir tiempo y esfuerzo en tratar estos y otros retos, incluyendo la optimización de forma diferente de las conexiones HTTP/1.1 vs. HTTP/2 a medida que vayan migrando gradualmente los navegadores y otros clientes en los próximos años. Esto es, al fin y al cabo, el futuro de la web.
Lea más en http://www.siliconweek.es/e-innovation/research/http2-el-futuro-de-la-web-ya-esta-aqui-86927#qI8RzuLkrdEf8rme.99
