[解決済み】Apacheで提供されるテキストファイルにgzipの代わりにdeflateを使用するのはなぜですか？

質問

LAMPサーバーで提供されるhtml, css, javascriptファイルには、どちらの方法がどのような利点があるのでしょうか。また、より良い選択肢はありますか？

サーバーから地図アプリケーションにJsonで情報を提供するため、小さなファイルが大量に発生します。

参照 http圧縮にdeflateではなくgzipを選択することで、何かパフォーマンス上の問題がありますか?

どのように解決するのですか？

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

簡単な答えは ドンマイ .

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

deflate RFC1950で定義されたzlib形式と、RFC1951で定義された圧縮機構を組み合わせたもの。

zlib形式は、以下のように定義されています。 RFC 1950 として。

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

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

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

つまり、いくつかのヘッダとADLER32チェックサム

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

gzip ファイル圧縮プログラムによって生成されるエンコード形式 RFC 1952 [25]に記述されている "gzip" (GNU zip)である。この形式は Lempel-Ziv coding (LZ77)に32ビットのCRCを付加したもの。

RFC1952 は、圧縮されたデータを次のように定義しています。

現在、このフォーマットはDEFLATE方式で圧縮されていますが、他の圧縮方式に簡単に拡張することができます。

CRC-32は ADLER32より遅い

同じ長さの巡回冗長検査と比較すると、信頼性と速度をトレードオフしている（後者を好む）。

ということは......2つの圧縮機構があることになりますね。 同じ 圧縮のためのアルゴリズムですが 異なる ヘッダーとチェックサム用のアルゴリズムです。

さて、基盤となるTCPパケットは、すでに かなり信頼できる したがって、ここで問題となるのは、アドラー32対 CRC-32 GZIPが使っている

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

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

このような複雑なロジックを組むと、しばしば壊れてしまいます。Verve Studioでは ユーザー投稿テスト というセクションを設けて、この状況がいかにひどいものかを示しています。

例えば、Safari 4.0ではdeflateは動作しますが、Safari 5.1では壊れ、IEでも常に問題があります。

アドラー32による）わずかな速度向上は、壊れたペイロードのリスクと見合わないのです。