説明 : Description

Everything you wanted to know about web content compression

あなたが知りたかった web コンテンツ圧縮のすべて

基本的なコンテンツ圧縮 : Basics of Content Compression

Compression of outbound Web server traffic provides benefits both for Web clients who see shorter response times, as well as for content providers, who experience lower consumption of bandwidth.

Web サーバトラフィックのアウトバウンドの圧縮は帯域幅の消費削減を体験する, コンテンツプロバイダだけでなく, レスポンスタイムの短縮を確認する Web クライアントの双方にベネフィットを提供します.

Most recently, content compression for web servers has been provided mainly through use of the gzip encoding. Other (non perl) modules are available that provide so-called deflate compression. Both approaches are very similar recently and use the LZ77 algorithm combined with Huffman coding. Luckily for us, to make use of them, there is no real need for most of us to understand all the details of the obscure underlying mathematics of these techniques. Apache handlers available from CPAN can usually do the dirty work. Apache addresses content compression through handlers configured in its configuration file.

ごく最近は, web サーバのコンテンツ圧縮は主に gzip エンコーディングの利用を通じて提供されています. 他の (非 perl) モジュールはいわゆる deflate 圧縮を利用できます. 最近はどちらのアプローチもよく似ていて Huffman コーディングと LZ77 アルゴリズムを組合わせて使います. 私たちにとって幸いなことに, それらを利用するために, 私たちのほとんどはそれらのテクニックの根底にある不明瞭な数学の詳細をすべて理解する必要はマジでありません. CPAN から利用可能な Apache ハンドラは通常汚れ仕事を行います. Apache はその構成ファイルで構成されたハンドラを通じてコンテンツ圧縮に対処します.

Compression is, by its nature, a content filter: It always takes its input as plain ASCII data that it converts to another binary form, and outputs the result to some destination. That is why every content compression handler usually belongs to a particular chain of handlers within the content generation phase of the request-processing flow.

圧縮は, その性質上, コンテンツフィルタです: それはインプットを常にプレーンな ASCII データとして受け取って別のバイナリ形式に変換し, なんらかの宛先にその結果をアウトプットします. そういうわけですべてのコンテンツ圧縮ハンドラは通常リクエスト処理フローでのコンテンツ生成フェーズ内の特定のハンドラチェーンに属します.

A chain of handlers is one more common term that is good to know about when you plan to compress data. There are two of them recently developed for Apache 1.3: Apache::OutputChain and Apache::Filter. We have to keep in mind that the compression handler developed for one chain usually fails inside another.

ハンドラチェーンはあなたがデータ圧縮を計画するときに知っておくとグッドな用語のひとつです. Apache 1.3 用に最近開発されたそれは 2 つあります: Apache::OutputChain と Apache::Filter です. 私たちはあるチェーンのために開発された圧縮ハンドラが通常他の中では失敗することを心に留めておかなければなりません.

Another important point deals with the order of execution of handlers in a particular chain. It's pretty straightforward in Apache::Filter. For example, when you configure...

別の重要なポイントは特定のチェーン内でのハンドラの実行順序を扱います. それは Apache::Filter ではとても簡単です. 例えば, あなたがこのように構成すると...

PerlModule Apache::Filter

<Files ~ "*\.blah">

  SetHandler perl-script

  PerlSetVar Filter On

  PerlHandler Filter1 Filter2 Filter3

</Files>

... コンテンツは最初に Filter1 を通過して, Filter2 によってその結果がフィルタされ, 最後にアウトバウンドのデータで最後の変更をするために Filter3 が呼びだされます.

However, when you configure Apache::OutputChain like...

しかしながら, あなたが Apache::OutputChain をこのように構成すると...

PerlModule Apache::OutputChain

PerlModule Apache::GzipChain

PerlModule Apaceh::SSIChain

PerlModule Apaceh::PassHtml

<Files *.html>

  SetHandler perl-script

  PerlHandler Apaceh::OutpuChain Apache::GzipChain Apache::SSIChain Apaceh::PassHtml

</Files>

...execution begins with Apache::PassHtml. Then the content will be processed with Apache::SSIChain and finally with Apache::GzipChain. Apache::OutputChain will not be involved in content processing at all. It is there only for the purpose of joining other handlers within the chain.

... Apache::PassHtml で実行がはじまります. それからそのコンテンツは Apacehh::SSIChain で最後に Apache::GzipChain で処理されます. Apaceh::OutputChain はコンテンツ処理にまったく関与しません. それはチェーン内で他のハンドラを繋げる目的だけのためにあります.

It is important to remember that the content compression handler should always be the last executable handler in any chain.

コンテンツ圧縮ハンドラは任意のチェーンの中で常に最後に実行されなければならないことを覚えておくことは重要です.

Another important problem of practical implementation of web content compression deals with the fact that some buggy Web clients declare the ability to receive and decompress gzipped data in their HTTP requests, but fail to keep their promises when an actual compressed response arrives. This problem is addressed through the implementation of the Apache::CompressClientFixup handler. This handler serves the fixup phase of the request-processing flow. It is compatible with all known compression handlers and is available from CPAN.

web コンテンツ圧縮の実践的な実装におけるまた別の重要な問題はいくつかのバグのある Web クライアントがその HTTP リクエストで gzip データの受信と展開能力を宣言しているが, 実際に圧縮されたレスポンスが到着したときにはその約束を果たさないという事実に対処することです. この問題は Apache::CompressClientFixup ハンドラの実装を通じて対処されます. このハンドラはリクエスト処理フローの fixup フェーズをサーブします. それはすべての知られた圧縮ハンドラと互換であり CPAN から利用可能です.

Web コンテンツの圧縮はなぜ重要 ? : Why it is important to compress Web content?

設備コストの削減と劇的なページロードの競争上の優位性 : Reduced equipment costs and the competitive advantage of dramatically faster page loads.

Web content compression noticeably increases delivery speed to clients and may allow providers to serve higher content volumes without increasing hardware expenditures. It visibly reduces actual content download time, a benefit most apparent to users of dialup and high-traffic connections.

Web コンテンツ圧縮はクライアントへのデリバリー速度を顕著に向上しプロバイダはハードウェアの出費を増やすことなくよりハイボリュームのコンテンツをサーブできるようにするはずです. 実際それはコンテンツのダウンロードタイムを目に見えて削減しますし, ダイアルアップや高トラフィック接続のユーザへの最も明確なベネフィットです.

Industry leaders like Yahoo and Google are widely using content compression in their businesses.

Yahoo や Google のような業界のリーダ達は彼らのビジネスでコンテンツ圧縮を広く使用しています.

私はどの程度の改善を期待できる ? : How much improvement can I expect?

効果的な圧縮は転送効率で 3 から 20 倍の増加をはたす : Effective compression can achieve increases in transmission efficiency from 3 to 20 times.

The compression ratio is highly content-dependent. For example, if the compression algorithm is able to detect repeated patterns of characters, compression will be greater than if no such patterns exist. You can usually expect to realize an improvement between of 3 to 20 times on regular HTML, JavaScript, and other ASCII content. I have seen peak HTML file compression improvements in excess of more than 200 times, but such occurrences are infrequent. On the other hand I have never seen ratios of less than 2.5 times on text/HTML files. Image files normally employ their own compression techniques that reduce the advantage of further compression.

圧縮比率は高いコンテンツ依存です. 例えば, その圧縮アルゴリズムが文字の繰り返しパターンを検出できる場合, そのようなパターンが存在しない場合よりも (# 存在する方が) 圧縮はよりグレートになります. レギュラーな HTML, JavaScript, その他 ASCCI コンテンツなら通常あなたは 3 から 20 倍の改善の実現を期待できます. 私は最大 200 倍を超える HTML ファイル圧縮の改善を見たことがありますが, そのような出来事はまれです. 一方で私は text/HTML ファイルで 2.5 倍未満の比率を見たことがありません. 普通イメージファイルはそれら独自の圧縮テクニックを採用しているのでさらに圧縮するアドバンテージは少なくなります.

On May 21, 2002 Peter J. Cranstone wrote to the mod_gzip@lists.over.net mailing list:

2002/05/21 に Peter J. Cranstone は mod_gzip@lists.over.net メーリングリストに書きました:

"...With 98% of the world on a dial up modem, all they care about is how long it takes to download a page. It doesn't matter if it consumes a few more CPU cycles if the customer is happy. It's cheaper to buy a newer faster box, than it is to acquire new customers."

"... 世界の 98% のダイアルアップモデムで, 彼らがケアしているのはページのダウンロードがどのくらい時間を取るかについてです. 顧客がハッピーならそれが CPU サイクルが多少多く消費するとしても問題にはなりません. 最新で高速のボックスの購入は安価です, 新しい顧客を獲得するよりも."

既存のサイトでのコンテンツ圧縮の実装はどのくらい難しい ? : How hard is it to implement content compression on an existing site?

既存サイトでのコンテンツ圧縮の実装は典型的にはその Web サイトで適切な Apache ハンドラをインストールして構成するだけ : Implementing content compression on an existing site typically involves no more than installing and configuring an appropriate Apache handler on the Web server.

This approach works in most of the cases I have seen. In some special cases you will need to take extra care with respect to the global architecture of your Web application, but such cases may generally be readily addressed through various techniques. To date I have found no fundamental barriers to practical implementation of Web content compression.

このアプローチは私が見てきたほとんどのケースで機能します. 一部の特別なケースであなたはあなたの Web アプリケーションのグローバルアーキテクチャに関して追加の注意を必要としますが, そのようなケースは通常さまざまなテクニックを通じてたやすく対処できるはずです. Web コンテンツ圧縮の実際の実装についての根本的な障壁を私は今日まで知りません.

標準的な Web ブラウザで圧縮は機能する ? : Does compression work with standard Web browsers?

イエス. クライアントサイドの変更や設定は不要 : Yes. No client side changes or settings are required.

All modern browser makers claim to be able to handle compressed content and are able to decompress it on the fly, transparent to the user. There are some known bugs in some old browsers, but these can be taken into account through appropriate configuration of the Web server.

すべてのモダンなブラウザメーカはユーザには透過的に, 圧縮されたコンテンツを処理可能でありオンザフライでそれを展開できると主張しています. 一部の古いブラウザにはいくつかの知られたバグがありますが, それらは Web サーバの適切な構成を通じて考慮にいれることができます.

I strongly recommend use of the Apache::CompressClientFixup handler in your server configuration in order to prevent compression for known buggy clients.

私は知られたバギーなクライアントでの圧縮を防止するためにあなたのサーバ構成で Apache::CompressClientFixup ハンドラの利用を強く推奨します.

データ暗号化とコンテンツ圧縮の組合わせは可能 ? : Is it possible to combine the content compression with data encryption?

イエス. 圧縮されたコンテンツは暗号化され SSL で安全に送信される : Yes. Compressed content can be encrypted and securely transmitted over SSL.

On the client side, the browser transparently unencrypts and uncompresses the content for the user. It is important to maintain the correct order of operations on server side to keep the transaction secure. You must compress the content first and then apply an encryption mechanism. This is the only order of operations current browsers support.

クライアントサイドでは, ブラウザはユーザに対して透過的にコンテンツを暗号解除し展開します. トランザクションの安全性をキープするにはサーバサイド上でのオペレーションの正しい順序を維持することが重要です. あなたは最初にコンテンツを圧縮しそれから暗号化メカニズムを適用しなければなりません. これは現在のブラウザがサポートする唯一の操作順序です

コンテンツ圧縮でサーバサイドに必要なソフトウェアは ? : What software is required on the server side for content compression?

Apache 1.3 の時点で 4 つの利用可能な Web コンテンツ圧縮のための mod_perl モジュール/パッケージが知られている (アルファベット順) : There are four known mod_perl modules/packages for Web content compression available to date for Apache 1.3 (in alphabetical order):

Apache::Compress

a mod_perl handler developed by Ken Williams (U.S.), Apache::Compress, can generate gzip output through the Apache::Filter. This module accumulates all incoming data and compresses the entire content body as a unit.

Ken Williams (アメリカ) によって開発された mod_perl ハンドラ, Apache::Compress は, Apache::Filter を通じて gzip 出力を生成できます. このモジュールはすべてのインカミングデータを蓄積しコンテンツボディ全体をひとつのユニットとして圧縮します.

Apache::Dynagzip

a mod_perl handler developed by Slava Bizyayev, Apache::Dynagzip uses the gzip format to compress output dynamically through the Apache::Filter or through the internal Unix pipe.

Slava Bizyayev によって開発された mod_perl ハンドラ, Apache::Dynagzip は Apache::Filter を通じてまたは 内部の Unix pipe を通じて動的に出力を圧縮するために gzip フォーマットを使います.

Apache::Dynagzip is most useful when one needs to compress dynamic outbound Web content (generated on the fly from databases, XML, etc.) when content length is not known at the time of the request.

Apache::Dynazip はリクエスト時にコンテンツの長さがわからない (データベース, XML などからオンザフライで生成される) 動的なアウトバウンドの Web コンテンツを圧縮する必要がある場合にもっとも便利です.

Apache::Dynagzip's features include:

Apache::Dynazip はこれらの機能を含みます:

• 
  

  Support for both HTTP/1.0 and HTTP/1.1.

  
  HTTP/1.0 と HTTP/1.1 両方のサポート.


• 
  

  Control over the chunk size on HTTP/1.1 for on-the-fly content compression.

  
  HTTP/1.1 でオンザフライでコンテンツ圧縮するためのチャンクサイズの制御.
  


• 
  

  Support for Perl, Java, or C/C++ CGI applications.

  
  Perl, Java, または C/C++ CGI アプリケーションのサポート.
  


• 
  

  Advanced control over the proxy cache with the configurable Vary HTTP header.

  
  構成可能な Vary HTTP ヘッダによるプロキシキャッシュの高度な制御.
  


• 
  

  Optional control over content lifetime in the client's local cache with the configurable Expires HTTP header.

  
  構成可能な Expires HTTP ヘッダによるクライアントのローカルキャッシュ内のコンテンツのライフタイムのオプション制御
  


• 
  

  Optional support for server-side caching of the dynamically generated (and compressed) content.

  
  動的に生成 (かつ圧縮された) されたコンテンツをサーバサイドでキャッシュするためのオプション制御.
  


• 
  

  Optional extra-light compression

  
  オプションの拡張軽量圧縮
  

  removal of leading blank spaces and/or blank lines, which works for all browsers, including older ones that cannot uncompress gzip format.

  
  先頭の空白スペース and/or 空白行の削除, それは gzip 形式を展開できない古いものを含むすべてのブラウザで機能する.
  

Apache::Gzip

an example of the mod_perl filter developed by Lincoln Stein and Doug MacEachern for their book Writing Apache Modules with Perl and C (U.S.), which like Apache::Compress works through Apache::Filter. Apache::Gzip is not available from CPAN. The source code may be found on the book's companion Web site at http://www.modperl.com/

Licoln Stein と Doug MacEachern によって彼らの本 Writing Apache Modules with Perl and C (アメリカ) のために開発された mod_perl フィルタの例です. それは Apache::Compress と同様に Apache::Filter を通じて機能します. Apache::Gzip は CPAN から利用できません. ソースコードはその本に付属する Web サイト http://www.modperl.com/ で見つけられるでしょう.

Apache::GzipChain

a mod_perl handler developed by Andreas Koenig (Germany), which compresses output through Apache::OutputChain using the gzip format.

Andreas Koenig (ドイツ) によって開発された mod_perl ハンドラで, gzip 形式を使用して Apache::OutputChain を通じた出力の圧縮をします.

Apache::GzipChain currently provides in-memory compression only. Use of this module under perl-5.8 or higher is appropriate for Unicode data. UTF-8 data passed to Compress::Zlib::memGzip() are converted to raw UTF-8 before compression takes place. Other data are simply passed through.

Apache::GzipChain は現在メモリ内圧縮のみを提供します. perl-5.8 以降でのこのモジュールの利用は Unicode データに適しています. Compress::Zlib::memGzip() に渡された UTF-8 データは圧縮が行われる前に生の UTF-8 に変換されます. 他のデータはシンプルに通過します.

コンテンツ圧縮のための CPU 使用に関する典型的なオーバーヘッドは ? What is the typical overhead in terms of CPU use for the content compression?

コンテンツ圧縮に起因する典型的な CPU オーバーヘッドはごくわずか : Typical CPU overhead that originates from content compression is insignificant.

In my observations of data compression of files of up to 200K it takes less then 60 ms CPU on a P4 3 GHz processor. I could not measure the lower boundary reliably for dynamic compression, because there are no really measurable latency. From the perspective of global architecture and scalability planning, I would suggest allowing some 10 ms per request on regular Web pages in order to roughly estimate/predict the performance of the application server.

私の観察では P4 3 GHz プロセッサでの 200K までのファイルのデータ圧縮は 60ms CPU 未満程度でした. 私は動的圧縮の下限の確実な測定はできませんでした, 実際に測定可能なレイテンシ (遅延時間) がなかったからです. グローバルアーキテクチャとスケーラビリティプランの観点から, アプリケーションサーバのパフォーマンスを大まかに推定/予測するために私は通常の Web ページではリクエストあたり 10ms 程度は許すことをお勧めします.

Estimation of connection times is an even less exact matter for of a variety of possible network-related reasons. The worst-case scenario is pretty impressive: a slow dialup connection through an ISP with no proxy/buffering holds the provider's socket for a time interval proportionate to the size of the requested file. At present, gzip reduces this connection time by a factor of approximately 3-20. If the ISP buffers its traffic, however, the content provider might not feel a dramatic impact -- apart of the fact that they are paying their telecom providers for the transmission of considerable unnecessary data.

接続時間の見積はネットワーク関連の様々な理由がありえるのでさらに正確さを欠く問題です. 最悪のシナリオはかなり印象的です: プロキシ/バッファリングのない IPS 経由の遅いダイアルアップ接続は要求されたファイルのサイズに比例した時間間隔でそのプロバイダのソケットを保持します. 目下, gzip はこの接続時間を約 3 - 20 倍削減します. しかしながら, その ISP がそのトラフィックをバッファしたとしても, コンテンツプロバイダは劇的なインパクトを感じないかもしれません -- かなりの不要なデータ送信のために彼らが彼らの通信プロバイダに支払っているという事実は別として.

Apache::Dynagzip で Apache::Registry からの出力を圧縮できるか ? : Is it possible to compress the output from Apache::Registry with Apache::Dynagzip?

イエス. これは次のように, まあまあ簡単にできる : Yes. This should be fairly easy to accomplish, as follows:

If your page/application is initially configured like this:

あなたのページ/アプリケーションがこのように初期構成されている場合:

<Directory /path/to/subdirectory>

  SetHandler perl-script

  PerlHandler Apache::Registry

  PerlSendHeader On

  Options +ExecCGI

</Directory>

you might replace it with the following:

あなたは次のものでそれをリプレイスできるかもしれません:

PerlModule Apache::Filter

PerlModule Apache::Dynagzip

PerlModule Apache::CompressClientFixup

<Directory /path/to/subdirectory>

  SetHandler perl-script

  PerlHandler Apache::RegistryFileter Apache::Dynagzip

  PerlSendHeader On

  Options +ExecCGI

  PerlSetVar Filter On

  PerlFixupHandler Apache::CompressClientFixup

  PerlSetVar LightCompression On

</Directory>

You should usually be all set after that.

これで通常あなたは準備完了です.

In more common cases, you will need to replace the line:

より一般的なケースでは, あなたはあなたの初期構成ファイル内の次の行を:

  PerlHandler Apache::Registry

in your initial configuration file with the following lines:

次の行でリプレイする必要があるかもしれません:

  PerlHandler Apache::RegistryFilter Apache::Dynagzip

  PerlSetVar Filter On

  Perl FixupHandler Apache::CompressClientFixup

Optionally, you might add:

オプションで, あなたはこれを追加できます:

PerlSetVar LightCompression On

to reduce the size of the stream for clients unable to speak gzip (like Microsoft Internet Explorer over HTTP/1.0).

gzip を話せない (Microsoft Internet Explorer over HTTP/1.0 のような) クライアントむけにストリームのサイズを削減するためにです.

Finally, make sure you have somewhere declared

最後に, あなたがどこかでこれを宣言していることを確認してください

  PerlModule Apache::Filter

  PerlModule Apache::Dynagzip

  PerlModule Apache::CompressClientFixup

This basic configuration uses many defaults. See Apache::Dynagzip POD for further fine tuning if required.

この基本構成は多くのデフォルトが使われます. さらなる微調整が必要なら Apache::Dynagzip POD を参照してください.

Note, however, that Apache::RegistryFilter is not yet another Apache::Registry. You may need to adjust your script in accordance with requirements of Apache::Filer first, especially when the script generates any CGI/1.1-specific HTTP headers. You can test your compatibility with the Apache::Filter chain using a temporary configuration like:

ただし, 注意してください, Apache::RegistryFilter はもうひとつの Apache::Registry ではありません. あなたは最初に Apache::Filter の要求にしたがってあなたのスクリプトの調整を必要とするかもしれません, 特にスクリプトが CGI/1.1 固有の HTTP ヘッダ を生成しているときはです. あなたはこのような一時的な構成を使って Apache::Filter チェーンとあなたの互換性をテストできます:

PerlModule Apache::Filter

<Directory /path/to/subdirectory>

  SetHandler perl-script

  PerlHandler Apache::RegistryFilter

  PerlSendHeader On

  Options +ExecCGI

  PerlSetVar Filter On

</Directory>

with no Apache::Dynagzip involved. See Apache::Filter documentation if you have any problems.

Apache::Dynagzip をまきこむことはありません. あなたが何らかの問題を抱えているなら Apache::Filter ドキュメントを参照してください.

Apache::Dynagzip で Mason ドリブンのアプリケーションからの出力を圧縮できるか ? : Is it possible to compress output from a Mason-driven application with Apache::Dynagzip?

イエス. HTML::Mason::ApacheHandler は Apache::Filter チェーンと互換 : Yes. HTML::Mason::ApacheHandler is compatible with the Apache::Filter chain.

If your application is initially configured like:

あなたのアプリケーションがこのような初期構成の場合:

PerlModule HTML::Mason::ApacheHandler

<Drectory /path/to/subdirectory>

  <FilesMatch "\.html$">

    SetHandler perl-script

    PerlHandler HTML::Mason::ApacheHandler

  </FilesMatch>

</Directory>

you may wish to replace it with the following:

あなたは次のようにそれをリプレイスするとよいでしょう:

PerlModule HTML::Mason::ApacheHandler

PerlModule Apache::Dynagzip

PerlModule Apache::CompressClientFixup

<Drectory /path/to/subdirectory>

  <FilesMatch "\.html$">

    SetHandler perl-script

    PerlHandler HTML::Mason::ApacheHandler Apache::Dynagzip

    PerlSetVar Filter On

    PerlFixupHandler Apache::CompressClientFixup

    PerlSetVar LightCompression On

  </FilesMatch>

</Directory>

You should be all set safely after that.

以降はすべて安全に設定できるはずです.

In more common cases, you will need to replace the line:

より一般的なケースでは, あなたはあなたの初期構成ファイルのこの行を:

    PerlHandler HTML::Mason::ApacheHandler

in your initial configuration file with the following lines:

次の行でリプレイする必要があるかもしれません:

    PerlHandler HTML::Mason::ApacheHandler Apache::Dynagzip

    PerlSetVar Filter On

    PerlFixupHandler Apache::CompressClientFixup

Optionally, you might add:

オプションで, あなたはこれも追加できます:

    PerlSetVar LightCompression On

to reduce the size of the stream for clients unable to speak gzip (like Microsoft Internet Explorer over HTTP/1.0).

gzip を話せない (Microsoft Internet Explorer over HTTP/1.0 のような) クライアントむけにストリームのサイズを削減するためにです.

Finally, make sure you have somewhere declared

最後に, これがどこかで宣言されていることを確認してください

PerlModule Apache::Dynagzip

PerlModule Apache::CompressClientFixup

This basic configuration uses many defaults. See Apache::Dynagzip POD for further fine tuning.

この基本構成は多くのデフォルトを使用します. さらなる微調整については Apache::Dynagzip POD を参照してください.

Apache::Dynagzip で商用サポートは利用可能 ? Is commercial support available for Apache::Dynagzip?

イエス. Slav Company, Ltd. は Apache::Dynagzip の商用サポートを世界的に提供している : Yes. Slav Company, Ltd. provides commercial support for Apache::Dynagzip worldwide.

Since the author of Apache::Dynagzip is employed by Slav Company, service is effective and consistent.

Apache::Dynagzip の作者は Slav Company に雇用されているので, サービスは効果的かつ一貫しています.

チャンクサイズのコントロールの維持が重要なのはなぜ ? : Why is it important to maintain a control over the chunk size?

レスポンスレイテンシの削減に役立つ : It helps to reduce response latency.

Apache::Dynagzip is the only handler to date that begins transmission of compressed data as soon as the initial uncompressed pieces of data arrive from their source, at a time when the source process may not even have completed generating the full document it is sending. Transmission can therefore take place concurrently with creation of later document content.

Apache::Dynagzip はソースからの最初の非圧縮圧縮データの一部が到着するとすぐに, それを送信するソースプロセスが完全なドキュメントの生成さえ完了していない可能性がある時点で転送を開始する今のところ唯一のハンドラです. 転送はしたがって後のドキュメントコンテンツの生成と並行して行われます.

This feature is mainly beneficial for HTTP/1.1 requests, because HTTP/1.0 does not support chunks.

この機のは主に HTTP/1.1 で有益です, HTTP/1.0 はチャンクをサポートしないからです.

I would also mention that the internal buffer in Apache::Dynagzip always prevents Apache from the creating too short chunks over HTTP/1.1, or from transmitting too short pieces of data over HTTP/1.0.

私はまた Apache::Dynagzip の内部バッファが Apache が HTTP/1.1 で短すぎるチャンクを生成したり, HTTP/1.0 で短すぎるデータピースを転送することを常に防止していることも言及しておきましょう.

gzip 圧縮に先だって先頭の空白を削除する価値はあるか ? : Is it worthwhile to strip leading blank spaces prior to gzip compression?

イエス. 通常これをする価値はある : Yes. It is usually worthwhile to do this.

The benefits of blank space stripping are mostly significant for non-gzipped data transmissions. One can expect some 5-20% reduction in stream size on regular 'structured' HTML, JavaScript, CSS, XML, etc., in this case at negligible cost in terms of CPU overhead and response delay.

空白スペースの除去の利点は大部分が非 gzip のデータ転送で重要です. 通常 '構造化された' HTML, JavaScript, CSS, XML, などのストリームサイズで 5-20% の削減を期待でき, この場合 CPU オーバーヘッドとレスポンス遅延の観点でのコストは無視できます.

After applying gzip compression, the benefits of previously applied blank space stripping are usually reduced to some 0.5-1.0% of the resulting size, because gzip compresses blank spaces very effectively. It is still worthwhile, however, to perform blank space stripping because:

gzip 圧縮を適用したあとは, 前もって提供された空白スペースの除去の利点は通常は結果のサイズのおよそ 0.5-1.0% 削減されます, gzip は空白スペースをとても効果的に圧縮するからです. しかしながら, 次の理由から空白スペースの除去の実行はまだ価値があります:

• chances are that your handler will ultimately have to send an uncompressed response back to a known buggy client;

  
  おそらくあなたのハンドラは既知のバグのあるクライアントにたいして最終的には非圧縮のレスポンスを送信しなければなりません;
  



• it really costs next-to-nothing, and every little bit helps to reduce the cost of data transmission, especially considering the cumulative effect of frequent repetitions.

  
  そのコストは本当にないに等しく, データ転送のコスト削減にわずかばかりの助けになります, 特に頻繁な繰り返しの累積的な影響を考慮すると.
  

vanilla Apache 1.3 用のコンテンツ圧縮ソリューションはあるか ? : Are there any content compression solutions for vanilla Apache 1.3?

イエス. vanilla Apache 1.3 で利用できる C で書かれた圧縮モジュールが 2 つある : Yes. There are two compression modules written in C that are available for vanilla Apache 1.3:

• mod_deflate
  

  an Apache handler written in C by Igor Sysoev (Russia).

  
  Igor Sysoev (ロシア) によって C で書かれた Apache ハンドラ.
  


• mod_gzip
  

  an Apache handler written in C, originally by Kevin Kiley, Remote Communications, Inc. (U.S.)

  
  元は Kevin Kiley, Remote Communications, Inc. (アメリカ) によって, C で書かれた Apache ハンドラ.
  

See their respective documentation for further details.

これらのさらなる詳細はそれぞれのドキュメントを参照してください.

アプリケーションレベルで私のサイトの出力を圧縮できるか ? : Can I compress the output of my site at the application level?

イエス, あなたの Web サーバが CGI/1.1 互換であなたのアプリケーションから特定の HTTP ヘッダを作成できる, または送信データを圧縮できる独自のハンドラを搭載したアプリケーションフレームワークをあなたが利用しているなら : Yes, if your Web server is CGI/1.1 compatible and allows you to create specific HTTP headers from your application, or when you use an application framework that carries its own handler capable of compressing outbound data.

For example, vanilla Apache 1.3 is CGI/1.1 compatible. It allows development of CGI scripts/programs that can generate compressed outgoing streams accomplished with specific HTTP headers.

例えば, vanilla Apache 1.3 は CGI/1.1 互換です. それは特定の HTTP ヘッダで圧縮されたアウトゴーイングのストリームの生成を達成する CGI スクリプト/プログラムの開発を可能にします.

Alternatively, on mod_perl enabled Apache, some application environments carry their own compression code that can be activated through appropriate configuration:

あるいは, mod_perl が有効化された Apache で, 一部のアプリケーション環境は適切な構成を通じてアクティブ化できる独自の圧縮コードをもっています:

Apache::ASP does this with the CompressGzip setting;

Apache::ASP は CompressGzip の設定でこれを行います.

Apache::AxKit uses the AxGzipOutput setting to do this.

Apache::AxKit はこれを行うために AxGzipOutput の設定を使用します.

See the documentation for the particular packages for details.

パッケージ固有の詳細はそのドキュメントを参照してください.

Apache-2 用のコンテンツ圧縮ソリューションは何かある ? : Are there any content compression solutions for Apache-2?

イエス. C で書かれた, コアの圧縮モジュール mod_deflate は, Apache-2 で利用可能 : Yes. A core compression module written in C, mod_deflate, is available for Apache-2.

mod_deflate for Apache-2 was written by Ian Holsman (USA).

Apache2 の mod_deflate は Ian Holsman (アメリカ) によって書かれました.

Despite its name, mod_deflate for Apache-2 provides gzip-encoded content. In accordance with the concept of output filters that was introduced in Apache-2, mod_deflate is capable of gzipping outbound traffic from any content generator, including CGI, Java, mod_perl, etc.

その名前にもかかわらず, Apache-2 の mod_deflate は gzip エンコードされたコンテンツを提供します. Apache-2 で導入されたアウトプットフィルタのコンセプトにしたがって, mod_deflate は CGI, Java, mod_perl, etc を含む任意のコンテンツジェネレータからのアウトバウンドトラフィックを gzip できます.

• This module supports flushing.

  
  このモジュールはフラッシュ (# 一気に流しだすこと) をサポートします.



• It is output filter-compatible.

  
  アウトプットフィルタ互換です.



• It has its own set of configuration options to maintain control over buggy clients.

  
  バギーなクライアントの制御を維持するために独自の構成オプションのセットをもっています.

Apache::Daynagzip が Apache-2 に移植されるのはいつ ? : When is Apache::Dynagzip supposed to be ported to Apache-2?

今のところ Apache-2 に Apache::Dynagzip が移植される予定はない : There are no current plans to port Apache::Dynagzip to Apache-2:

mod_deflate for Apache-2 is capable of providing all basic functionality required for effective dynamic content compression. The rest can be easily addressed through implementation of the accompanying specific, tiny filters. For instance, Apache::Clean, which is already ported to Apache-2, can be used to strip unnecessary blank spaces from outbound streams.

Apache-2 の mod_deflate は効果的な動的コンテンツ圧縮に必要とされるすべての基本機能を提供できます. 残りの部分は付属の固有の, 小さなフィルタの実装を通じて簡単に対処されます. たとえば, すでに Apache-2 に移植された, Apache::Claen は, アウトバウンドストリームから不要な空白の除去に使用できます.

gzip と deflate 形式のオリジナルの説明はどこで読める ? : Where can I read the original descriptions of the gzip and deflate formats?

gzip 形式は rfc1952 で公開され, deflate 形式は rfc1951 で公開されている : gzip format is published as rfc1952, and deflate format is published as rfc1951.

You can find many mirrors of RFC archives on the Internet. Try, for instance, my favorite at http://www.ietf.org/rfc.html

あなたはインターネット上で多くの RFC アーカイブのミラーをみつけられます. たとえば, 私のお気に入りの http://www.ietf.org/rfc.html にトライしてください.

特定のブラウザで既知の圧縮の問題はある ? : Are there any known compression problems with specific browsers?

イエス. Netscape 4 は CSS と JavaScript ファイルでの圧縮に問題がある : Yes. Netscape 4 has problems with compressed cascading style sheets and JavaScript files.

You can use Apache::CompressClientFixup to disable compression for these files dynamically on Apache-1.3. Apache::Dynagzip is capable of providing so-called light compression for these files.

Apache-1.3 でそれらの圧縮を動的に無効化するためにあなたは Apach::CompressClientFixup を使用できます. Apache::Dynagzip はそれらのファイルにいわゆる軽い圧縮 (light compression) を提供できます.

On Apache-2, mod_deflate can be configured to disable compression for these files dynamically, and the Apache::Clean filter can be used to strip unnecessary blank spaces.

Apache-2 では, それらのファイルの圧縮を動的に無効化するために mod_deflate を構成でき, Aache::Clean フィルタは不要な空白スペースの除去に使えます.

モダンブラウザの圧縮機能についての詳細はどこでみつかる ? : Where can I find more information about the compression features of modern browsers?

Michael Schroepl がとても価値あるサイトをメンテしている : Michael Schroepl maintains a highly valuable site

See it athttp://www.schroepl.net/projekte/mod_gzip/browser.htm

http://www.schroepl.net/projekte/mod_gzip/browser.htm でそれを参照してください

謝辞 : Acknowledgments

During this work, I received a great deal of real help from Kevin Kiley, Igor Sysoev, Michel Schroepl, and Henrik Nordstrom. I'm thankful to all subscribers of mod_perl users mailing list, mod_gzip mailing list, and squid users mailing list for the questions and discussions regarding the content compression. I'm especially thankful to Stas Bekman for the initiative to publish this FAQ on mod_perl Web site. I highly value patient efforts of Dan Hansen in making this text better English...

この作業中, 私は Kevin Kiley, Igor Sysoev, Michel Schroepl, そして Henrik Nordstrom からたくさんの本当の助力を受けました. 私はコンテンツ圧縮に関する質問や議論をしてくれた mod_perl ユーザーズメーリングリスト, mod_gzip メーリングリスト, それから squid ユーザーズメーリングリストのすべてのサブスクライバーに感謝しています. mod_perl Web サイト上でこの FAQ を公開するために率先してくれた Stas Bekman に私は特に感謝しています. 私はこのテキストの英語をより良くする Dan Hansen の忍耐強い努力を高く評価します...

メンテナ : Maintainers

The maintainer is the person you should contact with updates, corrections and patches.

• Slava Bizyayev <slava (at) cpan.org>

作者 : Authors

• Slava Bizyayev <slava (at) cpan.org>

Only the major authors are listed above. For contributors see the Changes file.

NEXT

今回で mod_perl のドキュメント mod_perl: Welcome to the mod_perl world の確認は終了します。

次回は, 作者の ドゥゲスト・ジャック (Jacques Deguest) さん本人からのお勧めにしたがって, Perl で本当の Try Catch ブロックを実装するモジュール「 Nice::Try 」を確認します。

参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index