HTTP/2, renovación de los cimientos de internet abstracta al usuario

Realizar este tipo de cambios sin duda acarrearán grandes problemas de circulación, por lo que será necesario diseñar al milímetro una estrategia de implantación que reduzca al mínimo plausible el impacto social de dicha medida.

Algo parecido ocurría en estos días en el tercer entorno. Mark Nottingham, presidente del grupo de trabajo de HTTP en IETF anunciaba en su blog (EN) que IESG (Internet Egineering Steering Group) ha aprobado oficialmente la especificación HTTP/2.

Una actualización del protocolo en el que se basa la comunicación cliente-servidor de todo internet, que se dice pronto. 16 años de preparativos para llegar a este momento.

¿Y qué es lo mejor de todo? Que HTTP/2 es retrocompatible con HTTP, por lo que el usuario final solo tendrá que actualizar el navegador, y esperar sentado a que el resto de stakeholders de internet vayan actualizando sus servicios a la nueva estandarización.

Es decir, que el cambio más brutal que internet va a sufrir en los últimos años (casi me atrevería a decir desde que Internet es lo que conocemos de Internet) se hace de forma totalmente abstracta al usuario. Usted, y el que escribe estas palabras, no notará ningún cambio cuando esta web pase de HTTP a HTTP/2, y sin duda el cambio es trascendental para actualizarse a las exigencias de una Internet con otros requisitos distintos a los que había hace dos décadas.

Entrando en el asunto, HTTP/2 viene a heredar algunos de los mantras definidos por Google en SPDY, ese protocolo del que hablábamos hace ya sus años y que ofrecería mayor seguridad a cambio de menor gasto de servidor. De hecho, SPDY dejará de ser soportado por Chrome (EN) en favor de HTTP/2.

Esto en sí mismo daría para hablar largo y tendido en otro artículo (de hecho seguramente acabe cayendo por estos lares), y es que el lobby de la estandarización de protocolos en Internet (como la mayoría del lobby tecnológico, dicho sea de paso) sigue moviéndose a razón de talonario y mono/duopolio de turno. En un panorama en el que IE es de los navegadores que más cumplen las estandarizaciones de Internet, Chrome y Firefox son los que reparten el bacalao, saltándoselas a gusto lo que digan los organismos oficiales, sabedores de que si como ha pasado con SPDY la industria lo acaba tomando casi como una estandarización, de facto acabará por transformarse en ella. Y esto mismo lo vivimos en su momento cuando IE y Netscape eran los gigantes de internet, y gustosos hacían lo que les venía en gana para marcar los cánones evolutivos de la web.

En fin, que me voy por las ramas… HTTP/2 viene con tres añadidos a considerar:

• Multiplexación de contenido: Me refiero a que HTTP/2 medio-soluciona uno de los principales problemas en arquitecturas cliente-servidor. Su escalabilidad. En un entorno cliente-servidor, conforme el número de clientes aumente se hace necesario servidor/es cada vez más potentes, lo que se traduce en mayor gasto de recursos (energético, digital, monetario). HTTP/2 ofrece la posibilidad de “empaquetar” peticiones de grupos de clientes en una misma, reduciendo drásticamente las peticiones al servidor, que tendrá que servir una vez para varios simultáneamente. Y digo que medio-soluciona porque tampoco es la panacea. No quiere decir con esto que el escalado deje de ser un problema en internet. Seguirá de hecho siéndolo, aunque al menos no con una curva tan pronunciada.
• Pre-almacenamiento: Un servidor podrá por HTTP/2 “informar” al cliente que ha actualizado alguno de los recursos almacenados por este para agilizar las comunicaciones. Y digo “informar”, con los guiones y todo, porque HTTP/2 no puede forzar su descarga, únicamente avisar de que hay algo nuevo. Si el cliente (en este caso, por ejemplo, el navegador) está configurado para hacer caso a una petición de este estilo antes que a su propio caché, el usuario podrá estar seguro de que está consumiendo el contenido actualizado, tal cual el servidor está a esta misma hora sirviendo. No me queda del todo claro qué papel (qué control, mejor dicho) tendrá el administrador de una web respecto a esto (o si dependerá a su vez de la configuración aplicada en el servidor), pero es de nuevo un punto medio entre las ventajas de un cacheado de recursos compartidos (habitualmente CSS, datos de formularios y páginas estáticas) en local (ya sabe, menor tiempo de carga) y el dinamismo de una web sin cacheado (cada vez descarga todo).
• Cifrado: La guinda del pastel. En su momento se barajaron varios supuestos sobre cómo gestionar las comunicaciones seguras en internet con el nuevo protocolo. O bien no habría cifrado, o bien se forzaba a que todo fuera cifrado, o bien un punto medio. Parece que lo que en un principio iba a ser la opción ganadora (todos protocolo seguro y listo) todavía no la veremos en acción. Eso sí, tanto Google como Mozilla (ya sabe, los que parten el bacalao…) han dejado claro que no implantarán HTTP/2 si este no permite el cifrado, así que incluso estandarizado las dudas siguen estando presentes.

Y ahora se preguntará porqué Nottingham es tan reacio a implantar por defecto conexiones TLS en HTTP/2, y le responderé que además del previsible gasto requerido por todos los actores (recuerde que TLS se basa en la confianza (y en el pago anual) que un servidor hace a una entidad certificadora para que esta demuestre inequívocamente (se supone) que la página o servicio que el servidor ofrece es el válido), entraña un verdadero quebradero de cabeza para todo el ecosistema alrededor de internet.