¿Por qué usar desinflar en lugar de gzip para archivos de texto servidos por Apache?

¿Qué ventajas ofrecen los métodos para los archivos html, css y javascript servidos por un servidor LAMP? ¿Hay mejores alternativas?

El servidor proporciona información a una aplicación de mapa utilizando Json, por lo que un gran volumen de archivos pequeños.

Ver también ¿Hay algún golpe de rendimiento involucrado al elegir gzip sobre deflate para compresión http?

¿Por qué usar desinflar en lugar de gzip para archivos de texto servidos por Apache?

La respuesta simple es no .


RFC 2616 define deflate como:

deflate El formato “zlib” definido en RFC 1950 en combinación con el mecanismo de compresión “desinflar” descrito en RFC 1951

El formato zlib se define en RFC 1950 como:

0 1 +---+---+ |CMF|FLG| (more-->) +---+---+ 0 1 2 3 +---+---+---+---+ | DICTID | (more-->) +---+---+---+---+ +=====================+---+---+---+---+ |...compressed data...| ADLER32 | +=====================+---+---+---+---+ 

Entonces, algunos encabezados y una sum de comprobación ADLER32

RFC 2616 define gzip como:

gzip Formato de encoding producido por el progtwig de compresión de archivos “gzip” (GNU zip) como se describe en RFC 1952 [25]. Este formato es una encoding Lempel-Ziv (LZ77) con un CRC de 32 bits.

RFC 1952 define los datos comprimidos como:

El formato actualmente usa el método de compresión DEFLATE, pero se puede extender fácilmente para usar otros métodos de compresión.

CRC-32 es más lento que ADLER32

En comparación con una verificación de redundancia cíclica de la misma longitud, intercambia confiabilidad por velocidad (prefiriendo la última).

Entonces … tenemos 2 mecanismos de compresión que usan el mismo algoritmo para compresión, pero un algoritmo diferente para encabezados y sum de comprobación.

Ahora, los paquetes TCP subyacentes ya son bastante confiables , por lo que el problema aquí no es Adler 32 vs CRC-32 que usa GZIP.


Resulta que muchos navegadores a lo largo de los años implementaron un algoritmo de desinflado incorrecto. En lugar de esperar el encabezado zlib en RFC 1950, simplemente esperaban la carga comprimida. Del mismo modo, varios servidores web cometieron el mismo error.

Por lo tanto, a lo largo de los años, los navegadores comenzaron a implementar una implementación de deflación de lógica difusa , intentan por el encabezado zlib y la sum de verificación adler; si eso falla, intentan usar la carga útil.

El resultado de tener una lógica compleja como esa es que a menudo se rompe. Verve Studio tiene una sección de prueba aportada por el usuario que muestra cuán mala es la situación.

Por ejemplo: desinflar funciona en Safari 4.0 pero está roto en Safari 5.1, también siempre tiene problemas en IE.


Entonces, lo mejor que se puede hacer es evitar la deflación por completo, el aumento de velocidad menor (debido a adler 32) no justifica el riesgo de cargas rotas.

GZip simplemente se desinfla más una sum de comprobación y un encabezado / pie de página. Sin embargo, desinflar es más rápido , ya que aprendí de la manera difícil.

gzip vs deflate gráfico

Es probable que no puedas elegir desinflar como una opción. Contrariamente a lo que puede esperar, mod_deflate no está usando desinflar sino gzip. Entonces, aunque la mayoría de los puntos son válidos, probablemente no sean relevantes para la mayoría.

La razón principal es que desinflar es más rápido de codificar que gzip y en un servidor ocupado que puede hacer la diferencia. Con páginas estáticas es una pregunta diferente, ya que pueden precomprimirse fácilmente una vez.

Creo que no hay gran diferencia entre desinflar y gzip, porque gzip básicamente es solo un encabezado alrededor del desinflado (ver RFCs 1951 y 1952).

mod_deflate requiere menos recursos en su servidor, aunque puede pagar una pequeña penalización en términos de la cantidad de compresión.

Si está entregando muchos archivos pequeños, le recomendaría comparar y cargar sus soluciones comprimidas y no comprimidas; es posible que encuentre algunos casos en los que la habilitación de la compresión no genere ahorros.

No debería haber ninguna diferencia en gzip y desinflar para la descompresión. Gzip simplemente se desinfla con un encabezado de algunas docenas de bytes alrededor, incluyendo una sum de comprobación. La sum de comprobación es la razón de la compresión más lenta. Sin embargo, cuando precomprime billones de archivos, quiere esas sums de comprobación como una verificación de cordura en su sistema de archivos. Además, puede utilizar las herramientas de línea de comando para obtener estadísticas en el archivo. Para nuestro sitio estamos precomprimiendo una tonelada de datos estáticos (todo el directorio abierto, 13,000 juegos, autocompletar para millones de palabras clave, etc.) y estamos clasificados 95% más rápido que todos los sitios web por Alexa. Faxo Search . Sin embargo, sí utilizamos un servidor web propietario propio. Apache / mod_deflate simplemente no lo cortó. Cuando esos archivos se comprimen en el sistema de archivos, no solo se acelera el archivo con el tamaño mínimo de bloque del sistema de archivos, sino que se hace cargo de todos los gastos innecesarios al administrar el archivo en el sistema de archivos que al servidor web no le importa. Sus preocupaciones deben ser la huella total del disco y el tiempo de acceso / descompresión y, en segundo lugar, la velocidad para poder precomprimir estos datos. La huella es importante porque, a pesar de que el espacio en disco es económico, se necesita tanto como sea posible para caber en la memoria caché.

En Ubuntu con Apache2 y el módulo de desinflado ya instalado (que es por defecto), puede habilitar la compresión deflag de gzip en dos sencillos pasos:

 a2enmod deflate /etc/init.d/apache2 force-reload 

¡Y estás lejos! Encontré las páginas que serví sobre mi conexión adsl cargadas mucho más rápido.

Editar: Según el comentario de @ GertvandenBerg, esto permite la compresión de gzip, no desinflar.

si recuerdo correctamente

  • gzip se comprimirá un poco más que desinflar
  • desinflar es más eficiente