JP3977601B2 - サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム - Google Patents

Description

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

Claims (14)

1. サーバ装置から送信されたリプライメッセージを受信し、該リプライメッセージをその宛先となるクライアント装置に通ずるクライアント側プロキシ装置へ送信するとともに、該クライアント装置から送信されたリクエストメッセージを該クライアント側プロキシ装置を介して受信し、該リクエストメッセージをその宛先となる該サーバ装置へ送信するサーバ側プロキシ装置であって、
   過去に前記クライアント側プロキシ装置へ送信したリプライメッセージのメッセージボディに搭載されたデータと、該データをもとに生成したフィンガープリントとを対応付けて保持する保持手段と、
   前記サーバ装置から送信されたリプライメッセージを受信した際に、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記保持手段に保持されている場合には、該データの代わりに該フィンガープリントを前記リプライメッセージのメッセージボディに搭載して送信する処理を行い、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記保持手段に保持されていない場合には、該データと該フィンガープリントとを対応付けて前記保持手段に保持する処理を行うとともに、該リプライメッセージを送信する処理を行う第１の処理手段と、
   前記クライアント側プロキシ装置から受信したリクエストメッセージを前記サーバ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記保持手段に保持されていない場合には、該受信したリクエストメッセージのメッセージボディに搭載されたデータと該フィンガープリントとを対応付けて前記保持手段に保持する処理を行う第２の処理手段とを備えたことを特徴とするサーバ側プロキシ装置。
2. サーバ装置から送信されたリプライメッセージをサーバ側プロキシ装置を介して受信し、該リプライメッセージをその宛先となるクライアント装置へ送信するとともに、該クライアント装置から送信されたリクエストメッセージを受信し、該リクエストメッセージをその宛先となるサーバ装置に通ずるサーバ側プロキシ装置へ送信するクライアント側プロキシ装置であって、
   前記サーバ側プロキシ装置は、
   前記サーバ装置から送信されたリプライメッセージを受信した際に、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが第１の保持手段に保持されている場合には、該データの代わりに該フィンガープリントを前記リプライメッセージのメッセージボディに搭載して送信する処理を行い、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが該第１の保持手段に保持されていない場合には、該データと該フィンガープリントとを対応付けて該第１の保持手段に保持する処理を行うとともに、該リプライメッセージを送信する処理を行う第１の処理手段と、
   前記クライアント側プロキシ装置から受信したリクエストメッセージを前記サーバ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記第１の保持手段に保持されていない場合には、該受信したリクエストメッセージのメッセージボディに搭載されたデータと該フィンガープリントとを対応付けて該第１の保持手段に保持する処理を行う第２の処理手段とを有し、
   前記クライアント側プロキシ装置は、
   過去に前記サーバ側プロキシ装置から受信したリプライメッセージのメッセージボディに搭載されたデータと、該データをもとに生成したフィンガープリントとを対応付けて保持する第２の保持手段と、
   前記サーバ側プロキシ装置からフィンガープリントをメッセージボディに搭載したリプライメッセージを受信した場合には、前記第２の保持手段から該フィンガープリントに対応付けて保持されているデータを取得し、該取得したデータを該フィンガープリントの代わりにメッセージボディに搭載したリプライメッセージを送信する処理を行い、前記サーバ側プロキシ装置からデータをメッセージボディに搭載したリプライメッセージを受信した場合には、該データと該データのフィンガープリントとを対応付けて前記第２の保持手段に保持する処理を行うとともに、該データをメッセージボディに搭載したリプライメッセージを送信する処理を行う第３の処理手段と、
   前記クライアント装置から受信したリクエストメッセージを前記サーバ側プロキシ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記第２の保持手段に保持されていない場合には、該データと該フィンガープリントとを対応付けて前記第２の保持手段に保持する処理を行う第４の処理手段とを備えたことを特徴とするクライアント側プロキシ装置。
3. 前記データが、複数の単位データから構成される場合に、該複数の単位データ毎に前記フィンガープリントを生成して前記保持手段への保持を行うことを特徴とする請求項１に記載のサーバ側プロキシ装置。
4. 前記データは、ＭＩＭＥエンコーディングされたものであり、
   前記単位データは、ＭＩＭＥエンコーディングを解いて得られたものであることを特徴とする請求項３に記載のサーバ側プロキシ装置。
5. 前記データが、複数の単位データから構成される場合に、該複数の単位データ毎に前記フィンガープリントを生成して前記第２の保持手段への保持を行うことを特徴とする請求項２に記載のクライアント側プロキシ装置。
6. 前記データは、ＭＩＭＥエンコーディングされたものであり、
   前記単位データは、ＭＩＭＥエンコーディングを解いて得られたものであることを特徴とする請求項５に記載のクライアント側プロキシ装置。
7. 前記第１の処理手段は、前記受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記保持手段に保持されていない場合に該リプライメッセージを送信する際には、該データのフィンガープリントをも該データに併せて該リプライメッセージのメッセージボディに搭載して送信することを特徴とする請求項１に記載のサーバ側プロキシ装置。
8. 前記第３の処理手段は、前記サーバ側プロキシ装置から前記データとともに該データのフィンガープリントがメッセージボディに搭載されたリプライメッセージを受信した場合に、該データと該フィンガープリントとを対応付けて前記第２の保持手段に保持することを特徴とする請求項２に記載のクライアント側プロキシ装置。
9. 前記第１の処理手段は、前記受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記保持手段に保持されていない場合であってかつ該データがＮｕｌｌでない場合に、該フィンガープリントと該データとを関連付けて前記保持手段に追加しかつ該リプライメッセージを前記クライアント装置宛として前記クライアント側プロキシ装置へ送信することを特徴とする請求項１に記載のサーバ側プロキシ装置。
10. 前記第４の処理手段は、前記受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記第２の保持手段に保持されていない場合であってかつ該データがＮｕｌｌでない場合に、該フィンガープリントと該データとを関連付けて前記第２の保持手段に追加しかつ該リクエストメッセージを前記サーバ側プロキシ装置へ送信することを特徴とする請求項２に記載のクライアント側プロキシ装置。
11. 前記サーバ側プロキシ装置は、ローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項１に記載のサーバ側プロキシ装置。
12. 前記クライアント側プロキシ装置は、ローカルエリアネットワークを介して前記クライアント装置と接続されたものであることを特徴とする請求項２に記載のクライアント側プロキシ装置。
13. サーバ装置から送信されたリプライメッセージを受信し、該リプライメッセージをその宛先となるクライアント装置に通ずるクライアント側プロキシ装置へ送信するとともに、該クライアント装置から送信されたリクエストメッセージを該クライアント側プロキシ装置を介して受信し、該リクエストメッセージをその宛先となる該サーバ装置へ送信するサーバ側プロキシ装置としてコンピュータを機能させるためのプログラムであって、
    過去に前記クライアント側プロキシ装置へ送信したリプライメッセージのメッセージボディに搭載されたデータと、該データをもとに生成したフィンガープリントとを対応付けて記憶装置に保持する機能と、
    前記サーバ装置から送信されたリプライメッセージを受信した際に、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記記憶装置に保持されている場合には、該データの代わりに該フィンガープリントを前記リプライメッセージのメッセージボディに搭載して送信する処理を行い、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記記憶装置に保持されていない場合には、該データと該フィンガープリントとを対応付けて前記記憶装置に保持する処理を行うとともに、該リプライメッセージを送信する処理を行う機能と、
    前記クライアント側プロキシ装置から受信したリクエストメッセージを前記サーバ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記記憶装置に保持されていない場合には、該受信したリクエストメッセージのメッセージボディに搭載されたデータと該フィンガープリントとを対応付けて前記記憶装置に保持する処理を行う機能とをコンピュータに実現させるためのプログラム。
14. サーバ装置から送信されたリプライメッセージをサーバ側プロキシ装置を介して受信し、該リプライメッセージをその宛先となるクライアント装置へ送信するとともに、該クライアント装置から送信されたリクエストメッセージを受信し、該リクエストメッセージをその宛先となるサーバ装置に通ずるサーバ側プロキシ装置へ送信するクライアント側プロキシ装置としてコンピュータを機能させるためのプログラムであって、
    前記サーバ側プロキシ装置は、
    前記サーバ装置から送信されたリプライメッセージを受信した際に、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが第１の記憶装置に保持されている場合には、該データの代わりに該フィンガープリントを前記リプライメッセージのメッセージボディに搭載して送信する処理を行い、該受信したリプライメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが該第１の記憶装置に保持されていない場合には、該データと該フィンガープリントとを対応付けて該第１の記憶装置に保持する処理を行うとともに、該リプライメッセージを送信する処理を行う第１の処理手段と、
    前記クライアント側プロキシ装置から受信したリクエストメッセージを前記サーバ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載された データをもとに生成したフィンガープリントが前記第１の記憶装置に保持されていない場合には、該受信したリクエストメッセージのメッセージボディに搭載されたデータと該フィンガープリントとを対応付けて該第１の記憶装置に保持する処理を行う第２の処理手段とを有し、
    前記プログラムは、
    過去に前記サーバ側プロキシ装置から受信したリプライメッセージのメッセージボディに搭載されたデータと、該データをもとに生成したフィンガープリントとを対応付けて第２の記憶装置に保持する機能と、
    前記サーバ側プロキシ装置からフィンガープリントをメッセージボディに搭載したリプライメッセージを受信した場合には、前記第２の記憶装置から該フィンガープリントに対応付けて保持されているデータを取得し、該取得したデータを該フィンガープリントの代わりにメッセージボディに搭載したリプライメッセージを送信する処理を行い、前記サーバ側プロキシ装置からデータをメッセージボディに搭載したリプライメッセージを受信した場合には、該データと該データのフィンガープリントとを対応付けて前記第２の記憶装置に保持する処理を行うとともに、該データをメッセージボディに搭載したリプライメッセージを送信する処理を行う機能と、
    前記クライアント装置から受信したリクエストメッセージを前記サーバ側プロキシ装置へ送信するにあたり、該受信したリクエストメッセージのメッセージボディに搭載されたデータをもとに生成したフィンガープリントが前記第２の記憶装置に保持されていない場合には、該データと該フィンガープリントとを対応付けて前記第２の記憶装置に保持する処理を行う機能とをコンピュータに実現させるためのものであることを特徴とするプログラム。

Images