Compresión HTTP
From Wikipedia, the free encyclopedia
La Compresión HTTP es una capacidad que se puede construir en los servidores web y clientes de Internet para mejorar la velocidad de transferencia y la utilización de ancho de banda.[1]
Los datos HTTP se comprimen antes de ser enviados desde el servidor: los navegadores compatibles anunciarán qué métodos son compatibles al servidor antes de descargar el formato correcto; los navegadores que no soportan el método de compresión compatible descargarán los datos sin comprimir. Los esquemas de compresión más comunes incluyen gzip y Deflate, sin embargo, una lista completa de los sistemas disponibles es mantenida por la IANA.[2] Además, terceros también desarrollan nuevos métodos y los incluyen en sus productos, por ejemplo, el esquema de Diccionario de Google compartido de compresión a través de HTTP (SDCH) implementado en el navegador Google Chrome y se utiliza en los servidores de Google.
Hay dos formas diferentes en que la compresión se puede hacer 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 cabecera Content-Encoding puede indicar que un recurso que se transfiere, almacena, o referencia está comprimido. La compresión usando Content-Encoding está soportada más ampliamente que Transfer-Encoding, y algunos navegadores no publicitan para la compresión Transfer-Encoding para evitar desencadenar errores en los servidores.[3]
En la mayoría de los casos, excluyendo SDCH, la negociación se hace en dos etapas, como se describe en RFC 2616:
1. El cliente web anuncia qué esquemas de compresión soporta incluyendo una lista de tokens en el HTTP request. Para Content-Encoding, la lista en un campo llamado Accept-Encoding; para Transfer-Encoding, el campo se llama TE.
GET /encrypted-area HTTP/1.1 Host: www.example.com Accept-Encoding: gzip, deflate
2. Si el servidor soporta uno o más esquemas de compresión, los datos salientes pueden ir comprimidos de una o más formas soportados por ambas partes. Si este es el caso, el servidor agregará un campo Content-Encoding o Transfer-Encoding en la respuesta HTTP con los esquemas usados, separados por comas.
HTTP/1.1 200 OK Date: mon, 21 mar 2025 22:38:34 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip
El servidor web no está para nada obligado a usar algún método de compresión - esto depende de la configuración del servidor web y también puede depender en la arquitectura interna del sitio web en cuestión.
En el caso de SDCH, se requiere una negociación de diccionario adicional, lo que puede involucrar pasos adicionales, como descargar un diccionario apropiado desde el servidor externo.
Tokens de Content-Encoding
La lista oficial de tokens disponible para servidores y clientes es mantenida por IANA,[4] e incluye:
- compress - método del programa UNIX "compress" (histórico; obsoleto en la mayoría de aplicaciones y sustituido por gzip o deflate)
- deflate - compresión basada en el algoritmo deflate (descrito en RFC 1951), envuelto en el interior del formato de datos zlib (RFC 1950);
- exi - Intercambio Eficiente de XML de W3C
- gzip - formato zip GNU (que se describe en el RFC 1952). Este método es el de más amplio soporte a marzo de 2011.[5]
- identity - 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[6]
Además de éstos, un número de tokens no oficiales o no normalizados se utilizan libremente tanto por servidores o clientes:
- bzip2 - compresión basada en el formato libre bzip2, soportado por [lighttpd][7]
- LZMA - compresión basada en (cruda) LZMA está disponible en Opera 20, y en elinks a través de una opción en tiempo de compilación[8]
- peerdist[9] - caché y Recuperación de contenido entre pares de Microsoft
- SDCH[10][11] - Google compresión de HTTP por diccionario compartido, basado en VCDIFF (RFC 3284); soportado en forma nativa en las últimas versiones de Google Chrome, Chromium y Android, así como en los sitios web de Google.
- xz - compresión basada en LZMA2 contenido, soportada con un parche no oficial de Firefox;[12] y aplicado plenamente en mget desde 2013-12-31.[13]
Servidores que soportan compresión HTTP
- SAP NetWeaver
- Microsoft IIS: incorporado o utilizando un módulo de terceros.
- Apache HTTP Server, vía mod_deflate (a pesar de su nombre, solo soporta gzip[14])
- Hiawatha HTTP server: entrega archivos pre-comprimidos[15]
- Cherokee HTTP server, comprime gzip y deflate en línea
- Oracle iPlanet Web Server
- Zeus Web Server
- lighttpd, vía mod_compress y el más nuevo mod_deflate (1.5.x)
- nginx – incorporado
- Las aplicaciones basadas en Tornado, si se fija "compress_response" en Verdadero (True) en la configuración (para versiones previas a 4.0, poner "gzip" en verdadero)
- Jetty Server – incorporado en proveerr contenido estático por omisión y disponible vía configuraciones de filtros de servlets
- GeoServer
- Apache Tomcat
- IBM Websphere
- AOLserver
- Ruby Rack, a través del middleware Rack::Deflater
La compresión en HTTP puede lograrse también usando la funcionalidad de lenguajes de programación del lado del servidor como PHP, o lenguajes de programación como Java.
