Compresión HTTP

La compresión HTTP es una capacidad que se puede integrar en servidores web y clientes web para mejorar la velocidad de transferencia y la utilización del ancho de banda.

Los datos HTTP se comprimen antes de que se envíen desde el servidor: los navegadores compatibles anunciarán qué métodos son compatibles con el servidor antes de descargar el formato correcto; los navegadores que no admiten el método de compresión compatible descargarán datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Brotli; IANA mantiene una lista completa de los esquemas disponibles.

Hay dos formas diferentes de realizar la compresión en HTTP. En un nivel inferior, un campo de encabezado Transfer-Encoding puede indicar que la carga útil de un mensaje HTTP está comprimida. En un nivel superior, un campo de encabezado de codificación de contenido puede indicar que un recurso que se transfiere, almacena en caché o se hace referencia de otro modo está comprimido. La compresión mediante la codificación de contenido es más compatible que la codificación de transferencia, y algunos navegadores no anuncian la compatibilidad con la compresión de codificación de transferencia para evitar la activación de errores en los servidores.

Negociación de esquemas de compresión

La negociación se realiza en dos pasos, descritos en RFC 2616:

1. El cliente web anuncia qué esquemas de compresión admite al incluir una lista de tokens en la solicitud HTTP. Para la codificación de contenido, la lista se encuentra en un campo denominado codificación de aceptación; para Transferencia-Codificación, el campo se llama TE.

GET  /encrypted-area  HTTP / 1.1 
Host:  www.example.com
Aceptar codificación:  gzip, deflate

2. Si el servidor admite uno o más esquemas de compresión, los datos salientes pueden comprimirse mediante uno o más métodos admitidos por ambas partes. Si este es el caso, el servidor agregará un campo Codificación de contenido o Codificación de transferencia en la respuesta HTTP con los esquemas utilizados, separados por comas.

HTTP / 1.1  200  OK 
Fecha:  lunes, 26 de junio de 2016 22:38:34 GMT 
Servidor:  Apache/1.3.3.7 (Unix) (Red-Hat/Linux) 
Última modificación:  miércoles, 08 de enero de 2003 23:11:55 GMT 
Rangos de aceptación:  bytes 
Longitud del contenido:  438 
Conexión:  cerrar 
Tipo de contenido:  texto/html; conjunto de caracteres = UTF-8
Codificación de contenido:  gzip

El servidor web no está obligado a utilizar ningún método de compresión; esto depende de la configuración interna del servidor web y también puede depender de la arquitectura interna del sitio web en cuestión.

Tokens de codificación de contenido

IANA mantiene la lista oficial de tokens disponibles para servidores y clientes, e incluye:

• br: Brotli, un algoritmo de compresión diseñado específicamente para la codificación de contenido HTTP, definido en RFC 7932 e implementado en todos los principales navegadores modernos.
• compress: método de programa "comprimir" de UNIX (histórico; obsoleto en la mayoría de las aplicaciones y reemplazado por gzip o deflate)
• deflate: compresión basada en el algoritmo deflate (descrito en RFC 1951), una combinación del algoritmo LZ77 y la codificación Huffman, envuelto dentro del formato de datos zlib (RFC 1950);
• exi – Intercambio XML eficiente W3C
• gzip: formato zip de GNU (descrito en RFC 1952). Utiliza el algoritmo de desinflado para la compresión, pero el formato de datos y el algoritmo de suma de comprobación difieren de la codificación de contenido "deflate". Este método es el más ampliamente admitido a partir de marzo de 2011.
• identidad: no se utiliza ninguna transformación. Este es el valor predeterminado para la codificación de contenido.
• pack200-gzip – Formato de transferencia de red para archivos Java
• zstd: compresión Zstandard, definida en RFC 8478

Además de estos, los servidores o los clientes utilizan una serie de tokens no oficiales o no estandarizados:

• bzip2: compresión basada en el formato gratuito bzip2, compatible con lighttpd
• lzma: la compresión basada en (sin procesar) LZMA está disponible en Opera 20 y en elinks a través de una opción de tiempo de compilación
• peerdist: almacenamiento en caché y recuperación de contenido de pares de Microsoft
• rsync: codificación delta en HTTP, implementada por un par de proxies rproxy.
• xpress: protocolo de compresión de Microsoft utilizado por Windows 8 y versiones posteriores para las actualizaciones de aplicaciones de la Tienda Windows. Compresión basada en LZ77 opcionalmente usando una codificación Huffman.
• xz: compresión de contenido basada en LZMA2, compatible con un parche de Firefox no oficial; y completamente implementado en mget desde 2013-12-31.

Servidores que admiten compresión HTTP

• SAP NetWeaver
• Microsoft IIS: integrado o utilizando un módulo de terceros
• Apache HTTP Server, a través de mod_deflate (a pesar de su nombre, solo admite gzip) y mod_brotli
• Servidor HTTP Hiawatha: sirve archivos precomprimidos
• Servidor HTTP Cherokee, compresiones gzip y deflate sobre la marcha
• Servidor Web Oracle iPlanet
• Servidor web Zeus
• luztpd
• nginx: integrado
• Aplicaciones basadas en Tornado, si "compress_response" se establece en True en la configuración de la aplicación (para versiones anteriores a la 4.0, establezca "gzip" en True)
• Jetty Server: servicio de contenido estático predeterminado integrado y disponible a través de configuraciones de filtro de servlet
• geoservidor
• gato apache
• Websphere de IBM
• servidor AOL
• Ruby Rack, a través del middleware Rack::Deflater
• HAProxy
• Barniz – incorporado. Funciona también con ESI
• Armeria – Sirviendo archivos precomprimidos
• NaviServer: compresión integrada, dinámica y estática

Muchas redes de entrega de contenido también implementan la compresión HTTP para mejorar la entrega rápida de recursos a los usuarios finales.

La compresión en HTTP también se puede lograr mediante el uso de la funcionalidad de lenguajes de secuencias de comandos del lado del servidor como PHP o lenguajes de programación como Java.

Existen varias herramientas en línea para verificar una implementación funcional de la compresión HTTP. Estas herramientas en línea generalmente solicitan múltiples variantes de una URL, cada una con diferentes encabezados de solicitud (con contenido variable de codificación de aceptación). Se considera que la compresión HTTP se implementa correctamente cuando el servidor devuelve un documento en formato comprimido. Al comparar los tamaños de los documentos devueltos, se puede calcular la relación de compresión efectiva (incluso entre diferentes algoritmos de compresión).

Problemas que impiden el uso de la compresión HTTP

Un artículo de 2009 de los ingenieros de Google Arvind Jain y Jason Glasgow afirma que se desperdician más de 99 años-persona al día debido al aumento del tiempo de carga de la página cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software antivirus interfiere con las conexiones para obligarlas a descomprimirse, cuando se usan proxies (con navegadores web demasiado cautelosos), cuando los servidores están mal configurados y cuando los errores del navegador impiden que se use la compresión. Internet Explorer 6, que pasa a HTTP 1.0 (sin características como compresión o canalización) cuando está detrás de un proxy (una configuración común en entornos corporativos), era el navegador principal más propenso a fallar en HTTP sin comprimir.

Otro problema encontrado al implementar la compresión HTTP a gran escala se debe a la definición de codificación deflate: mientras que HTTP 1.1 define la codificación deflate como datos comprimidos con deflate (RFC 1951) dentro de un flujo con formato zlib (RFC 1950), el servidor de Microsoft y los productos de cliente históricamente lo implementó como una secuencia desinflada "en bruto", lo que hace que su implementación no sea confiable. Por esta razón, algunos programas, incluido Apache HTTP Server, solo implementan la codificación gzip.

Implicaciones de seguridad

La compresión permite realizar una forma de ataque de texto sin formato elegido: si un atacante puede inyectar cualquier contenido elegido en la página, puede saber si la página contiene su contenido dado al observar el aumento de tamaño de la secuencia cifrada. Si el aumento es menor de lo esperado para las inyecciones aleatorias, significa que el compresor ha encontrado una repetición en el texto, es decir, el contenido inyectado se superpone a la información secreta. Esta es la idea detrás de CRIME.

En 2012, se anunció un ataque general contra el uso de la compresión de datos, llamado CRIME. Si bien el ataque CRIME podría funcionar de manera efectiva contra una gran cantidad de protocolos, incluidos, entre otros, TLS y protocolos de capa de aplicación como SPDY o HTTP, solo se demostraron y mitigaron en gran medida las vulnerabilidades contra TLS y SPDY en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, aunque los autores de CRIME han advertido que esta vulnerabilidad podría estar incluso más extendida que la compresión SPDY y TLS combinadas.

En 2013, se publicó una nueva instancia del ataque CRIME contra la compresión HTTP, denominada BREACH. Un ataque BREACH puede extraer tokens de inicio de sesión, direcciones de correo electrónico u otra información confidencial del tráfico web cifrado con TLS en tan solo 30 segundos (dependiendo de la cantidad de bytes que se extraerán), siempre que el atacante engañe a la víctima para que visite un enlace web malicioso. Todas las versiones de TLS y SSL están en riesgo de BREACH, independientemente del algoritmo de cifrado o cifrado utilizado. A diferencia de las instancias anteriores de CRIME, contra las que se puede defender con éxito desactivando la compresión TLS o la compresión de encabezado SPDY, BREACH aprovecha la compresión HTTP que, de manera realista, no se puede desactivar, ya que prácticamente todos los servidores web dependen de ella para mejorar las velocidades de transmisión de datos para los usuarios.

A partir de 2016, el ataque TIME y el ataque HEIST ahora son de conocimiento público.