 | 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?
 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. |
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.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.
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.
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 |
 |  |
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 | ||||||||||
| ||||||||||
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.
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:
Status Fecha Hito 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 7230, 7231, 7232, 7233, 7234, 7235 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 ;-)