{"id":751,"date":"2013-07-14T23:20:23","date_gmt":"2013-07-15T05:20:23","guid":{"rendered":"http:\/\/www.lastdragon.net\/?p=751"},"modified":"2013-07-14T23:39:43","modified_gmt":"2013-07-15T05:39:43","slug":"spdy-el-nuevo-protocolo-para-sustituir-http","status":"publish","type":"post","link":"https:\/\/www.lastdragon.net\/?p=751","title":{"rendered":"SPDY el nuevo protocolo para sustituir HTTP"},"content":{"rendered":"

SPDY es un nuevo protocolo que pretende ser sustituto al HTTP o convertirse en su nueva generaci\u00f3n 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.<\/p>\n

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.<\/p>\n

Hasta hoy ha funcionado muy bien el HTTP \u00bfpor que habr\u00eda necesidad de sustituirlo?<\/p>\n

El HTTP original estaba basado en una conexi\u00f3n por cada objeto en la p\u00e1gina WEB lo que lo hac\u00eda ineficiente en los sitios modernos que empezaban a tener muchas im\u00e1genes peque\u00f1as para los temas y texturas. Por ejemplo una pagina WEB con 5 im\u00e1genes le daba una carga de trabajo al servidor de 6 conexiones.<\/p>\n

1 Conexi\u00f3n para la pagina WEB HTML
\n5 para cada imagen llamada mediante la etiqueta IMG SRC<\/p>\n

Si que por cada imagen o por cada elemento que se insertara en la p\u00e1gina WEB el cliente lanza una nueva conexi\u00f3n al servidor abriendo un SOCKET nuevo por cada conexi\u00f3n y cerr\u00e1ndolo despu\u00e9s de hacer la descarga. Si recuerdas el proceso para realizar una conexi\u00f3n TCP, sabes que debes tener al menos 3 pasos, los 3 saludos, antes de poder transmitir algo. Imag\u00ednate 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\u00edan saludarse f\u00e1cilmente unas 500 o 600 veces por usuario<\/p>\n

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\u00edan existir, son demasiadas peticiones a un servidor WEB cuando un sitio tiene AJAX ser\u00eda casi aplicarle un DoS sin la intenci\u00f3n de hacerlo, el AJAX sobre el HTTP original funcionaria para paginas con bajo tr\u00e1fico y pocas visitas, pero dar\u00eda miedo imaginar la cantidad de conexi\u00f3n que se tendr\u00edan que realizar en sitios como facebook, twitter por millones de usuarios simult\u00e1neos, simplemente no se puede con el HTTP tradicional y es ah\u00ed donde entra keep alive<\/p>\n

Keep Alive<\/strong><\/p>\n

keep alive hace una conexi\u00f3n como lo har\u00eda el HTTP original, pero por ah\u00ed mismo pasan todos los objetos de la pagina, de forma que en el ejemplo de una p\u00e1gina con 6 im\u00e1genes, solo se abre una conexi\u00f3n para el HTML y para cada imagen, por ah\u00ed pasan todos los archivos, los sitios con AJAX son los m\u00e1s beneficiados, ya que todas las peticiones que hace AJAX pasan por una misma conexi\u00f3n<\/p>\n

Si el problema lo resuelve Keep Alive \u00bf Para qu\u00e9 se requiere SPDY ?<\/p>\n

Keep Alive b\u00e1sicamente es el HTTP com\u00fan y corriente con la \u00fanica ventaja de mantener viva la conexi\u00f3n para todas las peticiones del cliente, sin embargo cada petici\u00f3n del cliente inyecta y recibe en la conexi\u00f3n una cantidad indeseables de metadatos como el USER-AGENT, si la pagina es \u201ccacheable\u201d o no y otros, si sabes usar el m\u00e9todo HEAD del HTTP podr\u00edas obtener estos metadatos de cualquier servidor WEB. Donde m\u00e1s pesa toda esa burocracia de metadatos es en las conexiones para archivos peque\u00f1os como iconos o peque\u00f1os gr\u00e1ficos de botones en una pagina WEB<\/p>\n

Ejemplo:<\/p>\n

telnet lastdragon.net 80
\n.
\nConnected to lastdragon.net.
\nEscape character is ‘^]’.
\nHEAD \/ HTTP\/1.0<\/p>\n

HTTP\/1.1 200 OK
\nDate: Sun, 14 Jul 2013 20:36:49 GMT
\nServer: Apache\/2.4.2 (GNU\/Linux 64 (Last Dragon) 2012) PHP\/5.4.3
\nX-Powered-By: PHP\/5.4.3
\nSet-Cookie: PHPSESSID=fm14q095ltsbj6kj0tel4v1340; path=\/
\nExpires: Thu, 19 Nov 1981 08:52:00 GMT
\nCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
\nPragma: no-cache
\nX-Pingback: https:\/\/www.lastdragon.net\/xmlrpc.php
\nContent-Type: text\/html; charset=UTF-8<\/p>\n

Connection closed by foreign host.<\/p><\/blockquote>\n

SPDY<\/strong><\/p>\n

SPDY se pronuncia SPEEDY o RAPIDITO en espa\u00f1ol, b\u00e1sicamente 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\u00f3n 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\u00e1tico, los humanos no podr\u00e1n entender esos metadatos, ser\u00e1 informaci\u00f3n \u00fatil solo para la computadora<\/p>\n

Aunque vea poco el ahorro de los metadatos, cuando se trata de sitios con millones de consultas simultaneas, ese peque\u00f1o ahorro tiene sentido.<\/p>\n

SPDY PUSH<\/strong><\/p>\n

En estos momentos los servidores WEB nunca se comunican con el cliente en primer lugar, los servidores WEB siempre esperan una conexi\u00f3n e interact\u00faan con ella, el cliente debe estar ejecutando un JavaScript en su pagina WEB para simular que esta recibiendo informaci\u00f3n del servidor, pero en realidad esos JavaScript solo estar\u00e1n 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\u00f3n al cliente cuando la informaci\u00f3n este disponible, ahorr\u00e1ndose tener que estar conect\u00e1ndose una y otra vez al servidor WEB en busca de informaci\u00f3n.<\/p>\n

SPDY SSL<\/strong><\/p>\n

SPDY solo se ejecuta sobre SSL y en el caso de los sistemas tipo Unix, requiere de un OpenSSL al menos en la versi\u00f3n 1.0.1, la mayor\u00eda de los sistemas van en la 1.0.0 o incluso anterior.<\/p>\n

El que se ejecute sobre SSL evita que la conexi\u00f3n pueda ser espiada con sniffers de forma que los formularios y las sesiones est\u00e1n m\u00e1s seguras, algo de lo que carece el HTTP actual. Sin embargo hay un costo alto. Al ser una conexi\u00f3n 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.<\/p>\n

Laboratorio SDPY<\/strong><\/p>\n

Usando servidores de las mismas caracter\u00edsticas hice unas pruebas de Keep Alive VS SPDY<\/p>\n

SPDY gana cuando se trata de archivos reales y p\u00e1ginas web est\u00e1ticas, cuando una p\u00e1gina es din\u00e1mica por ejemplo usando PHP tiene problemas, a veces las paginas no cargan correctamente y deja elementos sin cargar.
\nEl navegador que m\u00e1s sufre con SPDY y PHP es Chrome, lo cual es muy extra\u00f1o ya que SPDY es impulsado por Google y por lo tanto Chrome deber\u00eda ser la mejor implementaci\u00f3n de navegador con soporte a SPDY<\/p>\n

Video demostraci\u00f3n del efecto de SPDY VS Keep Alive<\/p>\n

\"SPDY
\nVer mas grande<\/a><\/p>\n

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.<\/p>\n

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.<\/p>\n