JP3983987B2 - サーバ側プロキシ装置、データ転送方法及びプログラム - Google Patents
サーバ側プロキシ装置、データ転送方法及びプログラム Download PDFInfo
- Publication number
- JP3983987B2 JP3983987B2 JP2001069284A JP2001069284A JP3983987B2 JP 3983987 B2 JP3983987 B2 JP 3983987B2 JP 2001069284 A JP2001069284 A JP 2001069284A JP 2001069284 A JP2001069284 A JP 2001069284A JP 3983987 B2 JP3983987 B2 JP 3983987B2
- Authority
- JP
- Japan
- Prior art keywords
- fingerprint
- data
- client
- side proxy
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明は、他の装置のためにデータ転送を行うサーバ側プロキシ装置、データ転送方法及びプログラムに関する。
【0002】
【従来の技術】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。特に、インターネット上でHTTPプロトコルを使って通信するWEBサーバとクライアントとからなるWORLD WIDE WEBシステム(あるいは単にWEBとも呼ばれる)は、大変広く利用されているクライアント・サーバ型の情報システムである。通常、サーバ上ではサーバプログラムが動作し、クライアント上ではブラウザなどの所定のツール(プログラム)が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報(例えば、ホームページ、電子メール、デジタルコンテンツなど)や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋等の予約サービス、種々の契約の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【0003】
ところで、WEBのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間で通信に用いるネットワークの容量(バンド幅)が、システム全体のボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【0004】
WEBシステムの場合、クライアント上で動作するブラウザ等はキャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。WEBではURLと呼ばれる名前で情報やサービスを指定してアクセスがなされるので、クライアント上のキャッシュは、過去にWEBサーバに要求した情報やサービスの結果として返されるデータのうちでキャッシュ可能なものを、そのURLと対応させてキャッシュに記録している。この場合、キャッシュ内にあるものと同じURLの情報やサービスのリクエストがあった際に、そのキャッシュ内の応答データが古くなっていないと判断できるならば、そのデータを返すことで、WEBサーバとの間の通信を無くすことができる。
【0005】
企業のオフィス内のLANあるいは研究機関におけるLANあるいは家庭内のLANなどで複数のユーザがいる場合、該LANとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。クライアント内のキャッシュ(例えば、ブラウザのキャッシュ)は、当該クライアント・ユーザに専用のキャッシュとして動作するが、LAN上のプロキシサーバのキャッシュは、複数のクライアント・ユーザに共有のキャッシュとして動作する。そのため、後者では、過去に他人(他クライアント)がアクセスしたURLに対してアクセスする際にもキャッシュが効く。
【0006】
さて、WEBにおいて、クライアントとサーバとの間は、HTTPと呼ぶプロトコルで通信が行われる。HTTPプロトコルは、クライアントからサーバへ送る「リクエストメッセージ」と、それに答えてサーバからクライアントへ応答を返す「リプライメッセージ」とが組になっている。
【0007】
リクエストメッセージは、「リクエストヘッダ」と「リクエストボディ」からなる。リクエストヘッダには、アクセスしたい情報やサービスを指定するURLやアクセスの種類を示すメソッド名、その他アクセスに必要な各種の情報が入る。リクエストボディには、サーバに送るデータを入れる。リクエストボディに入っているデータを「リクエストデータ」とも呼ぶ。
【0008】
リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。リプライヘッダには、処理結果のステータスなどの情報が入り、リプライボディには要求された情報や要求されたサービスの処理結果などのデータが入る。リプライボディに入っているデータを「リプライデータ」とも呼ぶ。
【0009】
リクエストメッセージのメソッドとしては、サーバ上の情報を読み出す「GETメソッド」、ユーザの持つデータをサーバに書き込む「PUTメソッド」、リクエストの応じて処理した結果を送り返してもらう「POSTメソッド」が、情報やサービスのアクセスに用いられる主要なものである。その他、DELETEなどのメソッドが定義されている。
【0010】
多くの場合、GETメソッドのリクエストメッセージのリクエストボディ、PUTメソッドのリプライメッセージのリプライボディは空である。POSTメソッドのリクエストメッセージのリクエストボディには、必要に応じてサーバ側での処理に用いる情報が入り、POSTメソッドのリプライメッセージのリプライボディには、その処理の結果のデータが入る。
【0011】
GETメソッドでサーバから読み出すデータは、読み出す毎にサーバ側で生成する「動的データ」と、既にサーバ側で記憶しているデータをそのまま送り返す「静的データ」に分けることができる。これらのうち、動的データについては、同じURLでも読み出す度に内容が異なる可能性があるので、多くの場合、サーバはキャッシュ不可の指定をそのリプライメッセージのヘッダに入れて送り返す。したがって、WEBのデータでキャッシュの対象になるのは、静的データの部分である。この静的データは、不特定多数のユーザが参照して構わない「共有データ」と、ユーザ認証することで特定のユーザだけがアクセスできるようにアクセス制御を行う「プライベートデータ」に分けることができる。前者の共有データは、どのようなキャッシュでもキャッシュ可能である。しかしながら、後者のプライベートデータは、プロキシサーバなどの共有キャッシュでは、キャッシュ不可である(プライベートデータは必ずサーバでユーザを認証して送り返す必要があるので)。ただし、ブラウザなどの個人専用のキャッシュの場合には、プライベートデータでもキャッシュは可能である。
【0012】
POSTメソッドは、サーバ側で処理をした結果を返すので、一般的にサーバはキャッシュ不可の指定をリプライメッセージのヘッダに入れて結果を送り返す。そのため、通常はキャッシュの対象にはならない。
【0013】
PUTメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない。
【0014】
【発明が解決しようとする課題】
従来のWEBのキャッシュは、静的コンテンツをキャッシュの対象にしている。かつては、WEBで公開される情報やサービスには、情報の更新頻度がそれほど高くなく、不特定多数の人に公開されているものが多かったため、静的コンテンツの割合は非常に高く、従来のキャッシュ技術でもネットワークの負荷の軽減に有効であった。
【0015】
しかしながら、WEBベースのASP(Application Service Provider)のように、ユーザがWEBブラウザを使って、ネットワーク経由でサーバ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来のキャッシュ技術では対応できないデータが増加している。
・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデータが多い。
・バックエンドのデータベースを参照して生成する動的データが多い。
・帳票処理や検索などPOSTメソッドを使う場合が多い。
・グループ内の情報共有のためにPUTメソッドを使う場合が多い。
この結果、キャッシュ技術のみではネットワークの負荷を軽減する手法として有効に機能しなくなってきている。
【0016】
本発明は、上記事情を考慮してなされたもので、データ転送装置間を接続するネットワークの負荷をより軽減することができるキャッシュ技術・圧縮技術を備えたサーバ側プロキシ装置、データ転送方法及びプログラムを提供することを目的とする。
【0017】
【課題を解決するための手段】
本発明は、複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するサーバ側プロキシ装置であって、前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信する受信手段と、前記リプライデータのフィンガープリントを生成するフィンガープリント生成手段と、前記フィンガープリント生成手段が生成した前記フィンガープリントを、該フィンガープリントの元であった前記リプライデータに関連付けてフィンガープリント・キャッシュとして保持する保持手段と、前記受信手段が受信したリプライデータに基づいて前記フィンガープリント生成手段が生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信する送信手段とを備えたことを特徴とする。
【0025】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための(あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための)プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【0026】
本発明によれば、サーバ側プロキシ装置とクライアント側プロキシ装置との間でリプライメッセージに含まれるリプライデータとそのフィンガープリントとの対応を保持し、この対応を保持しているリプライデータを含むリプライメッセージについては、リプライデータを転送する代わりに対応するフィンガープリントを転送することで、プロキシ装置間の転送データ量を削減することができる。
【0027】
例えば、GETメソッドのリプライメッセージがプライベートデータであっても、これをフィンガープリントにより圧縮してプロキシ装置間を転送することができるようになる。また、例えば、GETメソッドのリプライメッセージが動的データであっても、内容が同じデータなら、これをフィンガープリントにより圧縮してプロキシ装置間を転送することができるようになる。また、例えば、POSTメソッドであっても、結果が同じデータなら、これをフィンガープリントにより圧縮してプロキシ装置間を転送することができるようになる。
【0028】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【0029】
以下では、WANがインターネットであり、クライアントはユーザオフィスLANに接続されたものであり、HTTPプロトコルが使用されるような場合を例にとって説明するが、もちろん、本発明は、WANがインターネット以外のものであっても、クライアントがオフィス以外の例えば家庭内LAN等に設置されたものであっても、HTTPプロトコル以外のプロトコルが使用されるものであっても適用可能である。
【0030】
図31に本発明を適用するコンピュータ・ネットワーク・システムの基本的な構成例を示す。この構成例では、ASPサーバセンター2内のローカルエリアネットワーク(LAN)12と、ユーザオフィス4内のローカルエリアネットワーク(LAN)16との間が、インターネットや専用回線などの広域ネットワーク(WAN)14を介して接続されており、ASPサーバセンター2内のサーバ20と、ユーザオフィス4内のクライアント50とが、LAN12・WAN14・LAN16を介して通信可能になっている。ASPサーバセンター内LANには1または複数のサーバが接続され、ユーザオフィス内LANには1または複数のクライアントが接続される。
【0031】
WEBベースのASPは、サーバセンター2に設置したサーバ20から、WAN14を介して、様々なアプリケーションプログラムによるサービスを提供し、ユーザはオフィス4に設置されたクライアント上のWEBブラウザ等を使ってそれらのサービスにアクセスする。
【0032】
このような利用形態においては、ユーザオフィス内LAN16とサーバセンター内LAN12とをつなぐネットワーク、特にインターネットなどの広域ネットワーク14の実効的な通信容量(バンド幅)は、サーバセンター内LAN12やユーザオフィス内LAN16よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。
【0033】
そこで、本実施形態では、図1に示すように、サーバセンター内LAN12とユーザオフィス内LAN16とをつなぐ広域ネットワーク14の両端に、サーバ側プロキシ30およびクライアント側プロキシ40という2つのモジュールを設置し、それらの間で後述するフィンガープリント圧縮(FP圧縮)を行って通信データ量を低減することで、広域ネットワークのボトルネックを解消する。
【0034】
本実施形態のサーバ20、サーバ側プロキシ30、クライアント側プロキシ40、クライアント50は、いずれも、計算機上でソフトウェア(サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム)を動作させる形で実現することができる。この場合に、必要に応じて計算機所望の機能を有するOSやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが搭載あるいは接続される。また、この場合に、ユーザあるいは管理者からの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース(GUI)を用いると好ましい。
【0035】
サービスを利用するためにユーザが使用するクライアント50上では、その目的に応じて例えばWEBブラウザ等のプログラムが動作する。ユーザは、例えば、WEBブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。もちろん、WEBブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【0036】
サーバ20上では、所定のサーバ・プログラムが動作し、クライアント20のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【0037】
サーバ側プロキシ30は、図1のように、サーバセンター内LAN12とWAN14との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図2のように、サーバセンター内LAN12上に設置して実施することもできる。また、図3のように、サーバ側プロキシ30の機能をサーバ20に内蔵するように実施することもできる。
【0038】
同様に、クライアント側プロキシ40は、図1のように、ユーザオフィス内LAN16とWAN14との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図2のように、ユーザオフィス内LAN16上に設置して実施することもできる。また、図3のように、クライアント側プロキシ40の機能をクライアント50上で動作するブラウザ等に内蔵するように実施することもできる。あるいは、ブラウザ等の動作するクライアント50上に、個人用のクライアント側プロキシ40を動作させるように実施することもできる。
【0039】
なお、サーバ側プロキシ30とクライアント側プロキシ40とは、図1〜図3などのように同じ形態であってもよいし、異なる形態であってもよい。
【0040】
本実施形態のサーバ側プロキシ30およびクライアント側プロキシ40は、いずれも、フィンガープリント・キャッシュ(FPキャッシュ)と呼ぶキャッシュ機構を持つ。フィンガープリント・キャッシュは、フィンガープリント(FP)と呼ぶ名前によって、HTTPプロトコルでやりとりされるデータを記録・管理する。
【0041】
フィンガープリントは、図4に例示するように、HTTPプロトコルでやり取りされるデータ(図4の例ではコンテンツ)の内容から、あらかじめ決められた計算方法(図4の例ではハッシュ関数)で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【0042】
フィンガープリントを計算する方法としては、良く知られているMD−5やSHA−1などのハッシュ関数を用いることができる。これらのハッシュ関数は、データに対する電子署名などに使われており、任意のデータが与えられると、MD−5の場合は128ビットの数値に、SHA−1の場合は160ビットの数値に、変換することができる。これらのハッシュ関数の特徴は、2つのデータX1,X2が与えられ、データX1とデータX2とが同じであれば、データX1に対して計算したハッシュ値とデータX2に対して計算したハッシュ値とは等しくなるが、異なる2つのデータA,Bが与えられた場合には、データAに対して計算したハッシュ値とデータBに対して計算したハッシュ値とは、非常に高い確率で異なるものになることである(原理上は、異なる2つのデータA,Bに対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい)。
【0043】
図5に示すように、サーバ側プロキシ30やクライアント側プロキシ40の持つフィンガープリント・キャッシュ(図中の60)は、過去にHTTPプロトコルでやり取りされたデータ本体(図中の61)を、そのデータから計算して求めたフィンガープリントの値(図中の62)を名前として、記録・管理している。
【0044】
例えばHTTPプロトコルでサーバ側プロキシ30からクライアント側プロキシ40へデータを転送するときに、サーバ側プロキシ30は、当該データのフィンガープリントを計算し、そのフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていれば、当該データ(と同じ内容のデータ)は過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ40は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出すことで、転送すべきデータを再現することができる。このような方式(すなわち、データ圧縮→データ転送→データ解凍)により、過去に送ったものと同じデータならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。もちろん、クライアント側プロキシ40からサーバ側プロキシ30へデータを転送するときも同様である。
【0045】
説明上、サーバ側プロキシ30とクライアント側プロキシ40との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮(FP圧縮)と呼ぶものとする。
【0046】
なお、サーバ側プロキシ30とクライアント側プロキシ40との間において、すべてのメッセージをFP圧縮を適用する対象(すなわち、フィンガープリント・キャッシュを利用してデータをフィンガープリントに置き換えるための処理を行う対象)としてもよいが、例えばフィンガープリント・キャッシュの効果が期待できないものなどに対する適用を除外するために、予め定められた条件を満たすメッセージについては、これをFP圧縮の適用対象外とする(常にFP圧縮しないで転送する)ようにしてもよい。
この場合の予め定められた条件とは、例えば、メッセージ・ヘッダに予め定められた情報が記述されていることである。具体的には、例えば、メッセージ・ヘッダにGETメソッドを示す情報およびリクエストを示す情報が記述されていることである。また、予め定められた条件の他の例としては、転送されるデータが空(null)あるいは非常に短いサイズであることである。
もちろん、それらの他にも種々のバリエーションがある。また、複数の条件を組み合わせて使用するようにしてもよい。
【0047】
次に、図6〜図10を参照しながら、サーバ側プロキシ30とクライアント側プロキシ40との間でデータ転送する際の(FP圧縮の適用対象のメッセージについての)プロキシ間メッセージ・フォーマットについて説明する。
【0048】
なお、FP圧縮の適用対象外のメッセージは、FP圧縮については、何もせずにそのままの(FP圧縮側(送信側)のプロキシが受信した際の)メッセージ・フォーマットでプロキシ間を転送して構わない。あるいは、FP圧縮側(送信側)のプロキシが、例えばそのメッセージ・ヘッダに当該メッセージがFP圧縮の適用対象外を識別可能とする情報を持つようにして転送することも可能である。
【0049】
さて、サーバ側プロキシ30とクライアント側プロキシ40との間でデータ転送する場合、FP圧縮の適用対象のメッセージには、データがFP圧縮されてフィンガープリントに置き換えられたメッセージ(圧縮時のメッセージ)と、FP圧縮されおらず、データが搭載されているメッセージ(非圧縮時のメッセージ)とがある。
【0050】
非圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータがフィンガープリントキャッシュに登録されていない場合に使用される。一方、圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータがフィンガープリントキャッシュに登録されている場合に使用される。
【0051】
解凍側(受信側)では、非圧縮時のフォーマットのメッセージを受信したことを契機として、当該データについてフィンガープリントキャッシュへの登録を行うことができる。
【0052】
図6に、メッセージ・フォーマットの一例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。
【0053】
(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーにデータの代わりにフィンガープリント(FP)が載せられる。また、この例では、メッセージ・ヘッダに、FP圧縮の有無を識別可能とする識別情報が(圧縮側のプロキシにおいて)記述され、この識別情報に基づいて(解凍側のプロキシにおいて)FP圧縮の有無を識別する(例えば、0ならば圧縮なし、1ならば圧縮あり)。なお、識別情報は、プロキシ間で使用される特別のものであってもよいし、もともと通常のHTTPメッセージ・ヘッダに存在するフィールドを利用あるいは併用したものであってもよい。
【0054】
なお、非圧縮時には、図6(a)の例では、メッセージにフィンガープリントを含ませなかったが、メッセージ・ボディーにデータに加えてフィンガープリントを含ませるようにしてもよいし、または図7に示すように、メッセージ・ヘッダにフィンガープリントを含ませるようにしてもよい。このようにすれば、解凍側で当該データについてフィンガープリント・キャッシュの登録を行う際に、該フィンガープリントを利用することによって、あらためて当該データからフィンガープリントを求める手間が省ける。
【0055】
なお、FP圧縮の適用対象外のメッセージが存在し得る場合には、解凍側(受信側)では、メッセージ・ヘッダに上記の識別情報が含まれるか否かで、FP圧縮の適用対象のメッセージか適用対象外のメッセージかを判断することもできる。また、FP圧縮の適用対象外のメッセージのヘッダにも識別情報を設け、該識別情報によって3種類のメッセージを識別するようにしてもよい(例えば、01ならば適用対象外、10なら(適用対象であって且つ)圧縮なし、11なら(適用対象であって且つ)圧縮あり)。
【0056】
ここで、図32に図6(a)のフォーマットのメッセージの具体例を示し、図33に図6(b)のフォーマットのメッセージの具体例を示す。各図のヘッダ中の“Fingerprint−Mode:…”が識別情報に相当し、図33のボディの“6E39…0128”がフィンガープリントに相当する。
【0057】
また、図34に、図7のフォーマットのメッセージの具体例を示す。ヘッダ中の“Fingerprint:…”がフィンガープリントに相当する。
【0058】
図8に、メッセージ・フォーマットの他の例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーは空(null)である。また、この例では、(a),(b)ともにメッセージ・ヘッダにフィンガープリント(FP)が記述される。FP圧縮の有無を識別可能とする識別情報について上記の例と同様である。
【0059】
なお、この場合に、非圧縮時には図6の(a)と同様のメッセージ・フォーマット(フィンガープリントを含まないフォーマット)を用いる方法もある。
【0060】
なお、FP圧縮の適用対象外のメッセージが存在し得る場合には、上記した識別情報に基づく方法の他に、圧縮側(送信側)のプロキシがFP圧縮の適用対象のメッセージ・ヘッダに常にフィンガープリントを記述する構成の場合には、解凍側(受信側)では、メッセージ・ヘッダにフィンガープリントが含まれるか否かで判断することもできる。
【0061】
ここで、図35に図8(a)のフォーマットのメッセージの具体例を示し、図36に図8(b)のフォーマットのメッセージの具体例を示す。
【0062】
図9に、メッセージ・フォーマットのさらに他の例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーは空(null)である。また、この例では、(a),(b)ともにメッセージ・ヘッダにフィンガープリント(FP)が記述される。ただし、この例では、FP圧縮の有無を識別可能とする識別情報は使用しない。
【0063】
この例では、メッセージ・ボディーが空(null)か否かによって、FP圧縮の有無を識別することができる。ただし、FP圧縮の適用対象外のメッセージでメッセージ・ボディーが空(null)のものが存在し得る場合には、例えば、メッセージ・ヘッダにフィンガープリント(FP)が存在するか否かによって、FP圧縮の適用対象で圧縮時のメッセージか、FP圧縮の適用対象外でメッセージ・ボディーが空(null)のメッセージかを識別する(あるいは、メッセージ・ヘッダにFP圧縮の適用対象か適用対象外かを示す情報を設けてもよい)。
【0064】
なお、非圧縮時には図10に示すようにメッセージにフィンガープリントを記述しないフォーマットを用いる方法もある。この場合には、メッセージ・ヘッダにフィンガープリントが含まれるか否かによって、FP圧縮の有無を識別することができる。ただし、FP圧縮の適用対象外のメッセージが存在し得る場合には、例えば、メッセージ・ヘッダにFP圧縮の適用対象か適用対象外かを示す情報を設ければよい。
【0065】
ここで、図37に図9(a)のフォーマットのメッセージの具体例を示し、図38に図9(b)のフォーマットのメッセージの具体例を示す。
【0066】
また、図39に、図10のフォーマットのメッセージの具体例を示す。
【0067】
以下では、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送するときにそのリプライデータをFP圧縮・解凍する場合を中心に本実施形態について詳しく説明する。
【0068】
図11に本実施形態のサーバ側プロキシ30の構成例を示し、図12に本実施形態のクライアント側プロキシ40の構成例を示す。なお、図11や図12は、サーバ側プロキシ30からクライアント側プロキシ40へデータを転送する際の構成を中心に示してある。
【0069】
図11に示されるように、本サーバ側プロキシ30は、サーバセンター内LAN12または広域ネットワーク14から転送メッセージを受信するための処理を行う受信部31、転送メッセージに含まれるデータに対してFP圧縮を施すための処理部32、サーバセンター内LAN12または広域ネットワーク14へ転送メッセージを送信するための処理を行う送信部33、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ(FPキャッシュ)34を備えている。また、処理部32は、転送メッセージに含まれるデータを圧縮対象とすべきか否かを判定するためのフィンガープリント(FP)圧縮判定部321、フィンガープリント・キャッシュ34に対する検索や登録などを行うためのフィンガープリント・キャッシュ(FPキャッシュ)管理部322、転送メッセージに含まれるデータを対応するフィンガープリントで置き換えるなどの処理を行うためのフィンガープリント(FP)圧縮処理部323を含む。
【0070】
図12に示されるように、本クライアント側プロキシ40は、ユーザオフィス内LAN16または広域ネットワーク14から転送メッセージを受信するための処理を行う受信部41、転送メッセージに含まれるデータに対してFP解凍を施すための処理部42、ユーザオフィス内LAN16または広域ネットワーク14へ転送メッセージを送信するための処理を行う送信部43、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ(FP・キャッシュ)44を備えている。また、処理部42は、転送メッセージに含まれるデータを圧縮対象とすべきか否かおよび転送メッセージに対するFP圧縮の有無を判定するためのフィンガープリント(FP)圧縮判定部421、フィンガープリント・キャッシュ34に対する検索や登録などを行うためのフィンガープリント・キャッシュ(FPキャッシュ)管理部422、FP圧縮された転送メッセージに含まれるフィンガープリントから元のデータを解凍するなどの処理を行うためのフィンガープリント(FP)解凍処理部423を含む。
【0071】
なお、圧縮側のFP圧縮判定部321と解凍側のFP圧縮判定部421は、前述したようにメッセージが予め定められた条件を満たすか否かを調べることによって、そのメッセージに含まれるデータをFP圧縮の適用対象とするか否かを判断する(すべてのメッセージをFP圧縮の適用対象にする場合には、圧縮側のFP圧縮判定部321および後に示す手順例の該当部分は不要であり、解凍側のFP圧縮判定部421の該当判断の部分および後に示す手順例の該当部分は不要である)。また、解凍側のFP圧縮判定部421は、FP圧縮の適用対象のメッセージについて、そのデータがFP圧縮されたものか否かを判定する。以下では、FP圧縮の適用対象となるメッセージを転送する場合(FP圧縮の適用対象とすると判断された場合、またはすべてのメッセージをFP圧縮の適用対象にする場合)を中心に説明する。
【0072】
図13に、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送する際のサーバ側プロキシ30の処理手順の一例を示す。なお、図13は、1つのリプライメッセージを受けたときの処理を記述しているが、実際はサーバ側プロキシ30が受け取ったリプライメッセージ全てに対して、図13に例示する処理を行う。
【0073】
サーバ側プロキシ30は、受信部31により、サーバ20からリプライメッセージを受信する(ステップS1)。
【0074】
FP圧縮判定部321は、該リプライメッセージのリプライデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS2)。リプライデータがFP圧縮対象外のものと判断されたならば(ステップS2)、受信したリプライメッセージを送信部33からクライアント側プロキシ40へ転送する(ステップS9)。
【0075】
ステップS2にて該リプライメッセージのリプライデータがFP圧縮対象のものであると判断されたならば、FPキャッシュ管理部322にて、該リプライデータのフィンガープリントの値を計算し(ステップS3)、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ34を検索する(ステップS4)。
【0076】
そして、該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ34に登録されていたならば(ステップS5)、FP圧縮処理部323にて、受信したリプライメッセージを、該フィンガープリントの値を用いてFP圧縮時のフォーマットにして(例えば図8(b)等)、送信部33から、クライアント側プロキシ40へ送信する(ステップS6)。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド(Content−Length:フィールド)の値を、FP圧縮時のフォーマットにあわせて設定する。
【0077】
一方、ステップS4の検索の結果、該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ34に登録されていなかったならば(ステップS5)、次の2つの作業を行う。
(1)FP圧縮処理部323にて、受信したリプライメッセージを、(必要に応じて該フィンガープリントの値を用いて)非FP圧縮時のフォーマットにして(例えば図8(a)等)、送信部33から、クライアント側プロキシ40へ送信する(ステップS7)。
(2)FPキャッシュ管理部322にて、該フィンガープリントの値と、該リプライデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ34に登録する(ステップS8)。
【0078】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0079】
次に、図14に、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送する際のクライアント側プロキシ40の処理手順の一例を示す。なお、図14は、1つのリクエストメッセージを受けたときの処理を記述しているが、実際はクライアント側プロキシ40が受け取ったリクエストメッセージ全てに対して、図14に例示する処理を行う。
【0080】
クライアント側プロキシ40は、受信部41により、サーバ側プロキシ30からリプライメッセージを受信する(ステップS11)。
【0081】
FP圧縮判定部421は、該リプライメッセージのリプライデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS12)。リプライデータがFP圧縮対象外のものと判断されたならば(ステップS12)、受信したリプライメッセージを送信部43からクライアント50へ転送する(ステップS20)。
【0082】
ステップS12にて該リプライメッセージのリプライデータがFP圧縮対象のものであると判断されたならば、FP圧縮判定部421は、さらに、リプライデータがFP圧縮されているか否か調べ、判断する(ステップS13)。
【0083】
ステップS13にて該リプライメッセージのリプライデータがFP圧縮されているものと判断されたならば(例えば図8(b)等の場合)、FPキャッシュ管理部422にて、該リプライデータのフィンガープリントの値を求め(ステップS14)、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ44を検索する(ステップS15)。
【0084】
そして、FP解凍処理部423にて、受信リプライメッセージに対して、フィンガープリント・キャッシュ34から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部43からクライアント50へ送信する(ステップS16)。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド(Content−Length:フィールド)の値を、該フィンガープリントの値に対応するデータの長さに設定する。
【0085】
一方、ステップS13にて該リプライメッセージのリプライデータがFP圧縮されていないものと判断されたならば(例えば図8(a)等の場合)、次の2つの作業を行う。
(1)FP解凍処理部423にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部43からクライアント50へ送信する(ステップS18)。
(2)FPキャッシュ管理部422にて、該リプライデータのフィンガープリントの値を求め(ステップS17)、該フィンガープリントの値と、該リプライデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ34に登録する(ステップS19)。
【0086】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0087】
ところで、ステップS14では、メッセージにフィンガープリントが記述されている。しかし、ステップS17では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リプライデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リプライデータをもとにフィンガープリントの値を計算する方法も可能である。
また、ステップS14/ステップS17は、ステップS12とステップS13の間にて行うようにしても構わないし、ステップS17は、ステップS18とステップS19の間にて行うようにしても構わない。
【0088】
また、ステップS12の判断とステップS13の判断は、同時に行ってもよい。
【0089】
なお、クライアント側プロキシ40からサーバ側プロキシ30へリクエストメッセージを転送する際にはフィンガープリント・キャッシュを用いないものとする場合には、サーバ側プロキシ30は、図15に例示するように、クライアント側プロキシ40からリクエストメッセージを受信し(ステップS21)、これをサーバ20へ送信する(ステップS22)、という手順で構わない。同様に、クライアント側プロキシ40は、図16に例示するように、クライアント50からリクエストメッセージを受信し(ステップS23)、これをサーバ側プロキシ30へ送信する(ステップS24)、という手順で構わない。
【0090】
以下では、図17(登録時すなわち非FP圧縮時)および図18(FP圧縮時)を参照しながら、フィンガープリント・キャッシュを利用したデータ転送についてより具体的に説明する。
【0091】
まず、図17を参照しながら、サーバ側プロキシ30からクライアント側プロキシ40へ、フィンガープリント・キャッシュ登録されていないデータを転送するとともに、フィンガープリント・キャッシュ登録する場合の動作について説明する。
【0092】
(1)クライアント50上のブラウザ等は、例えば“/A.cgi”というURLでサーバ20に、POSTメソッドのリクエストメッセージを出したとする。サーバ20へのリクエストメッセージは、まず、クライアント側プロキシ40に送られるように、ブラウザ等を設定しておく。
【0093】
(2)クライアント50からリクエストメッセージを受け取ったクライアント側プロキシ40は、そのリクエストメッセージをサーバ側プロキシ30に転送する。
【0094】
(3)リクエストメッセージを受け取ったサーバ側プロキシ30は、そのリクエストメッセージをサーバ50へ転送する。
【0095】
(4)サーバ20は、該リクエストメッセージに対する処理を行った後、サーバ側プロキシ30に、そのリプライメッセージを送り返す。
【0096】
(5)リプライメッセージを受け取ったサーバ側プロキシ30は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがフィンガープリント・キャッシュ34に入っているかどうかを調べる。入っていなければ、初めてのデータ(一旦フィンガープリント・キャッシュ登録されたものがその後に削除あるいは無効化されることがある構成の場合に、一旦フィンガープリント・キャッシュ登録されたが削除あるいは無効化され、その後において初めてである場合を含む)であるので、そのデータをフィンガープリントを名前としてフィンガープリント・キャッシュ34に入れる(登録する)。
【0097】
(6)サーバ側プロキシ30は、リプライメッセージをクライアント側プロキシ40に転送する。
なお、前述したように、リプライデータから計算したフィンガープリントの値を、リプライヘッダ等に入れて送ると、クライアント側プロキシ40で再度フィンガープリントを計算する手間を省くことが出来る。
【0098】
(7)リプライメッセージを受け取ったクライアント側プロキシ40は、初めてのデータであるので、リプライデータをフィンガープリント・キャッシュ44に登録する。
なお、前述したように、リプライデータからフィンガープリントを計算するか、あるいはサーバ側プロキシがリプライヘッダ等に入れたフィンガープリントを取り出し、これを名前として入れる。
【0099】
(8)クライアント側プロキシ40は、(リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ30とクライアント側プロキシ40との間だけで使用される情報が存在する構成の場合には、これを削除した後に、)リプライメッセージを、クライアント50(上で動作するブラウザ等)へ送り返す。
【0100】
なお、サーバ側プロキシ30において、上記の(5)のフィンガープリント・キャッシュ登録は、(6)の動作の後に行っても構わない。また、クライアント側プロキシ40において、(7)のフィンガープリント・キャッシュ登録は、(8)の動作の後に行っても構わない。
【0101】
次に、図18を参照しながら、図17の動作が行われてキャッシュ登録されているデータを、サーバ側プロキシ30からクライアント側プロキシ40へ転送する場合の動作について説明する。
【0102】
(1)〜(4)は、図17を参照して説明した動作における(1)〜(4)と同様である。
【0103】
(5)サーバ50からリプライメッセージを受け取ったサーバ側プロキシ40は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがフィンガープリント・キャッシュ34に入っているかどうかを調べる。入っていれば、過去に送ったことのあるデータ(フィンガープリント・キャッシュ登録されているデータ)なので、(前述したように例えばフィンガープリントの値をリプライヘッダに入れ且つリプライボディを空にするなどして)リプライボディのデータをフィンガープリントで置き換える。
【0104】
(6)サーバ側プロキシ30は、リプライボディをフィンガープリントで置き換えたリプライメッセージをクライアント側プロキシ40に転送する。
【0105】
(7)リプライメッセージを受け取ったクライアント側プロキシ40は、リプライデータがフィンガープリントで置き換えられていることを検出し、(前述したように例えばリプライヘッダなどにて)指定されたフィンガープリントを使ってフィンガープリント・キャッシュ44から対応するデータを取り出し、これをリプライボディに入れる。
【0106】
(8)そして、クライアント側プロキシ30は、(リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ30とクライアント側プロキシ40との間だけで使用される情報が存在する構成の場合には、これを削除した後に、)リプライメッセージを、クライアント(上で動作するブラウザ等)へ送り返す。
【0107】
ところで、サーバ側プロキシ30およびクライアント側プロキシ40のフィンガープリント・キャッシュは、その容量に上限があるため、所定のアルゴリズムに従いガーベジコレクションを行って、例えば古いデータや使いそうに無いデータを消して行くのが好ましい。
【0108】
ただし、このようにすると、サーバ側プロキシ30のフィンガープリント・キャッシュ34は持っていてもクライアント側プロキシ40のフィンガープリント・キャッシュ44では既に消されてしまっているデータが発生し得ることになるので、上記の(7)で、クライアント側プロキシ40において、フィンガープリントをもとにしてフィンガープリント・キャッシュ44からリプライデータを置き換えるべきデータを取り出そうとしたが、フィンガープリント・キャッシュ44に該当するフィンガープリントとデータの組が存在しない場合がある。このような場合には、例えば、クライアント側プロキシ40は、サーバ側プロキシ30に対して、指定したフィンガープリントのデータを送るように依頼し、依頼されたサーバ側プロキシ30は、指定されたフィンガープリントのデータをフィンガープリント・キャッシュ34から取り出して送り返すような仕組みを設ければよい。
【0109】
なお、逆に、サーバ側プロキシ30のフィンガープリント・キャッシュ34では既に消されてしまっているがクライアント側プロキシ40のフィンガープリント・キャッシュ44はまだ持っていてるデータが存在する場合には、図17を参照して説明した動作における(7)で、クライアント側プロキシ40において、フィンガープリント/リプライデータをフィンガープリント・キャッシュ44に登録する際に、その時点で登録されていたフィンガープリント/リプライデータに対して上書きしてもよい。
【0110】
図18を参照して説明した動作における(5)で、サーバ側プロキシ30において、リプライデータのフィンガープリントを求め、該フィンガープリントがフィンガープリント・キャッシュ34に入っていれば、当該リプライデータと同じデータが該フィンガープリントと組になってフィンガープリント・キャッシュ34に入っているものとみなして処理している。実用上、異なるデータから同じフィンガープリントが生成されないことを前提にすれば、この方法で十分であるが、非常に小さな確率で異なるデータのフィンガープリントが偶々同じ値になってしまった場合に生じるエラーを取り除くようにする方法もある。この場合には、リプライデータから求めたフィンガープリントがフィンガープリント・キャッシュ34に入っているときに、該フィンガープリントと組になってフィンガープリント・キャッシュ34に入っているデータと、当該プライデータとを比較して、同じか否かを判断するようにすればよい。このとき、もしフィンガープリントは同じであるが内容が異なるデータが登録されていると判断された場合の処理は、以下に例示するような方法が考えられる。
・そのフィンガープリントは以降使用しないものとする(そのフィンガープリントを与えるデータは以後キャッシュされないことになる)。
・先に登録されているフィンガープリント/データを優先する(登録中のフィンガープリントと同じ値のフィンガープリントを与える他のデータは、その登録中はキャッシュされないことになる)。
・現在登録対象となっているフィンガープリント/データを優先する(登録中のフィンガープリント/データは、同じ値のフィンガープリントを与える他のデータによって次々と更新されていくことになる)。
【0111】
ところで、本実施形態のサーバ側プロキシ30あるいはクライアント側プロキシ40に、後述するURLとフィンガープリントとの対応テーブル(URL・FPテーブル)を設け、これとフィンガープリント・キャッシュとを併用することで、プロキシサーバの共有キャッシュの動作をも行うようにすることができる。この機能は、個々のサーバ側プロキシ30毎に、また個々のクライアント側プロキシ40毎に、設けるか否かを定めることができる。
【0112】
まず、上記機能を設けたクライアント側プロキシ40について説明する。
【0113】
図19に、この場合のクライアント側プロキシ40の構成例を示す。このクライアント側プロキシ40は、図12の構成・機能に加えて、更に過去にアクセスしたURLと、そのリプライデータのフィンガープリントとの対応を保持するURL・フィンガープリント・テーブル(URL・FPテーブル)45と、URLキャッシュ処理部424とを備えている。
【0114】
なお、URL・FPテーブル45には、URLおよびフィンガープリント以外に、そのURLでアクセスしたときにリプライヘッダに入れられて来たMIMEタイプや、有効期間の判定に使うためのタイムスタンプなどの情報も併せて記録する。また、URL・FPテーブル45には、従来の共有キャッシュがキャッシュできる場合にのみ必要な情報を記録する。
【0115】
図20に、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送する際のクライアント側プロキシ40の処理手順の一例を示す。
【0116】
なお、この場合の処理手順は、図14の手順のステップS16およびS19の後に追加される以外は、図14の手順と同じであり、図20では、図14の手順のステップS16およびS19より後の処理手順の部分を示してある。ここでは、図14で説明した手順に追加する部分を中心に説明する。
【0117】
クライアント側プロキシ40は、送信部43により、クライアント50にリプライメッセージを送信(ステップS16またはS18)した後、URLキャッシュ処理部424にて、該リプライメッセージがキャッシュ対象のものであるか否か調べ、判断する(ステップS27)。キャッシュ対象であると判断されたならば、URLキャッシュ処理部424にて、URLとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて(URLをキーにして)をURL・FPテーブル45に登録する(ステップS28)。キャッシュ対象でないと判断されたならば、何もしない。
【0118】
なお、ステップS27の判断およびステップS28のURL・FPテーブルへの登録は、ステップS13とステップS16あるいはS19の間にて行うようにしても構わない。
【0119】
なお、登録時の受信リプライメッセージがキャッシュ対象のものであるか否かの判断方法は、従来の登録時の手法と同様で構わない(例えば、GETメソッドのリプライデータであって、かつ、そのヘッダにキャッシュ不可を示す情報が記述されていないものをキャッシュ対象とする等)。
【0120】
次に、図21に、クライアント50から受信したリクエストメッセージをクライアント側プロキシ40からサーバ側プロキシ30へ転送する際のクライアント側プロキシ40におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【0121】
クライアント側プロキシ40は、受信部41により、クライアント50からリクエストメッセージを受信する(ステップS31)。
【0122】
URLキャッシュ処理部424は、リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであるか否か調べ、判断する(ステップS32)。なお、応答時のキャッシュ対象か否かの判断方法は、従来の応答時の手法と同様で構わない(例えば、受信リクエストメッセージがGETメソッドのものであるか否か)。
【0123】
リクエストデータがキャッシュ対象外のものと判断されたならば(ステップS32)、受信したリクエストメッセージを送信部43からサーバ側プロキシ30へ転送する(ステップS38)。
【0124】
ステップS32にて該リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであると判断されたならば、URLキャッシュ処理部424は、さらに、該リクエストメッセージに指定されているURLを取り出し(ステップS33)、そのURLをキーとしてURL・FPテーブル45を検索する(ステップS34)。
【0125】
そのURLに対応するリプライデータのフィンガープリントがキャッシュされていなければ(ステップS35)、受信したリクエストメッセージを送信部43からサーバ側プロキシ30へ転送する(ステップS38)。このとき、現在保持しているデータのタイムスタンプをリクエストメッセージのIf−Modified−Sinceヘッダに記入してサーバ側プロキシ30へ転送し、サーバ側プロキシ30から現在保持しているデータが有効であるとのリプライメッセージを受け取ると、ステップS37へ行くように実施することもできる。
【0126】
また、そのURLに対応するリプライデータのフィンガープリントが登録されていても(ステップS35)、併せて保持されている有効期間の判定のための情報に基づいてそのデータが無効になっていると判断されれば(ステップS36)、受信したリクエストメッセージを送信部43からサーバ側プロキシ30へ転送する(ステップS38)。
【0127】
一方、そのURLに対応するリプライデータのフィンガープリントが登録されており(ステップS35)、かつ、併せて保持されている有効期間の判定のための情報に基づいてそのデータが有効であると判断されれば(ステップS36)、URLキャッシュ処理部424は、URL・FPテーブル45からリプライデータを構成するのに必要な情報を得るとともに、当該URLに対応するリプライデータのフィンガープリントをキーとしてフィンガープリント・キャッシュ44を検索してリプライデータを取得し、それらをもとにリプライメッセージを生成して、これを送信部43からクライアント50へ転送する(ステップS37)。
【0128】
以下では、図22(応答時)を参照しながら、共有キャッシュの動作についてより具体的に説明する。
【0129】
(1)クライアント50上のブラウザ等は、例えば“/C.html”というURLでサーバ20に、GETメソッドのリクエストメッセージを出したとする。
【0130】
(2)新しいURLでリクエストが来たときに、そのURLがURL・FPテーブル45に載っていれば、従来の共有キャッシュと同様に有効期間の判定を行い、有効と判断できれば、そのURLに対応するフィンガープリントをURL・FPテーブル45を引いて求め、それを名前とするデータをフィンガープリント・キャッシュ44から取り出してリプライデータとし、さらに、URL・FPテーブル45からMIMEタイプ等のリプライヘッダを構成するのに必要な情報を取り出してリプライヘッダを作成する。
【0131】
(3)作成したリプライメッセージを、クライアント20(上で動作するブラウザ等)へ送り返す。
【0132】
なお、キャッシュの内容が指定した時間以降に更新されている場合にのみデータを送ることを依頼するIf−Modified−Sinceヘッダを持ったリクエストメッセージの場合も、まずURL・FPテーブルを参照して更新されていないことが判断できれば、そこでリプライメッセージを作成して返し、そうでなければサーバまで再びIf−Modified−Sinceの情報を書き直して聞きに行くように実施することもできる。
【0133】
次に、キャッシュ機能を設けたサーバ側プロキシ30について説明する。
【0134】
上記ではクライアント側プロキシ40のキャッシュ機能について説明したが、サーバ側プロキシ30も同様に実施可能である。
【0135】
この場合、クライアント側プロキシ40に対するメッセージ転送元のクライアント50とメッセージ転送先のサーバ側プロキシ30が、サーバ側プロキシ30に対してはそれぞれクライアント側プロキシ40(転送元)とサーバ20(転送先)になり、キャッシュに関係する構成・手順は同様である。
【0136】
図23に、この場合のサーバ側プロキシ30の構成例を示す。このサーバ側プロキシ30は、図11の構成・機能に加えて、更に過去にアクセスしたURLと、そのリプライデータのフィンガープリントとの対応を保持するURL・フィンガープリント・テーブル(URL・FPテーブル)35と、URLキャッシュ処理部324とを備えている。
【0137】
図24に、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送する際のサーバ側プロキシ30の処理手順の一例を示す。
【0138】
なお、この場合の処理手順は、図13の手順のステップS6およびS8の後に追加される以外は、図13の手順と同じであり、図24では、図13の手順のステップS6およびS8より後の処理手順の部分を示してある。ここでは、図13で説明した手順と相違する部分を中心に説明する。
【0139】
サーバ側プロキシ30は、送信部33により、クライアント側プロキシ40にリプライメッセージを送信(ステップS6またはS8)した後、URLキャッシュ処理部324にて、該リプライメッセージのリプライデータがキャッシュ対象のものであるか否か調べ、判断する(ステップS39−2)。キャッシュ対象であると判断されたならば、URLキャッシュ処理部324にて、URLとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて(URLをキーにして)をURL・FPテーブル35に登録する(ステップS39−3)。キャッシュ対象でないと判断されたならば、何もしない。
【0140】
もちろん、前述と同様に、この手順も種々変形することが可能である。
【0141】
図25に、クライアント側プロキシ40から受信したリクエストメッセージをサーバ側プロキシ30からサーバ20へ転送する際のサーバ側プロキシ30におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【0142】
この場合の処理手順は、基本的には図21の手順と同様である。なお、図21のS37ではリプライデータを作成してクライアント50へ転送するが、これに対応する図25のS47ではFP圧縮時のフォーマット(例えば図8(b)等)でリプライデータを作成してクライアント側プロキシ40へ転送することになる。
【0143】
このように、サーバ側プロキシにもURL・FPテーブル表を持ってキャッシュの処理をする構成は、一つのサーバ側プロキシが複数のクライアント側プロキシから使われているときに有効に働く。すなわち、あるクライアント側プロキシから要求のあったキャッシュ可能なデータが既に他のクライアント側プロキシによってアクセスされている場合には、サーバ側プロキシにもキャッシュされているので、そのデータを送り返すだけで処理が完了する。
【0144】
なお、以上では、URL・FPテーブル表をフィンガープリント・キャッシュとは別途に設ける場合について説明したが、URL・FPテーブル表をフィンガープリント・キャッシュと一体化して構成することも可能である。
【0145】
さて、これまで説明した例では、サーバ側プロキシ30からクライアント側プロキシ40へリプライデータを転送するときに、該リプライデータがフィンガープリント・キャッシュに登録されているデータと同じものである場合には、該リプライデータに代えて、対応するフィンガープリントを転送することで、ネットワークのトラフィックを軽減しているが、FP圧縮は、クライアント側プロキシ40からサーバ側プロキシ30へリクエストデータを転送する場合についてさらに適用することが可能である。なお、FP圧縮を、クライアント側プロキシ240からサーバ側プロキシ230へリクエストデータを転送する場合についてのみ適用することも可能である。
【0146】
また、FP圧縮を該リクエストデータ転送のみに適用した場合、FP圧縮を該リプライデータ転送のみに適用した場合、FP圧縮を該リクエストデータ転送および該リプライデータ転送に適用した場合のいずれにおいても、リクエストメッセージが指定するURLに対応するリプライデータに対する共用キャッシュ機能に関する構成をクライアント側プロキシのみに設けることも、サーバ側プロキシのみに設けることも、両プロキシに設けることも可能である。
【0147】
FP圧縮をクライアント側プロキシ40からサーバ側プロキシ30へのリクエストデータ転送に適用する場合、すでに説明したリプライデータに対するサーバ側プロキシ30とクライアント側プロキシ40との役割を逆にすればよいので、FP圧縮を両データ転送に適用する場合には、サーバ側プロキシ30は図11の構成に加えて、更に処理部32にフィンガープリント解凍処理部を備え、クライアント側プロキシ40は図12の構成に加えて、更に処理部42にフィンガープリント圧縮処理部を備えればよい。
【0148】
なお、いずれのプロキシにおいても、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せて、フィンガープリント(FP)圧縮・解凍処理部としてもよい。
【0149】
また、サーバ側プロキシ30やクライアント側プロキシ40は、リプライデータ転送に対するフィンガープリント・キャッシュとは独立にリクエストデータ転送に対するフィンガープリント・キャッシュを設けてもよいが、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用してもよい。
【0150】
図26に、この場合のプロキシ(サーバ側プロキシ、クライアント側プロキシ)の構成例を示す。
【0151】
また、図27に、クライアント側プロキシ40からサーバ側プロキシ30へリクエストメッセージを転送する際のクライアント側プロキシ40の処理手順の一例を示す。
【0152】
クライアント側プロキシ40は、受信部41により、クライアント50からリクエストメッセージを受信する(ステップS51)。
【0153】
FP圧縮判定部421は、該リクエストメッセージのリクエストデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS52)。リクエストデータがFP圧縮対象外のものと判断されたならば(ステップS52)、受信したリクエストメッセージを送信部43からサーバ側プロキシ30へ転送する(ステップS59)。
【0154】
ステップS52にて該リクエストメッセージのリクエストデータがFP圧縮対象のものであると判断されたならば、FPキャッシュ管理部422にて、該リクエストデータのフィンガープリントの値を計算し(ステップS53)、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ44を検索する(ステップS54)。
【0155】
そして、該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ44に登録されていたならば(ステップS55)、FP圧縮・解凍処理部425にて、受信したリクエストメッセージを、該フィンガープリントの値を用いてFP圧縮時のフォーマットにして(例えば図8(b)等)、送信部43から、サーバ側プロキシ30へ送信する(ステップS56)。
【0156】
一方、ステップS54の検索の結果、該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ44に登録されていなかったならば(ステップS55)、次の2つの作業を行う。
(1)FP圧縮・解凍処理部425にて、受信したリクエストメッセージを、(必要に応じて該フィンガープリントの値を用いて)非FP圧縮時のフォーマットにして(例えば図8(a)等)、送信部43から、サーバ側プロキシ30へ送信する(ステップS57)。
(2)FPキャッシュ管理部422にて、該フィンガープリントの値と、該リクエストデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ44に登録する(ステップS58)。
【0157】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0158】
次に、図28に、クライアント側プロキシ40からサーバ側プロキシ30へリクエストメッセージを転送する際のサーバ側プロキシ30の処理手順の一例を示す。
【0159】
サーバ側プロキシ30は、受信部31により、クライアント側プロキシ40からリクエストメッセージを受信する(ステップS61)。
【0160】
FP圧縮判定部321は、該リクエストメッセージのリクエストデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS62)。リクエストデータがFP圧縮対象外のものと判断されたならば(ステップS62)、受信したリクエストメッセージを送信部33からサーバ20へ転送する(ステップS70)。
【0161】
ステップS62にて該リクエストメッセージのリクエストデータがFP圧縮対象のものであると判断されたならば、FP圧縮判定部321は、さらに、リクエストデータがFP圧縮されているか否か調べ、判断する(ステップS63)。
【0162】
ステップS63にて該リクエストメッセージのリクエストデータがFP圧縮されているものと判断されたならば(例えば図8(b)等の場合)、FPキャッシュ管理部322にて、該リクエストデータのフィンガープリントの値を求め(ステップS64)、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ34を検索する(ステップS65)。
【0163】
そして、FP圧縮・解凍処理部325にて、受信リプライメッセージに対して、フィンガープリント・キャッシュ34から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部33からサーバ20へ送信する(ステップS66)。
【0164】
一方、ステップS63にて該リクエストメッセージのリクエストデータがFP圧縮されていないものと判断されたならば(例えば図8(a)等の場合)、次の2つの作業を行う。
(1)FP圧縮・解凍処理部325にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部33からサーバ20へ送信する(ステップS68)。
(2)FPキャッシュ管理部322にて、該リクエストデータのフィンガープリントの値を求め(ステップS67)、該フィンガープリントの値と、該リクエストデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ34に登録する(ステップS69)。
【0165】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0166】
前述と同様、ステップS67では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リクエストデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リクエストデータをもとにフィンガープリントの値を計算する方法も可能である。
また、ステップS64/ステップS67は、ステップS62とステップS63の間にて行うようにしても構わないし、ステップS67は、ステップS68とステップS69の間にて行うようにしても構わない。
【0167】
また、ステップS62の判断とステップS63の判断は、同時に行ってもよい。
【0168】
このようにリクエストデータに対してもフィンガープリントで置き換えられるように実施すると、例えば、同じファイルを何度もサーバにアップロードする際ときには、2回目以降フィンガープリントを送るだけで済むので、ネットワークのトラフィックを軽減させることができる。
【0169】
もちろん、この場合に、前述したクライアントが送信したリクエストメッセージが指定するURLに対応するリプライデータに対する共用キャッシュ機能に関する構成をサーバ側プロキシやクライアント側プロキシに対して併せて実施することも可能である。この場合のプロキシ(サーバ側プロキシ、クライアント側プロキシ)の構成例を図29に示す。この場合のサーバ側プロキシやクライアント側プロキシの動作は既に説明したものと同様である。
【0170】
なお、本実施形態では、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージや、サーバ側プロキシからクライアント側プロキシへ転送されるリプライメッセージを対象とする場合について示してきたが、あるプロキシに、リクエストメッセージを送信する装置とリプライメッセージを送信する装置との両方、あるいはリクエストメッセージおよびリプライメッセージの両方を送信する装置が接続されている場合には、もちろん、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージおよびリプライメッセージならびにサーバ側プロキシからクライアント側プロキシへ転送されるリクエストメッセージおよびリプライメッセージを対象とすることや、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージおよびサーバ側プロキシからクライアント側プロキシへ転送されるリクエストメッセージのみ対象とすることなども可能である。
【0171】
ところで、これまでは1つのサーバ側プロキシと1つのクライアント側プロキシとの間の1対1の通信に着目して説明してきたが、本発明の適用範囲はもちろんサーバ側プロキシとクライアント側プロキシとが1対1で通信するシステムには限定されるものではないく、サーバ側プロキシとクライアント側プロキシとが1対多で通信するシステム、サーバ側プロキシとクライアント側プロキシとが多対1で通信するシステム、あるいはサーバ側プロキシとクライアント側プロキシとが多対多で通信するシステムにも適用可能である。例えば、図30のように、複数のユーザオフィスに設置したクライアント側プロキシや、モバイルユーザが利用する個人用プロキシなどがサーバ側プロキシを共有して使用するように実施することも可能である。
【0172】
また、これまでは、1つのメッセージに含まれるデータ全体をFP圧縮する対象(フィンガープリント・キャッシュに登録する対象)にしていたが、例えば、1つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、1つのメッセージに含まれる一部の単位データのみFP圧縮する対象(フィンガープリント・キャッシュに登録する対象)にする構成も可能である。
【0173】
なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための(あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための)プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【0174】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ2以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【0175】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【0176】
【発明の効果】
本発明によれば、プロキシ装置間でリプライデータとそのフィンガープリントとの対応を保持し、この対応を保持しているリプライデータについては、データを転送する代わりに対応するフィンガープリントを転送することで、プロキシ装置間の転送データ量を削減することができる。
【図面の簡単な説明】
【図1】本発明の一実施形態に係るコンピュータ・ネットワーク・システムの構成例を示す図
【図2】同実施形態に係るコンピュータ・ネットワーク・システムの他の構成例を示す図
【図3】同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図
【図4】同実施形態で使用するフィンガープリントについて説明するための図
【図5】同実施形態で使用するフィンガープリント・キャッシュについて説明するための図
【図6】同実施形態で使用するメッセージ・フォーマットの一例を示す図
【図7】同実施形態で使用するメッセージ・フォーマットの他の例を示す図
【図8】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図9】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図10】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図11】同実施形態に係るサーバ側プロキシの構成例を示す図
【図12】同実施形態に係るクライアント側プロキシの構成例を示す図
【図13】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図14】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図15】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図16】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図17】同実施形態に係るサーバ側プロキシとクライアント側プロキシとの間のデータ転送について説明するための図
【図18】同実施形態に係るサーバ側プロキシとクライアント側プロキシとの間のデータ転送について説明するための図
【図19】同実施形態に係るクライアント側プロキシの他の構成例を示す図
【図20】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図21】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図22】同実施形態に係るクライアントとクライアント側プロキシとの間のデータ転送について説明するための図
【図23】同実施形態に係るサーバ側プロキシの他の構成例を示す図
【図24】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図25】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図26】同実施形態にプロキシのさらに他の構成例を示す図
【図27】同実施形態に係るクライアント側プロキシのさらに他の手順例を示すフローチャート
【図28】同実施形態に係るサーバ側プロキシのさらに他の手順例を示すフローチャート
【図29】同実施形態にプロキシのさらに他の構成例を示す図
【図30】同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図
【図31】従来のコンピュータ・ネットワーク・システムについて説明するための図
【図32】図6(a)のフォーマットのメッセージの具体例を示す図
【図33】図6(b)のフォーマットのメッセージの具体例を示す図
【図34】図7のフォーマットのメッセージの具体例を示す図
【図35】図8(a)のフォーマットのメッセージの具体例を示す図
【図36】図8(b)のフォーマットのメッセージの具体例を示す図
【図37】図9(a)のフォーマットのメッセージの具体例を示す図
【図38】図9(b)のフォーマットのメッセージの具体例を示す図
【図39】図10のフォーマットのメッセージの具体例を示す図
【符号の説明】
2…ASPサーバセンター
4…ユーザオフィス
12…ASPサーバセンター内LAN
14…WAN
16…ユーザオフィス内LAN
20…サーバ装置
30…サーバ側プロキシ装置
40…クライアント側プロキシ装置
50…クライアント装置
31,41…受信部
32,42…処理部
33,43…送信部
34,44…フィンガープリント・キャッシュ
35,45…URL・FPテーブル
321,421…FP圧縮判定部
322,422…フィンガープリント・キャッシュ管理部
323…FP圧縮処理部
423…FP解凍処理部
324,424…URLキャッシュ処理部
325,425…FP解凍・解凍処理部
Claims (7)
- 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するサーバ側プロキシ装置であって、
前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信する受信手段と、
前記リプライデータのフィンガープリントを生成するフィンガープリント生成手段と、
前記フィンガープリント生成手段が生成した前記フィンガープリントを、該フィンガープリントの元であった前記リプライデータに関連付けてフィンガープリント・キャッシュとして保持する保持手段と、
前記受信手段が受信したリプライデータに基づいて前記フィンガープリント生成手段が生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、
前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信する送信手段とを備えたことを特徴とするサーバ側プロキシ装置。 - 前記送信手段は、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記リプライデータを前記フィンガープリントと共に前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とする請求項1に記載のサーバ側プロキシ装置。
- 前記送信手段は、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合であってかつ前記リプライデータがNullでない場合に、前記フィンガープリントと前記リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とする請求項1に記載のサーバ側プロキシ装置。
- 前記受信手段は、ローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項1に記載のサーバ側プロキシ装置。
- 前記所定のリクエストデータは、GETメソッドのリクエストメッセージであることを特徴とする請求項1に記載のサーバ側プロキシ装置。
- 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するものであるとともに、該リプライデータのフィンガープリントを、該リプライデータに関連付けてフィンガープリント・キャッシュとして保持するための保持手段を備えたサーバ側プロキシ装置のデータ転送方法であって、
前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、
前記リプライデータのフィンガープリントを生成し、
受信したリプライデータに基づいて生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定し、
前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とするデータ転送方法。 - 複数のクライアント装置それぞれから複数のサーバ装置宛に送信され、複数のクライアント装置それぞれの前記複数のサーバ装置へのアクセスの代理を担当するクライアント側プロキシ装置に中継された、複数のリクエストデータを受信して前記複数のサーバのうち該リクエストデータの宛先たるサーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを該リプライデータの宛先たるクライアント装置の代理であるクライアント側プロキシ装置へ転送するサーバ側プロキシ装置としてコンピュータを機能させるためのプログラムであって、
前記クライアント側プロキシ装置から転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信する受信機能と、
前記リプライデータのフィンガープリントを生成するフィンガープリント生成機能と、
前記フィンガープリント生成機能が生成した前記フィンガープリントを、該フィンガープリントの元であった前記リプライデータに関連付けてフィンガープリント・キャッシュとして保持する保持機能と、
前記受信機能が受信したリプライデータに基づいて前記フィンガープリント生成機能が生成した前記フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定機能と、
前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定機能が判定した場合に、該フィンガープリントの元であったリプライデータの代わりに該フィンガープリントを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信し、前記フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定機能が判定した場合に、前記フィンガープリントと該フィンガープリントの元であったリプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記リプライデータを前記リクエストデータの送信元の前記クライアント装置宛として前記クライアント側プロキシ装置へ送信する送信機能とをコンピュータに機能させるためのプログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001069284A JP3983987B2 (ja) | 2001-03-12 | 2001-03-12 | サーバ側プロキシ装置、データ転送方法及びプログラム |
US10/092,540 US7054912B2 (en) | 2001-03-12 | 2002-03-08 | Data transfer scheme using caching technique for reducing network load |
US11/353,935 US7636765B2 (en) | 2001-03-12 | 2006-02-15 | Data transfer scheme using caching technique for reducing network load |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001069284A JP3983987B2 (ja) | 2001-03-12 | 2001-03-12 | サーバ側プロキシ装置、データ転送方法及びプログラム |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007032640A Division JP4031516B2 (ja) | 2007-02-13 | 2007-02-13 | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム |
JP2007154496A Division JP4041157B2 (ja) | 2007-06-11 | 2007-06-11 | クライアント側プロキシ装置、データ転送方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002268935A JP2002268935A (ja) | 2002-09-20 |
JP3983987B2 true JP3983987B2 (ja) | 2007-09-26 |
Family
ID=18927339
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001069284A Expired - Fee Related JP3983987B2 (ja) | 2001-03-12 | 2001-03-12 | サーバ側プロキシ装置、データ転送方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3983987B2 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4642697B2 (ja) | 2006-05-24 | 2011-03-02 | Necディスプレイソリューションズ株式会社 | 画像キャッシュメモリを有する画像表示装置 |
JP4607937B2 (ja) * | 2007-10-31 | 2011-01-05 | 株式会社東芝 | キャッシュ方法及びキャッシュ装置 |
JP4607936B2 (ja) * | 2007-10-31 | 2011-01-05 | 株式会社東芝 | データ転送方法及びデータ転送システム |
US8943023B2 (en) | 2010-12-29 | 2015-01-27 | Amazon Technologies, Inc. | Receiver-side data deduplication in data systems |
US9116909B2 (en) | 2010-12-29 | 2015-08-25 | Amazon Technologies, Inc. | Reduced bandwidth data uploading in data systems |
SG191378A1 (en) * | 2010-12-29 | 2013-08-30 | Amazon Tech Inc | Receiver-side data deduplication in data systems |
JP6028567B2 (ja) | 2012-12-28 | 2016-11-16 | 富士通株式会社 | データ格納プログラム、データ検索プログラム、データ格納装置、データ検索装置、データ格納方法及びデータ検索方法 |
-
2001
- 2001-03-12 JP JP2001069284A patent/JP3983987B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002268935A (ja) | 2002-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3990115B2 (ja) | サーバ側プロキシ装置及びプログラム | |
US7636765B2 (en) | Data transfer scheme using caching technique for reducing network load | |
US7383348B2 (en) | Data transfer scheme using caching technique for reducing network load | |
US8024484B2 (en) | Caching signatures | |
EP1908213B1 (en) | A secure method of synchronizing cache contents of a mobile browser with a server field | |
EP1405224B1 (en) | System and method for pushing data from an information source to a mobile communication device including transcoding of the data | |
JP3984086B2 (ja) | キャッシュサーバ、データ転送装置及びプログラム | |
JP3848209B2 (ja) | データ転送装置、データ転送方法及びプログラム | |
JP4031516B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP3983987B2 (ja) | サーバ側プロキシ装置、データ転送方法及びプログラム | |
JP4053269B2 (ja) | データ転送装置およびデータ転送方法 | |
JP3943867B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
JP3943868B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
JP4041157B2 (ja) | クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP2003108464A (ja) | データ転送装置およびデータ転送方法 | |
JP3913508B2 (ja) | データ転送装置およびデータ転送方法 | |
JP3977601B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
JP4157585B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP3977651B2 (ja) | データ転送方法、サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
JP2006216081A (ja) | データ転送装置およびデータ転送方法 | |
WO2008034149A2 (en) | Data hosting and dissemination system for mobile devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061212 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070213 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070410 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070611 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070703 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070705 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100713 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100713 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110713 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120713 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130713 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |