Apache tarafından sunulan metin dosyaları için neden gzip yerine deflate kullanıyorsunuz?

Her iki yöntem de bir LAMP sunucusu tarafından sunulan html, css ve javascript dosyaları için ne gibi avantajlar sağlar? Daha iyi alternatifler var mı?

Sunucu, Json kullanarak bir harita uygulamasına bilgi sağlar, bu nedenle çok sayıda küçük dosya olur.

Ayrıca bkz . Http sıkıştırması için gzip over deflate seçiminde herhangi bir performans isabeti var mı?

Apache tarafından sunulan metin dosyaları için neden gzip yerine deflate kullanıyorsunuz?

Basit cevap yok .

RFC 2616 deflasyonu şu şekilde tanımlar:

deflat RFC 1950'de tanımlanan RFC 1951'de tanımlanan "deflate" sıkıştırma mekanizması ile birlikte tanımlanan "zlib" formatı

Zlib biçimi RFC 1950'de şu şekilde tanımlanır :

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

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

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

Yani, birkaç başlık ve bir ADLER32 sağlama toplamı

RFC 2616, gzip'i şu şekilde tanımlar:

gzip Dosya sıkıştırma programı "gzip" (GNU zip) tarafından RFC 1952'de [25] açıklandığı gibi üretilen bir kodlama formatı. Bu format, 32 bit CRC'li bir Lempel-Ziv kodlamasıdır (LZ77).

RFC 1952 , sıkıştırılmış verileri şu şekilde tanımlar:

Biçim şu anda DEFLATE sıkıştırma yöntemini kullanmaktadır ancak diğer sıkıştırma yöntemlerini kullanmak için kolayca genişletilebilir.

CRC-32, ADLER32'den daha yavaş

Aynı uzunlukta bir döngüsel artıklık kontrolü ile karşılaştırıldığında, hız için güvenilirlik sağlar (ikincisini tercih eder).

Yani ... sıkıştırma için aynı algoritmayı kullanan 2 sıkıştırma mekanizmamız var , ancak başlıklar ve sağlama toplamı için farklı bir algoritma var.

Şimdi, altta yatan TCP paketleri zaten oldukça güvenilir , bu nedenle buradaki sorun Adler 32 vs GZIP'in kullandığı CRC-32 değil.

Yıllar boyunca birçok tarayıcı yanlış bir deflate algoritması uyguladı. RFC 1950'de zlib başlığını beklemek yerine sıkıştırılmış yükü beklediler. Benzer şekilde çeşitli web sunucuları da aynı hatayı yaptı.

Bu nedenle, tarayıcılar yıllar boyunca bulanık bir mantık söndürme uygulamasını uygulamaya başladılar, zlib başlığı ve adler sağlama toplamı için çalışırlar, eğer bu başarısız olursa yük için dener.

Böyle karmaşık bir mantığa sahip olmanın sonucu, genellikle kırılmış olmasıdır. Verve Studio'nun durumun ne kadar kötü olduğunu gösteren kullanıcı katkısı olan bir test bölümü var.

Örneğin: deflate Safari 4.0'da çalışır, ancak Safari 5.1'de bozulur, IE'de de her zaman sorunları vardır.

Bu nedenle, yapılacak en iyi şey, tamamen söndürülmekten kaçınmaktır, küçük hız artışı (adler 32 nedeniyle) kırık yük taşıma riskine değmez.

GZip basitçe deflate artı bir sağlama toplamı ve üstbilgi / altbilgidir. Zor yoldan öğrendiğim gibi, deflasyon daha hızlıdır .

Büyük olasılıkla deflate'i bir seçenek olarak seçemezsiniz. Beklediğinizin aksine mod_deflate deflate değil gzip kullanıyor. Bu nedenle, verilen noktaların çoğu geçerli olsa da, çoğu için geçerli değildir.

Bence deflate ve gzip arasında büyük bir fark yok, çünkü gzip temelde sadece deflate etrafına sarılmış bir başlıktır (bkz. RFC 1951 ve 1952).

Bunun ana nedeni, deflate'in kodlanmasını gzip'ten daha hızlı ve fark yaratabilecek meşgul bir sunucuda olmasıdır. Statik sayfalarda bu farklı bir sorudur, çünkü bunlar bir kez kolayca önceden sıkıştırılabilir.

mod_deflate sunucunuzda daha az kaynak gerektirir, ancak sıkıştırma miktarı açısından küçük bir ceza ödeyebilirsiniz.

Çok sayıda küçük dosyaya hizmet veriyorsanız, sıkıştırılmış ve sıkıştırılmamış çözümlerinizi kıyaslama ve yük testi öneriyorum - sıkıştırmayı etkinleştirmenin tasarrufla sonuçlanmadığı bazı durumlar bulabilirsiniz.

Dekompresyon için gzip & deflate'te herhangi bir fark olmamalıdır. Gzip, bir sağlama toplamı da dahil olmak üzere etrafına sarılmış birkaç düzine bayt başlığıyla söndürülür. Sağlama toplamı daha yavaş sıkıştırmanın nedenidir. Ancak, milyonlarca dosyayı önceden sıkıştırdığınızda, bu sağlama toplamlarını dosya sisteminizde bir sağlık kontrolü olarak kullanmak istersiniz. Buna ek olarak, dosyadaki istatistikleri almak için komut satırı araçlarını kullanabilirsiniz. Sitemiz için bir ton statik veriyi sıkıştırıyoruz (tüm açık dizin, 13.000 oyun, milyonlarca anahtar kelime için otomatik tamamlama, vb.) Ve Alexa tarafından tüm web sitelerinden% 95 daha hızlı sıralanıyoruz. Faks Arama. Ancak, evde yetiştirilen özel bir web sunucusu kullanıyoruz. Apache / mod_deflate kesmedi. Bu dosyalar dosya sistemine sıkıştırıldığında, yalnızca minimum dosya sistemi blok boyutuyla dosyanız için bir hit yapmakla kalmaz, aynı zamanda web sunucusunun daha az önem verebileceği dosya sistemindeki dosyayı yönetmede tüm gereksiz yükü de alırsınız. Endişeleriniz toplam disk alanı ve erişim / açma süresi ve bu verileri önceden sıkıştırmak için ikincil hız olmalıdır. Ayak izi önemlidir, çünkü disk alanı ucuz olsa da, önbelleğe mümkün olduğunca sığmasını istersiniz.

Apache2 ve deflate modülünün kurulu olduğu Ubuntu'da (varsayılan olarak) deflate gzip sıkıştırmasını iki kolay adımda etkinleştirebilirsiniz :

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

Ve sen uzaktasın! Adsl bağlantım üzerinden sunduğum sayfaları çok daha hızlı yükledim.

Düzenleme: @ GertvandenBerg'in yorumuna göre, bu gzip sıkıştırma, deflate değil sağlar.

Eğer doğru hatırlıyorsam

• gzip sönükten biraz daha fazla sıkıştırır
• deflate daha verimli