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

Description

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

Claims (5)

1. クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシのデータ転送方法であって、
   クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、
   前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、
   前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持し、
   前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータを、前記サーバ装置から受信し、
   前記或リプライデータのフィンガープリントである或フィンガープリントを生成し、
   前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定し、
   前記判定にて、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると判定された場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、
   前記判定にて、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと判定された場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信することを特徴とするデータ転送方法。
2. クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシであって、
   クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、さらに、前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信手段と、
   前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、さらに前記或リプライデータのハッシュ値と前記サーバ側プロキシ識別情報とを含むフィンガープリントである或フィンガープリントを生成するフィンガープリント生成手段と、
   前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持する保持手段と、
   前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、
   前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信する送信手段とを備えることを特徴とするサーバ側プロキシ。
3. 前記クライアント側プロキシは、第1のローカルエリアネットワークを介して前記クライアント装置と接続されたものであり、前記サーバ側プロキシは、第２のローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項２に記載のサーバ側プロキシ。
4. 前記クライアント側プロキシと前記サーバ側プロキシとは、インターネットを介して接続されたものであることを特徴とする請求項２に記載のサーバ側プロキシ。
5. クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシとしてコンピュータを機能させるためのプログラムであって、
   クライアント側プロキシから転送されるリクエストデータへの返答であるリプライデータを、前記サーバ装置から受信し、さらに、前記クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信機能と、
   前記リプライデータのハッシュ値と前記サーバ側プロキシを示す識別情報であるサーバ側プロキシ識別情報とを含むフィンガープリントを生成し、さらに前記或リプライデータのハッシュ値と前記サーバ側プロキシ識別情報とを含むフィンガープリントである或フィンガープリントを生成するフィンガープリント生成機能と、
   前記リプライデータと前記フィンガープリントとを関連付けてフィンガープリント・キャッシュとして保持する保持機能と、
   前記或フィンガープリントが、前記フィンガープリント・キャッシュに保持されているか否か判定する判定機能と、
   前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていると前記判定機能が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを、前記或リプライデータの宛先となる或クライアント装置宛として、前記クライアント側プロキシへ送信し、前記或フィンガープリントが前記フィンガープリント・キャッシュに保持されていないと前記判定機能が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記クライアント側プロキシへ送信する送信機能とをコンピュータに実現させるためのプログラム。

Images