SPDY es un nuevo protocolo que pretende ser sustituto al HTTP o convertirse en su nueva generación algo asi como HTTP2 mientras corrige las debilidades del protocolo actual que es la misma que muchos otros protocolos como el SMTP , POP, FTP, IRC, HTTP entre otros.
La debilidad es simple, todos estos protocolo no son binarios, son protocolos basados en texto que cuando tienen que pasar datos binarios estos datos son convertidos a BASE64, al ser simple texto puede ser espiado por sniffers.
Hasta hoy ha funcionado muy bien el HTTP ¿por que habría necesidad de sustituirlo?
El HTTP original estaba basado en una conexión por cada objeto en la página WEB lo que lo hacía ineficiente en los sitios modernos que empezaban a tener muchas imágenes pequeñas para los temas y texturas. Por ejemplo una pagina WEB con 5 imágenes le daba una carga de trabajo al servidor de 6 conexiones.
1 Conexión para la pagina WEB HTML
5 para cada imagen llamada mediante la etiqueta IMG SRC
Si que por cada imagen o por cada elemento que se insertara en la página WEB el cliente lanza una nueva conexión al servidor abriendo un SOCKET nuevo por cada conexión y cerrándolo después de hacer la descarga. Si recuerdas el proceso para realizar una conexión TCP, sabes que debes tener al menos 3 pasos, los 3 saludos, antes de poder transmitir algo. Imagínate al cliente y el servidor haciendo los 3 saludos por cada una de las 6 conexiones y si son mas objetos en la pagina podrían saludarse fácilmente unas 500 o 600 veces por usuario
El protocolo ya no es asi, se le agrego un parche llamado keep alive, sin el keep alive las paginas con AJAX simplemente no podrían existir, son demasiadas peticiones a un servidor WEB cuando un sitio tiene AJAX sería casi aplicarle un DoS sin la intención de hacerlo, el AJAX sobre el HTTP original funcionaria para paginas con bajo tráfico y pocas visitas, pero daría miedo imaginar la cantidad de conexión que se tendrían que realizar en sitios como facebook, twitter por millones de usuarios simultáneos, simplemente no se puede con el HTTP tradicional y es ahí donde entra keep alive
Keep Alive
keep alive hace una conexión como lo haría el HTTP original, pero por ahí mismo pasan todos los objetos de la pagina, de forma que en el ejemplo de una página con 6 imágenes, solo se abre una conexión para el HTML y para cada imagen, por ahí pasan todos los archivos, los sitios con AJAX son los más beneficiados, ya que todas las peticiones que hace AJAX pasan por una misma conexión
Si el problema lo resuelve Keep Alive ¿ Para qué se requiere SPDY ?
Keep Alive básicamente es el HTTP común y corriente con la única ventaja de mantener viva la conexión para todas las peticiones del cliente, sin embargo cada petición del cliente inyecta y recibe en la conexión una cantidad indeseables de metadatos como el USER-AGENT, si la pagina es “cacheable” o no y otros, si sabes usar el método HEAD del HTTP podrías obtener estos metadatos de cualquier servidor WEB. Donde más pesa toda esa burocracia de metadatos es en las conexiones para archivos pequeños como iconos o pequeños gráficos de botones en una pagina WEB
Ejemplo:
telnet lastdragon.net 80
.
Connected to lastdragon.net.
Escape character is ‘^]’.
HEAD / HTTP/1.0HTTP/1.1 200 OK
Date: Sun, 14 Jul 2013 20:36:49 GMT
Server: Apache/2.4.2 (GNU/Linux 64 (Last Dragon) 2012) PHP/5.4.3
X-Powered-By: PHP/5.4.3
Set-Cookie: PHPSESSID=fm14q095ltsbj6kj0tel4v1340; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: https://www.lastdragon.net/xmlrpc.php
Content-Type: text/html; charset=UTF-8Connection closed by foreign host.
SPDY
SPDY se pronuncia SPEEDY o RAPIDITO en español, básicamente es un Keep Alive sobre SSL con metadatos en binario, de tal forma que los aproximadamente 500 bytes por cada archivo sean reducidos a un par de bytes pasando solo información en bits. Los metadatos tienen la mala costumbre de estar construidos en ASCII por lo que pasar metadatos en binario es un alivio para cualquier sistema informático, los humanos no podrán entender esos metadatos, será información útil solo para la computadora
Aunque vea poco el ahorro de los metadatos, cuando se trata de sitios con millones de consultas simultaneas, ese pequeño ahorro tiene sentido.
SPDY PUSH
En estos momentos los servidores WEB nunca se comunican con el cliente en primer lugar, los servidores WEB siempre esperan una conexión e interactúan con ella, el cliente debe estar ejecutando un JavaScript en su pagina WEB para simular que esta recibiendo información del servidor, pero en realidad esos JavaScript solo estarán consultando una y otra vez al servidor WEB por cambios gastando con eso el ancho de banda de cada consulta. SPDY puede por fin enviar información al cliente cuando la información este disponible, ahorrándose tener que estar conectándose una y otra vez al servidor WEB en busca de información.
SPDY SSL
SPDY solo se ejecuta sobre SSL y en el caso de los sistemas tipo Unix, requiere de un OpenSSL al menos en la versión 1.0.1, la mayoría de los sistemas van en la 1.0.0 o incluso anterior.
El que se ejecute sobre SSL evita que la conexión pueda ser espiada con sniffers de forma que los formularios y las sesiones están más seguras, algo de lo que carece el HTTP actual. Sin embargo hay un costo alto. Al ser una conexión cifrada que no puede ser intervenida significa que tampoco puede ser cacheada, por lo que no se puede poner un proxy intermedio que ayude a economizar el ancho de banda.
Laboratorio SDPY
Usando servidores de las mismas características hice unas pruebas de Keep Alive VS SPDY
SPDY gana cuando se trata de archivos reales y páginas web estáticas, cuando una página es dinámica por ejemplo usando PHP tiene problemas, a veces las paginas no cargan correctamente y deja elementos sin cargar.
El navegador que más sufre con SPDY y PHP es Chrome, lo cual es muy extraño ya que SPDY es impulsado por Google y por lo tanto Chrome debería ser la mejor implementación de navegador con soporte a SPDY
Video demostración del efecto de SPDY VS Keep Alive
Keep Alive siempre sale a la izquierda del video, SPDY siempre a la derecha y se puede confirmar ya que el URL usa SSL por lo tanto HTTPS.
En las pruebas siempre inicio primero a Keep Alive para darle ventaja aunque al final le gana SPDY, en el video se puede ver que cliente navegador de internet termina primero de cargar la pagina WEB.
Básicamente puros sitios sociales donde la carga de trabajo es intensa. Sabiendo esto. Sabes que la velocidad de Chrome es una trampa. Porque seguramente la mayoría de personas que han dicho que Chrome es mas rápido han probado estas pseudo velocidad en Facebook o Twitter, donde Chrome soporta SPDY, si Chrome hace conexiones Keep Alive tiene el mismo rendimiento que Firefox
Firefox lo soporta en sus últimas versiones y posiblemente Internet Explorer en su versión 11