JP3913508B2 - データ転送装置およびデータ転送方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、他の装置のためにデータ転送を行うデータ転送装置およびデータ転送方法に関する。
【０００２】
【従来の技術】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。特に、インターネット上でＨＴＴＰプロトコルを使って通信するＷＥＢサーバとクライアントとからなるＷＯＲＬＤ ＷＩＤＥ ＷＥＢシステム（あるいは単にＷＥＢとも呼ばれる）は、大変広く利用されているクライアント・サーバ型の情報システムである。通常、サーバ上ではサーバ・プログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（例えば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋等の予約サービス、種々の契約の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【０００３】
ところで、ＷＥＢのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間で通信に用いるネットワークの容量（バンド幅）が、システム全体のボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【０００４】
ＷＥＢシステムの場合、クライアント上で動作するブラウザ等はキャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。ＷＥＢではＵＲＬと呼ばれる名前で情報やサービスを指定してアクセスがなされるので、クライアント上のキャッシュは、過去にＷＥＢサーバに要求した情報やサービスの結果として返されるデータのうちでキャッシュ可能なものを、そのＵＲＬと対応させてキャッシュに記録している。この場合、キャッシュ内にあるものと同じＵＲＬの情報やサービスのリクエストがあった際に、そのキャッシュ内の応答データが古くなっていないと判断できるならば、そのデータを返すことで、ＷＥＢサーバとの間の通信を無くすことができる。
【０００５】
企業のオフィス内のＬＡＮあるいは研究機関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数のユーザがいる場合、該ＬＡＮとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。クライアント内のキャッシュ（例えば、ブラウザのキャッシュ）は、当該クライアント・ユーザに専用のキャッシュとして動作するが、ＬＡＮ上のプロキシサーバのキャッシュは、複数のクライアント・ユーザに共有のキャッシュとして動作する。そのため、後者では、過去に他人（他クライアント）がアクセスしたＵＲＬに対してアクセスする際にもキャッシュが効く。
【０００６】
さて、ＷＥＢにおいて、クライアントとサーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行われる。ＨＴＴＰプロトコルは、クライアントからサーバへ送る「リクエストメッセージ」と、それに答えてサーバからクライアントへ応答を返す「リプライメッセージ」とが組になっている。
【０００７】
リクエストメッセージは、「リクエストヘッダ」と「リクエストボディ」からなる。リクエストヘッダには、アクセスしたい情報やサービスを指定するＵＲＬやアクセスの種類を示すメソッド名、その他アクセスに必要な各種の情報が入る。リクエストボディには、サーバに送るデータを入れる。リクエストボディに入っているデータを「リクエストデータ」とも呼ぶ。
【０００８】
リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。
リプライヘッダには、処理結果のステータスなどの情報が入り、リプライボディには要求された情報や要求されたサービスの処理結果などのデータが入る。リプライボディに入っているデータを「リプライデータ」とも呼ぶ。 リクエストメッセージのメソッドとしては、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユーザの持つデータをサーバに書き込む「ＰＵＴメソッド」、リクエストに応じて処理した結果を送り返してもらう「ＰＯＳＴメソッド」が、情報やサービスのアクセスに用いられる主要なものである。その他、ＤＥＬＥＴＥなどのメソッドが定義されている。
【０００９】
多くの場合、ＧＥＴメソッドのリクエストメッセージのリクエストボディ、ＰＵＴメソッドのリプライメッセージのリプライボディは空である。ＰＯＳＴメソッドのリクエストメッセージのリクエストボディには、必要に応じてサーバ側での処理に用いる情報が入り、ＰＯＳＴメソッドのリプライメッセージのリプライボディには、その処理の結果のデータが入る。
【００１０】
ＧＥＴメソッドでサーバから読み出すデータは、読み出す毎にサーバ側で生成する「動的データ」と、既にサーバ側で記憶しているデータをそのまま送り返す「静的データ」に分けることができる。これらのうち、動的データについては、同じＵＲＬでも読み出す度に内容が異なる可能性があるので、多くの場合、サーバはキャッシュ不可の指定をそのリプライメッセージのヘッダに入れて送り返す。したがって、ＷＥＢのデータでキャッシュの対象になるのは、静的データの部分である。この静的データは、不特定多数のユーザが参照して構わない「共有データ」と、ユーザ認証することで特定のユーザだけがアクセスできるようにアクセス制御を行う「プライベートデータ」に分けることができる。前者の共有データは、どのようなキャッシュでもキャッシュ可能である。しかしながら、後者のプライベートデータは、プロキシサーバなどの共有キャッシュでは、キャッシュ不可である（プライベートデータは必ずサーバでユーザを認証して送り返す必要があるので）。ただし、ブラウザなどの個人専用のキャッシュの場合には、プライベートデータでもキャッシュは可能である。
【００１１】
ＰＯＳＴメソッドは、サーバ側で処理をした結果を返すので、一般的にサーバはキャッシュ不可の指定をリプライメッセージのヘッダに入れて結果を送り返す。そのため、通常はキャッシュの対象にはならない。
【００１２】
ＰＵＴメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない。
【００１３】
【発明が解決しようとする課題】
従来のＷＥＢのキャッシュは、静的コンテンツをキャッシュの対象にしている。かつては、ＷＥＢで公開される情報やサービスには、情報の更新頻度がそれほど高くなく、不特定多数の人に公開されているものが多かったため、静的コンテンツの割合は非常に高く、従来のキャッシュ技術でもネットワークの負荷の軽減に有効であった。
【００１４】
しかしながら、ＷＥＢベースのＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）のように、ユーザがＷＥＢブラウザを使って、ネットワーク経由でサーバ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来のキャッシュ技術では対応できないデータが増加している。
【００１５】
・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデータが多い。
【００１６】
・バックエンドのデータベースを参照して生成する動的データが多い。
【００１７】
・帳票処理や検索などＰＯＳＴメソッドを使う場合が多い。
【００１８】
・グループ内の情報共有のためにＰＵＴメソッドを使う場合が多い。
【００１９】
この結果、キャッシュ技術のみではネットワークの負荷を軽減する手法として有効に機能しなくなってきている。
【００２０】
本発明は、上記事情を考慮してなされたもので、データ転送装置間を接続するネットワークの負荷をより軽減することができるキャッシュ技術・圧縮技術を備えたデータ転送装置、データ転送方法及びプログラムを提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明のデータ転送方法は、所望のデータを示す第１のデータ識別情報を含む第１の情報要求と、前記第１のデータ識別情報を含む第２の情報要求と、を第１の装置から受信し、前記第１の情報要求を第２の装置宛に送信し、前記第１の情報要求に対する返答であり、前記データを保持する第３の装置の識別情報である装置識別情報と前記第１のデータ識別情報と前記データとを含む情報返答を受信し、前記装置識別情報と前記第１のデータ識別情報とを前記情報返答から抽出し関連付けて記憶し、前記データを示し前記第１のデータ識別情報とは別の第２のデータ識別情報を決定し、前記データと前記第２のデータ識別情報を関連付けて第２の情報記憶手段に記憶し、前記情報返答を前記第１の装置宛に送信し、前記第１のデータ識別情報を含む第２の情報要求を前記第１の装置から受信し、前記記憶された前記データ識別情報に関連付けられた前記装置識別情報を前記第２の情報要求に書き込んだ第３の情報要求を前記第２の装置宛に送信するようにした。
【００２２】
また、本発明のデータ転送装置は、所望のデータを示す第１のデータ識別情報を含む第１の情報要求と、前記第１のデータ識別情報を含む第２の情報要求と、を第１の装置から受信する第１の受信手段と、前記第１の情報要求に対する返答であり、前記データを保持する第３の装置の識別情報である装置識別情報と前記第１のデータ識別情報と前記データとを含む情報返答を受信する第２の受信手段と、前記装置識別情報と前記第１のデータ識別情報とを前記情報返答から抽出し関連付けて記憶する第１の情報記憶手段と、前記データを示し前記第１のデータ識別情報とは別の第２のデータ識別情報を決定する識別情報決定手段と、前記データと前記第２のデータ識別情報を関連付けて記憶する第２の情報記憶手段と、前記情報返答を前記第１の装置宛に送信する第２の送信手段と、前記第１の情報記憶手段に記憶された前記データ識別情報に関連付けられた前記装置識別情報を前記第２の情報要求に書き込んだ第３の情報要求を出力する装置識別情報書き込み手段と、前記第１の情報要求と、前記第３の情報要求と、を前記第２の装置宛に送信する第１の送信手段とを備えるようにした。
【００２３】
また、本発明のデータ転送装置は、所望のＷｅｂコンテンツに対応するＵＲＬを含む第１のリクエストメッセージをクライアント端末から受信するＬＡＮ側受信手段と、前記第１のリクエストメッセージをロードバランサ宛に送信するＷＡＮ側送信手段と、前記第１のリクエストメッセージに対するリプライであり、前記Ｗｅｂコンテンツを持っていたサーバのＩＰアドレスであるサーバＩＰアドレスと前記ＵＲＬと前記Ｗｅｂコンテンツとを含むリプライメッセージを受信するＷＡＮ側受信手段と、前記サーバＩＰアドレスと前記ＵＲＬとを前記リプライメッセージから抽出して記憶するホスト情報保存部と、前記ＷｅｂコンテンツのＦＰを求めるＦＰ圧縮処理部と、前記Ｗｅｂコンテンツと前記ＦＰとを関連付けて記憶するＦＰキャッシュと、前記リプライメッセージを前記クライアント端末宛に送信するＬＡＮ側送信手段と、前記ＵＲＬを含む第２のリクエストメッセージを前記クライアント端末から受信する前記ＬＡＮ側受信手段と、前記ホスト情報保存部に保持された前記ＵＲＬに対応する前記サーバＩＰアドレスを第２のリクエストメッセージに書き込むヘッダ付加部と、前記サーバＩＰアドレスが書き込まれた前記第２のリクエストメッセージを、前記ロードバランサ宛に送信する前記ＷＡＮ側送信手段とを備えるようにした。
【００２４】
このように、本願発明は装置に係る本発明としても方法に係る発明としても成立する。
【００２５】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２６】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２７】
以下では、ＷＡＮがインターネットであり、クライアントは支社４内のＬＡＮに接続されたものであり、ＨＴＴＰプロトコルが使用されるような場合を例にとって説明するが、もちろん、本発明は、ＷＡＮがインターネット以外のものであっても、クライアントが支社以外の例えば家庭内ＬＡＮ等に設置されたものであっても、ＨＴＴＰプロトコル以外のプロトコルが使用されるものであっても適用可能である。
【００２８】
図１は、本発明を適用するコンピュータ・ネットワーク・システムの全体構成例を示すものである。
【００２９】
ＡＳＰサーバセンター２内のローカルエリアネットワーク（ＬＡＮ）１８と、支社４内のＬＡＮ１６との間はそれぞれ、インターネットや専用回線などの広域ネットワーク（ＷＡＮ）１４と接続され、またＡＳＰサーバセンター２内において、前記ＬＡＮ１８と各サーバと各ＬＡＮ１２との間には、ロードバランサ７０とサーバ側プロキシ３０を介して接続されており、ＡＳＰサーバセンター２内の各サーバ２０と、各支社４内のクライアント５０とが、通信可能になっている。
ＡＳＰサーバセンター２内の各ＬＡＮ１２には１または複数のサーバが接続され、支社内ＬＡＮ１６には１または複数のクライアントが接続される。また、ＡＳＰサーバセンター２内のＬＡＮ１８には、１または複数のロードバランサが接続され、またサーバ側プロキシ等も接続可能である。
【００３０】
ＷＥＢベースのＡＳＰは、サーバセンター２に設置したサーバ２０から、ＷＡＮ１４を介して、様々なアプリケーションプログラムによるサービスを各会社へ提供し、ユーザは支社４内に設置されたクライアント上のＷＥＢブラウザ等を使ってそれらのサービスにアクセスする。
【００３１】
このような利用形態においては、ユーザオフィス内ＬＡＮ１６とサーバセンター内ＬＡＮ１８との間のネットワークのうち、特にインターネットなどの広域ネットワーク１４の実効的な通信容量（バンド幅）は、サーバセンター内ＬＡＮ１２、ＬＡＮ１８やユーザオフィス内ＬＡＮ１６よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。
【００３２】
そこで、本実施形態では、サーバ２０とクライアント５０との間の両端に、サーバ側プロキシ３０およびクライアント側プロキシ４０という２つのモジュールを設置し、それらの間で後述するフィンガープリント圧縮（ＦＰ圧縮）を行って通信データ量を低減することで、広域ネットワーク４０のボトルネックを解消する。
【００３３】
本実施形態のサーバ２０、サーバ側プロキシ３０、クライアント側プロキシ４０、クライアント５０、ロードバランサ７０は、いずれも、計算機上でソフトウェア（サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム、ロードバランサ・プログラム）を動作させる形で実現することができる。この場合に、必要に応じて計算機所望の機能を有するＯＳやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが搭載あるいは接続される。また、この場合に、ユーザあるいは管理者からの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いると好ましい。
【００３４】
サービスを利用するためにユーザが使用するクライアント５０上では、その目的に応じて例えばＷＥＢブラウザ等のプログラムが動作する。ユーザは、例えば、ＷＥＢブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。もちろん、ＷＥＢブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【００３５】
サーバ２０上では、所定のサーバ・プログラムが動作し、クライアント２０のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【００３６】
サーバ側プロキシ３０は、図１のように、サーバセンター内ＬＡＮ１２とロードバランサ７０との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図２（ａ）のように、サーバセンター内ＬＡＮ１２上に設置して実施することもできる。また、図３（ａ）のように、サーバ側プロキシ３０の機能をサーバ２０に内蔵するように実施することもできる。
【００３７】
同様に、クライアント側プロキシ４０は、図１のように、支社内ＬＡＮ１６とＷＡＮ１４との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図２（ｂ）のように、支社内ＬＡＮ１６上に設置して実施することもできる。また、図３（ｂ）のように、クライアント側プロキシ４０の機能をクライアント５０上で動作するブラウザ等に内蔵するように実施することもできる。あるいは、ブラウザ等の動作するクライアント５０上に、個人用のクライアント側プロキシ４０を動作させるように実施することもできる。
【００３８】
上記のコンピュータ・ネットワーク・システムにおいて、本実施の形態の概念的なフローについて、図４及び図５を用いて説明する。
【００３９】
図４は、サーバ２０上のＷｅｂコンテンツをサーバ側プロキシ３０およびクライアント側プロキシ４０へキャッシュする際の動作フローを示している。
【００４０】
まず、ユーザは、支店４内のクライアント５０のブラウザから、所望のサーバ２０に記憶されるＷｅｂコンテンツを読み出すために、そのＷｅｂコンテンツのＵＲＬを指定して、リクエストを行う。
【００４１】
このリクエストは、ネットワークを介して、サーバ２０へ通知される（図４−１）。この通知を受け取ったサーバ２０はリクエストされたＷｅｂコンテンツを読み出して、サーバ側プロキシ３０へ送信する（図４−２）。サーバ側プロキシ３０は、受け取ったＷｅｂコンテンツのフィンガープリント（ＦＰ）を計算する（図４−３）。計算されたＦＰをＷｅｂコンテンツと対応で受けて保存する（図４−４）。また、サーバ側プロキシ３０は受け取ったＷｅｂコンテンツを支社へリプライする（図４−５）。
【００４２】
クライアント側プロキシ４０は、受け取ったＷｅｂコンテンツのフィンガープリント（ＦＰ）を計算する（図４−６）。計算されたＦＰをＷｅｂコンテンツと対応で受けて保存する（図４−７）。クライアント側プロキシ４０は、Ｗｅｂコンテンツをクライアント５０へ送信する（図４−８）。以上により、Ｗｅｂコンテンツがサーバ側プロキシ３０およびクライアント側プロキシ４０へそれぞれキャッシュされる。
【００４３】
次に、図５は、Ｗｅｂコンテンツがサーバ側プロキシ３０およびクライアント側プロキシ４０に、既にキャッシュされている際の動作フローを示している。
【００４４】
まず、ユーザは、支店４内のクライアント５０のブラウザから、所望のサーバ２０に記憶されるＷｅｂコンンテンツを読み出すために、そのＷｅｂコンテンツのＵＲＬを指定して、リクエストを行う。
【００４５】
このリクエストは、ネットワークを介して、サーバ２０へ通知される（図５−１）。この通知を受け取ったサーバ２０はリクエストされたＷｅｂコンテンツを読み出して、サーバ側プロキシ３０へ送信する（図５−２）。サーバ側プロキシ３０は、受け取ったＷｅｂページのフィンガープリント（ＦＰ）を計算する（図５−３）。計算されたＦＰと同じＦＰが既にサーバ側プロキシ３０内に保存されているか否かの検索を行う（図５−４）。ここでは、計算されたＦＰと同じＦＰが保存済みであるため、サーバ側プロキシ３０は、受け取ったＷｅｂコンテンツを支店へ送信するのではなく、代わりに、そのＦＰを支店へリプライする（図５−５）。クライアント側プロキシ４０は、受け取ったＦＰで自装置内を検索する（図５−６）。検索されて見つかったＦＰに対応付けて保存されるＷｅｂコンテンツを読み出す（図５−７）。クライアント側プロキシ４０は、自装置内から読み出したＷｅｂページをクライアント５０へ送信する（図５−８）。以上により、サーバ側プロキシ３０からクライアント側プロキシ４０へ送信されるべきＷｅｂコンテンツを少量のＦＰに替えて送るから、特に、広域ネットワークのボトルネックを解消できる。
【００４６】
さて、ここでフィンガープリントについて、詳細に説明する。
【００４７】
本実施形態のサーバ側プロキシ３０およびクライアント側プロキシ４０は、いずれも、フィンガープリント・キャッシュ（ＦＰキャッシュ）と呼ぶキャッシュ機構を持つ。フィンガープリントキャッシュは、フィンガープリント（ＦＰ）と呼ぶ名前によって、ＨＴＴＰプロトコルでやりとりされるデータを記録・管理する。
【００４８】
フィンガープリントは、図６に例示するように、ＨＴＴＰプロトコルでやり取りされるデータ（図６の例ではコンテンツ）の内容から、あらかじめ決められた計算方法（図６の例ではハッシュ関数）で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【００４９】
フィンガープリントを計算する方法としては、良く知られているＭＤ−５やＳＨＡ−１などのハッシュ関数を用いることができる。これらのハッシュ関数は、データに対する電子署名などに使われており、任意のデータが与えられると、ＭＤ−５の場合は１２８ビットの数値に、ＳＨＡ−１の場合は１６０ビットの数値に、変換することができる。これらのハッシュ関数の特徴は、２つのデータＸ１，Ｘ２が与えられ、データＸ１とデータＸ２とが同じであれば、データＸ１に対して計算したハッシュ値とデータＸ２に対して計算したハッシュ値とは等しくなるが、異なる２つのデータＡ，Ｂが与えられた場合には、データＡに対して計算したハッシュ値とデータＢに対して計算したハッシュ値とは、非常に高い確率で異なるものになることである（原理上は、異なる２つのデータＡ，Ｂに対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい）。
【００５０】
図７に示すように、サーバ側プロキシ３０やクライアント側プロキシ４０の持つフィンガープリント・キャッシュ（図中の６０）は、過去にＨＴＴＰプロトコルでやり取りされたデータ本体（図中の６１）を、そのデータから計算して求めたフィンガープリントの値（図中の６２）を名前として、記録・管理している。
【００５１】
例えばＨＴＴＰプロトコルでサーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送するときに、サーバ側プロキシ３０は、当該データのフィンガープリントを計算し、そのフィンガープリントに対応するデータがフィンガープリントキャッシュに入っていれば、当該データ（と同じ内容のデータ）は過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリントキャッシュから取り出すことで、転送すべきデータを再現することができる。このような方式（すなわち、データ圧縮→データ転送→データ解凍）により、過去に送ったものと同じデータならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。もちろん、クライアント側プロキシ４０からサーバ側プロキシ３０へデータを転送するときも同様である。
【００５２】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリントキャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮（ＦＰ圧縮）と呼ぶものとする。
【００５３】
なお、サーバ側プロキシ３０とクライアント側プロキシ４０との間において、すべてのメッセージを、ＦＰ圧縮を適用する対象（すなわち、フィンガープリントキャッシュを利用してデータをフィンガープリントに置き換えるための処理を行う対象）としてもよいが、例えばフィンガープリントキャッシュの効果が期待できないものなどに対する適用を除外するために、予め定められた条件を満たすメッセージについては、これをＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで転送する）ようにしてもよい。
【００５４】
この場合の予め定められた条件とは、例えば、メッセージ・ヘッダに予め定められた情報が記述されていることである。具体的には、例えば、メッセージ・ヘッダにＧＥＴメソッドを示す情報およびリクエストを示す情報が記述されていることである。また、予め定められた条件の他の例としては、転送されるデータが空（ｎｕｌｌ）あるいは非常に短いサイズであることである。
【００５５】
もちろん、それらの他にも種々のバリエーションがある。また、複数の条件を組み合わせて使用するようにしてもよい。
【００５６】
ところで、図１の本発明を適用するコンピュータ・ネットワーク・システムにおいては、ＬＡＮ１８と複数のサーバ側プロキシ３０との間にロードバランサ７０が介在している。ロードバランサ７０は、ＬＡＮ１８から受ける処理要求に対する処理を軽減するために、複数のサーバ２０を設けて、処理内容や、各サーバの負荷などに応じて、適宜、要求を処理するサーバ２０を選択し、選択したサーバ２０に処理を供給するものである。従って、ここでは各サーバ２０は同じ情報（コンテンツ）を保存していることが望ましい。
【００５７】
このようなロードバランサ７０を備えた図１の本発明を適用するコンピュータ・ネットワーク・システムにおいては、支社４のクライアント側プロキシ４０とＡＳＰサーバセンター２のサーバ側プロキシ３０で、上記で説明したようなフィンガープリント技術を適用するだけでは、以下のような問題が生じる。
ａ）あるコンテンツに対して、複数回リクエストがあった時、ロードバランサ７０は、通常各回ごとに独立してサーバ側プロキシ３０を選択するので、同じコンテンツをそれぞれ異なるサーバプロキシで処理することが起きて、ＦＰキャッシュの効率が落ちてしまう。
ｂ）ＦＰを受信したクライアント側プロキシ５０は、自身のキャッシュを検索した際、例えば記憶容量の関係で既にキャッシュにコンテンツが無い場合に、再リクエストメッセージをサーバ側プロキシへ発行するが、このときに直前のリクエストメッセージの処理を行ったサーバ側プロキシ３０で処理を行わないと、正常なデータ取得ができなくなってしまう恐れがある。
【００５８】
そこで、本実施の形態のサーバ側プロキシ３０及びクライアント側プロキシ４０は、これらの問題点を解決するようにした。
【００５９】
図８、図９、及び図１０に、本実施の形態のクライアント側プロキシ４０、ロードバランサ７０及びサーバ側プロキシ３０の機能ブロック図を示し、詳細に説明する。なお、図８、図９および図１０は、クライアント側プロキシ４０、ロードバランサ７０及びサーバ側プロキシ３０の間のデータ転送の際の機能構成を中心に示してある。
【００６０】
ここで、まず、リクエストメッセージおよびリプライメッセージについて説明する。
【００６１】
リクエストメッセージは、［従来の技術］欄で示したようにリクエストヘッダとリクエストボディからなっており、リクエストヘッダには、予め決められた情報が格納される領域の他に、利用者によって書き込む情報が定義可能な領域を含んでいる。本実施の形態では、この利用者によって定義可能な領域に、（ＦＰキャッシュミスによる）リクエストメッセージが再送である旨を示す情報を書き込めるようにした。ここではＲＥＴＲＹと書き込むようにし、これをＲＥＴＲＹヘッダと呼ぶこととしている。また、本実施の形態では、この利用者によって定義可能な領域に、利用すべきサーバ側プロキシ３０のＩＰアドレスを書き込めるようにした。この領域をＩＰアドレスヘッダと呼ぶこととする。
【００６２】
リプライメッセージは、［従来の技術］欄で示したようにリプライヘッダとリプライボディからなっており、リプライヘッダには、予め決められた情報が格納される領域の他に、利用者によって書き込む情報を定義可能な領域を含んでいる。本実施の形態では、この利用者によって定義可能な領域に、リクエストヘッダと同様に、利用されたサーバ側プロキシ３０のＩＰアドレスを書き込むようにした。この領域をＩＰアドレスへッダと呼ぶこととする。また、本実施の形態では、この利用者によって定義可能な領域に、リクエストヘッダと同様に、（ＦＰキャッシュミスによる）リクエストメッセージが再送である旨を示す情報を書き込めるようにした。ここではＲＥＴＲＹと書き込むようにし、これをＲＥＴＲＹヘッダと呼ぶこととしている。なお、リプライヘッダは、基本的にはリクエストヘッダを踏襲しており、ここではリプライヘッダのＩＰアドレスへッダとＲＥＴＲＹヘッダはリクエストヘッダ時に付加されたものそのまま消去することなく利用していると考えて良い。
【００６３】
以下に、クライアント側プロキシ４０の構成を説明する。
【００６４】
受信部４０１は、クライアント５０からのリクエストメッセージを受信するものである。ヘッダ解析部４０２は、受け取ったリクエストメッセージのリクエストヘッダを解析し、ユーザが要求した要求先のＵＲＬを取り出して、ホスト情報保存部４０３を参照し、そのＵＲＬと一致するＵＲＬが保存されているか否かを検索する。これにより、一致するＵＲＬが見つかった際にはこのＵＲＬに対応して保存されるＩＰアドレスをホスト情報保存部４０３より読み出す。
ヘッダ付加部４０４は、その読み出されたＩＰアドレスをリクエストメッセージのＩＰアドレスヘッダに書き込み、送信部４０５へ送る。一方、一致するＵＲＬが見つからなかった際には、リクエストメッセージをそのまま、送信部４０５へ送る。送信部４０５は、ヘッダ解析部４０２またはヘッダ付加部４０４から送られてきたリクエストメッセージを、ＷＡＮ１４を介してロードバランサ７０へ送信する。
【００６５】
受信部４０６は、リクエストメッセージに対する応答であるリプライメッセージを受信するものである。ヘッダ解析部４０７は、リプライメッセージのリプライヘッダを解析し、ＵＲＬとＩＰアドレスを取得し、対応付けてホスト情報保存部４０３へ保存する。ホスト情報保存部４０３は、このように過去にリクエストされたＵＲＬが、どのサーバ側プロキシ３０で処理されたかを保存しておくものである。
【００６６】
ＦＰ圧縮判定部４０８は、受け取ったリプライメッセージに含まれるＦＰ圧縮フラグによって、そのリプライメッセージがＦＰ圧縮されたものか否かを判定するものである。ＦＰ圧縮されていればＦＰキャッシュ管理部４０９へ、ＦＰ圧縮されていなければＦＰ圧縮処理部４１４にリプライメッセージを送る。
【００６７】
ＦＰキャッシュ管理部４０９は、そのリプライメッセージ内のＦＰでＦＰキャッシュ４１１を検索し、検索されたＦＰに対応するコンテンツを得て、送信部４１３へ送るものである。ここで、ＦＰキャッシュ４１１には、本来全てのＦＰがあるはずだが、キャッシュメモリの容量不足により、ここでは古いものから少しずつ削除されるような構成としている。そのため、キャッシュミスが起きる場合が有る。その場合には、ＦＰキャッシュ管理部４０９は、リプライメッセージを再リクエスト生成部４１５へ送る。
【００６８】
再リクエスト生成部４１５は、再度、同じＵＲＬへコンテンツを要求するリクエストメッセージを生成する。このとき、再リクエスト生成部４１５は、リクエストヘッダにＲＥＴＲＹヘッダを付加する。この生成されたリクエストメッセージは、先に説明したヘッダ解析部４０２に送られる。
【００６９】
ＦＰ圧縮処理部４１４は、ＦＰ圧縮判定部４０８からリプライメッセージを受け取り、そのリプライデータ（＝コンテンツ）をＦＰ圧縮するものである。ＦＰ登録部４１０は、 ＦＰ圧縮処理部４１４で圧縮されたＦＰとリプライメッセージのリプライデータ（コンテンツ）とを対応付けてＦＰキャッシュ４１１に登録する。そして、リプライメッセージを送信部４１３へ送る。送信部４１３は、受信した情報をクライアント５０へ送信するものである。
【００７０】
なお、機能ブロックとして、受信部４０１と受信部４０６、送信部４０５と送信部４１３、を別々のブロック構成として図示したが、同じ構成であっても良く、また受信部４０１と送信部４１３、受信部４０５と受信部４０６、を送受信部として同じ構成としても良いことは勿論である。
【００７１】
次に、図９のロードバランサ７０について説明する。ロードバランサ７０は、受信部７０１にて、クライアント側プロキシ４０からのリクエストメッセージを受信する。ヘッダ解析部７０２は、受信部７０１にて受信したリクエストメッセージのリクエストヘッダを解析し、ＩＰアドレスヘッダを確認し、もし、ＩＰアドレスが書き込まれていれば、そのＩＰアドレスのサーバ側プロキシ３０へ送信部７０３を介し、送信する。受信部７０４は、各サーバ側プロキシ３０と接続され、サーバ側プロキシ３０からのリプライメッセージを受信し、送信部７０５からクライアント側プロキシ４０へリプライメッセージを転送する。
【００７２】
次に、図１０に示すサーバ側プロキシ３０の構成を説明する。
【００７３】
受信部３０１は、リクエストメッセージを受信する。ヘッダ解析部３１２は、受信したリクエストメッセージにＲＥＴＲＹヘッダが含まれているか否かを確認する。もし、ＲＥＴＲＹヘッダが含まれていれば、その旨をヘッダ情報保存部３１３へ書き込む。
【００７４】
リクエストメッセージは、そのまま送信部３０４へ送られ、送信部３０４からサーバ２０へ転送する。
【００７５】
受信部３０５は、サーバ２０からのリプライメッセージを受信するものである。ヘッダ判定部３０６は、受信部３０５からリプライメッセージを受けると、ヘッダ情報保存部３１３に、このリプライメッセージに対応するリクエストメッセージにＲＥＴＲＹヘッダを含んでいたか否かを判定する。ヘッダ判定部３０６は、ＲＥＴＲＹヘッダがあったと判定した場合には、再リクエストに対する応答であるため、そのままリプライメッセージを送信部３１１へ送る。これは、再びクライアント側プロキシ４０でキャッシュミスとなることを防ぐためであり、また、サーバ側プロキシ３０のＦＰキャッシュ３０９において既に登録されているからである。ヘッダ判定部３０６は、ＲＥＴＲＹヘッダが無かったと判断した場合は、リプライメッセージをＦＰ圧縮処理部３０７へ送る。
【００７６】
ＦＰ圧縮処理部３０７は、先に説明したＦＰ圧縮の方法で、リプライデータ（＝コンテンツ）を圧縮し、ＦＰを生成するものである。リプライメッセージと生成されたＦＰとをＦＰキャッシュ管理・登録部３０８へ送る。ＦＰキャッシュ管理・登録部３０８は、受け取ったＦＰでＦＰキャッシュ３０９を検索し、見つかった際にはリプライメッセージのリプライデータをＦＰに変えて、ヘッダ付加部３１０へ送る。見つからなければＦＰとコンテンツとを対応付けてＦＰキャッシュ３０９へ記憶するとともに、コンテンツを、ヘッダ付加部３１０へ送る。ヘッダ付加部３１０は、このサーバ側プロキシのＩＰアドレスを、リプライメッセージのＩＰアドレスヘッダに付加し、送信部３１１へ送る。
【００７７】
以上が、サーバ側プロキシ３０の構成である。
【００７８】
図１１は、クライアントからの一つのリクエストメッセージを受けた際のクライアント側プロキシ４０の処理手順の一例を示している。
【００７９】
クライアント側プロキシ４０は、受信部４０１、またはクライアント側プロキシ４０内の再リクエスト生成部４１５より（図１４の（Ａ）より）、リクエストメッセージを受ける（ステップＳ１０１）。ヘッダ解析部４０２は、リクエストメッセージのリクエストヘッダを解析し、クライアント５０にて要求されたＵＲＬを取得する（ステップＳ１０２）。取得したＵＲＬがホスト情報保存部４０３に保存されているか否かを確認する（ステップＳ１０３）。
【００８０】
ステップＳ１０３の結果、ホスト情報保存部４０３にＵＲＬがあった場合、ヘッダ情報保存部４０３に保存されるＵＲＬに対応するＩＰアドレスを取り出し、ヘッダ付加部４０４で、リクエストメッセージのリクエストヘッダのＩＰアドレスヘッダにそのＩＰアドレスを書き込み、送信部４０５によってそのリクエストメッセージをロードバランサ７０へ送信する（ステップＳ１０４）。一方、ステップＳ１０３の結果、ホスト情報保存部４０３にＵＲＬがなければ、送信部４０５によってリクエストメッセージをそのまま、ロードバランサ７０へ送信する（ステップＳ１０５）。
【００８１】
図１２は、一つのリクエストメッセージを受けたロードバランサ７０の処理手順の一例を示している。
【００８２】
ロードバランサ７０は、受信部７０１により、リクエストメッセージを受信する（ステップＳ２０１）。ヘッダ解析部７０２は、受信したリクエストメッセージのリクエストヘッダを解析し、ＩＰアドレスヘッダが付加されているか否かを検出する（ステップＳ２０２）。ステップＳ２０２の結果、ＩＰアドレスヘッダが付加されていれば、送信部７０３は、このＩＰアドレスを用いて、リクエストメッセージを送信する（ステップＳ２０３）。ステップＳ２０２の結果、ＩＰアドレスヘッダが付加されていなければ、ロードバランサ７０は、所定の方法（例えば、各サーバの負荷のもっとも小さなもの、等）にてサーバ側プロキシ３０を決定し、送信部７０３は、そのサーバ側プロキシ３０へリクエストメッセージを送信する（ステップＳ２０４）。
【００８３】
これによって、サーバ側プロキシ３０を介し、サーバ２０は、リクエストメッセージを受け、クライアント５０の所望のコンテンツを読み出して、リクエストメッセージが発行されたクライアント５０へ向けて、リプライメッセージを送信する。なお、図１０の説明でも示したためフローチャートを用いた説明は省略するが、サーバ側プロキシ３０の処理手順は、１）リクエストメッセージを解析し、２）ＲＥＴＲＹヘッダの有無を判断し、３）ＲＥＴＲＹヘッダがあった場合に、ヘッダ情報保存部３１３にその旨保存する、４）リクエストメッセージをサーバ２０へ送信する、ように動作する。
【００８４】
図１３は、サーバ２０から一つのリプライメッセージを受けた際のサーバ側プロキシ３０の処理手順の一例を示している。
【００８５】
サーバ側プロキシ３０は、受信部３０５により、サーバ２０からリプライメッセージを受信する（ステップＳ３０１）。ヘッダ判定部３０６は、ヘッダ情報保存部３１３にＲＥＴＲＹヘッダが付加されているか否かを判定する（ステップＳ３０２）。
【００８６】
ステップＳ３０２の結果、ＲＥＴＲＹヘッダが付加されていると判断すると、送信部３１１によってリプライメッセージをロードバランサ７０へ送信する（ステップＳ３１０）。
【００８７】
ステップＳ３０２の結果、ＲＥＴＲＹヘッダが付加されていないと判断すると、ＦＰ圧縮処理部３０７は、リプライメッセージのリプライデータ（＝コンテンツ）のＦＰを求める（ステップＳ３０３）。そして、ＦＰキャッシュ管理・登録部３０８にて、求められた該ＦＰをキーとしてフィンガープリントキャッシュ３０９を検索し（ステップＳ３０４）、該フィンガープリントの値とこれに対応するデータとの組がＦＰキャッシュ３０９に登録されているかいないかを判断する（ステップＳ３０５）。
【００８８】
ステップＳ３０５の結果、ＦＰキャッシュ３０９にＦＰが登録されていれば、リプライメッセージのリプライデータをこのＦＰに変更する（ステップＳ３０６）。このとき、リプライヘッダにＦＰ圧縮した旨のヘッダを付加する。
【００８９】
ステップＳ３０５の結果、ＦＰキャッシュ３０９にＦＰが登録されていなければ、ＦＰキャッシュ管理・登録部３０８は、該フィンガープリントの値と、該リプライデータとを対応付けて（フィンガープリントの値をキーとして）、フィンガープリントキャッシュ３０９に登録する（ステップＳ３０７）。
【００９０】
ヘッダ付加部３１０は、リプライメッセージのヘッダにサーバ側プロキシ自身のＩＰアドレスを付加する（ステップＳ３０８）。そして、送信部３１１は、リプライメッセージを、ロードバランサ７０へ送信する（ステップＳ３０９）。
【００９１】
次に、特に図示しないが、ロードバランサ７０は、サーバ側プロキシ３０からのリプライデータをクライアント側プロキシ４０に転送する。
【００９２】
次に、図１４に、一つのリプライメッセージを受けた際のクライアント側プロキシ４０の処理手順の一例を示している。
【００９３】
クライアント側プロキシ４０は、受信部４０６により、リプライメッセージを受信する（ステップＳ４０１）。ヘッダ解析部４０７は、このリプライメッセージのリプライヘッダを解析し、ＵＲＬと、ＩＰアドレスヘッダからＩＰアドレスを取得し、これらを対応づけてホスト情報保存部４０３へ保存する（ステップＳ４０２）。次に、ＦＰ圧縮判定部４０８は、リプライヘッダにＦＰ圧縮フラグの有無を確認することによって、リプライデータがＦＰ圧縮されているか否かを判定する（ステップＳ４０３）。
【００９４】
ステップＳ４０３の結果、ＦＰ圧縮されていれば、リプライメッセージのリプライデータはＦＰであるから、ＦＰキャッシュ管理部４０９にて、該リプライデータ（＝ＦＰ）をキーとしてフィンガープリントキャッシュ４１１を検索し（ステップＳ４０４）、ＦＰがＦＰキャッシュ４１１にあるか否かを判断する（ステップＳ４０５）。この検索によって、対応するフィンガープリントがあった場合、該フィンガープリントに対応するコンテンツを読み出し、リプライメッセージのリプライデータをこのコンテンツに変更する（ステップＳ４０６）。送信部４１３は、この変更されたリプライメッセージをクライアント５０へ向けて送信する（ステップＳ４０７）。
【００９５】
ステップＳ４０５の結果、対応するＦＰが無かった場合、再リクエスト生成部４１５は、リクエストメッセージを生成し、再リクエストである旨のＲＥＴＲＹヘッダを付加して、送信する（ステップＳ４０８）。
【００９６】
ステップＳ４０３の結果、リプライデータが圧縮されていなければ、ＦＰ圧縮処理部４１４は、リプライデータをＦＰ圧縮し、ＦＰを求める（Ｓ４０９）。
ＦＰキャッシュ登録部４１０は、求めた該フィンガープリントと、該リプライデータとを対応付けて（フィンガープリントの値をキーとして）、フィンガープリントキャッシュ４１１に登録する（ステップＳ４１０）。
【００９７】
送信部４１３は、そのままのリプライメッセージを、クライアント５０へ向けて送信する（ステップＳ４１１）。
【００９８】
以上本発明の実施の形態によれば、クライアン側プロキシ４０と複数のサーバ側プロキシ３０との間に、ロードバランサ７０を備えたとしても、初めにあるＵＲＬに対し、クライアント側プロキシ４０から発したリクエストメッセージと、次回にそのＵＲＬに対して発したリクエストメッセージとが同じサーバ側プロキシ３０へ送られて処理されるから、２度目のリクエストの際に、ＦＰが利用できるようになった。
【００９９】
また、本実施の形態のサーバ側プロキシ３０は、送信するリプライメッセージにデータまたはＦＰ値の何れかのみを付加して送付するようにしていたが、ＦＰ値を保存しデータを送信する場合（Ｓ３０５のＮＯの場合）、ＦＰ値もリプライメッセージに付けて送るようにしても良い。このような構成にすれば、クライアント側プロキシ４０内には、受信したリプライメッセージからＦＰ値を抽出する機能を有する必要があるが、ＦＰ圧縮を行う機能は不要となり、全体の速度の高速化が可能になるだろう。
【０１００】
ところで、これまでは、１つのメッセージに含まれるデータ全体をＦＰ圧縮する対象（フィンガープリントキャッシュに登録する対象）にしていたが、例えば、１つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、１つのメッセージに含まれる一部の単位データのみＦＰ圧縮する対象（フィンガープリントキャッシュに登録する対象）にする構成も可能である。
【０１０１】
なお、以上の各機能は、ソフトウェアとして実現可能である。
【０１０２】
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１０３】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
【０１０４】
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
【０１０５】
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
【０１０６】
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１０７】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１０８】
【発明の効果】
本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を保持しているデータについては、データを転送する代わりに対応する名前を転送することで、データ転送装置間の転送データ量を削減することができる。そして、特にロードバランサを備えた複雑なシステム構成であっても、実現できる。
【図面の簡単な説明】
【図１】 本発明の一実施形態に係るコンピュータ・ネットワーク・システムの構成例を示す図。
【図２】 同実施形態に係るコンピュータ・ネットワーク・システムの他の構成例を示す図。
【図３】 同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図。
【図４】 同実施形態に係るコンピュータ・ネットワーク・システムの基本概念を示す図。
【図５】 同実施形態に係るコンピュータ・ネットワーク・システムの基本概念を示す図。
【図６】 同実施の形態のフィンガープリントを示す図。
【図７】 同実施の形態のフィンガープリントキャッシュを示す図。
【図８】 同実施の形態のクライアント側プロキシの機能ブロック図。
【図９】 同実施の形態のロードバランサの機能ブロック図。
【図１０】 同実施の形態のサーバ側プロキシの機能ブロック図。
【図１１】 同実施形態に係るクライアント側プロキシの手順例を示すフローチャート。
【図１２】 同実施形態に係るロードバランサの手順例を示すフローチャート。
【図１３】 同実施形態に係るサーバ側プロキシの手順例を示すフローチャート。
【図１４】 同実施形態に係るクライアント側プロキシの手順例を示すフローチャート。
【符号の説明】
２…ＡＳＰサーバセンター
４…支社
１２、１６、１８…ＬＡＮ
１４…ＷＡＮ
１６…ユーザオフィス内ＬＡＮ
２０…サーバ装置
３０…サーバ側プロキシ装置
４０…クライアント側プロキシ装置
５０…クライアント装置
７０…ロードバランサ装置
３０１，３０５，４０１，４０６，７０１，７０４…受信部
４０２，４０７，７０２…ヘッダ解析部
４０３…ホスト情報保存部
３０４，３１１，４０５，４１３，７０３，７０５…送信部
３０６…ヘッダ判定部
３０７，４１４…ＦＰ圧縮処理部
３０８…フィンガープリントキャッシュ管理・登録部
４０９…フィンガープリントキャッシュ管理部
３０９，４１１…ＦＰキャッシュ
３１０，４０４…ヘッダ付加部
３１２，４１０…フィンガープリントキャッシュ登録部
４０８…フィンガープリント圧縮判定部
４１５…再リクエスト生成部

Claims (3)

1. 所望のデータを示す第１のデータ識別情報を含む第１の情報要求と、前記第１のデータ識別情報を含む第２の情報要求と、を第１の装置から受信し、
   前記第１の情報要求を第２の装置宛に送信し、
   前記第１の情報要求に対する返答であり、前記データを保持する第３の装置の識別情報である装置識別情報と前記第１のデータ識別情報と前記データとを含む情報返答を受信し、
   前記装置識別情報と前記第１のデータ識別情報とを前記情報返答から抽出し関連付けて記憶し、
   前記データを示し前記第１のデータ識別情報とは別の第２のデータ識別情報を決定し、
   前記データと前記第２のデータ識別情報を関連付けて第２の情報記憶手段に記憶し、
   前記情報返答を前記第１の装置宛に送信し、
   前記第１のデータ識別情報を含む第２の情報要求を前記第１の装置から受信し、
   前記記憶された前記データ識別情報に関連付けられた前記装置識別情報を前記第２の情報要求に書き込んだ第３の情報要求を前記第２の装置宛に送信することを特徴とするデータ転送方法。
2. 所望のデータを示す第１のデータ識別情報を含む第１の情報要求と、前記第１のデータ識別情報を含む第２の情報要求と、を第１の装置から受信する第１の受信手段と、
   前記第１の情報要求に対する返答であり、前記データを保持する第３の装置の識別情報である装置識別情報と前記第１のデータ識別情報と前記データとを含む情報返答を受信する第２の受信手段と、
   前記装置識別情報と前記第１のデータ識別情報とを前記情報返答から抽出し関連付けて記憶する第１の情報記憶手段と、
   前記データを示し前記第１のデータ識別情報とは別の第２のデータ識別情報を決定する識別情報決定手段と、
   前記データと前記第２のデータ識別情報を関連付けて記憶する第２の情報記憶手段と、
   前記情報返答を前記第１の装置宛に送信する第２の送信手段と、
   前記第１の情報記憶手段に記憶された前記データ識別情報に関連付けられた前記装置識別情報を前記第２の情報要求に書き込んだ第３の情報要求を出力する装置識別情報書き込み手段と、
   前記第１の情報要求と、前記第３の情報要求と、を前記第２の装置宛に送信する第１の送信手段と、
   を備えることを特徴とするデータ転送装置。
3. 所望のＷｅｂコンテンツに対応するＵＲＬを含む第１のリクエストメッセージをクライアント端末から受信するＬＡＮ側受信手段と、
   前記第１のリクエストメッセージをロードバランサ宛に送信するＷＡＮ側送信手段と、
   前記第１のリクエストメッセージに対するリプライであり、前記Ｗｅｂコンテンツを持っていたサーバのＩＰアドレスであるサーバＩＰアドレスと前記ＵＲＬと前記Ｗｅｂコンテンツとを含むリプライメッセージを受信するＷＡＮ側受信手段と、
   前記サーバＩＰアドレスと前記ＵＲＬとを前記リプライメッセージから抽出して記憶するホスト情報保存部と、
   前記ＷｅｂコンテンツのＦＰを求めるＦＰ圧縮処理部と、
   前記Ｗｅｂコンテンツと前記ＦＰとを関連付けて記憶するＦＰキャッシュと、
   前記リプライメッセージを前記クライアント端末宛に送信するＬＡＮ側送信手段と、
   前記ＵＲＬを含む第２のリクエストメッセージを前記クライアント端末から受信する前記ＬＡＮ側受信手段と、
   前記ホスト情報保存部に保持された前記ＵＲＬに対応する前記サーバＩＰアドレスを第２のリクエストメッセージに書き込むヘッダ付加部と、
   前記サーバＩＰアドレスが書き込まれた前記第２のリクエストメッセージを、前記ロードバランサ宛に送信する前記ＷＡＮ側送信手段と、
   を備えるデータ転送装置。

Images