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

Description

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

Claims (4)

1. 第１の装置と第２の装置との通信を中継するデータ転送装置において、
   キャッシュデータと、該キャッシュデータの識別情報であるキャッシュ識別情報とを関連付けて記憶する識別情報キャッシュを行う識別情報キャッシュ手段と、
   第２の装置への所望データの送信要求を示し、リクエストヘッダを有するリクエストメッセージを、前記第１の装置から受信するリクエスト受信手段と、
   前記リクエストヘッダを解析し、識別情報キャッシュを行う識別情報キャッシュ装置を前記リクエストメッセージが経由してきたか否かを解析する解析手段と、
   前記リクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを示す経由情報を保持する保持手段と、
   前記リクエストメッセージを前記第２の装置へ送信するリクエスト送信手段と、
   前記リクエストメッセージに対応しリプライヘッダとリプライボディとを有するリプライメッセージを、前記第２の装置から受信するリプライ受信手段と、
   前記保持手段に保持された前記経由情報に基づいて、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたか否かを判定する判定手段と、
   前記リプライボディの識別情報であるリプライボディ識別情報を定める識別情報決定手段と、
   前記識別情報キャッシュ手段に記憶された前記キャッシュ識別情報のなかから前記リプライボディ識別情報を検索する識別情報キャッシュ検索手段と、
   前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合に該リプライボディ識別情報と前記リプライボディとを関連付けて前記識別情報キャッシュ手段に記憶させ、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合に該リプライボディ識別情報と前記リプライボディとを関連付けて前記識別情報キャッシュ手段に記憶させない識別情報キャッシュ登録手段と、
   前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合あるいは前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定されかつ前記キャッシュ識別情報のなかに前記リプライボディ識別情報がない場合に前記リプライメッセージを前記第１の装置へ送信し、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定されかつ前記キャッシュ識別情報のなかに前記リプライボディ識別情報がある場合に前記リプライメッセージの前記リプライボディを前記リプライボディ識別情報に置き換えた識別情報リプライメッセージを前記第1の装置へ送信するリプライ送信手段と
   を備えることを特徴とするデータ転送装置。
2. 識別情報キャッシュ登録手段は、前記キャッシュ識別情報のなかに前記リプライボディ識別情報がない場合に、前記リプライボディと、該リプライボディ識別情報とを関連付けて前記識別情報キャッシュ手段に記憶させることを特徴とする請求項１記載のデータ転送装置。
3. 前記キャッシュ識別情報は、前記キャッシュデータから求められた前記キャッシュデータのＦＰであり、
   前記リプライボディ識別情報は、前記リプライボディから求められた前記リプライボディのＦＰであることを特徴とする請求項１記載のデータ転送装置。
4. 第１の装置と第２の装置との通信を中継するデータ転送方法において、
   識別情報キャッシュ手段に、キャッシュデータと、該キャッシュデータの識別情報であるキャッシュ識別情報とを関連付けて記憶する識別情報キャッシュを行い、
   リクエスト受信手段で、第２の装置への所望データの送信要求を示しリクエストヘッダを有するリクエストメッセージを前記第１の装置から受信し、
   解析手段で、前記リクエストヘッダを解析し、識別情報キャッシュを行う識別情報キャッシュ装置を前記リクエストメッセージが経由してきたか否かを解析し、
   保持手段で、前記リクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを示す経由情報を保持し、
   リクエスト送信手段で、前記リクエストメッセージを前記第２の装置へ送信し、
   リプライ受信手段で、前記リクエストメッセージに対応しリプライヘッダとリプライボディとを有するリプライメッセージを、前記第２の装置から受信し、
   判定手段で、前記保持手段に保持された前記経由情報に基づいて、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたか否かを判定し、
   識別情報決定手段で、前記リプライボディの識別情報であるリプライボディ識別情報を定め、
   識別情報キャッシュ検索手段で、前記識別情報キャッシュ手段に記憶された前記キャッシュ識別情報のなかから前記リプライボディ識別情報を検索し、
   前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合に該リプライボディ識別情報と前記リプライボディとを関連付けて前記識別情報キャッシュ手段に記憶させず、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合に識別情報キャッシュ登録手段で該リプライボディ識別情報と前記リプライボディとを関連付けて前記識別情報キャッシュ手段に記憶させ、
   リプライ送信手段で、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合あるいは前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定されかつ前記キャッシュ識別情報のなかに前記リプライボディ識別情報がない場合に、前記リプライメッセージを前記第１の装置へ送信し、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定されかつ前記キャッシュ識別情報のなかに前記リプライボディ識別情報がある場合に、前記リプライメッセージの前記リプライボディを前記リプライボディ識別情報に置き換えた識別情報リプライメッセージを前記第1の装置へ送信することを特徴とするデータ転送方法。

Images