jueves, 26 de febrero de 2015


YA, Por FIN, Tenemos HTTP / 2.0



HTTP, es el protocolo utilizado por los navegadores para poder visualizar las páginas web. Combiene recordar que la última versión, la HTTP/1.1, fue aprobada en 1999 (estandarizada en RFC 2616)
Sin sorpresa y conforme a los tiempos marcados, Marcos Nottingham actualmente preside el grupo de trabajo IETF HTTP, confirma que IESG ha aprobado por fin, las especificaciones de HTTP / 2 y HPACK , solo queda publicar su RFC, con su correspondiente asignación de números.
¿Qué aporta y en qué se diferencia esta última versión de protocolo de comunicación?. Pues la principal ventaja, es una óptima gestión de recursos, beneficiando especialmente a la velocidad de la web; voy a intentar explicarlo, “SPDY y HTTP2.0”
Esta nueva versión se presenta como una respuesta a SPDY , un protocolo compatible con HTTP desarrollado por Google y apoyado por los navegadores Chrome ,Opera , Firefox , Internet Explorer 11 , Safari , y Amazon Silk.

Para empezar ¿Que es HTTP?


arquitectura http web
Cada página HTML se identidifa por una URL, por ejemplo http://www.trotero.com/home.html

En primer lugar, tenemos el primer protocolo HTTP 1.0 Web. HTTP es lo que es un acrónimo de Protocolo de Transferencia de HiperTexto. Se ha desarrollado especialmente para descargar los documentos como HTML (Hypertext Markup Language) solicitados al servidor con el fin de descargar y visualizar en navegador. Aunque la última versión es 1.1, que es la normalmente utilizada, el proceso inicial es el siguiente.
Característica de funcionamiento de este HTTP, es muy simple. El patrón de comportamiento es como sigue.
  1. Desde el navegador, el solicitado un documento HTML al servidor (petición). (Tras la resolución de la IP y establecida la concesión TCP con el servidor)
  2. El Servidor, devuelve el documento HTML que se requiere para el navegador (respuesta)
Por esta razón, HTTP es un protocolo llamado de peticion - respuesta

Con la evolución de la Web, entra el problema de la velocidad!

Durante un tiempo, precia que la Web, no tenía ningún problema con este HTTP, más allá del ancho de banda de los antiguos modem sobre las líneas analógica de voz. Inicialmente en Web de sólo se pretendía mostrar el documento, porque yo solo quería descargar “un” documentos HTML y quizás alguna fotografía asociada al mismo.
Sin embargo, debido la evolución que la web y agravado con el HTML5, surge el problema de la velocidad. Esto es debido al hecho de que se descargan una gran cantidad de recursos con cada petición o página, y hace que llegué a producirse un cuello de botella en las peticiones.
Páginas Web que todo el mundo está usando ahora, ya no es solo un documento o fichero, se componen de una serie de recursos (JavaScript y hojas de estilo, imágenes, etc.) muy variados y numerosos. Por ejemplo, Trotero.com en HTML5 se compone de 90 peticiones de los recursos. Estos recursos, que se tratan de conseguir mediante HTTP, se convierten en la siguiente secuencia.

  • Desde el navegador, se solicita el documento por Pagina-principal de HTML al servidor.

  • Una vez que tenemos el documento HTML, lee e interpreta, para solicitar los siguientes recursos (hojas de estilo) ...

  • Una vez que haya descargado estos, los últimos recursos serán las imagen (sonido, video,..), y con ello la página Web se completa para poder ser mostrada.
En otras palabras, no es una única petición y una única respuesta del servidor, se produce 90 veces. Si por ejemplo para descargar uno de los recursos del servidor, nos lleva una media de 0,2 segundos, la página en cuestión nos llevará 18 segundos de promedio. Y es que lleva tanto tiempo, que se puede convertir en un servicio poco práctico, por mucha alta velocidad y buena cache que tengamos.
Para ello, la HTTP1.1 utilizada actualmente, lo solucionaba con la posibilidad transmitir y gestionadas simultáneamente  el número de peticiones, sin necesidad de ir encoladas una tras otra, con ello el tiempo de descarga se ve acortado. Con una analogía con el trasporte de paquetes, es como si en lugar de ir pidiendo un paquete y a recepción de este pedir otro al trasportista, y así consecutivamente, uno por uno, la empresa de trasporte nos lo facilita a través de 90 camiones distintos, como si fuéramos 90 clientes diferentes, cuanto más camiones se puedan disponer simultáneamente en el transporte antes se terminará.
Con esta solución, el problema de la velocidad se ha mejorado significativamente. En la Web actual y utilizar una variedad de técnicas, con la que es posible enviar 10 o más solicitudes simultáneas, con el objetivo de acelerar la velocidad.


 HTTP 1.0


 HTTP 1.1

peticiones respuesta http10

 


Nuevos problemas debido al abuso de las solicitudes concurrentes

Sin embargo ahora, con abuso de solicitudes simultáneas de facilitadas por HTTP se ha producido un nuevo problema. Se aumentar la carga en el equipo servidor y la red.
En el ejemplo de la compañía de trasporte anterior, se nos pasó por alto un detalle. Aparece un recurso problemático al implementarlo, y es que los camiones no ocupan un solo carril. Si lanzamos 10 camiones de transporte simultáneamente, significa que nos harán falta diez carriles independientes.
Creo que se ve, intuitivamente muy bien el problema. Del almacén saldrán varios camiones de carga, al mismo destino, simultáneamente, tendremos que hacer la carretera tan grande, como para cubrir todos los carriles, y además un carril para solo un camión ¿?. Lo creas o no, hoy más tráfico del sitio web no está lejos de esta analogía. El protocolo original de HTTP se remonta casi 25 años.
Pero volviendo al servidor y la red, tendremos ahora en la web una conexión TCP, por cada carril anterior, dado que en HTTP es equivalente a realizar un trasporte  sobre el carril con una conexión TCP. A más número de peticiones que se enviará al mismo tiempo, más número de conexión TCP se necesitaran provocando una carga excesiva en el servidor y la red.

SPDY, el advenimiento de HTTP2.0

SPDY, incluido en HTTP2.0, apareció para resolver el problema creado con tal número de conexiones simultáneas TCP. El uso de este protocolo Web avanzado, mejora hasta en un 65% los tiempos, aumentando con ello considerablemente  la velocidad, a la vez que es posible reducir la carga en el servidor y la red.
Culla finalidad principal de SPDY es reducir el tiempo de carga de las páginas web.
SPDY
Familia Protocolos de Internet
Función Transferencia de hipertexto
Ubicación en la pila de protocolos

Aplicación HTTP
Sesión SPDY
Transporte TCP
Red IP

La idea es muy simple. Siguiendo con la analogía en la autopista, la raíz de todos los males es que se ocuparía individuamente cada carril, un carril por cada camión. Parece lógico persuadir a los conductores, para que se organicen y conduzcan a todos los camiones por un solo carril.  Pues con SPDY, tuvieron exactamente la misma idea. Peticiones HTTP múltiple y por una única conexión TCP, el concepto lógico ya conocido de MULTIPLEXACIÓN.

http2 multiplexacion

Google presento la propuesta del protocolo SPDY y en el 2009 se publicada por primera vez, su primer borrador (http://www.chromium.org/spdy/spdy-whitepaper), actualmente soportado por Internet Explorer (versión 11), Google Chrome, Mozilla Firefox (versión 11 en adelante hasta la 28) y Opera (versión 12.10 en adelante). Además, diversos servicios de Google, Twitter, Facebook , lo utilizan actualmente a gran escala.


HTTP2.0 con SPDY

Además de multiplexación de HTTP2.0, se ha incluido una variedad de características para acelerar el flujo, como la compresión (ver  HPACK) y peticiones al servidor en la cabecera HTTP, y anticipación a peticiones del cliente, como mandar la imagen del logo, solo con recibir una petición de página.
El estudio de HTTP2.0 comenzó en 2012, tomando como punto de partida SPDY. La incorporación desde un principio, de la esencia de SPDY a la nueva versión de HTTP, es la voluntad de tratar de desarrollar una especificación estándar que resolver el problema de velocidad de HTTP1.1.
Con SPDY se siguió trabajando en paralelo también, con la última versión 4,( captura la parte de la especificación HTTP2.0) con la evidente necesidad de converger y guardar coherencia con HTTP2.0. Teniendo en el marco del IETF. Tratando de cubrir no sólo HTTP, también tiene pretensiones de mediar en otros protocolos (DNS y WebSocket).
Comentar, que ya Googleha anunciado en el blog de Chromium  que SPDY será dado de baja a principios en el 2016 e instó a los desarrolladores de servidores a adoptar el nuevo protocolo HTTP/2.


 Cronología:

StatusFechaHito
Hecho Dec 20, 2007 First HTTP 1.1 Revision Internet Draft
Hecho January 23, 2008 First HTTP Security Properties Internet Draft
Hecho Early 2012 Call for Proposals for HTTP 2.0
Hecho Oct 14, 2012 - Nov 25, 2012 Working Group Last Call for HTTP 1.1 Revision
Hecho Nov 28, 2012 First WG draft of HTTP 2.0, based upon draft-mbelshe-httpbis-spdy-00
Hecho Sep 2013 Submit HTTP 1.1 Revision to IESG for consideration as a Proposed Standard
Hecho Feb 12, 2014 IESG approved HTTP 1.1 Revision to publish as a Proposed Standard
Hecho June 6, 2014 Publish HTTP 1.1 Revision as RFC 723072317232723372347235
Hecho Aug 1, 2014 - Sep 1, 2014 Working Group Last call for HTTP/2
Hecho Dec 16, 2014 Submit HTTP/2 to IESG for consideration as a Proposed Standard
Hecho Dec 31, 2014 - Jan 14, 2015 IETF Last Call for HTTP/2
Hecho Jan 22, 2015 IESG telechat to review HTTP/2 as Proposed Standard
Hecho Feb 17, 2015 IESG approved HTTP/2 to publish as Proposed Standard
Pendiente Publish HTTP/2 as an RFC

Lecturas de referencia:
http://moz.com/blog/http2-a-fast-secure-bedrock-for-the-future-of-seo
http://html5experts.jp/komasshu/404/
https://groups.google.com/forum/?fromgroups=#!topic/spdy-dev/EWEEWSYtlhc

No hay comentarios:

Publicar un comentario

Gracias por tu comentario ;-)