Caching Proxy の基本構成

Caching Proxy は、リバース・キャッシング・プロキシー・サーバーのロールで構成することも (デフォルト構成)、フォワード・キャッシング・プロキシー・サーバーのロールで構成することもできます。コンテンツ・ホストで使用される場合、Caching Proxy は、インターネットと企業のコンテンツ・ホストの間に位置するリバース・キャッシング・プロキシー・サーバーのロールで構成されます。インターネット・アクセス・プロバイダーで使用される場合、Caching Proxy は、クライアントとインターネットの間に位置するフォワード・キャッシング・プロキシー・サーバーのロールで構成されます。

リバース Caching Proxy (デフォルト構成)

リバース・プロキシー構成を使用する際、Caching Proxy マシンは、インターネットと企業のコンテンツ・ホストとの間に配置されます。プロキシー は代理として機能し、インターネットから到着したユーザー要求をインターセプトして、それを適切なコンテンツ・ホストに転送し、戻りデータをキャッシュに入れてから、そのデータをインターネット経由でユーザーに引き渡します。 Caching Proxy は、キャッシングにより、以後同じコンテンツが要求されたときにそのコンテンツをキャッシュから直接引き渡すことができるため、改めてコンテンツ・ホストから取り出すよりもはるかに迅速に処理を行えます。 情報は、その有効期限、キャッシュのサイズ、および情報の更新時期にしたがって キャッシュに入れることが可能です。 キャッシュ・ヒットをより高速にダウンロードできるということは、カスタマーにとっては、 サービスの品質がよりよいということになります。図 1 は、Caching Proxy のこの基本的な機能を示しています。

図 1. リバース・プロキシーとして機能する Caching Proxy
この図は基本リバース・プロキシー構成を表します

この構成において、プロキシー (4) は、URL にコンテンツ・ホストのホスト名 (6) が含まれている要求をインターセプトします。クライアント (1) がファイル X を要求すると、その要求はインターネット (2) を経由し、企業のインターネット・ゲートウェイ (3) を通過してその企業の内部ネットワークに入ります。プロキシー は要求をインターセプトして、自身の IP アドレスを発信アドレスとして持つ新規要求を生成し、その新規要求をコンテンツ・ホスト (6) に送信します。

コンテンツ・ホストは、ファイル X をエンド・ユーザーに直接返すのではなく、プロキシー に返します。ファイルがキャッシュ可能である場合、Caching Proxy はそのファイルのコピーをキャッシュ (5) に格納してから、エンド・ユーザーに引き渡します。キャッシュ可能コンテンツの最も分かりやすい例は静的 Web ページです。ただし、Caching Proxy には、WebSphere® Application Server が動的に生成したコンテンツをキャッシュに入れて供給する機能もあります。

フォワード Caching Proxy

エンド・ユーザーへ直接インターネット・アクセスを提供することは、非常に非効率になる可能性があります。 Web サーバーから所定のファイルを取り出すすべてのユーザーは、たとえそのファイルを変更していないとしても、 そのファイルを取り出した最初のユーザーとして、ネットワークおよびインターネット・ゲートウェイにおいて同量のトラフィックを 生成していることになります。 これに対する解決策は、ゲートウェイの近くにフォワード Caching Proxy をインストールすることです。

フォワード・プロキシー構成を使用する場合、Caching Proxy マシンは、クライアントとインターネットの間に配置されます。Caching Proxy はクライアントの要求を、インターネットにあるコンテンツ・ホストに転送し、取り出したデータをキャッシュに入れて、そのデータをクライアントに引き渡します。

図 2. フォワード・プロキシーとして機能する Caching Proxy
このグラフィックは、フォワード・プロキシーの基本構成を示しています。

図 2 は、フォワード Caching Proxy の構成を示しています。 クライアントのブラウザー・プログラム (1 という番号が付いたマシン上のプログラム) は、フォワード・キャッシング・プロキシー (2) に要求を送るように構成され、フォワード・キャッシング・プロキシーは要求をインターセプトするように構成されています。コンテンツ・ホスト (6) に保管されているファイル X をエンド・ユーザーが要求すると、フォワード Caching Proxy はその要求をインターセプトして、自身の IP アドレスを発信アドレスとして持つ新規要求を生成し、企業のルーター (4) を使用してインターネット (5) 経由でその新規の要求を送信します。

このようにして、起点サーバーはファイル X を、エンド・ユーザーに直接戻さずに、フォワード・キャッシング・プロキシーに戻します。 フォワード Caching Proxy のキャッシング・フィーチャーが有効になっている場合、Caching Proxy は、その戻りヘッダーの設定値 (例えば、有効期限、およびそのファイルが動的に生成されたかどうかについての指示) をチェックして、ファイル X がキャッシングに適格であるかどうかを判断します。 ファイルがキャッシュ可能である場合、Caching Proxy は、そのキャッシュ (3) にファイルのコピーを保管してから、ファイルをエンド・ユーザーに引き渡します。 デフォルトでは、キャッシングが有効の設定であり、フォワード Caching Proxy はメモリー・キャッシュを使用します。 ただし、ユーザーは他のタイプのキャッシングを構成することもできます。

ファイル X に対する最初の要求では、フォワード Caching Proxy によって、インターネットへのアクセスの効率はそれほど向上しません。実際、ファイル X にアクセスする最初のユーザーに対する応答時間は、フォワード Caching Proxy なしの場合よりもおそらく遅くなります。これは、フォワード Caching Proxy が元の要求パケットを処理し、ファイル X を受け取ったときにそのヘッダーにあるキャッシュ可能性に関する情報について調べるのにいくらか余分に時間がかかるためです。フォワード・キャッシング・プロキシー使用の利点が生ずるのは、後で他のユーザーがファイル X を要求したときです。 フォワード Caching Proxy は、キャッシュに入れたファイル X のコピーがまだ有効であるか (期限切れでないか) を チェックし、有効である場合は、インターネット経由でコンテンツ・ホストに要求を転送することなく、キャッシュから直接ファイル X を供給します。

フォワード Caching Proxy は、要求ファイルの有効期限が切れていることを 発見したときでも、必ずしもコンテンツ・ホストからファイルを再フェッチする必要はありません。 代わりに、特別な状況検査メッセージをコンテンツ・ホストに送信します。 ファイルが変更されていないとコンテンツ・ホストが示した場合、フォワード・キャッシング・プロキシーは、 キャッシュに入れたバージョンを要求ユーザーに引き渡すことができます。

フォワード Caching Proxy をこのように構成することを、フォワード・プロキシーという用語で表しています。 これは、Caching Proxy がブラウザーに代って機能し、要求をインターネット経由でコンテンツ・ホストに転送するからです。 キャッシングを使用したフォワード・プロキシーの利点は次の 2 点です。

Caching Proxy は、いくつかのネットワーク転送プロトコルをプロキシーできます。プロキシー可能なプロトコルには、HTTP (Hypertext Transfer Protocol)、FTP (File Transfer Protocol)、および Gopher があります。

透過フォワード Caching Proxy (Linux システムのみ)

フォワード Caching Proxy の変化形として、透過 Caching Proxy があります。このロールの Caching Proxy は、基本のフォワード Caching Proxy と同じ機能を実行しますが、機能が実行されたことをクライアントが認識することはありません。透過 Caching Proxy 構成は、Linux システムでのみサポートされています。

フォワード Caching Proxy で説明した構成では、各クライアント・ブラウザーはそれぞれ個別に、特定のフォワード Caching Proxy に要求を送信するように構成されています。 このような構成を維持することは、 クライアント・マシンが多数ある場合には、とりわけ不都合なものになる可能性があります。 Caching Proxy では、管理を単純化するいくつかの代替手段をサポートしています。 1 つの可能性として、図 3 に示されているように Caching Proxy を透過プロキシー向けに構成することがあります。通常のフォワード Caching Proxy と同様、透過 Caching Proxy はゲートウェイ近くのマシンにインストールしますが、クライアント・ブラウザー・プログラムは、フォワード Caching Proxy に要求を送信するようには構成されません。 クライアントは、構成にプロキシーが存在することを認識しません。 代わりに、クライアント要求をインターセプトして、それらの要求を透過 Caching Proxy に送信するようにルーターが構成されます。 1 という番号が付いたマシンのうちの 1 台で動作するクライアントが、コンテンツ・ホスト (6) に保管されているファイル X を要求すると、ルーター (2) はその要求を Caching Proxy に渡します。 Caching Proxy は、自身の IP アドレスを発信アドレスとして持つ新規要求を生成し、ルーター (2) を使用してインターネット (5) 経由でその新規要求を送信します。ファイル X が到着すると、Caching Proxy はそのファイルを適宜 (フォワード Caching Proxy で説明した条件に応じて) キャッシュに入れてから、要求クライアントに渡します。

図 3. 透過フォワード・プロキシーとして機能する Caching Proxy
このグラフィックは、フォワード・プロキシーの基本構成を示しています。

HTTP 要求の場合、各ブラウザーでプロキシー構成情報を保守するための、別の考えられる手法は、 いくつかのブラウザー・プログラムで使用可能な自動プロキシー構成フィーチャーを使用することです。 このフィーチャーが使用可能なブラウザー・プログラムとしては、Netscape Navigator バージョン 2.0 および それ以降のバージョン、Microsoft Internet Explorer バージョン 4.0 およびそれ以降のバージョンがあります。 この場合、1 つ以上の中央プロキシー自動構成 (PAC) ファイルを作成し、ローカルのプロキシー構成情報ではなく、それらのファイルのいずれか 1 つを参照するようにブラウザーを 構成することができます。 ブラウザーは自動的に、PAC への変更を認識し、適宜、そのプロキシーの使用を調整します。これによって、 各ブラウザーに個別の構成情報を保守する必要がなくなるだけでなく、プロキシー・サーバーが使用不可になったときに 要求を転送することも容易になります。

3 つ目の代替手法は、一部のブラウザー・プログラム (Internet Explorer バージョン 5.0 以降など) で使用可能な、Web Proxy Auto Discovery (WPAD) メカニズムを使用することです。 このフィーチャーをブラウザーで使用可能にすると、このフィーチャーはそのネットワーク内で自動的に WPAD 準拠のプロキシー・サーバーを探し出し、その Web 要求をそこに送信します。 この場合、ユーザーが中央プロキシー構成ファイルを保守する必要はありません。 Caching Proxy は、WPAD 準拠です。