• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Trabajo sobre el protocolo Spdy
 

Trabajo sobre el protocolo Spdy

on

  • 758 views

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.

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.

Statistics

Views

Total Views
758
Views on SlideShare
758
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Trabajo sobre el protocolo Spdy Trabajo sobre el protocolo Spdy Document Transcript

    • 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Índice1. Introducción 12. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73. SPDY Proxy 7Referencias 8 SPDY, el protocolo de Google II
    • Iván Bautista Moreno1. Introducción Google Inc. es la empresa propietaria de la marca Google, cuyo principal productoes 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 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ápida2.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á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 Moreno2.2. Antecedentes Hoy en día, HTTP y TCP son los protocolos por excelencia de la web. TCP esel 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 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 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 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
    • 2.3 Protocolo SPDY Iván Bautista Moreno2.3. Protocolo SPDY SPDY es un protocolo capaz de optimizar las comunicaciones HTTP con unamejora 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 laweb 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 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
    • 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 descargassimultá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 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
    • 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 red2.6. ¡SPDY & HTTP! SPDY pretende que sea lo más compatible posible con las actuales aplicacionesbasadas 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 Morenosolicitud.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, 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 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, 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
    • 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 conexionesabiertas 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 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 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 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
    • Referencias Iván Bautista MorenoReferencias[1] Páginal oficial de google -SPDY[2] SPDY.pptx SPDY, el protocolo de Google 8