JP3943868B2 - サーバ側プロキシ、データ転送方法及びプログラム - Google Patents
サーバ側プロキシ、データ転送方法及びプログラム Download PDFInfo
- Publication number
- JP3943868B2 JP3943868B2 JP2001179016A JP2001179016A JP3943868B2 JP 3943868 B2 JP3943868 B2 JP 3943868B2 JP 2001179016 A JP2001179016 A JP 2001179016A JP 2001179016 A JP2001179016 A JP 2001179016A JP 3943868 B2 JP3943868 B2 JP 3943868B2
- Authority
- JP
- Japan
- Prior art keywords
- fingerprint
- side proxy
- server
- client
- data
- 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】
【課題を解決するための手段】
本発明は、クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシであって、クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、さらに、前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信手段と、前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、さらに前記或リプライデータのハッシュ値と前記サーバ側プロキシ識別情報とを含むフィンガープリントである或フィンガープリントを生成するフィンガープリント生成手段と、前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持する保持手段と、前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信する送信手段とを備えることを特徴とする。
【0023】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための(あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための)プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【0024】
本発明によれば、サーバ装置側に設けられたサーバ側プロキシは、クライアント装置側に設けられたクライアント側プロキシから該クライアント装置が該サーバ装置へ宛てて発したリクエストデータを受信してサーバ装置へ転送した後に、該サーバ装置が該クライアント装置へ宛てて発した該リクエストデータへの返答であるリプライデータを受信してクライアント側プロキシへ転送するにあたって、受信したリプライデータから生成した、該リプライデータのハッシュ値と該サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを、該リプライデータに関連付けて、フィンガープリント・キャッシュに保持しておくことによって、サーバ装置からリプライデータを受信した場合に、そのフィンガープリントがフィンガープリント・キャッシュに保持されているリプライデータについては、該リプライデータを転送する代わりに対応するフィンガープリントを転送することで、それらサーバ側プロキシとクライアント側プロキシとの間の転送データ量を削減することができる。また、フィンガープリントは、リプライデータのハッシュ値と、該フィンガープリントを生成して転送するサーバ側プロキシのサーバ側プロキシ識別情報とを含むようにしてあるので、サーバ側プロキシとクライアント側プロキシとが多対1で接続される際に、クライアント側プロキシが複数のサーバ側プロキシからそれぞれフィンガープリントを受信した場合に、それらを送信したサーバ側プロキシが異なれば、リプライデータのフィンガープリントが異なることになるので、リプライデータの内容が違うにもかかわらずそのフィンガープリントが一致してしまうようなことはなく、リプライデータとフィンガープリントとの対応の一貫性を維持することができる。
【0026】
また、本発明によれば、例えば、GETメソッドのリプライメッセージがプライベートデータであっても、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。また、例えば、GETメソッドのリプライメッセージが動的データであっても、内容が同じデータなら、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。また、例えば、POSTメソッドであっても、結果が同じデータなら、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。
【0027】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【0028】
以下では、WANがインターネットであり、クライアントはユーザオフィスLANに接続されたものであり、HTTPプロトコルが使用されるような場合を例にとって説明するが、もちろん、本発明は、WANがインターネット以外のものであっても、クライアントがオフィス以外の例えば家庭内LAN等に設置されたものであっても、HTTPプロトコル以外のプロトコルが使用されるものであっても適用可能である。
【0029】
図28に本発明を適用するコンピュータ・ネットワーク・システムの基本的な構成例を示す。この構成例では、ASPサーバセンター2内のローカルエリアネットワーク(LAN)12と、ユーザオフィス4内のローカルエリアネットワーク(LAN)16との間が、インターネットや専用回線などの広域ネットワーク(WAN)14を介して接続されており、ASPサーバセンター2内のサーバ20と、ユーザオフィス4内のクライアント50とが、LAN12・WAN14・LAN16を介して通信可能になっている。ASPサーバセンター内LANには1または複数のサーバが接続され、ユーザオフィス内LANには1または複数のクライアントが接続される。
【0030】
WEBベースのASPは、サーバセンター2に設置したサーバ20から、WAN14を介して、様々なアプリケーションプログラムによるサービスを提供し、ユーザはオフィス4に設置されたクライアント上のWEBブラウザ等を使ってそれらのサービスにアクセスする。
【0031】
なお、ASPサーバセンター2や、ユーザオフィス4は、複数存在し得る。
【0032】
このような利用形態においては、ユーザオフィス内LAN16とサーバセンター内LAN12とをつなぐネットワーク、特にインターネットなどの広域ネットワーク14の実効的な通信容量(バンド幅)は、サーバセンター内LAN12やユーザオフィス内LAN16よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。
【0033】
そこで、本実施形態では、図1に示すように、サーバセンター内LAN12とユーザオフィス内LAN16とをつなぐ広域ネットワーク14の両端に、サーバ側プロキシ30およびクライアント側プロキシ40という2つのモジュールを設置し、それらの間で後述するフィンガープリント圧縮(FP圧縮)を行って通信データ量を低減することで、広域ネットワークのボトルネックを解消する。
【0034】
なお、ここでは、複数のサーバ側プロキシ30と1つのクライアント側プロキシ40との間の通信にFP圧縮を適用する場合を考えている(1つのサーバ側プロキシ30は(ある時点において)1つのクライアント側プロキシ40とFP圧縮を適用した通信を行う場合を考える)。複数のサーバ側プロキシ30と複数のクライアント側プロキシ40との通信にFP圧縮を適用する場合については後述する。
【0035】
本実施形態のサーバ20、サーバ側プロキシ30、クライアント側プロキシ40、クライアント50は、いずれも、計算機上でソフトウェア(サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム)を動作させる形で実現することができる。この場合に、必要に応じて計算機に所望の機能を有するOSやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが搭載あるいは接続される。また、この場合に、ユーザあるいは管理者からの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース(GUI)を用いると好ましい。
【0036】
サービスを利用するためにユーザが使用するクライアント50上では、その目的に応じて例えばWEBブラウザ等のプログラムが動作する。ユーザは、例えば、WEBブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。もちろん、WEBブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【0037】
サーバ20上では、所定のサーバ・プログラムが動作し、クライアント50のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【0038】
サーバ側プロキシ30は、図1のように、サーバセンター内LAN12とWAN14との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図2のように、サーバセンター内LAN12上に設置して実施することもできる。また、図3のように、サーバ側プロキシ30の機能をサーバ20に内蔵するように実施することもできる。
【0039】
同様に、クライアント側プロキシ40は、図1のように、ユーザオフィス内LAN16とWAN14との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図2のように、ユーザオフィス内LAN16上に設置して実施することもできる。また、図3のように、クライアント側プロキシ40の機能をクライアント50上で動作するブラウザ等に内蔵するように実施することもできる。あるいは、ブラウザ等の動作するクライアント50上に、個人用のクライアント側プロキシ40を動作させるように実施することもできる。
【0040】
なお、各サーバ側プロキシ30及び各クライアント側プロキシ40は、例えば図1〜図3などのように、すべて同じ形態のものであってもよい。また、例えば、あるサーバ側プロキシ30は図1の形態で、あるサーバ側プロキシ30は図2の形態で、あるクライアント側プロキシ40は図1の形態で、あるクライアント側プロキシ40は図3の形態で、というように、異なる形態のものが混在していてもよい。
【0041】
また、クライアント側プロキシ40は、モバイル端末もしくはモバイル計算機等に内蔵されたものであってもよい。図4に、この場合の一例を示す。
【0042】
さて、本実施形態のサーバ側プロキシ30およびクライアント側プロキシ40は、いずれも、フィンガープリント・キャッシュ(FPキャッシュ)と呼ぶキャッシュ機構を持つ。フィンガープリント・キャッシュは、フィンガープリント(FP)と呼ぶ名前によって、HTTPプロトコルでやりとりされるデータを記録・管理する。
【0043】
図5に、サーバ側プロキシ30とクライアント側プロキシ40との間で交換されるフィンガープリントのデータ構造例を示す。この場合、フィンガープリントは、当該フィンガープリントの発行元となるサーバ側プロキシ30のサーバ側プロキシ識別情報からなる部分(サーバ側プロキシ識別情報)と、コンテンツの内容をもとに求められる情報からなる部分(コンテンツ依存情報)とを含む。
【0044】
サーバ側プロキシ識別情報は、ユニークにサーバ側プロキシを特定できる情報であり、例えば、IPアドレスやMACアドレス、ホストIDなどを用いることができる。
【0045】
コンテンツ依存情報は、コンテンツの内容に依存する情報であり、詳しくは後述するように、例えば、コンテンツからハッシュ値として求められる値である。
【0046】
フィンガープリントにサーバ側プロキシ識別情報を含ませることで、サーバ側プロキシが異なれば、コンテンツ依存情報が同じでもフィンガープリントが異なることになるので、データの内容が違うにもかかわらずその名前が一致してしまうようなことはなく、データと名前との対応の一貫性を維持することができる。
【0047】
以下では、フィンガープリントのコンテンツ依存情報について説明する。
【0048】
フィンガープリントのコンテンツ依存情報は、図6に例示するように、HTTPプロトコルでやり取りされるデータ(図6の例ではコンテンツ)の内容から、あらかじめ決められた計算方法(図6の例ではハッシュ関数)で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【0049】
フィンガープリントのコンテンツ依存情報を計算する方法としては、良く知られている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に対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい)。
【0050】
図7に示すように、サーバ側プロキシ30の持つフィンガープリント・キャッシュ(図中の60)は、過去にHTTPプロトコルでやり取りされたデータ本体(図中の61)を、自身のサーバ側プロキシ識別情報の値と、該データから計算して求めたコンテンツ依存情報の値とからなるフィンガープリント(図中の62)を名前として、記録・管理している。他方、クライアント側プロキシ40の持つフィンガープリント・キャッシュも、サーバ側プロキシ30の持つフィンガープリント・キャッシュと同様のフォーマットであるが、フィンガープリントのサーバ側プロキシ識別情報の部分には、通信相手となる当該サーバ側プロキシ30のサーバ側プロキシ識別情報が記述されていることになる(ただし、クライアント側プロキシ40は、サーバ側プロキシ30から渡されたフィンガープリントを元のデータに置き換える際に、特にサーバ側プロキシ識別情報を意識する必要はない)。
【0051】
例えばHTTPプロトコルでサーバ側プロキシ30からクライアント側プロキシ40へデータを転送するときに、サーバ側プロキシ30は、当該データのフィンガープリントのコンテンツ依存情報を計算し、自身のサーバ側プロキシ識別情報と該コンテンツ依存情報からなるフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていれば、当該データ(と同じ内容のデータ)は過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ40は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出すことで、転送すべきデータを再現することができる。このような方式(すなわち、データ圧縮→データ転送→データ解凍)により、過去に送ったものと同じデータならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。
【0052】
なお、クライアント側プロキシ40は、フィンガープリント・キャッシュへの登録時に、サーバ側プロキシ30からのメッセージ内にフィンガープリントが記述されてあって且つ該記述されているフィンガープリントを使用する構成と、サーバ側プロキシ30からのメッセージ内にフィンガープリントが記述されてなく且つ自身でフィンガープリントを計算する構成と、サーバ側プロキシ30からのメッセージ内にフィンガープリントが記述されてあって且つ自身であらためてフィンガープリントを計算する構成とがあるが、登録時に自身でフィンガープリントを計算する構成においては、通信相手となる当該サーバ側プロキシ30のサーバ側プロキシ識別情報を求めるとともに、当該データからコンテンツ依存情報を求め、それらからフィンガープリントを生成することになる。なお、サーバ側プロキシ識別情報は、例えば、リクエストメッセージ送信時の要求転送先プロキシの情報(例えば、IPアドレス等)から特定することができる。
【0053】
説明上、サーバ側プロキシ30とクライアント側プロキシ40との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮(FP圧縮)と呼ぶものとする。
【0054】
なお、サーバ側プロキシ30とクライアント側プロキシ40との間において、すべてのメッセージをFP圧縮を適用する対象(すなわち、フィンガープリント・キャッシュを利用してデータをフィンガープリントに置き換えるための処理を行う対象)としてもよいが、例えばフィンガープリント・キャッシュの効果が期待できないものなどに対する適用を除外するために、予め定められた条件を満たすメッセージについては、これをFP圧縮の適用対象外とする(常にFP圧縮しないで転送する)ようにしてもよい。
この場合の予め定められた条件とは、例えば、メッセージ・ヘッダに予め定められた情報が記述されていることである。具体的には、例えば、メッセージ・ヘッダにGETメソッドを示す情報およびリクエストを示す情報が記述されていることである。また、予め定められた条件の他の例としては、転送されるデータが空(null)あるいは非常に短いサイズであることである。
もちろん、それらの他にも種々のバリエーションがある。また、複数の条件を組み合わせて使用するようにしてもよい。
なお、このようなFP圧縮の適用対象に関する設定内容は、例えば、システム全体で同一にする方法や、サーバ側プロキシ30とクライアント側プロキシ40との対ごとに取り決める方法などがある。また、後者の場合には、予め設定しておく方法や、セッション毎に設定する方法などがある。
【0055】
次に、図8〜図12を参照しながら、サーバ側プロキシ30とクライアント側プロキシ40との間でデータ転送する際の(FP圧縮の適用対象のメッセージについての)プロキシ間メッセージ・フォーマットについて説明する。
【0056】
なお、FP圧縮の適用対象外のメッセージは、FP圧縮については、何もせずにそのままの(FP圧縮側(送信側)のプロキシが受信した際の)メッセージ・フォーマットでプロキシ間を転送して構わない。あるいは、FP圧縮側(送信側)のプロキシが、例えばそのメッセージ・ヘッダに当該メッセージがFP圧縮の適用対象外を識別可能とする情報を持つようにして転送することも可能である。
【0057】
さて、サーバ側プロキシ30とクライアント側プロキシ40との間でデータ転送する場合、FP圧縮の適用対象のメッセージには、データがFP圧縮されてフィンガープリントに置き換えられたメッセージ(圧縮時のメッセージ)と、FP圧縮されていない、データが搭載されているメッセージ(非圧縮時のメッセージ)とがある。
【0058】
非圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータがフィンガープリント・キャッシュに登録されていない場合に使用される。一方、圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータがフィンガープリント・キャッシュに登録されている場合に使用される。
【0059】
解凍側(受信側)では、非圧縮時のフォーマットのメッセージを受信したことを契機として、当該データについてフィンガープリント・キャッシュへの登録を行うことができる。
【0060】
図8に、メッセージ・フォーマットの一例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。
【0061】
(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーにデータの代わりにフィンガープリント(FP)が載せられる。また、この例では、メッセージ・ヘッダに、FP圧縮の有無を識別可能とする識別情報が(圧縮側のプロキシにおいて)記述され、この識別情報に基づいて(解凍側のプロキシにおいて)FP圧縮の有無を識別する(例えば、0ならば圧縮なし、1ならば圧縮あり)。なお、識別情報は、プロキシ間で使用される特別のものであってもよいし、もともと通常のHTTPメッセージ・ヘッダに存在するフィールドを利用あるいは併用したものであってもよい。
【0062】
なお、非圧縮時には、図8(a)の例では、メッセージにフィンガープリントを含ませなかったが、メッセージ・ボディーにデータに加えてフィンガープリントを含ませるようにしてもよいし、または図9に示すように、メッセージ・ヘッダにフィンガープリントを含ませるようにしてもよい。このようにすれば、解凍側で当該データについてフィンガープリント・キャッシュの登録を行う際に、該フィンガープリントを利用することによって、あらためて当該データからフィンガープリントを求める手間が省ける。
【0063】
なお、FP圧縮の適用対象外のメッセージが存在し得る場合には、解凍側(受信側)では、メッセージ・ヘッダに上記の識別情報が含まれるか否かで、FP圧縮の適用対象のメッセージか適用対象外のメッセージかを判断することもできる。また、FP圧縮の適用対象外のメッセージのヘッダにも識別情報を設け、該識別情報によって3種類のメッセージを識別するようにしてもよい(例えば、01ならば適用対象外、10なら(適用対象であって且つ)圧縮なし、11なら(適用対象であって且つ)圧縮あり)。
【0064】
図10に、メッセージ・フォーマットの他の例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーは空(null)である。また、この例では、(a),(b)ともにメッセージ・ヘッダにフィンガープリント(FP)が記述される。FP圧縮の有無を識別可能とする識別情報について上記の例と同様である。
【0065】
なお、この場合に、非圧縮時には図8の(a)と同様のメッセージ・フォーマット(フィンガープリントを含まないフォーマット)を用いる方法もある。
【0066】
なお、FP圧縮の適用対象外のメッセージが存在し得る場合には、上記した識別情報に基づく方法の他に、圧縮側(送信側)のプロキシがFP圧縮の適用対象のメッセージ・ヘッダに常にフィンガープリントを記述する構成の場合には、解凍側(受信側)では、メッセージ・ヘッダにフィンガープリントが含まれるか否かで判断することもできる。
【0067】
図11に、メッセージ・フォーマットのさらに他の例を示す。(a)は非圧縮時のメッセージであり、(b)は圧縮時のメッセージである。(a)ではメッセージ・ボディーにデータが載せられ、(b)ではメッセージ・ボディーは空(null)である。また、この例では、(a),(b)ともにメッセージ・ヘッダにフィンガープリント(FP)が記述される。ただし、この例では、FP圧縮の有無を識別可能とする識別情報は使用しない。
【0068】
この例では、メッセージ・ボディーが空(null)か否かによって、FP圧縮の有無を識別することができる。ただし、FP圧縮の適用対象外のメッセージでメッセージ・ボディーが空(null)のものが存在し得る場合には、例えば、メッセージ・ヘッダにフィンガープリント(FP)が存在するか否かによって、FP圧縮の適用対象で圧縮時のメッセージか、FP圧縮の適用対象外でメッセージ・ボディーが空(null)のメッセージかを識別する(あるいは、メッセージ・ヘッダにFP圧縮の適用対象か適用対象外かを示す情報を設けてもよい)。
【0069】
なお、非圧縮時には図12に示すようにメッセージにフィンガープリントを記述しないフォーマットを用いる方法もある。この場合には、メッセージ・ヘッダにフィンガープリントが含まれるか否かによって、FP圧縮の有無を識別することができる。ただし、FP圧縮の適用対象外のメッセージが存在し得る場合には、例えば、メッセージ・ヘッダにFP圧縮の適用対象か適用対象外かを示す情報を設ければよい。
【0070】
なお、以上の各フォーマット例において、サーバ側プロキシ識別情報として、リプライデータのヘッダ内にもともと存在する送信元情報(例えば、IPアドレス等)を利用できる場合には、フィンガープリントの部分に、コンテンツ依存情報のみを記述するフォーマットを使用し、クライアント側プロキシでサーバ側プロキシ識別情報とコンテンツ依存情報を組み合わせてフィンガープリントとすることも可能である。
【0071】
以下では、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送するときにそのリプライデータをFP圧縮・解凍する場合を中心に本実施形態について詳しく説明する。
【0072】
図13に本実施形態のサーバ側プロキシ30の構成例を示し、図14に本実施形態のクライアント側プロキシ40の構成例を示す。なお、図13や図14は、サーバ側プロキシ30からクライアント側プロキシ40へデータを転送する際の構成を中心に示してある。
【0073】
図13に示されるように、本サーバ側プロキシ30は、サーバセンター内LAN12または広域ネットワーク14から転送メッセージを受信するための処理を行う受信部31、転送メッセージに含まれるデータに対してFP圧縮を施すための処理部32、サーバセンター内LAN12または広域ネットワーク14へ転送メッセージを送信するための処理を行う送信部33、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ(FPキャッシュ)34を備えている。また、処理部32は、転送メッセージに含まれるデータを圧縮対象とすべきか否かを判定するためのフィンガープリント(FP)圧縮判定部321、フィンガープリント・キャッシュ34に対する検索や登録などを行うためのフィンガープリント・キャッシュ(FPキャッシュ)管理部322、転送メッセージに含まれるデータを対応するフィンガープリントで置き換えるなどの処理を行うためのフィンガープリント(FP)圧縮処理部323を含む。
【0074】
図14に示されるように、本クライアント側プロキシ40は、ユーザオフィス内LAN16または広域ネットワーク14から転送メッセージを受信するための処理を行う受信部41、転送メッセージに含まれるデータに対してFP解凍を施すための処理部42、ユーザオフィス内LAN16または広域ネットワーク14へ転送メッセージを送信するための処理を行う送信部43、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ(FP・キャッシュ)44を備えている。また、処理部42は、転送メッセージに含まれるデータを圧縮対象とすべきか否かおよび転送メッセージに対するFP圧縮の有無を判定するためのフィンガープリント(FP)圧縮判定部421、フィンガープリント・キャッシュ34に対する検索や登録などを行うためのフィンガープリント・キャッシュ(FPキャッシュ)管理部422、FP圧縮された転送メッセージに含まれるフィンガープリントから元のデータを解凍するなどの処理を行うためのフィンガープリント(FP)解凍処理部423を含む。
【0075】
なお、圧縮側のFP圧縮判定部321と解凍側のFP圧縮判定部421は、前述したようにメッセージが予め定められた条件を満たすか否かを調べることによって、そのメッセージに含まれるデータをFP圧縮の適用対象とするか否かを判断する(すべてのメッセージをFP圧縮の適用対象にする場合には、圧縮側のFP圧縮判定部321および後に示す手順例の該当部分は不要であり、解凍側のFP圧縮判定部421の該当判断の部分および後に示す手順例の該当部分は不要である)。また、解凍側のFP圧縮判定部421は、FP圧縮の適用対象のメッセージについて、そのデータがFP圧縮されたものか否かを判定する。以下では、FP圧縮の適用対象となるメッセージを転送する場合(FP圧縮の適用対象とすると判断された場合、またはすべてのメッセージをFP圧縮の適用対象にする場合)を中心に説明する。
【0076】
図15に、サーバ側プロキシ30が、クライアント側プロキシ40からリクエストメッセージを受信してから、当該クライアント側プロキシ40へリプライメッセージを転送するまでのサーバ側プロキシ30の処理手順の一例を示す。
【0077】
図15は、サーバ側プロキシ30のクライアント側プロキシ40からの1回のリクエストに応じた処理を記述しているが、例えば、複数のクライアント側プロキシ40から同時にリクエストメッセージを受ける場合には、それぞれのリクエストを受け取る都度、図15の処理を並行して行う。
【0078】
なお、図15は、クライアント側プロキシ40からサーバ側プロキシ30へのリクエストメッセージの転送ではFP圧縮を行わず、サーバ側プロキシ30からクライアント側プロキシ40へのリプライメッセージの転送ではFP圧縮を利用する場合の手順例である。
【0079】
サーバ側プロキシ30は、要求元のクライアント50に対応するクライアント側プロキシ40から、リクエストメッセージを受信すると(ステップS1)、これを宛先となるサーバ20へ送信する(ステップS2)。この時点で、当該1対のリクエストメッセージ及びリプライメッセージに対する処理としては、一旦、該当するリプライメッセージの受信を待つ状態に入ることになる。
【0080】
さて、その後、サーバ側プロキシ30は、受信部31により、サーバ20からリプライメッセージを受信すると(ステップS3)、まず、FP圧縮判定部321にて、該リプライメッセージのリプライデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS4)。リプライデータがFP圧縮対象外のものと判断されたならば(ステップS4)、受信したリプライメッセージを送信部33からクライアント側プロキシ40へ転送する(ステップS10)。
【0081】
ステップS4にて該リプライメッセージのリプライデータがFP圧縮対象のものであると判断されたならば、FPキャッシュ管理部322にて、該リプライデータのフィンガープリントのコンテンツ依存情報の値を計算し(ステップS5)、自身のサーバ側プロキシ識別情報を該コンテンツ依存情報に付加してフィンガープリントを求める(ステップS6)。そして、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ34を検索する(ステップS7)。
【0082】
該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ34に登録されていたならば(ステップS8)、FP圧縮処理部323にて、受信したリプライメッセージを、該フィンガープリントの値を用いてFP圧縮時のフォーマットにして(例えば図10(b)等)、送信部33から、当該クライアント側プロキシ40へ送信する(ステップS9)。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド(Content−Length:フィールド)の値を、FP圧縮時のフォーマットにあわせて設定する。
【0083】
一方、ステップS7の検索の結果、該フィンガープリントの値とこれに対応するデータとの組がフィンガープリント・キャッシュ34に登録されていなかったならば(ステップS8)、次の2つの作業を行う。
(1)FP圧縮処理部323にて、受信したリプライメッセージを、(必要に応じて該フィンガープリントの値を用いて)非FP圧縮時のフォーマットにして(例えば図10(a)等)、送信部33から、当該クライアント側プロキシ40へ送信する(ステップS11)。
(2)FPキャッシュ管理部322にて、該フィンガープリントの値と、該リプライデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ34に登録する(ステップS12)。
【0084】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0085】
図16に、クライアント側プロキシ40が、クライアント50からリクエストメッセージを受信してから、当該クライアント50へリプライメッセージを転送するまでのクライアント側プロキシ40の処理手順の一例を示す。
【0086】
図16は、クライアント側プロキシ40のクライアント50からの1回のリクエストに応じた処理を記述しているが、例えば、複数のクライアント50から同時にリクエストメッセージを受ける場合には、それぞれのリクエストを受け取る都度、図16の処理を並行して行う。
【0087】
なお、図16は、クライアント側プロキシ40からサーバ側プロキシ30へのリクエストメッセージの転送ではFP圧縮を行わず、サーバ側プロキシ30からクライアント側プロキシ40へのリプライメッセージの転送ではFP圧縮を利用する場合の手順例である。
【0088】
クライアント側プロキシ40は、要求元のクライアント50から、リクエストメッセージを受信すると(ステップS21)、これを宛先となるサーバ20に対応するサーバ側プロキシ30へ送信する(ステップS22)。この時点で、当該1対のリクエストメッセージ及びリプライメッセージに対する処理としては、一旦、該当するリプライメッセージの受信を待つ状態に入ることになる。
【0089】
さて、その後、クライアント側プロキシ40は、受信部41により、サーバ側プロキシ30からリプライメッセージを受信すると(ステップS23)、まず、FP圧縮判定部421にて、該リプライメッセージのリプライデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS24)。リプライデータがFP圧縮対象外のものと判断されたならば(ステップS24)、受信したリプライメッセージを送信部43からクライアント50へ転送する(ステップS32)。
【0090】
ステップS24にて該リプライメッセージのリプライデータがFP圧縮対象のものであると判断されたならば、FP圧縮判定部421は、さらに、リプライデータがFP圧縮されているか否か調べ、判断する(ステップS25)。
【0091】
ステップS25にて該リプライメッセージのリプライデータがFP圧縮されているものと判断されたならば(例えば図10(b)等の場合)、FPキャッシュ管理部422にて、該リプライデータのフィンガープリントの値を求め(ステップS26)、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ44を検索する(ステップS27)。
【0092】
そして、FP解凍処理部423にて、受信リプライメッセージに対して、フィンガープリント・キャッシュ44から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部43からクライアント50へ送信する(ステップS28)。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド(Content−Length:フィールド)の値を、該フィンガープリントの値に対応するデータの長さに設定する。
【0093】
一方、ステップS25にて該リプライメッセージのリプライデータがFP圧縮されていないものと判断されたならば(例えば図10(a)等の場合)、次の2つの作業を行う。
(1)FP解凍処理部423にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部43からクライアント50へ送信する(ステップS30)。
(2)FPキャッシュ管理部422にて、該リプライデータのフィンガープリントの値を求め(ステップS29)、該フィンガープリントの値と、該リプライデータとを対応付けて(フィンガープリントの値をキーにして)、フィンガープリント・キャッシュ44に登録する(ステップS31)。
【0094】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0095】
ところで、ステップS26では、メッセージにフィンガープリントが記述されている。しかし、ステップS29では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リプライデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リプライデータをもとにフィンガープリントの値を計算する方法も可能である。
また、ステップS26/ステップS29は、ステップS24とステップS25の間にて行うようにしても構わないし、ステップS29は、ステップS30とステップS31の間にて行うようにしても構わない。
【0096】
また、ステップS24の判断とステップS25の判断は、同時に行ってもよい。
【0097】
次に、図17に、サーバ側プロキシ30からクライアント側プロキシ40へ、フィンガープリント・キャッシュ登録されていないデータを転送するとともに、フィンガープリント・キャッシュ登録する場合の動作例を示す。
【0098】
(1)クライアント50上のブラウザ等は、例えば“/A.cgi”というURLでサーバ20に、POSTメソッドのリクエストメッセージを出したとする。サーバ20へのリクエストメッセージは、まず、クライアント側プロキシ40に送られるように、ブラウザ等を設定しておく。
【0099】
(2),(3)クライアント側プロキシ40及び宛先となるサーバ20に対応するサーバ側プロキシ30により、該リクエストメッセージは、サーバ20へ転送される。
【0100】
(4)サーバ20は、該リクエストメッセージに対する処理を行った後、当該サーバ側プロキシ30に、そのリプライメッセージを転送する。
【0101】
(5),(6)サーバ側プロキシ30は、受信したリプライメッセージのリプライデータが初めてのデータであるので、リプライデータをフィンガープリント・キャッシュ34に登録するとともに、該リプライメッセージを要求元のクライアント50に対応するクライアント側プロキシ40へ転送する。
【0102】
(7),(8)クライアント側プロキシ40は、受信したリプライメッセージのリプライデータが初めてのデータであるので、該リプライデータをもとにフィンガープリントを求め、該リプライデータとともに、フィンガープリント・キャッシュ44に登録する。そして、該リプライメッセージを要求元のクライアント50(上で動作するブラウザ等)へ転送する。
【0103】
続いて、図18に、図17の動作が行われてキャッシュ登録されているデータを、サーバ側プロキシ30からクライアント側プロキシ40へ転送する場合の動作例を示す。
【0104】
(1)〜(4)は、図17を参照して説明した動作における(1)〜(4)と同様である。
【0105】
(5),(6)サーバ側プロキシ40は、サーバ20から受け取ったリプライメッセージのリプライデータをフィンガープリントで置き換え、要求元のクライアント50に対応するクライアント側プロキシ40へ転送する。
【0106】
(7),(8)クライアント側プロキシ40は、リプライメッセージのリプライデータ
がフィンガープリントで置き換えられていることを検出し、指定されたフィンガープリントを使ってフィンガープリント・キャッシュ44から対応するデータを取り出し、これをリプライボディに入れた後に、該リプライメッセージを要求元のクライアント50(上で動作するブラウザ等)へ転送する。
【0107】
これまでは複数のサーバ側プロキシと1つのクライアント側プロキシとの間の多対1の通信に着目して説明してきたが、本発明は、サーバ側プロキシとクライアント側プロキシとが多対多で通信するシステムにも適用可能である。
【0108】
以下では、サーバ側プロキシとクライアント側プロキシとが多対多で通信するシステムについて説明する。なお、以下では、これまでと相違する点を中心に説明する。
【0109】
図19〜図21に、この場合に前述した図1〜図3にそれぞれ対応するコンピュータ・ネットワーク・システムの構成例を示す。
【0110】
サーバ20、サーバ側プロキシ装置30、クライアント側プロキシ装置40、クライアント装置50の基本的な機能は、これまで説明したものと同様である。
【0111】
前述と同様に、各サーバ側プロキシ30及び各クライアント側プロキシ40は、例えば図19〜図21などのように、すべて同じ形態のものであってもよいし、異なる形態のものが混在していてもよい。また、図4のように、クライアント側プロキシ40がモバイル端末もしくはモバイル計算機等に内蔵されたものであってもよい。
【0112】
以下、この場合のサーバ側プロキシ30の構成、動作について説明する。なお、クライアント側プロキシ40の構成例は、基本的には、図14と同様である。また、サーバ側プロキシ30からクライアント側プロキシ40へリプライメッセージを転送する際のクライアント側プロキシ40の処理手順の一例は、基本的には、図16と同様である。
【0113】
図22に、サーバ側プロキシ30の構成例を示す。
【0114】
この構成例は、図13/図15の構成例に、FP圧縮を適用する通信を行う相手となるクライアント側プロキシ40毎に、フィンガープリントとデータとの対応を管理する機能を付加したものである。
【0115】
すなわち、例えば、HTTPプロトコルでサーバ側プロキシ30からクライアント側プロキシ40へFP圧縮対象のデータを転送するときに、サーバ側プロキシ30は、当該データのフィンガープリント(自身のサーバ側プロキシ識別情報及び該データに対応するコンテンツ依存情報)を求め、そのフィンガープリントに対応するデータが、「当該クライアント側プロキシ40に対応する」フィンガープリント・キャッシュに入っていれば、当該データ(と同じ内容のデータ)は「当該クライアント側プロキシ40に対して」過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。一方、そのフィンガープリントに対応するデータが、「当該クライアント側プロキシ40に対応する」フィンガープリント・キャッシュに入っていなければ、当該データ(と同じ内容のデータ)は「当該クライアント側プロキシ40に対して」過去に転送したことがないので、当該データを転送するとともに、「当該クライアント側プロキシ40に対応する」フィンガープリント・キャッシュへの登録を行う。
【0116】
なお、サーバ側プロキシ30は、例えば、所定の通信規約に従って、サーバ20から受信したデータを転送すべきクライアント側プロキシ40を特定することができる。
【0117】
さて、FPキャッシュ管理部322は、FP圧縮を適用する通信を行う相手となるクライアント側プロキシ40毎に、フィンガープリントとデータとの対応を管理する。その形態には種々のバリエーションがあるが、以下、その幾つかについて説明する(なお、図22は、論理的にクライアント側プロキシ40毎にFPキャッシュ34が設けられる様子を表している)。
【0118】
(1)図23は、クライアント側プロキシ40毎にハッシュテーブルを設けるとともに、フィンガープリントに対応するデータも、クライアント側プロキシ40毎に保持する(同一コンテンツでもクライアント側プロキシ毎にそのコピーを持つ)構成例である。この場合、FPキャッシュ管理部322では、データの転送先となるクライアント側プロキシ40に対応するFPキャッシュ34を特定し、そのFPキャッシュ34に該データに対応するフィンガープリントが保持されているか否かをチェックすることになる。
【0119】
(2)図24は、ハッシュテーブルはクライアント側プロキシ40毎に設けるが、同一のコンテンツは一つしか持たず、そのポインター情報をハッシュテーブルに保持する(なお、クライアント側プロキシ40が異なり且つフィンガープリントの値が同じでも、元のデータの内容が異なる場合には、それぞれのデータを保持することになる)構成例である。この場合、FPキャッシュ管理部322では、データの転送先となるクライアント側プロキシ40に対応するFPキャッシュ34を特定し、そのFPキャッシュ34に該データに対応するフィンガープリントが保持されているか否かをチェックすることになる。
【0120】
(3)図25は、クライアント側プロキシ40毎にはFPキャッシュ34を設けない代わりに、ハッシュテーブルに、当該フィンガープリントに対応するデータの転送先となるクライアント側プロキシを識別するクライアント側プロキシ識別情報を追加して、クライアント側プロキシ識別情報とフィンガープリントの値の対からなるようにした構成例である。なお、図25では、(2)のように同一のコンテンツは一つしか持たず、そのポインター情報をハッシュテーブルに保持する構成例を示しているが、その代わりに、(1)のように、各エントリ毎にデータを保持する構成例も可能である。クライアント側プロキシ識別情報は、ユニークにクライアント側プロキシを識別できる情報であり、例えば、IPアドレスやMACアドレス、ホストID、チャネル識別子、あるいはそれらを一意に特定可能な情報などを用いることができる。この場合、FPキャッシュ管理部322では、データの転送先となるクライアント側プロキシ40のクライアント側プロキシ識別情報を特定し、FPキャッシュ34に、該クライアント側プロキシ識別情報と該データに対応するフィンガープリントとの対が保持されているか否かをチェックすることになる。
【0121】
(4)図26は、クライアント側プロキシ40毎にはFPキャッシュ34を設けず、ハッシュテーブルに、フィンガープリントの値に対応して、該フィンガープリントを利用可能なクライアント側プロキシ識別情報群を保持するようにした構成例である。この場合、FPキャッシュ管理部322では、データの転送先となるクライアント側プロキシ40のクライアント側プロキシ識別情報を特定し、FPキャッシュ34に、該データに対応するフィンガープリントが保持されているか否か、およびそのフィンガープリントに対するクライアント側プロキシ識別情報群に該クライアント側プロキシ識別情報が保持されているか否かをチェックすることになる。
【0122】
図27に、サーバ側プロキシ30が、クライアント側プロキシ40からリクエストメッセージを受信してから、当該クライアント側プロキシ40へリプライメッセージを転送するまでのサーバ側プロキシ30の処理手順の一例を示す。
【0123】
図27は、サーバ側プロキシ30のクライアント側プロキシ40からの1回のリクエストに応じた処理を記述しているが、例えば、複数のクライアント側プロキシ40から同時にリクエストメッセージを受ける場合には、それぞれのリクエストを受け取る都度、図17の処理を並行して行う。
【0124】
なお、図27は、クライアント側プロキシ40からサーバ側プロキシ30へのリクエストメッセージの転送ではFP圧縮を行わず、サーバ側プロキシ30からクライアント側プロキシ40へのリプライメッセージの転送ではFP圧縮を利用する場合の手順例である。
【0125】
以下では、要求元のクライアント側プロキシとは、1対のリクエストメッセージ及びリプライメッセージに対する処理において、当該要求元のクライアントに対応するクライアント側プロキシ、すなわち、リクエストメッセージの送信元且つリプライメッセージの受信先となるクライアント側プロキシを意味するものとする。
【0126】
サーバ側プロキシ30は、複数存在するクライアント側プロキシ中の或る1つのクライアント側プロキシ(すなわち、要求元のクライアント側プロキシ)40から、リクエストメッセージを受信すると(ステップS41)、これを宛先となるサーバ20へ送信する(ステップS42)。この時点で、当該1対のリクエストメッセージ及びリプライメッセージに対する処理としては、一旦、該当するリプライメッセージの受信を待つ状態に入ることになる。
【0127】
さて、その後、サーバ側プロキシ30は、受信部31により、サーバ20からリプライメッセージを受信すると(ステップS43)、まず、FP圧縮判定部321にて、該リプライメッセージのリプライデータがFP圧縮対象のものであるか否か調べ、判断する(ステップS44)。リプライデータがFP圧縮対象外のものと判断されたならば(ステップS44)、受信したリプライメッセージを送信部33からクライアント側プロキシ40へ転送する(ステップS50)。
【0128】
ステップS44にて該リプライメッセージのリプライデータがFP圧縮対象のものであると判断されたならば、FPキャッシュ管理部322にて、該リプライデータのフィンガープリントのコンテンツ依存情報の値を計算し(ステップS45)、自身のサーバ側プロキシ識別情報を該コンテンツ依存情報に付加してフィンガープリントを求める(ステップS46)。そして、該フィンガープリントの値をキーとして、要求元のクライアント側プロキシ40に対応するフィンガープリント・キャッシュ34を検索する(ステップS47)。
【0129】
該フィンガープリントの値とこれに対応するデータとの組が、当該要求元のクライアント側プロキシ40に対応するフィンガープリント・キャッシュ34に登録されていたならば(ステップS48)、FP圧縮処理部323にて、受信したリプライメッセージを、該フィンガープリントの値を用いてFP圧縮時のフォーマットにして(例えば図10(b)等)、送信部33から、当該要求元のクライアント側プロキシ40へ送信する(ステップS49)。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド(Content−Length:フィールド)の値を、FP圧縮時のフォーマットにあわせて設定する。
【0130】
一方、ステップS47の検索の結果、該フィンガープリントの値とこれに対応するデータとの組が、当該要求元のクライアント側プロキシ40に対応するフィンガープリント・キャッシュ34に登録されていなかったならば(ステップS48)、次の2つの作業を行う。
(1)FP圧縮処理部323にて、受信したリプライメッセージを、(必要に応じて該フィンガープリントの値を用いて)非FP圧縮時のフォーマットにして(例えば図10(a)等)、送信部33から、当該要求元のクライアント側プロキシ40へ送信する(ステップS51)。
(2)FPキャッシュ管理部322にて、該フィンガープリントの値と、該リプライデータとを対応付けて(フィンガープリントの値をキーにして)、当該要求元のクライアント側プロキシ40に対応するフィンガープリント・キャッシュ34に登録する(ステップS52)。
【0131】
なお、上記の(1)と(2)は、いずれを先に行ってもよいし、並行して行ってもよい。
【0132】
さて、これまで説明した例では、サーバ側プロキシ30からクライアント側プロキシ40へリプライデータを転送するときに、該リプライデータがフィンガープリント・キャッシュに登録されているデータと同じものである場合には、該リプライデータに代えて、対応するフィンガープリントを転送することで、ネットワークのトラフィックを軽減しているが、FP圧縮は、クライアント側プロキシ40からサーバ側プロキシ30へリクエストデータを転送する場合についてさらに適用することが可能である。なお、FP圧縮を、クライアント側プロキシ40からサーバ側プロキシ30へリクエストデータを転送する場合についてのみ適用することも可能である。
【0133】
FP圧縮をクライアント側プロキシ40からサーバ側プロキシ30へのリクエストデータ転送に適用する場合、すでに説明したリプライデータに対するサーバ側プロキシ30とクライアント側プロキシ40との役割を逆にすればよい。FP圧縮を両データ転送に適用する場合には、サーバ側プロキシ30及びクライアント側プロキシ40は、いずれも、フィンガープリント解凍処理部及びフィンガープリント圧縮処理部(または、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せたフィンガープリント(FP)圧縮・解凍処理部)を備えればよい。また、この場合に、サーバ側プロキシ30やクライアント側プロキシ40では、リプライデータ転送に対するフィンガープリント・キャッシュとは独立にリクエストデータ転送に対するフィンガープリント・キャッシュを設けてもよいが、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用してもよい。
【0134】
なお、本実施形態では、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージや、サーバ側プロキシからクライアント側プロキシへ転送されるリプライメッセージを対象とする場合について示してきたが、あるプロキシに、リクエストメッセージを送信する装置とリプライメッセージを送信する装置との両方、あるいはリクエストメッセージおよびリプライメッセージの両方を送信する装置が接続されている場合には、もちろん、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージおよびリプライメッセージならびにサーバ側プロキシからクライアント側プロキシへ転送されるリクエストメッセージおよびリプライメッセージを対象とすることや、クライアント側プロキシからサーバ側プロキシへ転送されるリクエストメッセージおよびサーバ側プロキシからクライアント側プロキシへ転送されるリプライメッセージのみ対象とすることなども可能である。
【0135】
ところで、これまでは、1つのメッセージに含まれるデータ全体をFP圧縮する対象(フィンガープリント・キャッシュに登録する対象)にしていたが、例えば、1つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、1つのメッセージに含まれる一部の単位データのみFP圧縮する対象(フィンガープリント・キャッシュに登録する対象)にする構成も可能である。
【0136】
なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための(あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための)プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【0137】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ2以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【0138】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【0139】
【発明の効果】
本発明によれば、サーバ装置側に設けられたサーバ側プロキシは、クライアント装置側に設けられたクライアント側プロキシから該クライアント装置が該サーバ装置へ宛てて発したリクエストデータを受信してサーバ装置へ転送した後に、該サーバ装置が該クライアント装置へ宛てて発した該リクエストデータへの返答であるリプライデータを受信してクライアント側プロキシへ転送するにあたって、受信したリプライデータから生成した、該リプライデータのハッシュ値と該サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを、該リプライデータに関連付けて、フィンガープリント・キャッシュに保持しておくことによって、サーバ装置からリプライデータを受信した場合に、そのフィンガープリントがフィンガープリント・キャッシュに保持されているリプライデータについては、該リプライデータを転送する代わりに対応するフィンガープリントを転送することで、それらサーバ側プロキシとクライアント側プロキシとの間の転送データ量を削減することができる。
【図面の簡単な説明】
【図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】従来のコンピュータ・ネットワーク・システムについて説明するための図
【符号の説明】
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 (5)
- クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシのデータ転送方法であって、
クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、
前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、
前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持し、
前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータを、前記サーバ装置から受信し、
前記或リプライデータのフィンガープリントである或フィンガープリントを生成し、
前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定し、
前記判定にて、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると判定された場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、
前記判定にて、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと判定された場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信することを特徴とするデータ転送方法。 - クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシであって、
クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、さらに、前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信手段と、
前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、さらに前記或リプライデータのハッシュ値と前記サーバ側プロキシ識別情報とを含むフィンガープリントである或フィンガープリントを生成するフィンガープリント生成手段と、
前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持する保持手段と、
前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、
前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信する送信手段とを備えることを特徴とするサーバ側プロキシ。 - 前記クライアント側プロキシは、第1のローカルエリアネットワークを介して前記クライアント装置と接続されたものであり、前記サーバ側プロキシは、第2のローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項2に記載のサーバ側プロキシ。
- 前記クライアント側プロキシと前記サーバ側プロキシとは、インターネットを介して接続されたものであることを特徴とする請求項2に記載のサーバ側プロキシ。
- クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシとしてコンピュータを機能させるためのプログラムであって、
クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、さらに、前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信機能と、
前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、さらに前記或リプライデータのハッシュ値と前記サーバ側プロキシ識別情報とを含むフィンガープリントである或フィンガープリントを生成するフィンガープリント生成機能と、
前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持する保持機能と、
前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定機能と、
前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定機能が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定機能が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信する送信機能とをコンピュータに実現させるためのプログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001179016A JP3943868B2 (ja) | 2001-06-13 | 2001-06-13 | サーバ側プロキシ、データ転送方法及びプログラム |
US10/167,413 US7383348B2 (en) | 2001-06-13 | 2002-06-13 | Data transfer scheme using caching technique for reducing network load |
US12/058,820 US7480731B2 (en) | 2001-06-13 | 2008-03-31 | Data transfer scheme using caching technique for reducing network load |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001179016A JP3943868B2 (ja) | 2001-06-13 | 2001-06-13 | サーバ側プロキシ、データ転送方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002373106A JP2002373106A (ja) | 2002-12-26 |
JP3943868B2 true JP3943868B2 (ja) | 2007-07-11 |
Family
ID=19019634
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001179016A Expired - Fee Related JP3943868B2 (ja) | 2001-06-13 | 2001-06-13 | サーバ側プロキシ、データ転送方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3943868B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4549174B2 (ja) * | 2004-12-14 | 2010-09-22 | シャープ株式会社 | データ送信装置、データ受信装置、プログラムおよび記録媒体 |
JP5131915B2 (ja) * | 2008-03-31 | 2013-01-30 | 国立大学法人 東京大学 | パケット符号化方法および装置ならびに復号方法および装置 |
WO2020004033A1 (ja) | 2018-06-28 | 2020-01-02 | ソニー株式会社 | 情報処理装置、情報処理方法及びプログラム |
SE2150128A1 (en) * | 2021-02-03 | 2022-08-04 | Degoo Backup Ab | Identification of compressed net resources |
-
2001
- 2001-06-13 JP JP2001179016A patent/JP3943868B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002373106A (ja) | 2002-12-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3990115B2 (ja) | サーバ側プロキシ装置及びプログラム | |
US7480731B2 (en) | Data transfer scheme using caching technique for reducing network load | |
US7636765B2 (en) | Data transfer scheme using caching technique for reducing network load | |
US8024484B2 (en) | Caching signatures | |
JP3733218B2 (ja) | 中継装置及びその制御方法及び記憶媒体 | |
WO2001080014A2 (en) | System and method for on-network storage services | |
CN103051663A (zh) | 图片共享对等网络中用于改进访客图像查看性能的代理高速缓存技术 | |
JP3984086B2 (ja) | キャッシュサーバ、データ転送装置及びプログラム | |
JP2004310371A (ja) | ファイル共有システム及び方法、ファイル共有サーバ、ファイル共有サービスのクライアント端末、ファイル共有プログラム、ファイル共有プログラムを記録した記録媒体 | |
JP3848209B2 (ja) | データ転送装置、データ転送方法及びプログラム | |
JP4031516B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP3983987B2 (ja) | サーバ側プロキシ装置、データ転送方法及びプログラム | |
JP4053269B2 (ja) | データ転送装置およびデータ転送方法 | |
JP3943867B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
JP3943868B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
JP3913508B2 (ja) | データ転送装置およびデータ転送方法 | |
JP2003108464A (ja) | データ転送装置およびデータ転送方法 | |
JP4041157B2 (ja) | クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP3977601B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
JP3977651B2 (ja) | データ転送方法、サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
JP4300220B2 (ja) | データ転送装置およびデータ転送方法 | |
JP2003242018A (ja) | キャッシュ方法およびキャッシュサーバ | |
JP2007293894A (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
JP2001290741A (ja) | ネットワークシステム | |
JP2005190339A (ja) | データ転送装置、通信システム、データ転送方法及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060815 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061016 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061212 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070131 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070215 |
|
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: 20070330 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070406 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110413 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130413 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140413 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |