Saltar al contenido
Mujer parada de manos en la palabra EVOLVE
BABEL Blog

HTTP 2.0 – La siguiente revolución

17 noviembre 2016

Tags

  • "HTTP 2.0"
  • Hypertext
  • "Hypertext Transfer Protocol
  • "
  • "Internet Engineering Task Force"
  • movilidad
  • Protocol
  • SPDY
  • Transfer




HTTP 2.0,
 o como muchos de vosotros lo conoceréis, Hypertext Transfer Protocol versión 2, es un nuevo protocolo de red utilizado por la World Wide Web que tiene como objetivo actualizar el protocolo HTTP/1.1, que lleva cerca de 16 años sin actualizarse, por lo que ya era hora de que alguien hiciera algo al respecto.

Además este nuevo protocolo está pensado para no modificar la semántica básica de su predecesor, por lo que la mayoría de los conceptos básicos se mantienen sin cambios e introduce numerosas mejoras que explicaremos en los siguiente puntos.


Un poco de historia

Este nuevo protocolo de red se nutre de otro proyecto anterior, SPDY, un protocolo de red desarrollado en 2009 por un equipo de Google que aumenta el desempeño de las páginas web que manejan gran cantidad de tráfico y no permite que estas colapsen cuando reciben grandes cantidades de peticiones. Hablando en números, esto significó mejorar hasta en un 60 por ciento la velocidad de carga de las páginas web estándar y hasta un 55 por ciento las conexiones protegidas con cifrado.

Más tarde el IETF (Internet Engineering Task Force) creó un equipo para el desarrollo de un nuevo protocolo de red, pero no fue hasta el año 2015 cuando los navegadores comenzaron a darle soporte.


HTTP Frames

Ahora que ya sabemos que es esto del HTTP 2, es posible que nos preguntemos cómo se realiza dicha conexión y cómo se comunican los dispositivos mediante este protocolo. Pues bien, una vez se ha establecido la conexión entre ambos, estos comienzan a generar unos paquetes y a enviárselos entre ellos. Estos paquetes o frames pueden tener un máximo de 16 MB, siempre y cuando el cliente y el servidor se pongan de acuerdo.

Pero además, estos frames contienen campos de prioridad para comparar distintos tipos de tramas, para así dar preferencias a unas respecto a otras.

A continuación dejamos un esquema obtenido de la propia página del HTTP 2, en donde explica la estructura de cada frame.

Tamaño Trama HTTP2

Figura 1. Formato de la trama

  • Length: 24 bits que indican la longitud de dicho frame sin contar los 9 bytes de la cabecera.
  • Type: 8 bits que nos informan de cómo se interpreta el resto de la trama. A pesar de que hoy día hay pocos tipos de frames disponibles, los 8 bits dejan espacio para 256 formatos diferentes de frames.
  • Flags: 8 bits que determinan el contenido de los flags.
  • R: se trata de un bit reservado. Debe permanecer con valor ‘0’ al ser enviado y debe ser ignorado cuando se recibe.
  • Stream Identifier: Se trata de un identificador de flujo de 32 bits. El bit más significativo siempre es 0.
  • Payload: contiene los datos, es de longitud variable.


Características

Una vez hemos entendido que esto del nuevo protocolo y un poco cómo se comunica, es hora de hablar de las distintas mejoras que trae este nuevo protocolo, y que describiremos a continuación.


Una sola conexión

HTTP 2.0 utiliza una única conexión para ofrecer múltiples solicitudes y respuestas en paralelo. Por lo que facilita el trabajo a algunas web que tienen que cargar altos contenidos.


Eliminación información redundante

Otra de las muchas mejoras que ofrece este protocolo es la de eliminar información que no es importante para la comunicación, de manera que evitamos enviar información repetida en cada petición y así facilitaremos la carga de datos.


Multiplexación

Con HTTP 1.1 cuando el navegador realiza una petición al servidor, este no puede solicitar otra hasta que no haya llegado la respuesta de la anterior petición, por lo que esto supone que algunas de las páginas web de hoy en día tengan un tiempo de espera muy alto a la hora de cargar todos los recursos. Pero todo esto se soluciona a través de la denominada “Multiplexación”, ya que nos permite enviar y recibir varios mensajes al mismo tiempo, optimizando la comunicación.

HTTP2 Multiplexing

Figura 2. Multiplexación


Protocolo binario

Otra ventaja de HTTP 2 es que es un protocolo binario, esto supone que sea más fácil encontrar el comienzo y el final de cada frame, que hoy en día es algo realmente complicado para cualquier protocolo de texto. Además al contar con esta sencillez en el mensaje supone que estos frames sean menos propensos a tener errores y que la“traducción” sea mucho más rápida.


Server push

O también conocido como “cache push” se basa en estimaciones que hace el servidor para enviar información al usuario antes de que éste la solicite para que la información esté disponible de forma inmediata.


Compresión de cabeceras

Anteriormente las cabeceras de los mensajes eran de texto claro y sin ningún tipo de compresión. Por lo que a la larga cuando estas peticiones aumentan su tamaño debido al uso de cookies, de los user-agent de los navegadores, etc. esto supone un gran problema y un envío masivo de información. Pero esto con HTTP 2.0 se soluciona mediante la compresión de cabeceras, con lo que se optimizan los tiempos de respuesta.

Esta compresión se realiza mediante un algoritmo HPACK que se basa en eliminar campos redundantes de las cabeceras.


Priorización de flujos

Como hemos comentado anteriormente los frames pueden llevar un tipo de prioridad, ya que los mensajes HTTP se pueden dividir en varios fragmentos durante la comunicación cliente – servidor. Por lo que es necesario este tipo de campo para controlar el orden y el retardo con el que estas tramas llegan a su destino.

Este tipo de prioridad es un valor que se puede asignar desde 1 hasta 256.


No requiere cifrado TLS

En HTTP/2 el uso de la encriptación TLS (Transport Layer Security) es opcional. Aunque algunos de los fabricantes de software (Firefox, Internet Explorer o Google Chrome) ya han anunciado que sus implementaciones solo soportan HTTP 2.0 sobre TLS.

Test Velocidad HTTP 2.0

Figura 3. Diferencia de velocidad


Control de Errores

Los códigos de error son campos de 32 bits utilizados para notificar los distintos fallos que pueden producirse. Los códigos que pueden darse se muestran a continuación:

  • NO_ERROR (0x0): La condición asociada no es el resultado de un error. Por ejemplo, podría usarse para indicar que el ordenador ha cerrado la conexión de forma inesperada.
  • PROTOCOL_ERROR (0x1): Error producido en el protocolo específico.
  • INTERNAL_ERROR(0x2): El punto final encontró un error interno inesperado.
  • FLOW_CONTROL_ERROR (0x3): Se da cuando el punto final detecta que su par incumple el protocolo de control de flujo.
  • SETTINGS_TIMEOUT (0x4): Tiene lugar cuando el punto final envía ajustes de marco, pero no recibe una respuesta a tiempo.
  • STREAM_CLOSED (0x5): Cierra la secuencia actual y libera todos los recursos.
  • FRAME_SIZE_ERROR (0x6): El punto final recibe una trama con un tamaño no válido.
  • REFUSED_STREAM (0x7): El servidor no procesa la respuesta.
  • CANCEL (0x8): Campo utilizado por el punto final para indicar que la conexión ya no es necesaria. Se termina el stream.
  • COMPRESSION_ERROR (0x9): Error al realizar la compresión de cabeceras. La conexión es cerrada por un motive poco usual.
  • CONNECT_ERROR (0xa): La conexión establecida se ha cerrado de forma inesperada.
  • ENHANCE_YOUR_CALM (0xb): El punto final detecta que su par está exhibiendo un comportamiento que podría generar una carga excesiva.
  • INADEQUATE_SECURITY (0xc): Se activa cuando no se cumplen los requisitos mínimos de seguridad.
  • HTTP_1_1_REQUIRED (0xd): El punto final requiere que se utilice HTTP versión 1.1 en lugar de usarse HTTP versión 2.0.


Otros enlaces de interés

Este artículo ha sido solo una pequeña introducción para explicar HTTP 2.0 y algunas de sus mejoras, por lo que si te ha gustado el tema y quieres conocerlo más a fondo te invito a que le eches un vistazo a algunos de los siguientes links en donde hay información más detallada de este protocolo.