Hace poco, Google lanzó un nuevo protocolo para internet al que bautizó SPDY (por “Speedy”), en un esfuerzo para hacer a la web más rápida. Pero, ¿hacia dónde va Google con esto?
Cuando se diseñó el protocolo HTTP, dando inicio a lo que hoy conocemos como “la web”, el tipo de contenido que se pensaba publicar era muy distinto al que se usa hoy en día, y según Google, ya es hora de pensar en un nuevo protocolo más acorde con los tiempos.
Google espera que poco a poco la comunidad de código abierto comience a contribuir con ideas, retroalimentación de código y resultados de pruebas. Mientras tanto, ya han habilitado SPDY en Chrome y en un servidor web en donde han logrado reducir hasta en un 64% el tiempo de carga de páginas usando este nuevo protocolo en vez de HTTP.
¿Qué tiene de malo HTTP?
El principal problema de HTTP es algo que se conoce como latencia, y es el tiempo en que el sistema en general está esperando a que algo suceda, por ejemplo cuando el cliente está esperando a que el servidor responda.
El efecto de la latencia no es muy conocido y casi toda la gente asocia la rapidez sólo con ancho de banda. Para que se hagan una idea, tener una alta latencia y un gran ancho de banda equivale a viajar en avión: El tiempo ganado en viajar se compensa con el tiempo perdido en esperar que el avión salga al inicio del viaje, más el tiempo perdido en recoger el equipaje al llegar a destino, sin mencionar el tiempo necesario para entrar y salir del aeropuerto cuando se encuentra fuera de la ciudad. Para viajes cortos, el tiempo de espera puede ser tan grande como el tiempo de viaje, y para viajes demasiado cortos, es mejor un taxi por muy rápido que sea el avión.
Para el caso de protocolos como HTTP, una gran transferencia de datos es mejor que varias transferencias pequeñas, ya que en el primer caso tenemos sólo una espera y una larga transferencia de datos, pero cuando hay varias transferencias se producen múltiples esperas para una transferencia de pocos datos: por muy rápida que sea esa transferencia, la espera será mucho tiempo perdido.
HTTP es simple y elegante, pero lento
El protocolo HTTP es bastante simple y elegante, muy fácil de implementar para un desarrollador promedio, pero tiene el inconveniente de ser lento debido a su latencia. Estas son algunas de las razones que expone Google para su lentitud:
Sólo una petición por conexión: cuando el navegador (o agente web) quiere obtener un recurso desde el servidor web, por ejemplo una imagen, un icono, un sonido o una página web, debe realizar una petición al servidor. Por cada conexión TCP/IP hacia el servidor se puede realizar sólo una petición a la vez, esto quiere decir que el agente web debe esperar a que el servidor responda para iniciar una segunda petición. Desde el 2008 los navegadores abren unas seis conexiones simultáneas por dominio, pero en cada conexión persiste en problema de las esperas.
Sólo el cliente puede iniciar una petición: en HTTP no es posible que el servidor envíe o informe algo al cliente si éste no ha realizado una petición, por lo que el servidor siempre está esperando a que el cliente pida los recursos que necesita. Por ejemplo un webmail no puede notificar al cliente sobre un nuevo correo sin que éste haya preguntado primero.
Información adicional: por cada petición y respuesta se debe agregar información adicional (encabezados) que aumenta la cantidad de datos a enviar. Aunque parezca poco, hay que considerar que el ancho de banda de subida generalmente es menor. Por otra parte, HTTP y los servidores web obligan a enviar información que generalmente no cambia, como la identificación del browser o agente web (User-Agent) o el nombre del dominio al que se quiere acceder en el servidor web.
La compresión de datos es opcional: como una forma de simplificar la construcción de clientes y servidores HTTP se estableció que la compresión de datos sería opcional. Es decir, sólo se utiliza si ambos agentes la implementan y están de acuerdo. Por ejemplo el texto tiene una tasa de compresión muy alta, y enviarlo sin comprimir es una gran pérdida de recursos.
Hacia donde apunta SPDY
SPDY apunta a mejorar la web con un mínimo de cambios a lo que ya existe. Por ejemplo, las aplicaciones web pueden mantenerse igual y el hardware de red es totalmente compatible, sólo es necesario implementar el protocolo en los clientes y servidores web. Los cambios se enfocan en tomar HTTP y aplicar lo que sea necesario para reducir la latencia y mejorar además el uso de ancho de banda.
Google dice que estas son sus metas técnicas:
Permitir múltiples peticiones HTTP en una sola conexión (sesión TCP): de esta forma no sería necesario esperar a que llegue un recurso para solicitar el siguiente.
Usar compresión en los encabezados, ya que se trata sólo de texto y tal como dijimos, la tasa de compresión es muy alta. Además se eliminarán los encabezados redundantes. En las pruebas realizadas, esto ha reducido en más del 80% la cantidad de datos a transmitir por encabezados.
Definir un protocolo fácil de implementar y eficiente por el lado del servidor. Se espera reducir la complejidad del HTTP eliminado los casos de borde, es decir, aquellos casos especiales que complican la implementación, y definiendo un formato fácil de procesar.
Usar SSL como protocolo subyacente. Esto quiere decir que todas las conexiones serán seguras. Además de proveer seguridad, la idea es que los proxies actuales no interfieran con la comunicación via SPDY.
Permitir que el servidor inicie la comunicación, enviando datos hacia el cliente cuando sea posible. Para esto se proponen dos mecanismos, uno es el envío de datos al browser en forma adicional al contenido que ya está pidiendo, y la otra es darle una pista al browser para que pida contenido adicional, indicándole qué debe pedir.
Cómo probarlo en casa
Desafortunadamente, aún no es posible probar la solución completa. Si bien Google ha publicado una versión de Chrome con SPDY, no ha publicado aún el servidor web compatible con SPDY.
Hasta el momento Google ha probado con unos 25 sitios seleccionados entre sus “Top100″ simulando una conexión de red casera. En estas pruebas han visto una reducción de entre un 27% a un 60% en tiempo de descarga por página usando conexiones sin SSL y desde un 39% a un 55% usando conexiones SSL.
Este protocolo se ve bastante prometedor y aunque las cifras se ven buenas, se sabe que aún hay espacio para mejorar, por ejemplo en el servidor de pruebas no han hecho todo lo que se cree que se puede hacer para que tenga un comportamiento más astuto.
Vía_fayerwayer.com
Fuente: http://dev.chromium.org/spdy/spdy-whitepaper
El 10 de Noviembre del año 1983 el estudiante Fred Cohen, graduado de la Universidad de California del Sur, realizó una demostración de una prueba de concepto consistente en un programa que lograba reproducirse entre computadores, logrando tener acceso a ellos sin intervención por parte de los usuarios.
Comentarios recientes