HTTP2 por fin ha sido aprobado

POR FIN HTTP2

Hace poco menos de una semana, el 10 de Febrero de 2015, nos desayunábamos con la noticia de que Google abandonaba seguir desarrollando su propuesta de protocolo HTTP. Dicha apuesta se llama SPDY (pronunciado “Speedy”) y con este protocolo Google pretendía optimizar la conexión entre el navegador web y el servidor, y reducir tanto el contenido que se transmite como las conexiones que se realizan, llegando a ratios de ahorro del 50% en la velocidad de las páginas web.

 

Spdy & Http2
SPDY ha sido el germen de HTTP2

El proyecto SPDY comenzó hace ya algunos años, concretamente en noviembre de 2009, y desde entonces han pasado muchas cosas al respecto, propuestas de mejora y evoluciones, todo ello con el objetivo de conseguir una fórmula que permitiese un mejor aprovechamiento de las comunicaciones por el protocolo HTTP. Afortunadamente del germen de SPDY surge la esperada evolución llamada HTTP2. (¿Esperábais algo mas original?).

Esta propuesta de estándar cogió las bases de SPDY y poder convertirlo en el menor tiempo posible en el protocolo estándar que todos usaremos para consultar páginas web, permitir la adopción rápida por todos los fabricantes y actores que tienen algo que decir en este sector, y sobre todo, dar un paso de gigante para dejar atrás ciertos protocolos que no fueron diseñados pensando en su vigencia tantos años después.

La propuesta HTTP2 incluye las mejoras que SPDY proponía, con lo cual se entiende que Google haya decidido abandonar su estándar propio en virtud de no crear hilos paralelos que al final suelen perjudicar a los usuarios. Mantener estos hilos siempre ha sido un histórico error y provoca que fabricantes tomen sus propios caminos y obliguen al mercado a tener en cuenta las diferentes excepciones que cada cual pueda entender. Afortunadamente parece que en este caso, Google no será culpable.

Pues bien, este fin de semana nos hemos encontrado con la noticia (¿casualidad?) de que se ha aprobado oficialmente el estándar HTTP2 , a falta de asignar el número del RFC y otros trabajos de edición menores según ha confirmado Mark Nottingham en su blog.

Esta notificación es un evento importantísimo para todos los que nos dedicamos a la optimización y en general, a cualquiera que tenga relación con Internet. Vamos a echar un vistazo sobre lo que representa todo esto.

¿Son compatibles HTTP1.1 y HTTP2?

Realmente son dos protocolos diferentes . Sin embargo, podemos decir que la versión 2 será compatible con las versiones previas, tanto la actual http1.1 como la anterior (hasta el comienzo de este siglo la http versión 1.0). Todavía no sabemos cómo lo harán cada uno de los implicados en el asunto, pero ya tenemos alguna propuesta como la de Microsoft.

Por ejemplo, los códigos de respuesta del protocolo ( 200, 301, 302, 404 ) siguen siendo exactamente los mismos, al igual que los métodos (GET, POST, HEAD, OPTIONS,etc). No cambiará el formato de las URL, se usarán las mismas variables y parámetros, etc. Se verá mucho más el código 101 (Switching) el cual será parte del diálogo entre el navegador del usuario y el servidor, y se usará para poder cambiar de http 1.1 a http 2 en las primeras conexiones de forma transparente al usuario.

¿Qué trae HTTP2 como mejoras de cara al rendimiento?

Pues bastantes:

  • Pipelining: Ahora mismo, una página cualquiera suele tener de media unos 100 objetos, ya sean contenido, texto, imágenes, ficheros de estilos… Cada archivo se carga desde una conexión (socket) diferente por cada navegador, con lo cual, si ahora mismo tienes 10 pestañas en tu navegador, es posible que puedas abrir cerca de 1000 conexiones cuando recargues. Esto, que lo he contado de forma muy sencilla, se complica cuando hablamos de servicios de datos en tiempo real y equipos de redes como firewalls o routers. Hay un número enorme de conexiones y eso provoca pequeños espacios de tiempo de espera que perjudica al producto web, y tampoco beneficia al usuario. No sólo por lentitud, sino también por problemática para determinados servicios.
En HTTP se pierde mucho tiempo entre conexión y conexión. HTTP2 lo solucionara
En HTTP se pierde mucho tiempo entre conexión y conexión. HTTP2 lo solucionara

Dependiendo de la estructura de las páginas, se da mucho el caso que haya objetos que tengan que esperar a que se descarguen otros objetos relacionados para poder ser mostrados, creando una congestión en la conexión parecida a la que se podría tener en una cola de un supermercado con muchos clientes y pocos dependientes. Ese bloqueo genera en el usuario una sensación de lentitud de la página cuando a lo mejor no es un problema del servidor, sino de cómo se ha estructurado el contenido.

Con HTTP2 se viene a dar respuesta a este problema, pues en una misma conexión TCP se pueden enviar varias peticiones o también trozos de respuesta de otras conexiones. Esto reduce muchísimo el tiempo de espera, y por consiguiente, el tiempo de pintado de una página también disminuye, aumentando la velocidad de la descarga. Reduce las conexiones y los bytes enviados.

Actualmente, los que nos dedicamos al WPO o a la optimización de plataformas usamos determinadas técnicas para minimizar este problema, alterando la estructura del HTML, modificando el orden de algunos objetos o dividiendo el número de nombres de host diferentes (entre otras). HTTP2 va a permitir solucionar de forma nativa este problema.

  • Ahorro en el texto de las cabeceras , enviándolas en formato binario comprimido. Esto ahorra una cantidad considerable de texto repetitivo (cookies, versión, fecha..etc).

Nótese que por cada uno de esas 100 conexiones, por página, de las que hablábamos en el punto anterior se está enviando determinada información como el User-Agent (la versión del navegador, que es siempre la misma), los lenguajes que el navegador acepta o las Cookies. Dentro de una misma sesión todos esos datos son siempre los mismos, por lo que si comprimimos ese texto y evitamos su repetición se ahorran multitud de bytes en todas y cada una de las conexiones.

  • CONTENT PUSHING: La actualización de muchos servicios web se basa en repetir peticiones a un mismo objeto del servidor para comprobar si éste ha cambiado o no, por ejemplo, un newsfeed. Esto es un desperdicio de tiempo y de recursos, pues por cada petición (poll) se gasta un round-trip y eso tiene una consecuencia en milisegundos.

Incluso han surgido tecnologías nuevas para mejorar estos comportamientos (como WebSockets), pero el objetivo primordial sigue sin resolverse. No se puede saber con http si un objeto ha cambiado o no hasta que se lo preguntamos. Con estas soluciones paralelas se consigue un efecto parecido, pero normalmente implican algo más de complejidad para los gestores de infraestructuras, diseñadores… No dejan de ser “parches” que deberían solucionarse de otra manera.

 

La tecnología PUSH acelera las conexiones y permite el tiempo real
La tecnología PUSH acelera las conexiones y permite el tiempo real

En otras tecnologías, como el correo electrónico, se dispone de servicios PUSH, los cuales se encargan de informar cuando hay cambios en el recurso. Pues bien, HTTP2 permite enviar archivos desde el servidor al cliente sin que éste los pida. Actualmente, en http/1.1 cuando pedimos una página, primero se descarga el HTML, se analizan los enlaces y después se descargan todos los objetos que la componen, archivos CSS, JavaScripts e imágenes enlazados por éste. Con PUSH podríamos enviar todos los objetos desde el principio sin la necesidad de que el browser haga el renderizado, analizado y emitir los consiguientes requests. Esto también ahorraría websockets y minimizaría la complejidad en servicios que necesiten actualización continua o tiempo real.

  • PRIORIZACION y ETIQUETADO: En el caso de aplicaciones que necesiten mayor velocidad, o un tratamiento especial, se les podrá etiquetar y priorizar, de tal modo que a la hora de recoger los fragmentos dentro de una conexión se pueda recuperar primero los que tengan más preferencia.

¿Qué retos nos supone para la optimización?

Es un protocolo binario sobre TLS. Más allá de la seguridad, esto quiere decir que toda la comunicación, ya sea en cabeceras o en el contenido, va a ser algo más complicada de inspeccionar y analizar:
1)     Al ser conexiones totalmente binarias, la capacidad de diagnóstico con las herramientas típicas, tipo sniffer, curl, Firebug o similar han de cambiar pues no seremos capaces de inspeccionar dentro de los protocolos binarios. Por ejemplo, Firefox ya lo soporta, y podemos ver las cabeceras sin cifrar:

Con Firefox tools ya podemos ver las cabeceras
Con Firefox tools ya podemos ver las cabeceras

2)     El pipelining va a enviarnos diferentes fragmentos en diferentes conexiones, con lo cual, las herramientas de diagnóstico deberán ser capaces de analizar los identificadores de los fragmentos para recomponer la trama y poder saber de dónde viene cada petición.

3)     El cambio de protocolo probablemente exija una negociación extra para las conexiones la primera vez, pues a priori, una URL que comparte el nombre de protocolo “http” no va a saber en qué versión está. Es decir, una url http o https implican el nombre del protocolo en sí mismo. Como las direcciones y esquemas de las páginas no pueden cambiarse (no podemos forzar a nadie a poner HTTP2 al inicio de las url’s o cambiar todas las páginas para que los enlaces empiecen por HTTP2) habrá una negociación extra para forzar al web browser al cambio de protocolo.

El equipo de Microsoft propone (desde Internet Explorer) enviar en cada request una cabecera extra Upgrade: , de tal manera que el servidor detecte dicha cabecera y pueda ofrecer un código determinado “101 Switching” que indique al navegador que soporta HTTP2 y realizar de nuevo toda la conexión, lo que en el argot se conoce como round-trip.

¿Qué hago para empezar a usar HTTP2?

Una vez que ya está aprobado de forma oficial, se deberán publicar las especificaciones reales del protocolo. Estas reglas serán las bases sobre las cuales cada uno de los desarrolladores de software y fabricante oficializará el soporte para la versión 2.

En los navegadores el soporte vendrá en alguna de las diferentes actualizaciones, y esto será totalmente transparente para el usuario.

Sin embargo, será algo más lento para servidores y elementos intermedios como proxys o firewalls. Esta última parte es la que llevará algo más de tiempo, pues los diferentes proveedores de servicios, CDNs y fabricantes de hardware deberán entender el protocolo. Aunque el propio concepto de HTTP2 implementará soluciones para que se pueda “tunelizar” en conexiones HTTP1, tendremos un reto debido a la gran cantidad de equipos o sistemas que no podrán actualizarse de ningún modo. Es decir, si una oficina que dispone de versión actualizada de navegadores se quiere conectar a un recurso http2 a través de un proxy que NO entiende ese protocolo, ¿cómo lo arregla? ¿Y si el fabricante de ese proxy no ofrece soporte?

Habrá que prestar atención a ver cómo se resuelve ese problema.

Probablemente muchos de que esos fabricantes hayan hecho ya ese trabajo sobre SPDY (por ejemplo Mozilla , Apache o NGINX), pero otros tantos no habrán querido hacer esa inversión hasta no tener seguro que el protocolo será el aceptado por el resto de la industria. Incluso, hay algunas voces disonantes, como la gente de Varnish, a los cuales no les acaba de convencer. Sin embargo, desde TransparentCDN pensamos que la adopción será relativamente rápida, y por nuestra parte, también lo será.

¿Qué pensamos en TransparentCDN?

A nosotros nos apasiona la mejora de las páginas y cómo con un poco de atención y de trabajo el rendimiento de los productos que aceleramos aumenta drásticamente. El beneficio de todos los participantes en esta industria redundará en una mejor adopción de las técnicas e iniciativas tecnológicas, permitiendo a todos ganar en este campo. Por nuestro lado, como expertos en la mejora y aceleración, no podemos más que congratularnos de que algunas de estas mejoras se puedan tener “de serie”.

Siempre habrá otras muchas cosas que mejorar, pero eso no lo veremos hasta que este protocolo esté totalmente extendido.

Falta por ver cómo homogeneizar las diferentes iniciativas abiertas para que converjan en el estándar real que todos han de cumplir. Sólo cuando salga el RFC real empezaremos a ver las primeras implementaciones serias y a partir de ahí empezar a ofrecer soluciones a los problemas que se nos planteen.

Estaremos atentos.

Os recomendamos la lectura de este documento para ampliar un poco más la información

Saludos cordiales,