Imagínese por un momento que el gobierno de su país decide levantar todo el sistema de carreteras para instalar un nuevo pavimentado más eficiente y duradero.
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.
Porque vuelvo al inicio del artículo. Que para el usuario final, el paso del HTTP al HTTP/2 es abstracto y directo, pero tanto para servidores, como para cortafuegos, antivirus, sistemas operativos, navegadores, y en definitiva, cualquier componente (hardware/software) conectado a internet, representa un verdadero cambio de paradigma, con la necesaria actualización de todo lo que hasta el día de hoy se consideraba estándar en la comunicación cliente-servidor.
Bienvenido al futuro de internet :).
Hola,
Aquí hay una serie de incoherencias bastante grandes:
1) Los actores que iban implementando HTTP2/SPDY no eran sólo Google y Firefox, si no que Facebook, Twitter y otras grandes empresas estaban implementándolo en sus servidores porque mejoraban sustancialmente el uso de sus recursos.
Puedes mirar aquí: https://github.com/http2/http2-spec/wiki/Implementations
2) Los estándares se mueven por WG del IETF, cuando hay consenso, se manda un RFC. Allí alguien llega, manda un posible estándar, y el resto discuten. En abierto.
3) los sistemas operativos y los cacharros conectados a internet, a menos que hagan uso de HTTP para sus comunicaciones, se la repanpinfla. Lo que tienen los SO es la pila TCP/IP, y llega hasta transporte, TCP. Lo que hagan luego las aplicaciones con lo que hay dentro de esos paquetes TCP, es cosa de ellos. Así que al SO le da igual si dentro de un TCP va HTTP1/1, HTTP2 o el protocolo que yo me haya inventado con mis colegas.
Por supuesto Carlos, SPDY fue defendido por Google, pero está claro que lo han implementado muchos otros. Si hubiera sido la Microsoft de ahora quizás no hubiera sido tal cual (aunque la tecnología lo mereciera), pero es lo que hay al tener peso suficiente para ofrecer tecnologías con más presión. Y si ha llegado a ser estándar no es únicamente porque Google tenga un papel decisivo en esto, sino porque en verdad es mejor que lo que había.
Los estándares se eligen en abierto. Por supuesto. Es más, seas quien seas (gigante de internet o pequeña organización sin ánimo de lucro), solo puedes tener un representante. Pero cuando Google y Mozilla dominan el panorama tecnológico, y por ende, la tecnología que usamos para construir las webs, es normal que la comunidad de desarrolladores implemente features que son solo compatibles con estos, y la presión hace el resto. Si más de la mitad de los consumidores ya usan esta tecnología ¿qué puede hacer IETF más que estandarizarlo? Y ojo, que es bueno y malo. Porque mantiene la evolución lógica de las tecnologías de internet (ahora es Google y Mozilla, antes fue Microsoft y Netscape, mañana serán quien sean…). Los que pueden no siguen las reglas, y con ello consiguen agenciarse tantos decisivos para el futuro de las comunicaciones digitales.
Y totalmente de acuerdo con el tercer punto. Está claro que me refiero a todo lo que esté conectado por HTTP. El cambio es en el protocolo de comunicación HTTP, y por tanto afecta únicamente a aquel que lo utilice. Si no lo utiliza (si no tiene contacto directo con el protocolo), no le afecta.
Buen aporte.
¿El estándar aprobado prevé algo similar al “SPDY Proxy” que comentaba Chema Alonso en este artículo?
http://www.elladodelmal.com/2014/12/google-o-el-garante-de-la-privacidad.html
hoy en día, no se tiene constancia de nada por el estilo. Pero tanto Google como Firefox están metiendo presión para que llegue. Lo comentábamos hace unas horas por Google+. El HTTP/2 se ha quedado un poco flojo…