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.
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. 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.
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.
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.
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.
La lista oficial de tokens disponible para servidores y clientes es mantenida por IANA, e incluye:
Además de éstos, un número de tokens no oficiales o no normalizados se utilizan libremente tanto por servidores o clientes:
La compresión en HTTP puede lograrse también usando la funcionalidad de lenguajes de Script del lado del servidor como PHP, o lenguajes de programación como Java.
Un artículo de 2009 por Arvind Jain y Jason Glasgow, ingenieros de Google, afirma que más de 99 personas-año se desperdician diariamente debido al mayor tiempo de carga de las páginas cuando los usuarios no reciben contenido comprimido. Esto ocurre cuando el software anti-virus interfiere con conexiones para obligarlas a ir sin compresión, donde se usan proxies (con navegadores demasiado reticentes), donde los servidores están mal configurados, y donde los errores del navegador impiden usar compresión. Internet Explorer 6, que cae a HTTP 1.0 (sin funciones como la compresión o la canalización) cuando está detrás de un proxy - una configuración común en entornos corporativos - era el navegador dominante más propensos a bajar a HTTP sin comprimir.
Otro problema encontrado durante la implementación de la compresión HTTP en gran escala es debido a la definición de codificación de deflate: mientras HTTP 1.1 define la codificación de deflate como datos comprimidos con deflate (RFC 1951) dentro de una corriente de zlib formateado (RFC 1950), los productos de servidor y cliente de Microsoft históricamente lo implementaron como una corriente desinflado "en bruto", lo que hace su implementación no fiable. Por esta razón, algunos programas, incluyendo el Apache HTTP Server, sólo implementan la codificación gzip.
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 trabajar eficazmente contra un gran número de protocolos, incluyendo pero no limitado a TLS, y protocolos de capa de aplicación, tales como SPDY o HTTP, sólo exploits contra TLS y SPDY fueron demostrados y en gran medida mitigados en los navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que los autores de CRIME han advertido que esta vulnerabilidad podría ser aún más extendida que la compresión combinada de SPDY y TLS.
En 2013, fue publicado una nueva instancia del ataque CRIME contra la compresión HTTP, llamado BREACH. Un ataque BREACH puede extraer tokens de acceso, direcciones de correo electrónico u otra información sensible desde tráfico web encriptado con TLS en tan sólo 30 segundos (dependiendo del número de bytes a ser extraídos), 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 encriptación o cifrado utilizado. A diferencia de los casos anteriores de CRIME, que se pueden defender con éxito apagando la compresión TLS o compresión de cabecera SPDY, los BREACH explotan la compresión HTTP la cual no puede ser apagada realmente, ya que prácticamente todos los servidores web se basan en ella para mejorar las velocidades de transmisión de datos para los usuarios.
Escribe un comentario o lo que quieras sobre Compresión HTTP (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)