Pourquoi utiliser deflate au lieu de gzip pour les fichiers texte servis par Apache?
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, générant ainsi un volume élevé de petits fichiers.
Pourquoi utiliser deflate au lieu de gzip pour les fichiers texte servis par Apache?
La réponse simple est non .
RFC 2616 définit déflater comme suit:
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 195 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 suit:
gzip Format de codage produit par le programme de compression de fichier "gzip" (GNU Zip) décrit dans la RFC 1952 [25]. Ce format est un codage Lempel-Ziv (LZ77) avec un CRC 32 bits.
RFC 1952 définit les données compressées comme suit:
Le format utilise actuellement la méthode de compression DEFLATE mais peut être facilement étendu à d’autres méthodes de compression.
Le CRC-32 est plus lent que ADLER32
Comparé à un contrôle de redondance cyclique de même longueur, il négocie la fiabilité pour la vitesse (préférant cette dernière).
Donc ... nous avons 2 mécanismes de compression qui utilisent le même algorithme pour la compression, mais un différent algorithme pour les en-têtes et la somme de contrôle.
Maintenant, les paquets sous-jacents TCP sont déjà assez fiables , le problème ici n'est donc pas Adler 32 vs CRC-32 utilisé par GZIP.
Au fil des années, de nombreux navigateurs ont implémenté un algorithme de déflation incorrect. Au lieu d'attendre l'en-tête zlib dans RFC 1950, ils s'attendaient simplement à la charge compressée. De même, différents serveurs Web ont commis la même erreur.
Ainsi, au fil des années, les navigateurs ont commencé à implémenter une implémentation à logique floue , ils essaient l’en-tête zlib et la somme de contrôle adler, s’ils échouent, ils essaient la charge utile.
Le résultat d’une telle logique est qu’elle est souvent brisée. Verve Studio a une section test utilisateur qui montre à quel point la situation est grave.
Par exemple: deflate fonctionne dans Safari 4.0 mais est cassé dans Safari 5.1, il a toujours des problèmes avec IE.
La meilleure chose à faire est donc d'éviter tout dégonflement, le gain de vitesse mineur (dû à l'adler 32) ne vaut pas le risque de rupture de charge utile.
GZip est simplement dégonfler 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.
Vous êtes probablement pas en mesure de choisir réellement dégonfler comme une option. Contrairement à ce à quoi vous pouvez vous attendre mod_deflate n’utilise pas deflate mais gzip. Ainsi, bien que la plupart des points soulevés soient valables, ils ne le sont probablement pas pour la plupart.
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 enroulé autour de deflate (voir RFC 1951 et 1952).
La raison principale est que deflate est plus rapide à encoder que gzip et sur un serveur occupé qui pourrait faire la différence. Avec les pages statiques, la question est différente, car elles peuvent facilement être pré-compressées une fois.
mod_deflate nécessite moins de ressources sur votre serveur, bien que vous puissiez payer une légère pénalité en termes de compression.
Si vous gérez de nombreux petits fichiers, nous vous recommandons d'effectuer une analyse comparative et de tester en charge vos solutions compressées et non compressées. Dans certains cas, l'activation de la compression n'entraînera aucune économie.
Il ne devrait y avoir aucune différence dans gzip et dégonfler pour la décompression. Gzip est juste dégonflé avec une en-tête de quelques dizaines d'octets entourée, incluant une somme de contrôle. La somme de contrôle est la raison de la compression plus lente. Toutefois, lorsque vous précompressez des zillions de fichiers, vous souhaitez que ces sommes de contrôle soient utilisées comme contrôle de cohérence dans votre système de fichiers. De plus, vous pouvez utiliser des outils en ligne de commande pour obtenir des statistiques sur le fichier. Pour notre site, nous précomprimons une tonne de données statiques (tout l'annuaire ouvert, 13 000 jeux, la saisie semi-automatique pour des millions de mots-clés, etc.) et nous sommes classés 95% plus vite 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 hit pour votre fichier avec la taille de bloc minimale du système de fichiers mais tout le temps système nécessaire à la gestion du fichier dans le système de fichiers, ce que le serveur Web se moque bien. Vos préoccupations doivent être l'encombrement total du disque et le temps d'accès/de décompression, puis la rapidité avec laquelle vous pouvez obtenir ces données précompressées. L’empreinte est importante car, même si l’espace disque est bon marché, vous souhaitez, autant que possible, tenir dans le cache.