HTTP/2

Con HTTP/1.x para cargar cualquier contenido web es necesario el uso de múltiples conexiones TCP simultáneas para poder descargar todos los elementos de dicha web. En cambio, HTTP 2.0 utiliza una única conexión para ofrecer múltiples solicitudes y respuestas en paralelo. Teniendo en cuenta que cada página web puede contener objetos HTML, CSS, JavaScript, imágenes, vídeo… la diferencia de trabajo entre utilizar una única conexión o utilizar varias es elevada.

Otro cambio de gran relevancia en HTTP 2.0 es la eliminación de información redundante cuyo objetivo es evitar el envío de datos repetidos durante una misma conexión, así conseguiremos que se consuman menos recursos, obteniendo una menor latencia.

Con HTTP/1.1 el navegador envía una petición y debe esperar la respuesta del servidor para poder enviar la siguiente solicitud. El problema es que las webs modernas suelen tener más de 100 objetos, por lo que el retardo es grande. La solución que introduce HTTP 2.0 a este problema es la denominada Multiplexación.

La multiplexación permite enviar y recibir varios mensajes al mismo tiempo optimizando la comunicación. Con la multiplexación se consigue reducir el número de conexiones mejorando considerablemente la velocidad de carga y disminuyendo la congestión de los servidores web.

La ventaja que tiene el uso de un protocolo binario es la facilidad para encontrar el comienzo y el final de cada frame, que es algo realmente complicado en cualquier protocolo de texto. Además, los protocolos binarios son mucho más simples y por lo tanto son menos propensos a tener errores que los protocolos de texto utilizados por las versiones anteriores a HTTP 2.0.

Comunicación entre un host y un servidor con el servicio 'server push'

El servicio “server push”[5] también conocido como “cache push”, se basa en estimaciones para que el servidor sea capaz de enviar información al usuario antes de que éste la solicite para que la información esté disponible de forma inmediata.

La forma de actuar del servidor es enviar varias respuestas a una única solicitud del cliente, es decir, además de la respuesta a la solicitud original, el servidor puede enviar recursos adicionales. Esto es así porque una página web está formada por decenas de archivos referenciados que gracias al servicio “server push” el servidor envía tras recibir una única solicitud ahorrando mensajes innecesarios.

HTTP 2.0 contiene un campo denominado ‘Ajustes’ con el que el cliente puede indicar si desea o no obtener los recursos que proporciona el servicio ‘server push’.

Con las versiones anteriores a HTTP 2.0, las cabeceras de los mensajes de solicitud eran de texto claro, sin ningún tipo de compresión. El problema aparece como consecuencia del incremento de tamaño que sufren estas cabeceras por los user-agent de los navegadores, al uso de cookies (también deben aparecer en los mensajes de solicitud), etc. Además, cuando HTTP/1.1 envía una petición, debe esperar la respuesta del servidor para poder enviar la siguiente solicitud, aumentado mucho el retardo sufrido.

Asimismo, hay que tener en cuenta que cuando un cliente hace numerosas peticiones a un mismo servidor, los encabezamientos apenas cambian unos de otros, por lo que se envía mucha información redundante.

Con HTTP 2.0 las cabeceras experimentan compresiones, con lo que se obtienen mejores tiempos de respuesta y también se mejora la eficiencia (sobre todo en terminales móviles). El algoritmo empleado para realizar la compresión de cabeceras es HPACK.[6] HPACK es un algoritmo simple y poco flexible que se basa en eliminar campos de cabecera redundantes, además de prevenir posibles vulnerabilidades.

Un mensaje HTTP se puede dividir en múltiples fragmentos en su recorrido desde el cliente hasta el servidor o desde servidor al cliente. El orden y el retardo con el que estas tramas llegan a su destino son fundamentales, dado que algunos objetos de las webs son más importantes que otros. Nos interesará que los objetos más relevantes cuenten con algún tipo de prioridad.

Para poder ‘controlar’ la prioridad que tienen las tramas, HTTP 2.0 permite asignar a cada flujo un peso (entre 1 y 256) y una dependencia. Debemos ser conscientes de que las prioridades pueden variar durante la ejecución.

Con las prioridades y la dependencia se hace un árbol de prioridades.

Ejemplo; Si A tiene un peso de 12 y B tiene un peso de 4: A dispondrá del 75 % de los recursos y B se quedará con el 25 % restante.

En HTTP/2 el uso de cifrado TLS (Transport Layer Security) es opcional. De todos modos un gran número de fabricantes de software[7] (Firefox, Internet Explorer o Google Chrome por ejemplo) ya han anunciado que sus implementaciones solo soportarán HTTP 2.0 sobre TLS usando la extensión ALPN[8] que requiere TLSv1.2 o superior.[9]

Recordemos que TLS es un protocolo criptográfico de la capa de transporte (de criptografía asimétrica), que proporciona comunicaciones seguras por la red. El uso de TLS añade un retardo adicional.

Las cabeceras se utilizan para iniciar un flujo, y pueden contener los siguientes campos:

• Pad Length (8 bits): contiene la longitud de la trama. Se mide en octetos.
• E (1bit): Bandera de un bit. Depende de la prioridad.
• Stream Dependency (31 bits): se trata de un identificador de flujo.
• Weight (8 bits): representa el nivel de prioridad, su valor puede variar de 1 a 256.
• Header Block Fragment: es un fragmento del bloque de cabecera.
• Padding: octetos para padding (tiene un tamaño variable).
• Quedan definidos los siguientes indicadores:
• END_STREAM (0x1): El último mensaje en una secuencia utiliza este campo para indicar el final de la transferencia de datos.
• END_HEADERS (0x4): Campo que indica el final de las cabecera. En este caso la trama contiene un bloque de cabecera completo.
• PADDED (0x8): Cuando se establece, indica que el campo de Longitud Pad y cualquier tipo de relleno están presentes.
• PRIORITY (0x20): Con este campo se puede indicar al servidor la prioridad que tiene el mensaje. Podrá ser modificada durante la ejecución.

Las frames utilizan campos de prioridad (type = 0x2) para comparar distintos tipos de tramas dando preferencias a unas respecto de otras.

Esta prioridad puede ser modificada en cualquier momento, sea cual sea el estado de la frame, pero es aconsejable que durante el intercambio de cabeceras no sea modificado su valor.

En el caso en el que, por cualquier motivo, se reciba una prioridad sin contenido se produce el siguiente error: ‘Protocol error’.

En el caso en el que se reciban en primer lugar los contenidos, y en segundo lugar sus prioridades, estás no se tendrán en cuenta a la hora de procesar las tramas.

En HTTP/2 el padding puede ser utilizado para ocultar el tamaño exacto del contenido de la trama, con la idea de ocultar la compresión de los datos más sensibles.

Debe tomarse en consideración que el uso del padding de forma redundante puede llegar a ser contraproducente, además de que su uso, en el mejor de los casos, sólo hace que sea más complicado para un atacante hacerse con la información, pero en ningún caso consigue hacerlo inevitable.

En HTTP 2.0 se permiten múltiples intercambios de stream por cada conexión TCP. El problema que puede darse es de denegación del servicio (sobrecarga de los recursos computacionales del sistema), debido a que se permite un total de 2^31 intercambios de stream por conexión.

Un atacante que quisiera sobrecargar la red podría abrir múltiples conexiones en las que se intercambiasen numerosos stream. Por este motivo se debe limitar el intercambio de stream por conexión.

Uno de los posibles problemas que nos podemos encontrar en HTTP 2.0 es debido al uso del servicio ‘server push’.[10]

Un atacante podría aprovechar las múltiples respuestas que realiza el servidor a una única solicitud, el uso de memorias caché… con el fin de poder acceder a contenidos web que fueron de uso público y ahora son de uso privado (que requieren de privilegios para poder ser accedidos).