Trabajo, realizado para la asignatura ingeniería de protocolos, que trata sobre los avances a la HTTP 2.0 sobre el protocolo que Google está desarrollando para reducir la latencia en páginas webs.

1. 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

2. Índice Iván Bautista Moreno
Índice
1. Introducción 1
2. SPDY: un protocolo experimental de una red más rápida 1
2.1. Inicio del proyecto SPDY . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3. Protocolo SPDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4. El diseño de SPDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Características del SPDY . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. ¡SPDY & HTTP! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6.1. La solicitud (resquest) . . . . . . . . . . . . . . . . . . . . . . 5
2.6.2. La respuesta (response) . . . . . . . . . . . . . . . . . . . . . . 6
2.6.3. Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. SPDY Proxy 7
Referencias 8
SPDY, el protocolo de Google II

3. Iván Bautista Moreno
1. Introducción
Google 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 motor
nació 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) para
mejorar 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 con
un 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 de
exhibició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 red
más rápida
2.1. Inicio del proyecto SPDY
Como 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áginas
web. Uno de estos experimentos es SPDY (pronunciado "Speedy"), un protocolo de
capa de aplicación complementario al protocolo HTTP, que funciona sobre TCP/IP
para el transporte de contenidos a través de la web, diseñado específicamente para
una latencia mínima.
Figura 1: Analogía capa OSI
SPDY, el protocolo de Google 1

4. 2.2 Antecedentes Iván Bautista Moreno
2.2. Antecedentes
Hoy 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 la
congestión y las características de otros medios de transporte. HTTP es el protocolo
de nivel de aplicación que proporciona peticiones básicas de solicitud-respuesta. Por
desgracia, HTTP no fue diseñado especialmente para la latencia y las páginas web
de transmisión de hoy día son significativamente diferentes de las páginas web de
hace 10 años, las mejoras de la demanda de HTTP no podía haber sido anticipado
cuando HTTP fue desarrollado por ello ahora se busca una solución que permita
una 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 recurso
a la vez debido a que los servidores tienen un retraso de 500 ms que impide la
reutilizació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 debe
esperar para recibir una solicitud de recursos por parte del cliente.
3. Solicitud y las cabeceras de respuesta sin comprimir. Las cabeceras
de las solicitudes de hoy en día varían en torno a un tamaño de 200 bytes a
más de 2 KB.
4. Cabeceras redundantes. Envío repetido de cabeceras.
5. Compresión de datos opcional. HTTP utiliza codificación opcional de
compresión de datos. El contenido siempre debe ser enviado en un formato
comprimido.
SPDY no es la única investigación para hacer más rápido HTTP, ha habido otras
propuestas sobre todo a nivel de la capa de transporte o de sesión como pueden ser:
Stream Transmission Control Protocol (SCTP), un protocolo de capa
de transporte para sustituir a TCP, que proporciona flujos multiplexados y el
control de flujo consciente de la congestión.
HTTP a través de SCTP, una propuesta para el funcionamiento de HTTP
a 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

5. 2.3 Protocolo SPDY Iván Bautista Moreno
2.3. Protocolo SPDY
SPDY 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 de
forma transparente lo complementa, sin que los usuarios se den cuenta, actualmente
só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 la
latencia que experimentamos entre peticiones usando HTTP ya que las conexiones
se abren y se cierran por petición. El cliente siempre realiza la petición inicial, por
lo 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 SPDY
son 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 capa
de transporte subyacente, por lo que no requiere cambios en la infraestructura
de red existente.
Los únicos cambios necesarios para apoyar SPDY se encuentran en el agente
de usuario cliente y el servidor de aplicaciones web.
Reunir ideas afines a las partes interesadas en la exploración de protocolos
como una forma de resolver el problema de latencia.
Algunos de los objetivos técnicos específicos son:
SPDY, el protocolo de Google 3

6. 2.4 El diseño de SPDY Iván Bautista Moreno
Permitir muchas solicitudes simultáneas HTTP para ejecutar a través de una
sola 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 de
uso y definir fácilmente analizable formatos de mensaje.
Para que SSL el protocolo de transporte subyacente, para una mejor seguridad
y 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 red
depende de una conexión de red segura. Además, el uso de SSL es necesario
para 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 datos
al cliente siempre que sea posible.
2.4. El diseño de SPDY
SPDY 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 transmitir
los datos a través del cable. Donde las peticiones pueden ser iniciadas por el cliente
y el servidor.
2.5. Características del SPDY
Flujos multiplexados SPDY, permite un número ilimitado de descargas
simultá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 menor
número de conexiones de red es necesario hacer, y menos, pero más densamente
poblado, los paquetes se emiten.
SPDY, el protocolo de Google 4

7. 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 las
solicitudes 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 prioridad
a cada solicitud. Esto evita que el canal de la red de la que se ha congestionado
con 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 respuesta
cabeceras HTTP, resultando en un menor número de paquetes y un menor
nú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 un
recurso para el cliente antes de que el cliente ha solicitado. Por primera vez
una página de descargas (por ejemplo, la primera vez que un usuario visita un
sitio), esto puede mejorar enormemente la experiencia del usuario.
Servidor de pista, En lugar de empujar de forma automática los recursos
para el cliente, el servidor utiliza la cabecera X-Subresources para sugerir al
cliente que se debe preguntar por los recursos específicos, en los casos en que
el 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 enviar
el contenido. En conexiones lentas, esta opción puede reducir el tiempo que le
toma 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 como
HTTP, lo único que SPDY só-
lo sustituye la forma en que los
datos 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 del
servidor o API de la aplicación, nada ha cambiado. Para lograr todo esto, la solicitud
de aplicación y la semántica de respuesta de cabecera se conservan. SPDY presenta
una "sesión" que se encuentra entre la capa de aplicación HTTP y el transporte
TCP para regular el flujo de datos. Esta "sesión" se asemeja a un servidor HTTP de
petición-respuesta. Los siguientes cambios representan las diferencias entre SPDY y
HTTP:
2.6.1. La solicitud (resquest)
Para iniciar una nueva solicitud, los clientes en primer lugar crean una nueva
sesión SPDY, así ya el cliente puede crear una nueva petición SPDY para enviar la
SPDY, el protocolo de Google 5

8. 2.6 ¡SPDY & HTTP! Iván Bautista Moreno
solicitud.A la hora de enviar la petición el encabezado HTTP en SPDY apenas sufre
cambios con respecto al encabezado HTTP de hoy, como son:
La primera línea de la petición se desdobla en pares de nombre / valor, como
otras 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 la
direcció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 con
la codificación gzip.
El "anfitrión" de cabecera se ignora. El anfitrión: la parte del puerto de la
dirección URL de HTTP es el huésped definitivo.
Independientemente de la Accept-Encoding enviado por el cliente, el servidor
puede seleccionar la codificación gzip o desinflarse en cualquier momento.
POST-cambios específicos:
• Peticiones POST se espera que contenga una secuencia de datos como
parte 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 datos
utilizando la corriente de SPDY creado por el cliente. La respuesta es similar a
HTTP/1.1, que se compone de un bloque de cabecera seguida por un cuerpo aunque
presenta algunos cambios como por ejemplo,
La línea de estado de respuesta se desarrolló en pares, nombre / valor, como
otras 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,se
incluyen parámetros que informan al cliente sobre la solicitud de que se hubiera
hecho 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

9. 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 manera
similar a cómo funciona en la actualidad HTTP. El cliente espera que sea el iniciador
de la conexión TCP quien arranque la sesión SPDY. Como va sobre TCP tenemos
un transporte fiable, a diferencia de HTTP, todas las conexiones con SPDY son
conexiones 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 hacen
referencia a una conexión, o hasta que el servidor cierra la conexión.
3. SPDY Proxy
Un 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 del
cliente 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 necesidad
de 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 pueden
ser inseguros, pero las conexiones SPDY a un proxy seguro podría añadir una
capa de protección.
SPDY, el protocolo de Google 7

10. Referencias Iván Bautista Moreno
Referencias
[1] Páginal oficial de google -SPDY
[2] SPDY.pptx
SPDY, el protocolo de Google 8