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

LAMPサーバーによって提供されるhtml、css、およびjavascriptファイルに対して、どちらの方法が提供する利点は何ですか。より良い代替案はありますか？

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

参照http圧縮にdeflateよりもgzipを選択すると、パフォーマンスに影響がありますか？

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

簡単な答えは「しない」です。

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

deflate RFC 1950で定義された「zlib」フォーマットと、RFC 1951で説明されている「deflate」圧縮メカニズムとの組み合わせ

zlib形式はRFC 1950で次のように定義されています。

     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より遅い

同じ長さの巡回冗長検査と比較すると、信頼性と速度（後者を優先）がトレードオフになります。

つまり...圧縮には同じアルゴリズムを使用するが、ヘッダーとチェックサムには異なるアルゴリズムを使用する2つの圧縮メカニズムがあります。

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

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

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

このような複雑なロジックを使用すると、しばしば壊れてしまいます。Verve Studioには、状況がいかに悪いかを示すユーザー寄稿のテストセクションがあります。

たとえば、deflateはSafari 4.0では機能しますが、Safari 5.1では機能しません。IEでも常に問題があります。

したがって、最善の策は、空気を完全に抜くことを避けることです。（アドラー32による）わずかな速度の向上は、ペイロードが壊れるリスクに値しません。

GZipは、デフレートに加えて、チェックサムとヘッダー/フッターです。ただし、難しい方法を学んだため、Deflateの方が高速です。

オプションとして実際に収縮を選択することはできません。mod_deflateがdeflateではなくgzipを使用しているのとは反対です。したがって、指摘されたほとんどの点は有効ですが、それはほとんどの場合適切ではありません。

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

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

mod_deflateを使用すると、サーバー上で必要なリソースが少なくなりますが、圧縮量の点でわずかなペナルティを支払う場合があります。

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

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

Apache2とdeflateモジュールがインストールされているUbuntu（デフォルト）は、2つの簡単な手順でdeflate gzip圧縮を有効にできます。

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

そして、あなたは離れています！私は、adsl接続を介して提供したページがはるかに速く読み込まれるのを見つけました。

編集： @GertvandenBergのコメントによると、これはデフレートではなくgzip圧縮を有効にします。

もし私が正確に覚えていれば

• gzipはdeflateより少し圧縮します
• deflateの方が効率的です