216

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

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

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

4

9 に答える 9

319

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

簡単な答えはしないでください。

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

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

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

     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が使用するAdler32とCRC-32ではありません。

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

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

そのような複雑なロジックを持つことの結果は、それがしばしば壊れているということです。Verve Studioには、状況がいかに悪いかを示すユーザー提供のテストセクションがあります。

例：deflateはSafari 4.0では機能しますが、Safari 5.1では機能しません。また、IEでも常に問題が発生します。

したがって、最善の方法は、収縮を完全に回避することです。マイナーな速度ブースト（adler 32による）は、ペイロードが破損するリスクに見合う価値はありません。

于 2012-03-25T00:20:09.613 に答える
172

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

gzip 対 deflate グラフ

于 2008-12-23T11:00:12.857 に答える
16

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

于 2012-12-12T10:49:21.407 に答える
4

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

于 2008-12-23T10:54:31.060 に答える
4

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

于 2008-12-23T10:56:58.013 に答える
2

mod_deflate を使用すると、サーバーで必要なリソースが少なくなりますが、圧縮量に関してわずかなペナルティが発生する場合があります。

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

于 2008-12-23T11:05:46.670 に答える
0

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

于 2009-10-20T15:51:27.480 に答える
-1

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

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

そして、あなたは離れています！私のadsl接続を介して提供したページの読み込みがはるかに高速であることがわかりました.

編集: @GertvandenBerg のコメントによると、これにより、空気を抜くのではなく、gzip 圧縮が有効になります。

于 2009-04-22T14:18:30.497 に答える
-6

私が正しく覚えていれば

  • gzip は deflate よりも少しだけ圧縮します
  • デフレートはより効率的です
于 2008-12-23T10:56:34.020 に答える