Los responsables del navegador Chromium proponen la adopción de un nuevo protocolo llamado spdy (por SPeeDY, veloz) para sustituir al omnipresente HTTP y optimizado para una carga rápida y óptima de contenidos. En sus experimentos han logrado mejoras de hasta un 64% en el tiempo de carga. HTTP es un protocolo a nivel de aplicación que funciona sobre el protocolo a nivel de red TCP. Con 10 años de historia, mejorar la latencia no era precisamente una de las preocupaciones de sus diseñadores. Entre sus limitaciones:

• Una sola petición por conexión, suplido en parte por el HTTP pipelining o conexiones múltiples en el navegador
• Peticiones iniciadas exclusivamente por el cliente, aunque el servidor tenga información que deba ser recibida por el cliente, no puede avisar a éste
• Las cabeceras de petición y respuesta no se comprimen a pesar de alcanzar los 2KB fácilmente por las cookies, lo que afecta sobre todo a las líneas lentas
• Cabeceras redundantes se repiten en cada petición debido a que para el servidor el cliente siempre es "nuevo"
• La compresión de datos es opcional y no obligatoria

Otros enfoques han intentado resolver esas carencias, por ejemplo, intentando optimizar el protocolo TCP, pese a los problemas que podría generar en la infraestructura existente. spdy, por su parte, persigue los siguientes objetivos:

• Reducir el 50% en los tiempos de carga
• Aprovechar el protocolo TCP existente para evitar requerir una infraestructura de red distinta a la actual
• Evitar modificaciones en el contenido existente (HTML)
• Conseguir varias peticiones concurrentes sobre una misma sesión TCP
• Comprimir las cabeceras y reducir campos innecesarios
• Simplificar el protocolo para facilitar su implementación y a la vez optimizarlo
• Mantener SSL como protocolo subyacente para aumentar la seguridad a pesar del incremento en latencia
• Permitir que el servidor envíe información al cliente cuando lo desee

Características

spdy permite crear una conexión TCP con el servidor sobre la que una serie de flujos concurrentes y entrelazados permiten una comunicación bidireccional (desde el cliente o desde el servidor).

• Flujos multiplexados sobre una sola conexión TCP. Al no necesitar múltiples conexiones TCP, con lo que ello implica, y al estar mejor aprovechada ésta con mayor densidad de información, la eficiencia es mucho mayor.
• La priorización de peticiones permite que el cliente identifique la información más importante y evitar que contenido de baja prioridad bloquee al resto.
• Compresión de las cabeceras HTTP
• El servidor puede enviar información al cliente mediante una cabecera X-Associated-Content que informa al cliente de nueva información disponible antes de que el éste la solicite.
• El servidor usa la cabecera X-Subresources para sugerir al cliente que solicite ciertos recursos aunque no se los envíe directamente al cliente.

Más información en el borrador de la especificación, en este artículo de Alex Russell (Dojo Toolkit) y en el artículo introductorio. En él se explica la implementación de un servidor y un cliente Chrome modificado para realizar las pruebas del protocolo con los resultados indicados anteriormente, y que son expuestos con detalle.