JP2001526814A

JP2001526814A - 分散型キャッシュ、プリフェッチ、複写の方法およびそのシステム

Info

Publication number: JP2001526814A
Application number: JP55045898A
Authority: JP
Inventors: ミルダット・スライマン・エー; ヘッダヤ・アブデルサラム・エー; イェーテス・ディビッド・ジェー
Original assignee: トラスティーズ・オブ・ボストン・ユニバーシティ
Priority date: 1997-05-22
Filing date: 1998-05-15
Publication date: 2001-12-18
Also published as: US6167438A; WO1998053410A2; AU737742B2; AU7388498A; CN1260890A; WO1998053410A3; EP0983558A2; CA2290786A1; NZ501380A; ZA984298B

Abstract

(57)【要約】特定ドキュメントに対する要求メッセージが、ルーチンググラフを形成する、クライアントからホームサーバへのパスに沿って、ネットワーク内で自動的、透過的、分散的、・拡大縮小可能および強固なキャッシュ、プリフェッチ、複写をする技術。クライアント要求メッセージは、キャッシュの無い場合は、このルーチンググラフをホームサーバ方向にさかのぼる。しかし、キャッシュサーバがルートに沿って設置されており、サービスが可能であれば、要求をインタセプトする。このような方法で、標準的なプロトコルから逸脱することなく、要求をサービスするために、キャッシュサーバは組み合わされたルータ内にパケットフィルタを装着できる必要があり、またクライアントの見地からホームサーバを代理する必要がある。複数のキャッシュサーバは、ローカル負荷、近接キャシュの負荷、接続された通信パスの負荷、およびドキュメント人気度に基づいて、ドキュメントをキャッシュおよび廃棄することで、クライアント要求をサービスするために協力する。キャッシュサーバは、また、セキュリティ対策およびドキュメント変換機能を実装する。

Description

【発明の詳細な説明】分散型キャッシュ、プリフェッチ、複写の方法およびそのシステム発明の背景インターネット、私用イントラネット、エクストラネット、仮想専用ネットワークのようなコンピュータネットワークは、情報の記憶や再生、通信、電子商取引、エンターテイメントおよびその他の用途を含むさまざまな分野に、ますます多く使用されるようになってきている。これらのネットワークでは、サーバとして知られる特定のコンピュータが情報の記憶と供給のために使用されている。ホストまたはホームサーバとして知られるサーバの一種は、本明細書で「ドキュメント」と称するものを除いて、各種コンピュータファイルフォーマットで保存されたデータやプログラムのような情報にアクセスできる機能を備えている。インターネットでは、ドキュメントは通常、基本的にテキストとグラフィックスから構成されているのに対して、各ドキュメントは、実際には、テキスト、テーブル、グラフィックイメージ、サウンド、動画、アニメーション、コンピュータプログラムコードおよび／またはその他の多くのデジタル化された情報を有する各種の情報を収容するデータ構造を含む高度にフォーマットされたコンピュータファイルである。ネットワークにおいてクライアントとして知られるその他のコンピュータでは、ユーザがホームサーバに対して、ネットワークを介してコピーをクライアントに送るように要求することにより、ドキュメントにアクセスできる。クライアントがホームサーバから情報を得るために、通常、各ドキュメントは参照できるアドレスを有している。たとえば、インターネットのコンテキストおよびＨＴＴＰ（ハイパーテキスト転送プロトコル(Hyper Text Transfer Protocol)）として知られる通信プロトコル内において、通常アドレスは、ＵＲＬ(Uniform Resource Locator)として知られる文字数字の列であり、（a）ホームサーバから情報を取得するために、名前または数字アドレスの形式でホームサーバのアドレスを指定し、さらに、（b）クライアントによって要求された情報を識別するローカル情報テキスト列（ファイル名、検索要求またはその他の識別情報）を指定する。ユーザがクライアントコンピュータに対してＵＲＬを指定すると、ＵＲＬのアドレス部分は、ネットワークを介してＤＮＳ(ドメイン名サービス(Domain Name Service))のようなネーミングサービスに送信されて、適正なホームサーバとの接続を確立する方法の命令を取得する。サーバとの接続が確立すると、ローカル情報テキスト列をネットワークを介して直接ホームサーバに送ることにより、クライアントは所望するドキュメントを再生できる。その際、サーバはローカルディスクまたはメモリ記憶からドキュメントを再生して、ネットワークを介してクライアントに伝送する。その後、ホームサーバとクライアント間のネットワーク接続は終了する。コンピュータおよびネットワーク産業のアナリストや専門家は、現在では、インターネット上の通信量が過大になってきているために、インターネットを使用可能にするための方法が本質的に変わる可能性があることを危惧している。特に、個人の多くは現在、インターネットが耐えられないほどに遅く、もはや現状に適合した情報交換のための信頼できる実体ではないと考えている。現在のボトルネックは、疑いもなく、ユーザ数のほかに、マルチメディアファイルのような複雑なドキュメントの送信数が、指数関数的に増加していることによる。解決手段は、単に、サーバとクライアント間の物理的接続に対してさらに帯域幅を追加することに見えるかもしれない。しかし、これは、家庭内や世界中の地域に、同軸ケーブルや光ファイバケーブルおよび組み合わせられたモデム等のような広帯域幅の相互接続用ハードウェアを設置する費用を負担してはじめて実現できる。さらに、帯域幅を追加しても、性能を改善するという保証はない。特に、ビデオエンターテイメント用のような大容量のマルチメディアファイルが、共通電子メールのようなさらに優先度の高い種類のデータに置き換わる可能性がある。残念ながら、帯域幅配分方式を、既存のネットワーク通信プロトコルを変更せずに実現することは困難である。インターネットで使用されている通信技術はＴＣＰ／ＩＰと呼ばれ、単純で明快なプロトコルであり、アップル社のマッキントッシュ（Macintosh）やＩＢＭ互換のＰＣ、ＵＮＩＸワークステーションのような異なる種類の多くのコンピュータでデータを共有して実行できる。ＴＣＰ／ＩＰプロトコルをアドレスがパケット内容の情報を含むことができるように拡張するという大がかりな提案があるが、これらの提案は技術的に複雑で、かつ膨大なコンピュータネットワークの使用者間の協調を必要とする。このように、既存のＴＣＰ／ＩＰプロトコルに変更を加えることを期待するのは非現実的である。取られた対策は、インターネットの急速に成長している用途が、サーバ容量および通信メディアの帯域幅容量を上回り続けることを認識することであった。これらの方法は、基本的なクライアント／サーバ方式（クライアントが直接ホームサーバに接続されている）が、特に１台の一ホームサーバから複数のクライアントに情報を広く分配する必要のある場合には資源を浪費することを前提に始まっている。実際に、予期しない要求を受けて対処できないために、インターネットサーバが簡単に故障した例は多い。ホームサーバに対する要求を軽減するために、大容量の中央ドキュメントキャッシュが使用される。キャッシュは、多くのクライアントから特定のホームサーバに対して、同一ドキュメントを繰り返し要求する無駄を減少させる。類似の要求をインタセプト（横取り）することにより、キャッシュは、複数のクライアントに対して同一ドキュメントのコピーを提供するの用いられる。クライアント側から見ると、キャッシュとの相互作用は、通常ユーザには意識されない方法で行われる。しかし、ネットワークメッセージの観点からは、僅かに異なるものである。その差異は、ホームサーバ接続に必要な情報を索引するために、ドメイン名サービス（ＤＮＳ）に対して要求のアドレス部分が提供されるときに、ＤＮＳが実際の本来のホームサーバに代わってキャッシュのアドレスを返送するようにプログラムされていることである。反対に、サーバノードは、クライアントに対して代理として動作し、キャッシュコピーを検索するための探査メッセージを送出する。ネットワーク内の特定ノードにおいてキャッシュコピーがいったん発見されると、要求がそのノードに転送される。たとえば、全米科学財団（National Science Foundation）の援助で、米国内のさまざまな場所にドキュメントキャッシュが設置された結果、海洋横断ネットワーク接続におけるボトルネックは解消された。一般に、西海岸に設置されたこれらのキャッシュのあるものは、アジア-太平洋および南米諸国からのドキュメント要求を処理しており、東海岸に設置されたものはヨーロッパからのドキュメント要求を処理している。これらの全国的なキャッシュのその他のものは、米国全体に設置された公共的ドキュメントの要求を処理している。しかし、このようなキャッシュ技術は、必ずしもまたは一般的にもドキュメント要求負荷の最適な分配を達成していない。特に、キャッシュが最も効率的であるためには、ＤＮＳネームサービスまたはその他のメッセージルーチング機構（経路選択機構）が、予測される人気が高いドキュメントに対する要求を適正にインタセプト（横取り）するように修正される必要がある。このようにキャッシュコピーを導入すると、一時的なコピーを置く必要があるため、ネーム解決の通信オーバーヘッドが増加する。ネームサービスは、これらのコピーを実在するように登録し、ドキュメントに対する要求を配布するために情報を広め、適時削除されたキャッシュコピーを記録から確実に除去する必要がある。しばしば、手動操作によって、キャシュの検索順を調整し、さらに／またはドキュメント分散の変更を実行する必要がある。残念ながら、要求パターンが頻繁かつ著しく変わると、キャッシュコピーの識別、位置、数さえも頻繁に変えさせることになる。キャッシュディレクトリの更新を必要とする結果、通常キャッシュコピーは大幅には効率よく複製できないこととなり、ネームサービス自体がボトルネックとなる。キャッシュを実現する別の可能な方法は、クライアント／サーバの相互作用プロトコルを、完全な分散形プロトコルを使用して、たとえばランダムな方向に探査を発行することにより、クライアントが前もって適切なキャッシュコピーを特定するように、変更することである。既存のプロトコルの修正の複雑さや、このような方法により生じるメッセージコストは別として、このような方法は、全体のドキュメントサービス待ち時間に１つ以上の往復遅延を付加（クライアントにもそれと分かる）することになる。発明の概要本発明は、自動的、分散的、透過的なキャッシュ方法であって、ドキュメント要求が流れるパス、つまり、コンピュータネットワークを通してクライアントから特定のホームサーバ上の特定のドキュメントに続く経路（パス）が、自然にルーチンググラフまたはツリーを形成する事実を利用している。本発明によれば、キャッシュサーバをネットワーク全体に設置して、ドキュメント要求がルーチンググラフに沿って中間ノードで実行できるなら、中間ノードがクライアントにキャッシュドキュメントを返送するようにする。このようにして、ドキュメント要求メッセージはホームサーバーに到達する前に返答される。ドキュメント要求メッセージは、キャシュが存在しない場合と同様の方法で、クライアントからルーチンググラフ上方にホームサーバ方向にルーチングできるので、ネームサービスを変更する必要はない。標準的なネットワークプロトコルから逸脱せずに本方法で要求をサービスできるようにするために、キャッシュサーバは、組み合わせたルータ内にパケットフィルタを有する。このフイルタは、組み合わせたキャッシュ内に高い確率でヒットし易い（キャッシュ内に存在する確率が高い）ドキュメント要求パケットを抜き出す。好ましくは、キャッシュサーバは、また、ホームサーバの通信プロトコルにおける代理を果たすように動作する。つまり、中間ノード位置においてドキュメント要求メッセージを実行する一部分として、使用中の通信プロトコルに従ってクライアントに適切なメッセージを送り、ドキュメントを実際にホームサーバから受け取ったようにクライアントを信じ込ませる。本発明は、また、複数のキャッシュサービスがクライアント要求をサービスするのに協力する方法を提供する。特に、各サーバは、そのローカルな負荷、近接キャッシュ上の負荷、隣接通信パスの負荷およびドキュメントの人気度合いに基づいて、ドキュメントをキャッシュおよび廃棄する機能を有する。たとえば、各サーバは、近接キャッシュの負荷評価を保持し、そのサーバ自体の負荷評価を近接キャッシュに通信する。あるキャッシュサーバが、近接キャッシュのいずれに比べても過負荷であると認識すると、その仕事の一部を軽減するか、軽負荷の近接サーバに転送する。これを実行するために、好ましくは、キャッシュサーバは、また、所定のホームサーバに対する経路を示すルーチンググラフ上の近接キャッシュの上流（つまり親）および下流（つまり子）のノードの識別を覚える。本発明にかかるドキュメントキャッシュシステムの基本概念にはいくつかの利点がある。第１に、この方法は、キャッシュディレクトリからのアドレス検索要求、ドキュメント要求のリダイレクト、またはキャッシュコピーを配置するためのネットワークの別の構成要素の探査を必要としないことである。したがって、キャッシュコピーの存在場所は、要求メッセージが流れる自然な経路に沿って、偶然的に決まる。これにより、クライアントは、適切なキャシュコピーを見つけるためにネットワークの別のエンティティを待つのに関連する遅延やボトルネックを回避できる。さらに、システム全体として、必要ならネットワークを通してドキュメントのキャッシュコピーを拡散でき、その代わりにキャッシュおよび通信経路に沿ったボトルネックを拡散できる。また、キャッシュコピーは常にクライアントよりも本来のサーバ近くに置かれるため、ネットワーク帯域幅の浪費を抑え応答時間を短縮できる。したがって、ドキュメント要求メッセージおよびドキュメント自体は、通常、要求される度にサーバと各クライアント間の全距離を移動する必要がない。このようにして、全体のネットワーク帯域幅は節約され、応答時間は短縮され、負荷は全体的に平均化する。このように、本発明は、既存のネットワークプロトコルを修正することなく、ホストサーバ上の負荷需要における差異を抑えるのに役立つだけでなく、ネットワーク通信資源上の負荷を低減する。さらに、キャッシュコピーがネットワーク上に分散されているため、キャッシュシステムの単一予測故障点は存在せず、システムは故障に強く安全確実になる。またこの技術は、キャッシュサーバをさらに追加することで、クライアントとサーバの両方に一層の便宜をもたらすという意味で、規模の拡大縮小が可能である。本発明は、ネットワークに付加的な機能を実現するのに使用できる。これら各種機能は、キャッシュサーバに組み合わせたルータに実装されたパケットフィルタも、また、ローカルキャッシュに対するドキュメントのコピーの簡単な派生的要求以上のことができる、という事実からくる。たとえば、キャッシュするドキュメントの選択を管理するためには、人気度の統計をキャッシュサーバにより収集する必要がある。このため、各キャッシュサーバは、特定のドキュメントに対する参照回数を受信し、どこから受信したかの記録を取り、総計の要求量と要求率を求めることができる。このデータはネットワーク領域ごとに中央に集計され、ドキュメント発行元は、彼らの資料（提供物）上へのヒット率だけでなく、ネットワークのどの場所からヒットがなされたのかの統計を得ることが可能となる。これは、ドキュメント人気の分析だけでなく、電子商取引や知的財産追跡に対しても重要である。キャッシュサーバは、また、サービスプロバイダの見地から、負荷を分割するように動作させて、データベースやサーチェンジンインデックスファイル等のような人気のあるドキュメントの複製を管理するのにも使用できる。すなわち、データデースプロバイダは、ドキュメントを最善の配置になるようにネットワーク内のどこにでも置くことができ、そのドキュメントにアクセスするクライアントにより近いデータを送り出す。セキュリティ構成セットをキャッシュサーバに付加することも容易である。そのような構成の１つは、要求メッセージとその他の情報の発信元の認証である。これは、キャッシュサーバが、ドキュメント要求メッセージおよびドキュメント自体の物理的発信源に対する情報を保持しているために可能となる。そのメカニズムは、また、各ノードがフィルタとパケットルータを有する事実による。フィルタとパケットルータは、要求をキャッシュコピーにリダイレクトする方法の記録だけでなく、情報に対する要求を認証してキャッシュコピーへのアクセスを制限するのに使用される。本発明は、また、ネットワークにおける各種の方式のドキュメント分散を可能とする。たとえば、本発明はドキュメント圧縮（別の形で帯域幅を節約する）や暗号化、特定のサーバおよびクライアントノードがキャッシュサーバを使用して通信をコミットされている限り（たとえば、ネットワーク内のクライアントとサーバ間のパスに沿った最初と最後のノードがキャッシュサーバを含む）可能である。本発明は、また、動的内容のドキュメントを効率良くキャッシュできるようにする。このような動的内容のドキュメントは、通常プログラム命令に従って、実行中にもクライアント変更に応答する方式である。本発明は、キャッシュ内に動的内容のドキュメントの存在を認識すると、ドキュメント用データをキャッシュするだけでなく、ドキュメントの表示方法またはデータを再生する時を指定するプログラムをフェッチして実行できるようにする。本発明によれば、また、サーバとクライアント間のネットワークノード数が減少するので、オーディオやビデオデータファイルのような記憶されている連続的メディアの配布も効率よくできる。図面の簡単な説明本発明による利点をさらに理解するためには、添付図面と合わせて次の説明を参照されたい。図１は、代表的なコンピュータネットワークを示す図であって、単一ドキュメントに対する要求経路および本発明による経路に沿ったキャッシュサーバ位置を示す。図２は、リソースマネージャ、プロトコルプロキシおよびスヌーパが、どのように本発明の実現に使用されているかを示す通信階層図である。図３は、ネットワーク上におけるドキュメント要求の代表的な行程を示す図である。図４は、本発明によるルーチング経路上に配置かれたリーフサーバにより実行される動作のフローチャートである。図５は、中間ノンリーフキャッシュサーバにより実行される動作のフローチャートである。図６は、ルーチング経路上の最終キャッシュサーバで実行される動作のフローチャートである。図７は、中間サーバによるドキュメント要求メッセージのインタセプトを示す図である。図８は、さらに詳細にドキュメント要求メッセージのインタセプトを示す図である。図９（ａ）および９（ｂ）は、最悪例のクライアント要求の際に、どのように拡散が進行するかを示す図である。図１０は、キャッシュサーバがドキュメント変換機能を実行する方法を示す図である。好ましい実施形態の詳細説明１．はじめに図１に示すように、インターネット、エクストラネット、私用イントラネット、仮想専用ネットワーク、ローカルエリアネットワークまたはその他の種類のコンピュータネットワークのようなコンピュータネットワーク１０は、クライアントコンピュータ１２−１、１２−２、１２−３、．．．、１２−４（まとめて、クライアント１２）、ルータ１４−１、１４−２、．．．、１４−１０、キャッシュサーバ１６−１、１６−３、１６−４、１６−６、１６−８、１６−１０およびホームサーバ２０を有する多数のネットワークエンティティから構成されている。ネットワークは、公共および私設の電話線、マイクロ波リンク、セルラーおよび無線、衛星リンク、その他の種類のデータ伝送のような、任意および各種の物理層信号伝送メディアを使用できる。図示したネットワークでは、特定のルータ１４はキャッシュサーバ１６とそれぞれ組み合わされている。一方、その他のルータはキャッシュサーバと組み合わされていない。キャッシュサーバ１６は、ディスク記憶１８− １−１および／またはメモリ記憶装１８−１−２を含むキャッシュ記憶装置１８ −１の形式で、ドキュメント用の種々の記憶装置を有する。クライアント１２およびホームサーバ２０では、従来技術と同様に、さまざまな情報（通常はドキュメントの形式）を分散するように動作する。このようなドキュメントは、実質的には、テキスト、グラフィックス、ピクチァ、オーディオ、ビデオ、コンピュータグラフィックス、および、コンピュータファイルもしくはコンピュータファイルの一部分に記憶される多くの種類の情報を含む。さらに、特定のドキュメントは、プログラムの実行により、アクセスがそのドキュメントを要求した時に作成されることもある。次の説明においては、ネットワーク１０はインターネットと仮定し、情報はハイパーテキスト転送プロトコル（ＨＴＴＰ）ドキュメントの形式にエンコードされ、ドキュメント要求メッセージは、ＴＣＰ／ＩＰ層プロトコルを使用してユニフォームリソースロケータ（ＵＲＬ）の形式で送信される。これは、その他の種類のワイヤ式、スイッチ式、ワイヤレス式ネットワーク、およびＦＴＰ、ゴーファー（Ｇｏｐｈｅｒ）、ＳＭＴＰ、ＮＮＴＰ等のようなその他の種類のプロトコルが、本発明を有利に使用できることを意味する。さらに、本発明はクライアント／サーバ形式の通信モデルのコンテキストで説明しているが、本発明の原理は、ピアッーピアネットワークにも同様に適合できることを理解すべきである。特定のドキュメントに対する要求メッセージは、たとえば、クライアント１２ −１のようなクライアントコンピュータの１つで発生する。そのメッセージは、ホームサーバ２０に対して、ディスクのようなホームサーバ２０位置に現在記憶されているドキュメントのコピーを送れという、クライアント１２による要求である。そのドキュメント要求メッセージは、ルータ１４−１、１４−２、１４−３のような１つ以上のルータ１４を介して、図示した矢印の方向に転送されてホームサーバ２０に達する。インターネットのようなネットワークでは、ドキュメント要求メッセージは、ルータを介して、１５またはそれ以上の数のノードまたは「ホップ」を通過した後に意図した宛先に到達する。クライアント１２−２、１２−３、または１２− ４のような他のクライアントからの同一ドキュメントに対する要求も、別のルータ１４を通過して同時にホームサーバ２０に到達する。なお、ルータ１４およびキャッシュサーバ１６は、図１では別個の構成要素として示されているが、それらの機能は単一構成要素にまとめても良い。あるモデルは、１つの特定のドキュメントに対する複数のクライアントからの要求が、コンピュータネットワーク１０の経路をいかに経由するかを理解するのに役立つ。そのモデルは、メッセージがネットワークを通してホームサーバ２０に伝送される際に、ドキュメント要求メッセージ上のルーチングアルゴリズムの効果から生じる構造Ｔである。図１に示すように、ホームサーバ２０は、ルートから最も離れたリーフノードレベル、つまりクライアント１２−１、１２−２、．．．、１２−４で発生したノードドキュメント要求と共に、構造Ｔのルートノードにあると考えることができる。構造Ｔは、また、ルータ１４に配置された多くの中間ノードを有する。クライアント要求が所定のホームサーバー２０に向かって流れる経路セットの構造Ｔは、正確かつ一般的には、データダィレクト、非循環グラフとして示されるが、ここでの説明では複雑性を増すだけである。特に、特定の単一ドキュメントが１つだけのホームサーバに置かれていると考えられる場合、その構造は単一ルートを持つツリーと呼ばれる。このように理解して、ツリーの用語を、ここでは構造Ｔを説明するのに使用する。このように理解すればグラフモデルも使用可能である。このモデルを念頭におくと、インターネット全体はツリーやグラフの森と考えられ、各ツリーやグラフは、ドキュメントの正式な複数組の永久コピーを提供する役割を持つ別のホームサーバ２０に対する経路を持つ。本発明によれば、ドキュメントのコピーはネットワーク中のキャッシュサーバ１６に置かれている。本発明では、キャッシュコピーの配置（したがって負荷の拡散）は、ツリー構造Ｔ内のノードに制約される。これにより、クライアントは、ホームサーバ２０もしくはドメイン名サービス（ＤＮＳ）のようなネームサービスと直接交信すること、またはネットワークを探索して適切なキャッシュコピーを探すことのいずれかによって、キャッシュコピーの位置を検索する必要がなくなる。本発明は、また、ドキュメント要求メッセージがクライアント１２からホームサーバ２０まで自然に選ぶツリーに沿った経路上に、キャッシュサーバ１６が存在すると仮定しており、キャッシュサーバは、ホームサーバ２０の過大負荷を軽減したり、通信リンク自体のようなその他の潜在的性能ボトルネックを拡散するのに協力する。実際には、キャッシュサーバに組み合わせたルータ１４が、通過するドキュメント要求メッセージパケットを検査して、キャッシュされたドキュメントを提供することによって、実行できる要求をインタセプトする（横取りする）。本発明の動作の最も一般的な説明では、ドキュメント要求メッセージは、クライアント１２−３のようなメッセージを発生したクライアントからホームサーバ２０に向かってツリーＴをさかのぼって移動する。その経路に沿ってドキュメント要求メッセージを受けた特定のルータ、たとえばルータ１４−７は、ローカルなキャッシュサーバ１６を持たない。したがって、単にドキュメント要求メッセージを、ルータ１４−６のようなツリー内の次のルータに渡すだけである。しかし、ルータ１４−６のようなその他の特定のルータは、ローカルキャッシュサーバを有しており、この場合、ドキュメント要求メッセージは検査されて、ローカルキャッシュ記憶装置１８に置かれたドキュメントを探すか否かが決定される。キャッシュコピーがキャッシュサーバで見つかれば、そのコピーはクライアント１２に返送され、要求メッセージは続けてホームサーバまでの経路上をたどることはない。しかし、キャッシュコピーが特定のキャッシュサーバ１６−６で見つからない場合は、ドキュメント要求メッセージはホームサーバ２０までの経路上における、次のルータ１４−４に渡される。ドキュメント要求メッセージパケットがルータ１４に入ると、ルータは、まず、その要求メッセージを、ルータのソフトウェアの一部分を構成する、本明細書ではフィルタコードと称する部分に渡す。ルータ１４内のフィルタコードは、必要に応じてローカルキャッシュサーバー１６により更新される。フィルタコードは、パケットの種類、キャッシュ内容、ローカルキャッシュサーバ１６の負荷、または接続されている通信リンク上の負荷に依存する。フィルタは、（ローカルキャッシュサーバにより提供されるサービスに対する）パケットをインタセプトするか、またはパケットをルータ１４に送り返して、パケットがホームサーバ２０までの経路を取る次のホップを決定する。理想的には、キャッシュサーバ１６の実装は、クライアント１２またはサーバ２０のいずれの通常動作モードに対しても、変更が要求されない。別の目的は、ネットワーク１０の既存の下部構造に次第に用いられるように、設計をすることである。好ましくは、任意の新しいメカニズムが、既存の通信プロトコルと互換性を有する。このためには、キャッシュサーバ１６と組み合わせルータ１４が、図２の階層図に示すように、４つの機能構成要素から構成されるのが好ましい。アプリケーション層のような相対的に上位層のプロトコルレベルにおいて、キャッシュサーバ１６はＨＴＴＰプロキシ２２とリソースマネージャ２４とを含む。物理層のような下位層では、ルータは通常パケットフィルタ２６とＩＰプロキシまたはスヌーパ２８を実装する。ＨＴＴＰプロキシ２２は、標準ＨＴＴＰブロトコルを実装して、記憶管理とキャシュされたドキュメントをアクセスするのに必要なインデックス構造の維持を含む役割を果たす。ＨＴＴＰプロキシ２２が、ローカルキャッシュ１８に存在しないドキュメントに対する要求を受け取った場合は、ホームサーバ２０にそのドキュメントを要求して、ドキュメントを受け取ると、要求に応答する。ＨＴＴＰプロキシ２２は、単にリソースマネージャ２４により指示された通りにドキュメントをキャッシュするように構成されている。図２では、２種類のプロキシ（代理）、つまりＨＴＴＰおよびＩＰレベルにおける代理を示すが、その実装は、アプリケーション層、ＩＰ層、またはトランスポート、セッション、プレゼンテーション等の別の層のプロキシを含むことができる。リソースマネージャ２４は、次に詳細を説明するように、ドキュメントコピーをネットワーク１０を通して分散するプロトコルを実装する。リソースマネージャ２４は、ドキュメント負荷分散メカニズムで使用される状態情報を保持する役割を持つ。リソースマネージャ２４は、キャッシュサーバ１６自体の負荷を管理するだけでなく、ルータ１４を相互接続するために使用する通信経路上のトラフィックを管理するようにプログラムされている。この負荷管理、つまり負荷バランスを達成するために、リソースマネージャ２４は、近接するキャッシュサーバ３０のアイデンティティ（実体）および負荷に関する情報を保持する。どのように近接のキャッシュサーバ情報を保持するかの詳細については、次に第３節で説明する。さらに、キャッシュ１８内の各ドキュメントに対して、リソースマネージャ２４は、近接のキャッシュサーバ３０の各々から受け取る要求を区別する。これは、各近接キャッシュサーバ３０から受け取る要求に対するヒット数を、別々に保持することでなされる。このような情報を用いて、リソースマネージャ２４は、分散する過大負荷部分を計算する。これらの負荷部分を求めると、リソースマネージャ２４は、キャッシュすべきドキュメントと受け取るべき要求の負荷部分を近接の軽負荷サーバ３０に通知する。この負荷部分は、組み合わせたルータ１４に導入される新しいフィルタコードを生成するのにも使用される。同様の方法が、軽負荷の近接サーバ３０でも実行される。必要なら、軽負荷のホームサーバ２０のリソースマネージャ２４は、接続されているＨＴＴＰプロキシ２２に、キャッシュ１８に新しいドキュメントを追加するように通知する。リソースマネージャ２４のその他の役割は、近接サーバの発見、近接サーバ３０に対して負荷情報の普及、潜在的障害の発見と負荷平均化への回復である。これらのメカニズムは次にさらに詳しく説明する。ルータ１４は、キャッシュサーバおよび／または通信経路の平均化の目的を遂行するキャッシュサーバ１６を支援するのに積極的な役目を果たす。これは、リソースマネージャ２４が、フィルタ２６およびスヌーパ２８を実装するコード形式で機能をルータ１４に導入させることで、遂行される。特に、ホストサーバ２０に対して直接アドレス指定されておらず、ルータ１４を通過する全パケットは、先ずスヌーパ２８に渡される。スヌーパ２８は、パケットを検査して、その種類、宛先、要求されるドキュメントを判定する。キャッシュサーバ１６の状態とパケットタイプに応じて、スヌーパ２８は、パケットをインタセプトするか、またはホームサーバ２０までの目的の宛先パスに沿って、次のホップまたはルータ１４にパケットを単に送出する。要求されたドキュメントがローカルキャッシュサーバ１６に存在するかを判断するために、スヌーパ２８はフィルタ２６に問い合わせる。フイルタ２６が、要求されたドキュメントがキャッシュされてローカルにサービスできることを示すと、パケットはインタセプトされて、リソースマネージャ２４に渡される。そうでない場合は、パケットは宛先のホームサーバに向かって、次のホップに渡される。スヌーパ２８は、通常、ＴＣＰプロトコルとＴＣＰおよびＨＴＴＰパケットの両方の構造とを認知している。スヌーパ２８の別の機能として、ＨＴＴＰ要求パケットを抜き出して、リソースマネージャに渡すことがある。この機能は、リソースマネージャ２４が、近接サーバを検出し、潜在的な障害から回復することを支援するために使用される。２．ＴＣＰ／ＩＰネットワーク内のＨＴＴＰドキュメント要求の処理ＨＴＴＰを使用するネットワーク１０の現在の実装は、クライアントとサーバ間の高信頼性の端末間通信用の階層化されたＴＣＰ／ＩＰプロトコルに依存している。この階層化は、要求メッセージの通常処理を３段階に分割している。つまり、コネクションの確立（すなわち｛ＳＹＮ｝メッセージ形式のＴＣＰレベルのスリー・ウエイ・ハンドシェイク）、｛ＧＥＴ｝メッセージ形式のＨＴＴＰドキュメント要求／応答、および｛ＦＩＮ｝メッセージの形式のコネクションの終了である。この処理は図３に示すとおりである。クライアント１２は、まず、ホームサーバ２０に、シーケンス番号を含む｛ＳＹＮ｝メッセージを発行し、ホームサーバ２０は、確認応答｛ＡＣＫ｝と共に｛ＳＹＮ｝メッセージを返す。これに応答して、クライアント１２は、所望するドキュメントのＵＲＬを含む｛ＧＥＴ｝メッセージの形式のドキュメント要求を送信する。ドキュメントは、ホームサーバ２０によって、クライアントに送出される。クライアント１２が確認応答を返した後に、サーバ２０とクライアント１２は、｛ＦＩＮ｝と｛ＡＣＫ｝メッセージを交換して、コネクションを終了する。上述したように、このような環境でキャッシュサーバ１６を実際に実装させる上での一番の障害は、クライアント１２からで要求されたドキュメントを、キャッシュサーバ１６が識別しなければならない、という要求である。しかし、図３に示すように、ＵＲＬ情報は、通常、ＴＣＰ／ＩＰコネクションがクライアント１２とホームサーバとの間で確立した後に、ＨＴＴＰクライアント１２によって伝えられる。１つの解決法は、このようなコネクションすべてをホームサーバ２０との間に確立させて、中間ルータ１４のスヌーパ２８にすべての｛ＧＥＴ｝パケットをインタセプトさせることである。この方法は、ホームサーバから大量の負荷を取り除くが、ドキュメントに関係するＴＣＰコネクションをホームサーバにまで到達させるので、ホームサーバ２０の負荷を軽減させる本来の目的を失わせてしまう。需要が集中する間は、多数の要求によって、ホームサーバ１０に｛ＳＹＮ｝要求が殺到する。さらに、最初の｛ＳＹＮ｝がインタセプトされない場合は、コネクションの確立と解除の両方がさらに著しく複雑になる。この障害を克服するために、好ましい実施形態では、中間ルータ１４がＴＣＰプロトコルをある程度認識している。ＴＣＰ認識ルータ１４は、すべてのＨＴＴＰサーバに対するＴＣＰコネクション要求（つまり、ＨＴＴＰポートに向かう｛ＳＹＮ｝パケット）を検出でき、ホームサーバ２０のプロキシ（つまり「擬似」）として動作することができる。この機能はスヌーパ２８により実装されている。特に、スヌーパ２８はＨＴＴＰホームサーバ２０への経路上のルータ１４内に配置されて、ルータ１４を通っていくパケットを検査してパケットを識別する。さらに、ＨＴＴＰホームサーバ２０に向かう任意の｛ＳＹＮ｝パケットをインタセプトする。｛ＳＹＮ｝パケットはクライアント１２が要求しようとしているドキュメントの情報を含まないので、スヌーパ２８はホームサーバのプロキシ、つまり「擬似」として動作する。この動作には、クライアント１２とキャッシュサーバ１６のローカルトランスポート層間のコネクションを確立し、クライアント１２とローカルトランスポート層の両方で使用する初期シーケンス番号を控える。コネクションの確立後、スヌーパ２８は通っていくすべてのパケットを検査し、対応する｛ＧＥＴ｝要求を待つ。｛ＧＥＴ｝要求が到達すると、スヌーパ２８はローカルフィルタ２６とリソースマネージャ２４に、要求されたドキュメントがキャッシュされているかを問い合わせる。ドキュメントがキャッシュされていれば、スヌーパ２８はＨＴＴＰの｛ＧＥＴ｝メッセージをローカルリソースマネージャ２４に送出し、リソースマネージャ２４が要求をサービスするのを待つてからコネクションを終了する。そうでない場合は、要求されたドキュメントはキャッシュされていない（たとえば、フィルタ２６またはリソースマネージャ２４がミスする（見つけられなかった））。この時点で、ドキュメント要求にサービスするために、いくつかの異なる方法を採用できる。第１の方法では、ＴＣＰコネクションをはずす。すなわち、スヌーパ２８は、クライアント１２との擬似ＴＣＰコネクションのサーバ部分を終了し、合成「ピギーバック」｛ＳＹＮ＋ＧＥＴ｝メッセージ（つまり、｛ＳＹＮ｝メッセージに｛ＧＥＴ｝メッセージが埋め込まれたもの）形式でホームサーバ２０に向かうドキュメント要求を送出する。さらに、｛ＳＹＮ＋ＧＥＴ｝メッセージは、要求されたドキュメントをキャッシュするホームサーバ２０への経路上の、任意の別の中間キャッシュサーバとのＴＣＰコネクションのサーバ部分をはずすのに必要なすべての状態情報を含む。第２の別の方法は、スヌーパがＴＣＰリレーとして動作するもので、クライアントとのＴＣＰコネクションは維持し、分離したコネクション上で、｛ＳＹＮ＋ＧＥＴ｝メッセージを、ホームサーバ２０への経路上の次の中間キャッシュサーバに中継する。上述のＴＣＰコネクションをはずす方法を図４にフローチャートで示す。この方法は、リーフノードサーバ３８と呼ばれる、特定のクラスのキャッシュサーバ１６で実行され、このリーフノードサーバ３８は、ツリーＴの最下位レベルノードに存在する、つまりクライアント１２からの｛ＳＹＮ｝パケットを最初にインタセプトするキャッシュサーバ１６である。図１において、ツリーＴ内のリーフノードサーバ３８は、キャッシュサーバ１６−１、１６−６、および１６−８である。図４のステップ４１に示すように、リーフノードサーバ３８が｛ＳＹＮ｝パケットを受信すると、ホームサーバ２０はＴＣＰコネクションをリーフノードサーバ３８とクライアント１２間に直接確立して、ホームサーバの代理をする、つまりホームサーバと見せかける。その後、リーフノードサーバ３８は、クライアント１２からの応答｛ＧＥＴ｝要求をインタセプトするため待機する。なお、クラィアント１２とキャッシュサーバ１６間で交換されるパケットが、上述のようにスヌーパ２８によって修正されて、このように擬似（見せかけること）が起こる。特に、要求をサービスするキャッシュサーバ１６のネットワークアドレスは、ホームサーバ２０のネットワークアドレスと置き代わり、コネクションははずされている。また、キャッシュサーバ１６が発行するシーケンス番号バイトは、リーフサーバ３８が決定するシーケンス番号に続く。ステップ４１に戻って、要求されたドキュメントがフィルタ２８によるキャッシュ問い合わせテストに合格し、ステップ４２に入る。リソースマネージャ２２が、要求ドキュメントがローカルキャッシュ内に存在することを検出し、そのドキュメントへのアクセスを許可すると、ドキュメント要求はローカルにサービスされる。つまり、リーフサーバ３８で処理される。ステップ４５では、｛ＧＥＴ｝コマンドはリソースマネージャに送出され、要求ドキュメントに応答する。最後に、再度ホームサーバ２０と見せかけて、終了の｛ＦＩＮ｝と｛ＡＣＫ｝メッセージをクライアントに発行することで、リーフサーバ３８とクライアント１２間のＴＣＰコネクションを終了する。一方、ステップ４２と４３でミスがあると、スヌーパ２８は｛ＳＹＮ＋ＧＥＴ｝パケットをホームサーバ２０に向けて送出し、そのサーバを擬似ＴＣＰコネクションのサーバ部分を終了する。これにより、ッリー上の別のキャッシュサーバが、可能であれば、サービスする。図４のステップｄ）とｅ）は非同期なイベントであって、通常は同時に起こる。次に、リーフサーバ３８のスヌーパ２８は、｛ＧＥＴ｝要求の受信を確認する必要がある。図１のネットワークでは、上流側中間ノンリーフノード３９は、キャッシュサーバ１６−３、１６−４、および１６−１０を含む。ノンリーフノード３９のキャッシュサーバ１６は、少し異なった方法で、｛ＳＹＮ＋ＧＥＴ｝パケットの処理を必要とする。特に、ノンリーフノード３９内のスヌーパ２８は、要求されたドキュメントがキャッシュされて、ローカルキャッシュサーバ１６がサービスするのに十分な容量を持っている場合のみ、｛ＳＹＮ＋ＧＥＴ｝パケットをインタセプトする。図５は、ノンリーフ中間ノード３９で実行される処理の詳細なフローチャートである。ステップ５１に示すように、要求に対するサービスをするために、スヌーパ２８は先ずリーフノード３８から｛ＳＹＮ｝を代理で受け取り、次の｛ＧＥＴ｝要求をインタセプトする。次のステップ５２および５３では、リーフノード３８と同様に、フィルタ２６とリソースマネージャ２４に問い合わせして、｛ＧＥＴ｝がローカルに処理できるかどうか決定する。その要求がローカルに処理できる場合は、ステップ５５では、クライアント１２間のＴＣＰコネクションのサーバ部分を確立し、｛ＧＥＴ｝をリソースマネージャ２４に発行し、ドキュメントをクライアント１２に返送し、ＴＣＰコネクションを終了することによって、ホームサーバ２０の代理を完了する。｛ＧＥＴ｝メッセージがローカルに処理できない場合は、ステップ５４が実行され、｛ＳＹＮ＋ＧＥＴ｝がツリーＴの次のノードに送出される。中間ノンリーフノード３９内で異なった方法で｛ＳＹＮ＋ＧＥＴ｝パケットを処理する主な利点は、実際に要求されたドキュメントを有する特定の中間ノード３９とのＴＣＰコネクションが一度はずされるだけである。別の利点は、｛ＳＹＮ＋ＧＥＴ｝が、コネクションをはずすのに必要なすべての状態情報を含むことである（つまり、リーフノードサーバ３８のスヌーパ２８と、要求されたドキュメントを実際にキャッシュする中間ノード３９のスヌーパとの間で、さらに状態情報の交換をしない）。この方法におけるピギーバック｛ＳＹＮ＋ＧＥＴ｝パケットの欠点は、このようなパケットを処理するトランスポートプロトコルを採用しなければ、ホームサーバ２０がこのようなパケットを適切にインタセプトしないことである。この問題を避けて現在のネットワークプロトコルでの相互操作性を確実にするには、追加対策が必要である。それためには、スヌーパ２８をホームサーバ２０の前の最終中間ノード３９に置き、すべての｛ＳＹＮ＋ＧＥＴ｝パケットをインタセプトする。したがって、リーフノードサーバ３８または中間ノードサーバ３９のいずれにも要求されたドキュメントがキャッシュされていない場合、最終中間サーバ３９が｛ＳＹＮ＋ＧＥＴ｝をインタセプトして、明白なＨＴＴＰ｛ＧＥＴ｝要求をホームサーバ２０に中継する。このような場合に適合させるために、図５のステップ５４を図６の方法に置き換える。その場合、ステップ６１において、経路Ｔに沿った次の上流ノード（または親ノード）がホームサーバ２０でなければ、ステップ６２に入り、｛ＳＹＮ＋ＧＥＴ｝がＴ上の次の中間ノードに送出される。しかし、次のノードがホームサーバ２０の場合は、ステップ６３が実行される。特に、スヌーパ２８はクライアント１２とＴＣＰコネクションのサーバ部分を確立し、ローカルリソースマネージャ２４に対する｛ＳＹＮ＋ＧＥＴ｝を｛ＰＲＯＸＹ−ＧＥＴ｝要求に置きかえる。リソースマネージャ２４は、｛ＰＲＯＸＹ＿ＧＥＴ｝要求をホームサーバ２０に向けて発行する明白な｛ＧＥＴ｝に変換する。その後、ホームサーバ２０の応答はクライアント１２に中継され、キャッシュサーバが要求されたドキュメントをキャッシュしていたかのようにする。これまで説明したキャッシュ技術の別の欠点は、特定のクライアント１２とホームサーバ２０間のツリーＴに沿った経路が、リーフノードサーバ３８または中間ノードサーバ３９が要求へのサービスを決定した後に、代わりうることである。これは、たとえば、ネットワーク接続またはリンクが２つのサーバノード間で失われる時に起こる。図７は、この比較的まれな事例を示している。ここで、クライアント１２とホームサーバ２０間の経路は、中間キャッシュサーバ１６ｂがクライアント１２からのドキュメント要求を処理している間に代わってしまう。その結果、クライアント１２から送信されるすべての｛ＡＣＫ｝は、新しい経路上を移動し、新しいキャッシュサーバ１６ｘを通ってホームサーバ２０に到達する。これにより、キャッシュサーバ１６ｂはタイムアウトして、そのパケットを再送信してしまう。この問題を解決するために、サーバ１６ｂのスヌーパ２８が、パケットが再送信された回数を記録する。パケットが所定の回数、例えば３回よりも多く再送信された場合、スヌーパ２８は、クライアント１２とホームサーバ２０間の経路が代わったと見なして、クライアント１２とのコネクションを終了するステップを取る。特に、スヌーパ２８はクライアント１２とのコネクションを中止してキャッシュサーバ１６ｂとのコネクションを中止し、同時にホームサーバ２０と見せかけて、リセットパケット（例えば、｛ＲＳＴ｝パケット）をクライアント１２に送信する。別の方法では、クライアント１２に最も近いリーフノードサーバ３８とサーバ２０に最も近い最終のホップノードには、クライアント１２とサーバ２０それぞれに対して、一つのルートのみが設けられている。これは、単に要求メッセージを通常のルートで送出させる代わりに、キャッシュサーバにクライアントの要求メッセージをキャッシュサーバーキャッシュサーバ間の固定したＴＣＰコネクションを介して送出させて行う。したがって、一連の適切に結合されたＴＣＰコネクションとして実装されているコネクションセットは、ネットワーク構成が変化した時、ＩＰルーチング（ＩＰ経路選択）の変化に自動的に適応する。３．近接発見（近接サーバの発見）しかし、近接キャッシュサーバとの通信により、近接キャッシュサーバの構成のすべての変化を検出し、資源負荷の平均化と本発明により可能なその他の利点が達成される。特に、上述の方法に関係する各キャッシュサーバ１６は、他のどのサーバが近接しているかを判定する。さらに、各ルーチングッリーＴ上で、キャッシュサーバ１６は上流側サーバ（親ノードに設置）と下流側サーバ（子ノードに設置）を区別する。ツリーＴ内の特定のノードｉはノードｊの親ノードである。ｊからホームサーバ２０方向のルート上で、ｉが最初のキャッシュサーバ１６ならば、この場合はノードｊはノードｉの子と呼ばれる。キャッシュサーバ１６がその近接サーバを発見する１つの方法は、下位ルータ１４とスヌーパ２８の支援を必要とする。選択した時間に、リソースマネージャ２４はローカルルータ１４に、そのルータが保持しているルーチングテーブル内の各宛先に対して近接発見メッセージを発行するように求める。次に、これらの近接発見パケットは、ツリー内にキャッシュサーバ１６を有する別のノードに存在する所定のスヌーパによりインタセプトされる。近接発見パケットを発行するキャッシュサーバ１６のリソースマネージャ２４に応答を送信するのは、インタセプトするキャッシュサーバ１６の役割である。応答において、親であること（例えば、そのパケットを発行しているキャッシュサーバよりにホームサーバ２０により近いこと）、およびツリーＴのアイデンティティ（実体）を知らせる。近接発見パケットに対する宛先ポートは、存在しえないポート番号を指定してもよい。これは、宛先ホームサーバ２０が、インタセプトされていない近接パケットを、間違って処理しないようにするためである。また、ホップカウントフィールドは、近接発見パケットを過剰に送出されるのを制限するのに、つまり離れたノードまで送出されるのを防止するのに使用される。この方法の欠点は、近接発見パケットがネットワークに溢れる可能性があることである。別の方法は、各キャッシュサーバ１６内のフィルタを通過するドキュメント要求メッセージパケット（すなわち、｛ＳＹＮ＋ＧＥＴ｝パケット）を使用する。この方法では、各要求メッセージは前のホップを識別するフィールドを含み、上述の実行した方法で、特定の要求パケットが通過した最終サーバ１６の識別が行われる。要求がルーター１２を通過する時（つまり、インタセプトされない）、ローカルスヌーパ２８は、付帯しているキャッシュサーバ１６のＩＰアドレスをスタンプする。キャッシュサーバ１６がその近接サーバを発見しようとするとき、キャッシュサーバ１６は、付帯しているスヌーパ２８に、要求パケットから最終監視宛先と最終ホップアドレスとを抜き出すように指示し、その後この情報をローカルリソースマネージャ２４に渡す。図８に示すように、代表的なＨＴＴＰ｛ＧＥＴ｝メッセージがクライアント１２からＡを通ってホームサーバ２０に経路を流れ、中間キャッシュ１６ｃによりインタセプトされる。キャッシュサーバ１６ｃが要求を処理している間、ホームサーバ２０とクライアント１２間の経路は、すべての確認応答に対して、別の経路を使用させる。この情報を使用して、キャッシュサーバ１６ｃのリソースマネージャ２４は、キャッシュサーバ１６が存在しているルーチングツリーと、ツリー上のすべての下流側キャッシュサーバ１６との両方を求める。サーバ１６ｃが、サーバ１６ｂがツリーＴ上の下流側の子と判定すると、キャッシュサーバ１６ｃは、自身がＴ上の親であることをキャッシュサーバ１６ｂに明確に通知する。異なる構成要素間（スプーパ２８とリソースマネージャ２４）のメッセージ交換回数を減らすために、スヌーパ２８は多数のパケットをキャッシュして、それらすべてを１回でリソースマネージャ２４に送出できるようになっている。近接情報は、近接発見の所定の世代数、たとえば世代だけ保持される。この期間中に、どんな要求も子キャッシュサーバ１６ｂを介して受信しない場合は、子キャッシュサーバ１６ｂを近接のキャッシュサーバ１６ｃのモデルから除外する。次に、親キャッシュサーバ１６ｃは、子キャッシュサーバ１６ｂに、モデルから除外する意図を通知する。キャッシュサーバ１６が、ホームサーバ２０へのルーチングツリー上に、親スヌーパ２８を持たないこともある。この場合、キャッシュサーバ１６ｂのスヌーパ２８は、近接発見パケットをホームサーバ２０に向けて送出する。サーバ１６ｃのような上流側スヌーパはパケットを受信し、１６ｂに自身がホームサーバ２０に対するツリー上の親であることを通知する。しかし、キャッシュサーバ１６ｂのスヌーパ２８が、ホームサーバ２０に対するツリー上にキャッシュサーバ１６ｃのような親ノードを持たない場合は、スヌーパ２８が近接発見パケット上の１６ｂアドレスを置換して、それをホームサーバ２０方向に送出する。この近接発見方法は多くの利点を持つ。第１は、ルーチングツリーＴが、動作を開始するためのキャッシュプロトコルに対して完全に構成されていなくてよいことである。別の利点は、協働するキャッシュサーバ１６は動的な発見ができ、ルート変更に適合できることである。最終的にはプロトコルが全体に分散され、これにより、サーバ故障に対して強くなる。４．負荷の平均化（ロードバランス）大部分の他のキャッシュ方法と異なり、本発明によるキャッシュ方法は、実際にクライアントからの要求がある前に、キャッシュサーバ１６へのキャッシュコピーの分散を必要とする。すなわち、クライアント１２からの特定のドキュメント要求のすべてに直接応答するよりは、将来のドキュメント要求を予測してドキュメントをキャッシュサーバ１６間で移動させる。上述のドキュメントキャッシュと近接発見の方法は、キャッシュ負荷の分散および／またはキャッシュサーバ１６およびそれらを相互接続する通信経路の両方の負荷平均化のような、多数の異なる種類の目的に適合する。好ましい実施形態において、この負荷分散方法では、厳密にはローカル情報に依存する、拡散ベースのキャッシュアルゴリズムを使用して、キャッシュシステムのサイズを急激に拡大するオーバーヘッドの発生を避ける。特に、ルーチングツリーＴの上流側（親）ノードが、軽負荷の下流側（子）ノードまたはリンク（これに対しては、リソースマネージャが、キャッシュされたドキュメントの１つを与えてドキュメントサービス負荷のいくつかを移動できる）を検出したときだけ、リソースマネージャ２４はキャッシュコピーを作成する。ここでは負荷は、要求実行率、クライアント応答時間、サーバ動作時間の一部のような多数の異なる性能の基準となる。逆方向における負荷の不均一は、子ノードから、キャッシュされたドキュメントのいくつかを消去させたり、サービスしようとするこれらドキュメントに対する要求の一部を減少させたりする。通常、一定の判断基準に従って子ノードから頻繁に親ノードに要求されるドキュメントは、軽負荷の子ノードに向けられる。同様に、キャッシュサーバ１６がローカルキャッシュ１８からドキュメントをなくす必要があるのは、そのドキュメントに通常ほとんど要求がないときである。さらに、負荷を近接サーバに移管するときは、キャッシュサーバ１６はドキュメントを子または親にそれぞれ押しつけ、または開放（放出）できる。拡散メカニズムによるこのドキュメントキャッシュの目的は２つある。それらは一般に従来の拡散方法にはないものである。これは、キャッシュサーバが複写するドキュメントを決定する他に、ドキュメント要求のどの部分（つまり、負荷）を軽負荷の近接１６に移管すべきか決定する必要性のなかで明白にされる。第１の目的は、キャッシュサーバが軽負荷の近接サーバにドキュメントを渡す方法を決定することである。ここでの目的は、ネットワーク内のキャッシュサーバ１６すべての最大容量を引き出すことである。第２の目的は、人気のあるドキュメントをクライアント近くに移動し、人気のないドキュメントをクライアントから離し、複写の作成を最小にして、応答時間を短縮することである。これらの目的は、キャッシュサーバ１６間の通信経路負荷をも考慮して、達成される。これらの目的を実行するには、ノードｉの過負荷のキャッシュサーバーが、次式のように、子ノードｊの最小軽負荷キャッシュサーバーを判定する。ここで、Ｌｉは特定のキャッシュサーバーｉの負荷、Ｃｉは全キャッシュサーバーの集合である。過負荷キャッシュサーバーｉは、子ｊに最も人気のあるドキュメントに対する要求の一部を押しつける。特に、次の特性を持つ場合、ドキュメントｄはノードｉからノードｊに押しつけられる。ここで、Ｄｉはノードｉにキャッシュされているドキュメントの集合である。一方、次式を満たす場合は、ドキュメントｄはノードｉからノードｊに開放（放出）される。この方法は最大−最小ドキュメント拡散と呼ばれ、上で述べた最初の２つの目的を満足する。所定のキャッシュは、大部分が負荷軽減に寄与するドキュメントを一杯にする、ビンと見なすことができる。これにより、所定のドキュメントに関する負荷が増すにつれ、特定のキャッシュ内に置く必要のあるドキュメントの数は小さくなる。最大−最小ドキュメント拡散は、この第３の条件を満たすために、最小のドキュメント数を提供する。拡散するドキュメントを決定すると、キャッシュサーバは、近接サーバにその負荷を移管するときにインタセプトする要求の一部を変更する方法を決定する必要がある。この部分は、キャッシュサーバがドキュメントによる負荷の一部を移管する方法を考慮して決定できる。特に、ノードｉがノードｊの親で、ｉがｊに比べて過負荷であると仮定する。さらに、ノードｉがドキュメントｄをノードｊに提供する要求の全数のＲ_ij(d)に等しい複数の要求を押しつけたいと要望していると仮定する。要求の全数を次のように定義すると、ドキュメントｄに対してノードｉがサービスする要求数は次式で与えられる。Ｒ_ij(d)要求をノードｊに押しつけた後に、ノードｉは次式で与えられる複数の要求をサービスする。ここで、 Δ_ji(d)は、ノードｉへの移管が完了後に、ノードｊでインタセプトされない要求の数を表す。Δ’_ji(d)については、ノードｉでインタセプトされた新しい部分がβ’_ji(d)で表される。次式が成立する。上の値Δ’_ji(d)とＲ’_ji(d)を用いると、簡単に次のようになる。代数的計算により、次の新しい値となる。新しい部分β’_ji(d)を計算後、ノードｉは組み合わされたフィルタを更新し、ドキュメントｄのコピーをノードｊに送出し、ノードｊにノードｊがＲ_ij(d) によってインタセプトされる要求の数を増加するように指定する。ノードｊがこの情報を受け取ると、次式を計算し、これらの更新内容をそのローカルフィルタコードに反映させる。なお、解析を完成するには、ノードｊでフィルタされる要求の数がＲ_ij(d)で増加する。次式でも知られている。 β’_mj(d)の新しい値を代入すると、次式が得られる。代数的計算により、このようにして解析を完了する。大きなドキュメントでは、ローカルキャッシュ１８が要求されるドキュメントの一部だけを含むのが有利である。この場合は、キャッシュサーバはドキュメントのローカルにキャッシュされた部分をクライアント１２に提供することを開始でき、一方同時にドキュメントの残り部分をホームサーバから送るように要求できる。その他の基準は、ドキュメントのサイズ、ドキュメントの種類、伝送方向、または特定のドキュメントに関連する優先度である。キャッシュサーバ１６とルータ１４は、通信バッファを使用して、高い優先度のメッセージのトラフィックを向上させることもできる。同一種類の関係するドキュメント、またはキャッシュサーバ１６により、いくつかの点で通常密に連続して要求されるのが認められた関係するドキュメントは、同一動作でキャッシュサーバ間を移動する。このように各キャッシュサーバ１６には、そのローカルな負荷、近接負荷、通信経路負荷、ならびに人気度合い、サイズ、フェッチコスト等のドキュメント属性に基づいて、ドキュメントのキャッシュと放棄の機能が与えられる。特に各サーバは、その近接サーバの負荷の評価結果を維持し、および／またはさまざまな時間にその情報または実際の負荷の情報を近接キャッシュサーバ１６に転送、または「ゴシップ」する。キャッシュサーバ１６が、近接サーバに比較してどれかの点で自身が過負荷であると認識すると、将来予測される仕事の一部分を、上に述べたように、軽負荷の子または親の近接サーバに移管する。このように本発明は負荷分割に適し、所定のサーバに対するルーチングツリーＴ内の同一パス上の近接（「同胞」）ノードは、特定ドキュメントに対する要求負荷を分担する。上記のドキュメント拡散アルゴリズムは、最適な負荷分散にある種の難題を伴う可能性がある。特に、所定のキャッシュサーバｊが潜在的な障害になるのは、最低限２つの子キャッシュサーバｋおよびｋ’、ならびに親キャッシュサーバｉを持ち、その各サーバの負荷Ｌが次式を満たすときで、キャッシュサーバｊは軽負荷の子ｋが要求するどんなファイルもキャッシュしない。図９(a)は、そのような場合の例を示す。キャッシュシステムは、（ノード番号１において）ホームサーバ２０と、３台の中間サーバ３９（ノード２、３、４とする）から構成される。要求はリーフノードのみで発生し、特にドキュメントｄ＿１とｄ＿２はノード４から要求されており、ｄ＿３はノード３から要求されている。図は特定ノードのキャッシュコピーの配置と各キャッシュされたコピーによりサービスされる要求を示す。この例では、ノード２のキャッシュサーバ１６は潜在的な障害になる。このサーバは、ｄ＿３をキャッシュしないので、その負荷をノード３のキャッシュサーバに拡散できない。さらに、ノード２のキャッシュサーバ１６は、ノード１のキャッシュサーバが問題の存在を認識することを妨げている。１つの可能な最適負荷配分は、負荷を各ノードサービス要求に合わせて４つのノードに等しく分散することことである。図９(b)は、この条件を満たすファイルキャッシュと負荷分散を示す。しかし、拡散を基本とした方法は、キャッシュサーバ１６が図９(a)のような不都合な状態を検出してそれを回復できるように、変更することが可能である。特に、ｊが軽負荷を修正するアクションを取ることなく、ｋがｊに比べて所定の時間回数（たとえば２）以上に軽負荷に留まるときは、キャッシュサーバｋはその親サーバｊが潜在的に障害であると仮定できる。図９(a)の例では、キャッシュサーバｋはノード３に対応し、キャッシュサーバｊはノード２に対応する。親ノードｋから拡散された負荷が無いことを検出すると、子ノードは親ノードがｋにルートをもつサブツリーから要求されたドキュメントをキャッシュしていないと推測する。これらドキュメントのコピーが最終的に提供されると、サーバｋは通常通りそれをキャッシュできる。この場合サーバｋは負荷障害となる親ノードｊが存在する状態でも、コピーを取り込んでキャシュできるため、この技術はトンネリングと呼ばれている。５．その他の機能本発明はネットワークで追加機能を実装するのに使用できる。これらの各種機能は、ルータ１４に設置されているフィルタ２６が、ローカルキャッシュサーバに対するドキュメントのコピーの要求を単に転送する以上の役割をこなすという事実による。たとえば、どのドキュメントをどのサーバにキャッシュするかの選択を制御するためには、ドキュメントの人気統計がキャッシュサーバ１６で収集される必要がある。各ノードのキャッシュサーバ１６は特定のドキュメントに対する参照回数とそれがどこから来たのかを記録し、要求総量を集計する。このデータは中央位置に収集され、特定のネットワーク領域に設置されたキャッシュサーバ１６のグループによるのと同様に、キャッシュサーバ１６のグループによって整理される。このように収集したデータにより、特定のクライアントでその資料に対する「ヒット率」の統計を得たドキュメントだけでなく、ヒットが発生したネットワーク１０の下位部分の発行も可能である。また本発明では、需要を予測して、ネットワーク１０中に一種のドキュメントの加速分散ができる。キャッシュサーバ１６は、サービスプロバイダの検知から負荷分割装置としてデータベース、索引ファイルの検索、その他の人気のあるドキュメントのホストの複製に使用できる。すなわち、データベースプロバイダは、ネットワーク１０内にドキュメントを配置して持つことができ、配置がどのようであろうと、アクセスを希望するクライアントにより近いデータを送出できる。また、キャッシュサーバは、要求メッセージとその他の情報の発生源の確認を実行できる。これはキャッシュサーバ１６が、特定のドキュメント要求メッセージの発生源のクライアントについては自動的に情報を保持することでなされる。クライアント１２がそのドキュメントに対し許可された要求者でない場合は、その要求メッセージは、ホームサーバ２０に到達する前に、キャッシュサーバ１６で終了させることができる。選択セキュリティも設けられる。そのメカニズムはノードの各々がフィルタ２６、リソースマネージャ２４、キャッシュ収納装置１８およびＨＴＴＰプロクシ２２を備えているからである。フィルタ２６は、キャッシュコピーに対する要求をＨＴＴＰプロキシ２２にリダイレクトする方法を記録するだけでなく、その情報に対する要求を認証することで、キャッシュコピーへのアクセスするのに使用される。キャッシュサーバ１６間のリンクが容易に高信頼性リンクとして構成できるため、クライアント１２からサーバ２０への経路に沿った最初と最後のホップは信頼性が高い。安全確実なリンクがクライアント１２とホームサーバ２０間をキャッシュサーバ１６を経由して提供される。さらに一般的には、キャッシュサーバ１６は、ホームサーバ２０による分散とその後のクライアントへの配布の間、いくつかの時点でドキュメントを変換する。このような変換は、ドキュメントまたはプログラムをキャッシュするために値に加えるいくつかの機能を可能および／または実装でき、ドキュメントまたは／およびプログラムの圧縮や暗号化ような機能を含む。さらに、既知のセキュリティ技術が発生源、宛先または両方（取引業務の場合）において、変換として適用できる。暗号化と解読の他に、これらは認証、許可（アクセスコントロール）、拒絶禁止、保全性管理を含む。これらのセキュリティ技術は、通常、鍵を要求する暗号化技術を使用でき、さらに、キャッシュサーバへの物理パスに使用して、認証、許可、拒絶禁止を強化できる。通常の用途では、これらの変換は、それぞれに整合を取られ（例えば、各暗号については、一致解読であるべき）、個別に使用される。しかし、それらはドキュメントの寿命の点では異なって構成されている。たとえば、ドキュメントは、すべて異なる時点で、圧縮、暗号化、解読、および解凍される。図１０は、ドキュメントを変換するのに適用する１つの可能な方法を示す。この例では、ドキュメントがホームサーバ２０から配布され、クライアントに送られる時に、明確な変換が別個に４回生じている。つまり、Ｔ１において、要求がクライアント１２で作成されるときＴ２において、要求がサーバ２０に送出されるときＴ３において、、応答がサーバ２０により送られたときＴ４において、応答がクライアント１２に送出されたとき図１０の変換が通信の４つのフェーズに関連しているとしても、実際には、変換はノード自体により実行される。このように、要求受信後のキャッシュサーバ１６−６によって、または要求送信前のクライアント１２によって、Ｔ１はその要求で実行される。前者の場合、キャッシュサーバ１６−６が変換を実行している。後者の場合は、クライアント１２が変換を実行する。まれにキャッシュサーバ１６−６を通してこれをトンネリングする。同様に、要求がホームサーバ２０に送出される際に、変換Ｔ２がキャッシュサーバ１６−７またはホームサバー２０で実行される。応答がホームサバー２０から送信され、最終的にはクライアント１２に送出される際に、同様であって逆のことがＴ３とＴ４に適用される。図１０で実行される変換は、セキュリティ用（またはドキュメント以外の入力を要求する別の変換）の鍵の配置において、重要な役割を持つ。キャッシュサーバ１６自体がセキュリティを実装する場合は、暗号化鍵は、必要に応じてキャッシュサーバ１６に分散されなければならない。この場合、端末間のセキュリティは、クライアント１２とキャッシュサーバ１６−６間のほかに、キャッシュサーバ１６−７とホームサーバ２０間にもセキュリティチャネルを追加して提供される。クライアント１２とホームサーバ２０が、それら自体で端末間セキュリティを実装する場合は、キャッシュサーバ１６は妨害せずに、鍵をクライアント１２とホームサーバ２０に配布するのに可能な限り協力する。図１０は、ネットワーク端にキャッシュサーバ１６−６と１６−７がある図を示し、クライアント１２とキャッシュサーバ１６−６間の他に、キャッシュサーバ１６−７とホームサーバ２０間にも直接の経路が存在する。しかし、変換が中間キャッシュサーバ１６−９と１６−１０で実行されるとき、上述したように、この構成ではさらに一般的な構成を排除することはない。すなわち、図１０で、要求または応答または両方申に、変換が中間キャッシュサーバ１６−９と１６−１０でなされてもよい。特定のホームサーバ２０とクライアント１２がキャッシュサーバ１６を使用して通信をコミットされている限り、この方法は、別の形で帯域幅を節約する、透過的なドキュメント圧縮方式を許容する。特に、クライアント１２とサーバ２０間の経路に沿った最初のホップ後の、最初のリーフノードサーバ１６−６は、クライアント１２とホームサーバ２０の両者に透過的な圧縮または暗号化を実装できる。ドキュメントは、また、送出される前に、精細な検査とコード認証ができる。本発明は、また、動的内容のドキュメントの効率的なキャッシュができ、クライアントに返送されるデータの最終結果は実行中にでも変化する。たとえば、Ｊａｖａコードが埋め込まれているドキュメントには、このようなデータが含まれている。キャッシュサーバ１６は、ドキュメント用データをキャッシュするだけでなく、データ再生時にドキュメントを表示する方法を指定したプログラムをキャッシュして、このような動的内容のドキュメントの効率的な配布を達成できる。プログラムがドキュメントを表示するときに、プログラムがクライアント１２で通常実行される形式ならば、そのプログラムとデータは単にクライアント１２に転送されるだけである。しかし、そのプログラムが、クライアント１２がホームサーバ２０上で実行することを希望する形式であれば、キャッシュサーバ１６はホームサーバの付加的レベルを実行し、そのプログラムも実行することでホームサーバと見せかける（代理の役割を果たす）。この時、キャッシュサーバ１６がクライアント１２と相互作用的セッション状態を維持して、ホームサーバ２０と完全に見せかける必要がある。本発明は、また、本来、ホームサーバ２０とクライアント１２間のホップ数が少ないために、オーディオやビデオデータのファイルのような記憶メディアの配布に有効なものである本発明によるいくつかの実施形態を示し説明したが、本発明がそれに限定されず、当業者には既知の多数の変更と修正が可能である。したがって、通常の技術を有する者には明白な変更と修正のすべてをカバーする以外は、ここで示し説明した詳細を制限することを望むものではない。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｌ 12/58 Ｈ０４Ｌ 11/20 １０１Ｚ 29/06 (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ヘッダヤ・アブデルサラム・エーアメリカ合衆国，マサチューセッツ州 02154 ウォルザム，スターンズヒルロード 901 (72)発明者イェーテス・ディビッド・ジェーアメリカ合衆国，マサチューセッツ州 02062 ノーウッド，ビレッジロードウェスト 2809 【要約の続き】装する。

Claims

【特許請求の範囲】１．通信プロトコルを使用してネットワークを介して通信する複数のコンピュータであって、ドキュメントの形式で情報を記憶するために前記ネットワーク内の特定ノードにホームサーバまたは単なるサーバとして動作するコンピュータと、ドキュメント要求メッセージをアプリケーション層の前記サーバに送るクライアントとして動作する特定のその他のコンピュータとを有し、そのドキュメント要求メッセージが前記サーバに記憶するドキュメントに対する要求であるシステムにおいて、ドキュメント要求メッセージを実行する方法であって、（ａ）前記ネットワーク内の複数の中間ノード位置にあるドキュメントのローカルキャッシュコピーを記憶し、（ｂ）前記サーバの特定の１つに送ろうとする特定のアプリケーション層ドキュメント要求メッセージを発生する前記クライアントの特定の１つに応答して、前記中間ノード位置の１つにおいて、前記アプリケーション層より下位の選択された通信層で前記特定のアプリケーション層ドキュメント要求メッセージを実行して、前記ドキュメント要求メッセージをインタセプトして前記ローカルキャッシュコピーの１つを前記クライアントのアプリケーション層に返送し、前記アプリケーション層ドキュメント要求メッセージが前記中間ノードの下位層でインタセプトされて、前記サーバ上のアプリケーション層がアプリケーション層ドキュメント要求メッセージを受信しないようにする、各ステップを有する方法。２．請求項１において、選択された中間ノードにおいて、さらに、（ｃ）特定のドキュメント要求メッセージが、前記ローカルキャッシュコピーの１つを提供しても実行できない場合は、そのドキュメント要求メッセージを他のノードにルーチングするステップを有する方法。３．請求項１において、前記特定のドキュメント要求を実行するステップがさらに、クライアントでもサーバでも無い最低１つの前記中間ノード内で、（ｃ）他の中間ノード上にも記憶されている特定ドキュメントのローカルキャッシュコピーを記憶し、（ｄ）ローカルキャッシュコピーを記憶する近接中間ノードのアイデンティティを決定し、（ｅ）前記中間ノードのドキュメント要求メッセージ負荷実行資源の有用性を基に、前記中間ノードと近接中間ノード間でドキュメント要求メッセージの実行を割り当てる、各ステップを有する方法。４．請求項３において、前記メッセージ負荷実行資源が前記キャッシュを含む方法。５．請求項３において、前記メッセージ負荷実行資源が通信パス負荷を含む方法。６．請求項３において、前記ドキュメント要求メッセージの実行を割り当てるステップがさらに、（ｆ）処理負荷、通信パス負荷、ドキュメントサイズ、ドキュメント要求メッセージ応答時間、ドキュメント要求メッセージの要求率、ドキュメント要求メッセージの変更率、またはホームサーバ運用性の少なくとも１つから選択された情報を含む状態メッセージを、前記中間ノードと近接ノード間で交換するステップを有する方法。７．請求項１において、さらに、（ｃ）他の中間ノード上にも記憶されている特定ドキュメントのローカルキャッシュコピーを記憶し、（ｄ）ローカルキャッシュコピーを記憶する近接中間ノードの前記アイデンティティを決定し、（ｅ）前記通信パス負荷を基に、前記中間ノードと近接中間ノード間で前記ドキュメント要求メッセージの実行を割り当てる各ステップを有することにより、前記特定のドキュメント要求を実行するステップが、前記ノードを相互接続するパス間の通信パス負荷分散を実行する方法。８．請求項２において、選択された中間ノードにおいて、さらに、（ｄ）そこから特定のドキュメント要求メッセージを受け取る第１の近接ノードのアイデンティティを決定し、（ｅ）前記特定のドキュメント要求メッセージが前記クライアントに対し前記ローカルキャッシュコピーを返送することによっても実行されない場合は、前記ホームサーバへのパス上で、そこに特定のドキュメント要求メッセージがルーチングされる第２近接ノードのアイデンティティを決定する各ステップを有する方法。９．請求項８において、ローカルキャッシュコピーを記憶するステップがさらに、（ｆ）前記第１近接ノードのノード状態パラメータと前記ローカルノードのノード状態パラメータを決定して、その第１近接ノードとローカルノードのノード状態パラメータが、相互に所定の量だけ異なるとき、前記ローカルキャッシュコピーの少なくとも１つのコピーを前記第１近接ノードに送出して前記第１近接ノード位置に記憶するステップを有する方法。１０．請求項９において、前記ノード状態パラメータが、要求実行率、要求実行変化、ドキュメントサイズ、ドキュメントフェッチ応答時間、通信パス負荷、キャッシュサーバ負荷、またはホームサーバ動作状態から成るグループから選択される方法。１１．請求項８において、ローカルキャッシュコピーを記憶するステップがさらに、（ｆ）前記第２近接ノードのノード状態パラメータとローカルノードのノード状態パラメータを決定して、前記第２近接ノードとローカルノードのノード状態パラメータが所定の量だけ異なるとき、前記ローカルキャッシュコピーの少なくとも１つを送出するステップを有する方法。１２．請求項１１において、前記ノード状態パラメータが、要求実行率、要求実行率の変化、ドキュメントサイズ、ドキュメントフェッチ応答時間、通信パス負荷、キャッシュサーバ負荷、またはホームサーバ動作状態から成るグループから選択される方法。１３．請求項８において、ローカルキャッシュコピーを記憶するステップがさらに、（ｆ）前記第２近接ノードのノード状態パラメータとローカルノードのノード状態パラメータを決定して、前記第２近接ノードとローカルノードのノード状態パラメータが所定の量だけ異なるとき、前記フィルタリングのステップにおいて、前記クライアントにローカルキャッシュコピーを提供して実行される前記ドキュメント要求の部分を減少するステップを有する方法。１４．請求項１において、前記フィルタリングのステップがさらに、（ｃ）ローカルノード状態パラメータが所定の量と異なる場合は、前記クライアントにローカルキャッシュコピーを返送するステップを有する方法。１５．請求項１において、前記の選択された中間ノードにおいて、さらに、（ｃ）前記ローカルキャッシュコピーの１つを前記クライアントに提供して実行される要求メッセージの数に関する負荷統計を記録するステップを有する方法。１６．請求項１において、選択された中間ノードにおいて、さらに、（ｃ）特定のドキュメントに対して受け取られて実行された要求メッセージの数に関する要求メッセージ統計を記録するステップを有する方法。１７．請求項１１において、前記の選択された中間ノードにおいて、さらに、（ｃ）特定のサーバに記憶されたドキュメントに対して受け取られた要求メッセージの数に関する応答時間統計を記録するステップを有する方法。１８．請求項１において、ドキュメント要求メッセージが複数の通信パス上の前記中間ノードで受け取られ、さらに、前記の選択された中間ノードにおいて、（ｃ）ドキュメント要求メッセージが特定のパスから受け取られた記録に関する要求メッセージ統計を記録するステップを有する方法。１９．請求項１において、ドキュメント要求メッセージが、複数の通信パス上の前記中間ノードで受け取られ、さらに、全体のネットワーク需要とネットワーク領域需要の１つから選択された基準によるか、または特定のクライアント需要によって、通信パスの使用頻度を予測する方法。２０．請求項１において、前記ドキュメント要求メッセージをフィルタリングするステップがさらに、（ｃ）前記ドキュメント要求メッセージドを送出する前に、それを介してドキュメント要求メッセージがクライアントから届くノードを認証するステップを有する方法。２１．請求項１において、前記ドキュメント要求メッセージをフィルタリングするステップがさらに、（ｃ）前記ローカルキャッシュコピーを前記クライアントに返送する前に、前記のキャッシュされたドキュメントが発生したノードを認証するステップを有する方法。２２．請求項１において、前記サーバが前記ドキュメント上で動作するプログラムも記憶し、ステップ（ｂ）が、前記中間ノードにおいて、さらに、（ｃ）要求されたドキュメントコピーに関係する特定の選択されたプログラムが前記サーバから得られるように、選択されたプログラムのローカルキャッシュコピーを記憶するステップを有する方法。２３．請求項２２において、さらに、（ｄ）前記クライアントからの要求に応じて、前記中間ノードにおいて選択されたプログラムの前記ローカルキャッシュコピーを実行するステップを有する方法。２４．請求項２２において、さらに、（ｄ）前記中間ノードと前記クライアント間の相互作用的セッションを維持して、前記サーバとして動作する前記中間ノードを、前記サーバが前記ドキュメント要求メッセージを実行した場合に動作させるステップを有する方法。２５．請求項１において、前記ドキュメント要求メッセージをフィルタリングするステップがさらに、（ｃ）選択されたプログラムを前記ローカルキャッシュコピーに適用して結果を得て、その後にそのプログラムの適用結果をクライアントに返送するステップを有する方法。２６．請求項１において、前記ドキュメントがマルチメディアドキュメント、プログラム、データベース、圧縮データ、または暗号化データのグループから選択される方法。２７．請求項８において、複数の中間ノードが前記サーバと前記クラィアント間に設置され、前記ドキュメントの需要予測率に基づいて、特定ドキュメントが複数のノードに対してをルーチングされてネットワークに送出される方法。２８．請求項９において、前記所定の要求実行率が、予測要求実行率、予測要求実行率変化、ドキュメントサイズ、予測ドキュメントフェッチ応答時間、または予測キャッシュサーバ負荷のグループから選択されたドキュメント属性に依存する方法。２９．請求項１において、前記中間ノードにおいて、さらに、（ｃ）前記ローカルキャッシュコピーと共に、前記ローカルキャッシュコピーの放出についての条件を示すデータを記憶し、（ｄ）前記条件を満足した場合にだけ、前記ローカルキャッシュコピーを前記クライアントに返送する各ステップを有する方法。３０．請求項２９において、前記条件が前記ドキュメントを放出した時間である方法。３１．請求項１において、キャッシュコピーを記憶するステップが、所定の基準条件を基に選択的に実行される方法。３２．請求項３１において、前記条件が時刻を含む方法。３３．請求項３１において、前記条件基準がドキュメントサイズ、希望されるドキュメント要求メッセージ応答時間、ドキュメント要求メッセージ率、ドキュメント要求メッセージ率の変化率、サーバ負荷、通信パス負荷、またはホームサーバ動作状態のグループから選択された少なくとも１つである方法。３４．請求項１において、キャッシュコピーを記憶するステップがさらに、所定のサイズ以上のドキュメントの部分コピーを記憶するステップを有する方法。３５．請求項１において、さらに、（ｃ）所定の基準条件を基に実行されたドキュメントのキャッシュコピーを選択的に消去するステップを有する方法。３６．請求項３５において、前記所定の基準条件が時刻を含む方法。３７．請求項３５において、前記所定の基準条件がドキュメントサイズ、希望されるドキュメント要求メッセージ応答時間、ドキュメント要求メッセージ率、ドキュメント要求メッセージ率の変化率、サーバ負荷、または通信パス負荷のグループから選択された少なくとも１つである方法。３８．請求項１において、キャッシュコピーを記憶するステップがさらに、所定のサイズ以上のドキュメントの部分コピーを記憶するステップを有する方法。３９．コンピュータが複数のノードにおいて複数のパスにより相互接続されるコンピュータネットワークで動作する論理的通信ネットワークを提供する方法であって、その論理的通信ネットワークにより第１ネットワークの第１コンピュータが確実に第２ネットワークノードの第２コンピュータと通信できるようにするもので、（ａ）前記第１ノードと、前記第１ノードと前記第２ノード間の通信パス内の第１ホップである第１の中間ノードとの間のパスに沿った確実な通信パスを提供し、（ｂ）前記第２ノードと、前記第１ノードと前記第２ノード間のパス内の最終ホップである最終の中間ノードとの間の確実な通信パスを提供し、（ｃ）前記第１および最終中間ノードに対し暗号化鍵を提供し、前記第１中間ノードがその鍵を使用して情報を暗号化した後に前記パス内の他の中間ノードに送出し、前記最終ノードがその鍵を使用して情報を暗号化した後に前記第２中間ノードに送出して、その結果、確実な通信パスが第１と最終中間ノード間に提供される各ステップを有する方法。４０．コンピュータが複数のノードにおいて複数のパスにより相互接続されるコンピュータネットワークで動作する通信ネットワークを提供する方法であって、その通信ネットワークにより第１のネットワークノードの第１コンピュータが第２ネットワークノードの第２コンピュータと通信できるようにするもので、（ａ）前記第１ノードと、前記第１ノードと前記第２ノード間の通信パス内の第１ホップである第１の中間ノードとの間のパスに沿った通信パスであって、複数のパスを有する通信パスを提供し、（ｂ）前記第２ノードと、前記第１ノードと前記第２ノード間のパス内の最終ホップである最終の中間ノードとの間の通信パスを提供し、（ｃ）前記第１および最終中間ノードに対し圧縮と復元の機能を提供し、前記第１中間ノードがその圧縮機能を使用して情報を圧縮した後に前記パス内の他の中間ノードに送出し、前記最終ノードが前記復元機能を使用して情報を復元した後に前記第２中間ノードに送出して、その結果、帯域幅を縮小した通信パスが前記第１と第２の中間ノード間に提供される各ステップを有する方法。４１．請求項１において、キャッシュの一貫性を維持するために、さらに、（ｃ）前記サーバにおいて、前記ドキュメントにドキュメント終了タイムスタンプを付し、（ｄ）中間ノードにおいて、キャッシュされたドキュメントに付された前記タイムスタンプを検査して、ドキュメントが終了したかどうか判定し、（ｅ）前記キャッシュされたドキュメントが終了していた場合は、そのドキュメントを消去または再生する各ステップを有する方法。４２．請求項１において、さらに、（ｃ）前記サーバにおいて、前記ドキュメントにドキュメント変更タイムスタンプを付し、（ｄ）中間ノードにおいて、前記ドキュメントの変更率を評価して、そのドキュメント変更率が前記要求率よりも所定量大きい場合は、前記キャッシュされたコピーを消去し、そのドキュメント変更率が前記要求率よりも所定量小さい場合は、キャッシュコピーの更新を要求する各ステップを有する方法。４３．階層化通信プロトコルを使用してネットワークを介して通信する複数のコンピュータを含むシステムにおいて、そのネットワーク内の特定のノードのコンピュータがドキュメントの形式で情報を記憶するサーバとして動作し、特定の他のコンピュータがドキュメント要求メッセージをアプリケーション層レベルの前記サーバに送るクライアントとして動作し、前記ドキュメント要求メッセージが前記サーバに記憶されたドキュメントに対する要求であって、透過的な代理によってドキュメント要求メッセージを実行する方法であって、（ａ）ネットワーク内の複数の中間ノード位置にローカルキャッシュコピーを記憶し、（ｂ）前記サーバの特定の１つに送ろうとする特定のアプリケーション層ドキュメント要求メッセージを発生する前記クライアントの特定の１つに応答して、そのドキュメント要求メッセージをインタセプトして前記中間ノード位置の１つで前記アプリケーション層ドキュメント要求メッセージを実行して、前記ローカルキャッシュコピーの１つをクライアントのアプリケーション層に返送し、その結果前記アプリケーション層要求メッセージが中間ノードでインタセプトされて、その結果ネットワーク接続が前記サーバのアプリケーション層との間で確立されないようにする各ステップを有する方法。４４．請求項４３において、中間ノードがキャッシュサーバとルータとを有し、そのルータにおいて、さらに、（ｃ）インタセプトされるドキュメント要求メッセージを認識して、そのメッセージを抜き出して前記キャッシュサーバで処理するステップを有する方法。４５．請求項１において、さらに、（ｃ）最も頻繁に連続して要求される関係ドキュメントを合わせて同時にプリフェッチするステップを有する方法。４６．請求項１において、さらに、前記クライアントにおいて、（ｃ）前記クライアントとサーバ間に通信パスを確立することを要求する接続要求メッセージを発生し、中間ノードにおいて、（ｄ）前記クライアントから接続要求メッセージを受け取り次第、ドキュメント要求メッセージの受信を待ち、その接続要求メッセージと前記ドキュメント要求メッセージを合わせて前記パス内の次の中間ノードに送出する各ステップを有する方法。４７．請求項４６において、さらに、前記要求メッセージにより指示された前記ドキュメントをキャッシュする中間ノードにおいて、（ｅ）前記クラィアントに対し前記接続要求を確認応答し、そのクライアントに前記の要求されたドキュメントを返送するステップを有する方法。４８．請求項１において、さらに、（ｃ）ローカルキャッシュに記憶するドキュメントとそのローカルキャッシュから取り除くドキュメントを選択するキャッシュサーバを動作させて、そのキャッシュサーバに最も頻繁に要求されるドキュメントを選択してパス内のノードの近接キャッシュサーバに複写させ、ほとんど要求されないドキュメントをメモリから削除させるステップを有する方法。４９．請求項１において、各中間ノードにはリソースマネージャが組み合わされており、このリソースマネージャが、（ｃ）設計上で重要と考えられているメッセージトラフィックを向上させるために、入力および出力メッセージを緩衝記憶する通信バッファの使用を割り当てるステップを遂行する方法。５０．請求項４９において、（ｄ）ドキュメントサイズ、ドキュメント種類、伝送方向、または優先度の組み合わせから選択された内容属性を基に、通信バッファおよび通信パス帯域幅の使用を割り当てるステップを有する方法。５１．請求項１において、前記中間ノードにおいて、さらに、（ｃ）前記中間ノードのノード状態パラメータを近接サーバのノード状態パラメータと比較し、（ｄ）前記近接ノードのパラメータおよび前記中間ノードパラメータが、所定の時間長さ以上に所定量だけ異なる場合は、前記中間ノードにおいて、その近接ノードが中間ノードで要求された１つまたは複数のドキュメントをキャッシュしないと推定する各ステップを有する方法。５２．請求項５１において、前記ノード状態パラメータが、要求実行率、要求実行率の変化、ドキュメントサイズ、ドキュメントフェッチ応答時間、通信パス負荷、ホームサーバ運用性、またはキャッシュサーバ負荷から成るグループから選択される方法。５３．ネットワークを介して通信する複数のコンピュータを含み、そのネットワーク内の特定のノードのコンピュータがドキュメントの形式で情報を記憶するサーバとして動作し、特定の他のコンピュータがドキュメントを前記サーバに記憶されるように要求するドキュメント要求メッセージを送るクライアントとして動作するシステムにおいて、ドキュメント要求メッセージの実行を調整して負荷を分散する方法であって、（ａ）ネットワーク内の複数の中間ノード位置にローカルキャッシュコピーを記憶するステップと、前記サーバの特定の１つに送ろうとする特定のドキュメント要求メッセージを発生する前記クライアントの特定の１つに応答して、（ｂ）その特定ドキュメント要求メッセージ内で指定されたドキュメントに対応する前記キャッシュサーバの１つを返送して、複数の中間ノード位置の１つで前記特定ドキュメント要求メッセージを実行して、前記ローカルキャッシュコピーの１つをクライアントのアプリケーション層に返送し、その結果、前記中間ノード位置のアプリケーション層がその要求をインタセプトして前記サーバのアプリケーション層が前記ドキュメント要求メッセージを受け取らないようにするステップとを有する方法。５４．請求項５３において、さらに、（ｃ）前記複数の中間ノード位置間で、前記キャッシュコピーを記憶するステップを調整し、かつ、前記複数の中間ノード位置間でドキュメント実行を分割して、前記中間ノードキャッシュサーバまたはホームサーバにドキュメント要求負荷を分散するステップを有する方法。５５．請求項５３において、さらに、（ｃ）前記中間ノード位置において、キャッシュコピーを記憶するステップを調整し、かつ、前記複数の中間ノード位置間でドキュメント実行を分割して、通信パス負荷を分散するステップを有する方法。５６．請求項５３において、キャッシュコピーを記憶するステップを前記複数の中間ノード位置間で調整してドキュメント負荷を減少させるステップを調整するステップが、（ｃ）近接するノード位置においてドキュメントを複写するステップを有する方法。５７．請求項５３において、中間ノード位置にドキュメントのコピーを記憶するステップが、さらに、（ｃ）所定の基準の基づいて、そのようなコピーを有効または無効のどちらかにすることで、ドキュメント要求を実行するステップを有する方法。５８．請求項５７において、前記所定の基準が時刻である方法。５９．請求項５３において、前記中間サーバの１つで前記特定ドキュメント要求メッセージを実行するステップが、さらに、（ｃ）前記クライアントからドキュメント要求メッセージを最初に受け取る前記中間ノード位置の１つであるリーフノードと、前記サーバとの間の通信接続をオープンし、（ｄ）前記ドキュメント要求および前記通信接続を、前記リーフノードよりもネットワーク内の前記サーバにより近い他の中間ノードに送出する各ステップを有する方法。６０．請求項５３において、前記中間サーバの１つで前記特定ドキュメント要求メッセージを実行するステップが、さらに、（ｃ）前記クライアントからドキュメント要求メッセージを最初に受け取る前記中間ノード位置の１つにあるリーフノードと、前記サーバとの間の通信接続をオープンし、（ｄ）前記ドキュメント要求を、前記リーフノードよりもネットワーク内の前記サーバにより近い他の中間ノードに中継する各ステップを有する方法。６１．請求項５３において、前記キャッシュサーバが、さらに、（ｃ）前記クライアントの観点から前記ホームサーバに対して通信代理として動作するステップを遂行する方法。６２．請求項５３において、前記ドキュメント要求メッセージを実行するステップがさらにドキュメントへのアクセスを制御するものであり、さらに、（ｃ）前記ドキュメント要求メッセージ内のＵＲＬ(Uniform Resource Location ）フィールドに基づき、ドキュメント要求メッセージをフィルタリングするステップを有する方法。６３．請求項５３において、前記ドキュメント要求メッセージを実行するステップがさらにドキュメントへのアクセスを制御するものであり、さらに、（ｃ）前記ドキュメント要求メッセージ内の確認フィールドに基づき、ドキュメント要求メッセージをフィルタリングするステップを有する方法。６４．請求項５３において、前記クライアントに前記ドキュメントのキャッシュコピーを返送するステップが、さらに、（ｃ）前記ドキュメントを精細に検査するステップを有する方法。６５．請求項５３において、前記クライアントに前記ドキュメントのキャッシュコピーを返送するステップが、さらに、（ｃ）前記ドキュメントをコード認定するステップを有する方法。６６．請求項５３において、前記クライアントに前記ドキュメントのキャッシュコピーを返送するステップが、さらに、（ｃ）前記ドキュメントを解読するステップを有する方法。６７．請求項５３において、前記クライアントに前記ドキュメントのキャッシュコピーを返送するステップが、さらに、（ｃ）クライアント認証およびホームサーバ要求に基づき、前記ドキュメントのキャッシュコピーへのアクセスを制御するステップを有する方法。６８．コンピュータネットワーク内の情報に対する要求を実行する方法であって、少なくともそのネットワーク内のいくつかコンピュータが情報を記憶するホームサーバとして動作し、少なくともいくつかコンピュータが前記ホームサーバに要求メッセージを送るクライアントとして動作するもので、（ａ）キャッシュサーバとして動作する前記ネットワーク内の複数のコンピュータ内に情報のコピーを記憶することにより、そのネットワークを介して情報のキャッシュコピーを分散し、（ｂ）前記ネットワーク内の複数の中間コンピュータを通して、前記クライアントから前記サーバに要求メッセージをルーチングし、その際、少なくとも前記中間コンピュータのいくつかがキャッシュサーバとしても動作し、前記要求メッセージが前記サーバの特定の１つから発行されて前記サーバの特定の１つから情報を取得し、（ｃ）前記キャッシュサーバを通ってルーチングされた通りに要求メッセージを透過的に処理することで、前記ホームサーバの代わりに前記キャッシュサーバから提供される要求メッセージが、前記クライアントとホームサーバに対して透過的な方法で、前記キャッシュサーバから提供されるようにする各ステップを有する方法。６９．請求項５９において、さらに、（ｄ）前記キャッシュサーバによる前記要求メッセージの提供に関する所定の基準に対応して、ネットワーク内の前記キャッシュサーバ間でキャッシュコピーを自動的に移動させるステップを有する方法。７０．請求項１において、前記マルチメディアドキュメントがテキスト、グラフィックス、オーディオ、ビデオ、プログラムまたはその他のデータから選択されたデジタル化情報を含む方法。７１．請求項１において、前記ネットワークがワイヤレスネットワークを有する方法。７２．請求項１において、前記中間ノードが、特定の通信エンティティが故障しているかどうか判断し、故障していれば他のネットワークエンティティに通告するステップを遂行する方法。７３．請求項７２において、前記通信エンティティがルータまたは通信パスのいずれか１つである方法。７４．請求項７２において、前記他のネットワークエンティティが他の中間ノード、ネットワーク管理者、または他のネットワーク化コンピュータシステムのいずれか１つである方法。７５．請求項５７において、前記所定の基準が前記クライアントによる通告である方法。７６．請求項５７において、前記所定の基準が前記ホームサーバによる通告である方法。７７．請求項２において、選択された中間ノードにおいて、さらに、（ｄ）特定のドキュメント要求メッセージを受け渡す第１近接ノードのアイデンティティを決定し、（ｅ）前記ホームサーバへのパス上で、特定のドキュメント要求メッセージがルーチングされる第２近接ノードのアイデンティティを決定し、（ｆ）前記中間ノードにおいて処理に失敗するかまたは処理が遅いために、前記特定ドキュメント要求メッセージが前記中間ノードで満足に実行されない場合、前記パスを変更してその中間ノードを迂回する各ステップを有する方法。