Bajo este nombre de entrada con tanta siglas (prometo explicarlas una por una), se esconde un cambio más que necesario en el modelo de comunicación entre cliente/servidor de internet.
La IETF (Internet Engineering Task Force).
Es la organización sin ánimo de lucro detrás de la normalización de los estándares de arquitectura de internet. Dicho de otra manera, son el colectivo que decide qué protocolos se acaban usando y cuales no, y por tanto, el desarrollo de la red de redes depende enteramente de ellos. La IETF es la encargada de marcar los RFC (Request for Comments), unos documentos necesarios para que un proyecto informático (ya sea un protocolo, una arquitectura, una aplicación) salga adelante. En él se recogen los aspectos fundamentales sobre su uso e implementación, de cara a que si en un futuro, ese proyecto acaba llevándose a cabo, exista ya una fuente de información suficiente para empezar a trabajar en ello. Tenéis ejemplos de RFC en el que en su día se hizo sobre el protocolo IP (RFC 791) o el del HTTP que hemos estado usando hasta ahora (RFC 2616, escrito por Tim Berners-Lee).
HTTP o Hypertext Transfer Protocol es el protocolo que gestiona las conexiones entre cliente/servidor cuando accedemos a una web, por ejemplo. El RFC que ha estado vigente hasta ahora (o más bien los RFC) normalizaban un tipo de conexión entre protocolo TCP/IP que ha servido relativamente bien hasta el auge de la web dinámica y la explosión móvil. Sin embargo, la aparición de diversas conexiones continuas (actualmente cada petición se abre y se cierra, cuando por lo general, estamos consultando información dinámica cada instante) o la imposibilidad de re-usar conexiones para reducir los tiempos de carga en teléfonos móviles, hace necesaria la creación de un nuevo estándar actualizado a los usos actuales.
Y aquí es donde entra el dichoso SPDY («Speedy» en inglés), un protocolo ajeno a HTTP (creación de Google), pero totalmente compatible con sus estándares, que simplifica algunas deficiencias del segundo, y asegura hasta el 64% más de velocidad en la navegación mediante empaquetado de cabeceras, reutilización de conexiones y establecimiento de conexiones dinámicas.
Para que SPDY funcione, es necesario que tanto el cliente como el servidor pueda manejar el protocolo. Por parte del cliente, ya la mayoría de los navegadores «recomendados» lo tienen (Chrome, Firefox, Opera,…). Por parte del cliente, existen diferentes extensiones según el lenguaje usado (Apache, Python, Java,…).
El modelo (porque aún no podemos hablar de RFC) tendrá que pasar de mano en mano hasta que se decida un estándar para él. En la mesa hay varios candidatos, entre los que destaca SPDY Speed+Mobility de Microsoft, que asegura mejoras aún superiores en teléfonos móviles, gracias al empaquetado de archivos.
De cara al desarrollador, hay algunos cambios, aunque por lo general, se puede decir que no va a suponer un cambio en los lenguajes, sino más bien en los hábitos actuales para reducir la latencia, como son los sprites de imágenes o el unificar CSS y javascript bajo un mismo archivo, algo que ya no será necesario.
Y de cara al usuario, como es de esperar, son todo bondades. Más rapidez en la navegación a nivel de carga, lo que reduce una barbaridad el tiempo general para establecer conexión y mantenerla, por lo que a voz de pronto, con el próximo HTTP2.0 las webs dinámicas se actualizarán casi a tiempo real.
