Cada vez que visitamos una página web, el navegador busca mediante una solicitud al servidor todos los medios que conforman la página. Desde el nacimiento de internet esto se ha hecho a través de HTTP/1.1.
Con el paso del tiempo y la evolución de la tecnología, los sitios web se han convertido cada vez en algo más complejo y pesado, y el protocolo HTTP/1.1 ha sido sometido cada vez más a mayor presión, con una gran cantidad de soluciones necesarias para hacer frente a los problemas de rendimiento.
Las páginas Web, tal como las conocemos hoy en día, a menudo se completan con recursos tales como imágenes, texto, tipografías, etc., que las hacen mucho más pesadas ??que las de la década de 1990 o incluso los años 2000. En consecuencia, se necesita más tiempo para que se carguen, lo que ha llevado a los diseñadores y desarrolladores web ha crear soluciones ingeniosas para minimizar el problema. Aún así, es evidente que hay una necesidad de realizar una actualización del mismo protocolo HTTP.
HTTP/2 traerá algunos cambios en la forma en que las páginas se entregan al navegador. Mientras que los usuarios comunes de Internet podrían no ver una gran diferencia, los diseñadores y desarrolladores web lo notarán bastante. Este artículo se centra en estos cambios, y cómo le afectarán a un usuario técnico.
Cómo trabaja HTTP/1
Para buscar la página web que deseas visitar, tu navegador se comunica con el servidor. Los dos intercambian mensajes, el navegador requiere al servidor en solicitudes separadas las imágenes, fuentes y otros recursos necesarios, y el servidor, a su vez, los envía como respuestas.
Como resultado, el flujo de datos a través de innumerables conexiones provoca congestión, y la velocidad de carga de la página se ralentiza. Para superar el problema del envío de muchas solicitudes, y para hacer mejor uso de los procesos en línea HTTP/1, la inventiva de los desarrolladores ha llevado a utilizar la concatenación y los sprites de imagen. Afortunadamente con el desarrollo de HTTP/2 esto será cosa del pasado.
Cómo trabajará HTTP/2
El navegador seguirá enviando peticiones a un servidor y obtendrá respuestas con los medios necesarios para componer la página Web, pero algunos matices van a cambiar. HTTP/2 ofrece nuevas características tales como Flujos Multiplexados, Server Push, Compresión de Cabecera y Formato Binario.
Flujos Multiplexados
Recuerda las congestiones causadas por las múltiples conexiones que llevan los recursos tales como texto, fuentes e imágenes desde el servidor al navegador. La Multiplexación elimina este problema al hacer esos recursos en partes más pequeñas, pasando todos ellos a través de una conexión, y luego volviendo a montar los recursos después de que han llegado a su destino final, el navegador.
Server Push
Server push representa una manera más eficiente de entregar medios a un navegador. En un entorno HTTP/1, la página HTML se envía al navegador, el navegador lo analiza y decide cuáles son los medios que podría necesitar y, a continuación, solicita esos medios al servidor.
HTTP/2 es más proactivo en este sentido, envía los medios que es probable que se necesiten sin que tener que solicitarlo al navegador. Estos medios van a la memoria caché del navegador y están disponibles de inmediato siempre y cuando se necesiten, lo cual es una ventaja para el rendimiento.
Compresión de Cabecera
En HTTP/1, cada solicitud enviada tiene un pequeño trozo de datos adicionales, conectados a los encabezados HTTP, que describen cómo se comporta un navegador o un servidor. En promedio, los navegadores son capaces de hacer unas seis conexiones a la vez pero, dado que el número de conexiones necesarias para cargar una página web típica puede ser de hasta alrededor de 100, lo que deja una gran cantidad de datos que recuperar, algo que lleva consumo de tiempo y ancho de banda.
Cuando se establece una conexión HTTP/2, todas las cabeceras se empaquetan en un bloque comprimido para ser enviado como una unidad. Se hace más rápido y cuando se termina la transmisión, el bloque de cabecera se decodifica.
Binario en vez de formato de texto
El formato de texto tiene cierta sobrecarga adicional y necesita ser refinado, mientras que el binario no necesita ningún tipo de análisis. También es mucho más compacto. El trabajo adicional en un servidor supone más tiempo de espera a que la página web se cargue. Por esto, el formato binario, es una mejora justificada.
Lo que los desarrolladores podrán hacer de manera diferente ahora
Los desarrolladores ya no tienen que hacer sprites de imágenes, hacer procesos en línea ni concatenar archivos, ya no habrá necesidad de reducir el número de peticiones en una página web. Básicamente, este va a ser el mayor cambio. Sin embargo, hay más cosas acerca de los cambios internos que puedan afectar de alguna manera a tu trabajo.
Cosas a tener en cuenta
Aunque no está requerido por la especificación actual HTTP/2, la mayoría de los navegadores que soporten HTTP/2 requerirán cifrado HTTPS. Esto significa que, si el sitio HTTP/2 no se sirve a través de una conexión cifrada, los visitantes ya sea que encontrar algún otro cliente para visitar su sitio o pierda.
Aunque existe un esfuerzo en estos días para servir los sitios a través de HTTPS, este requisito para los navegadores ha sido criticado y, sin duda, para algunos representa un obstáculo a la hora de considerar el cambio a HTTP/2.
Las modificaciones y actualizaciones necesarias para la nueva versión del protocolo de trabajo se llevará a cabo en servidores y navegadores. Los servidores se actualizarán con el tiempo para apoyar ambos protocolos. Los navegadores que soportan el nuevo protocolo se cambiarán a HTTP/2 automáticamente. Al mismo tiempo, los más viejos no lo entenderán. Como desarrollador necesitas saber si tanto el navegador como el servidor utilizan el soporte HTTP/2 para asegurarte de que la conexión se actualizará.
Esta es la diferencia
En esta demo de Akamai se ilustra cómo los recursos se cargan simultáneamente en las dos versiones del protocolo. La primera imagen se carga a través de HTTP/1 y seis conexiones simultáneas (si estás utilizando Google Chrome), mientras que el segundo viene en su conjunto a través de HTTP/2 y todas las partes las carga simultáneamente.
Si quieres tener un ejemplo más detallado de las diferencias de la carga de datos a través de las conexiones en los dos protocolos, echa un vistazo a este ejemplo de golang.org. Te permite probar diferentes ajustes de latencia por lo que puedes ver cómo los datos se cargan simultáneamente en los dispositivos de diferente capacidad. Cuanto más larga sea la demora, más visible es que HTTP/2 es mejor en términos de rendimiento.
Comentarios