web-dev-qa-db-ja.com

Apacheが提供するテキストファイルにgzipではなくdeflateを使用する理由

LAMPサーバーが提供するHTML、CSS、およびJavaScriptファイルに対して、どちらの方法が提供する利点は何ですか。より良い代替手段はありますか？

サーバーは、Jsonを使用して大量の小さなファイルを使用して、地図アプリケーションに情報を提供します。

も参照してください http圧縮のためにgzipでdeflateを選択するとパフォーマンスに影響がありますか？

apachecompressiongziplampdeflate
208
Ken

Apacheが提供するテキストファイルにgzipではなくdeflateを使用する理由

簡単な答えはdo n'tです。

RFC 2616 deflateを次のように定義します：

deflate RFC 1951で説明されている「deflate」圧縮メカニズムと組み合わせて、RFC 1950で定義されている「zlib」形式

Zlib形式は RFC 195 で次のように定義されています：

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

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

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

そのため、いくつかのヘッダーとADLER32チェックサム

RFC 2616は、gzipを次のように定義しています。

gzip RFC 1952 [25]に記述されているファイル圧縮プログラム "gzip"（GNU Zip）によって生成されるエンコード形式。この形式は、32ビットCRCを使用したLempel-Zivコーディング（LZ77）です。

RFC 1952 は、圧縮データを次のように定義します。

現在、この形式はDEFLATE圧縮方式を使用していますが、他の圧縮方式を使用するように簡単に拡張できます。

CRC-32は ADLER32よりも遅い

同じ長さの巡回冗長検査と比較して、速度と信頼性を犠牲にします（後者を優先します）。

だから...圧縮にsameアルゴリズムを使用する2つの圧縮メカニズムがありますが、differentヘッダーとチェックサムのアルゴリズム。

現在、基礎となるTCPパケットはすでに かなり信頼できる であるため、ここでの問題はGZIPが使用するAdler 32 vs CRC-32 ではありません。

長年にわたって多くのブラウザが誤ったデフレートアルゴリズムを実装していたことが判明しました。 RFC 1950のzlibヘッダーを期待する代わりに、彼らは単に圧縮されたペイロードを期待していました。同様に、さまざまなWebサーバーが同じ間違いを犯しました。

そのため、ブラウザーは長年にわたってファジーロジックdeflate実装の実装を開始し、ペイロードの試行に失敗した場合はzlibヘッダーとadlerチェックサムを試行します。

そのような複雑なロジックを使用すると、多くの場合破損します。 Verve Studioには、状況がどれほど悪いかを示す ユーザー提供テスト セクションがあります。

たとえば、deflateはSafari 4.0では機能しますが、Safari 5.1では壊れています。IEでも常に問題が発生します。

だから、行うべき最善のことは完全に空気を抜くことを避けることです、マイナーな速度ブースト（アドラー32による）は壊れたペイロードのリスクの価値はありません。

308
Sam Saffron

GZipは単にdeflateとチェックサムとヘッダー/フッターです。 Deflateは高速です、ただし 私は苦労しました

gzip vs deflate graph

169
Jeff Atwood

実際には、オプションとしてデフレートを選択することはできません。 mod_deflateは、deflateではなくgzipを使用しています。そのため、作成されたポイントのほとんどは有効ですが、ほとんどの場合は関係ありません。

15
Amblyopius

Gzipは基本的にdeflateにラップされたヘッダーにすぎないため、deflateとgzipの間に大きな違いはないと思います（RFC 1951および1952を参照）。

4
schnaader

主な理由は、deflateはgzipよりもエンコードが速く、ビジーなサーバーでは違いが生じる可能性があるためです。静的なページでは、1回簡単に事前圧縮できるため、別の質問になります。

3
Joachim Sauer

mod_deflateを使用すると、サーバー上で必要なリソースが少なくなりますが、圧縮量に関してわずかなペナルティを支払うことができます。

多数の小さなファイルを提供している場合は、圧縮および非圧縮ソリューションのベンチマークと負荷テストをお勧めします-圧縮を有効にしても節約にならない場合があります。

1
Dave R.

Gzipに違いがあってはなりません。 Gzipは、チェックサムを含む数ダースのバイトヘッダーでラップされているだけの収縮です。チェックサムが、圧縮が遅い理由です。ただし、何十億ものファイルを事前に圧縮する場合、それらのチェックサムをファイルシステムの健全性チェックとして使用する必要があります。さらに、コマンドラインツールを使用して、ファイルの統計情報を取得できます。このサイトでは、大量の静的データ（オープンディレクトリ全体、13,000ゲーム、数百万のキーワードのオートコンプリートなど）を事前に圧縮しており、AlexaのすべてのWebサイトよりも95％早くランク付けされています。 Faxo Search 。ただし、自社開発の独自のWebサーバーを利用しています。 Apache/mod_deflateはそれをカットしませんでした。これらのファイルがファイルシステムに圧縮されると、ファイルシステムの最小ブロックサイズでファイルがヒットするだけでなく、ウェブサーバーがあまり気にしないファイルシステムでファイルを管理する際の不必要なオーバーヘッドが発生します。懸念事項は、ディスクの総フットプリントとアクセス/解凍時間、およびこのデータを事前に圧縮できる速度の二次的なものです。ディスク領域は安価ですが、キャッシュにできるだけ収まるようにするため、フットプリントは重要です。

0
Steven