JP3983987B2 - サーバ側プロキシ装置、データ転送方法及びプログラム - Google Patents

Description

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

Claims (7)

1. 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するサーバ側プロキシ装置であって、
   前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信する受信手段と、
   前記リプライデータのフィンガープリントを生成するフィンガープリント生成手段と、
   前記フィンガープリント生成手段が生成した前記フィンガープリントを、該フィンガープリントの元であった前記リプライデータに関連付けてフィンガープリント・キャッシュとして保持する保持手段と、
   前記受信手段が受信したリプライデータに基づいて前記フィンガープリント生成手段が生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、
   前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信する送信手段とを備えたことを特徴とするサーバ側プロキシ装置。
2. 前記送信手段は、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記リプライデータを前記フィンガープリントと共に前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とする請求項１に記載のサーバ側プロキシ装置。
3. 前記送信手段は、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合であってかつ前記リプライデータがＮｕｌｌでない場合に、前記フィンガープリントと前記リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とする請求項１に記載のサーバ側プロキシ装置。
4. 前記受信手段は、ローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項１に記載のサーバ側プロキシ装置。
5. 前記所定のリクエストデータは、ＧＥＴメソッドのリクエストメッセージであることを特徴とする請求項１に記載のサーバ側プロキシ装置。
6. 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するものであるとともに、該リプライデータのフィンガープリントを、該リプライデータに関連付けてフィンガープリント・キャッシュとして保持するための保持手段を備えたサーバ側プロキシ装置のデータ転送方法であって、
   前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、
   前記リプライデータのフィンガープリントを生成し、
   受信したリプライデータに基づいて生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定し、
   前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とするデータ転送方法。
7. 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するサーバ側プロキシ装置としてコンピュータを機能させるためのプログラムであって、
   前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信する受信機能と、
   前記リプライデータのフィンガープリントを生成するフィンガープリント生成機能と、
   前記フィンガープリント生成機能が生成した前記フィンガープリントを、該フィンガープリントの元であった前記リプライデータに関連付けてフィンガープリント・キャッシュとして保持する保持機能と、
   前記受信機能が受信したリプライデータに基づいて前記フィンガープリント生成機能が生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定機能と、
   前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定機能が判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定機能が判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信する送信機能とをコンピュータに機能させるためのプログラム。

Images