Pourquoi utiliser deflate au lieu de gzip pour les fichiers texte servis par Apache ?

Question

Quels sont les avantages de l'une ou l'autre méthode pour les fichiers html, css et javascript servis par un serveur LAMP ? Existe-t-il de meilleures alternatives ?

Le serveur fournit des informations à une application cartographique en utilisant Json, donc un grand volume de petits fichiers.

Voir aussi Y a-t-il un impact sur les performances en choisissant gzip plutôt que deflate pour la compression http ?

Answer 1

Pourquoi utiliser deflate au lieu de gzip pour les fichiers texte servis par Apache ?

La réponse est simple Ne le fais pas. .

---

RFC 2616 définit deflate comme :

deflate Le format "zlib" défini dans la RFC 1950 en combinaison avec le mécanisme de compression "deflate" décrit dans la RFC 1951.

Le format zlib est défini dans RFC 1950 comme :

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

Donc, quelques en-têtes et une somme de contrôle ADLER32.

La RFC 2616 définit gzip comme :

gzip Un format d'encodage produit par le programme de compression de fichiers "gzip" (GNU zip) tel que décrit dans la RFC 1952 [25]. Ce format est un codage Lempel-Ziv (LZ77) avec un CRC de 32 bits.

RFC 1952 définit les données compressées comme :

Le format utilise actuellement la méthode de compression DEFLATE mais peut facilement être étendu pour utiliser d'autres méthodes de compression.

Le CRC-32 est plus lent que ADLER32

Par rapport à un contrôle de redondance cyclique de même longueur, il troque la fiabilité contre la vitesse (en préférant cette dernière).

Donc ... nous avons 2 mécanismes de compression qui utilisent le système de la même pour la compression, mais un différents pour les en-têtes et la somme de contrôle.

Maintenant, les paquets TCP sous-jacents sont déjà assez fiable donc la question ici n'est pas Adler 32 vs. CRC-32 que GZIP utilise.

---

Il s'avère que de nombreux navigateurs ont implémenté un algorithme deflate incorrect au fil des ans. Au lieu d'attendre l'en-tête zlib de la RFC 1950, ils attendaient simplement la charge utile compressée. De même, plusieurs serveurs web ont fait la même erreur.

Ainsi, au fil des ans, les navigateurs ont commencé à mettre en place une logique floue La mise en œuvre de deflate, ils essaient pour zlib header et adler checksum, si cela échoue ils essaient pour payload.

Le résultat d'une telle logique complexe est qu'elle est souvent brisée. Verve Studio dispose d'un test réalisé par l'utilisateur qui montrent à quel point la situation est mauvaise.

Par exemple : deflate fonctionne dans Safari 4.0 mais est cassé dans Safari 5.1, il a aussi toujours des problèmes sur IE.

---

Donc, la meilleure chose à faire est d'éviter complètement le deflate, le petit gain de vitesse (dû à l'adler 32) ne vaut pas le risque de casser les charges utiles.

Answer 2

GZip est simplement deflate plus une somme de contrôle et un en-tête/pied de page. Deflate est plus rapide cependant, comme J'ai appris à la dure.

Answer 3

Il est probable que vous ne puissiez pas choisir la déflation comme option. Contrairement à ce que vous pourriez croire mod_deflate n'utilise pas deflate mais gzip. Ainsi, bien que la plupart des points soulevés soient valables, ils ne sont probablement pas pertinents pour la plupart des gens.

Answer 4

La raison principale est que deflate est plus rapide à encoder que gzip et sur un serveur occupé, cela peut faire la différence. Avec les pages statiques, la question est différente, car elles peuvent facilement être pré-compressées une fois.

Answer 5

Je pense qu'il n'y a pas de grande différence entre deflate et gzip, car gzip n'est en fait qu'un en-tête enveloppé autour de deflate (voir RFCs 1951 et 1952).