JP5288204B2 - ゲートウェイシステム及び制御方法 - Google Patents

Description

本発明は、クライアント−サーバ型のネットワークサービスにおけるゲートウェイシステムの負荷分散のための技術に関する。

端末の性能が向上し、また、アクセス網が高速化することによって、キャリアのゲートウェイが処理するトラフィックは増大している。このため、キャリアは、インターネットとのトランジット回線を増強し、また、情報処理技術を用いてゲートウェイにおけるトラフィックを削減することを目指している。

例えば、トラフィックを削減するための情報処理技術には、コンテンツキャッシュがある。ここで、コンテンツキャッシュとは、ある端末がインターネット上のサーバ装置（例えば、Ｗｅｂサーバ）のコンテンツを要求した場合、ゲートウェイのサーバ装置（例えば、Ｗｅｂプロキシ）が、Ｗｅｂサーバから取得したコンテンツを一時的に格納し、他の端末が該コンテンツを要求した場合、Ｗｅｂプロキシが、Ｗｅｂサーバの代理として、格納されたコンテンツを返答する技術である。

これによって、ゲートウェイは、Ｗｅｂサーバとの間のトラフィックを削減することができる。また、ゲートウェイは、コンテンツ取得の処理を速くすることができる。

また、ゲートウェイは、大量の端末を収容し、また、大量のコンテンツを格納するために複数のサーバ装置を備え、これらのサーバ装置にコンテンツを分散する。ゲートウェイが備えるサーバ装置の性能に限界がある場合、複数のサーバ装置に処理を分散する方法は非常に有効である。

従来では、複数のサーバ装置に処理を分散するため、例えば、端末とゲートウェイのサーバ装置との間に負荷分散装置が設置されている。負荷分散装置は、端末からの要求（例えば、コンテンツ取得要求）を各サーバ装置に転送する。なお、負荷分散の処理は、端末からの要求をどこまで深く解析するかによって異なる。

例えば、送信元ＩＰアドレスなどの低いレイヤの情報に基づいて負荷分散を実行する場合、解析の処理が少ないので、負荷分散装置は、大容量のトラフィックを処理することができる。しかしながら、端末からの要求の転送先を計算するための情報が少ないので、負荷分散装置は、適切に負荷分散を実行できない可能性がある。

また、ＨＴＴＰリクエストなどのレイヤ７の情報の情報に基づいて負荷分散を実行する場合、負荷分散装置は、アプリケーション毎の特性に応じて適切に負荷分散を実行することができる。しかし、負荷分散装置自体の負荷が高くなるので、負荷分散装置は、多数のサーバを管理できない可能性がある。

そこで、前述した問題を解決するために、以下に示す負荷分散のための技術が提案されている。

例えば、各端末が、送信先を判定するためのテーブルに基づいて、各サーバ装置に要求を分散する技術が提案されている（例えば、特許文献１参照）。特許文献１に記載された技術によると、どのサーバに要求を送信すべきかを判定するためのテーブルが端末に配布されるので、端末は各サーバ装置に要求を分散することができる。さらに、端末からの要求に対する返答にテーブルの更新情報が含められるので、テーブルの配布に要する負荷も軽減される。

また、各端末の要求から生成されたハッシュ値に基づいて、各端末が要求を各ゲートウェイに分散する技術が提案されている（例えば、特許文献２参照）。特許文献２に記載された技術によると、要求から生成されたハッシュ値がゲートウェイのインデックスとして利用されるので、各端末から送信された同じ内容の要求（例えば、同じホストに対するコンテンツ取得要求）は、同じゲートウェイに送信される。

また、負荷分散装置が端末からの要求内容に基づいてハッシュ値を計算し、計算されたハッシュ値に基づいて要求の転送先となる適切なサーバ装置を選択する技術が提案されている（例えば、特許文献３）。特許文献３に記載された技術によると、負荷分散装置が、端末の要求内容に基づいて計算されたハッシュ値を用いて要求を転送するので、負荷分散装置は処理を各サーバ装置に分散することができる。

特開平１１−００４２６１号公報 特表２００２−５２３８３８号公報 特開２００４−０３０６９０号公報

特許文献３に記載された技術では、負荷分散装置がハッシュ値を計算しているので、負荷分散装置の処理量が増え、負荷分散装置がボトルネックとなる可能性がある。つまり、負荷分散装置を用いる方法では、負荷分散装置自体に負荷が集中し、負荷分散装置が単一障害点になる可能性がある。一方、特許文献１及び２に記載された技術は、負荷分散装置を必要としない。

しかしながら、特許文献１に記載された技術では、各端末が、要求の転送先情報（テーブル）を管理している。このため、担当するサーバ装置（Ｗｅｂサーバ）が変更された場合、テーブルの更新に要する負荷が大きい問題がある。また、端末に新たにテーブルの検索機能及び更新機能を追加しなければならない。したがって、既存のシステムへこの技術を導入するには高いコストを要する問題がある。

そして、特許文献２に記載された技術も、特許文献１に記載された技術と同様に、端末にテーブルの検索機能及び更新機能を追加しなければならない問題がある。なお、端末がハッシュ値を計算する場合も、端末側にハッシュ値を計算するための機能を追加しなければならない。

本発明は、前述した問題に鑑みてなされたものであり、ゲートウェイの前段に複雑な負荷分散装置を設置することなく、さらに、端末に複雑な機能を追加しないで、複数のゲートウェイに負荷を分散することができるゲートウェイシステムを提供することを目的とする。具体的には、本発明のゲートウェイシステムは、要求内容を識別する値、例えば、宛先ホスト名又はＵＲＬから生成されたハッシュ値に基づいて、ＩＰアドレスを生成し、コンテンツへのアクセスを各ゲートウェイに適切に分散する。

本発明の代表的な一例を示せば以下のとおりである。すなわち、複数の端末から複数の第１サーバ装置への要求を分散するゲートウェイシステムであって、前記ゲートウェイシステムは、複数の第２サーバ装置と、名前解決装置と、を備え、前記名前解決装置には、文字列からＩＰアドレスを生成するアドレス生成関数が配布され、前記各第２サーバ装置には、所定の複数のＩＰアドレスが登録され、前記名前解決装置は、前記端末から送信された、アクセス先のＵＲＬの名前解決のための第１要求を受信すると、前記受信した第１要求からアクセス先のＵＲＬを抽出し、前記アドレス生成関数を用いて、前記抽出されたＵＲＬのホスト名の文字列からＩＰアドレスを生成し、前記生成されたＩＰアドレスを、前記第１要求の回答として、前記端末に送信し、前記端末が、前記第１サーバ装置のＵＲＬをアクセス先とする第２要求を、前記第１要求の回答として送信されたＩＰアドレスが登録されている前記第２サーバ装置に送信すると、前記第２サーバ装置は、アクセス先のＵＲＬに基づいて、前記送信された第２要求を前記第１サーバ装置に転送することを特徴とする。

本発明の一実施形態によれば、ゲートウェイシステムは、名前解決装置が、ハッシュ値に基づいてサーバ装置のＩＰアドレスを生成するので、負荷分散装置を用いずに、均等に負荷を分散することができる。

本発明の第１の実施形態のゲートウェイシステムの構成を示す説明図である。 本発明の第１の実施形態の管理サーバが備えるアドレス割当テーブルの構成を示す説明図である。 本発明の第１の実施形態の管理サーバが備えるアドレス生成関数を示す説明図である。 本発明の第１の実施形態の管理サーバが備える対象ドメインネームテーブルの構成を示す説明図である。 本発明の第１の実施形態のＤＮＳプロキシの構成を示すブロック図である。 本発明の第１の実施形態のＤＮＳプロキシが実行する名前解決の処理を示すフローチャートである。 本発明の第１の実施形態のＷｅｂプロキシの構成を示すブロック図である。 本発明の第１の実施形態のＷｅｂプロキシが備える担当ＩＰアドレステーブルの構成を示す説明図である。 本発明の第１の実施形態のＷｅｂプロキシが備えるコンテンツテーブルの構成を示す説明図である。 本発明の第１の実施形態のＷｅｂプロキシが実行するコンテンツ取得の処理を示すフローチャートである。 本発明の第１の実施形態のゲートウェイシステムのコンテンツ取得の処理を示すシーケンスである。 本発明の第１の実施形態の割当変更要求のフォーマットを示す説明図である。 本発明の第１の実施形態のＷｅｂプロキシが実行する割当変更の処理を示すフローチャートである。 本発明の第１の実施形態のゲートウェイシステムの割当変更の処理を示すシーケンスである。 本発明の第２の実施形態のＵＲＬ変換ルールを示す説明図である。 本発明の第２の実施形態のＷｅｂプロキシが実行するコンテンツ取得の処理を示すフローチャートである。 本発明の第２の実施形態のゲートウェイシステムのコンテンツ取得の処理を示すシーケンスである。

本発明の概要は、以下のとおりである。

本発明のゲートウェイシステムは、複数のサーバ装置（Ｗｅｂプロキシ）、名前解決装置（ＤＮＳプロキシ）及び管理装置（管理サーバ）を備え、例えば、コンテンツのキャッシュシステムなどに適用される。なお、コンテンツをキャッシュするシステムに限らず、例えば、各サーバ装置の間の負荷を分散するシステムに適用されてもよい。

複数のＷｅｂプロキシには、担当するＩＰアドレスの範囲が割り当てられる。ＤＮＳプロキシは、アドレス生成関数を用いて、名前解決を実行する。具体的には、端末からの要求を受けると、要求の識別子（例えば、コンテンツ取得先のホスト名）からハッシュ値を計算し、計算されたハッシュ値に基づいて、ＩＰアドレスを生成し、生成されたＩＰアドレスを端末に返答する。

端末は、返答されたＩＰアドレスに基づいて、そのＩＰアドレスを担当するＷｅｂプロキシに要求を送信するので、ゲートウェイシステムは、負荷分散装置を必要とせずに、負荷を分散することができる。このように、端末は、ＤＮＳプロキシの処理を利用することによって、要求の送信先を取得することができる。このため、端末にはこのゲートウェイシステムを利用するための特別な機能を新たに追加する必要がない。また、管理サーバは、ＤＮＳプロキシが生成するすべてのＩＰアドレスを複数のＩＰアドレスの範囲に分割し、分割されたＩＰアドレスの範囲を各Ｗｅｂプロキシに割り当てる。このため、ＤＮＳプロキシは、各Ｗｅｂプロキシが担当するＩＰアドレスの範囲を示す情報（担当ＩＰアドレステーブル）を備える必要がない。

そして、端末は、コンテンツ取得先のホスト（Ｗｅｂサーバ）にアクセスする場合、ホスト名に対応するＩＰアドレスをＤＮＳプロキシに問い合わせる。ＤＮＳプロキシは、アドレス生成関数に基づいて生成されたＩＰアドレスを端末に返答する。端末は、そのＩＰアドレスを送信先として、コンテンツ取得要求などを送信する。この要求は、一般的なＩＰルーティングに従って、ゲートウェイのいずれかのＷｅｂプロキシに到達する。ゲートウェイの各Ｗｅｂプロキシは、担当するＩＰアドレスに対応するホストのコンテンツをキャッシュしている。

さらに、Ｗｅｂプロキシは、Ｗｅｂプロキシの機能を持ち、コンテンツ取得先のＵＲＬのホスト名以外の情報（パス名）を適切な負荷分散のための情報源として利用してもよい。

具体的には、Ｗｅｂプロキシは、端末からのコンテンツ取得要求を受けると、コンテンツ取得要求によって示されるコンテンツ取得先のＵＲＬ全体からハッシュ値を計算し、計算されたハッシュ値をホスト部のＳｕｆｉｘとしてＵＲＬに追加する。そして、Ｗｅｂプロキシは、ハッシュ値が追加されたＵＲＬを端末に返答する。

また、Ｗｅｂプロキシは、コンテンツ取得要求に基づいて、Ｗｅｂサーバからコンテンツを取得する。この場合、取得されたコンテンツにリンク先としてＵＲＬが含まれる場合、該ＵＲＬ全体からハッシュ値を計算し、計算されたハッシュ値を該ＵＲＬに追加する。そして、ハッシュ値が追加されたＵＲＬを、コンテンツ取得要求に対する回答として、端末に返答する。このように、要求に含まれる情報（コンテンツ取得先のＵＲＬ全体）からハッシュ値が生成されるので、例えば、同じＷｅｂサーバに対する要求（ホスト部が同じコンテンツ取得要求）を、ユーザ毎、コンテンツタイプ毎に異なるＷｅｂプロキシに分散することができる。

［実施形態１］
以下、本発明の第１の実施形態について図面を参照して説明する。

図１は、本発明の第１の実施形態のゲートウェイシステムの構成を示す説明図である。

本実施形態のゲートウェイシステムは、ＤＮＳプロキシ１０４、複数のＷｅｂプロキシ（Ｗｅｂプロキシ１＿１０５−１、Ｗｅｂプロキシ２＿１０５−２、・・・）及び管理サーバ１０８を備える。各装置は、ローカルネットワーク１０６を介して相互に接続される。

また、ＤＮＳプロキシ１０４及び複数のＷｅｂプロキシ（Ｗｅｂプロキシ１＿１０５−１ほか）は、広域ネットワーク１０３を介して、ＤＮＳサーバ１０１、複数のＷｅｂサーバ（Ｗｅｂサーバ１＿１０２−１、Ｗｅｂサーバ２＿１０２−２、・・・）に接続し、ローカルネットワーク１０６に接続された複数の端末（端末１０７＿１、端末２＿１０７−２、・・・）にサービスを提供する。例えば、端末１０７＿１からＷｅｂサーバ１＿１０２−１への要求メッセージ、及びＷｅｂサーバ１＿１０２−１から端末１０７＿１への返答メッセージは、いずれかのＷｅｂプロキシを経由して送受信される。

なお、複数のＷｅｂプロキシのいずれにも共通する説明をする場合、その説明において、複数のＷｅｂプロキシを総称して、Ｗｅｂプロキシ１０５と記載する。また、複数のＷｅｂサーバのいずれにも共通する説明をする場合、その説明において、複数のＷｅｂサーバを総称して、Ｗｅｂサーバ１０２と記載する。また、複数の端末のいずれにも共通する説明をする場合、その説明において、複数の端末を総称して、端末１０７と記載する。

なお、図１では、例として、１台のＤＮＳサーバ１０１、２台のＷｅｂサーバ１０２、４台のＷｅｂプロキシ１０５、及び２台の端末１０７が図示されているが、図示された台数以上の各装置が広域ネットワーク１０３又はローカルネットワーク１０６に接続されてもよい。

ＤＮＳサーバ１０１は、ＤＮＳプロトコルを用いて、通常の名前解決を実行する。Ｗｅｂサーバ１０２は、広域ネットワークに接続され、端末１０７の要求に応じて、コンテンツを提供する。ここで、コンテンツとは、例えば、動画、静止画、テキスト、音声などの情報である。

ＤＮＳプロキシ１０４は、端末１０７から送信された名前解決要求を受信すると、名前解決の処理を実行する。具体的には、名前解決要求によって示されるホスト名が管理サーバ１０８によって指定されたホスト名に該当する場合、ＤＮＳプロキシ１０４は、ＩＰアドレスを生成し、生成されたＩＰアドレスを、名前解決要求に対する回答として端末１０７に送信する。

なお、ここで、ホスト名とは、サーバ装置の名前を示す文字列であり、例えば、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｅｘ／１」のうち、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」の部分である。また、ここで、ＤＮＳプロキシ１０４が生成するＩＰアドレスとは、本実施形態のゲートウェイシステムにおいてのみ用いられるＩＰアドレスである。

具体的には、ＤＮＳプロキシ１０４は、あらかじめ配布されたアドレス生成関数を用いて、ホスト名からハッシュ値を計算し、計算されたハッシュ値に基づいてＩＰアドレスを生成する。アドレス生成関数の詳細については、図２Ｂを用いて後述する。また、ＤＮＳプロキシ１０４の構成については、図３を用いて後述する。

端末１０７は、送信されたＩＰアドレスに基づいて、コンテンツ取得要求を、該ＩＰアドレスを担当するＷｅｂプロキシ１０５に転送する。

なお、ホスト名が管理サーバ１０８によって指定されたホスト名に該当しない場合、ＤＮＳプロキシ１０４は、名前解決要求を、ＤＮＳサーバ１０１に転送する。ＤＮＳサーバは、ホスト名に対応するＷｅｂサーバ１０２の実際のＩＰアドレスを名前解決要求に対する回答として端末１０７に送信する。

Ｗｅｂプロキシ１０５は、端末１０７から送信されたコンテンツ取得要求に基づき、要求されたコンテンツをＷｅｂサーバ１０２から取得し、取得したコンテンツをキャッシュする。さらに、取得したコンテンツを端末１０７に送信する。Ｗｅｂプロキシ１０５には、管理サーバ１０８によって、あらかじめ担当するＩＰアドレスの範囲が割り当てられるので、コンテンツ取得要求は、ＩＰアドレスに従って担当のＷｅｂプロキシ１０５に送信される。なお、Ｗｅｂプロキシ１０５の構成については、図５を用いて後述する。

管理サーバ１０８は、各Ｗｅｂプロキシ１０５に割り当てられるＩＰアドレスを管理する。また、管理サーバ１０８は、ＤＮＳプロキシによってＩＰアドレスに変換されるホスト名を指定する。これによって、Ｗｅｂプロキシ１０５は、指定されたホスト名に対応するＷｅｂサーバ１０２のコンテンツのみをキャッシュする。

なお、管理サーバ１０８は、アドレス割当テーブル２００（図２Ａ参照）、アドレス生成関数２１０（図２Ｂ参照）及び対象ドメインネームテーブル２２０（図２Ｃ参照）を備える。

図２Ａは、本発明の第１の実施形態の管理サーバ１０８が備えるアドレス割当テーブル２００の構成を示す説明図である。

アドレス割当テーブル２００は、各Ｗｅｂプロキシ１０５に割り当てられるＩＰアドレスの範囲を示したテーブルであり、例えば、サーバＩＤ２０１、開始アドレス２０２及び終了アドレス２０３を含む。

サーバＩＤ２０１は、サーバ装置（Ｗｅｂプロキシ１０５）を識別するための識別子である。開始アドレス２０２は、サーバＩＤ２０１によって特定されるＷｅｂプロキシ１０５に割り当てられるアドレス範囲の開始アドレスである。終了アドレス２０３は、アドレス範囲の終了アドレスである。ここで、あるＷｅｂプロキシ１０５が担当するＩＰアドレス範囲は、他のＷｅｂプロキシ１０５が担当するＩＰアドレス範囲と重複しないのであれば、一の連続した範囲でなくてもよく、いくつかの範囲に分かれていてもよい。

なお、管理サーバ１０８は、自動設定によって、あらかじめ定められたアドレス範囲を等しく分割し、等しく分割された各アドレス範囲を各Ｗｅｂプロキシ１０５に割り当ててもよい。また、ゲートウェイシステムの負荷の状態に応じて、管理者が各Ｗｅｂプロキシ１０５に割り当てられるアドレス範囲を設定してもよい。

図２Ｂは、本発明の第１の実施形態の管理サーバ１０８が備えるアドレス生成関数２１０を示す説明図である。

アドレス生成関数２１０は、文字列などの可変長データＸからＩＰアドレスを生成するための関数であり、ハッシュ関数２１５を含む。アドレス生成関数２１０は、可変長データＸが入力されると、ハッシュ関数２１５によって、入力された可変長データＸを、例えば、６４ビットのハッシュ値に変換する。そして、所定の６４ｂｉｔのＩＰｖ６プレフィックスと変換された６４ビットのハッシュ値とを合わせることによって、ＩＰｖ６のＩＰアドレスを生成し、生成されたＩＰアドレスを出力する。

なお、ハッシュ関数には、例えば、ＳＨＡ１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）が用いられてもよい。また、ＳＨＡ１の他に、ＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ Ａｌｇｏｒｉｔｈｍ ５）などが用いられてもよい。

また、本実施形態では、アドレス生成関数２１０に入力される可変長データＸには、Ｗｅｂサーバ１０２のホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」など）が用いられる。

図２Ｃは、本発明の第１の実施形態の管理サーバ１０８が備える対象ドメインネームテーブル２２０の構成を示す説明図である。

対象ドメインネームテーブル２２０は、名前解決の処理において、名前解決要求によって示されるホスト名をＩＰアドレスに変換するか否かを判定するために用いられる。対象ドメインネームテーブル２２０は、例えば、ドメイン名（ホスト名）２２１及び変換対象２２２を含む。

ドメイン名（ホスト名）２２１は、端末１０７にコンテンツを提供するＷｅｂサーバ１０２のホスト名である。変換対象２２２には、ドメイン名２２１に示されたドメイン名（ホスト名）をＩＰアドレスに変換するか否かを示す情報が格納される。

ＤＮＳプロキシ１０４は、アドレス生成関数２１０及び対象ドメインネームテーブル２２０を用いて、名前解決の処理を実行する。なお、なお、ＤＮＳプロキシ１０４が実行する名前解決の処理については、図４を用いて後述する。

なお、管理サーバ１０８は、アドレス生成関数２１０及び対象ドメインネームテーブル２２０をＤＮＳプロキシ１０４に配布する。また、管理サーバ１０８は、アドレス生成関数２１０を各Ｗｅｂプロキシ１０５に配布する。また、管理サーバ１０８は、アドレス割当テーブル２００に基づいて、各Ｗｅｂプロキシ１０５が担当するＩＰアドレスの範囲を示す担当ＩＰアドレステーブル６００（図６Ａ参照）を作成し、作成された担当ＩＰアドレステーブル６００を各Ｗｅｂプロキシ１０５に配布する。

図３は、本発明の第１の実施形態のＤＮＳプロキシ１０４の構成を示すブロック図である。

ＤＮＳプロキシ１０４は、アドレス変換処理機能部３０１、メモリ３０２、及びネットワークインタフェース３０３を備え、広域ネットワーク１０３及びローカルネットワーク１０６に接続する。

メモリ３０２には、管理サーバ１０８から配布されたアドレス生成関数２１０及び対象ドメインネームテーブル２２０が格納される。

アドレス変換処理機能部３０１は、メモリ３０２に格納された対象ドメインネームテーブル２２０及びアドレス生成関数２１０を用いて、アドレス変換の処理などを実行する。アドレス変換処理機能部３０１が実行する処理の詳細については、図４を用いて後述する。なお、図示しないプロセッサは、メモリ３０２に格納された各種プログラムを実行することによって、アドレス変換処理機能部３０１の処理を実現する。

ネットワークインタフェース３０３は、ＤＮＳプロキシ１０４が広域ネットワーク１０３及びローカルネットワーク１０６に接続するためのインターフェースである。

図４は、本発明の第１の実施形態のＤＮＳプロキシ１０４が実行する名前解決の処理を示すフローチャートである。

まず、ＤＮＳプロキシ１０４のアドレス変換処理機能部３０１は、端末１０７から送信された名前解決要求（例えば、「ＡＡＡＡ？ ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）を受信する（Ｓ４０１）。次に、アドレス変換処理機能部３０１は、名前解決要求を受信すると、対象ドメインネームテーブル２２０を検索し、名前解決要求によって示されるホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）がＩＰアドレスに変換される対象であるか否かを判定する（Ｓ４０２）。

Ｓ４０２において、ホスト名が変換対象でないと判定された場合、ＤＮＳプロキシ１０４は、広域ネットワーク１０３を介して、端末１０７から送信された名前解決要求をＤＮＳサーバ１０１に転送する。

ドメインネームサービスを提供するＤＮＳサーバ１０１は、通常の名前解決を実行し、ホスト名に対応する実際のＩＰアドレスを、名前解決要求に対する回答として、要求者であるＤＮＳプロキシ１０４に送信する。そして、ＤＮＳプロキシ１０４は、ＤＮＳサーバ１０１から送信された名前解決要求に対する回答を受信して、ホスト名に対応する実際のＩＰアドレスを取得する（Ｓ４０３）。

一方、Ｓ４０２において、ホスト名が変換対象であると判定された場合、ＤＮＳプロキシ１０４のアドレス変換処理機能部３０１は、アドレス生成関数２１０を用い、名前解決要求によって示されるホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）からハッシュ値（例えば、「４１ｄｅ：３２９７：ｅｃ１８：５ｆａｅ」」）を計算し、所定のＩＰｖ６プレフィックス（例えば、「２００１：ｄｂ８：：」）と計算されたハッシュ値とを合わせて、ＩＰアドレス（例えば、「２００１：ｄｂ８：：４１ｄｅ：３２９７：ｅｃ１８：５ｆａｅ」）を生成する（Ｓ４０４）。ここで、生成されたＩＰアドレスは、本実施形態のゲートウェイシステムにおいて用いられるＩＰアドレスであり、Ｗｅｂサーバ１０２のコンテンツをキャッシュするＷｅｂプロキシ１０５に対応付けられる。

次に、アドレス変換処理機能部３０１は、ＤＮＳサーバ１０１から取得した実際のＩＰアドレス、又はアドレス生成関数２１０によって生成されたＩＰアドレスを、名前解決要求に対する回答（例えば、「ＡＡＡＡ ２００１：ｄｂ８：：４１ｄｅ：３２９７：ｅｃ１８：５ｆａｅ」）として、端末１０７に送信する（Ｓ４０５）。

図５は、本発明の第１の実施形態のＷｅｂプロキシ１０５の構成を示すブロック図である。

Ｗｅｂプロキシ１０５は、Ｗｅｂキャッシュ処理機能部５０１、メモリ５０２、及びネットワークインタフェース５０３を備え、広域ネットワーク１０３及びローカルネットワーク１０６に接続する。

メモリ５０２には、担当ＩＰアドレステーブル６００、及びコンテンツテーブル６１０が格納される。また、必要に応じて、アドレス生成関数２１０が格納されてもよい。

担当ＩＰアドレステーブル６００については、図６Ａを用いて後述する。コンテンツテーブル６１０については、図６Ｂを用いて後述する。アドレス生成関数２１０は、図２Ｂに示した関数と同じであり、管理サーバ１０８によって必要に応じて配布される。

Ｗｅｂキャッシュ処理機能部５０１は、メモリ５０２に格納されたアドレス生成関数２１０、担当ＩＰアドレステーブル６００、及びコンテンツテーブル６１０を用いて、端末１０７から送信されたコンテンツ取得要求に基づき、要求されたコンテンツをＷｅｂサーバ１０２から取得し、取得したコンテンツをキャッシュする。Ｗｅｂキャッシュ処理機能部５０１が実行する処理の詳細については、図７を用いて後述する。なお、図示しないプロセッサは、メモリ５０２に格納された各種プログラムを実行することによって、Ｗｅｂキャッシュ処理機能部５０１の処理を実現する。

ネットワークインタフェース５０３は、Ｗｅｂプロキシ１０５が広域ネットワーク１０３及びローカルネットワーク１０６に接続するためのインターフェースである。Ｗｅｂプロキシ１０５は、担当ＩＰアドレステーブル６００に設定されたＩＰアドレスを、自装置のＩＰアドレスとして、ネットワークインタフェース５０３に登録する。これによって、Ｗｅｂプロキシ１０５は、端末１０７から送信されたコンテンツ取得要求を受信することができる。

なお、本実施形態では、Ｗｅｂプロキシ１０５は、Ｗｅｂキャッシュ処理機能を備えるが、Ｗｅｂキャッシュ処理機能の代わりに、例えば、フィルタ機能、コンテンツ変換機能などを備えてもよい。これによって、本発明のゲートウェイシステムを、キャッシュシステムだけでなく、他のサービスを提供するシステムにも適用することもできる。

図６Ａは、本発明の第１の実施形態のＷｅｂプロキシ１０５が備える担当ＩＰアドレステーブル６００の構成を示す説明図である。

担当ＩＰアドレステーブル６００は、一つのＷｅｂプロキシ１０５が担当するＩＰアドレスの範囲を示すテーブルであり、開始アドレス６０１及び終了アドレス６０２を含む。

なお、担当ＩＰアドレステーブル６００は、管理サーバ１０８によって配布されてもよいし、管理サーバ１０８によって通知されたＩＰアドレスの範囲に基づいて、Ｗｅｂプロキシ１０５によって作成されてもよい。

Ｗｅｂプロキシ１０５は、当該Ｗｅｂプロキシが担当するすべてのＩＰアドレスをネットワークインタフェース５０３に登録し、登録されたＩＰアドレスを宛先とするコンテンツ取得要求を受信する。Ｗｅｂプロキシ１０５が実行するコンテンツ取得の処理については、図７を用いて後述する。

なお、Ｗｅｂプロキシ１０５は、担当するＩＰアドレスのアドレス解決要求を受信すると、自装置に設定されたＭＡＣアドレスを、端末１０７、近隣のルータなどに通知する。ここで、アドレス解決要求とは、例えば、ＩＰｖ４の場合はＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）であり、ＩＰｖ６の場合は近隣探索（ＮＤ：Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ）である。

図６Ｂは、本発明の第１の実施形態のＷｅｂプロキシが備えるコンテンツテーブル６１０の構成を示す説明図である。

コンテンツテーブル６１０は、Ｗｅｂプロキシ１０５がキャッシュしたコンテンツを格納するテーブルであり、例えば、ＵＲＬ６１１、宛先ＩＰアドレス６１２、コンテンツ６１３及びメタ情報６１４を含む。

ＵＲＬ６１１は、コンテンツ取得先のＵＲＬである。宛先ＩＰアドレス６１２は、コンテンツ取得要求によって示される宛先ＩＰアドレスであり、ＤＮＳプロキシ１０４によって、コンテンツ取得先であるＷｅｂサーバ１０２のホスト名から生成されたＩＰアドレスである。

コンテンツ６１３には、Ｗｅｂプロキシ１０５がＷｅｂサーバ１０２から取得したコンテンツが格納される。メタ情報６１４は、例えば、取得したコンテンツのサイズ、日時、保存期間などである。

図７は、本発明の第１の実施形態のＷｅｂプロキシが実行するコンテンツ取得の処理を示すフローチャートである。

まず、Ｗｅｂプロキシ１０５は、端末１０７から送信されたコンテンツ取得要求を受信する（Ｓ７０１）。次に、Ｗｅｂプロキシ１０５のＷｅｂキャッシュ処理機能部５０１は、コンテンツ取得先であるＷｅｂサーバ１０２のＵＲＬを検索キーとして、コンテンツテーブルを検索し（Ｓ７０２）、検索キーと一致するエントリがあるか否かを判定する（Ｓ７０３）。

Ｓ７０３において、検索キーと一致するエントリがあると判定された場合、要求されたコンテンツはキャッシュされているので、Ｗｅｂキャッシュ処理機能部５０１は、検索キーと一致するエントリのコンテンツ６１３に格納されたコンテンツを取得し、取得したコンテンツを含むコンテンツ取得要求に対する回答を作成する（Ｓ７０４）。

一方、Ｓ７０３において、検索キーと一致するエントリがないと判定された場合、要求されたコンテンツはキャッシュされていないので、Ｗｅｂキャッシュ処理機能部５０１は、当該コンテンツを格納するＷｅｂサーバ１０２（オリジンサーバ）に、端末１０７から送信されたコンテンツ取得要求を転送する（Ｓ７０５）。

なお、この場合、Ｗｅｂプロキシ１０５は、コンテンツ取得先のＷｅｂサーバ１０２のＩＰアドレスを取得するため、通常の名前解決を実行する。具体的には、Ｗｅｂプロキシ１０５は、名前解決要求をＤＮＳサーバ１０１に送信し、ＤＮＳサーバ１０１から、名前解決要求に対する回答として、コンテンツ取得先であるＷｅｂサーバ１０２のホスト名に対応する実際のＩＰアドレスを受信する。これによって、Ｗｅｂプロキシ１０５は、コンテンツ取得要求をＷｅｂサーバ１０２に転送することができる。

また、Ｗｅｂプロキシ１０５は、コンテンツテーブル６１０に新しいエントリを追加し、追加されたエントリのＵＲＬ６１１及び宛先ＩＰアドレス６１２に、それぞれ、端末１０７から送信されたコンテンツ取得要求によって示されるコンテンツ取得先のＵＲＬ及び宛先ＩＰアドレスを格納する。

次に、Ｗｅｂキャッシュ処理機能部５０１は、Ｗｅｂサーバ１０２から送信された、コンテンツ取得要求に対する回答を受信する（Ｓ７０６）。次に、Ｗｅｂキャッシュ処理機能部５０１は、コンテンツ取得要求に対する回答を受信すると、受信した回答からコンテンツを取得し、取得したコンテンツ及びコンテンツの情報を、それぞれ、コンテンツテーブル６１０に追加された新しいエントリのコンテンツ６１３及びメタ情報６１４に格納する。また、Ｗｅｂキャッシュ処理機能部５０１は、取得したコンテンツを含むコンテンツ取得要求に対する回答を作成する（Ｓ７０７）。

最後に、Ｗｅｂキャッシュ処理機能部５０１は、ステップＳ７０４又はＳ７０７において作成されたコンテンツ取得要求に対する回答を端末１０７に送信し（Ｓ７０８）、処理を終了する（Ｓ７０９）。

なお、本実施形態の別の例として、ゲートウェイシステムは、Ｗｅｂプロキシ１０５の前段に、アドレス変換装置を備えてもよい。この場合、管理サーバ１０８は、例えば、図２Ａに示したアドレス割当テーブル２００をアドレス変換装置に配布する。また、Ｗｅｂプロキシ１０５に設定された代表ＩＰアドレスをアドレス変換装置に通知する。

アドレス変換装置は、アドレス割当テーブル２００に記載されたサーバＩＤ（ＷｅｂプロキシのＩＤ）と、通知されたＷｅｂプロキシ１０５の代表ＩＰアドレスとが対応付けられたアドレス変換テーブルを備える。これによって、アドレス変換装置は、端末１０７から送信されたコンテンツ取得要求の宛先ＩＰアドレスを、ハッシュ値に基づいて生成されたＩＰアドレスから代表ＩＰアドレスに書き換え、代表ＩＰアドレスに対応するＷｅｂプロキシ１０５にコンテンツ取得要求を転送する。

なお、本実施形態の別の例では、Ｗｅｂプロキシ１０５は、ステップＳ７０７において、Ｗｅｂサーバ１０２からコンテンツを取得すると、管理サーバから１０８から配布されたアドレス生成関数２１０を用いて、Ｗｅｂサーバ１０２のホスト名からＩＰアドレスを生成し、生成されたＩＰアドレスをコンテンツテーブル６１０に追加された新しいエントリの宛先ＩＰアドレス６１２に格納する。

アドレス変換装置を備えるゲートウェイシステムは、大量のＩＰアドレスをＷｅｂプロキシ１０５に割り当てることがコスト的に困難な場合に利用されてもよい。このゲートウェイシステムは、レイヤ４の情報に基づいて負荷分散を実行するため、レイヤ７の情報に基づいて負荷分散を実行するゲートウェイシステムよりも、高速かつ安価に実現される。

以上の処理によってコンテンツテーブル６１０が作成されるので、各Ｗｅｂプロキシ１０５がキャッシュしているコンテンツが容易に特定される。作成されたコンテンツテーブル６１０は、後述する図１０及び図１１に示す割当変更処理でも使用される。移動元のＷｅｂプロキシ１０５は、コンテンツテーブル６１０のうち、移動したいコンテンツを含むエントリを移動先のＷｅｂプロキシ１０５に移動する。

図８は、本発明の第１の実施形態のゲートウェイシステムのコンテンツ取得の処理を示すシーケンスである。

図８に示す例では、Ｗｅｂサーバ１０２は、例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」のホスト名が付与されたサーバ装置である。

最初に、管理サーバ１０８は、ＤＮＳプロキシ１０４に、アドレス生成関数２１０及び対象ドメインネームテーブル２２０を配布する（Ｓ８０１）。また、Ｗｅｂプロキシ１０５−１及び１０５−２Ｗｅｂプロキシに、アドレス生成関数２１０及びアドレス割当テーブル２００（又は担当ＩＰアドレステーブル６００）を配布する（Ｓ８０２、Ｓ８０３）。

次に、各Ｗｅｂプロキシ１０５は、担当ＩＰアドレステーブル６００を受け取ると、担当ＩＰアドレステーブル６００に含まれるすべてのＩＰアドレスを自装置に割り当てられたＩＰアドレスとして、ネットワークインタフェース５０３に登録する（Ｓ８０４、Ｓ８０５）。

次に、端末１０７は、例えば、ユーザによって入力されたＵＲＬ（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｅｘ／１」）を受ける（Ｓ８０６）と、このＵＲＬにアクセスしてコンテンツを取得するためのコンテンツ取得要求を送信する。この場合、端末１０７は、まず、ホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）に対応するＩＰアドレスを取得するために、ＤＮＳプロキシ１０４に名前解決要求（例えば、「ＡＡＡＡ？ ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）を送信する（Ｓ８０７）。

ＤＮＳプロキシ１０４は、端末１０７から送信された名前解決要求を受信すると、対象ドメインネームテーブル２２０を参照して、受信した名前解決要求によって示されるホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）が変換対象である否かを判定する。そして、当該ホスト名が変換対象であると判定された場合、ＤＮＳプロキシ１０４は、配布されたアドレス生成関数２１０を用いて、当該ホスト名からＩＰアドレスを生成する（Ｓ８０８）。

次に、ＤＮＳプロキシ１０４は、例えば、生成されたＩＰアドレス（例えば、「２００１：ｄｂ８：：４１ｄｅ：３２９７：ｅｃ１８：５ｆａｅ」）を、名前解決要求に対する回答として、端末１０７に送信する（Ｓ８０９）。

次に、端末１０７は、名前解決要求に対する回答を受信すると、受信した回答から当該ホスト名に対応するＩＰアドレスを取得し、取得したＩＰアドレスをコンテンツ取得要求の宛先アドレスに設定した後、コンテンツ取得要求を送信する（Ｓ８１２）。なお、ここで、ＴＣＰコネクションが確立される。

具体的には、コンテンツ取得要求は、ＩＰパケットとして、経路上のＩＰルータなどでルーティングされ、宛先ＩＰアドレスに従い、当該ＩＰアドレスを担当するいずれかのＷｅｂプロキシ１０５に送信される。この場合、経路上のＩＰルータ、端末１０７などは、当該ＩＰアドレスが登録された装置を探索するため、通常のアドレス解決（ＡＲＰ、ＮＤなど）を実行する（Ｓ８１０）。そして、自宛のアドレス解決要求を受信した装置（例えば、Ｗｅｂプロキシ１＿１０５−１）は、要求者（経路上のＩＰルータ、端末１０７など）に自装置のＭＡＣアドレスを通知する（Ｓ８１１）。これによって、例えば、端末１０７とＷｅｂプロキシ１＿１０５−１との間にＴＣＰコネクションが確立され、Ｗｅｂプロキシ１＿１０５−１は、当該ＩＰアドレスを宛先とするコンテンツ取得要求を受信することができる。

次に、Ｗｅｂプロキシ１＿１０５−１は、端末１０７からコンテンツ取得要求を受信すると、コンテンツ取得要求（例えば、「ＧＥＴ ／ｅｘ／１ ＨＴＴＰ／１．０ Ｈｏｓｔ： ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ・・・」）から、コンテンツ取得先のＵＲＬ（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｅｘ／１」）を取得する（Ｓ８１２）。

そして、Ｗｅｂプロキシ１＿１０５−１は、取得したＵＲＬを検索キーとして、コンテンツテーブル６１０を検索し、要求されたコンテンツがキャッシュされているか否かを判定する。ここで、例えば、要求されたコンテンツがキャッシュされていないと判定される（Ｓ８１３）と、Ｗｅｂプロキシ１＿１０５−１は、コンテンツを格納しているＷｅｂサーバ１０２に、端末１０７から送信されたコンテンツ取得要求を転送する（Ｓ８１４）。

Ｗｅｂサーバ１０２は、コンテンツ取得要求を受信すると、要求されたコンテンツを含むコンテンツ取得要求に対する回答をＷｅｂプロキシ１＿１０５−１に送信する（Ｓ８１５）。

Ｗｅｂプロキシ１＿１０５−１は、コンテンツ取得要求に対する回答を受信すると、受信した回答からコンテンツを取得し、取得したコンテンツをキャッシュし（Ｓ８１６）、当該コンテンツを、コンテンツ取得要求に対する回答として、端末１０７に送信する（Ｓ８１７）。

以上の処理によって、各Ｗｅｂプロキシ１０５は、担当するＩＰアドレスに対応付けられたホスト名を持つＷｅｂサーバ１０２のコンテンツをキャッシュすることができる。つまり、本実施形態のゲートウェイシステムでは、同じホスト名に属するコンテンツは、同じＷｅｂプロキシにキャッシュされることが保証される。これは、ハッシュ関数に基づいてホスト名から生成されたＩＰアドレスが、Ｗｅｂプロキシ１０５のいずれか一つに対応付けられているためである。

以下に、本実施形態のＷｅｂプロキシ１０５の担当ＩＰアドレスの範囲を変更する処理について説明する。管理サーバ１０８は、例えば、Ｗｅｂプロキシ１０５のうちの何台かを計画的に停止する場合、及び負荷に偏りが生じた場合、各Ｗｅｂプロキシ１０５の担当ＩＰアドレスの範囲を変更することができる。

図９は、本発明の第１の実施形態の割当変更要求のフォーマットを示す説明図である。

割当変更要求９００は、移動元ＷｅｂプロキシのＩＰアドレス９０１、移動先ＷｅｂプロキシのＩＰアドレス９０２、移動対象となるＩＰアドレスの範囲９０３を含む。

管理サーバ１０８は、各Ｗｅｂプロキシ１０５が担当するＩＰアドレスの範囲を変更する場合、割当変更要求９００をすべてのＷｅｂプロキシ１０５、又は移動元及び移動先のＷｅｂプロキシ１０５に送信する。

図１０は、本発明の第１の実施形態のＷｅｂプロキシ１０５が実行する割当変更の処理を示すフローチャートである。

あるＷｅｂプロキシ１０５は、管理サーバ１０８から送信された割当変更要求９００を受信する（Ｓ１００１）と、受信した割当変更要求９００に含まれる移動元ＷｅｂプロキシのＩＰアドレス９０１及び移動先ＷｅｂプロキシのＩＰアドレス９０２のいずれかと、自装置に付与されたＩＰアドレスとが一致するか否かを判定する（Ｓ１００２）。

ステップＳ１００２において、移動元のＷｅｂプロキシのＩＰアドレス９０１と自装置のＩＰアドレスとが一致すると判定された場合、割当変更要求９００を受信したＷｅｂプロキシ１０５は移動元のＷｅｂプロキシであるので、移動元のＷｅｂプロキシは、コンテンツテーブル６１０から、移動対象となるＩＰアドレスの範囲９０３によって指定されたＩＰアドレスに対応するエントリを抽出する（Ｓ１００３）。

そして、移動元のＷｅｂプロキシは、抽出されたエントリを、移動先ＷｅｂプロキシのＩＰアドレス９０２によって指定された移動先のＷｅｂプロキシのコンテンツテーブルに移動する（Ｓ１００４）。

なお、この場合、移動元のＷｅｂプロキシは、必要に応じて、例えば、抽出されたエントリのコンテンツ６１３及びメタ情報６１４のデータを消去し、ＵＲＬ６１１及び宛先ＩＰアドレス６１２のデータのみのエントリを移動先のＷｅｂプロキシに送信してもよい。これによって、割当項要求の処理における各Ｗｅｂプロキシ１０５の間のトラフィックを削減することができる。

次に、移動元のＷｅｂプロキシは、移動対象となるＩＰアドレスの範囲９０３によって指定されたＩＰアドレスに対応するエントリをコンテンツテーブル６１０から削除する（Ｓ１００５）。さらに、移動対象となるＩＰアドレスの範囲９０３によって指定されたＩＰアドレスの範囲を担当ＩＰアドレステーブル６００から削除し、ネットワークインタフェース５０３に登録された当該ＩＰアドレスを削除する（Ｓ１００６）。

一方、ステップＳ１００２において、移動先のＷｅｂプロキシのＩＰアドレス９０２と自装置のＩＰアドレスとが一致すると判定された場合、割当変更要求９００を受信したＷｅｂプロキシ１０５は移動先のＷｅｂプロキシであるので、移動先のＷｅｂプロキシは、移動元のＷｅｂプロキシから送信された移動対象のエントリの受信を待ち受ける（Ｓ１００７）。

移動先のＷｅｂプロキシは、移動対象のエントリを受信すると、受信したエントリをコンテンツテーブル６１０に追加する（Ｓ１００８）。また、移動先のＷｅｂプロキシは、移動対象となるＩＰアドレスの範囲９０３によって指定されたＩＰアドレスを、担当ＩＰアドレステーブル６００に追加する（Ｓ１００９）。また、新たに追加されたＩＰアドレスをネットワークインタフェース５０３に登録する。

さらに、移動先のＷｅｂプロキシは、近隣広告パケット又はＧｒａｔｕｉｔｏｕｓ ＡＲＰを送信する（Ｓ１０１０）。これによって、移動先のＷｅｂプロキシは、新しいアドレスが割り当てられたことを、近隣のＩＰルータ、端末１０７、Ｗｅｂプロキシ１０５、管理サーバ１０８などに通知することができる。なお、近隣のＩＰルータ、端末１０７などは、近隣広告パケット又はＧｒａｔｕｉｔｏｕｓ ＡＲＰを受信すると、再度、アドレス解決要求を送信して、新しくＩＰアドレスが登録されたネットワークインタフェースのＭＡＣアドレスを取得する。

一方、ステップＳ１００２において、移動元ＷｅｂプロキシのＩＰアドレス９０１及び移動先ＷｅｂプロキシのＩＰアドレス９０２のいずれとも、自装置のＩＰアドレスに一致しないと判定された場合、その割当変更要求は自装置に送信されたメッセージではないので、Ｗｅｂプロキシ１０５は、そのメッセージを廃棄する（Ｓ１０１１）。これによって、例えば、割当変更要求をマルチキャストによって、すべてのＷｅｂプロキシ１０５に送信した場合であっても、移動元及び移動先のＷｅｂプロキシは、送信された割当変更要求を正しく受信することができる。

図１１は、本発明の第１の実施形態のゲートウェイシステムの割当変更の処理を示すシーケンスである。

Ｗｅｂプロキシ１＿１０５−１は、初期設定では、例えば、ＩＰアドレス「２００１：ｄｂ８：：４０００：００００：００００：００００」から「２００１：ｄｂ８：：４ｆｆｆ：ｆｆｆｆ：ｆｆｆｆ：ｆｆｆｆ」の範囲が割り当てられ、割り当てられたＩＰアドレスに対応するコンテンツをキャッシュする（Ｓ１１０１）。

また、Ｗｅｂプロキシ２＿１０５−２は、例えば、ＩＰアドレス「２００１：ｄｂ８：：２０００：００００：００００：００００」から「２００１：ｄｂ８：：３ｆｆｆ：ｆｆｆｆ：ｆｆｆｆ：ｆｆｆｆ」の範囲が割り当てられ、割り当てられたＩＰアドレスに対応するコンテンツをキャッシュする（Ｓ１１０２）。

次に、管理サーバ１０８は、例えば、Ｗｅｂプロキシ１＿１０５−１が担当している「２００１：ｄｂ８：：４０００：００００：００００：００００」から「２００１：ｄｂ８：：４ｆｆｆ：ｆｆｆｆ：ｆｆｆｆ：ｆｆｆｆ」の範囲に対応するコンテンツをＷｅｂプロキシ２＿１０５−２に移動する指示をそれぞれのＷｅｂプロキシに送信する（Ｓ１１０３）。

Ｗｅｂプロキシ１＿１０５−１は、管理サーバ１０８からコンテンツを移動する指示を受信すると、コンテンツテーブル６１０から、指示されたＩＰアドレスの範囲に対応するエントリを抽出し、抽出されたエントリを移動先のＷｅｂプロキシ２＿１０５−２に転送する（Ｓ１１０４）。また、当該エントリをコンテンツテーブル６１０から削除する。そして、担当ＩＰアドレステーブル６００から、指示されたＩＰアドレスを削除し、また、ネットワークインタフェース５０３から、指示されたＩＰアドレスを削除する（Ｓ１１０５）。

一方、Ｗｅｂプロキシ２＿１０５−２は、移動元のＷｅｂプロキシ１＿１０５−１から移動されたエントリをコンテンツテーブル６１０に追加する。そして、指示されたＩＰアドレスの範囲を担当ＩＰアドレステーブル６００に追加し、また、追加されたＩＰアドレスの範囲をネットワークインタフェース５０３に登録する（Ｓ１１０６）。

次に、Ｗｅｂプロキシ２＿１０５−２は、近隣広告パケット近又はＧｒａｔｕｉｔｏｕｓ ＡＲＰを送信することによって、担当するＩＰアドレスの範囲が変更されたことを、近隣の端末１０７、ＩＰルータ、Ｗｅｂプロキシ１０５などに通知する（Ｓ１１０７）。これは、近隣の端末１０７、ＩＰルータなどが、近隣広告パケット近又はＧｒａｔｕｉｔｏｕｓ ＡＲＰによって示されるＩＰアドレス宛てに、再度、アドレス解決要求を送信し、当該ＩＰアドレスに対応するＭＡＣアドレスを取得するためである。

以降、ステップＳ１１０８からＳ１１１６の処理は、図８に示したＳ８０６からＳ８１７の処理と同じである。

以上説明したように、第１の実施形態によれば、ゲートウェイシステムは、ハッシュによって生成されたＩＰアドレスに従って、端末からＷｅｂサーバへのコンテンツ取得要求を適切なＷｅｂプロキシに転送するので、均等な負荷分散を実現することができる。また、スケーラブルな収容能力の拡張が可能となる。さらに、負荷分散装置が不要になるので、ゲートウェイシステムの管理コストを削減し、耐障害性を強化することができる。

また、各Ｗｅｂプロキシの負荷に偏りが生じ、各Ｗｅｂプロキシが担当するＩＰアドレスの範囲を変更する場合（言い換えると、キャッシュされたコンテンツを移動する場合）、ゲートウェイシステムは、各Ｗｅｂプロキシの間のみで情報を交換し、Ｗｅｂプロキシと、ＤＮＳプロキシ及び端末などの他装置との間では情報を交換しない。このため、ＩＰアドレスの割当変更に要する処理を軽減することができる。

また、名前解決を実行するＤＮＳプロキシは、Ｗｅｂプロキシの状態を管理しない。このため、ＤＮＳプロキシを容易に冗長化することができ、ゲートウェイシステムの高速化及び高信頼化を実現できる。

また、端末はＤＮＳプロキシが提供する名前解決を利用して、Ｗｅｂプロキシにアクセルするので、端末には、Ｗｅｂプロキシにアクセスするための機能を追加する必要がない。このため、大量の既存端末が存在する環境においても、本実施形態のゲートウェイシステムを容易に導入することができる。

［実施形態２］
第２の実施形態のゲートウェイシステムの構成は、図１に示した第１の実施形態のゲートウェイシステムの構成と同じである。第２の実施形態のＤＮＳプロキシの構成は、図３に示した第１の実施形態のＤＮＳプロキシの構成と同じである。また、第２の実施形態のＷｅｂプロキシの構成は、図５に示した第１の実施形態のＷｅｂプロキシの構成と同じである。

ただし、第２の実施形態のＤＮＳプロキシのアドレス変換処理機能部の処理は、第１の実施形態のアドレス変換処理機能部の処理と一部異なる（図１４のＳ１４０４、Ｓ１４１２）。また、第２の実施形態のＷｅｂプロキシのＷｅｂキャッシュ処理機能部の処理は、第１の実施形態のＷｅｂキャッシュ処理機能部の処理と一部異なる（図１４のＳ１４０２）。

第１の実施形態のゲートウェイシステムでは、ＤＮＳプロキシ１０４が、コンテンツ取得先のホスト名からハッシュ値を計算し、計算されたハッシュ値を用いてＩＰアドレスを生成した。このため、端末１０７から送信されたコンテンツ取得要求は、ホスト名の単位で分散される。

したがって、第１の実施形態のゲートウェイシステムでは、ある一つのＷｅｂサーバ１０２（ホスト）へのアクセス要求は、ある一つのＷｅｂプロキシ１０５が受けるので、そのＷｅｂサーバ１０２へのアクセスが集中した場合、担当するＷｅｂプロキシ１０５の負荷が大きくなり、各Ｗｅｂプロキシ１０５の間の負荷の偏りが生じる可能性がある。

そこで、第２の実施形態のゲートウェイシステムでは、Ｗｅｂプロキシ１０５が、コンテンツ取得先のＵＲＬ全体からハッシュ値を計算し、計算されたハッシュ値をホスト名のＳｕｆｆｉｘｔとして埋め込んだＵＲＬを、コンテンツ取得先のＵＲＬとして、端末１０７に返答する。

ＤＮＳプロキシ１０４は、端末１０７から名前解決要求を受けると、ハッシュ値を含むホスト名から、担当するＷｅｂプロキシ１０５のＩＰアドレスを生成する。したがって、第２の実施形態では、ＵＲＬ全体から生成されたハッシュ値に基づいて、各Ｗｅｂプロキシ１０５にコンテンツ取得要求が分散される。

つまり、第２の実施形態では、同じホスト名に属するコンテンツであっても、複数のＷｅｂプロキシ１０５にキャッシュされるので、一のＷｅｂプロキシ１０５に負荷が集中することを避けることができる。

なお、第２実施形態は、第１の実施形態と合わせて、キャッシュシステムなどに適用されてもよい。

以下に、第２の実施形態におけるＵＲＬ変換ルールについて説明する。

図１２は、本発明の第２の実施形態のＵＲＬ変換ルールを示す説明図である。

本実施形態では、Ｗｅｂプロキシ１０５が、メモリ５０２に格納されたアドレス生成関数２１０（ハッシュ関数２１５）を用いて、例えば、端末１０７から送信されたコンテンツ取得要求によって示される、ホスト名及びパス名を含むＵＲＬ１２０１（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｅｘ／２．ｈｔｍｌ」）から、ハッシュ値１２０４（例えば、「８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ」）を生成する。

そして、Ｗｅｂプロキシ１０５は、ＵＲＬのホスト名までの部分１２０２（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）と、ピリオド（．）１２０５と、ハッシュ値１２０４（例えば、「８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ」）と、ホスト名のＳｕｆｆｉｘ１２０６（例えば、「．ｈａｓｈ．ｖａｌｕｅ」）と、ＵＲＬのホスト名以降の部分１２０３（例えば、「／ｅｘ／４．ｈｔｍｌ」）とを合わせる。これによって、ハッシュ値が埋め込まれたＵＲＬ１２０７（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ／ｅｘ／２．ｈｔｍｌ」）が生成される。

図１３は、本発明の第２の実施形態のＷｅｂプロキシ１０５が実行するコンテンツ取得の処理を示すフローチャートである。

あるＷｅｂプロキシ１０５は、端末１０７から送信されたコンテンツ取得要求を受信すると（Ｓ１３０１）、受信したコンテンツ取得要求のパケットのヘッダからコンテンツ取得先のホスト名を取得する（Ｓ１３０２）。次に、Ｗｅｂプロキシ１０５は、取得されたホスト名に、図１２に示したＵＲＬ変換ルールに基づいて変換されたＵＲＬであることを示すホスト名のＳｕｆｆｉｘ１２０６（例えば、「．ｈａｓｈ．ｖａｌｕｅ」）（又は、ハッシュ値１２０４）が含まれているか否かを判定する（Ｓ１３０３）。

ステップＳ１３０３において、取得されたホスト名に、「．ｈａｓｈ．ｖａｌｕｅ」が含まれていないと判定された場合、受信したコンテンツ取得要求に含まれるＵＲＬは、図１２に示したＵＲＬ変換ルールに基づいて変換されたＵＲＬではないので、Ｗｅｂプロキシ１０５は、受信したコンテンツ取得要求のパケットのヘッダからＵＲＬを取得し、ＵＲＬ変換ルールに基づいて、ハッシュ関数２１５を用いて、取得されたＵＲＬをハッシュ値を含むＵＲＬに変換する（Ｓ１３０４）。

次に、Ｗｅｂプロキシ１０５は、コード３０２のＨＴＴＰ応答を端末１０７に返答する（Ｓ１３０５）。ここで、コード３０２のＨＴＴＰ応答とは、Ｗｅｂプロキシ１０５が、端末１０７に、ＵＲＬ変換ルールに基づいて変換されたＵＲＬにコンテンツ取得要求を再送させるための指示である。端末１０７は、コード３０２のＨＴＴＰ応答を受信すると、受信したＨＴＴＰ応答によって示される、ハッシュ値を含むＵＲＬに、コンテンツ取得要求を再送する。

一方、ステップＳ１３０３において、取得されたホスト名に、「．ｈａｓｈ．ｖａｌｕｅ」が含まれていると判定された場合、受信したコンテンツ取得要求に含まれるＵＲＬは既にＵＲＬ変換されているので、Ｗｅｂプロキシ１０５は、受信したコンテンツ取得要求のパケットのヘッダから取得されたＵＲＬのホスト部から、ハッシュ値１２０４及びホスト名のＳｕｆｆｉｘ１２０６（「．ｈａｓｈ．ｖａｌｕｅ」）の文字列を削除し、ＵＲＬ変換前のＵＲＬを復元する（Ｓ１３０６）。

次に、Ｗｅｂプロキシ１０５は、復元されたＵＲＬを検索キーとして、コンテンツテーブル６１０のエントリを検索し（Ｓ１３０７）、検索キーと一致するエントリがあるか否かを（Ｓ１３０８）。

ステップＳ１３０８において、検索キーと一致するエントリがあると判定された場合、端末１０７から要求されたコンテンツがキャッシュされているので、Ｗｅｂプロキシ１０５は、そのエントリに格納されているコンテンツを用いて、コンテンツ取得要求に対する回答を作成する（Ｓ１３０９）。

一方、ステップＳ１３０８において、検索キーと一致するエントリがないと判定された場合、端末１０７から要求されたコンテンツがキャッシュされていないので、Ｗｅｂプロキシ１０５は、コンテンツ取得要求をＷｅｂサーバ１０２（オリジンサーバ）に転送する（Ｓ１３１０）。この場合、Ｗｅｂプロキシ１０５は、コンテンツテーブル６１０に新しいエントリを追加し、追加されたエントリのＵＲＬ６１１及び宛先ＩＰアドレス６１２に、各々、復元されたＵＲＬ及びＩＰアドレスを格納する。

次に、Ｗｅｂプロキシ１０５は、Ｗｅｂサーバ１０２からコンテンツ取得要求に対する回答を受信し、受信した回答に含まれるコンテンツを取得する（Ｓ１３１１）。次に、取得されたコンテンツにリンク先のＵＲＬが含まれている場合、Ｗｅｂプロキシ１０５は、図１２に示したＵＲＬ変換ルールに基づいて、リンク先のＵＲＬを、ハッシュ値を含むＵＲＬに変換する（Ｓ１３１２）。また、変換されたＵＲＬを含むコンテンツを用いて、コンテンツ取得要求に対する回答を作成する。

次に、Ｗｅｂプロキシ１０５は、取得したコンテンツ、及びリンク先のハッシュ値を含むＵＲＬを、コンテンツテーブル６１０の対応するエントリのコンテンツ６１３に格納する（Ｓ１３１３）。

そして、最後に、Ｗｅｂプロキシ１０５は、コンテンツ取得要求に対する回答を端末１０７に送信し（Ｓ１３１４）、処理を終了する（Ｓ１３１５）。

図１４は、本発明の第２の実施形態のゲートウェイシステムのコンテンツ取得の処理を示すシーケンスである。

まず、端末１０７は、コンテンツ取得要求（例えば、「ＧＥＴ／ｅｘ／２ ＨＴＴＰ／１．０ Ｈｏｓｔ： ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ・・・」）を、例えば、Ｗｅｂプロキシ１＿１０５−１に送信する（Ｓ１４０１）。

なお、端末１０７は、ステップＳ１４０１の前に、図８に示したステップＳ８０７によって、名前解決要求（例えば、「ＡＡＡＡ？ ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」）をＤＮＳプロキシ１０４に送信してもよい。ＤＮＳプロキシ１０４は、図８に示したステップＳ８０８及び８０９によって、名前解決要求を実行してもよい。これによって、第１の実施形態と同様に、コンテンツ取得要求は、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ」に対応するＩＰアドレス（例えば、「２００１：ｄｂ８：：４１ｄｅ：３２９７：ｅｃ１８：５ｆａｅ」）を担当するＷｅｂプロキシ１＿１０５−１に到達する。

次に、Ｗｅｂプロキシ１＿１０５−１は、端末１０７から送信されたコンテンツ取得要求を受信すると、受信したコンテンツ取得要求のヘッダからコンテンツ取得先のＵＲＬを取得し、図１２に示したＵＲＬ変換ルールに基づいて、取得されたＵＲＬを、ハッシュ値を含むＵＲＬ、例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ／ｅｘ／２」に変換する（Ｓ１４０２）。そして、Ｗｅｂプロキシ１＿１０５−１は、コード３０２のＨＴＴＰ返答を端末１０７に送信する（Ｓ１４０３）。

次に、名前解決及びアドレス解決の処理が実行される（Ｓ１４０４）。

具体的には、端末１０７は、コード３０２のＨＴＴＰ返答を受信すると、ハッシュ値を含むホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ」）に対応するＩＰアドレスを取得するために、再度、ＤＮＳプロキシ１０４に名前解決要求を送信する（Ｓ１４０４）。

ここで、ＤＮＳプロキシ１０４は、第１の実施形態の処理とは異なり、ハッシュ値を含むホスト名（例えば、「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ」）から、ハッシュ値（例えば、「８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ」）のみを抽出してもよい。そして、アドレス生成関数２１０で用いられるＩＰｖ６プレフィックスと、抽出されたハッシュ値とを合わせて、ＩＰアドレスを生成してもよい。

なお、ＤＮＳプロキシ１０４は、第１の実施形態と同様に、アドレス生成関数２１０を用いて、ハッシュ値を含むホスト名（「ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ」）から、新しいハッシュ値を計算し、計算されたハッシュ値に基づいてＩＰアドレスを生成してもよい。

さらに、端末１０７又は近隣のルータは、生成されたＩＰアドレスが登録された装置を特定するため、アドレス解決要求を送信し、生成されたＩＰアドレスを担当するＷｅｂプロキシ１０５のＭＡＣアドレスを取得する。

次に、端末１０７は、生成されたＩＰアドレスを担当する、例えば、Ｗｅｂプロキシ２＿１０５−２に、コンテンツ取得要求（例えば、「ＧＥＴ／ｅｘ／２ ＨＴＴＰ／１．０
Ｈｏｓｔ：ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ・・・」）を送信する（Ｓ１４０５）。

次に、Ｗｅｂプロキシ２＿１０５−２は、受信したコンテンツ取得要求のヘッダからハッシュ値を含むＵＲＬを取得し、取得されたハッシュ値を含むＵＲＬ（例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ．８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ．ｈａｓｈ．ｖａｌｕｅ／ｅｘ／２」）から、ハッシュ値（例えば、「８２０ｄ９２ｄｃｂ０８ｅｄｃｄｄ」）及びホスト名のＳｕｆｆｉｘ（例えば、「．ｈａｓｈ．ｖａｌｕｅ」）を削除する。これによって、変換前のＵＲＬ（Ｓ１４０１で要求されたコンテンツ取得先のＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｏｒｇ／ｅｘ／２」）が取得される。次に、Ｗｅｂプロキシ２＿１０５−２は、取得した変換前のＵＲＬを検索キーとして、コンテンツテーブル６１０を検索し、検索キーのＵＲＬに対応するコンテンツがキャッシュされているか否かを判定する（Ｓ１４０６）。ここで、対応するコンテンツがキャッシュされていないとすると、Ｗｅｂプロキシ２＿１０５−２は、Ｗｅｂサーバ１０２にコンテンツ取得要求を転送する（Ｓ１４０７）。

そして、Ｗｅｂプロキシ２＿１０５−２は、Ｗｅｂサーバ１０２からコンテンツ取得要求に対する回答を受信する（Ｓ１４０８）。次に、Ｗｅｂプロキシ２＿１０５−２は、受信した回答に含まれるコンテンツを取得し、取得したコンテンツをコンテンツテーブル６１０のエントリに格納する（Ｓ１４０９）。ここで、取得したコンテンツにリンク先のＵＲＬが含まれている場合、Ｗｅｂプロキシ２＿１０５−２は、図１２に示したＵＲＬ変換ルールに基づいて、コンテンツに含まれるＵＲＬを変換し、変換されたＵＲＬもコンテンツテーブル６１０のエントリに格納する（Ｓ１４０９）。

つまり、Ｗｅｂプロキシは、ＵＲＬ変換ルールに基づいて、端末１０７に送信されるコンテンツに含まれるＵＲＬをあらかじめハッシュ値を含むＵＲＬに変換する。これは、端末１０７があるコンテンツにアクセスする場合、「．ｈａｓｈ．ｖａｌｕｅ」を含まないコンテンツ取得要求と「．ｈａｓｈ．ｖａｌｕｅ」を含むコンテンツ取得要求との２つの要求が発生するのを回避するためである。

次に、Ｗｅｂプロキシ２＿１０５−２は、取得したコンテンツ及びコンテンツのリンク先のハッシュ値を含むＵＲＬを、コンテンツ取得要求に対する回答として、端末１０７に送信する（Ｓ１４１０）。

なお、送信されたコンテンツのリンク先のＵＲＬがユーザによってクリックされた場合、そのリンク先のＵＲＬには、既にハッシュ値が埋め込まれているので、ステップＳ１４０１からＳ１４０４の処理は省略される。

以上説明したように、第２の実施形態によれば、ホスト単位よりも下位のパス単位で、キャッシュされるコンテンツが各Ｗｅｂプロキシに分散されるので、ゲートウェイシステムは、さらに効率的な負荷分散を実現することができる。

１０１ ＤＮＳサーバ
１０２ Ｗｅｂサーバ
１０３ 広域ネットワーク
１０４ ＤＮＳプロキシ
１０５ Ｗｅｂプロキシ
１０６ ローカルネットワーク
１０７ 端末
１０８ 管理サーバ
２００ アドレス割当テーブル
２１０ アドレス生成関数
２１５ ハッシュ関数
２２０ 対象ドメインネームテーブル
６００ 担当ＩＰアドレステーブル
６１０ コンテンツテーブル
９００ 割当変更要求
１２０１ ＵＲＬ
１２０７ ハッシュ値が埋め込まれたＵＲＬ

Claims (10)

1. 複数の端末から複数の第１サーバ装置への要求を分散するゲートウェイシステムであって、
   前記ゲートウェイシステムは、管理装置と、複数の第２サーバ装置と、名前解決装置と、を備え、
   前記管理装置は、
   文字列からＩＰアドレスを生成するアドレス生成関数を、前記名前解決装置に配布し、
   前記名前解決装置において前記アドレス生成関数によって生成されるすべての前記ＩＰアドレスを複数のＩＰアドレスに分割し、
   前記分割された複数のＩＰアドレスを、各々前記第２サーバ装置に配布し、
   前記第２サーバ装置は、
   前記管理装置から配布された複数のＩＰアドレスを登録し、
   前記名前解決装置は、
   前記端末から送信された、アクセス先のＵＲＬの名前解決のための第１要求を受信すると、前記受信した第１要求からアクセス先のＵＲＬを抽出し、
   前記アドレス生成関数を用いて、前記抽出されたＵＲＬのホスト名の文字列からＩＰアドレスを生成し、
   前記生成されたＩＰアドレスを、前記第１要求の回答として、前記端末に送信し、
   前記端末が、前記第１サーバ装置のＵＲＬをアクセス先とする第２要求を、前記第１要求の回答として送信されたＩＰアドレスが登録されている前記第２サーバ装置に送信すると、前記第２サーバ装置は、アクセス先のＵＲＬに基づいて、前記送信された第２要求を前記第１サーバ装置に転送することを特徴とするゲートウェイシステム。
2. 前記第２サーバ装置は、
   前記第１サーバ装置からコンテンツを取得するための前記第２要求に基づいて、前記第１サーバ装置からコンテンツを取得すると、前記取得したコンテンツを、前記コンテンツが格納されていたＵＲＬに対応付けて格納し、
   前記端末から送信された第２要求を受信すると、前記受信した第２要求から抽出されたＵＲＬに基づいて、前記端末から要求されたコンテンツが格納されているか否かを判定し、
   前記端末から要求されたコンテンツが格納されていない場合、前記受信した第２要求を前記第１サーバ装置に転送し、
   前記第１サーバ装置から前記要求されたコンテンツを取得し、
   前記端末から要求されたコンテンツが格納されている場合、前記格納されたコンテンツを前記端末に送信することを特徴とする請求項１に記載のゲートウェイシステム。
3. 前記名前解決装置は、ＤＮＳプロキシであることを特徴とする請求項１に記載のゲートウェイシステム。
4. 前記ゲートウェイシステムは、さらに、アドレス変換装置を備え、
   前記アドレス変換装置には、前記複数のＩＰアドレスが登録され、
   前記第２サーバ装置には、所定の代表ＩＰアドレスが登録され、
   前記端末によって、前記送信されたＩＰアドレスが登録されている前記アドレス変換装置に前記第２要求が送信されると、前記アドレス変換装置は、前記送信された第２要求を、前記登録された複数のＩＰアドレスと前記第２サーバ装置の代表ＩＰアドレスとの対応関係に基づいて、前記第２サーバ装置に転送することを特徴とする請求項１に記載のゲートウェイシステム。
5. 複数の端末から複数の第１サーバ装置への要求を分散するゲートウェイシステムであって、
   前記ゲートウェイシステムは、複数の第２サーバ装置と、名前解決装置と、を備え、
   前記各第２サーバ装置には、
   所定の複数のＩＰアドレスが登録され、
   文字列からハッシュ値を生成するハッシュ関数が配布され、
   前記第２サーバ装置は、
   前記第１サーバ装置からコンテンツを取得するための第２要求を前記端末から受信すると、前記受信した第２要求からアクセス先のＵＲＬを抽出し、
   前記抽出されたＵＲＬにハッシュ値が含まれているか否かを判定し、
   前記ハッシュ値が含まれている場合、前記抽出されたＵＲＬから、前記ハッシュ値を削除し、
   前記ハッシュ値が削除されたＵＲＬをアクセス先とする前記第２要求を前記第１サーバ装置に転送し、
   前記ハッシュ値が含まれていない場合、前記配布されたハッシュ関数を用いて、前記抽出されたＵＲＬの文字列からハッシュ値を生成し、
   前記生成されたハッシュ値を前記抽出されたＵＲＬのホスト名に追加し、
   前記ハッシュ値を含むＵＲＬをアクセス先とする前記第２要求を再送するように前記端末に指示し、
   前記端末によって、前記ハッシュ値を含むＵＲＬの名前解決のための第１要求が前記名前解決装置に送信されると、前記名前解決装置は、前記第１要求からアクセス先のＵＲＬを抽出し、
   さらに、前記抽出されたＵＲＬからハッシュ値を抽出し、
   所定のプレフィックスと前記抽出されたハッシュ値とを合わせて、ＩＰアドレスを生成し、
   前記生成されたＩＰアドレスを、前記第１要求の回答として、前記端末に送信し、
   前記端末によって、前記ハッシュ値を含むＵＲＬをアクセス先とする前記第２要求が、前記第１要求の回答として送信されたＩＰアドレスが登録されている前記第２サーバ装置に送信されることを特徴とするゲートウェイシステム。
6. 前記第２サーバ装置は、
   前記第２要求に基づいて、前記第１サーバ装置からコンテンツを取得し、
   前記取得したコンテンツにリンク先のＵＲＬが含まれている場合、前記ハッシュ関数を用いて、前記リンク先のＵＲＬの文字列からハッシュ値を生成し、
   前記生成されたハッシュ値を前記リンク先のＵＲＬのホスト名に追加し、
   前記取得したコンテンツ及び前記ハッシュ値を含むリンク先のＵＲＬを格納し、
   前記取得したコンテンツ及び前記ハッシュ値を含むリンク先のＵＲＬを、前記第２要求の回答として、前記端末に送信することを特徴とする請求項５に記載のゲートウェイシステム。
7. 複数の端末から複数の第１サーバ装置への要求を分散するゲートウェイシステムにおいて実行される制御方法であって、
   前記ゲートウェイシステムは、管理装置と、複数の第２サーバ装置と、名前解決装置と、を備え、
   前記制御方法は、
   前記管理装置が、文字列からＩＰアドレスを生成するアドレス生成関数を、前記名前解決装置に配布するステップと、
   前記管理装置が、前記名前解決装置において前記アドレス生成関数よって生成されるすべての前記ＩＰアドレスを複数のＩＰアドレスに分割するステップと、
   前記管理装置が、前記分割された複数のＩＰアドレスを、各々前記第２サーバ装置に配布するステップと、
   前記第２サーバ装置が、前記配布された複数のＩＰアドレスを登録するステップと、
   前記名前解決装置が、アクセス先のＵＲＬの名前解決のための第１要求を前記端末から受信すると、前記受信した第１要求からアクセス先のＵＲＬを抽出するステップと、
   前記名前解決装置が、前記アドレス生成関数を用いて、前記抽出されたＵＲＬのホスト名の文字列からＩＰアドレスを生成するステップと、
   前記名前解決装置が、前記生成されたＩＰアドレスを、前記１要求の回答として、前記端末に送信するステップと、
   前記端末が、前記第１サーバ装置のＵＲＬをアクセス先とする第２要求を、前記送信されたＩＰアドレスが登録されている前記第２サーバ装置に送信すると、前記第２サーバ装置が、アクセス先のＵＲＬに基づいて、前記送信された第２要求を前記第１サーバ装置に転送するステップと、を含むことを特徴とする制御方法。
8. 複数の端末から複数の第１サーバ装置への要求を分散するゲートウェイシステムにおい
   て実行される制御方法であって、
   前記ゲートウェイシステムは、管理装置と、複数の第２サーバ装置と、名前解決装置と、を備え、
   前記名前解決装置には、文字列からＩＰアドレスを生成するアドレス生成関数が配布され、
   前記各第２サーバ装置には、所定の複数のＩＰアドレスが登録され、
   前記制御方法は、
   前記管理装置が、文字列からハッシュ値を生成するハッシュ関数を、前記第２サーバ装置に配布するステップと、
   前記名前解決装置が、アクセス先のＵＲＬの名前解決のための第１要求を前記端末から受信すると、前記受信した第１要求からアクセス先のＵＲＬを抽出するステップと、
   前記名前解決装置が、前記アドレス生成関数を用いて、前記抽出されたＵＲＬのホスト名の文字列からＩＰアドレスを生成するステップと、
   前記名前解決装置が、前記生成されたＩＰアドレスを、前記１要求の回答として、前記端末に送信するステップと、
   前記端末が、前記第１サーバ装置のＵＲＬをアクセス先とする第２要求を、前記送信されたＩＰアドレスが登録されている前記第２サーバ装置に送信すると、前記第２サーバ装置が、前記端末から送信された第２要求を受信して、前記受信した第２要求からアクセス先のＵＲＬを抽出するステップと、
   前記第２サーバ装置が、前記抽出されたＵＲＬにハッシュ値が含まれているか否かを判定するステップと、
   前記ハッシュ値が含まれている場合、前記第２サーバ装置が、前記抽出されたＵＲＬから、前記ハッシュ値を削除するステップと、
   前記ハッシュ値が含まれていない場合、前記第２サーバ装置が、前記配布されたハッシュ関数を用いて、前記抽出されたＵＲＬの文字列からハッシュ値を生成するステップと、
   前記第２サーバ装置が、前記生成されたハッシュ値を前記抽出されたＵＲＬのホスト名に追加するステップと、
   前記第２サーバ装置が、前記ハッシュ値を含むＵＲＬをアクセス先とする前記第２要求を再送するように前記端末に指示するステップと、
   前記名前解決装置が、前記ハッシュ値を含むＵＲＬの名前解決のための第１要求を前記再送指示された前記端末から再受信すると、前記再受信した第１要求から前記ハッシュ値を含むＵＲＬを再抽出するステップと、
   前記名前解決装置が、前記アドレス生成関数を用いて、前記再抽出された前記ハッシュ値を含むＵＲＬからＩＰアドレスを再生成するステップと、
   前記名前解決装置が、前記再生成されたＩＰアドレスを、前記再受信された前記第１要求の回答として、前記端末に送信するステップと、
   前記再送を指示された前記端末が、前記ハッシュ値を含むＵＲＬをアクセス先とする第２要求を、前記再生成されたＩＰアドレスが登録されている前記第２サーバ装置に再送信すると、前記第２サーバ装置が、前記ハッシュ値を含むＵＲＬに基づいて、前記再送信された第２要求を前記第１サーバ装置に転送するステップと、を含むことを特徴とする制御方法。
9. 前記第２サーバ装置が、前記第１サーバ装置からコンテンツを取得するための前記第２要求に基づいて、前記第１サーバ装置からコンテンツを取得すると、前記取得したコンテンツにリンク先のＵＲＬが含まれているか否かを判定するステップと、
   前記取得したコンテンツにリンク先のＵＲＬが含まれている場合、前記第２サーバ装置が、前記ハッシュ関数を用いて、前記リンク先のＵＲＬの文字列からハッシュ値を生成するステップと、
   前記第２サーバ装置が、前記生成されたハッシュ値を前記リンク先のＵＲＬのホスト名に追加するステップと、
   前記第２サーバ装置が、前記取得したコンテンツ及び前記ハッシュ値を含むリンク先のＵＲＬを、前記ハッシュ値が削除されたＵＲＬに対応付けて格納するステップと、を含むことを特徴とする請求項８に記載の制御方法。
10. 前記ハッシュ値を削除するステップの後、前記第２サーバ装置が、前記ハッシュ値が削除されたＵＲＬに基づいて、前記端末から要求されたコンテンツが格納されているか否かを判定するステップと、
    前記要求されたコンテンツが格納されていない場合、前記第２サーバ装置が、前記ハッシュ値が削除されたＵＲＬをアクセス先とする前記第２要求を前記第１サーバ装置に転送するステップと、
    前記要求されたコンテンツが格納されている場合、前記第２サーバ装置が、前記格納されたコンテンツ及び前記ハッシュ値を含むリンク先のＵＲＬを、前記端末に送信するステップと、を含むことを特徴とする請求項９に記載の制御方法。

Images