SPDY, el protocolo de Google

Iván Bautista Moreno

Ingeniería de protocolos. Optativa 3ºI.T.T esp. telemática

E.P.S Linares

Índice Iván Bautista Moreno

Índice

1. Introducción 1

2. SPDY: un protocolo experimental de una red más rápida 12.1. Inicio del proyecto SPDY . . . . . . . . . . . . . . . . . . . . . . . . . 12.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3. Protocolo SPDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4. El diseño de SPDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.5. Características del SPDY . . . . . . . . . . . . . . . . . . . . . . . . . 42.6. ¡SPDY & HTTP! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.6.1. La solicitud (resquest) . . . . . . . . . . . . . . . . . . . . . . 52.6.2. La respuesta (response) . . . . . . . . . . . . . . . . . . . . . . 62.6.3. Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. SPDY Proxy 7

Referencias 8

SPDY, el protocolo de Google II

Iván Bautista Moreno

1. IntroducciónGoogle Inc. es la empresa propietaria de la marca Google, cuyo principal producto

es el motor de búsqueda de contenido en Internet del mismo nombre. Dicho motornació como resultado de la tesis doctoral de Larry Page y Sergey Brin (dos estudian-tes de doctorado en Ciencias de la Computación de la Universidad de Stanford) paramejorar las búsquedas en Internet, aunque su principal herramienta es el buscador,poco a poco esta fue mejorando y adquiriendo diversas empresas para aumentar suárea de trabajo de tal forma que actualmente es una de las mayores compañías conun altísimo capital. Tal explosión de esta compañía se debe entre otras cosas:

Adquisición Youtube. (2006)

Integración de página principal en el navegador Mozilla.

Adquisiciones de DoubleClick, dedicada a la publicidad y Panoramio, sitio deexhibición de fotografías. (2007)

Adquisición de Motorola Mobility.

Aparte de los innumerables servicios que ofrece en la actualidad.

2. SPDY: un protocolo experimental de una redmás rápida

2.1. Inicio del proyecto SPDYComo parte de la iniciativa "vamos a hacer la web más rápida" , se está experimen-

tando con protocolos alternativos para ayudar a reducir la latencia de las páginasweb. Uno de estos experimentos es SPDY (pronunciado "Speedy"), un protocolo decapa de aplicación complementario al protocolo HTTP, que funciona sobre TCP/IPpara el transporte de contenidos a través de la web, diseñado específicamente parauna latencia mínima.

Figura 1: Analogía capa OSI

SPDY, el protocolo de Google 1

2.2 Antecedentes Iván Bautista Moreno

2.2. AntecedentesHoy en día, HTTP y TCP son los protocolos por excelencia de la web. TCP es

el protocolo genérico de transporte fiable, que proporciona una entrega garantizada,la supresión de duplicados, la entrega en orden, control de flujo, para evitar lacongestión y las características de otros medios de transporte. HTTP es el protocolode nivel de aplicación que proporciona peticiones básicas de solicitud-respuesta. Pordesgracia, HTTP no fue diseñado especialmente para la latencia y las páginas webde transmisión de hoy día son significativamente diferentes de las páginas web dehace 10 años, las mejoras de la demanda de HTTP no podía haber sido anticipadocuando HTTP fue desarrollado por ello ahora se busca una solución que permitauna latencia mucho menor al cargar estas páginas.Algunas de las características de HTTP que inhiben un rendimiento óptimo son:

1. Única solicitud por cada conexión. HTTP sólo puede obtener un recursoa la vez debido a que los servidores tienen un retraso de 500 ms que impide lareutilización del canal TCP para solicitudes adicionales..

2. Exclusivamente iniciada por el cliente solicite. En HTTP, sólo el clien-te puede iniciar una solicitud. Si el servidor sabe que el cliente necesita un re-curso, no tiene ningún mecanismo para informar al cliente y en su lugar debeesperar para recibir una solicitud de recursos por parte del cliente.

3. Solicitud y las cabeceras de respuesta sin comprimir. Las cabecerasde las solicitudes de hoy en día varían en torno a un tamaño de 200 bytes amás de 2 KB.

4. Cabeceras redundantes. Envío repetido de cabeceras.

5. Compresión de datos opcional. HTTP utiliza codificación opcional decompresión de datos. El contenido siempre debe ser enviado en un formatocomprimido.

SPDY no es la única investigación para hacer más rápido HTTP, ha habido otraspropuestas sobre todo a nivel de la capa de transporte o de sesión como pueden ser:

Stream Transmission Control Protocol (SCTP), un protocolo de capade transporte para sustituir a TCP, que proporciona flujos multiplexados y elcontrol de flujo consciente de la congestión.

HTTP a través de SCTP, una propuesta para el funcionamiento de HTTPa través de SCTP.

MUX y SMUX protocolos de capa intermedia que permiten la multiplexa-ción de los flujos.

HTTP Speed+Mobility por parte de Microsoft a partir del SPDY de Goo-gle. (Ver este artículo)

SPDY, el protocolo de Google 2

2.3 Protocolo SPDY Iván Bautista Moreno

2.3. Protocolo SPDYSPDY es un protocolo capaz de optimizar las comunicaciones HTTP con una

mejora de hasta el 64% en carga de páginas. No sustituye a HTTP sino que deforma transparente lo complementa, sin que los usuarios se den cuenta, actualmentesólo Chrome y Firefox 11 o superior lo incorporan.

Figura 2: Optimización SPDY vS. HTTP

Las motivaciones que han llevado a la definición de este protocolo se basan en lalatencia que experimentamos entre peticiones usando HTTP ya que las conexionesse abren y se cierran por petición. El cliente siempre realiza la petición inicial, porlo que el servidor sólo espera la llegada de peticiones.El proyecto SPDY define e implementa un protocolo de capa de aplicación para la

web lo que reduce enormemente la latencia. Los objetivos de alto nivel para SPDYson los siguientes:

Reducción del 50% en el tiempo de carga de página.

Minimizar la complejidad de la implementación. SPDY utiliza TCP como capade transporte subyacente, por lo que no requiere cambios en la infraestructurade red existente.

Los únicos cambios necesarios para apoyar SPDY se encuentran en el agentede usuario cliente y el servidor de aplicaciones web.

Reunir ideas afines a las partes interesadas en la exploración de protocoloscomo una forma de resolver el problema de latencia.

Algunos de los objetivos técnicos específicos son:

SPDY, el protocolo de Google 3

2.4 El diseño de SPDY Iván Bautista Moreno

Permitir muchas solicitudes simultáneas HTTP para ejecutar a través de unasola sesión TCP.

Reducir el ancho de banda utilizado actualmente por HTTP mediante la com-presión de los encabezados y la eliminación de los encabezados innecesarios.

Definir un protocolo que es fácil de implementar y eficiente en el servidor.Esperando reducir la complejidad de HTTP mediante la reducción de casos deuso y definir fácilmente analizable formatos de mensaje.

Para que SSL el protocolo de transporte subyacente, para una mejor seguridady compatibilidad con la infraestructura de red existente. Aunque SSL se in-troduce una sanción de latencia, creemos que el futuro a largo plazo de la reddepende de una conexión de red segura. Además, el uso de SSL es necesariopara asegurar que la comunicación a través de proxys existentes no está roto.

Habilita al servidor para iniciar las comunicaciones con el cliente y enviar datosal cliente siempre que sea posible.

2.4. El diseño de SPDYSPDY añade una capa de sesión en la cima de SSL que permite múltiples descargas

simultáneas, entrelazando a través de una conexión TCP.

Figura 3: Diseño de capas

El habitual formate de peticiones del tipo GET y POST siguen siendo los mismos,sin embargo, SPDY especifica un formato de trama nueva para codificar y transmitirlos datos a través del cable. Donde las peticiones pueden ser iniciadas por el clientey el servidor.

2.5. Características del SPDYFlujos multiplexados SPDY, permite un número ilimitado de descargassimultáneas a través de una conexión TCP. Dado que las solicitudes se inter-calan en un solo canal, la eficiencia de los TCP es mucho mayor: un menornúmero de conexiones de red es necesario hacer, y menos, pero más densamentepoblado, los paquetes se emiten.

SPDY, el protocolo de Google 4

2.6 ¡SPDY & HTTP! Iván Bautista Moreno

Solicitudes prioritarias , aunque un número ilimitado de corrientes para-lelas resolver el problema de la serialización, que introducir un concepto nuevo:si el ancho de banda en el canal se ve limitada, el cliente puede bloquear lassolicitudes por miedo a la obstrucción del canal. Para superar este problema,SPDY implementa las prioridades de demanda: el cliente puede solicitar ar-tículos, como muchos, ya que quiere desde el servidor, y asignar una prioridada cada solicitud. Esto evita que el canal de la red de la que se ha congestionadocon los recursos que no son críticos, cuando la solicitud de alta prioridad estápendiente.

La compresión de cabeceras, SPDY comprime de solicitud y respuestacabeceras HTTP, resultando en un menor número de paquetes y un menornúmero de bytes transmitidos.

Servidor de inserción, SPDY experimentos con una opción para los ser-vidores para enviar datos a los clientes a través de la cabecera X-Associated-Content. Esta cabecera informa al cliente que el servidor está impulsando unrecurso para el cliente antes de que el cliente ha solicitado. Por primera vezuna página de descargas (por ejemplo, la primera vez que un usuario visita unsitio), esto puede mejorar enormemente la experiencia del usuario.

Servidor de pista, En lugar de empujar de forma automática los recursospara el cliente, el servidor utiliza la cabecera X-Subresources para sugerir alcliente que se debe preguntar por los recursos específicos, en los casos en queel servidor sabe de antemano del cliente que esos recursos serán necesarios.Sin embargo, el servidor esperará a que la petición del cliente antes de enviarel contenido. En conexiones lentas, esta opción puede reducir el tiempo que letoma a un cliente al descubrir que tiene un recurso por cientos de milisegundos,y puede ser mejor para no inicial carga la página.

Todo es exactamente comoHTTP, lo único que SPDY só-lo sustituye la forma en que losdatos se escriben en la red

2.6. ¡SPDY & HTTP!SPDY pretende que sea lo más compatible posible con las actuales aplicaciones

basadas en web. Esto significa que, desde la perspectiva de la lógica de negocio delservidor o API de la aplicación, nada ha cambiado. Para lograr todo esto, la solicitudde aplicación y la semántica de respuesta de cabecera se conservan. SPDY presentauna "sesión" que se encuentra entre la capa de aplicación HTTP y el transporteTCP para regular el flujo de datos. Esta "sesión" se asemeja a un servidor HTTP depetición-respuesta. Los siguientes cambios representan las diferencias entre SPDY yHTTP:

2.6.1. La solicitud (resquest)

Para iniciar una nueva solicitud, los clientes en primer lugar crean una nuevasesión SPDY, así ya el cliente puede crear una nueva petición SPDY para enviar la

SPDY, el protocolo de Google 5

2.6 ¡SPDY & HTTP! Iván Bautista Moreno

solicitud.A la hora de enviar la petición el encabezado HTTP en SPDY apenas sufrecambios con respecto al encabezado HTTP de hoy, como son:

La primera línea de la petición se desdobla en pares de nombre / valor, comootras cabeceras HTTP. Los nombres de los campos de primera línea son met-hod , url , y version . Estas teclas se requiere que esté presente. El ’url’ es ladirección URL completa, que contiene el protocolo, host, el puerto y la ruta.

Los nombres duplicados de cabecera no están permitidos.

Nombres de los encabezados son en minúsculas.

La Connection y el Keep-Alive ya no son válidos y se ignoran si están presentes.

Los clientes se supone que apoyan Accept-Encoding: gzip .

Encabezados de peticiones HTTP se comprimen mediante la compresión conla codificación gzip.

El "anfitrión" de cabecera se ignora. El anfitrión: la parte del puerto de ladirección URL de HTTP es el huésped definitivo.

Independientemente de la Accept-Encoding enviado por el cliente, el servidorpuede seleccionar la codificación gzip o desinflarse en cualquier momento.

POST-cambios específicos:

• Peticiones POST se espera que contenga una secuencia de datos comoparte del mensaje.

• Content-length es sólo de asesoramiento para la longitud.• La codificación fragmentada ya no es válida.• El flujo de datos POST se termina por un bastidor de longitud cero datos.

2.6.2. La respuesta (response)

Al responder a una petición HTTP, los servidores envian las tramas de datosutilizando la corriente de SPDY creado por el cliente. La respuesta es similar aHTTP/1.1, que se compone de un bloque de cabecera seguida por un cuerpo aunquepresenta algunos cambios como por ejemplo,

La línea de estado de respuesta se desarrolló en pares, nombre / valor, comootras cabeceras HTTP. Los nombres de la línea de estado son status y version. Son datos obligados a estar presentes.

Si la respuesta SPDY ocurre antes de un SYN_STREAM, a continuación,seincluyen parámetros que informan al cliente sobre la solicitud de que se hubierahecho de recibir esta respuesta, mediante la inclusión de url y el method.

Todos los nombres de cabecera deben estar en minúsculas.

La Connection y la Keep-alive de respuesta ya no son válidas.

Content-length es sólo de asesoramiento para la longitud.

SPDY, el protocolo de Google 6

Iván Bautista Moreno

Codificación fragmentada ya no es válida.

Los nombres duplicados de cabecera no están permitidos.

2.6.3. Conexiones

La primera implementación de la sesión SPDY se ejecuta sobre TCP, de manerasimilar a cómo funciona en la actualidad HTTP. El cliente espera que sea el iniciadorde la conexión TCP quien arranque la sesión SPDY. Como va sobre TCP tenemosun transporte fiable, a diferencia de HTTP, todas las conexiones con SPDY sonconexiones persistentes. El encabezado de la conexión HTTP no se aplica.Para un mejor rendimiento, se espera que los clientes no cierren las conexiones

abiertas hasta que el usuario se desplaza fuera de todas las páginas web que hacenreferencia a una conexión, o hasta que el servidor cierra la conexión.

3. SPDY ProxyUn uso potencial para SPDY es proporcionar un acceso rápido y seguro a un ser-

vidor proxy. Por ejemplo, si tuviéramos un proxy de avance que se solicita SPDY delcliente y podría emitir las peticiones HTTP a la web, entonces podríamos aprove-char los beneficios de SPDY sobre el vínculo cliente-> servidor proxy sin necesidadde actualizar toda la web. Algunos entornos en los que esto podría ser especialmenteútiles incluyen:

Las redes móviles, donde RTT son muy altos.

Las redes públicas locales, donde los protocolos Wi-Fi o de otro tipo puedenser inseguros, pero las conexiones SPDY a un proxy seguro podría añadir unacapa de protección.

SPDY, el protocolo de Google 7

Referencias Iván Bautista Moreno

Referencias[1] Páginal oficial de google -SPDY

[2] SPDY.pptx

SPDY, el protocolo de Google 8