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

215

Quels sont les avantages des deux méthodes pour les fichiers html, css et javascript servis par un serveur LAMP. Y a-t-il de meilleures alternatives?

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

Voir aussi Y a-t-il un impact sur les performances dans le choix de gzip plutôt que de dégonfler pour la compression http?

apache compression gzip lamp deflate Ken
la source
inversé les réponses acceptées ... le consensus actuel est de deux contre un en faveur de gzip
Ken
1
mod_deflate est pour Apache 2, mod_gzip est pour Apache 1.3.
SPRBRN du

Réponses:

315

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

La réponse simple est non .

La RFC 2616 définit le dégonflage comme:

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

Le format zlib est défini dans la 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 de codage produit par le programme de compression de fichiers "gzip" (GNU zip) comme décrit dans la RFC 1952 [25]. Ce format est un codage Lempel-Ziv (LZ77) avec un CRC 32 bits.

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

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

CRC-32 est plus lent que ADLER32

Par rapport à un contrôle de redondance cyclique de même longueur, il échange la fiabilité contre la vitesse (préférant ce dernier).

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

Maintenant, les paquets TCP sous-jacents sont déjà assez fiables , donc le problème ici n'est pas Adler 32 vs CRC-32 que GZIP utilise.

Il s'avère que de nombreux navigateurs au fil des ans ont mis en œuvre un algorithme de dégonflage incorrect. Au lieu d'attendre l'en-tête zlib dans la RFC 1950, ils s'attendaient simplement à la charge utile compressée. De même, divers serveurs Web ont fait la même erreur.

Ainsi, au fil des ans, les navigateurs ont commencé à implémenter une implémentation de dégonflage de logique floue , ils essaient pour l'en-tête zlib et la somme de contrôle adler, si cela échoue, ils essaient pour la charge utile.

Le résultat d'une logique complexe comme celle-ci est qu'elle est souvent brisée. Verve Studio a une section de test contribuée par l'utilisateur qui montre à quel point la situation est mauvaise.

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

Donc, la meilleure chose à faire est d'éviter complètement le dégonflage, l'augmentation de vitesse mineure (due à l'adler 32) ne vaut pas le risque de charges utiles cassées.

Sam Saffron
la source
Ne devrait-il pas y avoir une nouvelle norme qui combine adler32 avec gzip?
Pacerier
1
@Sam Saffron, cela signifie-t-il que si le navigateur Web n'est pas dans l'image, je peux utiliser le dégonflage sur gzip? Par exemple, si je vais télécharger un fichier compressé sur mon serveur FTP.
Xegara
1
Une autre différence très mineure est que l'encapsuleur zlib est de six octets contre 18 octets pour gzip. Ainsi, pour les très petits paquets, il peut être avantageux d'envoyer 12 octets de moins. La conclusion ne change pas cependant, ce qui est dû au fait que Microsoft l'a vissé pour tout le monde en interprétant mal ce que "dégonfler" signifiait dans ce qu'ils ont livré sur leurs serveurs IIS, il est plus facile d'utiliser simplement le format gzip.
Mark Adler
Mais comment la charge utile pourrait-elle être rompue, si elle est transmise via TCP? L'idée de TCP est de transmettre des charges utiles ininterrompues.
user1095108
Cette réponse date de 2012. Les navigateurs modernes souffrent-ils toujours du problème de l'implémentation incorrecte des algorithmes de dégonflage ou est-il sûr de l'utiliser maintenant? Cette partie de la réponse est-elle toujours à jour?
ihebiheb
172

GZip est simplement dégonflé plus une somme de contrôle et un en-tête / pied de page. Le dégonflage est plus rapide , cependant, comme je l'ai appris à la dure.

gzip vs graphique de dégonflage

Jeff Atwood
la source
13
Sans oublier que zlib ne prend pas en charge l'extension, et même si c'est le cas, l'instruction CRC32 dans SSE 4.2 utilise le polynôme 1EDC6F41, et le format gzip utilise le polynôme EDB88320 - des algorithmes totalement différents, efficacement.
Jack Lloyd
7
Et comme le dégonflage est plus rapide, pourquoi SO utilise-t-il gzip?
David Murdoch
40
Eh bien, cette réponse s'avère incorrecte ... voir: zoompf.com/blog/2012/02/lose-the-wait-http-compression ... en particulier, le client dispose de 2 façons pour "interpréter" le dégonflage, sans en-tête / sans somme de contrôle et avec en-tête zlib. L'implémentation sur les navigateurs d'un dégonflage correct est mauvaise. dégonfler doit être évité.
Sam Saffron
4
@sam en plus je viens de relancer les benchmarks et sur une puce Intel moderne, j'obtiens gzip 1441/692 et je dégonfle 1286/531. Le deuxième nombre est décompresser, le premier est compresser. Le dégonflage est donc encore plus rapide, vos repères indiquent-ils le contraire? (Je suis d'accord que cela peut ne pas être utile pour d'autres raisons, mais la réponse est correcte , le dégonflage est plus rapide ..)
Jeff Atwood
6
@JeffAtwood mais la question n'a pas été plus rapide?
Ken
16

Vous n'êtes probablement pas en mesure de choisir le dégonflage en option. Contrairement à ce à quoi vous pouvez vous attendre, mod_deflate n'utilise pas deflate mais gzip. Ainsi, bien que la plupart des arguments avancés soient valables, cela n'est probablement pas pertinent pour la plupart.

Amblyopius
la source
4

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

schnaader
la source
3

La raison principale est que le dégonflage est plus rapide à coder que gzip et sur un serveur occupé qui pourrait faire une différence. Avec les pages statiques, c'est une question différente, car elles peuvent facilement être précompressées une fois.

Joachim Sauer
la source
sans doute avec gzip, vous ne pouvez pas commencer à transmettre l'en-tête avant d'avoir obtenu, stocké et compressé toutes les données? (parce que vous avez besoin de la somme de contrôle pour créer l'en-tête)
OJW
8
Dans le format gzip, la somme de contrôle vient à la fin du fichier, spécifiquement pour que l'on puisse commencer à écrire des blocs de dégonflage pendant qu'ils sont traités sans avoir à tout retenir.
Jack Lloyd
2

mod_deflate nécessite moins de ressources sur votre serveur, bien que vous puissiez payer une petite pénalité en termes de quantité de compression.

Si vous servez de nombreux petits fichiers, je vous recommande de comparer et de tester la charge de vos solutions compressées et non compressées - vous pouvez trouver des cas où l'activation de la compression n'entraînera pas d'économies.

Dave R.
la source
Pour ceux qui se demandent, avec le dégonflage, mes fichiers texte passent de 30 Ko à 10 Ko - les fichiers doivent donc être encore plus petits pour ne pas économiser. Je suppose que moins de 1 Ko ou quelque chose de similaire.
hextech
0

Il ne devrait pas y avoir de différence entre gzip et dégonflage pour la décompression. Gzip est simplement dégonflé avec un en-tête de quelques dizaines d'octets enroulé autour, y compris une somme de contrôle. La somme de contrôle est la raison de la compression plus lente. Cependant, lorsque vous précompressez des millions de fichiers, vous voulez que ces sommes de contrôle soient un test de cohérence dans votre système de fichiers. De plus, vous pouvez utiliser des outils de ligne de commande pour obtenir des statistiques sur le fichier. Pour notre site, nous précompressons une tonne de données statiques (l'ensemble du répertoire ouvert, 13 000 jeux, la saisie semi-automatique pour des millions de mots-clés, etc.) et nous sommes classés 95% plus rapidement que tous les sites Web par Alexa. Recherche Faxo. Cependant, nous utilisons un serveur Web propriétaire développé localement. Apache / mod_deflate ne l'a tout simplement pas coupé. Lorsque ces fichiers sont compressés dans le système de fichiers, non seulement vous prenez un coup pour votre fichier avec la taille minimale du bloc de système de fichiers, mais tout le surcoût inutile dans la gestion du fichier dans le système de fichiers dont le serveur Web se soucie peu. Vos préoccupations doivent être l'empreinte totale du disque et le temps d'accès / de décompression et, accessoirement, la vitesse d'obtention de ces données précompressées. L'encombrement est important car même si l'espace disque est bon marché, vous souhaitez autant que possible tenir dans le cache.

Steven
la source
GZip vérifie probablement la somme de contrôle sur la décompression, d'où la différence de vitesse pour la décompression.
Seun Osewa
-1

Sur Ubuntu avec Apache2 et le module dégonfler déjà installé ( ce qui est par défaut), vous pouvez activer dégonfler la compression gzip en deux étapes:

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

Et tu es parti! J'ai trouvé les pages que j'ai diffusées via ma connexion adsl chargées beaucoup plus rapidement.

Edit: Selon le commentaire de @ GertvandenBerg, cela permet la compression gzip, pas le dégonfler.

aidan
la source
6
Sauf que cela active gzip, puisque mod_deflate implémente de manière confuse uniquement la compression gzip ...
Gert van den Berg
@GertvandenBerg J'ai mis à jour ma réponse, mais pour mémoire, gzip est dégonflé, juste avec des en-têtes supplémentaires et une somme de contrôle
aidan
@aiden yep mais la somme de contrôle a un impact sur les performances ... (et le dégonflage brut n'est pas conforme aux normes)
Gert van den Berg
-4

si je me souviens bien

  • gzip compressera un peu plus que dégonfler
  • dégonfler est plus efficace
JimmyJ
la source
2
gzip est dégonflé avec un en-tête. Et le dégonflage HTTP 1.1 est en fait zlib (qui est également un wrapper autour du dégonflage)
David Murdoch