JP3485915B1 - ゲートウェイ装置、クライアント計算機およびプロキシサーバ計算機 - Google Patents

Abstract

【要約】 【課題】 ファイルオブジェクトに対するアクセス要求
を分散して経路を有効に利用し、スループットを向上さ
せ、さらにローカルネットワーク上の通信量を削減する
こと。 【解決手段】 システムは、クライアント計算機２４
と、クライアント計算機２４からの情報提供要求に応じ
て情報を提供するサーバ計算機１２と、サーバ計算機１
２のファイルオブジェクトを制御するｒｅｄｉｒｅｃｔ
ｏｒ計算機７２〜７７と、クライアント計算機２４から
の情報提供要求に基づくファイルオブジェクトの転送を
中継するｐｒｏｘｙサーバ計算機６５〜６７とからな
る。ｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７は、情報提
供要求に含まれる文字列とシステム内のｐｒｏｘｙサー
バ計算機６５〜６７の数とを用いた所定の演算による演
算結果に基づいて、要求した情報を格納するｐｒｏｘｙ
サーバ計算機を決めることで、ｐｒｏｘｙサーバ計算機
毎に格納される情報量を分散させる制御をすることを特
徴とする。

Description

【発明の詳細な説明】 【技術分野】

【０００１】 本発明は、ネットワーク上に分散した複
数のサーバ計算機と、複数のクライアント計算機とがゲ
ートウェイ装置（計算機）を介して通信回線で相互に接
続されている分散ファイルシステムに関し、特に、複数
のクライアント計算機がゲートウェイ装置を介してサー
バ計算機内部の記憶装置内のファイルオブジェクトにア
クセスする場合の分散ファイルシステムのファイル中継
を行なうゲートウェイ装置、ゲートウェイ装置にアクセ
ス要求を出力するクライアント計算機、およびｐｒｏｘ
ｙサーバ計算機に関する。

【背景技術】

【０００２】 以下の説明で「サーバ計算機」とは、ネ
ットワーク上において何らかのサービスを提供している
計算機をいい、「クライアント計算機」とは、そうした
サーバ計算機のサービスを要求し、受ける計算機をいう
ものとする。また「ファイルオブジェクト」とは、分散
ファイルシステムの利用するネットワークプロトコル
と、ネットワークアドレス（サーバ計算機の名称）と、
ファイル名称と、ファイルの実体との組をいうものとす
る。ここで「ファイルオブジェクトの名称」とは、ネッ
トワークプロトコルとネットワークアドレスとファイル
名称との組のことをいう。

【０００３】 従来、上述したような分散ファイルシス
テムにおいては、複数のクライアント計算機からのサー
バ計算機上のファイルオブジェクトに対する読出要求
は、一旦途中のゲートウェイ計算機で中継されていた。
ゲートウェイ計算機がサーバ計算機から読出したファイ
ルオブジェクトは、クライアント計算機に中継される。
それと同時にそれらファイルオブジェクトは、ゲートウ
ェイ計算機内部のキャッシュファイル（固定ディスク、
半導体メモリなど）に蓄積される。そうしたゲートウェ
イ計算機の一例が特開平４−３１３１２６号公報（発明
の名称「分散ファイルシステムのファイル入出力方
式」）に開示されている。

【０００４】 図１５は、この従来の分散ファイルシス
テムを示している。このシステムは、ゲートウェイ計算
機１１０と、このゲートウェイ計算機１１０を介して相
互に接続されたサーバ計算機１００および複数のクライ
アント計算機１２０を含む。サーバ計算機１００は、複
数のクライアント計算機１２０によって共有されてい
る。

【０００５】 サーバ計算機１００は、ファイルを格納
するディスク装置１３６と、ネットワークを介してディ
スク装置１３６のファイルの内容を入出力するためのフ
ァイル入出力応答手段１３４と、ディスク装置１３６内
のブロック情報をネットワークを介してクライアント計
算機１２０に応答するためのブロック情報応答手段１３
２とを含む。

【０００６】 クライアント計算機１２０は、サーバ計
算機１００のブロック情報応答手段１３２に対してブロ
ック情報要求を送り、ブロック情報を受けるためのブロ
ック情報要求手段１５２と、ゲートウェイ計算機１１０
を介してサーバ計算機１００のファイル入出力応答手段
１３４に対してファイル入出力要求を送り、当該ファイ
ルを受信するためのファイル入出力要求手段１５４とを
含む。

【０００７】 ゲートウェイ計算機１１０は、クライア
ント計算機１２０（複数）とサーバ計算機１００との間
に介在し、サーバ計算機１００内のディスク装置１３６
と、各クライアント計算機１２０との間のキャッシュメ
モリとして機能するものであり、キャッシュした内容を
格納するためのディスクキャッシュ１４４と、ファイル
入出力要求手段１５４およびファイル入出力応答手段１
３４の間に介在するキャッシュ管理手段１４２とを含
む。

【０００８】 このシステムは次のように動作する。ま
ず、クライアント計算機１２０がサーバ計算機１００内
のディスク装置１３６内のファイルにアクセスして１つ
のブロックを読込む場合の動作について説明する。ブロ
ック情報要求手段１５２は、ゲートウェイ計算機１１０
を介してサーバ計算機１００に対して読込対象のブロッ
クにかかるブロック情報の取得を要求するブロック情報
要求メッセージを発行する。

【０００９】 サーバ計算機１００内のブロック情報応
答手段１３２は、このメッセージに応答して、ディスク
装置１３６から該当するブロック情報を取出し、そのブ
ロック情報を有するブロック情報応答メッセージをゲー
トウェイ計算機１１０を介してクライアント計算機１２
０内のブロック情報要求手段１５２に返却する。

【００１０】 クライアント計算機１２０のファイル入
出力要求手段１５４は、返却されたブロック情報に基づ
いて読込対象のブロックの読込を要求するファイルアク
セス要求を、ゲートウェイ計算機１１０内のキャッシュ
管理手段１４２に対して発行する。

【００１１】 このファイルアクセス要求を受取ったキ
ャッシュ管理手段１４２は、そのファイルアクセス要求
にかかるブロック情報とディスクキャッシュ１４４に記
憶されている読込対象のブロックにかかるブロック情報
との比較を行なう。そしてディスクキャッシュ１４４
に、該当するブロック情報が存在しない場合、または両
方のブロック情報の内容（更新時間）が異なる場合（読
込対象のブロックのキャッシュが有効でない場合）に
は、キャッシュ管理手段１４２は上述のファイルアクセ
ス要求をサーバ計算機１００のファイル入出力応答手段
１３４に対して発行する。

【００１２】 サーバ計算機１００のファイル入出力応
答手段１３４は、このファイルアクセス要求に応答し
て、ディスク装置１３６内のファイルをアクセスして、
該当するブロックを読込み、ゲートウェイ計算機１１０
にそのブロックを転送する。

【００１３】 キャッシュ管理手段１４２は、このブロ
ックをディスクキャッシュ１４４に格納し、そのブロッ
クにかかるブロック情報のディスクキャッシュ１４４へ
の設定または更新を行なう。キャッシュ管理手段１４２
は同時に、そのブロックをクライアント計算機１２０の
ファイル入出力要求手段１５４に対して転送する。

【００１４】 以上でディスクキャッシュ１４４内に有
効なファイルが存在しない場合のこのシステムの動作に
ついて説明した。

【００１５】 次回に同一ファイルに対するアクセス要
求があった場合には、ゲートウェイ計算機１１０のキャ
ッシュ管理手段１４２は、ディスクキャッシュ１４４か
ら当該ブロックを取出し、アクセス要求を発行したクラ
イアント計算機１２０のファイル入出力要求手段１５４
に対して当該ブロックを転送する。したがってこの場
合、ゲートウェイ計算機１１０からサーバ計算機１００
に対する転送要求は発行されない。したがって中継アク
セスの高速化が図られる。

【００１６】 類似の技術が、特開昭６３−２００２４
４号公報（発明の名称「ファイル・アクセス・システ
ム」）や、特開昭６３−２０１８４号公報（発明の名称
「遠隔ファイル・アクセス・システム」）にも開示され
ている。いずれの技術においても、あるファイルオブジ
ェクトに対するアクセス要求が発行された場合に、当該
ファイルオブジェクトの内容が更新されているかどうか
を確認するために、サーバ計算機の保持するファイルオ
ブジェクトの変更時刻をキャッシュファイルの変更時刻
と比較する。そしてキャッシュファイルの内容が古い場
合には、クライアント計算機は更新されたサーバ計算機
の内容を読出すようになっている。しかし、これら２件
の公報に記載された技術では、キャッシュファイルはク
ライアント計算機内に存在しており、特開平４−３１３
１２６号公報に開示されたシステムのようにシステム内
にゲートウェイ計算機が含まれているわけではない。

【００１７】 しかし、これら３件の従来技術文献は、
サーバ計算機のファイルオブジェクトと、キャッシュさ
れたファイルオブジェクトとの内容が食い違わないよう
な工夫をしているという共通点を持っている。

【００１８】 このように本来同一であるべきファイル
の食い違いを防ぐことをインテグリティ（Integrity ）
を保つという。また、食い違いの起きたファイルのデー
タをステールデータ（stale data）と呼ぶ。

【００１９】 上述した従来の技術の基本は、ネットワ
ーク経由でサーバ計算機の、該当するファイルオブジェ
クトの変更時刻を調べ、対応するキャッシュファイルの
内容の変更時刻と比較するアルゴリズムを使用してい
る。そのため、サーバ計算機に対するネットワーク経由
の問合せを必ず行なわなければならない。ネットワーク
の実効的な転送速度が小さい場合や、該当するファイル
オブジェクトを有するサーバ計算機にかかっている負荷
が高くて即座に応答できない場合には、そうした問合せ
自体にかなり時間がかかってしまうことがある。そのた
めネットワークファイルシステムによっては、このよう
なファイルキャッシュのシステムを採用していない場合
もある。すなわちこうしたシステムでは、サーバ計算機
の保持するファイルオブジェクトが更新されているにも
かかわらず、ゲートウェイ計算機の持つキャッシュ内の
対応するファイルオブジェクトは必ずしも更新されてい
ない。このようなネットワークファイルシステム方式の
代表的なものとして、いわゆるインターネットにおける
ＨＴＴＰ（Hyper Text Transfer Protocol）を使った広
域分散型マルチメディア情報システムがある。

【００２０】 インターネットは、その基本プロトコル
としてＴＣＰ／ＩＰプロトコルを利用した、グローバル
なネットワークである。インターネット上に構築された
地域分散型マルチメディア情報提供システムは、World
Wide Wed（ＷＷＷ）と呼ばれる。ＷＷＷは、ネットワー
ク上に分散したファイルオブジェクトを扱うことができ
る。これらのファイルオブジェクトは、単なるテキスト
データにとどまらず、画像データ、音声データ、ビデオ
画像データなどさまざまな種類のものを含む。ＷＷＷ
は、情報提供側にとっても、情報利用者（ユーザ）にと
っても魅力的であるため、ネットワーク上のＷＷＷに関
するトラフィックが爆発的に増加している。ＷＷＷシス
テムでは、クライアント計算機のユーザは、グラフィカ
ルユーザインタフェースを持ったブラウザソフトウェア
をクライアント計算機上で実行させるだけで、ネットワ
ーク上に分散したサーバ計算機の保持するさまざまなフ
ァイルオブジェクトで構成された情報を次々とアクセス
することができる。ＷＷＷは、このような操作の簡単さ
のために近時めざましい普及をみせている。

【００２１】 そしてこのＷＷＷシステムは、ＴＣＰ／
ＩＰプロトコルの上に構築されたＨＴＴＰプロトコルで
ファイルオブジェクトを転送している。

【００２２】 ＨＴＴＰプロトコルを実施する上におい
ては、特開平４−３１３１２６号公報に記載されたよう
なゲートウェイ計算機によりファイルオブジェクトを中
継転送することが広く行なわれている。データは、ゲー
トウェイ装置にキャッシュされる。またＷＷＷシステム
では、ファイルオブジェクトの中継転送においてステー
ルデータが発生することは容認されている。すなわちゲ
ートウェイ計算機にキャッシュされている内容が、サー
バ計算機の当該ファイルオブジェクトと一致していない
場合を許容している。

【００２３】 キャッシュファイル内のステールデータ
の率をステールデータ率と呼ぶこととする。何らかの方
式でキャッシュファイルの内容を更新しない限り、ステ
ールデータ率は増加する。一般にキャッシュファイルの
ステールデータ率が増加すると、クライアント計算機を
操作しているユーザは、内容が古いと自主的に判断し
て、ファイルオブジェクトをサーバ計算機から再度ロー
ドすることを試みる。この場合、キャッシュファイルの
内容を利用しないプロトコルが用いられる。この結果、
ゲートウェイ計算機内のキャッシュファイルシステムが
意味を持たなくなる傾向がある。

【００２４】 一方で、このようなステールデータの発
生を容認するプロトコルの利点もある。クライアント計
算機が、サーバ計算機のファイルオブジェクトのアクセ
スをゲートウェイ計算機に中継依頼してアクセスを行な
った場合、ゲートウェイ計算機のキャッシュファイルに
ヒットした場合には、キャッシュファイルからファイル
オブジェクトが読出されてクライアント計算機に転送さ
れる。サーバ装置に対する当該ファイルオブジェクトの
変更時刻の問合せは不要である。そのため短時間にファ
イルオブジェクトがキャッシュから取出され、クライア
ントに返送される。

【００２５】 ＨＴＴＰプロトコルのようにステールデ
ータを容認するネットワークファイルプロトコルは、全
地球的な広域ネットワークで利用される上で有利な点を
有している。すなわち、ゲートウェイ装置のキャッシュ
に当該ファイルオブジェクトがキャッシュされていれ
ば、サーバ装置に対するアクセスが発生しない。その結
果応答時間短縮を図ることができるという有利な点を持
っている。

【００２６】 上述のようにネットワーク上のファイル
オブジェクトのアクセスを高速化し、かつインターネッ
トのトラフィックを低減させるゲートウェイ計算機は特
に「ｐｒｏｘｙサーバ装置」とも呼ばれている。

【００２７】 「ｐｒｏｘｙ」とは「代理人」という意
味である。ｐｒｏｘｙサーバ装置は、その名のとおり、
クライアント計算機がネットワーク上のサーバ計算機の
ファイルオブジェクトにアクセスする場合に、そのアク
セス要求をサーバ計算機を代理して受付け、ファイルオ
ブジェクトの転送を中継する機能を果たす。ｐｒｏｘｙ
サーバ装置の概念を図１６を参照して説明する。

【００２８】 ｐｒｏｘｙサーバ装置１３は、たとえば
ある企業内に用いられた内部ネットワーク２３と、その
企業外の外部ネットワーク（インターネットなど）２５
との間に介在して設けられるものである。内部ネットワ
ーク２３は複数個のクライアント計算機２４を含み、外
部ネットワーク２５は、同じく複数個のサーバ計算機１
１を含んでいる。各サーバ計算機１１は、ファイルオブ
ジェクト１２を保有している。

【００２９】 ｐｒｏｘｙサーバ装置１３は、キャッシ
ュファイル１６と、クライアント計算機からリード要求
１９を受け、キャッシュファイル１６内に当該ファイル
オブジェクトが存在する場合にはそのファイルオブジェ
クトをデータ２０として返送し、キャッシュファイル１
６内に当該ファイルオブジェクトの有効なものが存在し
ない場合には外部ネットワーク２５を介してサーバ計算
機１１に対するリード要求１７を発行し、対応するファ
イルオブジェクトをデータ１８として受けてクライアン
ト計算機２４に対して返送するｐｒｏｘｙプロセス１４
と、ｐｒｏｘｙプロセス１４によるファイルオブジェク
トの転送記録を記録するアクセスログ１５とを含む。ｐ
ｒｏｘｙプロセス１４は、サーバ計算機１１からファイ
ルオブジェクトを取得したときには、当該ファイルオブ
ジェクトをキャッシュファイル１６にも新たに書込む機
能を有している。

【００３０】 このｐｒｏｘｙサーバ装置１３は次のよ
うに動作する。まず、内部ネットワーク２３内のクライ
アント計算機２４が、外部ネットワーク２５上のサーバ
計算機１１のファイルオブジェクト１２に対するリード
要求１９をｐｒｏｘｙサーバ装置１３内のｐｒｏｘｙプ
ロセス１４に対して発行する。ｐｒｏｘｙプロセス１４
はこのリード要求１９に応答して、キャッシュファイル
１６をアクセスし、キャッシュファイル中に当該ファイ
ルオブジェクトのキャッシュデータがあるか否かを判定
する。当該ファイルオブジェクトがキャッシュされてい
れば、ｐｒｏｘｙサーバ装置１３固有のキャッシュファ
イル有効期限と、キャッシュされたファイルオブジェク
トの最終変更時刻とを比較する。キャッシュが有効期限
内であれば、キャッシュファイルからファイルオブジェ
クト読出（２２）、そのデータ２０を内部ネットワーク
２３のリード要求１９を発行したクライアント計算機２
４に対して返送する。

【００３１】 キャッシュファイル１６内に該当ファイ
ルオブジェクトが存在しない場合、および存在していた
としても有効期限が過ぎている場合には、キャッシュフ
ァイル１６内に有効なファイルオブジェクトが存在しな
いものと判定される。その場合、ｐｒｏｘｙプロセス１
４は、外部ネットワーク２５のサーバ計算機１１に対し
て、ファイルオブジェクト１２の読出要求１７を発行す
る。これに応答してサーバ計算機１１は、ファイルオブ
ジェクト１２をデータ１８としてｐｒｏｘｙプロセス１
４に返送する。ｐｒｏｘｙプロセス１４は、ログファイ
ル１５にアクセスログとして、ファイルオブジェクト名
称（すなわちネットワークプロトコル名称と、サーバ計
算機のネットワークアドレス名称と、ファイル名称との
組）と、ファイルオブジェクトのデータの実体（すなわ
ちファイルオブジェクトそのもの）と、書込時刻とを書
込む（２６）。

【００３２】 ｐｒｏｘｙプロセス１４はさらに、内部
ネットワーク２３内のクライアント計算機２４にデータ
２０を転送し、かつキャッシュファイル１６に、当該フ
ァイルオブジェクトを書込む（２１）。

【００３３】 したがってキャッシュファイル１６内に
は、ファイルオブジェクト名称と、ファイルオブジェク
トの実体と、ファイルオブジェクトをサーバ装置から取
得した時刻（最終変更時刻）とが記録されている。

【００３４】 ｐｒｏｘｙサーバ装置は、ヨーロッパ原
子核物理研究所ＣＥＲＮで開発されたｈｔｔｐｄや、日
本の電子技術総合研究所の佐藤豊氏の開発されたＤｅｌ
ｅＧａｔｅなどのソフトウェアを、ネットワーク接続さ
れたＵＮＩＸ（Ｒ）の動くコンピュータ上で実行するこ
とにより実現されることが一般的である。

【００３５】 ｐｒｏｘｙサーバ装置の物理構成を図１
７に示す。ｐｒｏｘｙサーバ装置は、ＵＮＩＸ（Ｒ）の
動作するワークステーション２００により構成される。
ワークステーション２００は、ＣＰＵ（中央処理装置）
２０２と、ＣＰＵ２０２に対して内部バス２０４により
接続されるメモリ２０６と、ファイル用のＩ／Ｏ（入出
力）装置２０８と、ルータ２１０を介して外部ネットワ
ークに接続される第１ネットワークＩ／Ｏインタフェー
ス２１２と、内部ネットワークに接続される第２ネット
ワークＩ／Ｏインタフェース２１４とを含む。Ｉ／Ｏ装
置２０８には、キャッシュファイルの蓄積、アクセスロ
グ、および各種ワークファイルの記憶場所として使用さ
れるファイル部２１６が接続されている。

【００３６】 このワークステーション２００は、ＣＰ
Ｕ２０２が、上述したｈｔｔｐｄやＤｅｌｅＧａｔｅと
いうソフトウェアを実行することによりｐｒｏｘｙサー
バ装置１３を実現する。

【００３７】 図１８は、ｐｒｏｘｙサーバ装置の他の
構成例を示す図である。このｐｒｏｘｙサーバ装置はワ
ークステーション３００からなっている。ワークステー
ション３００は、概略、図１７のワークステーション２
００と同様の構成であるが、図１７の第２ネットワーク
Ｉ／Ｏインタフェース２１４に代えて、モデム装置３０
４に接続されるシリアルポート３０２を有している点が
異なっている。そしてこのワークステーション３００
は、モデム装置３０４および公衆電話回線網３０６を介
して内部ネットワークに接続されている。

【００３８】 図１８において、図１７と同一の部品に
は同一の参照番号を付している。それらの名称および機
能も同一である。したがって、ここではそれらについて
の詳しい説明は繰返さない。

【００３９】 図１９にｐｒｏｘｙサーバ装置のさらに
他の構成例を示す。図１９のｐｒｏｘｙサーバ装置も、
同じくワークステーション４００により実現される。こ
のワークステーション４００は、概略、図１７に示され
るワークステーション２００と同様の構成であるが、第
１ネットワークＩ／Ｏインタフェース２１２および第２
ネットワークＩ／Ｏインタフェース２１４に代えて、内
部ネットワーク２３に接続された１つのネットワークＩ
／Ｏインタフェース４０２を有している点で異なってい
る。内部ネットワーク２３は、ルータ２１０を介して外
部ネットワーク２５に接続されており、また複数個のク
ライアント計算機２４にも接続されている。ワークステ
ーション４００は、内部ネットワーク２３およびルータ
２１０を介して外部ネットワーク２５のサーバ計算機１
１と通信するとともに、内部ネットワーク２３およびク
ライアント計算機２４を介してユーザ３１と通信するこ
とができる。

【００４０】 図１９と図１７とにおいて、同一の部品
には同一の参照符号および名称を与えている。それらの
機能も同一である。したがって、ここではそれらについ
ての詳しい説明は繰返さない。

【００４１】 ｐｒｏｘｙサーバ装置は、既に述べたよ
うに中継データのキャッシュ機構を有する。すなわち、
ｐｒｏｘｙサーバ装置はその内部に存在するキャッシュ
ファイル装置に、中継するファイルオブジェクトのデー
タをキャッシュする。

【００４２】 ｐｒｏｘｙサーバ装置のキャッシュファ
イルには、ｐｒｏｘｙサーバ装置固有の有効期限が定め
られている。ファイルオブジェクトがキャッシュに書込
まれてから有効期限内に、同じサーバ計算機上のファイ
ルオブジェクトへのアクセス要求をクライアント計算機
から受取った場合には、キャッシュファイルに以前に書
込まれたファイルオブジェクトを取出してクライアント
計算機に転送する。これによりサーバ計算機に対するア
クセスは発生しない。

【００４３】 このようなゲートウェイ装置によるキャ
ッシュの効果を以下具体的に説明する。ｐｒｏｘｙサー
バ装置はある会社組織に設置し、外部のネットワークと
は６４ｋｂｐｓの速度で接続するものとする。また、こ
のｐｒｏｘｙサーバ装置は一方で、１０Ｍｂｐｓの速度
の会社組織内のローカルエリアネットワークに接続され
るものとする。外部と内部のネットワークの速度差は１
桁以上ある。このような例はよく見られる例であり、そ
の典型的な例が図１９に示す構成である。

【００４４】 このとき、ｐｒｏｘｙサーバ装置で中継
ファイルオブジェクトをキャッシュするものとして、キ
ャッシュのヒット率をＨｉｔｒａｔｅとする。Ｈｉｔｒ
ａｔｅは、ファイルオブジェクトに対するアクセス要求
に対してキャッシュが１００％ヒットするとき１であ
り、０％ヒットするとき０になる指数である。

【００４５】 なお、ｐｒｏｘｙサーバ装置におけるキ
ャッシュファイルからのデータ読出およびキャッシュフ
ァイルへのデータ書込速度は、ネットワーク速度に比べ
て十分高速であるものとする。すなわち、キャッシュフ
ァイルに対するファイルオブジェクトの入出力に要する
時間は無視できるものとする。

【００４６】 このとき、外部ネットワークにあるファ
イルオブジェクトを内部からアクセスするときの平均ア
クセス速度Ｖａｖｅは次の数１によって表わされる。

【００４７】

【数式１】

【００４８】 キャッシュファイルが存在しない場合、
Ｈｉｔｒａｔｅは０である。したがって平均速度（ｋｂ
ｐｓ）は、数１から外部ネットワークのアクセス速度６
４ｋｂｐｓと等しくなる。また、Ｈｉｔｒａｔｅが１で
あれば、すなわち１００％キャッシュファイルにヒット
するのであれば、平均速度（ｋｂｐｓ）は、内部ネット
ワークの速度と等しく１０，０００ｋｂｐｓ（＝１０Ｍ
ｂｐｓ）となる。つまり、ヒット率が高いほどクライア
ント計算機から見た平均アクセス速度は高くなる。ヒッ
ト率と平均アクセス速度との関係を示す数１をグラフ化
したものを図２０に示す。

【００４９】 ところで、キャッシュヒット率は、キャ
ッシュファイルの量に依存している。すなわち、ファイ
ルオブジェクトをなるべくたくさんキャッシュファイル
の中に蓄積しておけば、再びアクセスされたファイルオ
ブジェクトやキャッシュファイル中に含まれる確率は高
く、ヒット率は高くなる。そうした関係を示すものとし
て、キャッシュヒット率と、キャッシュファイルの蓄積
量との関係を図２１にグラフとして示す。図２１に示す
ように、キャッシュファイルサイズを小さくすればキャ
ッシュヒット率は０に近く、キャッシュファイルサイズ
を大きくすればキャッシュヒット率は徐々に上昇する。

【００５０】 ｐｒｏｘｙプロセスにおいては、キャッ
シュファイルの内容を維持する方式として、最初のファ
イルアクセスによる書込が起きてから一定期間経過した
ファイルオブジェクトを無効としていく制御方式が取ら
れている。この一定期間を有効期限と呼んでいる。この
有効期限は、ｐｒｏｘｙサーバ装置を管理する者が実情
に合わせて適切な値を設定する。有効期限を長く取れ
ば、キャッシュファイルに蓄積されるデータ量は増加す
る。その結果、キャッシュのヒット率は高くなる。すな
わち、キャッシュのヒット率を上げるには、キャッシュ
の有効期限を長く取ればよい。

【００５１】 なお、キャッシュファイルを格納するフ
ァイル装置の記憶容量は有限であるから、有効期限を無
制限に長くするわけにはいかない。有効期限が過ぎたキ
ャッシュファイルは、何らかのタイミングで消去され
る。このようにキャッシュファイルを消去するまでの時
間を、この明細書では消去時間と呼ぶことにする。

【００５２】 本願発明者の実験によれば、キャッシュ
有効期限とキャッシュファイルに蓄積されるファイル量
とほぼ比例する。この関係を図２２に示す。これは、内
部ネットワークから外部ネットワークへのアクセス量
が、日によらずほぼ一定であるためである。したがって
次のような関係が成り立つ。

【００５３】

【数式２】

【００５４】 この関係から、図２２に示したように、
キャッシュ有効期限を増やすとキャッシュのヒット率が
高まることがわかる。

【００５５】 キャッシュ有効期限とファイルオブジェ
クトの量との関係は、クライアント計算機を利用する内
部ユーザが、外部ネットワーク上のサーバ計算機のファ
イルオブジェクトをアクセスする頻度によって異なる。
キャッシュ有効期限とキャッシュファイル蓄積量とは、
ほぼ比例するものの、その比例係数はネットワーク速
度、内部クライアント計算機ユーザ数などの使用環境に
より変動する。

【００５６】 なお、キャッシュファイル１日程度の有
効期限では、キャッシュヒット率は１２％程度である。
有効期限を１４日にするとキャッシュヒット率は４１％
程度になることが経験されている。有効期限１４日のと
きにはファイルオブジェクトが７００ＭＢ程度キャッシ
ュファイルに蓄積されていることが観察されている。

【００５７】 また、近年ローカルネットワークの規模
が大きくなり、接続されるクライアント計算機の数が増
大するにつれ、またはクライアント計算機の読出要求が
増大するにつれて、単一のｐｒｏｘｙサーバ計算機で
は、各クライアント計算機からの要求に十分に応えるこ
とが難しくなってきている。そこで、複数のｐｒｏｘｙ
サーバ計算機を組合せて、ファイルオブジェクトに対す
るアクセス処理の効率の向上を図る方式が提案されてお
り実施されている。

【００５８】 図２３は、複数のｐｒｏｘｙサーバ計算
機を用いたシステムの構成例である。ｐｒｏｘｙサーバ
計算機５０１は、広域ネットワークとローカルネットワ
ーク間の中継を行ない、ファイルオブジェクトをキャッ
シュする。このｐｒｏｘｙサーバ計算機５０１は、以後
２次キャッシュｐｒｏｘｙサーバ計算機と呼ぶ。これに
対して、ｐｒｏｘｙサーバ計算機５０３〜５０８は、１
次キャッシュｐｒｏｘｙサーバ計算機と呼ばれ、さらに
分割されたローカルネットワークに接続されるクライア
ント計算機２４と２次キャッシュｐｒｏｘｙサーバ計算
機５０１間の中継およびファイルオブジェクトのキャッ
シュを行なう。

【００５９】 たとえば、クライアント計算機２４から
１次キャッシュｐｒｏｘｙサーバ計算機５０４に対して
ファイルオブジェクトに対する読出要求を出力したとす
る。このとき、１次キャッシュｐｒｏｘｙサーバ計算機
５０４のキャッシュファイル５１０内に有効なファイル
オブジェクトが存在する場合、１次キャッシュｐｒｏｘ
ｙサーバ計算機５０４は、キャッシュファイル５１０よ
りファイルオブジェクトを取出し、読出要求を出したク
ライアント計算機２４に送信する。

【００６０】 また、１次キャッシュｐｒｏｘｙサーバ
計算機５０４に有効なファイルオブジェクトが存在しな
かった場合、クライアント計算機２４からの読出要求は
２次キャッシュｐｒｏｘｙサーバ計算機５０１に中継さ
れる。２次キャッシュｐｒｏｘｙサーバ計算機５０１
は、同様にキャッシュファイル５０２内の有効なファイ
ルオブジェクトの有無をチェックし、当該ファイルオブ
ジェクトが存在すれば１次キャッシュｐｒｏｘｙサーバ
計算機５０４に送出し、存在しなければ読出要求を広域
ネットワーク６１を介してサーバ計算機１１に中継す
る。

【００６１】 以降の処理は、単体のｐｒｏｘｙサーバ
計算機と同様であるので、ここではその詳しい説明は繰
返さない。

【００６２】 この方式によって、各々の１次キャッシ
ュｐｒｏｘｙサーバ計算機５０３〜５０８は、クライア
ント計算機を分担して受け持つことができ、負荷の分散
が図れる。また、２次キャッシュｐｒｏｘｙサーバ計算
機５０１も、各１次キャッシュｐｒｏｘｙサーバ計算機
５０３〜５０８でキャッシュされていなかったファイル
オブジェクトに関してのみ処理を行なえばよいので、負
荷の軽減が図れる。具体的には、全体でＮ台のクライア
ント計算機２４が存在する場合、従来の方式ではｐｒｏ
ｘｙサーバ計算機は、Ｎ台のクライアント計算機の要求
を処理する必要があったが、この方式では数３で算出さ
れる台数分のクライアント計算機からの要求を処理すれ
ばよいことになる。

【００６３】

【数式３】

【００６４】 しかしながら、この方式では１台の２次
キャッシュｐｒｏｘｙサーバ計算機５０１が広域ネット
ワーク６１に接続されるサーバ計算機１１との中継をす
べて行なっており、本質的な負荷の分散が達成されてい
るとは言い難い。

【００６５】 また、キャッシュファイルの使用にも無
駄が多い。すなわち、１次キャッシュｐｒｏｘｙサーバ
計算機群５０３〜５０８の有するファイルオブジェクト
の内容はすべて２次キャッシュｐｒｏｘｙサーバ計算機
５０１も保持していると考えられる。これは、中継経路
上にある２次キャッシュｐｒｏｘｙサーバ計算機５０１
と１次キャッシュｐｒｏｘｙサーバ計算５０３〜５０８
では必ずファイルオブジェクトがキャッシュされるから
である。また、各１次キャッシュｐｒｏｘｙサーバ計算
機同士でも、別の１次キャッシュｐｒｏｘｙサーバ計算
機に接続されるクライアント計算機が同一のファイルオ
ブジェクトを読出している場合、同一のファイルオブジ
ェクトを重複して持っている可能性が高い。

【００６６】 したがって、分散ファイルシステム全体
でのキャッシュ容量は２次キャッシュｐｒｏｘｙサーバ
計算機５０１のキャッシュファイル５０２の容量である
といえるので、１台の２次キャッシュｐｒｏｘｙサーバ
計算機だけではキャッシュファイルの容量には限界があ
るといえる。

【００６７】 このような問題を解決するために、図２
４のような方式が提案され実施されている。

【００６８】 この方式では、図２３の２次キャッシュ
ｐｒｏｘｙサーバ計算機５０１に相当するｐｒｏｘｙサ
ーバ計算機は存在しない。各ｐｒｏｘｙサーバ計算機６
０１〜６０６は、クライアント計算機群を分担して受け
持っている。たとえば、ｐｒｏｘｙサーバ計算機６０２
に接続されたクライアント計算機２４からの読出要求
は、ｐｒｏｘｙサーバ計算機６０２に受信される。ここ
で、ｐｒｏｘｙサーバ計算機６０２のキャッシュファイ
ル６０８に有効なファイルオブジェクトが存在する場
合、当該ファイルオブジェクトを取出し、読出要求を出
したクライアント計算機２４に送出する。

【００６９】 ｐｒｏｘｙサーバ計算機６０２のキャッ
シュファイル６０８に有効なファイルオブジェクトが存
在しなかった場合、ｐｒｏｘｙサーバ計算機６０２はロ
ーカルネットワーク６００に接続される他のｐｒｏｘｙ
サーバ計算機６０１，６０３〜６０６に対し、それぞれ
に接続されるキャッシュファイル６０７，６０９〜６１
２内に有効なファイルオブジェクトを保持しているかど
うかを問合せる。有効なファイルオブジェクトを保持し
ているｐｒｏｘｙサーバ計算機が存在する場合には、た
とえば、ｐｒｏｘｙサーバ計算機６０５がキャッシュフ
ァイル６１１に有効なファイルオブジェクトを保持して
いる場合、ｐｒｏｘｙサーバ計算機６０５はｐｒｏｘｙ
サーバ計算機６０２に対してファイルオブジェクトを送
信し、ｐｒｏｘｙサーバ計算機６０２は当該ファイルオ
ブジェクトを読出要求を出したクライアント計算機２４
に送出する。

【００７０】 ローカルネットワーク６００に接続され
たｐｒｏｘｙサーバ計算機６０１，６０３〜６０６のキ
ャッシュファイル６０７，６０９〜６１２に有効なファ
イルオブジェクトが存在しなかった場合、ｐｒｏｘｙサ
ーバ計算機６０２は広域ネットワーク６１を経由して、
サーバ計算機１１にクライアント計算機２４からの読出
要求を中継する。

【００７１】 以降の処理は、単体のｐｒｏｘｙサーバ
計算機と同様であるので、ここでの詳細な説明は繰返さ
ない。

【００７２】 この方式により、同一のファイルオブジ
ェクトを複数のｐｒｏｘｙサーバ計算機が保持すること
がなくなり、キャッシュファイルの有効利用が図れる。
また、分散ファイルシステム全体でのキャッシュ容量
は、全ｐｒｏｘｙサーバ計算機６０１〜６０６のキャッ
シュファイル６０７〜６１２の容量の合計となり、キャ
ッシュの大容量化が図れる。したがって、高いキャッシ
ュヒット率が期待でき、実行転送速度の向上が期待でき
る。

【００７３】 また、図２５のような方式も提案され実
施されている。図２３の方式との違いは、２次キャッシ
ュｐｒｏｘｙサーバ計算機７０５〜７０７が複数台用意
され、１次キャッシュｐｒｏｘｙサーバ計算機７１１〜
７１６が２次キャッシュｐｒｏｘｙサーバ計算機７０５
〜７０７にクライアント計算機群からの読出要求を中継
する場合、その読出要求の要求先であるサーバ計算機７
０１，７０２のアドレス名称によって、たとえば、名称
がｘｘｘ．ｅｄｕならばｅｄｕドメインサーバ計算機７
０２に対する読出要求と判断して、ｐｒｏｘｙサーバ計
算機７０５にアクセス要求を出力する。また、名称がｙ
ｙｙ．ｃｏｍならばｃｏｍドメインサーバ計算機７０２
に対する読出要求と判断してｐｒｏｘｙサーバ計算機７
０６にアクセス要求を出力する。このように、末尾のド
メイン名称（ｅｄｕ，ｃｏｍ等）による簡単なルールで
アクセス要求を中継する２次キャッシュｐｒｏｘｙサー
バ計算機７０５〜７０７を選択している。

【００７４】 その他の処理は単一のｐｒｏｘｙサーバ
計算機と同一であるので、ここでの詳細な説明は繰返さ
ない。

【００７５】 これにより、同一の２次キャッシュｐｒ
ｏｘｙサーバ計算機に読出要求が集中することがなくな
り、負荷の分散が図れる。この方式においても、同一の
ファイルオブジェクトを複数の２次キャッシュｐｒｏｘ
ｙサーバ計算機が保持する必要はなく、キャッシュファ
イルの有効利用が図れる。また、分散ファイルシステム
全体でのキャッシュ容量は全２次キャッシュｐｒｏｘｙ
サーバ計算機のキャッシュファイルの容量の合計とな
り、キャッシュの大容量化が図れる。したがって、高い
キャッシュヒット率が期待でき、実行転送速度の向上が
期待できる。

【文献１】特開平４−３１３１２６号公報

【文献２】特開昭６３−２００２４４号公報

【文献３】特開昭６３−２０１８４号公報

【発明の開示】 【発明が解決しようとする課題】

【００７６】 上述したｐｒｏｘｙサーバ装置において
は、キャッシュ有効期限をある程度の長さに設定するこ
とによりキャッシュファイルに蓄積されるファイルオブ
ジェクトの容量が増え、キャッシュヒット率が高まり効
率的なファイルオブジェクトの転送が可能になる。

【００７７】 しかし、一方、サーバ計算機のファイル
オブジェクトの内容は、修正変更されることがあるた
め、キャッシュファイルの有効期限が長いと、その期間
内はサーバ計算機内のファイルオブジェクトの内容が変
更されているにもかかわらず、内部ネットワークのクラ
イアント計算機のユーザはキャッシュファイルに蓄積さ
れた古い内容のファイルオブジェクトを読出すことにな
る。

【００７８】 たとえば、天気図や電子新聞等のファイ
ルオブジェクトは、同一のファイルオブジェクト名称で
ありながら数時間おきに情報更新されるものが多い。し
たがって、たとえば、キャッシュ有効期限を２４時間と
すると、３時間おきに更新される天気図、電子新聞など
の情報は７／８以上の確率で古くて役に立たない情報と
なってしまう。

【００７９】 図２６は、このような従来のｐｒｏｘｙ
サーバ装置におけるキャッシュ制御のデータの流れをタ
イムチャートにしたものである。Ａ，Ｂ，Ｃ，Ｄ，Ｅ等
の名称は同一ファイルオブジェクト名称でありながら内
容が異なるデータであることを示している。クライアン
ト計算機がｐｒｏｘｙサーバ装置経由でアクセス（ユー
ザアクセス（１））すると、サーバ計算機のファイルオ
ブジェクトの内容Ｂがｐｒｏｘｙサーバ計算機によって
キャッシュされ、クライアント計算機にはＢが転送され
る。次に、クライアント計算機からユーザアクセス
（２）が送信されると、ｐｒｏｘｙサーバ装置にキャッ
シュされている内容Ｂは２４時間有効なので、キャッシ
ュヒットしてファイルオブジェクトの内容Ｂがクライア
ント計算機に転送される。しかしこのときには、既にサ
ーバ計算機内では内容がＥとなっているのに、クライア
ント計算機はＢという内容の古いデータを見ていること
になる。

【００８０】 このようなキャッシュファイルの内容の
うち、外部ネットワークに接続されたサーバ計算機内に
存在する元のデータが変更されている割合をステールデ
ータ率（stale date rate ）と呼ぶ。したがって、キャ
ッシュ有効期限を増やすとキャッシュファイルに蓄積さ
れるファイルオブジェクトの容量が増加してキャッシュ
ヒット率が高くなるが、キャッシュファイル内の内容の
ステールデータ率が増加することになる。

【００８１】 上述したＣＥＲＮのｈｔｔｐｄソフトウ
ェアで構成されるｐｒｏｘｙサーバ装置であれば、特定
のサーバ計算機のファイルオブジェクトのキャッシュ有
効期限を小さくできるが、この方法ではクライアント計
算機がファイルオブジェクトにアクセスを行なうと、キ
ャッシュ有効期限が短いためキャッシュにミスヒットし
てからサーバ計算機にファイルオブジェクトに対するア
クセスを行なうことになる。したがって、クライアント
計算機のユーザは、ｐｒｏｘｙサーバ計算機によるキャ
ッシュの恩恵を受けられず、広域ネットワークによる低
速なファイルオブジェクト転送が終了するまで待たされ
ることになる。

【００８２】 したがって上述した従来の技術では、キ
ャッシュファイルの中のファイルオブジェクトの内容の
新鮮さとキャッシュヒット率の維持はそれぞれ相反する
問題となる。

【００８３】 一般に、キャッシュファイルのステール
データ率が増加すると、クライアント計算機のユーザは
内容が古いはずであると自主的に判断してファイルオブ
ジェクトをサーバ計算機から直接ロードするようにな
る。この場合キャッシュファイルを通り越して、実際に
サーバ計算機からロードすることを指定するプロトコル
が利用される。その結果、ｐｒｏｘｙサーバ計算機のキ
ャッシュファイルが意味を持たなくなることになる。

【００８４】 また、従来よりｐｒｏｘｙサーバ計算機
の負荷を分散する方法として、上述したように図２３〜
図２５の方式が提案されている。しかしいずれの場合に
も十分に負荷が分散されているとはいえない。図２３に
示す方式では、１台の２次キャッシュｐｒｏｘｙサーバ
計算機５０１が広域ネットワークに接続されているサー
バ計算機との中継をすべて行なっているので、負荷の分
散が達成されているとはいえない。

【００８５】 図２４の方式では、ｐｒｏｘｙサーバ計
算機６０１〜６０６と広域ネットワーク６１との間の経
路が多重化されていない。また、ローカルネットワーク
６００に接続されるｐｒｏｘｙサーバ計算機６０１〜６
０６は、この方式に対応した特殊なプロトコルを理解す
るものに置き換える必要がある。

【００８６】 図２５の方式では、１次キャッシュｐｒ
ｏｘｙサーバ計算機７１１〜７１６は、ドメイン名等の
単純なルールで分散を行なうので、２次キャッシュｐｒ
ｏｘｙサーバ計算機７０５〜７０７間での負荷の偏りが
生じる。

【００８７】 本発明は、上記問題点を解決するために
なされたもので、その目的は、ファイルオブジェクトに
対するアクセス要求を分散して経路を有効に利用し、ス
ループットを向上させ、さらにローカルネットワーク上
の通信量を削減することである。

【発明を実施するための最良の形態】

【００９７】 ［実施の形態１］ 本発明が適用されるゲートウェイ装置（ｐｒｏｘｙサー
バ装置と呼ぶ）は、ネットワークインタフェースを備え
たＵＮＩＸ（Ｒ） ＯＳの動作する計算機によって、以
下の説明および図面を参照すれば容易に実現可能であ
る。そうしたｐｒｏｘｙサーバ装置の構成の一例は、図
１９に示したとおりである。図１９のｐｒｏｘｙサーバ
装置については既に説明したので、その構成についての
詳細な説明はここでは繰返さない。

【００９８】 通常は、ユーザ３１がクライアント計算
機２４を使用してｐｒｏｘｙサーバ装置（図１９におけ
るｐｒｏｘｙサーバ装置４００）に対して、サーバ計算
機１１のファイルオブジェクト１０にを取得するようネ
ットワーク２３を経由して依頼を出す。ファイルオブジ
ェクト１２は、前述したようにプロトコル名称と、サー
バ計算機のネットワークアドレスと、ファイルオブジェ
クトの名称と、ファイルデータの実体との組からなって
いる。

【００９９】 図１に本願発明に係るｐｒｏｘｙサーバ
装置の第１の実施の形態における装置５３のシステム構
成を示す。ｐｒｏｘｙサーバ装置５３は、内部ネットワ
ーク２３および外部ネットワーク２５に接続された第１
のｐｒｏｘｙプロセス１４と、第１のｐｒｏｘｙプロセ
ス１４が使用するキャッシュファイル１６と、第１のｐ
ｒｏｘｙプロセス１４が、アクセスログ（転送記録）と
してファイルの名称を記録するアクセスログ１５と、ア
クセスログ１５の末尾から順次取出して格納し、先に格
納されたアクセスログから順に出力するＦＩＦＯバッフ
ァ３５と、予め作成されたアクセスパターンリストを格
納するパターンファイル３０と、ＦＩＦＯバッファ３５
からアクセスログを取出してパターンファイル３０に格
納されたアクセスパターンと比較し一致する場合にはこ
のアクセスログをメモリバッファＵＲＬＢＵＦ（ＵＲＬ
については後述する）に格納するキャッシュ更新プロセ
ス３６と、ＵＲＬＢＵＦに格納されたアクセスログに含
まれるファイルオブジェクト名称をもとに、当該ファイ
ルオブジェクトをサーバ計算機１１から取得してキャッ
シュファイル１６に格納する第２のｐｒｏｘｙプロセス
３４とを含む。

【０１００】 第１のｐｒｏｘｙプロセス１４と、第２
のｐｒｏｘｙプロセス３４と、キャッシュ更新プロセス
３６とはいずれも、たとえば図１９に示すメモリ２０６
内にプログラムとして格納され、ＣＰＵ２０２によって
これを実行することにより実現される。

【０１０１】 第１のｐｒｏｘｙプロセス１４が、特許
請求の範囲に記載の転送手段に相当し、キャッシュファ
イル１６がキャッシュファイル手段に相当し、アクセス
ログ１５がファイル転送記録手段に相当する。また、キ
ャッシュ更新プロセス３６と、パターンファイル３０
と、ＦＩＦＯバッファ３５と、第２のｐｒｏｘｙプロセ
ス３４とによりキャッシュ更新手段が構成される。

【０１０２】 第２のｐｒｏｘｙプロセス３４は、本願
発明に係るゲートウェイ装置に特有なものであるが、次
のような条件に従って起動される。

【０１０３】 （１） 第２のｐｒｏｘｙプロセス３４
は、第１のｐｒｏｘｙプロセス１４と共通のキャッシュ
ファイル１６を使用する。

【０１０４】 （２） 第２のｐｒｏｘｙプロセス３４
のキャッシュ有効期限は０に設定される。すなわち、第
２のｐｒｏｘｙプロセスを経由するサーバ計算機１１へ
のアクセスは、必ず外部ネットワーク２５内のサーバ計
算機１１に対して行なわれ、ファイルオブジェクトを取
得してキャッシュファイル１６に格納する。

【０１０５】 図１に示すｐｒｏｘｙサーバ装置５３の
動作について以下説明する。内部ネットワーク２３内の
クライアント計算機２４が、このｐｒｏｘｙサーバ装置
５３に対してネットワークアクセス要求１９を与えるも
のとする。第１のｐｒｏｘｙプロセス１４が、このネッ
トワークアクセス要求１９を受け取り、まずＩ／Ｏイン
タフェース２０２（図１７、図１８、図１９参照）を経
由してファイル装置２１６内に存在するキャッシュファ
イル１６をアクセスする（２１）。また第１のｐｒｏｘ
ｙプロセス１４は、このネットワークアクセス要求とキ
ャッシュファイル１６内のファイルオブジェクト名称と
を比較し（２２）、一致しているか否かを判定する。一
致したものがあれば第１のｐｒｏｘｙプロセス１４はさ
らに、当該ファイルオブジェクトのキャッシュファイル
１６内の最終変更時刻を抽出し（２２）、現在の時刻と
比較する。そして現在の時刻が、当該ファイルオブジェ
クトの最終変更時刻を起点とする有効期限内であれば、
キャッシュファイル１６から当該ファイルオブジェクト
を抽出し（２２）、ネットワークＩ／Ｏインタフェース
４０２を経由してクライアント計算機２４にファイルオ
ブジェクトを返す（２０）。

【０１０６】 該当するファイルオブジェクトがキャッ
シュファイル１６内に存在していない場合、または存在
していてもそのキャッシュ有効期限が切れている場合に
は、第１のｐｒｏｘｙプロセス１４は、ネットワークＩ
／Ｏインタフェース４０２を経由して外部ネットワーク
２５のサーバ計算機１１にファイルオブジェクト転送要
求１７を送る。このときのサーバ計算機１１は、当該フ
ァイルオブジェクト内のネットワークアドレス名称によ
り特定される。

【０１０７】 該当するサーバ計算機１１は、要求され
たファイルオブジェクトを第１のｐｒｏｘｙプロセス１
４に返送する（１８）。すなわちこのファイルオブジェ
クトが第１のｐｒｏｘｙプロセス１４により取得され
る。

【０１０８】 第１のｐｒｏｘｙプロセス１４は、この
ファイルオブジェクトをキャッシュファイル１６にその
最終変更時刻とともに書込み（２１）、アクセスログ１
５にこのファイルオブジェクトの名称を記録する（２
６）。

【０１０９】 一方、本願発明のｐｒｏｘｙサーバ装置
５３は、キャッシュ更新プロセス３６と第２のｐｒｏｘ
ｙプロセス３４とをＣＰＵ２０２により処理走行させて
ファイルオブジェクトを更新する点において従来のｐｒ
ｏｘｙサーバ装置と相違する。

【０１１０】 キャッシュ更新プロセス３６および第２
のｐｒｏｘｙプロセス３４は次のように動作する。第１
のｐｒｏｘｙプロセス１４によってアクセスログファイ
ル１５に格納されたアクセスログの末尾からＦＩＦＯバ
ッファ３５に順に格納される（２８）。ＦＩＦＯバッフ
ァ３５は、先に格納されたアクセスログから順に出力す
る（２７）。キャッシュ更新プロセス３６は、ＦＩＦＯ
バッファ３５からアクセスログを１行ずつ抽出し、メモ
リバッファに格納する。キャッシュ更新プロセス３６
は、メモリバッファからアクセスログを取出し、それぞ
れのアクセスログをもとにキャッシュにヒットしている
か否かを判定する。キャッシュにヒットしていればさら
に、パターンファイル３０からアクセスパターンリスト
を抽出し（２９）、アクセスログに含まれるファイルオ
ブジェクト名称がアクセスパターンリストと一致してい
るものを抽出する。またキャッシュ更新プロセス３６
は、抽出したファイルオブジェクトのうちファイルオブ
ジェクト名称が特定のパターンに一致するものは除外し
て、これをメモリバッファＵＲＬＢＵＦに格納する。

【０１１１】 第２のｐｒｏｘｙプロセス３４は、ＵＲ
ＬＢＵＦが空でないならば、ＵＲＬＢＵＦに格納された
ファイルオブジェクト名称をもとに（３１）、サーバ計
算機１１にアクセスし（３２）、当該ファイルオブジェ
クトを取得して（３３）キャッシュファイル１６に格納
する（３７）。これによりキャッシュファイル１６内の
ファイルオブジェクトが最新の内容に維持される。

【０１１２】 このように、第２のｐｒｏｘｙプロセス
３４を起動すると、大きく次の２つの効果を得ることが
できる。

【０１１３】 （１） 第１のｐｒｏｘｙプロセス１４
では、キャッシュファイルの有効期限がある値に設定さ
れており、ファイルオブジェクトのキャッシュ更新処理
をこの第１のｐｒｏｘｙプロセス１４を用いて行なった
とすると、キャッシュファイル１６にヒットしてしまう
可能性が高い。これでは、外部ネットワーク２５のサー
バ計算機１１のファイルオブジェクトに対するアクセス
が行なわれないので、キャッシュファイル１６の更新が
実現できない。

【０１１４】 一方、第２のｐｒｏｘｙプロセス３６
は、キャッシュ有効期限が０になっており、第２のｐｒ
ｏｘｙプロセス３６に対してアクセス要求を出せば、こ
のキャッシュファイルはミスヒットしたことになるの
で、外部ネットワーク２５を介してサーバ計算機１１に
対するファイルオブジェクトのアクセスが行なわれ（３
２）、当該ファイルオブジェクトは第２のｐｒｏｘｙプ
ロセス３４に転送される（３３）ことによって、キャッ
シュファイル１６中のファイルオブジェクトは最新の状
態に更新される。

【０１１５】 （２） 第１のｐｒｏｘｙプロセス１４
は、アクセスログを残すが、このアクセスログをもとに
キャッシュ更新アクセスをするべきファイルオブジェク
トが抽出される。したがって、もしキャッシュ更新プロ
セス３６が第１のｐｒｏｘｙプロセス１４を使用してサ
ーバ計算機１１のファイルオブジェクトのアクセスを行
なうと、その結果として生成されるアクセスログがアク
セスファイル１５に記録されてしまう。キャッシュ更新
プロセス３６は、次回の更新アクセス動作においてアク
セスログファイル１５に格納されたアクセスログをもと
にアクセスすべきファイルオブジェクト名称を抽出す
る。したがって、再度同じファイルオブジェクトをサー
バ計算機１１から取得することになり、同一のファイル
オブジェクトが多重に出現するループ動作が起きてしま
うことになる。これを避けるために第２のｐｒｏｘｙプ
ロセス３４を動作させ、第２のｐｒｏｘｙプロセス３４
を利用したキャッシュ更新アクセス動作を行なう。

【０１１６】 本発明を非常に有効に適用できる例とし
て、インターネット上のＷＷＷシステムがある。ＷＷＷ
システム上でのｐｒｏｘｙサーバ装置において、本願発
明のキャッシュ更新プロセスを行なう手順を以下に説明
する。

【０１１７】 ＷＷＷシステムでは、ネットワーク上に
分散したファイルオブジェクト名称はUniform Resource
Locator（ＵＲＬ）と呼ばれる形式で表現され、特定さ
れる。ＵＲＬの一例を次に示す。

【０１１８】

【数式４】

【０１１９】 数４においては「ｈｔｔｐ」は使用する
プロトコルを示す。「ｗｗｗ．ｘｘｘ．ｃｏ．ｊｐ」
は、ネットワーク上のＨＴＴＰサーバ計算機のアドレス
を示すものであり、ネットワーク上で同一のものはない
よう選ばれている。また「／ｔｅｓｔ／ｉｎｄｅｘ．ｈ
ｔｍｌ」はサーバ計算機内のファイル名称を示す。

【０１２０】 第１のｐｒｏｘｙプロセス１４として一
般に利用されているＤｅｌｅＧａｔｅを使用する場合
は、そのアクセスログの例は次のように、クライアント
計算機名称、時刻、“ＨＴＴＰプロトコル（ファイル取
得要求）”、その他、およびキャッシュヒット状況（キ
ャッシュヒットした場合Ｈ）などとなる。以下に、その
アクセスログの例を示す。

【０１２１】

【数式５】

【０１２２】 数５に示すアクセスログは、図２に示す
ような、出願人がインターネット上で公開している情報
ページへアクセスした場合のアクセスログに相当する。
図２に示されるページは、テキストと、６個のグラフィ
ックデータとから構成されているので、このページに対
するアクセスを１回行なうと、６個のグラフィックデー
タに対するアクセスを含む７つのアクセスログが形成さ
れる。すなわち、上述のアクセスログにおいて第１行目
はこの情報ページのテキストに対するアクセス要求であ
り、残りの６行は表紙に貼り込まれた出願人会社のロゴ
のグラフィックデータ（ｓｈａｒｐｃｏｌｏｒ．ｇｉ
ｆ）、出願人会社内の情報システム事業本部と呼ばれる
事業部のロゴ（ｉｓｇ．ｇｉｆ）、出願人会社の４つの
製品の写真のグラフィックデータ（Ｚａｕｒｕｓ．ｇｉ
ｆ，Ｓｈｏｉｎ．ｇｉｆ，Ｐｒｏｓｔａｔｉｏｎ．ｇｉ
ｆ，Ｓ２．ｇｉｆ）の取得要求を示している。

【０１２３】 ＨＴＴＰプロトコルは、コマンド文字列
（ＧＥＴ等）と、ＵＲＬと、プロトコルバージョン
（「ＨＴＴＰ／１．０」等）から構成されている。以下
はその一例である。

【０１２４】

【数式６】

【０１２５】 ＨＴＴＰプロトコルについては、最後に
掲げる表内に示された参考文献のうち、参考文献３およ
び参考文献４に記載されている。キャッシュ更新プロセ
スの実施手順について以下に説明するが、そのための前
提条件は次の（１）および（２）となっている。

【０１２６】 （１） 第１のｐｒｏｘｙプロセス１４
は、キャッシュ有効期限Ｍ（時間）で起動する。たとえ
ばＭ＝２４時間とする。

【０１２７】 （２） 第２のｐｒｏｘｙプロセス３４
は、（ｉ）キャッシュファイルを第１のｐｒｏｘｙプロ
セス１４のものと共有し、（ｉｉ）キャッシュ有効期限
を０に設定する、という２つの条件に従って起動され
る。

【０１２８】 このような条件の下に、本願発明のキャ
ッシュ更新プロセスを毎日一定時刻に起動し、一定時刻
に終了する。毎日一定時刻にキャッシュ更新プロセスを
自動起動するには、ＵＮＩＸ（Ｒ） ＯＳに備わってい
るタイマ機能（ｃｒｏｎ）を使用する。これは、ＵＮＩ
Ｘ（Ｒ） ＯＳに関連してよく知られている機能である
ので、その詳細についてはここでは説明しない。なお、
ＵＮＩＸ（Ｒ） ＯＳ以外のＯＳでも、同様の機能が提
供されていることが多い。

【０１２９】 図３は、本願発明のキャッシュ更新プロ
セスの処理手順を示すフローチャートである。このプロ
セスを実現するためのプログラムは、たとえば図１９の
メモリ２０６内に配置され、ＣＰＵ２０２によって実行
される。このプロセスとネットワークおよびファイル装
置２１６との入出力には、それぞれネットワークＩ／Ｏ
インタフェース４０２とＩ／Ｏインタフェース２０８と
が使用される。

【０１３０】 まず、ステップＳ１において第１のｐｒ
ｏｘｙプロセス１４が、アクセスログファイル１５に格
納されるアクセスログの末尾を１行読出す。読出せない
場合は、アクセスログが読めるまで待機する。ＵＮＩＸ
（Ｒ）では、このようなアクセスログの末尾を呼出す機
能は、ＯＳとともに提供されているコマンドｔａｉｌで
可能であり、その標準出力から１行読出し、メモリ内に
確保された文字列バッファであるＬＩＮＥバッファに１
行格納するには、以下のように行なう。ここで、第１の
ｐｒｏｘｙプロセス１４が格納したアクセスログが／ｕ
ｓｒ／ｌｏｃａｌ／ｅｔｃ／ｔｅｌｅｇａｔｅｄ／ｌｏ
ｇｓ／１０００１．ｈｔｔｐであるとする。これは図１
のアクセスログファイル１５に格納されるアクセスログ
に相当する。

【０１３１】

【数式７】

【０１３２】 数７のｔａｉｌ −ｆによる１行読出
は、図１の２７に相当するが、これはソフトウェアによ
るＦＩＦＯバッファ３５を構成しており、読出ポインタ
および書込ポインタをそれぞれ有している。

【０１３３】

【数式８】

【０１３４】 すなわち、第１のｐｒｏｘｙプロセス１
４が書込むアクセスログは、１個のファイルオブジェク
ト転送ごとに１行発生するが、このとき書込ポインタ
（ｗｐ）を１行進める。また、ソフトウェアによるＦＩ
ＦＯバッファ３５がｔａｉｌ −ｆでアクセスログを１
行読出せば、読出ポインタ（ｒｐ）を１行進める。第１
のｐｒｏｘｙプロセス１４による書込速度（行／秒）
と、キャッシュ更新プロセス３６におけるｔａｉｌ −
ｆによる１行読出速度（行／秒）が一致していなくても
よい。第１のｐｒｏｘｙプロセス１４によるアクセスロ
グ書込速度が大きくなると、書込ポインタ（ｗｐ）は先
に進むが、キャッシュ更新プロセス３４によってこれを
読出ポインタ（ｒｐ）が追いかけながらアクセスログが
読出される。アクセスログ書込速度が小さいか、読出側
のキャッシュ更新プロセス３４の処理が進行すれば、や
がて読出ポインタ（ｒｐ）が書込ポインタ（ｗｐ）に追
いつくことになる。これが、ソフトウェアＦＩＦＯバッ
ファとしての動作である。

【０１３５】 次に、ＬＩＮＥバッファに格納された１
行のアクセスログ情報は過去にアクセスされたファイル
オブジェクトの記録であるので、以下のような条件でキ
ャッシュ更新アクセスを行なうべきファイルオブジェク
ト名称を含むものを選択する。この選択処理を、以後フ
ィルタリングと呼び、図３に示すフローチャートのステ
ップＳ２に相当する。このフィルタリングのルールは以
下のとおりである。

【０１３６】 （１） ＨＴＴＰコマンド文字列がファ
イルオブジェクトに対するリード要求（ＧＥＴ）である
もの。

【０１３７】 （２） ファイルオブジェクト名称のプ
ロトコル部分がｈｔｔｐであるもの。

【０１３８】 （３） キャッシュにヒットしたアクセ
スであるもの。

【０１３９】 （４） ファイルオブジェクト名称がキ
ャッシュ更新アクセスに適さないものを除外する。

【０１４０】 （５） 特定の文字列パターンを含むア
クセスリストとファイルオブジェクト名称が一致するも
の。

【０１４１】 以上の（１）〜（５）の条件を用いてフ
ィルタリングを行ない、ファイルオブジェクト名称のフ
ィールドだけを取出して、キャッシュ更新アクセスでフ
ァイルオブジェクト名称を抽出する。

【０１４２】 ファイルオブジェクト名称のプロトコル
部分がｈｔｔｐのもののみ抽出するのは、第１のｐｒｏ
ｘｙプロセス１４および第２のｐｒｏｘｙプロセス３４
として一般的に利用されているＤｅｌｅＧａｔｅソフト
ウェアがキャッシュファイルを生成するプロトコルはｈ
ｔｔｐプロトコルのみであるので、そのファイルオブジ
ェクトのみはキャッシュ更新アクセスする意味があるか
らである。それ以外のプロトコルによるアクセスはファ
イルオブジェクトがキャッシュされないので、キャッシ
ュ更新アクセスをする意味がない。

【０１４３】 キャッシュにヒットしたもののみを抽出
するのは、キャッシュにヒットしていないファイルオブ
ジェクトはサーバ計算機１１へのアクセスが行なわれた
ものと解釈されるので、その直後にキャッシュ更新アク
セスを行なう必要はないと判断されるからである。

【０１４４】 ファイルオブジェクト名称が、キャッシ
ュ更新アクセスに適さないものとしては、ＵＲＬ中に
「？」を含むものなどがある。「？」を含むＵＲＬ表記
は、サーバ計算機１１に対してクライアント計算機２４
を使用するユーザが文字列を人手で入力する場合などに
使われるため、この文字を含むＵＲＬ表記を有するファ
イルオブジェクトをキャッシュ更新アクセスの対象とす
ると、予期せぬ結果を招くおそれがある。

【０１４５】 特定の文字列パターンを含むアクセスリ
ストと一致するもののみを選ぶのは、サーバ計算機にお
いて頻繁に内容更新が行なわれるものである天気図、電
子新聞等を提供しているサーバ計算機など特定のもので
あることが多い。そこで、そのようなサーバ計算機のフ
ァイルオブジェクトを指定するような文字列パターンを
格納したアクセスリストと一致したものだけをキャッシ
ュ更新アクセスの対象とすることによって、不要なキャ
ッシュ更新アクセスを極力削減するためのものである。

【０１４６】 このような文字列パターンを格納したパ
ターンファイル３０を、ここでｐａｔｔｅｒｎ．ｔｘｔ
とし、その内容を数９に示すものとする。

【０１４７】

【数式９】

【０１４８】 ＵＮＩＸ（Ｒ）では、このようなファイ
ルオブジェクト名称の抽出作業は、ＯＳとともに提供さ
れているコマンド群である数１０を用いて行なうことが
できる。

【０１４９】

【数式１０】

【０１５０】 たとえば、次のようなコマンドを入力す
ることにより、ステップＳ２の処理を経たものがメモリ
上の文字列バッファＵＲＬＢＵＦに出力される。

【０１５１】

【数式１１】

【０１５２】 なお、上述したフィルタリングルールに
反していれば、文字列バッファＵＲＬＢＵＦは空にな
る。この間の経過を以下に説明する。第１のｐｒｏｘｙ
プロセス１４により作成されたアクセスログファイル１
５の形式は既に述べたように次のとおりである。

【０１５３】

【数式１２】

【０１５４】 キャッシュヒット時には“Ｈ”という文
字がキャッシュヒット状況として行の末尾に出力され
る。

【０１５５】 まず、ｇｒｅｐ −ｖ”＼？”に入力す
ることで、？を含まない行を抽出し標準出力に出力す
る。それをさらにｇｒｅｐ”＼”ＧＥＴ”でその行がフ
ァイルオブジェクト取得要求であるＧＥＴコマンドであ
る行のみ抽出し、標準出力に出力する。さらにｇｒｅ
ｐ’Ｈ＄’に入力することで行末が「Ｈ」で終了する、
すなわちキャッシュにヒットしたものを選び標準出力に
出力する。ここで、＄は行の末尾を表現する正規表現で
ある。

【０１５６】 さらに空白がフィールド間の区切である
と考えると、７番目のフィールドがファイルオブジェク
ト名称に相当するので、ａｗｋ’｛ｐｒｉｎｔ＄７｝’
を使ってファイルオブジェクト名称のみを抽出してい
る。

【０１５７】 さらに、ファイルオブジェクト名称部分
が、予め用意されたパターンファイルｐａｔｔｅｒｎ．
ｔｘｔの中のいずれかの行に一致するか否かをｆｇｒｅ
ｐ −ｆ ｐａｔｔｅｒｎ．ｔｘｔによりマッチングを
行なってその結果を文字列バッファＵＲＬＢＵＦに出力
する。

【０１５８】 ステップＳ３では、文字列バッファＵＲ
ＬＢＵＦが空でないか否かを判定する。もし文字列バッ
ファＵＲＬＢＵＦが空の場合には、ステップＳ１に戻
り、空でない場合にはステップＳ４へ進む。

【０１５９】 ステップＳ４では、第２のｐｒｏｘｙプ
ロセス３４によって、キャッシュ更新プロセス３６で抽
出されたファイルオブジェクトをサーバ計算機１１から
取得する。文字列バッファＵＲＬＢＵＦに格納されたキ
ャッシュ更新アクセスの対象であるファイルオブジェク
ト名称に基づいて、第２のｐｒｏｘｙプロセス３４はサ
ーバ計算機１１へアクセスするための子プロセスを起動
する。子プロセスをキャッシュ更新子プロセスと呼ぶ。
キャッシュ更新子プロセスは、第２のｐｒｏｘｙプロセ
ス３４を通じてネットワーク接続をサーバ計算機１１に
対して行なう。これにより、サーバ計算機１１に格納さ
れるファイルオブジェクトへのアクセスが発生し、キャ
ッシュファイル１６の内容が更新される。この処理の詳
細は後述する。

【０１６０】 ステップＳ５では、現在の時刻を調べ、
指定時刻が過ぎていればプロセスを終了する。指定時刻
を過ぎていなければステップＳ１に戻り、以上の処理を
繰返す。

【０１６１】 以上が、本願発明の第１の実施の形態に
おけるｐｒｏｘｙサーバ装置におけるアルゴリズムであ
る。図７は、ｐｒｏｘｙサーバ計算機５３のキャッシュ
有効期限が２４時間で、サーバ計算機１１のファイルオ
ブジェクトが同一名称でありながら、内容が３時間おき
に更新される場合のファイルオブジェクトのデータがキ
ャッシュされるようすを示している。

【０１６２】 まず、ユーザアクセス（１）が発生した
ときに、キャッシュファイル１６に該当するファイルオ
ブジェクトがなかったとすると、サーバ計算機１１から
データＢがアクセスされ、キャッシュファイル１６に書
込まれるとともに、クライアント計算機２４に転送され
る。

【０１６３】 次に、ユーザアクセス（２）が発生する
と、キャッシュにヒットしたデータＢがクライアント計
算機２４に転送される。このとき、サーバ計算機１１は
データＤになっているので、クライアント計算機２４は
３時間程度古いステールデータを読んだことになる。し
かし、この動作の結果アクセスログファイル１５にファ
イルオブジェクト名称とキャッシュにヒットしたという
情報を含むアクセスログが記録されるので、図３を用い
て説明した動作に従い、ｐｒｏｘｙサーバ装置５３が自
発的にサーバ装置１１にアクセスし、データＥを読出し
キャッシュファイル１６を更新する。

【０１６４】 さらに、ユーザアクセス（３）が起きる
と、キャッシュされたデータＥがクライアント計算機２
４に転送される。この動作をきっかけにしてアクセスロ
グファイル１５にファイルオブジェクト名称とキャッシ
ュにヒットしたという情報を含むアクセスログが記録さ
れるので、図３を用いて説明した動作に従い、ｐｒｏｘ
ｙサーバ装置５３が自発的にサーバ計算機１１にアクセ
スし、データＩを読出してキャッシュファイル１６を更
新する。

【０１６５】 したがって、ユーザアクセス（４）が起
きると、キャッシュされたデータＩがクライアント計算
機２４に転送される。

【０１６６】 以上の動作からわかるように、クライア
ント計算機２４はステールデータを読んでいることに変
わりがないが、図２６の場合に比べると最新に近い情報
を読んでいることになる。ユーザによるアクセスの間隔
が３時間以内であれば、ステールデータは発生する確率
が非常に低くなり、サーバ計算機１１の最新の情報を得
ることが可能になることが理解できる。

【０１６７】 なお、図３のステップＳ４のネットワー
クアクセス部の実現方法としては、キャッシュ更新プロ
セスから直接ＨＴＴＰプロトコルを発生させればよい
が、ＵＮＩＸ（Ｒ）では広く一般に利用されているｌｙ
ｎｘ等のＷＷＷクライアントプログラムを利用すれば、
ＨＴＴＰを発生するキャッシュ更新プロセスを新たに製
作しなくてもＨＴＴＰに従ったネットワークアクセスを
行なうキャッシュ更新プロセス操作を実現できる。その
方法を以下に説明する。

【０１６８】 ｌｙｎｘはＵＮＩＸ（Ｒ） ＯＳの上で
動作するプログラムであるので、以下の説明ではＵＮＩ
Ｘ（Ｒ）の記述を使用する。

【０１６９】 ｌｙｎｘでは次のコマンドを指定すれ
ば、指定ＵＲＬを読出してｔｅｍｐ＿ｆｉｌｅというフ
ァイルに書込むことができる。

【０１７０】

【数式１３】

【０１７１】 さらに、ｐｒｏｘｙプロセス経由のアク
セスも、ＵＮＩＸ（Ｒ） ＯＳの環境変数ｈｔｔｐ＿ｐ
ｒｏｘｙを設定することにより、ｌｙｎｘから利用可能
である。また、ｐｒｏｘｙプロセスがＤｅｌｅＧａｔｅ
のようなｐｒｏｘｙソフトウェアであれば、ＵＲＬ表記
にｐｒｏｘｙを指定することによりｐｒｏｘｙ経由のア
クセスが可能である。これについては参考文献１２を参
照されたい。

【０１７２】 後者の方式を採用する場合について以下
に説明する。ｐｒｏｘｙプロセスが、ネットワークアド
レスがｐｒｏｘｙｓｅｒｖｅｒであるゲートウェイ計算
機のＴＣＰ／ＩＰの１０００１番のポート番号を利用し
ているプロセスであるならば、このｐｒｏｘｙプロセス
経由でサーバ計算機１１のファイルオブジェクトｈｔｔ
ｐ：／／ｗｗｗ．ｘｘｘ．ｃｏ．ｊｐ／ｔｅｓｔ／ｉｎ
ｄｅｘ．ｈｔｍｌにアクセスするためには次の数１４の
コマンドを指定すればよい。

【０１７３】

【数式１４】

【０１７４】 したがって、本願発明を実施する際に
は、同様にしてｐｒｏｘｙプロセスを第２のｐｒｏｘｙ
プロセス３４のポート番号に設定すればよい。

【０１７５】

【数式１５】

【０１７６】 本願発明では、このようなファイルオブ
ジェクト（ＵＲＬ）のキャッシュ更新アクセスにより、
第１のｐｒｏｘｙプロセス１４の管理するキャッシュフ
ァイル１６を最新状態に保つことが目的である。したが
って、ｔｅｍｐ＿ｆｉｌｅ自体は利用しないので捨てて
よい。ＯＳがＵＮＩＸ（Ｒ）であれば、空ファイルとし
て／ｄｅｖ／ｎｕｌｌが準備されているので、このファ
イルに書込むようにすれば実際にはファイルの生成は行
なわないので効率的である。

【０１７７】 次に、第１のｐｒｏｘｙプロセス１４お
よび第２のｐｒｏｘｙプロセス３４のキャッシュ管理手
法について説明する。ｐｒｏｘｙプロセスのキャッシュ
管理手法は、参考文献５、参考文献１２にあるような公
知の技術であるキャッシュ制御機能を持ったＤｅｌｅＧ
ａｔｅなどにおけるものである。ＤｅｌｅＧａｔｅにお
けるキャッシュ管理手法は、ソースコードの形で公開さ
れているので以下にその手法を述べる。なお、本願発明
はこれと同様のキャッシュ管理手法が使われているキャ
ッシュ機能付ｐｒｏｘｙサーバソフトウェアであれば、
第１のｐｒｏｘｙプロセス１４および第２のｐｒｏｘｙ
プロセス３４として適用可能である。

【０１７８】 上述したように、第２のｐｒｏｘｙプロ
セス３４がｐｒｏｘｙｓｅｒｖｅｒという名称のシステ
ムで動作しており、ＴＣＰ／ＩＰの１０００１番でＵＲ
Ｌ取得要求を受付けるものとする。このとき、文字列バ
ッファＵＲＬＢＵＦに指定ＵＲＬ表記が格納されている
場合に、キャッシュ更新プロセス３６は、数１６に記載
のコマンドを実行することでｔｅｍｐ＿ｆｉｌｅに指定
ＵＲＬのファイルオブジェクトが格納されると述べた。

【０１７９】

【数式１６】

【０１８０】 なお、第２のｐｒｏｘｙプロセス３４と
キャッシュ更新プロセス３６の通信はＴＣＰ／ＩＰ、た
とえばＵＮＩＸ（Ｒ）のメッセージ通信で行なわれる。

【０１８１】 たとえば、文字列バッファＵＲＬＢＵＦ
にｈｔｔｐ：／／ｗｗｗ．ｓｈａｒｐ．ｃｏ．ｊｐ／ｓ
ａｍｐｌｅ／ｔｅｓｔ．ｈｔｍｌという文字列が格納さ
れているとする。キャッシュ更新プロセス３６が数１６
のコマンドを実行すると、キャッシュ更新プロセス３６
はＵＲＬ取得要求を第２のｐｒｏｘｙプロセス３４に出
力する。第２のｐｒｏｘｙプロセス３４は、子プロセス
を生成し、この子プロセスにＵＲＬ取得の処理を任せて
自身のプロセスは再びキャッシュ更新プロセス３６から
のＵＲＬ出力要求を待つ。キャッシュ更新プロセス３４
による数１６の実行によりＵＲＬ取得を実行する第２の
ｐｒｏｘｙプロセス３４が生成した子プロセスは、図４
のフローチャートに示す処理を行なう。

【０１８２】 以下、第２のｐｒｏｘｙプロセス３４が
生成した子プロセスの動作を図４のフローチャートを用
いて説明する。

【０１８３】 ｐｒｏｘｙプロセスでは、キャッシュフ
ァイル１６を持っているが、それは通常のＵＮＩＸ
（Ｒ）ファイルシステムの一部として作られる。キャッ
シュ用ディレクトリとして／ｃａｃｈｅというパーティ
ションを使用するとすると、数１７に示すようにプロト
コル名称がｈｔｔｐ、サーバ計算機名称ｗｗｗ．ｓｈａ
ｒｐ．ｃｏ．ｊｐ、ファイルオブジェクトの実体部分が
ｓａｍｐｌｅ／ｔｅｓｔ．ｈｔｍｌとなる。

【０１８４】

【数式１７】

【０１８５】 このとき、キャッシュファイルは次の数
１８に示す名称規則でキャッシュファイルを生成しよう
とする。

【０１８６】

【数式１８】

【０１８７】 したがって、ｈｔｔｐ：／／ｗｗｗ．ｓ
ｈａｒｐ．ｃｏ．ｊｐ／ｓａｍｐｌｅ／ｔｅｓｔ．ｈｔ
ｍｌは数１９に示すファイルとなる（Ｓ１１）。

【０１８８】

【数式１９】

【０１８９】 ｐｒｏｘｙプロセスはまず、数１９に示
すファイル名称に変換し、そのファイルが存在するかど
うかＯＳのｏｐｅｎ（ ）のシステムコールにより既存
のファイルがオープンできるかどうかにより調べる（Ｓ
１２）。ファイルが存在しなければ、ファイル新規作成
モードで数１９に示すファイル名のキャッシュファイル
を作成する（Ｓ１３）。また、キャッシュファイルに対
して排他制御を行なって、他のプロセスが書込めないよ
うに排他ロックする（Ｓ１４）。

【０１９０】 次に、ネットワークを経由してＵＲＬで
指定されたファイルオブジェクトをサーバ計算機１１か
ら取得する（Ｓ１５）。取得したファイルオブジェクト
をクライアント計算機２４へ転送するとともにファイル
オブジェクトを数１９に示すファイル名称のキャッシュ
ファイルに書込む（Ｓ１６）。続いて、キャッシュファ
イルをクローズして排他ロックを解除する（Ｓ１７）。

【０１９１】 上記処理では、キャッシュファイルを排
他ロックしているが、この排他制御はＯＳがＵＮＩＸ
（Ｒ）であればシステムコールであるｆｌｏｃｋ（ ）
関数を使って排他ロックできる。排他制御を使用する理
由は、ｐｒｏｘｙプロセスは１つのファイルオブジェク
トの転送ごとに子プロセスを起動してその子プロセスに
キャッシュ制御を行なわせるため、同じキャッシュファ
イルシステムに対して子プロセス間で競合が発生する場
合があるからである。

【０１９２】 なお、キャッシュファイルに書込んだと
き、ファイル変更時刻Ｔｍがファイル（数１９）の属性
として記録される。ファイル更新時刻Ｔｍは、ＵＮＩＸ
（Ｒ） ＯＳのファイルシステムを管理するＯＳがファ
イルの属性として必ず付加するものである。すなわち、
キャッシュファイルは通常のＯＳのファイルシステムを
そのまま使用しており、何ら特殊なファイルシステムで
はない。

【０１９３】 次に、キャッシュファイルが既に存在し
た場合を説明する（Ｓ１９〜Ｓ２６）。

【０１９４】 キャッシュファイル／ｃａｃｈｅ／ｈｔ
ｔｐ／ｗｗｗ．ｓｈａｒｐ．ｃｏ．ｊｐ／ｓａｍｐｌｅ
／ｔｅｓｔ．ｈｔｍｌの最終変更時刻ＴｍをＯＳから読
出す。最終変更時刻は、ＵＮＩＸ（Ｒ）であれば、ｆｓ
ｔａｔ（ ）システムコールで得られるもので、過去か
ら未来に向かって単調に増加する関数である（Ｓ１
９）。

【０１９５】 現在時刻をシステムコールから読出しＴ
ｎｏｗという変数に格納する（Ｓ２０）。現在時刻Ｔｎ
ｏｗは、ＯＳのシステムコールから得られる。最終変更
時刻Ｔｍと、現在時刻Ｔｎｏｗを比較し、キャッシュ有
効期限以内かどうかを判定する（Ｓ２１）。キャッシュ
有効期限以内であれば、キャッシュファイルを共有排他
ロックして他のプロセスからの書込はできないが、読出
はできるようにする（Ｓ２２）。そして、既にあるキャ
ッシュファイルを読出し、クライアント計算機２４に転
送する（Ｓ２３）。さらに、キャッシュファイルをクロ
ーズし、共有排他ロックを解除する（Ｓ１７）。

【０１９６】 また、キャッシュ有効期限を過ぎている
場合は、キャッシュファイルに対して排他制御を行なっ
て、他のプロセスが書込めないように排他ロックする
（Ｓ２４）。次に、ネットワーク経由でＵＲＬで指定さ
れたファイルオブジェクトをサーバ計算機１１から取得
する（Ｓ２５）。取得したファイルオブジェクトをクラ
イアント計算機２４へ転送するとともに、ファイルオブ
ジェクトをキャッシュファイル（数１９）に書込む（Ｓ
２６）。そして、キャッシュファイルをクローズして排
他ロックを解除する（Ｓ１７）。

【０１９７】 以上が、一般にソースコードが公開さ
れ、よく知られているｐｒｏｘｙプロセスのキャッシュ
制御手順であるが、本願発明ではこの性質を利用して、
キャッシュファイル１６を第１のｐｒｏｘｙプロセス１
４と第２のｐｒｏｘｙプロセス３４で共有している。第
２のｐｒｏｘｙプロセス３４は、キャッシュ有効期限０
であるから、図３のフローチャートのＳ４により、第２
のｐｒｏｘｙプロセス３４経由のサーバ計算機１１への
アクセスがキャッシュファイル１６の更新が必ず行なえ
ることがわかる。

【０１９８】 第１の実施形態においては、クライアン
ト計算機２４の利用が始まる７時００分より起動し、ク
ライアント計算機２４の利用が少なくなる夜２１時００
分には終了するよう実施した。これにより、クライアン
ト計算機２４の利用のない時間帯には、キャッシュ更新
プロセス３６を排除し、当制御方式を採用した計算機の
メモリ資源を無駄にしないようにしている。

【０１９９】 以上説明したように、ｐｒｏｘｙサーバ
計算機５３はユーザが行なったファイルオブジェクトに
対するアクセス要求がキャッシュヒットすれば、その直
後にサーバ計算機１１から当該ファイルオブジェクトを
取得してキャッシュファイル１６を更新するので、別の
ユーザが同一ファイルオブジェクトをアクセスした場合
に、最新のファイルオブジェクトが既にキャッシュファ
イル１６に格納されていることになる。したがって、キ
ャッシュ有効期限を長めに取っておいても、キャッシュ
の有効期限よりも短い間隔で変更されるサーバ計算機の
ファイルオブジェクトがキャッシュに反映される確率が
高くなる。

【０２００】 また、同一ユーザが時間をおいてから同
一ファイルオブジェクトをアクセスし直すと、キャッシ
ュの内容が最新のものに更新されていることになる。ま
た、特定のパターンに一致するファイルオブジェクトの
み更新アクセスの対象となるので、予めファイルオブジ
ェクトの更新頻度の高いサーバ計算機を登録しておけば
不要なキャッシュ更新アクセスを削減でき、無駄なトラ
フィックを抑制して回線を有効に利用することができ
る。

【０２０１】 ［実施の形態２］ 次に、本願発明のゲートウェイ装置の第２の実施形態を
説明する。この実施形態２は、実施形態１と同様である
が、実施形態１に対応するフローチャート（図３）のス
テップＳ４を改良したものである。実施形態１では、ス
テップＳ４においてアクセスログファイル１５からファ
イルオブジェクト名称を文字列格納バッファＵＲＬＢＵ
Ｆに格納して、第２のｐｒｏｘｙプロセス３４を介して
サーバ計算機１１にアクセスしているが、第２の実施形
態では処理の高速化を図るため複数のファイルオブジェ
クトに対するアクセスを、順不同で同時並列的に実行す
るものである。

【０２０２】 本発明が実施できるＴＣＰ／ＩＰのネッ
トワークでは、通信はパケット単位で行なわれるため、
外部ネットワークの複数のサーバ計算機との同時通信が
見掛け上可能である。したがって、ステップＳ４におけ
るキャッシュ更新子プロセスを複数同時に実施すること
ができる。

【０２０３】 内部ネットワーク２３には複数のクライ
アント計算機２４が接続されるので、ｐｒｏｘｙサーバ
装置５３によるファイルオブジェクトの中継転送要求
は、外部ネットワーク２５上の異なる複数のサーバ計算
機１１へのアクセスが入り交じって行なわれる。したが
って、ファイルオブジェクトに対するアクセスは外部ネ
ットワーク２５上のさまざまな経路を通じて行なわれる
ため、実際のファイルオブジェクトの転送速度は、経路
の途中のボトルネックによって決まる。

【０２０４】 そのうちの１つのボトルネックは、ｐｒ
ｏｘｙサーバ装置５３と外部ネットワーク２５を結ぶ最
初の通信路（図１９における通信路１２７）である。さ
らには、外部ネットワーク２５上への複数のサーバ計算
機１１への経路にはさまざまなボトルネックが存在す
る。このため、外部ネットワーク２５からｐｒｏｘｙサ
ーバ計算機５３への転送速度は、この通信路の最大転送
速度より小さい転送速度となるのが常である。たとえ
ば、ｐｒｏｘｙサーバ装置５３と外部ネットワーク２５
を結ぶ通信路（図１９における通信路１２７）の最大転
送速度が６４ｋｂｐｓであっても、海外にあるサーバ計
算機からの転送速度はその１０分の１以下であることが
しばしばである。

【０２０５】 したがって、ｐｒｏｘｙサーバ装置５３
と外部ネットワーク２５を結ぶ最初の通信路１２７の最
大転送容量に近い転送を行なうように、同時に複数のネ
ットワーク接続を実施することで転送のスループットを
上げることが可能になる。すなわちこのネットワーク接
続を１個の子プロセスに対応させるとして、複数のキャ
ッシュ更新子プロセスを起動し、この通信路１２７の転
送容量が１００％近く使用されるように、複数のネット
ワーク接続を並列に実施した方が処理が高速化される。

【０２０６】 そこで、同時に複数のキャッシュ更新ア
クセスを実行するように、キャッシュ更新子プロセスの
最大並列実行数をＭＡＸＰＲＯＣＥＳＳ数と定める。こ
れは、以下に説明するフローチャートではメモリ（図１
９のメモリ２０６）に置かれる定数である。この値をあ
まり大きく取ると、ＯＳのプロセス手順などの管理資源
（メモリ）を消費することになるので、システムの動作
状況によって決める必要がある。この実施形態２では１
０とした。

【０２０７】 以下、具体的な処理手順を図５を参照し
ながら説明する。まず、変数としてメモリ２０６中にｐ
ｒｏｃｅｓｓｅｓ変数を定義する。バックグラウンド
で、現在走行しているキャッシュ更新子プロセスの数を
求めてｐｒｏｃｅｓｓｅｓ変数に代入する。プロセスの
数はＯＳのプロセス管理テーブルから得られる（Ｓ４２
１）。次にｐｒｏｃｅｓｓｅｓ変数と指定された最大子
プロセス数ＭＡＸＰＲＯＣＥＳＳを比較する。もし、ｐ
ｒｏｃｅｓｓｅｓ≧ＭＡＸＰＲＯＣＥＳＳならばＳ４２
３に移り、一定時間休止（ｓｌｅｅｐ）する（たとえば
１０秒）。これは、先に走行しているキャッシュ更新子
プロセスの処理を終了するのを待つために行なわれる
（Ｓ４２３）。

【０２０８】 次に、指定の終了時刻になったかどうか
の判定を行なう。指定時刻を過ぎていれば、キャッシュ
更新プロセスは処理を終了する。指定時刻を過ぎていな
ければ、Ｓ４２１以下の処理を繰返す（Ｓ４２４）。

【０２０９】 また、Ｓ４２３でｐｒｏｃｅｓｓｅｓ＜
ＭＡＸＰＲＯＣＥＳＳならば、第２のｐｒｏｘｙプロセ
ス３４にアクセス要求を出力することによって、第２の
ｐｒｏｘｙプロセス３４はキャッシュ更新子プロセスを
バックグラウンドプロセスとして１つ起動する（Ｓ４２
５）。ＵＮＩＸ（Ｒ） ＯＳにおいて、プロセスをバッ
クグラウンドで実行させるには、コマンドラインに＆の
記号を付けて起動すればよい。文字列バッファＵＲＬＢ
ＵＦには、Ｓ２により取得されたファイルオブジェクト
名称が格納されているので、数２０に示すコマンドを実
行すれば、キャッシュ更新子プロセスがバックグラウン
ドプロセスとして実施される。

【０２１０】

【数式２０】

【０２１１】 最後に、指定の終了時刻になったかどう
かを判定し、指定時刻をすぎていればキャッシュ更新プ
ロセスは処理を終了し、指定の終了時刻を過ぎていなけ
ればＳ１以下の処理を繰返す（Ｓ４２６）。

【０２１２】 以上のような処理により、ＭＡＸＰＲＯ
ＣＥＳＳ以下のプロセスで同時並列実行が可能になる。

【０２１３】 この実施形態２により、キャッシュ更新
処理速度を速め、常にキャッシュ更新処理を待つ状態に
することでキャッシュ更新処理の遅滞の拡大を防止する
ことが可能となる。なお、パターンファイル３０を用意
して、特定ファイルオブジェクトだけを更新対象にして
いるＳ２の処理も効果を上げている。

【０２１４】 以上説明したように、実施の形態２で
は、キャッシュ更新処理を同時に行なうことで、キャッ
シュ更新の開始から終了までが短縮されるので、第１の
ｐｒｏｘｙプロセス１４によるユーザからのアクセス処
理の頻度に追随してキャッシュ更新処理を進めることが
可能となる。

【０２１５】 ［実施の形態３］ 実施の形態３においては、実施の形態２と同様に、キャ
ッシュ更新子プロセスの並列実行を行なうが、さらにプ
ロセスの制御を行なうことにより、内部ネットワーク２
３のクライアント計算機２４を使用するユーザが第１の
ｐｒｏｘｙプロセス１４を使用して外部ネットワーク２
５のサーバ計算機１１に頻繁にアクセスしている時間帯
に、キャッシュ更新プロセス３６を実行しても、キャッ
シュ更新子プロセスの数が抑制される。すなわち、キャ
ッシュ更新子プロセスには低い優先権が与えられること
で、クライアント計算機２４を使用するユーザのネット
ワーク利用を妨げないようにしたものである。

【０２１６】 また、第１のｐｒｏｘｙプロセス１４を
利用するユーザのネットワークアクセスは、通常１つの
ページが複数のファイルオブジェクトから構成されてい
るため（たとえば、図２に示す情報ページ）、１つのペ
ージのアクセスにおいては、複数のファイルオブジェク
トのアクセスが時間的に連続して発生する。したがっ
て、キャッシュ更新アクセスの子プロセスの起動におい
て、休止時間を設けて子プロセス起動を遅延させること
により、ユーザのページアクセスが終了してからキャッ
シュ更新アクセスが起きる確率を高めることができる。

【０２１７】 また、同一のファイルオブジェクトに対
するキャッシュ更新アクセスの条件が揃ったとき、すな
わち、実施形態１および２のＵＲＬＢＵＦが空でないと
き（図３および図４のＳ３がｙｅｓの場合）一定時間の
無効時間を設け、前回キャッシュが更新されてから所定
時間以内であればサーバ計算機１１に対するキャッシュ
更新アクセスを行なわないことで、クライアント計算機
２４が頻繁にファイルオブジェクトアクセスを行なって
いるときに、キャッシュ更新アクセスでサーバ計算機１
１に対するアクセスが頻繁に発生することを防止するも
のである。

【０２１８】 この処理の簡単な実現方法として、第２
のｐｒｏｘｙプロセス３４のキャッシュ有効期限を０で
はなく、無効時間を設定して起動すればよい。この無効
時間として、３０分または１時間等とし、サーバ計算機
１１の変更頻度の平均の最小時間程度にすればよい。こ
れにより、無効時間以内に実施形態１、２または３の方
式でキャッシュ更新アクセスを行なっても、キャッシュ
にヒットすることになるのでサーバ計算機１１にアクセ
スが発生しなくなる。

【０２１９】 図６は、実施の形態３の処理を示すフロ
ーチャートである。図６は、実施形態２の処理を示すフ
ローチャートである図５のＳ４２１とＳ４２５をＳ４３
１とＳ４３５に置き換えたものである。

【０２２０】 図６に示す処理を行なうに先立って、最
大ネットワーク接続個数ＭＡＸＰＲＯＣＥＳＳという定
数を定める。この定数は、キャッシュ更新子プロセスの
数と第１のｐｒｏｘｙプロセス１４がネットワークアク
セスの中継のために起動した子プロセスの数を加算した
値の最大を示す定数である。したがって、ｐｒｏｘｙサ
ーバ装置５３は、なるべくのＭＡＸＰＲＯＣＥＳＳ以下
にサーバ計算機１１へのネットワークアクセスを制限し
ようとする。図６のＳ１〜Ｓ３の処理は、実施形態１、
２と同様であるのでここでの説明は繰返さない。

【０２２１】 バックグラウンドで走行しているキャッ
シュ更新子プロセスの数と、第１のｐｒｏｘｙプロセス
１４のネットワークアクセス中継子プロセスの数を求め
て加算してｐｒｏｃｅｓｓｅｓ変数（数２１）とする
（Ｓ４３１）。

【０２２２】

【数式２１】

【０２２３】 ｐｒｏｃｅｓｓｅｓ変数と指定された最
大子プロセスＭＡＸＰＲＯＣＥＳＳを比較し、ｐｒｏｃ
ｅｓｓｅｓ≧ＭＡＸＰＲＯＣＥＳＳならばＳ４３３へ移
り、一定時間休止（ｓｌｅｅｐ）する（たとえば１０
秒）。これは、先に起動されたキャッシュ更新子プロセ
ス数の処理が終了するのを待つものである。

【０２２４】 次に、指定の終了時刻になったか否かを
判定し、指定時刻を過ぎていればキャッシュ更新プロセ
スは処理を終了する。指定の終了時刻になっていなけれ
ば、Ｓ４３１に戻って処理を続行する（Ｓ４３４）。ま
た、Ｓ４３２でｐｒｏｃｅｓｓｅｓ＜ＭＡＸＰＲＯＣＥ
ＳＳならば、抽出したファイルオブジェクト名称（ＵＲ
ＬＢＵＦに格納されたもの）をもとに、第２のｐｒｏｘ
ｙプロセス３６を用いてアクセスするキャッシュ更新子
プロセスをバックグラウンドプロセスとして１つ起動す
る。

【０２２５】 このとき、子プロセスは数２２に示すよ
うに、休止時間をＤＥＬＡＹＴＩＭＥ変数（単位は秒）
としてＯＳの休止機能をｓｌｅｅｐを使ってＤＥＬＡＹ
ＴＩＭＥ秒間休止してからキャッシュ更新アクセスを行
なうようにする。１ページＷＷＷデータは、図２に示す
ように複数の画像ファイルオブジェクトからなる場合、
キャッシュヒット時は１０秒以下でｐｒｏｘｙサーバ装
置５３からクライアント計算機２４に転送可能であるこ
とが経験的に知られているので、ＤＥＬＡＹＴＩＭＥは
１０秒程度としている。

【０２２６】

【数式２２】

【０２２７】 最後に、指定の終了時刻になったかどう
かを判定し、指定時刻を過ぎていればキャッシュ更新プ
ロセスは処理を終了し、指定終了時刻を過ぎていなけれ
ば、Ｓ１へ戻り処理を繰返す（Ｓ４３６）。

【０２２８】 以上のように、キャッシュ更新子プロセ
スの個数と第１のｐｒｏｘｙプロセス１４を利用してい
るユーザのネットワークアクセスの中継子プロセス数の
合計を制限しながらキャッシュ更新子プロセスを制御す
る。この結果、第１のｐｒｏｘｙプロセス１４を利用し
ているユーザによるネットワークアクセスの数が増える
と、キャッシュ更新子プロセスは起動されにくくなる。
したがって、ユーザが第１のｐｒｏｘｙプロセス１４を
利用している時間帯に、キャッシュ更新プロセス３６を
実行しても、キャッシュ更新子プロセスには低い優先権
が与えられることで、ユーザのネットワーク活動を妨げ
ないようにすることができる。

【０２２９】 また、ユーザのファイルオブジェクトに
対するアクセスがキャッシュにヒットした場合は、通常
１ページの転送は、数秒以内に終了するが、キャッシュ
更新子プロセスはＤＥＬＡＹＴＩＭＥ（秒）遅延してか
ら起動されるので、ＤＥＬＡＹＴＩＭＥを１０秒程度に
設定すればユーザのファイルオブジェクトアクセスとキ
ャッシュ更新アクセスは時間的にずれて実施される（す
なわちパイプライン）ので、ｐｒｏｘｙサーバ計算機５
３への負担を減らし、ユーザに快適なネットワーク利用
を提供することが可能となる。

【０２３０】 以上説明したように、実施の形態３では
ユーザが第１のｐｒｏｘｙプロセス１４を利用している
時間帯に、キャッシュ更新プロセス３６を実行しても、
キャッシュ更新子プロセスには低い優先権が与えられる
ことで、ユーザのネットワーク利用を妨げない効果があ
る。また、遅延時間を導入することで、キャッシュ更新
処理はユーザの連続したファイルオブジェクト転送処理
が終了してから行なわれるので、ｐｒｏｘｙサーバ計算
機５３の処理負担を軽減し、ユーザへのファイルオブジ
ェクト転送を最優先できる。また、無効時間が設定され
るため、クライアント計算機２４が無効時間以内に同一
ファイルオブジェクトに対してアクセスを行ない、キャ
ッシュ更新アクセスの条件が揃ってもキャッシュ更新ア
クセスはキャッシュにヒットすることになり、実質的に
サーバ計算機１１に対するアクセスが発生しない。これ
により、クライアント計算機２４が同一ファイルオブジ
ェクトを頻繁にアクセスしても、時間のかかるサーバ計
算機１１へのキャッシュ更新アクセスが抑制されるので
サーバ計算機１１への負担の軽減とキャッシュ更新処理
の効率化が図れる。

【０２３１】 ［実施の形態４］ 実施の形態１〜３は、ｐｒｏｘｙサーバ計算機に関する
ものであったが、実施の形態４ではファイルオブジェク
トの中継制御のみを行なうゲートウェイ装置（ｒｅｄｉ
ｒｅｃｔｏｒ計算機）について説明する。図８は、キャ
ッシュサーバ計算機（ｐｒｏｘｙサーバ計算機）６５〜
６７およびｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７をロ
ーカルネットワーク７１で接続する構成を示す図であ
る。

【０２３２】 ｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７
は、ｐｒｏｘｙサーバ計算機の１種でもあるが、実施の
形態４のｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７は、ｐ
ｒｏｘｙサーバ計算機６５〜６７への中継のみを行ない
キャッシュは行なわない。

【０２３３】 以下、ｒｅｄｉｒｅｃｔｏｒ計算機７２
〜７７の動作について詳細に説明する。

【０２３４】 ｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７
は、複数のｐｒｏｘｙサーバ計算機６５〜６７とクライ
アント計算機群との間に介在し、ｐｒｏｘｙサーバ計算
機６５〜６７とはローカルネットワーク７１で接続さ
れ、クライアント計算機群とはローカルネットワーク７
８で接続される。また、ファイルオブジェクトを提供す
るサーバ計算機１１とｐｒｏｘｙサーバ計算機６５〜６
７とは、広域ネットワーク６１で接続される。

【０２３５】 まず、クライアント計算機２４からのフ
ァイルオブジェクトに対する読出要求をローカルネット
ワーク７８を介してｒｅｄｉｒｅｃｔｏｒ計算機７３内
のｒｅｄｉｒｅｃｔｏｒプロセスが受信する。ｒｅｄｉ
ｒｅｃｔｏｒ計算機は、上述した図１７〜１９に示すワ
ークステーション２００〜４００で実現可能である。す
なわち、ｒｅｄｉｒｅｃｔｏｒプロセスに相当するプロ
グラムをメモリ２０６内に格納し、そのプログラムをＣ
ＰＵ２０２が実行することによってこのｒｅｄｉｒｅｃ
ｔｏｒ計算機の機能が実現される。ｒｅｄｉｒｅｃｔｏ
ｒプロセスは、受信した読出要求の内容に基づいてハッ
シュ関数の計算を行ないその計算結果に従って中継する
ｐｒｏｘｙサーバ計算機６５〜６７を選択する。そして
ｒｅｄｉｒｅｃｔｏｒプロセスは、読出要求を選択され
たｐｒｏｘｙサーバ計算機６５〜６７内のｐｒｏｘｙプ
ロセスに中継する。

【０２３６】 本発明を非常に有効に適用できる例とし
て、前述したインターネット上のＷＷＷシステムがあ
る。図９は、ＷＷＷシステム上でのｒｅｄｉｒｅｃｔｏ
ｒ計算機の処理手順を示すフローチャートである。

【０２３７】 ＷＷＷシステムではネットワーク上に分
散したファイルオブジェクト名称はUniform Resource L
ocator（ＵＲＬ）と呼ばれる形式で表現され特定され
る。

【０２３８】 たとえば、ｒｅｄｉｒｅｃｔｏｒ計算機
７３が、クライアント計算機２４からの読出要求を受信
したとすると、ｒｅｄｉｒｅｃｔｏｒ計算機７３は要求
に含まれるＵＲＬを取出す（Ｓ３１）。取出されたＵＲ
Ｌに基づいてハッシュ関数による計算を行なう。ここ
で、ハッシュ関数にはさまざまなものが考えられるが、
実施の形態４ではＵＲＬ形式で表現されたファイルオブ
ジェクト名称に含まれる文字の文字コードをすべて加算
し、ｐｒｏｘｙサーバ計算機６５から６７の台数で割っ
た剰余を使用した（Ｓ３３）。

【０２３９】 このハッシュ関数によって算出された値
によって、読出要求を中継するｐｒｏｘｙサーバ計算機
６５〜６７の番号を決定する（Ｓ３４）。そして、選択
されたｐｒｏｘｙサーバ計算機６５〜６７に読出要求が
中継される（Ｓ３５）。

【０２４０】 同一のファイルオブジェクトの読出要求
は、すべて同一のｐｒｏｘｙサーバ計算機６５〜６７で
中継されることが、キャッシュの有効利用の観点からは
望ましい。なぜなら、同一のファイルオブジェクトを異
なるｐｒｏｘｙサーバ計算機で重複して保持すると、キ
ャッシュ容量が減少し、キャッシュファイルの有効利用
が図れなくなるからである。そのためには、ハッシュ関
数がすべてのｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７内
のｒｅｄｉｒｅｃｔｏｒプロセスで同一のものである必
要がある。

【０２４１】 上述したハッシュ関数は、各ｐｒｏｘｙ
サーバ計算機６５〜６７が均等に選択されるため、それ
ぞれのｐｒｏｘｙサーバ計算機６５〜６７に対する負荷
は均等になるが、適切にハッシュ関数を選ぶことによ
り、各ｐｒｏｘｙサーバ計算機６５〜６７の能力に応じ
て意図的に均等でなく負荷を分散することも容易に実現
できる。すなわち、処理能力の高いｐｒｏｘｙサーバ計
算機に対しては、選択される可能性を高くし、処理能力
の低いｐｒｏｘｙサーバ計算機に対しては、選択される
可能性を低くすることによって各ｐｒｏｘｙサーバ計算
機の処理速度を均等にするものである。

【０２４２】 このようにして算出された番号により示
されるｐｒｏｘｙサーバ計算機が、選択されたｐｒｏｘ
ｙサーバ計算機となり、ｒｅｄｉｒｅｃｔｏｒプロセス
は選択されたｐｒｏｘｙサーバ計算機内のｐｒｏｘｙプ
ロセスにクライアント計算機２４からの読出要求を中継
する。ｐｒｏｘｙサーバ計算機６５〜６７内のｐｒｏｘ
ｙプロセスは、ｒｅｄｉｒｅｃｔｏｒ計算機７３内のｒ
ｅｄｉｒｅｃｔｏｒプロセスにより中継されたクライア
ント計算機２４からの読出要求を広域ネットワーク６１
を介してサーバ計算機１１に中継し、転送されたファイ
ルオブジェクトをキャッシュする。

【０２４３】 ｒｅｄｉｒｅｃｔｏｒプロセスは、広く
一般に利用されているＤｅｌｅＧａｔｅを利用して実施
することが可能である。実施の形態４のｒｅｄｉｒｅｃ
ｔｏｒプロセスは、ＤｅｌｅＧａｔｅの中継記法とフィ
ルタ機能を利用して実現されている。以下に、中継記法
の例を示す。

【０２４４】

【数式２３】

【０２４５】 数２３の記述のうち、最初のｈｔｔｐは
使用するプロトコル名を示し、ｐｒｏｘｙｓｅｒｖｅｒ
はネットワーク上のｐｒｏｘｙサーバ計算機のアドレス
を示すものである。また、１００８０はＴＣＰ／ＩＰ接
続のポート番号と呼ばれ、ｐｒｏｘｙサーバ計算機上の
どのプロセスに対し読出要求を送るのかを示す。−＿−
は、これがＤｅｌｅＧａｔｅの中継記法であることを示
す。残りのｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏ．ｊｐ
／ｔｅｓｔ／ｉｎｄｅｘ．ｈｔｍｌが、本来の読出要求
のＵＲＬである。

【０２４６】 ＤｅｌｅＧａｔｅが上記読出要求を受信
すると、ｐｒｏｘｙサーバ計算機ｐｒｏｘｙｓｅｒｖｅ
ｒのポート番号１００８０で示されるｐｒｏｘｙプロセ
スに対し、ＵＲＬで示されるファイルオブジェクトの読
出要求を中継する。すなわち、読出要求の中で、中継す
るｐｒｏｘｙサーバ計算機を指定することが可能であ
る。

【０２４７】 フィルタ機能は、外部プログラムを利用
してＤｅｌｅＧａｔｅ機能を拡張するための仕組みであ
る。ＤｅｌｅＧａｔｅはクライアント計算機もしくは他
のｐｒｏｘｙサーバ計算機からの読出要求を受信する
と、受信した読出要求を一旦外部プログラムに引渡し、
この外部プログラムによって処理された読出要求を再び
受取って中継等の処理を行なうことが可能である。

【０２４８】 図１１は、ｒｅｄｉｒｅｃｔｏｒ計算機
の内部構成を示す図である。実施の形態４において、Ｄ
ｅｌｅＧａｔｅによって実現されるｒｅｄｉｒｅｃｔｏ
ｒプロセス８１が、たとえば、数２４に示すＵＲＬを含
む読出要求を受信したとする。

【０２４９】

【数式２４】

【０２５０】 これは、ｗｗｗ．ｘｘｘ．ｃｏ．ｊｐで
表わされるサーバ計算機１１にこの読出要求を送信する
ことを示している。

【０２５１】 しかし、実施の形態４ではＤｅｌｅＧａ
ｔｅのフィルタ機能により、外部プログラムとして実現
されたｐｒｏｘｙ切換制御部８２においてＵＲＬをもと
にハッシュ関数の計算を行ない（図９のＳ３２〜Ｓ３
３）、その演算結果によってｐｒｏｘｙサーバ計算機ｐ
ｒｏｘｙｓｅｒｖｅｒ１が選択されたとすると、上記読
出要求内のＵＲＬを数２５のように書替える（図９のＳ
３４）。

【０２５２】

【数式２５】

【０２５３】 外部プログラムであるｐｒｏｘｙ切換制
御部８２によって書替えられた読出要求を受取ったｒｅ
ｄｉｒｅｃｔｏｒプロセス８１は、ｐｒｏｘｙｓｅｖｅ
ｒ１で表わされるｐｒｏｘｙサーバ計算機にｗｗｗ．ｘ
ｘｘ．ｃｏ．ｊｐで表わされるサーバ計算機１１に対す
る読出要求を中継する（図９のＳ３５）。

【０２５４】 したがって、ハッシュ関数で計算された
結果に基づいてＵＲＬ中のｐｒｏｘｙサーバ計算機のア
ドレスをｐｒｏｘｙｓｅｒｖｅｒ１に変えることによ
り、元の読出要求のＵＲＬに基づいて中継するｐｒｏｘ
ｙサーバ計算機を選択することができる。実際に、２台
のｐｒｏｘｙサーバ計算機を用意し、ハッシュ関数はＵ
ＲＬに含まれるファイルオブジェクト名称の文字の文字
コードをすべて加算し（図８のＳ３２）、ｐｒｏｘｙサ
ーバ計算機の台数２で割った剰余を使用した（図８のＳ
３３）。すなわち、ハッシュ関数の計算結果が０であっ
た場合ｐｒｏｘｙｓｅｒｖｅｒ０により中継し、１であ
った場合はｐｒｏｘｙｓｅｒｖｅｒ１で中継を行なうも
のとする。

【０２５５】 図１０は、図２に示す同一ページのファ
イルオブジェクトが、２台のｐｒｏｘｙサーバ計算機に
分散されるようすを示したものである。図１０の上段
は、本来の読出要求のＵＲＬ、ファイルオブジェクト名
称の文字コードの総計（ｃｈｅｃｋ ｓｕｍ）、文字コ
ードの総計をｐｒｏｘｙサーバ計算機の台数である２で
割った余りおよび選択されたｐｒｏｘｙサーバ計算機の
アドレスを示している。図１０の下段は、ｐｒｏｘｙ切
換制御部８２で書替られたＵＲＬを示している。この例
では、ハッシュ関数の結果が０の方が多くなっており、
ｐｒｏｘｙｓｅｒｖｅｒ０への中継が多くなってしまう
が、これはサンプル数が少ないことによるものである。
実際の運用では膨大なアクセスが、ハッシュ関数による
分散が確率的に均等になるという性質のもとに、ほぼ２
分の１ずつ均等に分散されることが確認されている。

【０２５６】 以上説明したように、複数あるｐｒｏｘ
ｙサーバ計算機が別々な経路で広域ネットワークに接続
されている場合、クライアント計算機からのアクセス要
求を複数あるｐｒｏｘｙサーバ計算機に分散すること
は、複数ある経路に分散することでもある。したがって
経路の有効利用が可能となり、スループットが向上す
る。ｐｒｏｘｙサーバ計算機の処理能力には限界がある
が、クライアント計算機からのアクセス要求が複数のｐ
ｒｏｘｙサーバ計算機に分散されることにより、ｐｒｏ
ｘｙサーバ計算機１台で処理されるアクセス要求数が減
少し、スループットが向上する。

【０２５７】 また、同一ページ内に複数のファイルオ
ブジェクトが含まれている場合、それらのファイルオブ
ジェクトに対するアクセス要求も複数のｐｒｏｘｙサー
バ計算機によって分散して処理されるので、単一ページ
のアクセス速度も向上する。

【０２５８】 また、どのクライアント計算機からの中
継要求であっても、同一ＵＲＬに対するハッシュ関数が
同じであるので、常に同じｐｒｏｘｙサーバ計算機が選
択されることになり、同一ＵＲＬのアクセスが２回以上
あればキャッシュによるアクセスの高速化が図れる。さ
らに、ハッシュ関数が一意にきまるものであれば任意の
関数が選択できるので、ｐｒｏｘｙサーバ計算機の数も
また任意の台数が使用できる。

【０２５９】 実施の形態４において、ハッシュ関数内
で使われているＵＲＬに含まれる文字の文字コードをす
べて加算した値（ｃｈｅｃｋ ｓｕｍ）は、平均して数
千程度になることが確かめられている。たとえば、シャ
ープ奈良工場における実施においては、１９９６年３月
１３日に実測された３０４８１件のファイルオブジェク
トに対するアクセス要求のＵＲＬに含まれる文字や文字
コードの合計の平均は４４３８（小数点以下四捨五入）
であった。

【０２６０】 前述したとおり、実施の形態４ではこの
アクセス要求のＵＲＬに含まれる文字や文字コードの合
計をｐｒｏｘｙサーバ計算機の台数で割った剰余をハッ
シュ関数として使用し、ｐｒｏｘｙサーバ計算機の選択
に使用している。したがって、図１０の例ではｐｒｏｘ
ｙサーバ計算機は２台であるが、この台数が数千程度で
あっても、ハッシュ関数によるｐｒｏｘｙサーバ計算機
の選択はほぼ均等に行なわれると考えられる。

【０２６１】 また、同一のハッシュ関数であれば、ｒ
ｅｄｉｒｅｃｔｏｒ計算機の数は任意である。したがっ
て、本方式ではスケーラビリティも非常に優れている。

【０２６２】 また、本方式ではキャッシュ付のｐｒｏ
ｘｙサーバ計算機は既存のものをそのまま使用すること
が可能である。したがって、図２４の従来の方式に比べ
導入が容易で経済的である。また、クライアント計算機
に関しても、既存のクライアント計算機を使用して、ｒ
ｅｄｉｒｅｃｔｏｒ計算機を既存のｐｒｏｘｙサーバ計
算機に見立てて設定を行なうだけでよく、特殊なクライ
アント計算機を用意する必要はない。

【０２６３】 ［実施の形態５］ 実施の形態５は、実施の形態４において独立した計算機
上で実行していたｒｅｄｉｒｅｃｔｏｒプロセスを、ク
ライアント計算機２４上で実行する。図１２は、実施の
形態５における装置の内部構成を示す図であり、クライ
アント計算機２４内のクライアントプロセス８４（図８
のクライアント計算機２４と同じ動作をするプロセス）
からの読出要求は、ローカルネットワーク上には送出さ
れず、クライアント計算機２４内部のｒｅｄｉｒｅｃｔ
ｏｒプロセス８５に直接送信される。この送信は、たと
えばＵＮＩＸ（Ｒ）のメッセージ通信によって行なわれ
る。

【０２６４】 ｒｅｄｉｒｅｃｔｏｒプロセス８５がア
クセス要求を受信した後の処理は、上述したｒｅｄｉｒ
ｅｃｔｏｒ計算機７２〜７７内で動作するｒｅｄｉｒｅ
ｃｔｏｒプロセス８１と同様であり、ローカルネットワ
ークを介する他のクライアント計算機からのアクセス要
求を受信して処理することも可能である。したがって、
ここでの詳細な説明は繰返さない。また、このｒｅｄｉ
ｒｅｃｔｏｒプロセス８５の機能をクライアントプロセ
ス８４のプログラムに直接組込むことも可能である。

【０２６５】 図８に示す実施の形態４のクライアント
計算機２４とｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７と
の通信が、実施の形態５では同じクライアント計算機２
４内部で処理されるため、ローカルネットワーク上での
通信量が削減できる。したがって、独立したｒｅｄｉｒ
ｅｃｔｏｒ計算機を用意する必要がなく、クライアント
計算機２４を利用してｒｅｄｉｒｅｃｔｏｒ計算機の機
能を実現できるためコストの削減が可能となる。

【０２６６】 ［実施の形態６］ 実施の形態６では、実施の形態４において独立した計算
機上で実行していたｒｅｄｉｒｅｃｔｏｒプロセスを、
ｐｒｏｘｙサーバ計算機上で実行する。図１３は、実施
の形態６における装置の内部構成を示す図であり、たと
えば、クライアント計算機２４ｂから読出要求があった
場合に、その読出要求はｐｒｏｘｙサーバ計算機９９内
のｒｅｄｉｒｅｃｔｏｒプロセス９１で受信される。そ
の後、ｒｅｄｉｒｅｃｔｏｒプロセス９１は、図９を用
いて説明したようにアクセス要求を中継するｐｒｏｘｙ
サーバ計算機を選択し、その選択されたｐｒｏｘｙサー
バ計算機が９８であれば、ｐｒｏｘｙサーバ計算機９８
のｐｒｏｘｙプロセス８６に対してアクセス要求を中継
する（９２）。また、受信したｒｅｄｉｒｅｃｔｏｒプ
ロセスの動作しているｐｒｏｘｙサーバ計算機と選択さ
れたｐｒｏｘｙサーバ計算機がともに９９である場合、
読出要求の中継はネットワーク上に送出されずｐｒｏｘ
ｙサーバ計算機９９内部で直接行なわれる（９３）。そ
して、ｐｒｏｘｙプロセス（８６または８９）が広域ネ
ットワーク６１を介してサーバ計算機１１に対してアク
セス要求を送出する（６２または６３）。

【０２６７】 同様に、クライアント計算機２４ａから
読出要求があった場合に、その読出要求は、ｐｒｏｘｙ
サーバ計算機９８上のｒｅｄｉｒｅｃｔｏｒプロセス９
６で受信される。その後、ｒｅｄｉｒｅｃｔｏｒプロセ
スは、ｐｒｏｘｙサーバ計算機の選択を行ない、その選
択されたｐｒｏｘｙサーバ計算機が９９であれば、ｐｒ
ｏｘｙサーバ計算機９９のｐｒｏｘｙプロセス８９に対
してアクセス要求を中継する（９５）。

【０２６８】 また、受信したｒｅｄｉｒｅｃｔｏｒプ
ロセスの動作しているｐｒｏｘｙサーバ計算機と選択さ
れたｐｒｏｘｙサーバ計算機がともに９８である場合、
読出要求の中継はネットワーク上に送出されずｐｒｏｘ
ｙサーバ計算機９８内部で直接行なわれる（９６）。そ
して、ｐｒｏｘｙプロセス（８６または８９）が広域ネ
ットワーク６１を介してサーバ計算機１１に対してアク
セス要求を送出する（６２または６３）。

【０２６９】 サーバ計算機１１から取得したファイル
オブジェクトをキャッシュファイル（８７または９０）
に格納する処理は、上述した処理と同様であるので詳細
な説明は繰返さない。

【０２７０】 また、このｒｅｄｉｒｅｃｔｏｒプロセ
スの機能を、ｐｒｏｘｙサーバ計算機上でｐｒｏｘｙサ
ーバとしての機能を実現しているプログラムに直接組込
むことも可能である。

【０２７１】 したがって、ｒｅｄｉｒｅｃｔｏｒ計算
機とｐｒｏｘｙサーバ計算機の通信の一部がｐｒｏｘｙ
サーバ計算機内部で処理されるため、ローカルネットワ
ーク上での通信量が削減できる。また、独立したｒｅｄ
ｉｒｅｃｔｏｒ計算機を用意する必要がなく、ｐｒｏｘ
ｙサーバ計算機を利用してｒｅｄｉｒｅｃｔｏｒ計算機
の機能を実現できるためコストを削減することが可能に
なる。

【０２７２】 ［実施の形態７］ 実施の形態４のｒｅｄｉｒｅｃｔｏｒ計算機７２〜７７
はアクセス要求の中継のみを行なっていた。しかし、図
２３で説明したようなツリー状の構成が有効であるよう
な大規模なローカルネットワークでは、１次キャッシュ
ｐｒｏｘｙサーバ計算機５０３〜５０８の持つキャッシ
ュ機能をｒｅｄｉｒｅｃｔｏｒ計算機に持たせることに
よって、ネットワーク上の通信量およびｐｒｏｘｙサー
バ計算機の負荷を軽減することが可能となる。図１４
は、そのシステム構成を示す図である。ｒｅｄｉｒｅｃ
ｔｏｒサーバ計算機４０〜４５は、図１１に示すｒｅｄ
ｉｒｅｃｔｏｒ計算機８０と図１６に示すｐｒｏｘｙサ
ーバ計算機１３を組合せることにより可能である。すな
わち、図１６のリード要求１７を図１１のｒｅｄｉｒｅ
ｃｔｏｒプロセス８１が受信することによって実現可能
であるので、ここでの詳細な説明は繰返さない。また、
実施の形態５におけるクライアント計算機内部でキャッ
シュを行なうことによっても、ローカルネットワーク上
の通信量の削減とｐｒｏｘｙサーバ計算機の負荷を軽減
することが可能となる。

【０２７３】 上述したように、ｒｅｄｉｒｅｃｔｏｒ
計算機においてキャッシュすることにより、ローカルネ
ットワーク上のでの通信量およびｐｒｏｘｙサーバ計算
機の負荷を軽減することができる。

【０２７４】 ［実施の形態８］ 上述した実施の形態４から７は、排他的に使用されなけ
ればいけないものではない。すなわち、実施の形態８に
おいてはｒｅｄｉｒｅｃｔｏｒ機能を実現するすべての
計算機（ｐｒｏｘｙサーバ計算機、クライアント計算
機、ｒｅｄｉｒｅｃｔｏｒ計算機）において、ｒｅｄｉ
ｒｅｃｔｏｒ機能の使用するハッシュ関数が同一であ
り、すべてのアクセス要求がそれぞれ同一のｐｒｏｘｙ
サーバ計算機等のキャッシュ機能を有する計算機で中継
およびキャッシュされれば、実施の形態４〜７に記載さ
れた各種の計算機は、単一のネットワーク内に混在して
使用されても全く問題はない。したがって、それぞれの
会社等の組織におけるさまざまなネットワークや計算機
の運用事情に応じ、非常に柔軟なネットワーク運用を行
なうことが可能となる。

【０２７５】 ある程度以上の大規模なローカルネット
ワークでは、広域ネットワークとの接続が複数の経路
（図８の６２〜６４）からなる場合もある。そのような
場合、ｐｒｏｘｙサーバ計算機ごとに異なる経路を使用
すると、クライアント計算機からのアクセス要求を複数
ある経路に分散して中継することになる。したがって、
複数ある広域ネットワークとの通信経路を有効利用し、
広域ネットワークとローカルネットワークとの通信のス
ループット向上が図れる。

【０２７６】 実際の運用においては、すべての計算機
の設定を一度に変えることは現実的ではない。移行には
暫く時間がかかることが普通である。より効率のよい運
用を図るためには、すべてのｒｅｄｉｒｅｃｔｏｒ機能
を有する計算機内でハッシュ関数を一致させる必要があ
るため、すべてのクライアント計算機がｒｅｄｉｒｅｃ
ｔｏｒ計算機を利用するようシステムを構築するか、ク
ライアント計算機がｒｅｄｉｒｅｃｔｏｒ機能を持つ必
要がある。しかし、そのようなシステムを構築しなくて
もｒｅｄｉｒｅｃｔｏｒ機能を有する計算機を使用する
ことは可能である。すなわち、本発明の各方式では、従
来のｐｒｏｘｙサーバ計算機やクライアント計算機を全
く手を付けない状態で、システムの一部にｒｅｄｉｒｅ
ｃｔｏｒ機能を持たせて、システム全体はそのまま使用
することも可能である。

【０２７７】 同様に、システムの再構築の際、複数の
ｒｅｄｉｒｅｃｔｏｒ機能におけるハッシュ関数が一致
しない場合もあり得る。このような場合でも、システム
全体の動作自体には影響はないので、通常と同様に利用
が可能である。上述したいずれの場合も利用は可能であ
るが、ｐｒｏｘｙサーバ計算機その他の有効利用の観点
からは望ましい状況とはいえない。したがって、できる
だけ早い時期にすべてのｒｅｄｉｒｅｃｔｏｒ機能を有
する計算機での設定を統一させることが望ましい。しか
し移行期に新旧の設定を混在していても不必要な混乱を
起こさず、スムーズに移行することが可能である。

【０２７８】 なお、ｈｔｔｐプロトコルを含めた参考
文献リストを以下に示す。

【０２７９】

【数式２６】

【０２８０】

【数式２７】

【図面の簡単な説明】

【０２８１】

【図１】本発明におけるゲートウェイ装置の一例である
ｐｒｏｘｙサーバ計算機の動作概念図である。

【図２】ＷＷＷサーバ内の情報ページをクライアント計
算機に読出したときの表示画面を示す図である。

【図３】実施の形態１のゲートウェイ装置であるｐｒｏ
ｘｙサーバ計算機で行なわれるキャッシュ更新プロセス
の処理手順を示すフローチャートである。

【図４】ｐｒｏｘｙプロセスにおけるキャッシュファイ
ル管理の処理手順を示すフローチャートである。

【図５】実施の形態２のゲートウェイ装置であるｐｒｏ
ｘｙサーバ装置で行なわれるキャッシュ更新プロセスの
処理手順を示すフローチャートである。

【図６】実施の形態３のゲートウェイ装置であるｐｒｏ
ｘｙサーバ装置で行なわれるキャッシュ更新プロセスの
処理手順を示すフローチャートである。

【図７】本発明を実施した場合のサーバ計算機とクライ
アント計算機の間で転送されるデータのタイムチャート
である。

【図８】実施の形態４における分散ファイルシステムの
全体構成を示す図である。

【図９】実施の形態４におけるｒｅｄｉｒｅｃｔｏｒ計
算機の処理手順を示すフローチャートである。

【図１０】図２に示す同一ページのファイルオブジェク
トに対するアクセス要求が２台のサーバ計算機に分散さ
れるようすを示す図である。

【図１１】実施の形態４におけるｒｅｄｉｒｅｃｔｏｒ
計算機の内部構成を示す図である。

【図１２】実施の形態５におけるクライアント計算機の
内部構成を示す図である。

【図１３】実施の形態６におけるｐｒｏｘｙサーバ計算
機の内部構成を示す図である。

【図１４】実施の形態７における分散ファイルシステム
の全体構成を示す図である。

【図１５】従来のゲートウェイ計算機の構成を示す図で
ある。

【図１６】ｐｒｏｘｙサーバ装置の概念図である。

【図１７】ｐｒｏｘｙサーバ装置の回路構成の第１の例
を示す図である。

【図１８】ｐｒｏｘｙサーバ装置の回路構成の第２の例
を示す図である。

【図１９】ｐｒｏｘｙサーバ装置の回路構成の第３の例
であって、本願発明の実施の形態でｐｒｏｘｙサーバ装
置としても使用されるｐｒｏｘｙサーバ装置の回路構成
を示す図である。

【図２０】キャッシュヒット率と平均アクセス速度との
関係を示すグラフである。

【図２１】キャッシュファイルサイズとキャッシュヒッ
ト率との関係を示すグラフである。

【図２２】キャッシュ有効期限とキャッシュファイルの
大きさとの関係を示すグラフである。

【図２３】従来の分散ファイルシステムの全体構成の第
１の例を示す図である。

【図２４】従来の分散ファイルシステムの全体構成の第
２の例を示す図である。

【図２５】従来の分散ファイルシステムの全体構成の第
３の例を示す図である。

【図２６】従来の分散ファイルシステムにおけるサーバ
計算機内のデータの更新とクライアント計算機が読出し
たデータとの関係を示すタイムチャートである。

【符号の説明】

【０２８２】 １１ サーバ計算機、１４ 第１のｐｒ
ｏｘｙプロセス、１５ アクセスログ、１６ キャッシ
ュファイル、３０ パターンファイル、３４ 第２のｐ
ｒｏｘｙプロセス、３５ ＦＩＦＯバッファ、３６ キ
ャッシュ更新プロセス、７２〜７７ ｒｅｄｉｒｅｃｔ
ｏｒ計算機。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平３−263940（ＪＰ，Ａ) 特開 平８−55072（ＪＰ，Ａ) Ｓｕｐｅｒ Ｐｒｏｘｙ Ｓｃｒｉｐ ｔ− ＵＲＬハッシュ式分散Ｐｒｏｘｙ キャッシュ，日本，シャープ株式会社, 1996年 ８月 ９日，ＵＲＬ，ｈｔｔ ｐ：／／ｎａｒａｇｗ．ｓｈａｒｐ．ｃ ｏ．ｊｐ／ｓｐｓ／ｉｎｄｅｘｊ．ｈｔ ｍｌ (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 546 G06F 13/00 540 G06F 17/00 H04L

Claims (9)

(57)【特許請求の範囲】
1. 【請求項１】 クライアント計算機と、前記クライアン
   ト計算機からの情報提供要求に応じて情報を提供するサ
   ーバ計算機と、前記サーバ計算機のファイルオブジェク
   トを制御するゲートウェイ装置と、前記クライアント計
   算機からの情報提供要求に基づくファイルオブジェクト
   の転送を中継するｐｒｏｘｙサーバ計算機とからなるシ
   ステムにおけるゲートウェイ装置であって、 前記情報提供要求に含まれる文字列とシステム内のｐｒ
   ｏｘｙサーバ計算機の数とを用いた所定の演算による演
   算結果に基づいて、要求した情報を格納するｐｒｏｘｙ
   サーバ計算機を決めることで、ｐｒｏｘｙサーバ計算機
   毎に格納される情報量を分散させる制御をすることを特
   徴とするゲートウェイ装置。
2. 【請求項２】 前記所定の演算が、情報提供要求に含ま
   れるＵＲＬ文字列の文字コードを加算してシステム内の
   ｐｒｏｘｙサーバ計算機の数で割った剰余を用いたハッ
   シュ演算であることを特徴とする請求項１記載のゲート
   ウェイ装置。
3. 【請求項３】 前記所定の演算は、システム内の他のゲ
   ートウェイ装置と同じ計算式を用い、同一の情報提供要
   求による演算結果は同一のｐｒｏｘｙサーバ計算機を決
   定することを特徴とする請求項１または２記載のゲート
   ウェイ装置。
4. 【請求項４】 クライアント計算機と、前記クライアン
   ト計算機からの情報提供要求に応じて情報を提供するサ
   ーバ計算機と、前記サーバ計算機のファイルオブジェク
   トの制御と前記クライアント計算機からの情報提供要求
   に基づくファイルオブジェクトの転送の中継とを行なう
   ｐｒｏｘｙサーバ計算機とからなるシステムにおけるｐ
   ｒｏｘｙサーバ計算機であって、 前記情報提供要求に含まれる文字列とシステム内のｐｒ
   ｏｘｙサーバ計算機の数とを用いた所定の演算による演
   算結果に基づいて、要求した情報を格納するｐｒｏｘｙ
   サーバ計算機を自機を含めて決めることで、ｐｒｏｘｙ
   サーバ計算機毎に格納される情報量を分散させる制御を
   することを特徴とするｐｒｏｘｙサーバ計算機。
5. 【請求項５】 前記所定の演算が、情報提供要求に含ま
   れるＵＲＬ文字列の文字コードを加算してシステム内の
   ｐｒｏｘｙサーバ計算機の数で割った剰余を用いたハッ
   シュ演算であることを特徴とする請求項４記載のｐｒｏ
   ｘｙサーバ計算機。
6. 【請求項６】 前記所定の演算は、システム内の他のｐ
   ｒｏｘｙサーバ計算機と同じ計算式を用い、同一の情報
   提供要求による演算結果は同一のｐｒｏｘｙサーバ計算
   機を決定することを特徴とする請求項４または５記載の
   ｐｒｏｘｙサーバ計算機。
7. 【請求項７】 クライアント計算機と、前記クライアン
   ト計算機からの情報提供要求に応じて情報を提供するサ
   ーバ計算機と、前記クライアント計算機からの情報提供
   要求に基づくファイルオブジェクトの転送を中継するｐ
   ｒｏｘｙサーバ計算機とからなるシステムにおけるクラ
   イアント計算機であって、 前記情報提供要求に含まれる文字列とシステム内のｐｒ
   ｏｘｙサーバ計算機の数とを用いた所定の演算による演
   算結果に基づいて、要求した情報を格納するｐｒｏｘｙ
   サーバ計算機を決めることで、ｐｒｏｘｙサーバ計算機
   毎に格納される情報量を分散させる制御をすることを特
   徴とするクライアント計算機。
8. 【請求項８】 前記所定の演算が、情報提供要求に含ま
   れるＵＲＬ文字列の文字コードを加算してシステム内の
   ｐｒｏｘｙサーバ計算機の数で割った剰余を用いたハッ
   シュ演算であることを特徴とする請求項７記載のクライ
   アント計算機。
9. 【請求項９】 前記所定の演算は、システム内の他のク
   ライアント計算機と同じ計算式を用い、同一の情報提供
   要求による演算結果は同一のｐｒｏｘｙサーバ計算機を
   決定することを特徴とする請求項７または８記載のクラ
   イアント計算機。