JP3848209B2 - データ転送装置、データ転送方法及びプログラム - Google Patents
データ転送装置、データ転送方法及びプログラム Download PDFInfo
- Publication number
- JP3848209B2 JP3848209B2 JP2002149131A JP2002149131A JP3848209B2 JP 3848209 B2 JP3848209 B2 JP 3848209B2 JP 2002149131 A JP2002149131 A JP 2002149131A JP 2002149131 A JP2002149131 A JP 2002149131A JP 3848209 B2 JP3848209 B2 JP 3848209B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- fingerprint
- client
- server
- complete
- 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
【０００１】
【発明の属する技術分野】
本発明は、他の装置のためにデータ転送を行うデータ転送装置、データ転送方法及びプログラムに関する。
【０００２】
【従来の技術】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。特に、インターネット上でＨＴＴＰプロトコルを使って通信するＷｅｂサーバとクライアントとからなるWorld Wide Webシステム（あるいは単にＷｅｂとも呼ばれる）は、大変広く利用されているクライアント・サーバ型の情報システムである。通常、サーバ上ではサーバプログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（例えば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋等の予約サービス、種々の契約の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【０００３】
ところで、Ｗｅｂのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間で通信に用いるネットワークの容量（バンド幅）が、システム全体のボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【０００４】
Ｗｅｂシステムの場合、クライアント上で動作するブラウザ等はキャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。ＷｅｂではＵＲＬと呼ばれる名前で情報やサービスを指定してアクセスがなされるので、クライアント上のキャッシュは、過去にＷｅｂサーバに要求した情報やサービスの結果として返されるデータのうちでキャッシュ可能なものを、そのＵＲＬと対応させてキャッシュに記録している。この場合、キャッシュ内にあるものと同じＵＲＬの情報やサービスのリクエストがあった際に、そのキャッシュ内の応答データが古くなっていないと判断できるならば、そのデータを返すことで、Ｗｅｂサーバとの間の通信を無くすことができる。
【０００５】
企業のオフィス内のＬＡＮあるいは研究機関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数のユーザがいる場合、該ＬＡＮとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。クライアント内のキャッシュ（例えば、ブラウザのキャッシュ）は、当該クライアント・ユーザに専用のキャッシュとして動作するが、ＬＡＮ上のプロキシサーバのキャッシュは、複数のクライアント・ユーザに共有のキャッシュとして動作する。そのため、後者では、過去に他人（他クライアント）がアクセスしたＵＲＬに対してアクセスする際にもキャッシュが効く。
【０００６】
さて、Ｗｅｂにおいて、クライアントとサーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行われる。ＨＴＴＰプロトコルは、クライアントからサーバへ送る「リクエストメッセージ」と、それに答えてサーバからクライアントへ応答を返す「リプライメッセージ」とが組になっている。
【０００７】
リクエストメッセージは、「リクエストヘッダ」と「リクエストボディ」からなる。リクエストヘッダには、アクセスしたい情報やサービスを指定するＵＲＬやアクセスの種類を示すメソッド名、その他アクセスに必要な各種の情報が入る。リクエストボディには、サーバに送るデータを入れる。リクエストボディに入っているデータを「リクエストデータ」とも呼ぶ。
【０００８】
リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。リプライヘッダには、処理結果のステータスなどの情報が入り、リプライボディには要求された情報や要求されたサービスの処理結果などのデータが入る。リプライボディに入っているデータを「リプライデータ」とも呼ぶ。
【０００９】
リクエストメッセージのメソッドとしては、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユーザの持つデータをサーバに書き込む「ＰＵＴメソッド」、リクエストの応じて処理した結果を送り返してもらう「ＰＯＳＴメソッド」が、情報やサービスのアクセスに用いられる主要なものである。その他、ＤＥＬＥＴＥなどのメソッドが定義されている。
【００１０】
多くの場合、ＧＥＴメソッドのリクエストメッセージのリクエストボディ、ＰＵＴメソッドのリプライメッセージのリプライボディは空である。ＰＯＳＴメソッドのリクエストメッセージのリクエストボディには、必要に応じてサーバ側での処理に用いる情報が入り、ＰＯＳＴメソッドのリプライメッセージのリプライボディには、その処理の結果のデータが入る。
【００１１】
ＧＥＴメソッドでサーバから読み出すデータは、読み出す毎にサーバ側で生成する「動的データ」と、既にサーバ側で記憶しているデータをそのまま送り返す「静的データ」に分けることができる。これらのうち、動的データについては、同じＵＲＬでも読み出す度に内容が異なる可能性があるので、多くの場合、サーバはキャッシュ不可の指定をそのリプライメッセージのヘッダに入れて送り返す。したがって、Ｗｅｂのデータでキャッシュの対象になるのは、静的データの部分である。この静的データは、不特定多数のユーザが参照して構わない「共有データ」と、ユーザ認証することで特定のユーザだけがアクセスできるようにアクセス制御を行う「プライベートデータ」に分けることができる。前者の共有データは、どのようなキャッシュでもキャッシュ可能である。しかしながら、後者のプライベートデータは、プロキシサーバなどの共有キャッシュでは、キャッシュ不可である（プライベートデータは必ずサーバで認証して送り返す必要があるので）。ただし、ブラウザなどの個人専用のキャッシュの場合には、プライベートデータでもキャッシュは可能である。
【００１２】
ＰＯＳＴメソッドは、サーバ側で処理をした結果を返すので、一般的にサーバはキャッシュ不可の指定をリプライメッセージのヘッダに入れて結果を送り返す。そのため、通常はキャッシュの対象にはならない。
【００１３】
ＰＵＴメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない。
【００１４】
【発明が解決しようとする課題】
従来のＷｅｂのキャッシュは、静的コンテンツをキャッシュの対象にしている。かつては、Ｗｅｂで公開される情報やサービスには、情報の更新頻度がそれほど高くなく、不特定多数の人に公開されているものが多かったため、静的コンテンツの割合は非常に高く、従来のキャッシュ技術でもネットワークの負荷の軽減に有効であった。
【００１５】
しかしながら、ＷｅｂベースのＡＳＰ(Application Service Provider)のように、ユーザがＷｅｂブラウザを使って、ネットワーク経由でサーバ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来のキャッシュ技術では対応できないデータが増加している。
・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデータが多い。
・バックエンドのデータベースを参照して生成する動的データが多い。
・帳票処理や検索などＰＯＳＴメソッドを使う場合が多い。
・グループ内の情報共有のためにＰＵＴメソッドを使う場合が多い。
この結果、キャッシュ技術のみではネットワークの負荷を軽減する手法として有効に機能しなくなってきている。
【００１６】
本発明は、上記事情を考慮してなされたもので、データ転送装置間を接続するネットワークの負荷をより軽減することができるキャッシュ技術・圧縮技術を備えたデータ転送装置、データ転送方法及びプログラムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明は、サーバ装置と、該サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置との通信を中継するデータ転送装置において、サーバ装置から受信して他のデータ転送装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、前記サーバ装置がクライアント装置を宛先として送信した第２の完全データを受信する受信手段と、前記第１の完全データと前記第２の完全データとの差分である差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記差分データが差分データであることを示す第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とする。
また、本発明は、サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置と、前記クライアント装置との通信を中継するデータ転送装置において、他のデータ転送装置から受信してクライアント装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、前記クライアント装置が宛先とされた、前記第１の完全データと第２の完全データとの差分である差分データと、該差分データが差分データであることを示す第２の識別情報とを受信する受信手段と、前記第１の完全データと前記差分データとを用いて前記第２の完全データを生成し、該差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、該第２の完全データを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とする。
【００２３】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２４】
本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を保持しているデータについては、データ本体を転送する代わりに対応する名前を転送することで、データ転送装置間の転送データ量を削減させることができる。例えば、ＧＥＴメソッドのリプライメッセージがプライベートデータであっても、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。また、例えば、ＧＥＴメソッドのリプライメッセージが動的データであっても、内容が同じデータなら、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。また、例えば、ＰＯＳＴメソッドであっても、結果が同じデータなら、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。
【００２５】
また、本発明によれば、データに対応する名前が保持されていないために、データを転送する代わりに対応する名前を転送することができない場合であっても、保持されている参照データに対応する名前を利用して当該データを圧縮して表現した圧縮データを転送することによって、データ転送装置間の転送データ量を削減することができる。例えば、ＧＥＴメソッドやＰＯＳＴメソッドのリプライデータが以前にアクセスしたデータと一部が異なる場合には、差分転送することで、データ量を削減することができる。また、例えば、ＰＵＴメソッドやＰＯＳＴメソッドのリクエストデータが以前に送ったデータと一部が異なる場合には、差分転送することでデータ量を削減することができる。
【００２６】
また、本発明によれば、データ圧縮が可能な場合には、データの代わりに圧縮データを保存することにより、記憶装置（メモリやハードディスクなど）を有効利用できる。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
以下では、ＷＡＮがインターネットであり、クライアントはユーザオフィスＬＡＮに接続されたものであり、ＨＴＴＰプロトコルが使用されるような場合を例にとって説明するが、本発明は、ＷＡＮがインターネット以外のものでも、クライアントがオフィス以外の例えば家庭内ＬＡＮ等に設置されたものでも、ＨＴＴＰ以外のプロトコルが使用されるものでも適用可能である。
【００２９】
図４９に本発明を適用するコンピュータ・ネットワーク・システムの基本的な構成例を示す。この構成例では、ＡＳＰサーバセンター２内のローカルエリアネットワーク（ＬＡＮ）１２とユーザオフィス４内のローカルエリアネットワーク（ＬＡＮ）１６との間が、インターネットや専用回線などの広域ネットワーク（ＷＡＮ）１４を介して接続されており、サーバ２０とクライアント５０とがＬＡＮ１２・ＷＡＮ１４・ＬＡＮ１６を介して通信可能になっている。ＬＡＮ１２には１または複数のサーバが接続され、ＬＡＮ１６には１または複数のクライアントが接続される。
【００３０】
ＷｅｂベースのＡＳＰは、センター２に設置したサーバ２０からＷＡＮ１４を介して様々なアプリケーションプログラムによるサービスを提供し、ユーザはオフィス４に設置されたクライアント上のＷｅｂブラウザ等を使ってそれらのサービスにアクセスする。このような利用形態においては、オフィス内ＬＡＮ１６とセンター内ＬＡＮ１２とをつなぐネットワーク、特にインターネットなどのＷＡＮ１４の実効的な通信容量（バンド幅）は、ＬＡＮ１２やＬＡＮ１６よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。そこで、本実施形態では、例えば図１に示すように、センター内ＬＡＮ１２とオフィス内ＬＡＮ１６をつなぐＷＡＮ１４の両端に、サーバ側プロキシ３０及びクライアント側プロキシ４０なる２つのモジュールを設置し、サーバ２０とクライアント５０がＬＡＮ１２・プロキシ３０・ＷＡＮ１４・プロキシ４０・ＬＡＮ１６を介して通信するにあたって、それらプロキシ間で後述するフィンガープリント圧縮（ＦＰ圧縮）や差分圧縮を行って通信データ量を低減することで、広域ネットワークのボトルネックを解消する。さらに、それらプロキシでは、詳しくは後述するように、圧縮に必要なデータの一部を差分情報によって保持することで、必要なキャッシュ量を削減する。
【００３１】
本実施形態のサーバ２０、サーバ側プロキシ３０、クライアント側プロキシ４０、クライアント５０は、いずれも、計算機上でソフトウェア（サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム）を動作させる形で実現することができる。この場合に、所望の機能を有する、ＯＳやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが、必要に応じて計算機に搭載あるいは接続される。また、この場合に、ユーザあるいは管理者などからの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いると好ましい。
【００３２】
サービスを利用するためにユーザが使用するクライアント５０上では、その目的に応じて例えばＷｅｂブラウザ等のプログラムが動作する。ユーザは、例えば、Ｗｅｂブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。なお、Ｗｅｂブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【００３３】
サーバ２０上では、所定のサーバ・プログラムが動作し、クライアント５０のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【００３４】
サーバ側プロキシ３０は、図１のように、サーバセンター内ＬＡＮ１２とＷＡＮ１４の両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施してもよい。また、図２のようにサーバセンター内ＬＡＮ１２上に設置して実施してもよい。また、図３のようにサーバ側プロキシ３０の機能をサーバ２０に内蔵するように実施してもよい。
【００３５】
同様にクライアント側プロキシ４０は、図１のように、ユーザオフィス内ＬＡＮ１６とＷＡＮ１４の両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施してもよい。また、図２のようにユーザオフィス内ＬＡＮ１６上に設置して実施してもよい。また、図３のようにクライアント側プロキシ４０の機能をクライアント５０上で動作するブラウザ等に内蔵するように実施してもよい。あるいは、ブラウザ等の動作するクライアント５０上に、個人用のクライアント側プロキシ４０を動作させるように実施してもよい。
【００３６】
なお、サーバ側プロキシ３０とクライアント側プロキシ４０とは、図１〜図３などのように同じ形態であってもよいし、異なる形態であってもよい。
【００３７】
以下では、フィンガープリント・キャッシュ、これを利用したＦＰ圧縮及び差分圧縮、データ管理について、それらの概要を説明する。
【００３８】
なお、以下、サーバ側プロキシ３０とクライアント側プロキシ４０との間のデータ転送方向としていずれか一方向を例にとって説明する際には、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する場合を例にとって説明していくが、クライアント側プロキシ４０からサーバ側プロキシ３０へデータを転送する場合にも同様のことが可能である。
【００３９】
本実施形態のサーバ側プロキシ３０とクライアント側プロキシ４０は、フィンガープリント・キャッシュと呼ぶキャッシュ機構を持つ。フィンガープリント・キャッシュは、フィンガープリント（ＦＰ）と呼ぶ名前によって、ＨＴＴＰプロトコルでやりとりされるデータを記録・管理する。
【００４０】
フィンガープリントは、図４に例示するように、ＨＴＴＰプロトコルでやり取りされるデータ（図４ではコンテンツ）の内容から、あらかじめ決められた計算方法（図４ではハッシュ関数）で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【００４１】
フィンガープリントを計算する方法としては、良く知られているＭＤ−５やＳＨＡ−１などのハッシュ関数を用いることができる。これらのハッシュ関数は、データに対する電子署名などに使われており、任意のデータが与えられると、ＭＤ−５の場合は１２８ビットの数値に、ＳＨＡ−１の場合は１６０ビットの数値に、変換することができる。これらのハッシュ関数の特徴は、２つのデータＸ１、Ｘ２が与えられ、データＸ１とデータＸ２とが同じであれば、データＸ１に対して計算したハッシュ値とデータＸ２に対して計算したハッシュ値とは等しくなるが、異なる２つのデータＡ、Ｂが与えられた場合には、データＡに対して計算したハッシュ値とデータＢに対して計算したハッシュ値とは、非常に高い確率で異なるものになることである（原理上は、異なる２つのデータＡ、Ｂに対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい）。
【００４２】
図５に示すように、サーバ側プロキシ３０やクライアント側プロキシ４０の持つフィンガープリント・キャッシュ（２６０）は、過去にＨＴＴＰプロトコルでやり取りされたデータ本体（２６１）または後述する差分圧縮により生成されたデータ（２６４）を、そのやりとりされたデータから計算して求めたフィンガープリントの値（２６２）を名前として、記録されているデータがデータ本体かそれとも差分圧縮により生成されたデータかを示す差分圧縮データ識別子（以下、圧縮識別子と記述する）（２６３）とともに記録・管理する。なお、以下では、該識別子＝０が“記録されているデータはデータ本体である”ことを示し、該識別子＝１が“記録されているデータが差分圧縮により生成されたデータである”ことを示すものとした例で説明するが、これに限定されるものではない。
【００４３】
例えば、ＨＴＴＰプロトコルでサーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する場合に、サーバ側プロキシ３０は、当該データのフィンガープリントを計算し、そのフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていてかつ圧縮識別子が０であれば、キャッシュに存在するデータは差分圧縮により生成されたデータではないが、当該データ（と同じ内容のデータ）は過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出すことで、転送すべきデータを再現することができる。
【００４４】
また例えば、上記の場合に、サーバ側プロキシ３０は、計算したフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていてかつ圧縮識別子が１であれば、キャッシュに存在するデータは差分圧縮により生成されたデータであり、当該受信データ（と同じ内容のデータ）に対して過去に差分圧縮が成功し、差分情報を転送したことがあることがわかり、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出して差分圧縮されているデータを解凍することで、転送すべきデータを再現することができる。
【００４５】
このような方式（すなわち、フィンガープリントによるデータの圧縮→フィンガープリントの転送→フィンガープリントによるデータの解凍）により、過去に送ったものと同じデータ（データ本体あるいは差分圧縮により生成されたデータ）ならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。
【００４６】
なお、上記の場合に、計算したフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていないものについては、今回は、後述する差分圧縮により生成されたデータまたはデータ本体を転送するとともに、フィンガープリント・キャッシュへの登録を行うことによって、次回からは、ＦＰ圧縮によるフィンガープリントの転送ができるようになる。
【００４７】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮（ＦＰ圧縮）と呼ぶものとする。
【００４８】
続いて、差分圧縮について説明する。
【００４９】
上記のＦＰ圧縮では、データに対するフィンガープリントを用いてデータの同一性を高速に判断し、フィンガープリント・キャッシュに登録されているデータと同じデータはプロキシ間で転送せず、代わりに当該データに対するフィンガープリントを転送するようにして、ネットワークの負荷を低減させる。しかし、フィンガープリント・キャッシュに登録されているデータと異なるデータは、たとえ大部分は同じ内容であってもＦＰ圧縮を適用できない。そこで、本実施形態では、ＦＰ圧縮できない場合であっても、フィンガープリント・キャッシュに登録されている１または複数のデータを参照データとして、参照データのフィンガープリントや、参照データに対する差分情報など転送すべきデータを復元するための情報によって、転送データを表現することによって、少ない情報量で転送データを表現し、なるべく転送データ量を減らすようにしている。すなわち、フィンガープリント・キャッシュの中のデータを辞書として使って、その中から取り出せるデータは送らないようにする。
【００５０】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータを参照データのフィンガープリント等に置き換えて転送情報量を圧縮することを、差分圧縮と呼ぶものとする。また、この差分圧縮により生成された転送データを、差分圧縮データと呼ぶものとする。
【００５１】
なお、このようなフィンガープリントを利用した差分圧縮は、転送すべきデータと参照データとの間の関係を予め取り決めておく必要がないという利点も得られる。すなわち、従来の差分転送では、予め双方で何をベースに差分を取るかを決める必要があるため、差分転送をＷｅｂシステムに実際に用いようとすると、このＵＲＬのデータはこのデータをベースに差分を取るというようなルールを、双方に登録する手段が必要であり、任意のデータに対して有効に機能させることは不可能であった。これに対して、本差分圧縮方法は、フィンガープリント・キャッシュの中にあるデータを参照データとして差分を取ることで、差分のベースを予め決めておかなくても、差分によるデータの圧縮の効果を得ることができる。
【００５２】
次に、本実施形態のデータ管理方法について説明する。
【００５３】
本実施形態では、サーバ側プロキシ３０においてサーバ２０から受信したリプライデータに対して差分圧縮が成功した場合、サーバ側プロキシ３０は差分圧縮により生成された差分圧縮データをクライアント側プロキシ４０に送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該差分圧縮データとを記録・管理する。この際、記録・管理されているデータが差分圧縮データであることを示すために、圧縮識別子を１にセットする。
【００５４】
クライアント側プロキシ４０においては、サーバ側プロキシ３０から受信したリプライデータが差分圧縮データであった場合には、差分圧縮データからサーバ側プロキシ３０が受信したリプライデータを生成しクライアント５０に送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、差分圧縮データから生成された該リプライデータに対するフィンガープリントと、サーバ側プロキシ３０から受信した差分圧縮データとを記録・管理する。この際、記録・管理されているデータが差分圧縮データであることを示すために、圧縮識別子を１にセットする。
【００５５】
一方、サーバ側プロキシ３０においてサーバ２０から受信したリプライデータが初めてのデータであり、ＦＰ圧縮及び差分圧縮の両方とも失敗した場合には、サーバ側プロキシ３０はクライアント側プロキシ４０に対して該リプライデータを送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該リプライデータとを記録・管理する。この際、記録・管理されているデータが差分圧縮データではないことを示すため、圧縮識別子を０にセットする。
【００５６】
クライアント側プロキシ４０においては、サーバ側プロキシ３０から受信したリプライデータがＦＰ圧縮及び差分圧縮のどちらも施されていないデータであることを検知した場合には、該リプライデータをクライアント５０へ送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該リプライデータとを記録・管理する。この際、記録・管理されているデータが差分圧縮データではないことを示すため、圧縮識別子を０にセットする。
【００５７】
これにより、差分圧縮が成功したデータについては、サーバ側プロキシ３０及びクライアント側プロキシ４０双方のフィンガープリント・キャッシュ２６０において、差分圧縮データのみが保存されることになる。
【００５８】
ところで、ＷｅｂベースのＡＳＰのような応用では、大部分は同じ内容であるが一部分だけが異なっているようなデータが多く使われる。例えば、帳票のデータなどは、多くのフィールドに同じ情報が記入されていて、一部分だけが違うようなものが多数存在する。また、例えば、Ｗｅｂページで日付もしくは時刻のみ異なるものや、総アクセス回数のカウンタ値のみ異なるものなどもある。このような場合には、差分圧縮データによる転送や保存は特に有効で、データ本体による転送や保存を効果的に少なくすることができる。
【００５９】
なお、両プロキシ３０，４０間において、全メッセージをＦＰ圧縮の適用対象としてもよいが、例えば、予め定められた条件を満たすメッセージについては、これをＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで転送する）ようにしてもよい。予め定められた条件は、例えば、メッセージ・ヘッダに予め定められた情報（例えばＧＥＴメソッドを示す情報およびリクエストを示す情報）が記述されていること、転送されるデータが空（ｎｕｌｌ）あるいは非常に短いサイズであることなど、種々のバリエーションが考えられる。
【００６０】
また、ＦＰ圧縮の適用対象のメッセージをすべて差分圧縮の適用対象としてもよいが、ＦＰ圧縮の適用対象のメッセージのうち予め定められた条件を満たすメッセージについては、これを差分圧縮の適用対象外とするようにしてもよい（この場合、差分圧縮を適用される条件が、ＦＰ圧縮を適用される条件に対して更に他の条件を加重したものになる）。例えば、ＦＰ圧縮しないデータサイズの上限値Ｕ１よりも、差分圧縮しないデータサイズの上限値Ｕ２を大きくする（ＦＰ圧縮すべきデータサイズの下限値Ｌ１よりも、差分圧縮すべきデータサイズの下限Ｌ２を大きくする）という方法や、ＦＰ圧縮の適用対象か否かはデータサイズで判断するが、差分圧縮の適用対象か否かについては、ＦＰ圧縮の適用対象のうちＨＴＭＬやＸＭＬ以外のデータを適用対象外とする（ＨＴＭＬやＸＭＬのデータに対してのみ差分圧縮を行う）という方法等、種々のバリエーションが考えられる。なお、以下では、ＦＰ圧縮の適用対象のメッセージをすべて差分圧縮の適用対象とする場合を例にとって説明する。
【００６１】
本実施形態では、ＦＰ圧縮対象且つ差分圧縮対象のメッセージは、データがＦＰ圧縮されたメッセージ（ただし、圧縮識別子が０になるものと１になるものとがある）、データが差分圧縮されたメッセージ、またはデータが圧縮されていないメッセージのいずれかとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６２】
また、ＦＰ圧縮対象であり且つ差分圧縮対象でないメッセージがある場合、該メッセージは、データがＦＰ圧縮されたメッセージ（圧縮識別子＝０になる）、またはデータが圧縮されていないメッセージのいずれかとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６３】
また、ＦＰ圧縮対象でないメッセージがある場合には、該メッセージは、データが圧縮されていないメッセージとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６４】
ここで、差分圧縮の方法について説明する。
【００６５】
フィンガープリント・キャッシュを利用した差分圧縮の方法には次に例示するものなど種々の方法がある。
・フィンガープリント・キャッシュに登録されているデータのうちの１つを参照データとする。プロキシ間では、参照データに対応するフィンガープリントの値と、転送データと参照データとの差分を示す情報とを転送する。
・上記の方法において、参照データとの差分の全部または一部についても、フィンガープリント・キャッシュに登録されているデータを利用する。あるいは、フィンガープリント・キャッシュに登録されているデータ（の全体または部分）を組み合わせることによって転送データの全部または一部を表現する。例えば、フィンガープリント・キャッシュに登録されているデータのうち任意数のものを参照データとする。プロキシ間では、参照データに対応するフィンガープリントの値と、参照データのうち転送データの復元に使用する部分を示す情報と、その部分をもとにした転送データの復元方法を示す情報とを転送する。
【００６６】
以下では、差分圧縮データの表現方法の一例を示す。
【００６７】
図６に、転送すべきデータを表現するための３種類の指示を示す。データの代わりに転送される差分圧縮データは、これら指示の並びで構成する。
【００６８】
（ａ）は、フィンガープリント・キャッシュ内のデータを参照するときに、参照データに番号を付けて定義する指示である。１バイト目の８ｎ（図６の例では、ｎ＝０）は指示識別子である。この指示識別子のうちｎは、そのフィンガープリントで指定されるデータをｎ番の参照データとして扱うことを示す。２バイト目から始まる１６バイトが当該参照データに対するフィンガープリントの値を示す。この例では、８０〜８Ｆによってそれぞれ０番の参照データから、最大１５番までの参照データが扱えるようになっている。扱える参照データの最大数は、実装によって多くも少なくもできる。
【００６９】
（ｂ）は、（ａ）で定義された参照データの中から部分データをコピーする指示を表す。１バイト目の９ｎ（図６の例では、ｎ＝０）は指示識別子である。この指示識別子のうちｎは、（ａ）の指示で定義されたｎ番の参照データを使用することを示す。２バイト目からの４バイトは、そのｎ番の参照データ中のオフセット位置を、６バイト目からの４バイトでデータの長さをそれぞれ指示する。そして、それらによって、ｎ番の参照データの中の指定オフセット位置から指定長さのデータを、この指示の並びの位置（順番）に従って（転送データの構成部分として）コピーすべきことを示す。
【００７０】
（ｃ）は、データを直接指定するための指示である。１バイト目のＡ０は、指示識別子である。２バイト目からの４バイトは、データの長さを示す。６バイト目以降に、その長さで指定されたバイト数のデータが続く。そして、それらによって、６バイト目以降のデータを、この指示の並びの位置（順番）に従って（転送データの構成部分として）コピーすることを示す。
【００７１】
このような指示の並びで構成された差分圧縮データは、フィンガープリント・キャッシュを参照しながら、指示された順にデータをコピーして接続していくだけで解凍することができる。
【００７２】
次に、上記の方法に従った差分圧縮の例を示す。
【００７３】
図７に示すようなデータがフィンガープリント５Ｅ８３…Ｂ６としてフィンガープリント・キャッシュに入っていたとする。
【００７４】
このとき、図８のようなデータが与えられると、図７のデータを参照データとして、図９のように差分圧縮することができる。
【００７５】
すなわち、図８のデータは、図７のデータと比較すると、図７のデータの『ＴＯＫＹＯ』が『ＯＳＡＫＡ』に変わっているだけである。そこで、図９のように、まず、０バイト目でフィンガープリント“５Ｅ８３…Ｂ６”のデータを０番参照データとして定義することを指示し、１７バイト目で０番参照データの０バイト目から６０バイトをコピーすることを指示し、次に２６バイト目で『ＯＳＡＫＡ』の５文字をコピーすることを指示し、最後に３６バイト目で０番参照データの６５バイト目から５１バイトをコピーすることを指示している。
【００７６】
この指示の通りに解凍すれば、図８のデータを再現することができる。
【００７７】
この例では、参照データを１つだけ用いたが、複数個使うことも可能である。
【００７８】
次に、上記の方法に従った差分圧縮の他の例を示す。
【００７９】
図１０に示すようなデータがフィンガープリント８２Ｆ３…３８としてフィンガープリント・キャッシュに入っており、図１１に示すようなデータがフィンガープリントＡ２０Ｄ…ＣＢとしてフィンガープリント・キャッシュに入っていたとする。このとき、図１２のようなデータが与えられると、図１０のデータと図１１のデータを参照データとして、図１３のように差分圧縮することができる。
【００８０】
図１３では、まず、０バイト目でフィンガープリント“８２Ｆ３…３８”のデータを０番参照データとして定義することを指示し、１７バイト目で０番参照データの０バイト目から５３バイトをコピーすることを指示し、２６バイト目でフィンガープリント“Ａ２０Ｄ…ＣＢ”のデータを１番参照データとして定義することを指示し、４３バイト目で１番参照データの９６バイト目から５５バイトをコピーすることを指示している。
【００８１】
この指示の通りに解凍すれば、図１２のデータを再現することができる。
【００８２】
なお、上記した方法では、参照データの使用すべき部分の指示と、使用すべきデータの直接指定を行う方法（方法１）であったが、その代わりに、参照データのうち使用しない部分（直接指示データで置き換える部分）の指示と、その使用しない部分に嵌め込むデータの直接指定を行う方法（方法２）も可能である。
【００８３】
また、方法１と方法２を併用することも可能である。
【００８４】
次に、図１４〜図１８を参照しながら、サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する際の（ＦＰ圧縮の適用対象のメッセージについての）プロキシ間メッセージ・フォーマットについて説明する。
【００８５】
サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する場合、ＦＰ圧縮の適用対象のメッセージには、データがＦＰ圧縮されてフィンガープリントに置き換えられたメッセージ（ＦＰ圧縮時のメッセージ）と、ＦＰ圧縮されないが、差分圧縮されたデータが搭載されているメッセージ（差分圧縮時のメッセージ）と、ＦＰ圧縮も差分圧縮もされていないデータが搭載されているメッセージ（非圧縮時のメッセージ）とがある。すべてのメッセージをＦＰ圧縮の適用対象とするのではない構成の場合には、これら３つのメッセージに加えて、ＦＰ圧縮の適用対象外のメッセージがある。
【００８６】
両プロキシのうち送信側プロキシにおいて、ＦＰ圧縮時のメッセージでは、データが削除され、フィンガープリントが付加され、差分圧縮時のメッセージでは、データが削除され、参照データのフィンガープリントなど当該データを復元するための情報が付加される。非圧縮時のメッセージおよび圧縮適用対象外のメッセージでは、データは削除されない。
【００８７】
両プロキシのうち受信側プロキシにおいては、上記の３種もしくは４種のメッセージを識別できる必要がある。ＦＰ圧縮時のメッセージ受信時は、フィンガープリントをデータに戻し（ただし、圧縮識別子が０である場合には、データ本体が保持されているが、圧縮識別子が１である場合には、差分圧縮により生成されたデータが保持されているので、これをもとにデータを復元する）、差分圧縮時のメッセージ受信時は、データを復元する。また、差分圧縮時または非圧縮時のメッセージ受信時は、フィンガープリント・キャッシュの登録を行う。
【００８８】
図１４に、メッセージ・フォーマットの一例を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）は差分圧縮時のメッセージであり、（ｃ）はＦＰ圧縮時のメッセージである。
【００８９】
（ａ）ではメッセージ・ボディーにデータが載せられ、（ｂ）ではメッセージ・ボディーにデータの代わりに当該データを復元するための情報が載せられ、（ｃ）ではメッセージ・ボディーにデータの代わりにフィンガープリント（ＦＰ）が載せられる。
【００９０】
また、この例では、メッセージ・ヘッダに、メッセージの種類を識別可能とする識別情報が（圧縮側のプロキシにおいて）記述され、この識別情報に基づいて（解凍側のプロキシにおいて）ＦＰ圧縮の有無を識別する（例えば、０１ならば非圧縮なし、１０ならば差分圧縮、１１ならばＦＰ圧縮）。なお、識別情報は、プロキシ間で使用される特別のものであってもよいし、もともと通常のＨＴＴＰメッセージ・ヘッダに存在するフィールドを利用あるいは併用したものであってもよい。
【００９１】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合には、圧縮側（送信側）のプロキシにおいて、図１４（ｄ）に示すように、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダに上記の識別情報（例えば、００とする）を含めればよい。
【００９２】
また、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合に、解凍側（受信側）プロキシにおいて、メッセージ・ヘッダに含まれる何らかの情報によって当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断できるとき、あるいはメッセージ・ボディーが空（ｎｕｌｌ）のときに当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断するようにしたときなどには、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダには識別情報を含めないようにすることも可能である。
【００９３】
なお、非圧縮時や差分圧縮時には、図１４（ａ），（ｂ）の例では、メッセージに当該データに対するフィンガープリントを含ませなかったが、メッセージ・ヘッダにフィンガープリントを含ませるようにしてもよい（あるいは、メッセージ・ボディーに当該データに対するフィンガープリントを含ませるようにしてもよい）。図１５（ａ）〜（ｃ）は、非圧縮時や差分圧縮時には、メッセージ・ヘッダにフィンガープリントを含ませ、ＦＰ圧縮時には、メッセージ・ボディーにフィンガープリントを含ませる場合の一例である。このようにすれば、解凍側で当該データについてフィンガープリント・キャッシュの登録を行う際に、該フィンガープリントを利用することによって、あらためて当該データからフィンガープリントを求める手間が省ける。
【００９４】
なお、以上のいずれの場合においても、図１６に示すように、ＦＰ圧縮時のメッセージでは、メッセージ・ヘッダにフィンガープリント（ＦＰ）を含め、メッセージ・ボディーを空（ｎｕｌｌ）にしてもよい。
【００９５】
なお、以上の他にも、種々のメッセージ・フォーマットが可能である。
【００９６】
例えば、図１７では、（ａ）の非圧縮時のメッセージのヘッダに非圧縮フラグを記述し且つフィンガープリントは記述せず、（ｂ）の差分圧縮時のメッセージのヘッダに差分圧縮フラグを記述し且つフィンガープリントは記述せず、（ｃ）のＦＰ圧縮時のメッセージのヘッダにフィンガープリントは記述し且つボディーは空（ｎｕｌｌ）にする。
【００９７】
この場合には、メッセージ・ボディーが空（ｎｕｌｌ）であることあるいはメッセージのヘッダにフィンガープリントが記述されていることを検出するによって、当該メッセージがＦＰ圧縮時のメッセージであることを識別することができる。また、非圧縮時のメッセージや差分圧縮時のメッセージは、ヘッダに非圧縮フラグや差分圧縮フラグが記述されていることを検出することによって、識別することができる。
【００９８】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合には、圧縮側（送信側）のプロキシにおいて、図１８の（ａ），（ｂ）に示すように（（ａ）はデータが空（ｎｕｌｌ）でない場合、（ｂ）はデータが空（ｎｕｌｌ）である場合）、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダに対象外フラグを含めればよい。
【００９９】
また、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合に、解凍側（受信側）プロキシにおいて、メッセージ・ヘッダに含まれる何らかの情報によって当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断できるときなどには、図１８の（ｃ），（ｄ）に示すように（（ｃ）はデータが空（ｎｕｌｌ）でない場合、（ｄ）はデータが空（ｎｕｌｌ）である場合）ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダには対象外フラグを含めないようにすることも可能である。
【０１００】
以下では、まずサーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送するときにそのリプライデータをＦＰ圧縮・解凍する場合を中心に本実施形態について詳しく説明する。
【０１０１】
図１９に本実施形態におけるサーバ側プロキシ３０の構成例を示し、図２０に本実施形態におけるクライアント側プロキシ４０の構成例を示す。なお、図１９や図２０は、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する際の構成を中心に示してある。
【０１０２】
図１９のサーバ側プロキシ３０は、サーバセンター内ＬＡＮ１２または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部３１、転送メッセージに含まれるデータに対してＦＰ圧縮、差分圧縮を施すための処理部３２、サーバセンター内ＬＡＮ１２または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部３３、フィンガープリントとそのもととなったデータまたは差分圧縮データとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰキャッシュ）３４を備えている。また、処理部３２は、転送メッセージに含まれるデータを圧縮対象とすべきか否かを判定するためのフィンガープリント圧縮判定部（ＦＰ圧縮判定部）３２１、ＦＰキャッシュ３４に対する検索や登録などを行うためのフィンガープリント・キャッシュ管理部（ＦＰキャッシュ管理部）３２２、転送メッセージに含まれるデータを対応するフィンガープリントで置き換えるなどの処理を行うためのフィンガープリント圧縮処理部（ＦＰ圧縮処理部）３２３、転送メッセージに含まれるデータを差分圧縮データで置き換えるなどの処理を行うための差分圧縮処理部３２４を含む。
【０１０３】
図２０のクライアント側プロキシ４０は、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部４１、転送メッセージに含まれるデータに対してＦＰ解凍を施すための処理部４２、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部４３、フィンガープリントとそのもととなったデータまたは差分圧縮データとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰキャッシュ）４４を備えている。また、処理部４２は、転送メッセージに含まれるデータを圧縮対象とすべきか否か並びに転送メッセージに対するＦＰ圧縮および差分圧縮の有無を判定するためのフィンガープリント圧縮判定部（ＦＰ圧縮判定部）４２１、ＦＰキャッシュ４４に対する検索や登録などを行うためのフィンガープリント・キャッシュ管理部（ＦＰキャッシュ管理部）４２２、ＦＰ圧縮された転送メッセージに含まれるフィンガープリントから元のデータを解凍するなどの処理を行うためのフィンガープリント解凍処理部（ＦＰ解凍処理部）４２３、差分圧縮された転送メッセージに含まれる差分圧縮データから元のデータを解凍するなどの処理を行うための差分解凍処理部４２４を含む。
【０１０４】
なお、圧縮側のＦＰ圧縮判定部３２１と解凍側のＦＰ圧縮判定部４２１は、前述したようにメッセージが予め定められた条件を満たすか否かを調べることによって、そのメッセージに含まれるデータをＦＰ圧縮の適用対象とするか否かを判断する（全メッセージをＦＰ圧縮の適用対象にする場合には、圧縮側のＦＰ圧縮判定部３２１及び後に示す手順例の該当部分並びに解凍側のＦＰ圧縮判定部４２１の該当判断の部分及び後に示す手順例の該当部分は不要である）。また、解凍側のＦＰ圧縮判定部４２１は、ＦＰ圧縮の適用対象のメッセージについて、そのデータがＦＰ圧縮されたものか否かを判定する。以下では、ＦＰ圧縮の適用対象となるメッセージを転送する場合（ＦＰ圧縮の適用対象とすると判断された場合、または全メッセージをＦＰ圧縮の適用対象にする場合）を中心に説明する。
【０１０５】
図２１及び図２２に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。なお、図２１及び図２２は、１つのリプライメッセージを受けたときの処理を記述しているが、実際はサーバ側プロキシ３０が受け取ったリプライメッセージ全てに対して、図２１及び図２２に例示する処理を行う。
【０１０６】
サーバ側プロキシ３０は、受信部３１により、サーバ２０からリプライメッセージを受信する（ステップＳ１）。
【０１０７】
ＦＰ圧縮判定部３２１は、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（Ｓ２）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（Ｓ２）、受信したリプライメッセージを送信部３３からクライアント側プロキシ４０へ転送する（Ｓ１３）。
【０１０８】
ステップＳ２にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰキャッシュ管理部３２２にて、該リプライデータのフィンガープリントの値を計算し（Ｓ３）、該フィンガープリントの値をキーとしてＦＰキャッシュ３４を検索する（Ｓ４）。
【０１０９】
そして、該フィンガープリントの値とこれに対応するデータ（データ本体または差分圧縮データ）との組がＦＰキャッシュ３４に登録されていたならば（Ｓ５）、ＦＰ圧縮処理部３２３にて、受信したリプライメッセージを、該フィンガープリントの値を用いてＦＰ圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ６）。
【０１１０】
一方、ステップＳ４の検索の結果、該フィンガープリントの値とこれに対応するデータとの組がＦＰキャッシュ３４に登録されていなかったならば（Ｓ５）、差分圧縮処理部３２４にて、差分圧縮を行い（Ｓ７）、差分圧縮に成功したか否か判定する（Ｓ８）。
【０１１１】
差分圧縮に成功したか否かは、例えば、差分圧縮の対象とした元のデータのデータ量ｒ０と、差分圧縮データのデータ量ｒ１とを比較し、ｒ０−ｒ１＞ｄを満たすならば、成功したと判断する。ここで、定数ｄは、予め定められた０以上の整数である。
【０１１２】
ステップＳ８で差分圧縮に成功したと判断された場合、次の２つの作業を行う(1-1と1-2のいずれを先に行ってもよいし、並行して行ってもよい)。
（１−１）差分圧縮処理部３２４にて、受信したリプライメッセージを、（必要に応じて該フィンガープリントの値を用いて）差分圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ９）。
（１−２）ＦＰキャッシュ管理部３２２にて、該フィンガープリントの値と、ステップＳ７において生成された差分圧縮データとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ３４に登録する（Ｓ１０）。この際、登録するデータは差分圧縮データであるので、圧縮識別子を１にセットする。
【０１１３】
なお、上記（１−２）においては全ての差分圧縮データをＦＰキャッシュに登録するものとしたが、（ｉ）差分圧縮データのサイズと該差分圧縮データの元になったデータのサイズがほとんど変わらない場合は差分圧縮データではなく該差分圧縮データの元になったデータを保存する、（ｉｉ）差分圧縮データのサイズが該差分圧縮データの元になったデータのサイズに比べて非常に小さい場合は差分圧縮データは保存せず、該差分圧縮データの元になったデータも保存せず差分圧縮データ作成時に参照データとして用いたデータのＦＰキャッシュにおける登録を維持する、などの方法も可能である。その他にも種々のバリエーションがある。また、この点は、後で説明する他の処理手順例において差分圧縮データをＦＰキャッシュに登録する場合についても同様である（なお、後の説明でも、全ての差分圧縮データをＦＰキャッシュに登録するものとした場合を例にとって説明している）。
【０１１４】
一方、ステップＳ８で差分圧縮に失敗したと判断された場合、次の２つの作業を行う(2-1と2-2のいずれを先に行ってもよいし、並行して行ってもよい)。
(2-1)差分圧縮処理部３２４（あるいはＦＰ圧縮処理部３２３）にて、受信したリプライメッセージを、非圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ１１）。
(2-2)ＦＰキャッシュ管理部３２２にて、該フィンガープリントの値と、該リプライメッセージとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ３４に登録する（Ｓ１２）。この際、登録するデータは差分圧縮データではないので、圧縮識別子を０にセットする。
【０１１５】
次に、図２３〜図２５に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のクライアント側プロキシ４０の処理手順の一例を示す。なお、図２３〜図２５は、１つのリクエストメッセージを受けたときの処理を記述しているが、実際はクライアント側プロキシ４０が受け取ったリクエストメッセージ全てに対して、図２３〜図２５に例示する処理を行う。
【０１１６】
クライアント側プロキシ４０は、受信部４１により、サーバ側プロキシ３０からリプライメッセージを受信する（ステップＳ２１）。
【０１１７】
ＦＰ圧縮判定部４２１は、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（Ｓ２２）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（Ｓ２２）、受信したリプライメッセージを送信部４３からクライアント５０へ転送する（Ｓ３８）。
【０１１８】
ステップＳ２２にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰ圧縮判定部４２１は、さらに、リプライデータがＦＰ圧縮されているか否か調べ、判断する（Ｓ２３）。
【０１１９】
ステップＳ２３にて該リプライメッセージのリプライデータがＦＰ圧縮されているものと判断されたならば、ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ２４）、該フィンガープリントの値をキーとしてＦＰキャッシュ４４を検索する（Ｓ２５）。
【０１２０】
次に、ステップＳ２５において検索の結果得られたデータが差分圧縮データかどうか、ＦＰキャッシュ管理部４２２にて該データの圧縮識別子を用いて調べ、判断する（Ｓ２６）。
【０１２１】
ステップＳ２６にて該データが差分圧縮データであると判断された（本例では、圧縮識別子が１）ならば、差分解凍処理部４２４にて、（ＦＰキャッシュ管理部４２２において参照データを検索・取得した後に）差分圧縮データを解凍して元のリプライデータを復元し（Ｓ２７）、該復元したリプライデータをリプライメッセージに付加し、またプロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除し、該リプライメッセージを送信部４３からクライアント５０へ送信する（Ｓ２８）。
【０１２２】
ステップＳ２６にて該データが差分圧縮データではないと判断された（本例では、圧縮識別子が０）ならば、ＦＰ解凍処理部４２３にて、受信リプライメッセージに対して、ＦＰキャッシュ４４から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（Ｓ２９）。
【０１２３】
一方、ステップＳ２３にて該リプライメッセージのリプライデータがＦＰ圧縮されていないものと判断されたならば、ＦＰ圧縮判定部４２１は、さらに、該リプライデータが差分圧縮されているか否か判定する（Ｓ３０）。
【０１２４】
ステップＳ３０で差分圧縮されていると判断された場合、次の２つの作業を行う(1-1と1-2のいずれを先に行ってもよいし、並行して行ってもよい)。
（１−１）差分解凍処理部４２４にて、（ＦＰキャッシュ管理部４２２により参照データを検索・取得した後に）差分圧縮データを解凍して元のリプライデータを復元し（Ｓ３１）、該復元したリプライデータをリプライメッセージに付加し、またプロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除し、該リプライメッセージを送信部４３からクライアント５０へ送信する（Ｓ３２）。
（１−２）ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ３３）、該フィンガープリントの値と、差分圧縮データとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ４４に登録する（Ｓ３４）。このとき、ＦＰキャッシュ４４への登録においては、リプライメッセージは差分圧縮データであるので、圧縮識別子は１にセットする。
【０１２５】
一方、ステップＳ３０で差分圧縮されてないと判断された場合、次の２つの作業を行う(2-1と2-2のいずれを先に行ってもよいし、並行して行ってもよい)。
(2-1)差分解凍処理部４２４（あるいはＦＰ解凍処理部４２３）にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（Ｓ３５）。
(2-2)ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ３６）、該フィンガープリントの値と、該リプライメッセージとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ４４に登録する（Ｓ３７）。このとき、ＦＰキャッシュ４４への登録においては、リプライメッセージは差分圧縮データではないので、圧縮識別子は０にセットする。
【０１２６】
なお、ステップＳ２４／Ｓ３３／Ｓ３６では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リプライデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リプライデータをもとにフィンガープリントの値を計算する方法も可能である。また、ステップＳ２４／Ｓ３３／Ｓ３６は、フィンガープリントを使用する以前の他のタイミングで行って構わない。また、ステップＳ２２、Ｓ２３、Ｓ２６、Ｓ３０の判断の全部または一部を同時に行ってもよい。
【０１２７】
次に、差分圧縮を行う手順について説明する。
【０１２８】
図２６に、差分圧縮手順の一例を示す。これは、先に説明した３種類の指定を用いる場合の手順例である。
【０１２９】
ここでは、差分圧縮を行うために、フィンガープリント・キャッシュに入っているデータのうち、最近アクセスしたものを順に並べた履歴表を利用するものとする。この履歴表には、必ずしもフィンガープリント・キャッシュに入っている全てのデータのフィンガープリントが記録されている必要は無い。例えば、予め定められた個数が記録されていればよい（この場合、個数は、例えば差分圧縮の参照データとして使用するに有効な個数を想定して予め決定する）。
もちろん、履歴表への記録の基準として、最近のアクセスの順以外の１又は複数の基準を用いてもよいし、最近のアクセスの順の基準に加えて他に１又は複数の基準を併用してもよい。
【０１３０】
なお、履歴表は、フィンガープリント・キャッシュと一体化して構成する方法もある。
【０１３１】
（ステップＳ２３１）
まず、作業用のコピーバッファおよび指示バッファを空にする。
【０１３２】
このコピーバッファにコピーされた内容をもとに、図６（ａ）〜（ｃ）の指示が作成され、これが指示バッファに書き出される。最終的に、指示バッファに書き出された指示の並びが、差分圧縮データになる。
【０１３３】
（ステップＳ２３２）
差分圧縮の対象とするデータを文字列として扱い、その文字列上を指すポインタを用意する。まず、ポインタが当該文字列のうちの最初の文字を指すように設定する。
【０１３４】
以下では、ステップＳ２４１でポインタが当該文字列のうちの最後の文字に辿りついたと判断されるまで、ループ処理を実行することになる。
【０１３５】
（ステップＳ２３３）
履歴表に記録されているフィンガープリントに対応するデータを、新しいものから順に取り出し、その中に、差分圧縮したいデータの中のポインタの指す場所から予め定められた長さ以上マッチするデータを参照データとして取り出す。
【０１３６】
なお、参照データと決定方法としては、種々の方法がある。例えば、履歴表に記録されているフィンガープリントに対応するデータを最新の順に調べていき、最初に予め定めた長さ以上マッチしたデータを参照データとして取り出す方法、履歴表に記録されているフィンガープリントに対応するデータの全てを調べ、その中でマッチした長さが最も長かったデータ（ただし、予め定めた長さ以上マッチしたことを条件とする）を参照データとして取り出す方法などがある。
【０１３７】
（ステップＳ２３４）
参照データが見つけられたらならば、ステップＳ２３７へ移る。参照データが見つけられなかったならば、ステップＳ２３５へ移る。
【０１３８】
（ステップＳ２３７）
ステップＳ２３４にて参照データが見つけられた場合に、コピーバッファが空でなければ、コピーバッファ中の文字列に対応する、図６の（ｃ）の直接指定によるコピー指示を作成し、これを指示バッファに書き出す。コピーバッファは、空にする。
なお、コピーバッファが空ならば、何もしない。
【０１３９】
（ステップＳ２３８）
ステップＳ２３３にて見つかった参照データに対応する図６の（ａ）の参照データ定義が未だ指示バッファに書き出されていなければ、指示バッファに当該参照データ定義の指示を書き出す。
【０１４０】
（ステップＳ２３９）
参照データからマッチした文字列のコピー指示を、図６の（ｂ）のコピー指示として指示バッファに書き出す。
【０１４１】
（ステップＳ２４０）
ポインタを参照データとマッチした文字列の長さ分だけ進める。
【０１４２】
（ステップＳ２３５）
一方、ステップＳ２３４にて参照データが見つけられた場合に、ポインタの指す文字をコピーバッファに入れる。
【０１４３】
（ステップＳ２３６）
ポインタを１文字分だけ進める。
【０１４４】
（ステップＳ２４１）
差分圧縮の対象とするデータの最後までポインタが来ていなければ（処理していないデータ部分が残っていれば）、ステップＳ２３３へ戻る。差分圧縮の対象とするデータの最後までポインタが来ていたら（処理していないデータ部分が残っていなければ）、処理ループを抜けて、ステップＳ２４２へ移る。
【０１４５】
（ステップＳ２４２）
コピーバッファが空でなければ、コピーバッファ中の文字列に対応する、図６の（ｃ）の直接指定によるコピー指示を作成し、これを指示バッファに書き出す。コピーバッファは、空にする。
なお、コピーバッファが空ならば、何もしない。
【０１４６】
このときの指示バッファの内容が、差分圧縮データとなる。
【０１４７】
なお、前述のように、実際には、このようにして差分圧縮を行った後、差分圧縮を行った結果のデータサイズが、行う前のデータサイズよりも小さくなっている（あるいは一定基準（一定の圧縮量）を超えて小さくなっている）ことを確認する。差分圧縮によってデータサイズが小さくならない（あるいは一定基準（一定の圧縮量）を超えては小さくならない）場合には、差分圧縮しない方が良いので、データはそのまま転送する。
【０１４８】
ところで、上記の差分圧縮の処理において、ステップＳ２３３の予め定められた長さ以上マッチする文字列を持つ最新のデータを選び出す処理が、最も時間がかかる処理であると考えられる。この処理をより高速化するために、ハッシュ表を利用することができる。履歴表に入れるデータから、その中の全ての予め定められた長さの文字列を取り出し、そのハッシュ値（例えば、全ての文字のコードを足したものなど）を計算し、ハッシュ表に登録しておく。このハッシュ表は、同じハッシュ値を持つデータがあればより最新のデータによって上書きされるようにしておく。
このハッシュ表を使って、差分圧縮したいデータの現在のポインタの位置から予め定められた長さの文字列のハッシュ値を求め、そのハッシュ値を使ってハッシュ表を引いて求めたデータが、ステップＳ２３３で選ぶべきデータの第１の候補になる。ここで、異なる文字列でも同じハッシュ値を生成する場合があるので、本当に同じかどうかは文字列を実際に比較して確認し、同じでなければ、履歴表のデータを順に見るなど方法で次の候補を探す。
【０１４９】
ステップＳ２３３の処理を高速化する他の方法は、行を単位として比較処理を行う方法である。図２６の手順では文字を単位として比較処理をしていたが、履歴表にあるすべてのデータに対して、そのデータ内の各行のハッシュ値の列を計算しておく。差分圧縮したいデータからも、まず、各行のハッシュ値の列を計算する。以降は、図２６の手順と同様であるが、比較は文字単位ではなく、行のハッシュ値を単位として行う。この方法は、行を単位としているため、文字単位よりも比較回数を減らすことができる。ただし、ハッシュ値で比較するために、異なる行でも同じハッシュ値を持つ場合があるので、最終的にはハッシュ値が同じだと判断した後に、実際に行の中も比較して本当に同じかどうかを判断するのが望ましい。
もちろん、このように行を単位として比較する構成についても、上記のハッシュ技法を組み合わせることができる。この場合、連続する複数行を組み合わせて、予め定められた長さと同じか長くなる最少の行数を単位としてハッシュ表に登録すればよい。
【０１５０】
次に、図２７に、差分圧縮手順の他の例を示す。これは、フィンガープリント・キャッシュに登録されているデータのうちの１つを参照データとし、プロキシ間では、参照データに対応するフィンガープリントの値と、転送データと参照データとの差分を示す情報とを転送する場合の手順例である。
【０１５１】
ここでも、前述したような履歴表を用いるものとする。
【０１５２】
まず、履歴表に記録されているフィンガープリントに対応するデータのうち、所定の基準を満たす一つを、参照データとして選択する（ステップＳ２４５）。
【０１５３】
所定の基準は、例えば、差分圧縮の対象とするデータのうち、参照データとするデータとの間でマッチしなかった部分のデータ量が、予め定められたデータ量以下であって、かつ、参照データをそのマッチしなかった部分によって複数の塊に分断したときにおけるその分断された塊の数が、予め定められた数以下である場合に、これを参照データとして選択可能とする。
【０１５４】
そして、参照データとして決定する方法としては、前述のように、例えば、履歴表に記録されているフィンガープリントに対応するデータを最新の順に調べていき、最初に予め定めた長さ以上マッチしたデータを参照データとして取り出す方法、履歴表に記録されているフィンガープリントに対応するデータの全てを調べ、その中でマッチしなかったデータ量や分断数が最も少なかったデータを参照データとして取り出す方法など、種々の方法がある。
【０１５５】
参照データが見つけられたらならば（Ｓ２４６）、参照データ定義の指示（例えば図６の（ａ））を、指示バッファに書き出す（Ｓ２４７）。
【０１５６】
参照データのうち、マッチしなかった部分（直接指定データで置換する部分）を示す指示（例えば図６の（ｂ）と同じフォーマットの指示で１バイト目の指示識別子を変えたもの）を、指示バッファに書き出す（Ｓ２４８）。
【０１５７】
参照データのマッチしなかった部分に嵌め込むべきデータを示す直接指定する指示（例えば図６の（ｃ））を、指示バッファに書き出す（Ｓ２４９）。
【０１５８】
なお、置換部分が複数個所ある場合には、その分だけステップＳ２４８とステップＳ２４９を実行する。
【０１５９】
このときの指示バッファの内容が、差分圧縮データとなる。
【０１６０】
一方、参照データが見つけられたらならば（Ｓ２４６）、差分圧縮はしないことになる。
【０１６１】
なお、上記の図２６や図２７の説明では、履歴表をフィンガープリント・キャッシュとは別に設けるものとしたが、履歴表は、フィンガープリント・キャッシュと一体化して構成する方法もある。
【０１６２】
また、上記の説明では、履歴表を用いるものとしたが、履歴表を用いない方法もある。例えば、フィンガープリント・キャッシュを所定の順番で（例えば、エントリ順にあるいはランダムに）予め定められた上限数だけ調べ、それらのうちで最良のものを使用するようにする方法や、フィンガープリント・キャッシュを所定の順番で（例えば、エントリ順にあるいはランダムに）調べ、予め定められた条件を満たす参照データが初めて得られた時点で、参照データを決定してしまう方法など、種々の方法がある。
【０１６３】
また、履歴表またはフィンガープリント・キャッシュに、フィンガープリントに加えて、そのフィンガープリントを登録したときに元となったリプライデータを含んでいたリプライメッセージについてのＵＲＬをも保持しておき、参照データを探索する際に、まず差分圧縮対象のリプライデータを含むリプライメッセージについてのＵＲＬと同じＵＲＬを持つデータが、履歴表またはフィンガープリント・キャッシュに登録されていないかどうか調べ、登録されているならば当該ＵＲＬと同じＵＲＬを持つデータを他のものよりも優先して、参照データとして使用できないかどうか調べるようにしてもよい。
【０１６４】
もちろん、図２６や図２７の他にも、種々の差分圧縮の手順が可能である。
【０１６５】
なお、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際にはフィンガープリント・キャッシュを用いないものとする場合には、サーバ側プロキシ３０は、図２８に例示するように、クライアント側プロキシ４０からリクエストメッセージを受信し（ステップＳ６０）、これをサーバ２０へ送信する（ステップＳ６１）、という手順で構わない。同様に、クライアント側プロキシ４０は、図２９に例示するように、クライアント５０からリクエストメッセージを受信し（ステップＳ６２）、これをサーバ側プロキシ３０へ送信する（ステップＳ６３）、という手順で構わない。
【０１６６】
以下では、図３０〜図３２を参照しながら、フィンガープリント・キャッシュを利用したデータ転送についてより具体的に説明する。
【０１６７】
まず、図３０を参照しながら、サーバ側プロキシ３０からクライアント側プロキシ４０へ、フィンガープリント・キャッシュ登録されていないデータであって且つ差分圧縮も成功しなかったデータを転送するとともに、該データについてフィンガープリント・キャッシュ登録する場合の動作について説明する。
【０１６８】
（１）クライアント５０上のブラウザ等は、例えば“/A.cgi”というＵＲＬでサーバ２０に、ＰＯＳＴメソッドのリクエストメッセージを出したとする。サーバ２０へのリクエストメッセージは、まず、クライアント側プロキシ４０に送られるように、ブラウザ等を設定しておく。
【０１６９】
（２）クライアント５０からリクエストメッセージを受け取ったクライアント側プロキシ４０は、そのリクエストメッセージをサーバ側プロキシ３０に転送する。
【０１７０】
（３）リクエストメッセージを受け取ったサーバ側プロキシ３０は、そのリクエストメッセージをサーバ２０へ転送する。
【０１７１】
（４）サーバ２０は、該リクエストメッセージに対する処理を行った後、サーバ側プロキシ３０に、そのリプライメッセージを送り返す。
【０１７２】
（５）リプライメッセージを受け取ったサーバ側プロキシ３０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここでは、入っておらず、初めてのデータ（一旦フィンガープリント・キャッシュ登録されたものがその後に削除あるいは無効化されることがある構成の場合に、一旦フィンガープリント・キャッシュ登録されたが削除あるいは無効化され、その後において初めてである場合を含む）であるので、そのデータをフィンガープリントを名前としてＦＰキャッシュ３４に入れる（登録する）。なお、ここでは、リプライデータを差分圧縮してデータ量を減らすことができなかったものとする。このとき、ＦＰキャッシュ３４への登録においては、該データが差分圧縮データではないので、圧縮識別子は０にセットする。
【０１７３】
（６）サーバ側プロキシ３０は、データを載せたリプライメッセージをクライアント側プロキシ４０に転送する。なお、リプライデータから計算したフィンガープリントの値を、リプライヘッダ等に入れて送ると、クライアント側プロキシ４０で再度フィンガープリントを計算する手間を省くことが出来る。
【０１７４】
（７）リプライメッセージを受け取ったクライアント側プロキシ４０は、初めてのデータであるので、リプライデータをＦＰキャッシュ４４に登録する。このとき、ＦＰキャッシュ４４への登録においては、該リプライデータが差分圧縮データではないので、圧縮識別子は０にセットする。なお、前述したように、リプライデータからフィンガープリントを計算するか、あるいはサーバ側プロキシがリプライヘッダ等に入れたフィンガープリントを取り出し、これを名前として入れる。
【０１７５】
（８）クライアント側プロキシ４０は、（リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除した後に、）リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１７６】
なお、サーバ側プロキシ３０において、上記の（５）のフィンガープリント・キャッシュ登録は、（６）の動作の後に行っても構わない。また、クライアント側プロキシ４０において、（７）のフィンガープリント・キャッシュ登録は、（８）の動作の後に行っても構わない。
【０１７７】
次に、図３１を参照しながら、サーバ側プロキシ３０からクライアント側プロキシ４０へ、フィンガープリント・キャッシュ登録されていないデータであって且つ差分圧縮が成功したデータを転送するとともに、該データについてフィンガープリント・キャッシュ登録する場合の動作について説明する。
【０１７８】
（１）〜（４）は、図３０を参照して説明した動作における（１）〜（４）と同様である。
【０１７９】
（５）リプライメッセージを受け取ったサーバ側プロキシ３０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここでは、入っておらず、初めてのデータであることを判断する。そして、圧縮対象になるデータをＦＰ圧縮できなかった場合には、差分圧縮処理を行い、リプライデータを差分圧縮してデータ量を減らすことができるならば、差分圧縮する。ここでは、フィンガープリントが“７１Ｆ０…７３Ｅ６”のデータを参照データとした場合に、リプライデータを差分圧縮してデータ量を減らすことができたものとする。リプライデータを差分圧縮データに置き換え、リプライヘッダ等に差分圧縮したことを示す情報を入れる。
【０１８０】
（６）サーバ側プロキシ３０は、（５）において生成された差分圧縮データを同じく（５）で計算したフィンガープリントを名前としてＦＰキャッシュ３４へ入れる（登録する）。このとき、ＦＰキャッシュ３４への登録においては、該データが差分圧縮データであるので、圧縮識別子を１にセットする。
【０１８１】
（７）サーバ側プロキシ３０は、リプライメッセージをクライアント側プロキシ４０に転送する。
【０１８２】
（８）クライアント側プロキシ４０は、リプライヘッダ等を見て、リプライデータが差分圧縮されていることを知り、圧縮の解凍を行う。このとき、まず、圧縮されたデータ内に指定されている参照データのフィンガープリント“７１Ｆ０…７３Ｅ６”を取り出し、次に、該フィンガープリントに対応するデータをＦＰキャッシュ４４から取り出して使用する。そして解凍したデータをリプライデータに入れ、リプライヘッダのコンテンツサイズなど必要なヘッダを書き換える。
【０１８３】
（９）また、リプライメッセージを受け取ったクライアント側プロキシ４０は、初めてのデータであるので、サーバ側プロキシ３０から受信した差分圧縮データをＦＰキャッシュ４４に登録する。このとき、ＦＰキャッシュ４４への登録においては、登録するデータが差分圧縮データであるので、圧縮識別子を１にセットする。また、リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除する。なお、前述したように、リプライデータ（差分圧縮データから解凍して得られたデータ）からフィンガープリントを計算するか、あるいはサーバ側プロキシがリプライヘッダ等に入れたフィンガープリントを取り出し、これを名前として入れる。
【０１８４】
（１０）クライアント側プロキシ４０は、リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１８５】
なお、上記の（５）では、圧縮対象で未登録のデータは、すべてフィンガープリント・キャッシュに登録するものとし、また、上記の（６）で参照データに用いたデータは、すべてフィンガープリント・キャッシュの登録を維持するものとしたが、参照データに唯一のデータを使用した場合であって、かつ、差分圧縮対象となったデータと、その差分圧縮に用いた参照データとが、ほとんど同じ内容（例えば、両者でマッチしないデータ量が基準以下）である場合には、（ｉ）圧縮対象で未登録のデータはフィンガープリント・キャッシュに登録せず、参照データはフィンガープリント・キャッシュの登録を維持する、あるいは（ii）圧縮対象で未登録のデータをフィンガープリント・キャッシュに登録し、参照データはフィンガープリント・キャッシュから削除する、などの方法も可能である。また、参照データに唯一のデータを使用した場合であって、かつ、差分圧縮対象となったデータと、その差分圧縮に用いた参照データとが、ほとんど同じ内容であって、かつ、ＵＲＬが同一の場合には、データが更新されたものとして、圧縮対象で未登録のデータをフィンガープリント・キャッシュに登録し、参照データはフィンガープリント・キャッシュから削除する、などの方法も可能である。その他にも種々のバリエーションがある。
【０１８６】
次に、図３２を参照しながら、図３０または図３１の動作が行われてキャッシュ登録されているデータを、サーバ側プロキシ３０からクライアント側プロキシ４０へ転送する場合の動作について説明する。
【０１８７】
（１）〜（４）は、図３０を参照して説明した動作における（１）〜（４）と同様である。
【０１８８】
（５）サーバ５０からリプライメッセージを受け取ったサーバ側プロキシ４０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここではフィンガープリント・キャッシュ登録されているので、（例えばフィンガープリントの値をリプライヘッダ等に入れ且つリプライボディを空にするなどして）リプライボディのデータをフィンガープリントで置き換える。
【０１８９】
（６）サーバ側プロキシ３０は、リプライボディをフィンガープリントで置き換えたリプライメッセージをクライアント側プロキシ４０に転送する。
【０１９０】
（７）リプライメッセージを受け取ったクライアント側プロキシ４０は、リプライデータがフィンガープリントで置き換えられていることを検出し、（前述したように例えばリプライヘッダなどにて）指定されたフィンガープリントを使ってＦＰキャッシュ４４から対応するデータを取り出す。
ここで、該データの圧縮識別子が０である場合には、該データは差分圧縮データではないので、これをリプライボディに入れる。一方、該データの圧縮識別子は１である場合には、該データは差分圧縮データであるので、これを解凍してもとのリプライデータを復元し、これをリプライボディに入れる。なお、図３２は、前者の場合を例示している。
また、リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除する。
【０１９１】
（８）そして、クライアント側プロキシ３０は、リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１９２】
ところで、サーバ側プロキシ３０およびクライアント側プロキシ４０のフィンガープリント・キャッシュは、その容量に上限があるため、所定のアルゴリズムに従いガベージコレクションを行って、例えば古いデータや使いそうに無いデータを消して行くのが好ましい。
【０１９３】
ただし、このようにすると、サーバ側プロキシ３０のＦＰキャッシュ３４は持っていてもクライアント側プロキシ４０のＦＰキャッシュ４４では既に消されているようなデータが発生し得ることになるので、図３２を参照して説明した動作における（７）で、クライアント側プロキシ４０において、フィンガープリントをもとにしてＦＰキャッシュ４４からリプライデータを置き換えるべきデータを得ようとしたが、ＦＰキャッシュ４４に該当するフィンガープリントとデータの組が存在しない場合がある。このような場合には、例えば、クライアント側プロキシ４０は、サーバ側プロキシ３０に対して、指定したフィンガープリントのデータを送るように依頼し、依頼されたサーバ側プロキシ３０は、指定されたフィンガープリントのデータをＦＰキャッシュ３４から取り出して送り返すような仕組みを設ければよい。
【０１９４】
なお、逆に、サーバ側プロキシ３０のＦＰキャッシュ３４では既に消されているがクライアント側プロキシ４０のＦＰキャッシュ４４はまだ持っているようなデータが存在する場合には、図３０を参照して説明した動作における（７）や図３１を参照して説明した動作における（９）で、クライアント側プロキシ４０において、フィンガープリント／データをＦＰキャッシュ４４に登録する際に、その時点で登録されていたフィンガープリント／リプライデータに対して上書きしてもよい。
【０１９５】
図３２を参照して説明した動作における（５）で、サーバ側プロキシ３０において、リプライデータのフィンガープリントを求め、該フィンガープリントがＦＰキャッシュ３４に入っていれば、当該プライデータと同じデータが該フィンガープリントと組になってＦＰキャッシュ３４に入っているものとみなして処理している。実用上、異なるデータから同じフィンガープリントが生成されないことを前提にすれば、この方法で十分であるが、非常に小さな確率で異なるデータのフィンガープリントが偶々同じ値になってしまった場合に生じるエラーを取り除くようにする方法もある。この場合には、リプライデータから求めたフィンガープリントがＦＰキャッシュ３４に入っているときに、該フィンガープリントと組になってＦＰキャッシュ３４に入っているデータと、当該プライデータとを比較して、同じか否かを判断するようにすればよい。このとき、もしフィンガープリントは同じであるが内容が異なるデータが登録されていると判断された場合の処理は、以下に例示するような方法が考えられる。
・そのフィンガープリントは以降使用しないものとする（そのフィンガープリントを与えるデータは以後キャッシュされないことになる）
・先に登録されているフィンガープリント／データを優先する（登録中のフィンガープリントと同じ値のフィンガープリントを与える他のデータは、その登録中はキャッシュされないことになる）
・現在登録対象となっているフィンガープリント／データを優先する（登録中のフィンガープリント／データは、同じ値のフィンガープリントを与える他のデータによって次々と更新されていくことになる）
ところで、これまで説明した例では、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライデータを転送する際にフィンガープリント・キャッシュを利用するものとし、あるデータとこれに対するフィンガープリントとの組をフィンガープリント・キャッシュに登録するタイミングは、そのデータが初めてサーバ側プロキシ３０からクライアント側プロキシ４０へ転送されるときとしている。しかし、例えばＷｅｂベースのＡＳＰのような利用法では、データはまずユーザオフィス等で作成されてサーバに登録され、それをブラウザ等からアクセスするような場合が多いため、このような場合には、当該データを（データ本体または差分圧縮データとして）サーバに登録する時点でクライアント側プロキシおよびサーバ側プロキシのフィンガープリント・キャッシュに登録しておくと、それ以降のアクセスを高速化することができる。そこで、サーバが送信するリプライデータが、もともとはクライアントからサーバへ転送されたデータ（ただし、この転送のときはリクエストデータ）である場合には、登録タイミングを、該リプライデータとなる元のリクエストデータが初めてクライアント側プロキシ４０からサーバ側プロキシ３０へ転送されるときとするようにしてもよい（この場合、当該データがリプライデータとなって初めてサーバ側プロキシ３０からクライアント側プロキシ４０へ転送される際には、すでにフィンガープリント・キャッシュへの登録が完了していることになるので、リプライデータとしては初めての転送であっても、フィンガープリント・キャッシュを利用して、転送データ量を削減することができる）。
【０１９６】
さて、これまで説明した例では、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライデータを転送するときに、該リプライデータがフィンガープリント・キャッシュに登録されているデータと同じものである場合には、該リプライデータに代えて、対応するフィンガープリントを転送し、または差分圧縮データを転送することで、ネットワークのトラフィックを軽減しているが、本発明は、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストデータを転送する場合についてさらに適用することが可能である。
【０１９７】
なお、ＦＰ圧縮を両方に適用する場合に、差分圧縮をいずれか一方についてのみ適用することも可能である。
【０１９８】
また、ＦＰ圧縮および差分圧縮を、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストデータを転送する場合についてのみ適用することも可能である。
【０１９９】
ＦＰ圧縮および差分圧縮をクライアント側プロキシ４０からサーバ側プロキシ３０へのリクエストデータ転送に適用する場合、すでに説明したリプライデータに対するサーバ側プロキシ３０とクライアント側プロキシ４０との役割を逆にすればよいので、ＦＰ圧縮および差分圧縮を両データ転送に適用する場合には、サーバ側プロキシ３０は図１９の構成に加えて、更に処理部３２にフィンガープリント解凍処理部および差分解凍処理部を備え、クライアント側プロキシ４０は図２０の構成に加えて、更に処理部４２にフィンガープリント圧縮処理部および差分圧縮処理部を備えればよい。
【０２００】
なお、いずれのプロキシにおいても、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せて、フィンガープリント（ＦＰ）圧縮・解凍処理部としてもよい。同様に、差分圧縮処理部と差分解凍処理部とを併せて、差分圧縮・解凍処理部としてもよい。
【０２０１】
また、サーバ側プロキシ３０やクライアント側プロキシ４０は、リプライデータ転送に対するフィンガープリント・キャッシュとは独立にリクエストデータ転送に対するフィンガープリント・キャッシュを設けてもよいが、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用してもよい。なお、差分圧縮の際に前述した履歴表を使用する構成の場合には、履歴表についても同様に独立して設けてもよいし、共用してもよい。
【０２０２】
図３３に、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用する場合のプロキシ（サーバ側プロキシ、クライアント側プロキシ）の構成例を示す。
【０２０３】
また、図３４及び図３５に、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際のクライアント側プロキシ４０の処理手順の一例を示す。図３４及び図３５は、図２１及び図２２において、転送するメッセージがリプライメッセージからリクエストメッセージになり、メッセージ送信元がサーバからクライアントになり、メッセージ送信先がクライアントからサーバになり、サーバ側プロキシ３０の動作とクライアント側プロキシ４０の動作とを入れ替えたものに相当する。
【０２０４】
また、図３６〜図３８に、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。
【０２０５】
図３６〜図３８は、図２３〜図２５において、転送するメッセージがリプライメッセージからリクエストメッセージになり、メッセージ送信元がサーバからクライアントになり、メッセージ送信先がクライアントからサーバになり、サーバ側プロキシ３０の動作とクライアント側プロキシ４０の動作とを入れ替えたものに相当する。
【０２０６】
このようにリクエストデータに対してもフィンガープリントまたは差分圧縮データで置き換えられるように実施すると、例えば、同じファイルを何度もサーバにアップロードするときには、２回目以降フィンガープリントを送るだけで済むので、ネットワークのトラフィックを軽減させることができる。
【０２０７】
なお、本実施形態では、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージや、サーバ側プロキシからクライアント側プロセスへ転送されるリプライメッセージを対象とする場合について示してきたが、あるプロキシに、リクエストメッセージを送信する装置とリプライメッセージを送信する装置との両方、あるいはリクエストメッセージおよびリプライメッセージの両方を送信する装置が接続されている場合には、もちろん、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージおよびリプライメッセージならびにサーバ側プロキシからクライアント側プロセスへ転送されるリクエストメッセージおよびリプライメッセージを対象とすることや、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージおよびサーバ側プロキシからクライアント側プロセスへ転送されるリクエストメッセージのみ対象とすることなども可能である。
【０２０８】
ところで、これまでは１つのサーバ側プロキシと１つのクライアント側プロキシとの間の１対１の通信に着目して説明してきたが、本発明の適用範囲はもちろんサーバ側プロキシとクライアント側プロキシとが１対１で通信するシステムには限定されるものではなく、サーバ側プロキシとクライアント側プロキシとが１対多で通信するシステム、サーバ側プロキシとクライアント側プロキシとが多対１で通信するシステム、あるいはサーバ側プロキシとクライアント側プロキシとが多対多で通信するシステムにも適用可能である。例えば、図３９のように、複数のユーザオフィスに設置したクライアント側プロキシや、モバイルユーザが利用する個人用プロキシなどがサーバ側プロキシを共有して使用するように実施することも可能である。
【０２０９】
また、これまでは、１つのメッセージに含まれるデータ全体をＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にしていたが、例えば、１つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、１つのメッセージに含まれる一部の単位データのみＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にする構成も可能である。
【０２１０】
ところで、本実施形態のサーバ側プロキシあるいはクライアント側プロキシ（一方でも両方でもよい）に、プロキシの共有キャッシュ機構でキャッシュ可能とされているリプライデータについて、クライアントが出したリクエストメッセージにおいて指定されていたＵＲＬと、該リクエストメッセージに対応するリプライメッセージに含まれていたリプライデータと、該リプライデータに対応するフィンガープリントと、該リプライメッセージのリプライ・ヘッダに入れられて来たＭＩＭＥタイプなどのリクエスト・ヘッダを構成するのに必要な情報や有効期間の判定に使うためのタイムスタンプなどの情報を対応付けてキャッシュしておき（フィンガープリント・キャッシュにすべて保持してもよいし、リプライデータを除く情報（ＵＲＬとフィンガープリントと他の情報）を保持する対応テーブルを別途設けてもよい）、これとフィンガープリント・キャッシュとを併用することで、プロキシサーバの共有キャッシュの動作をも行うようにすることができる。例えば、クライアント側プロキシに該キャッシュ機能を設けた場合、クライアントが送信したリクエストメッセージにて指定されているＵＲＬに対するリプライデータがキャッシュされており且つ該データが有効である場合には、該クライアント側プロキシが、ＵＲＬに対応するデータをフィンガープリント・キャッシュから取得して、リプライメッセージを作成して、これをクライアントに応答することができる。
【０２１１】
この機能は、個々のサーバ側プロキシ３０毎に、また個々のクライアント側プロキシ４０毎に、設けるか否かを定めることができる。
【０２１２】
まず、上記機能を設けたクライアント側プロキシ４０について説明する。
【０２１３】
図４０に、この場合のクライアント側プロキシ４０の構成例を示す。このクライアント側プロキシ４０は、図２０の構成・機能に加えて、更に過去にアクセスしたＵＲＬと、そのリプライデータのフィンガープリントとの対応を保持するＵＲＬ・フィンガープリント・テーブル（ＵＲＬ・ＦＰテーブル）４５と、ＵＲＬキャッシュ処理部４２７とを備えている。
【０２１４】
なお、ＵＲＬ・ＦＰテーブル４５には、ＵＲＬおよびフィンガープリント以外に、そのＵＲＬでアクセスしたときにリプライヘッダに入れられて来たＭＩＭＥタイプや、有効期間の判定に使うためのタイムスタンプなどの情報も併せて記録する。また、ＵＲＬ・ＦＰテーブル４５には、従来の共有キャッシュがキャッシュできる場合にのみ必要な情報を記録する。
【０２１５】
図４１に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のクライアント側プロキシ４０の処理手順例を示す。
【０２１６】
なお、この場合の処理手順は、図２３〜図２５の手順の端子４および端子６およびステップＳ３８の後に追加される以外は、図２３〜図２５の手順と同じであり、図４１では、図２３〜図２５の手順の端子４および端子６およびステップＳ３８より後の処理手順の部分を示してある。ここでは、図２３〜図２５で説明した手順に追加する部分を中心に説明する。
【０２１７】
クライアント側プロキシ４０は、送信部４３により、クライアント５０にリプライメッセージを送信（図２３〜図２５のステップＳ２８、Ｓ２９、Ｓ３２、Ｓ３５またはＳ３８）した後、ＵＲＬキャッシュ処理部４２７にて、該リプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ３９）。キャッシュ対象であると判断されたならば、ＵＲＬキャッシュ処理部４２７にて、ＵＲＬとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて（ＵＲＬをキーにして）をＵＲＬ・ＦＰテーブル４５に登録する（Ｓ４０）。キャッシュ対象でないと判断されたならば、何もしない。
【０２１８】
なお、ステップＳ３９の判断およびステップＳ４０のＵＲＬ・ＦＰテーブルへの登録は、ステップＳ２３とステップＳ２８あるいはＳ２９、ステップＳ２３とステップＳ３２あるいはステップＳ３５の間にて行うようにしても構わない。
【０２１９】
なお、登録時の受信リプライメッセージがキャッシュ対象のものであるか否かの判断方法は、従来の登録時の手法と同様で構わない（例えば、ＧＥＴメソッドのリプライデータであって、かつ、そのヘッダにキャッシュ不可を示す情報が記述されていないものをキャッシュ対象とする等）。
【０２２０】
次に、図４２および図４３に、クライアント２５０から受信したリクエストメッセージをクライアント側プロキシ４０からサーバ側プロキシ３０へ転送する際のクライアント側プロキシ４０におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【０２２１】
クライアント側プロキシ４０は、受信部４１により、クライアント５０からリクエストメッセージを受信する（ステップＳ１４１）。
【０２２２】
ＵＲＬキャッシュ処理部４２７は、リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１４２）。なお、応答時のキャッシュ対象か否かの判断方法は、従来の応答時の手法と同様で構わない（例えば、受信リクエストメッセージがＧＥＴメソッドのものであるか否か）。
【０２２３】
リクエストデータがキャッシュ対象外のものと判断されたならば（Ｓ１４２）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。
【０２２４】
ステップＳ１４２にて該リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであると判断されたならば、ＵＲＬキャッシュ処理部４２７は、さらに、該リクエストメッセージに指定されているＵＲＬを取り出し（Ｓ１４３）、そのＵＲＬをキーとしてＵＲＬ・ＦＰテーブル４５を検索する（Ｓ１４４）。
【０２２５】
そのＵＲＬに対応するリプライデータのフィンガープリントがキャッシュされていなければ（Ｓ１４５）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。このとき、現在保持しているデータのタイムスタンプをリクエストメッセージのIf-Modified-Sinceヘッダに記入してサーバ側プロキシ３０へ転送し、サーバ側プロキシ３０から現在保持しているデータが有効であるとのリプライメッセージを受け取ると、ステップＳ１４７へ行くように実施することもできる。
【０２２６】
また、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されていても（Ｓ１４５）、併せて保持されている有効期間の判定のための情報に基づいてそのデータが無効になっていると判断されれば（Ｓ１４６）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。
【０２２７】
一方、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されており（Ｓ１４５）、かつ、併せて保持されている有効期間の判定のための情報に基づいてそのデータが有効であると判断されれば（Ｓ１４６）、ＵＲＬキャッシュ処理部４２７は、ＵＲＬ・ＦＰテーブル４５からリプライデータを構成するのに必要な情報を得るとともに、当該ＵＲＬに対応するリプライデータのフィンガープリントをキーとしてＦＰキャッシュ４４を検索する（Ｓ１４７）。
【０２２８】
次に、ＦＰキャッシュ管理部４２２は、ステップＳ１４７にて取得したデータが差分圧縮データであるかどうかを、圧縮識別子が０または１のいずれであるかをもって判断する（Ｓ１４８）。圧縮識別子が０であれば、差分圧縮データではないと判断され、１であれば、差分圧縮データであると判断される。
【０２２９】
該データが差分圧縮データであることが判明した場合（Ｓ１４８）、差分解凍処理部４２４は該データを解凍し、リプライデータを生成する（Ｓ１４９）。そして、該リプライデータからリプライメッセージを生成し、送信部４３からクライアントへ転送する（Ｓ１５０）。
【０２３０】
一方、該データが差分圧縮データでないことが判明した場合（Ｓ１４８）、ＦＰ圧縮解凍部４２３は、該データからリプライデータを生成し、送信部４３からクライアントへ転送する（Ｓ１５０）。
【０２３１】
以下では、図４４（応答時）を参照しながら、共有キャッシュの動作についてより具体的に説明する。
【０２３２】
（１）クライアント５０上のブラウザ等は、例えば“/C.html”というＵＲＬでサーバ２０に、ＧＥＴメソッドのリクエストメッセージを出したとする。
【０２３３】
（２）新しいＵＲＬでリクエストが来たときに、そのＵＲＬがＵＲＬ・ＦＰテーブル４５に載っていれば、従来の共有キャッシュと同様に有効期間の判定を行い、有効と判断できれば、そのＵＲＬに対応するフィンガープリントをＵＲＬ・ＦＰテーブル４５を引いて求め、それを名前とするデータをＦＰキャッシュ４４から取り出す。そして、圧縮識別子により、該データが差分圧縮データかどうか調べる。図４４の例では、圧縮識別子が１であるので差分圧縮データである。すると、差分圧縮を解凍し（図４４では、差分圧縮データ内に、フィンガープリントが“７１Ｆ０…７３Ｅ６”であるデータへの参照情報があるため、既にキャッシュされている該データが参照され、解凍される）、これをリプライデータとする。さらに、ＵＲＬ・ＦＰテーブル４５からＭＩＭＥタイプ等のリプライヘッダを構成するのに必要な情報を取り出してリプライヘッダを作成する。
【０２３４】
（３）作成したリプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０２３５】
なお、キャッシュの内容が指定した時間以降に更新されている場合にのみデータを送ることを依頼するIf-Modified-Sinceヘッダを持つリクエストメッセージの場合も、まずＵＲＬ・ＦＰテーブルを参照し更新されていないことが判断できれば、そこでリプライメッセージを作成して返し、そうでなければサーバまで再びIf-Modified-Sinceの情報を書き直して聞きに行くように実施することもできる。
【０２３６】
次に、キャッシュ機能を設けたサーバ側プロキシ３０について説明する。
【０２３７】
上記ではクライアント側プロキシ４０のキャッシュ機能について説明したが、サーバ側プロキシ３０も同様に実施可能である。
【０２３８】
この場合、クライアント側プロキシ４０に対するメッセージ転送元のクライアント５０とメッセージ転送先のサーバ側プロキシ３０が、サーバ側プロキシ３０に対してはそれぞれクライアント側プロキシ４０（転送元）とサーバ２０（転送先）になり、キャッシュに関係する構成・手順は同様である。
【０２３９】
図４５に、この場合のサーバ側プロキシ３０の構成例を示す。このサーバ側プロキシ３０は、図１９の構成・機能に加えて、更に過去にアクセスしたＵＲＬと、そのリプライデータのフィンガープリントとの対応を保持するＵＲＬ・フィンガープリント・テーブル（ＵＲＬ・ＦＰテーブル）３５と、ＵＲＬキャッシュ処理部３２７とを備えている。
【０２４０】
図４６に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。
【０２４１】
なお、この場合の処理手順は、図２１及び図２２の手順のステップＳ６および端子２およびＳ１３の後に追加される以外は、図２１及び図２２の手順と同じであり、図４６では、図２１及び図２２の手順のステップＳ６および端子２およびＳ１３より後の処理手順の部分を示してある。ここでは、図２１及び図２２で説明した手順と相違する部分を中心に説明する。
【０２４２】
サーバ側プロキシ３０は、送信部３３により、クライアント側プロキシ４０にリプライメッセージを送信（図２１及び図２２のステップＳ６、Ｓ９、Ｓ１１、またはＳ１３）した後、ＵＲＬキャッシュ処理部３２７にて、該リプライメッセージのリプライデータがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１４）。キャッシュ対象であると判断されたならば、ＵＲＬキャッシュ処理部３２７にて、ＵＲＬとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて（ＵＲＬをキーにして）をＵＲＬ・ＦＰテーブル３５に登録する（Ｓ１５）。キャッシュ対象でないと判断されたならば、何もしない。
【０２４３】
もちろん、前述と同様に、この手順も種々変形することが可能である。
【０２４４】
図４７に、クライアント側プロキシ４０から受信したリクエストメッセージをサーバ側プロキシ３０からサーバ２０へ転送する際のサーバ側プロキシ３０におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【０２４５】
サーバ側プロキシ３０は、受信部３１により、クライアント側プロキシ４０からリクエストメッセージを受信する（ステップＳ１６１）。
【０２４６】
ＵＲＬキャッシュ処理部３２７は、リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１６２）。なお、応答時のキャッシュ対象か否かの判断方法は、従来の応答時の手法と同様で構わない（例えば、受信リクエストメッセージがGETメソッドのものであるか否か）。
【０２４７】
リクエストデータがキャッシュ対象外のものと判断されたならば（Ｓ１６２）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。
【０２４８】
ステップＳ１６２にて該リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであると判断されたならば、ＵＲＬキャッシュ処理部３２７は、さらに、該リクエストメッセージに指定されているＵＲＬを取り出し（Ｓ１６３）、そのＵＲＬをキーとしてＵＲＬ・ＦＰテーブル３５を検索する（Ｓ１６４）。
【０２４９】
そのＵＲＬに対応するリプライデータのフィンガープリントがキャッシュされていなければ（Ｓ１６５）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。このとき、現在保持しているデータのタイムスタンプをリクエストメッセージのIf-Modified-Sinceヘッダに記入してサーバ２０へ転送し、サーバ２０から現在保持しているデータが有効であるとのリプライメッセージを受け取ると、ステップＳ１６７へ行くように実施することもできる。
【０２５０】
また、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されていても（Ｓ１６５）、併せて保持されている有効期間の判定のための情報に基づいてそのデータが無効になっていると判断されれば（Ｓ１６６）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。
【０２５１】
一方、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されており（Ｓ１６５）、かつ、併せて保持されている有効期間の判定のための情報に基づいてそのデータが有効であると判断されれば（Ｓ１６６）、ＵＲＬキャッシュ処理部３２７は、ＵＲＬ・ＦＰテーブル３５からリプライデータを構成するのに必要な情報を得るとともに、当該ＵＲＬに対応するリプライデータのフィンガープリントをキーとしてＦＰキャッシュ３４を検索する（Ｓ１６７）。
【０２５２】
ＦＰキャッシュ管理部３２２は、ＦＰキャッシュ３４から取得したデータから、該フィンガープリントの値を用いてリプライメッセージをＦＰ圧縮時のフォーマットで生成し、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ１６８）。
【０２５３】
このように、サーバ側プロキシにもＵＲＬ・ＦＰテーブル表を持ってキャッシュの処理をする構成は、一つのサーバ側プロキシが複数のクライアント側プロキシから使われているときに有効に働く。すなわち、あるクライアント側プロキシから要求のあったキャッシュ可能なデータが既に他のクライアント側プロキシによってアクセスされている場合には、サーバ側プロキシにもキャッシュされているので、そのデータを送り返すだけで処理が完了する。
【０２５４】
このように、サーバ側プロキシにもＵＲＬ・ＦＰテーブル表を持ってキャッシュの処理をする構成は、一つのサーバ側プロキシが複数のクライアント側プロキシから使われているときに有効に働く。すなわち、あるクライアント側プロキシから要求のあったキャッシュ可能なデータが既に他のクライアント側プロキシによってアクセスされている場合には、サーバ側プロキシにもキャッシュされているので、そのデータを送り返すだけで処理が完了する。
【０２５５】
なお、以上では、ＵＲＬ・ＦＰテーブル表をフィンガープリント・キャッシュとは別途に設ける場合について説明したが、ＵＲＬ・ＦＰテーブル表をフィンガープリント・キャッシュと一体化して構成することも可能である。
【０２５６】
なお、いずれのプロキシにおいても、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せて、フィンガープリント（ＦＰ）圧縮・解凍処理部としてもよい。また、いずれのプロキシにおいても、差分圧縮処理部と差分解凍処理部とを併せて、差分圧縮・解凍処理部としてもよい。図４８に、この場合のプロキシ（サーバ側プロキシ、クライアント側プロキシ）の構成例を示す。
【０２５７】
ＦＰ圧縮を該リクエストデータ転送のみに適用した場合、ＦＰ圧縮を該リプライデータ転送のみに適用した場合、ＦＰ圧縮を該リクエストデータ転送および該リプライデータ転送に適用した場合のいずれにおいても、リクエストメッセージが指定するＵＲＬに対応するリプライデータに対する共用キャッシュ機能に関する構成をクライアント側プロキシのみに設けることも、サーバ側プロキシのみに設けることも、両プロキシに設けることも可能である。
【０２５８】
なお、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することも、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０２５９】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０２６０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０２６１】
【発明の効果】
本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を保持しているデータについては、データ本体を転送する代わりに対応する名前を転送することで、データ転送装置間の転送データ量を削減させることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワーク・システムの構成例を示す図
【図２】同実施形態に係るネットワーク・システムの他の構成例を示す図
【図３】同実施形態に係るネットワーク・システムのさらに他の構成例を示す図
【図４】フィンガープリントについて説明するための図
【図５】同実施形態に係るフィンガープリント・キャッシュについて説明するための図
【図６】同実施形態で使用する差分圧縮の指示方法について説明するための図
【図７】同実施形態の差分圧縮の具体例について説明するための図
【図８】同実施形態の差分圧縮の具体例について説明するための図
【図９】同実施形態の差分圧縮の具体例について説明するための図
【図１０】同実施形態の差分圧縮の他の具体例について説明するための図
【図１１】同実施形態の差分圧縮の他の具体例について説明するための図
【図１２】同実施形態の差分圧縮の他の具体例について説明するための図
【図１３】同実施形態の差分圧縮の他の具体例について説明するための図
【図１４】同実施形態で使用するメッセージ・フォーマットの一例を示す図
【図１５】同実施形態で使用するメッセージ・フォーマットの他の例を示す図
【図１６】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１７】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１８】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１９】同実施形態に係るサーバ側プロキシの構成例を示す図
【図２０】同実施形態に係るクライアント側プロキシの構成例を示す図
【図２１】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２２】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２３】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２４】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２５】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２６】同実施形態の差分圧縮の処理手順の一例を示すフローチャート
【図２７】同実施形態の差分圧縮の処理手順の他の例を示すフローチャート
【図２８】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２９】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図３０】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３１】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３２】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３３】同実施形態にプロキシの他の構成例を示す図
【図３４】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図３５】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図３６】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３７】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３８】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３９】同実施形態に係るネットワーク・システムのさらに他の構成例を示す図
【図４０】同実施形態に係るクライアント側プロキシの他の構成例を示す図
【図４１】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４２】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４３】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４４】同実施形態に係るクライアントとクライアント側プロキシとの間のデータ転送について説明するための図
【図４５】同実施形態に係るサーバ側プロキシの他の構成例を示す図
【図４６】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図４７】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図４８】同実施形態に係るプロキシのさらに他の構成例を示す図
【図４９】従来のコンピュータ・ネットワーク・システムについて説明するための図
【符号の説明】
２…ＡＳＰサーバセンター
４…ユーザオフィス
１２…ＡＳＰサーバセンター内ＬＡＮ
１４…ＷＡＮ
１６…ユーザオフィス内ＬＡＮ
２０…サーバ装置
３０…サーバ側プロキシ装置
４０…クライアント側プロキシ装置
３１，４１…受信部
３２，４２…処理部
３３，４３…送信部
３４，４４…フィンガープリント・キャッシュ
３５，４５…ＵＲＬ・ＦＰテーブル
３２１，４２１…ＦＰ圧縮判定部
３２２，４２２…フィンガープリント・キャッシュ管理部
３２３…ＦＰ圧縮処理部
４２３…ＦＰ解凍処理部
３２４…差分圧縮処理部
４２４…差分解凍処理部
３２５，４２５…ＦＰ圧縮・解凍処理部
３２６，４２６…差分圧縮・解凍処理部
３２７，４２７…ＵＲＬキャッシュ処理部
５０…クライアント装置
【発明の属する技術分野】
本発明は、他の装置のためにデータ転送を行うデータ転送装置、データ転送方法及びプログラムに関する。
【０００２】
【従来の技術】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。特に、インターネット上でＨＴＴＰプロトコルを使って通信するＷｅｂサーバとクライアントとからなるWorld Wide Webシステム（あるいは単にＷｅｂとも呼ばれる）は、大変広く利用されているクライアント・サーバ型の情報システムである。通常、サーバ上ではサーバプログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（例えば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋等の予約サービス、種々の契約の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【０００３】
ところで、Ｗｅｂのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間で通信に用いるネットワークの容量（バンド幅）が、システム全体のボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【０００４】
Ｗｅｂシステムの場合、クライアント上で動作するブラウザ等はキャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。ＷｅｂではＵＲＬと呼ばれる名前で情報やサービスを指定してアクセスがなされるので、クライアント上のキャッシュは、過去にＷｅｂサーバに要求した情報やサービスの結果として返されるデータのうちでキャッシュ可能なものを、そのＵＲＬと対応させてキャッシュに記録している。この場合、キャッシュ内にあるものと同じＵＲＬの情報やサービスのリクエストがあった際に、そのキャッシュ内の応答データが古くなっていないと判断できるならば、そのデータを返すことで、Ｗｅｂサーバとの間の通信を無くすことができる。
【０００５】
企業のオフィス内のＬＡＮあるいは研究機関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数のユーザがいる場合、該ＬＡＮとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。クライアント内のキャッシュ（例えば、ブラウザのキャッシュ）は、当該クライアント・ユーザに専用のキャッシュとして動作するが、ＬＡＮ上のプロキシサーバのキャッシュは、複数のクライアント・ユーザに共有のキャッシュとして動作する。そのため、後者では、過去に他人（他クライアント）がアクセスしたＵＲＬに対してアクセスする際にもキャッシュが効く。
【０００６】
さて、Ｗｅｂにおいて、クライアントとサーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行われる。ＨＴＴＰプロトコルは、クライアントからサーバへ送る「リクエストメッセージ」と、それに答えてサーバからクライアントへ応答を返す「リプライメッセージ」とが組になっている。
【０００７】
リクエストメッセージは、「リクエストヘッダ」と「リクエストボディ」からなる。リクエストヘッダには、アクセスしたい情報やサービスを指定するＵＲＬやアクセスの種類を示すメソッド名、その他アクセスに必要な各種の情報が入る。リクエストボディには、サーバに送るデータを入れる。リクエストボディに入っているデータを「リクエストデータ」とも呼ぶ。
【０００８】
リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。リプライヘッダには、処理結果のステータスなどの情報が入り、リプライボディには要求された情報や要求されたサービスの処理結果などのデータが入る。リプライボディに入っているデータを「リプライデータ」とも呼ぶ。
【０００９】
リクエストメッセージのメソッドとしては、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユーザの持つデータをサーバに書き込む「ＰＵＴメソッド」、リクエストの応じて処理した結果を送り返してもらう「ＰＯＳＴメソッド」が、情報やサービスのアクセスに用いられる主要なものである。その他、ＤＥＬＥＴＥなどのメソッドが定義されている。
【００１０】
多くの場合、ＧＥＴメソッドのリクエストメッセージのリクエストボディ、ＰＵＴメソッドのリプライメッセージのリプライボディは空である。ＰＯＳＴメソッドのリクエストメッセージのリクエストボディには、必要に応じてサーバ側での処理に用いる情報が入り、ＰＯＳＴメソッドのリプライメッセージのリプライボディには、その処理の結果のデータが入る。
【００１１】
ＧＥＴメソッドでサーバから読み出すデータは、読み出す毎にサーバ側で生成する「動的データ」と、既にサーバ側で記憶しているデータをそのまま送り返す「静的データ」に分けることができる。これらのうち、動的データについては、同じＵＲＬでも読み出す度に内容が異なる可能性があるので、多くの場合、サーバはキャッシュ不可の指定をそのリプライメッセージのヘッダに入れて送り返す。したがって、Ｗｅｂのデータでキャッシュの対象になるのは、静的データの部分である。この静的データは、不特定多数のユーザが参照して構わない「共有データ」と、ユーザ認証することで特定のユーザだけがアクセスできるようにアクセス制御を行う「プライベートデータ」に分けることができる。前者の共有データは、どのようなキャッシュでもキャッシュ可能である。しかしながら、後者のプライベートデータは、プロキシサーバなどの共有キャッシュでは、キャッシュ不可である（プライベートデータは必ずサーバで認証して送り返す必要があるので）。ただし、ブラウザなどの個人専用のキャッシュの場合には、プライベートデータでもキャッシュは可能である。
【００１２】
ＰＯＳＴメソッドは、サーバ側で処理をした結果を返すので、一般的にサーバはキャッシュ不可の指定をリプライメッセージのヘッダに入れて結果を送り返す。そのため、通常はキャッシュの対象にはならない。
【００１３】
ＰＵＴメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない。
【００１４】
【発明が解決しようとする課題】
従来のＷｅｂのキャッシュは、静的コンテンツをキャッシュの対象にしている。かつては、Ｗｅｂで公開される情報やサービスには、情報の更新頻度がそれほど高くなく、不特定多数の人に公開されているものが多かったため、静的コンテンツの割合は非常に高く、従来のキャッシュ技術でもネットワークの負荷の軽減に有効であった。
【００１５】
しかしながら、ＷｅｂベースのＡＳＰ(Application Service Provider)のように、ユーザがＷｅｂブラウザを使って、ネットワーク経由でサーバ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来のキャッシュ技術では対応できないデータが増加している。
・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデータが多い。
・バックエンドのデータベースを参照して生成する動的データが多い。
・帳票処理や検索などＰＯＳＴメソッドを使う場合が多い。
・グループ内の情報共有のためにＰＵＴメソッドを使う場合が多い。
この結果、キャッシュ技術のみではネットワークの負荷を軽減する手法として有効に機能しなくなってきている。
【００１６】
本発明は、上記事情を考慮してなされたもので、データ転送装置間を接続するネットワークの負荷をより軽減することができるキャッシュ技術・圧縮技術を備えたデータ転送装置、データ転送方法及びプログラムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明は、サーバ装置と、該サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置との通信を中継するデータ転送装置において、サーバ装置から受信して他のデータ転送装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、前記サーバ装置がクライアント装置を宛先として送信した第２の完全データを受信する受信手段と、前記第１の完全データと前記第２の完全データとの差分である差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記差分データが差分データであることを示す第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とする。
また、本発明は、サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置と、前記クライアント装置との通信を中継するデータ転送装置において、他のデータ転送装置から受信してクライアント装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、前記クライアント装置が宛先とされた、前記第１の完全データと第２の完全データとの差分である差分データと、該差分データが差分データであることを示す第２の識別情報とを受信する受信手段と、前記第１の完全データと前記差分データとを用いて前記第２の完全データを生成し、該差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、該第２の完全データを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とする。
【００２３】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２４】
本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を保持しているデータについては、データ本体を転送する代わりに対応する名前を転送することで、データ転送装置間の転送データ量を削減させることができる。例えば、ＧＥＴメソッドのリプライメッセージがプライベートデータであっても、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。また、例えば、ＧＥＴメソッドのリプライメッセージが動的データであっても、内容が同じデータなら、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。また、例えば、ＰＯＳＴメソッドであっても、結果が同じデータなら、これをフィンガープリントにより圧縮してデータ転送装置間を転送することができるようになる。
【００２５】
また、本発明によれば、データに対応する名前が保持されていないために、データを転送する代わりに対応する名前を転送することができない場合であっても、保持されている参照データに対応する名前を利用して当該データを圧縮して表現した圧縮データを転送することによって、データ転送装置間の転送データ量を削減することができる。例えば、ＧＥＴメソッドやＰＯＳＴメソッドのリプライデータが以前にアクセスしたデータと一部が異なる場合には、差分転送することで、データ量を削減することができる。また、例えば、ＰＵＴメソッドやＰＯＳＴメソッドのリクエストデータが以前に送ったデータと一部が異なる場合には、差分転送することでデータ量を削減することができる。
【００２６】
また、本発明によれば、データ圧縮が可能な場合には、データの代わりに圧縮データを保存することにより、記憶装置（メモリやハードディスクなど）を有効利用できる。
【００２７】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２８】
以下では、ＷＡＮがインターネットであり、クライアントはユーザオフィスＬＡＮに接続されたものであり、ＨＴＴＰプロトコルが使用されるような場合を例にとって説明するが、本発明は、ＷＡＮがインターネット以外のものでも、クライアントがオフィス以外の例えば家庭内ＬＡＮ等に設置されたものでも、ＨＴＴＰ以外のプロトコルが使用されるものでも適用可能である。
【００２９】
図４９に本発明を適用するコンピュータ・ネットワーク・システムの基本的な構成例を示す。この構成例では、ＡＳＰサーバセンター２内のローカルエリアネットワーク（ＬＡＮ）１２とユーザオフィス４内のローカルエリアネットワーク（ＬＡＮ）１６との間が、インターネットや専用回線などの広域ネットワーク（ＷＡＮ）１４を介して接続されており、サーバ２０とクライアント５０とがＬＡＮ１２・ＷＡＮ１４・ＬＡＮ１６を介して通信可能になっている。ＬＡＮ１２には１または複数のサーバが接続され、ＬＡＮ１６には１または複数のクライアントが接続される。
【００３０】
ＷｅｂベースのＡＳＰは、センター２に設置したサーバ２０からＷＡＮ１４を介して様々なアプリケーションプログラムによるサービスを提供し、ユーザはオフィス４に設置されたクライアント上のＷｅｂブラウザ等を使ってそれらのサービスにアクセスする。このような利用形態においては、オフィス内ＬＡＮ１６とセンター内ＬＡＮ１２とをつなぐネットワーク、特にインターネットなどのＷＡＮ１４の実効的な通信容量（バンド幅）は、ＬＡＮ１２やＬＡＮ１６よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。そこで、本実施形態では、例えば図１に示すように、センター内ＬＡＮ１２とオフィス内ＬＡＮ１６をつなぐＷＡＮ１４の両端に、サーバ側プロキシ３０及びクライアント側プロキシ４０なる２つのモジュールを設置し、サーバ２０とクライアント５０がＬＡＮ１２・プロキシ３０・ＷＡＮ１４・プロキシ４０・ＬＡＮ１６を介して通信するにあたって、それらプロキシ間で後述するフィンガープリント圧縮（ＦＰ圧縮）や差分圧縮を行って通信データ量を低減することで、広域ネットワークのボトルネックを解消する。さらに、それらプロキシでは、詳しくは後述するように、圧縮に必要なデータの一部を差分情報によって保持することで、必要なキャッシュ量を削減する。
【００３１】
本実施形態のサーバ２０、サーバ側プロキシ３０、クライアント側プロキシ４０、クライアント５０は、いずれも、計算機上でソフトウェア（サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム）を動作させる形で実現することができる。この場合に、所望の機能を有する、ＯＳやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが、必要に応じて計算機に搭載あるいは接続される。また、この場合に、ユーザあるいは管理者などからの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いると好ましい。
【００３２】
サービスを利用するためにユーザが使用するクライアント５０上では、その目的に応じて例えばＷｅｂブラウザ等のプログラムが動作する。ユーザは、例えば、Ｗｅｂブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。なお、Ｗｅｂブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【００３３】
サーバ２０上では、所定のサーバ・プログラムが動作し、クライアント５０のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【００３４】
サーバ側プロキシ３０は、図１のように、サーバセンター内ＬＡＮ１２とＷＡＮ１４の両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施してもよい。また、図２のようにサーバセンター内ＬＡＮ１２上に設置して実施してもよい。また、図３のようにサーバ側プロキシ３０の機能をサーバ２０に内蔵するように実施してもよい。
【００３５】
同様にクライアント側プロキシ４０は、図１のように、ユーザオフィス内ＬＡＮ１６とＷＡＮ１４の両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施してもよい。また、図２のようにユーザオフィス内ＬＡＮ１６上に設置して実施してもよい。また、図３のようにクライアント側プロキシ４０の機能をクライアント５０上で動作するブラウザ等に内蔵するように実施してもよい。あるいは、ブラウザ等の動作するクライアント５０上に、個人用のクライアント側プロキシ４０を動作させるように実施してもよい。
【００３６】
なお、サーバ側プロキシ３０とクライアント側プロキシ４０とは、図１〜図３などのように同じ形態であってもよいし、異なる形態であってもよい。
【００３７】
以下では、フィンガープリント・キャッシュ、これを利用したＦＰ圧縮及び差分圧縮、データ管理について、それらの概要を説明する。
【００３８】
なお、以下、サーバ側プロキシ３０とクライアント側プロキシ４０との間のデータ転送方向としていずれか一方向を例にとって説明する際には、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する場合を例にとって説明していくが、クライアント側プロキシ４０からサーバ側プロキシ３０へデータを転送する場合にも同様のことが可能である。
【００３９】
本実施形態のサーバ側プロキシ３０とクライアント側プロキシ４０は、フィンガープリント・キャッシュと呼ぶキャッシュ機構を持つ。フィンガープリント・キャッシュは、フィンガープリント（ＦＰ）と呼ぶ名前によって、ＨＴＴＰプロトコルでやりとりされるデータを記録・管理する。
【００４０】
フィンガープリントは、図４に例示するように、ＨＴＴＰプロトコルでやり取りされるデータ（図４ではコンテンツ）の内容から、あらかじめ決められた計算方法（図４ではハッシュ関数）で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【００４１】
フィンガープリントを計算する方法としては、良く知られているＭＤ−５やＳＨＡ−１などのハッシュ関数を用いることができる。これらのハッシュ関数は、データに対する電子署名などに使われており、任意のデータが与えられると、ＭＤ−５の場合は１２８ビットの数値に、ＳＨＡ−１の場合は１６０ビットの数値に、変換することができる。これらのハッシュ関数の特徴は、２つのデータＸ１、Ｘ２が与えられ、データＸ１とデータＸ２とが同じであれば、データＸ１に対して計算したハッシュ値とデータＸ２に対して計算したハッシュ値とは等しくなるが、異なる２つのデータＡ、Ｂが与えられた場合には、データＡに対して計算したハッシュ値とデータＢに対して計算したハッシュ値とは、非常に高い確率で異なるものになることである（原理上は、異なる２つのデータＡ、Ｂに対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい）。
【００４２】
図５に示すように、サーバ側プロキシ３０やクライアント側プロキシ４０の持つフィンガープリント・キャッシュ（２６０）は、過去にＨＴＴＰプロトコルでやり取りされたデータ本体（２６１）または後述する差分圧縮により生成されたデータ（２６４）を、そのやりとりされたデータから計算して求めたフィンガープリントの値（２６２）を名前として、記録されているデータがデータ本体かそれとも差分圧縮により生成されたデータかを示す差分圧縮データ識別子（以下、圧縮識別子と記述する）（２６３）とともに記録・管理する。なお、以下では、該識別子＝０が“記録されているデータはデータ本体である”ことを示し、該識別子＝１が“記録されているデータが差分圧縮により生成されたデータである”ことを示すものとした例で説明するが、これに限定されるものではない。
【００４３】
例えば、ＨＴＴＰプロトコルでサーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する場合に、サーバ側プロキシ３０は、当該データのフィンガープリントを計算し、そのフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていてかつ圧縮識別子が０であれば、キャッシュに存在するデータは差分圧縮により生成されたデータではないが、当該データ（と同じ内容のデータ）は過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出すことで、転送すべきデータを再現することができる。
【００４４】
また例えば、上記の場合に、サーバ側プロキシ３０は、計算したフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていてかつ圧縮識別子が１であれば、キャッシュに存在するデータは差分圧縮により生成されたデータであり、当該受信データ（と同じ内容のデータ）に対して過去に差分圧縮が成功し、差分情報を転送したことがあることがわかり、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出して差分圧縮されているデータを解凍することで、転送すべきデータを再現することができる。
【００４５】
このような方式（すなわち、フィンガープリントによるデータの圧縮→フィンガープリントの転送→フィンガープリントによるデータの解凍）により、過去に送ったものと同じデータ（データ本体あるいは差分圧縮により生成されたデータ）ならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。
【００４６】
なお、上記の場合に、計算したフィンガープリントに対応するデータがフィンガープリント・キャッシュに入っていないものについては、今回は、後述する差分圧縮により生成されたデータまたはデータ本体を転送するとともに、フィンガープリント・キャッシュへの登録を行うことによって、次回からは、ＦＰ圧縮によるフィンガープリントの転送ができるようになる。
【００４７】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮（ＦＰ圧縮）と呼ぶものとする。
【００４８】
続いて、差分圧縮について説明する。
【００４９】
上記のＦＰ圧縮では、データに対するフィンガープリントを用いてデータの同一性を高速に判断し、フィンガープリント・キャッシュに登録されているデータと同じデータはプロキシ間で転送せず、代わりに当該データに対するフィンガープリントを転送するようにして、ネットワークの負荷を低減させる。しかし、フィンガープリント・キャッシュに登録されているデータと異なるデータは、たとえ大部分は同じ内容であってもＦＰ圧縮を適用できない。そこで、本実施形態では、ＦＰ圧縮できない場合であっても、フィンガープリント・キャッシュに登録されている１または複数のデータを参照データとして、参照データのフィンガープリントや、参照データに対する差分情報など転送すべきデータを復元するための情報によって、転送データを表現することによって、少ない情報量で転送データを表現し、なるべく転送データ量を減らすようにしている。すなわち、フィンガープリント・キャッシュの中のデータを辞書として使って、その中から取り出せるデータは送らないようにする。
【００５０】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータを参照データのフィンガープリント等に置き換えて転送情報量を圧縮することを、差分圧縮と呼ぶものとする。また、この差分圧縮により生成された転送データを、差分圧縮データと呼ぶものとする。
【００５１】
なお、このようなフィンガープリントを利用した差分圧縮は、転送すべきデータと参照データとの間の関係を予め取り決めておく必要がないという利点も得られる。すなわち、従来の差分転送では、予め双方で何をベースに差分を取るかを決める必要があるため、差分転送をＷｅｂシステムに実際に用いようとすると、このＵＲＬのデータはこのデータをベースに差分を取るというようなルールを、双方に登録する手段が必要であり、任意のデータに対して有効に機能させることは不可能であった。これに対して、本差分圧縮方法は、フィンガープリント・キャッシュの中にあるデータを参照データとして差分を取ることで、差分のベースを予め決めておかなくても、差分によるデータの圧縮の効果を得ることができる。
【００５２】
次に、本実施形態のデータ管理方法について説明する。
【００５３】
本実施形態では、サーバ側プロキシ３０においてサーバ２０から受信したリプライデータに対して差分圧縮が成功した場合、サーバ側プロキシ３０は差分圧縮により生成された差分圧縮データをクライアント側プロキシ４０に送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該差分圧縮データとを記録・管理する。この際、記録・管理されているデータが差分圧縮データであることを示すために、圧縮識別子を１にセットする。
【００５４】
クライアント側プロキシ４０においては、サーバ側プロキシ３０から受信したリプライデータが差分圧縮データであった場合には、差分圧縮データからサーバ側プロキシ３０が受信したリプライデータを生成しクライアント５０に送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、差分圧縮データから生成された該リプライデータに対するフィンガープリントと、サーバ側プロキシ３０から受信した差分圧縮データとを記録・管理する。この際、記録・管理されているデータが差分圧縮データであることを示すために、圧縮識別子を１にセットする。
【００５５】
一方、サーバ側プロキシ３０においてサーバ２０から受信したリプライデータが初めてのデータであり、ＦＰ圧縮及び差分圧縮の両方とも失敗した場合には、サーバ側プロキシ３０はクライアント側プロキシ４０に対して該リプライデータを送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該リプライデータとを記録・管理する。この際、記録・管理されているデータが差分圧縮データではないことを示すため、圧縮識別子を０にセットする。
【００５６】
クライアント側プロキシ４０においては、サーバ側プロキシ３０から受信したリプライデータがＦＰ圧縮及び差分圧縮のどちらも施されていないデータであることを検知した場合には、該リプライデータをクライアント５０へ送信するとともに、自分自身のフィンガープリント・キャッシュ２６０には、該リプライデータから取得したフィンガープリントと該リプライデータとを記録・管理する。この際、記録・管理されているデータが差分圧縮データではないことを示すため、圧縮識別子を０にセットする。
【００５７】
これにより、差分圧縮が成功したデータについては、サーバ側プロキシ３０及びクライアント側プロキシ４０双方のフィンガープリント・キャッシュ２６０において、差分圧縮データのみが保存されることになる。
【００５８】
ところで、ＷｅｂベースのＡＳＰのような応用では、大部分は同じ内容であるが一部分だけが異なっているようなデータが多く使われる。例えば、帳票のデータなどは、多くのフィールドに同じ情報が記入されていて、一部分だけが違うようなものが多数存在する。また、例えば、Ｗｅｂページで日付もしくは時刻のみ異なるものや、総アクセス回数のカウンタ値のみ異なるものなどもある。このような場合には、差分圧縮データによる転送や保存は特に有効で、データ本体による転送や保存を効果的に少なくすることができる。
【００５９】
なお、両プロキシ３０，４０間において、全メッセージをＦＰ圧縮の適用対象としてもよいが、例えば、予め定められた条件を満たすメッセージについては、これをＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで転送する）ようにしてもよい。予め定められた条件は、例えば、メッセージ・ヘッダに予め定められた情報（例えばＧＥＴメソッドを示す情報およびリクエストを示す情報）が記述されていること、転送されるデータが空（ｎｕｌｌ）あるいは非常に短いサイズであることなど、種々のバリエーションが考えられる。
【００６０】
また、ＦＰ圧縮の適用対象のメッセージをすべて差分圧縮の適用対象としてもよいが、ＦＰ圧縮の適用対象のメッセージのうち予め定められた条件を満たすメッセージについては、これを差分圧縮の適用対象外とするようにしてもよい（この場合、差分圧縮を適用される条件が、ＦＰ圧縮を適用される条件に対して更に他の条件を加重したものになる）。例えば、ＦＰ圧縮しないデータサイズの上限値Ｕ１よりも、差分圧縮しないデータサイズの上限値Ｕ２を大きくする（ＦＰ圧縮すべきデータサイズの下限値Ｌ１よりも、差分圧縮すべきデータサイズの下限Ｌ２を大きくする）という方法や、ＦＰ圧縮の適用対象か否かはデータサイズで判断するが、差分圧縮の適用対象か否かについては、ＦＰ圧縮の適用対象のうちＨＴＭＬやＸＭＬ以外のデータを適用対象外とする（ＨＴＭＬやＸＭＬのデータに対してのみ差分圧縮を行う）という方法等、種々のバリエーションが考えられる。なお、以下では、ＦＰ圧縮の適用対象のメッセージをすべて差分圧縮の適用対象とする場合を例にとって説明する。
【００６１】
本実施形態では、ＦＰ圧縮対象且つ差分圧縮対象のメッセージは、データがＦＰ圧縮されたメッセージ（ただし、圧縮識別子が０になるものと１になるものとがある）、データが差分圧縮されたメッセージ、またはデータが圧縮されていないメッセージのいずれかとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６２】
また、ＦＰ圧縮対象であり且つ差分圧縮対象でないメッセージがある場合、該メッセージは、データがＦＰ圧縮されたメッセージ（圧縮識別子＝０になる）、またはデータが圧縮されていないメッセージのいずれかとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６３】
また、ＦＰ圧縮対象でないメッセージがある場合には、該メッセージは、データが圧縮されていないメッセージとして、サーバ側プロキシ３０とクライアント側プロキシ４０との間を転送されることになる。
【００６４】
ここで、差分圧縮の方法について説明する。
【００６５】
フィンガープリント・キャッシュを利用した差分圧縮の方法には次に例示するものなど種々の方法がある。
・フィンガープリント・キャッシュに登録されているデータのうちの１つを参照データとする。プロキシ間では、参照データに対応するフィンガープリントの値と、転送データと参照データとの差分を示す情報とを転送する。
・上記の方法において、参照データとの差分の全部または一部についても、フィンガープリント・キャッシュに登録されているデータを利用する。あるいは、フィンガープリント・キャッシュに登録されているデータ（の全体または部分）を組み合わせることによって転送データの全部または一部を表現する。例えば、フィンガープリント・キャッシュに登録されているデータのうち任意数のものを参照データとする。プロキシ間では、参照データに対応するフィンガープリントの値と、参照データのうち転送データの復元に使用する部分を示す情報と、その部分をもとにした転送データの復元方法を示す情報とを転送する。
【００６６】
以下では、差分圧縮データの表現方法の一例を示す。
【００６７】
図６に、転送すべきデータを表現するための３種類の指示を示す。データの代わりに転送される差分圧縮データは、これら指示の並びで構成する。
【００６８】
（ａ）は、フィンガープリント・キャッシュ内のデータを参照するときに、参照データに番号を付けて定義する指示である。１バイト目の８ｎ（図６の例では、ｎ＝０）は指示識別子である。この指示識別子のうちｎは、そのフィンガープリントで指定されるデータをｎ番の参照データとして扱うことを示す。２バイト目から始まる１６バイトが当該参照データに対するフィンガープリントの値を示す。この例では、８０〜８Ｆによってそれぞれ０番の参照データから、最大１５番までの参照データが扱えるようになっている。扱える参照データの最大数は、実装によって多くも少なくもできる。
【００６９】
（ｂ）は、（ａ）で定義された参照データの中から部分データをコピーする指示を表す。１バイト目の９ｎ（図６の例では、ｎ＝０）は指示識別子である。この指示識別子のうちｎは、（ａ）の指示で定義されたｎ番の参照データを使用することを示す。２バイト目からの４バイトは、そのｎ番の参照データ中のオフセット位置を、６バイト目からの４バイトでデータの長さをそれぞれ指示する。そして、それらによって、ｎ番の参照データの中の指定オフセット位置から指定長さのデータを、この指示の並びの位置（順番）に従って（転送データの構成部分として）コピーすべきことを示す。
【００７０】
（ｃ）は、データを直接指定するための指示である。１バイト目のＡ０は、指示識別子である。２バイト目からの４バイトは、データの長さを示す。６バイト目以降に、その長さで指定されたバイト数のデータが続く。そして、それらによって、６バイト目以降のデータを、この指示の並びの位置（順番）に従って（転送データの構成部分として）コピーすることを示す。
【００７１】
このような指示の並びで構成された差分圧縮データは、フィンガープリント・キャッシュを参照しながら、指示された順にデータをコピーして接続していくだけで解凍することができる。
【００７２】
次に、上記の方法に従った差分圧縮の例を示す。
【００７３】
図７に示すようなデータがフィンガープリント５Ｅ８３…Ｂ６としてフィンガープリント・キャッシュに入っていたとする。
【００７４】
このとき、図８のようなデータが与えられると、図７のデータを参照データとして、図９のように差分圧縮することができる。
【００７５】
すなわち、図８のデータは、図７のデータと比較すると、図７のデータの『ＴＯＫＹＯ』が『ＯＳＡＫＡ』に変わっているだけである。そこで、図９のように、まず、０バイト目でフィンガープリント“５Ｅ８３…Ｂ６”のデータを０番参照データとして定義することを指示し、１７バイト目で０番参照データの０バイト目から６０バイトをコピーすることを指示し、次に２６バイト目で『ＯＳＡＫＡ』の５文字をコピーすることを指示し、最後に３６バイト目で０番参照データの６５バイト目から５１バイトをコピーすることを指示している。
【００７６】
この指示の通りに解凍すれば、図８のデータを再現することができる。
【００７７】
この例では、参照データを１つだけ用いたが、複数個使うことも可能である。
【００７８】
次に、上記の方法に従った差分圧縮の他の例を示す。
【００７９】
図１０に示すようなデータがフィンガープリント８２Ｆ３…３８としてフィンガープリント・キャッシュに入っており、図１１に示すようなデータがフィンガープリントＡ２０Ｄ…ＣＢとしてフィンガープリント・キャッシュに入っていたとする。このとき、図１２のようなデータが与えられると、図１０のデータと図１１のデータを参照データとして、図１３のように差分圧縮することができる。
【００８０】
図１３では、まず、０バイト目でフィンガープリント“８２Ｆ３…３８”のデータを０番参照データとして定義することを指示し、１７バイト目で０番参照データの０バイト目から５３バイトをコピーすることを指示し、２６バイト目でフィンガープリント“Ａ２０Ｄ…ＣＢ”のデータを１番参照データとして定義することを指示し、４３バイト目で１番参照データの９６バイト目から５５バイトをコピーすることを指示している。
【００８１】
この指示の通りに解凍すれば、図１２のデータを再現することができる。
【００８２】
なお、上記した方法では、参照データの使用すべき部分の指示と、使用すべきデータの直接指定を行う方法（方法１）であったが、その代わりに、参照データのうち使用しない部分（直接指示データで置き換える部分）の指示と、その使用しない部分に嵌め込むデータの直接指定を行う方法（方法２）も可能である。
【００８３】
また、方法１と方法２を併用することも可能である。
【００８４】
次に、図１４〜図１８を参照しながら、サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する際の（ＦＰ圧縮の適用対象のメッセージについての）プロキシ間メッセージ・フォーマットについて説明する。
【００８５】
サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する場合、ＦＰ圧縮の適用対象のメッセージには、データがＦＰ圧縮されてフィンガープリントに置き換えられたメッセージ（ＦＰ圧縮時のメッセージ）と、ＦＰ圧縮されないが、差分圧縮されたデータが搭載されているメッセージ（差分圧縮時のメッセージ）と、ＦＰ圧縮も差分圧縮もされていないデータが搭載されているメッセージ（非圧縮時のメッセージ）とがある。すべてのメッセージをＦＰ圧縮の適用対象とするのではない構成の場合には、これら３つのメッセージに加えて、ＦＰ圧縮の適用対象外のメッセージがある。
【００８６】
両プロキシのうち送信側プロキシにおいて、ＦＰ圧縮時のメッセージでは、データが削除され、フィンガープリントが付加され、差分圧縮時のメッセージでは、データが削除され、参照データのフィンガープリントなど当該データを復元するための情報が付加される。非圧縮時のメッセージおよび圧縮適用対象外のメッセージでは、データは削除されない。
【００８７】
両プロキシのうち受信側プロキシにおいては、上記の３種もしくは４種のメッセージを識別できる必要がある。ＦＰ圧縮時のメッセージ受信時は、フィンガープリントをデータに戻し（ただし、圧縮識別子が０である場合には、データ本体が保持されているが、圧縮識別子が１である場合には、差分圧縮により生成されたデータが保持されているので、これをもとにデータを復元する）、差分圧縮時のメッセージ受信時は、データを復元する。また、差分圧縮時または非圧縮時のメッセージ受信時は、フィンガープリント・キャッシュの登録を行う。
【００８８】
図１４に、メッセージ・フォーマットの一例を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）は差分圧縮時のメッセージであり、（ｃ）はＦＰ圧縮時のメッセージである。
【００８９】
（ａ）ではメッセージ・ボディーにデータが載せられ、（ｂ）ではメッセージ・ボディーにデータの代わりに当該データを復元するための情報が載せられ、（ｃ）ではメッセージ・ボディーにデータの代わりにフィンガープリント（ＦＰ）が載せられる。
【００９０】
また、この例では、メッセージ・ヘッダに、メッセージの種類を識別可能とする識別情報が（圧縮側のプロキシにおいて）記述され、この識別情報に基づいて（解凍側のプロキシにおいて）ＦＰ圧縮の有無を識別する（例えば、０１ならば非圧縮なし、１０ならば差分圧縮、１１ならばＦＰ圧縮）。なお、識別情報は、プロキシ間で使用される特別のものであってもよいし、もともと通常のＨＴＴＰメッセージ・ヘッダに存在するフィールドを利用あるいは併用したものであってもよい。
【００９１】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合には、圧縮側（送信側）のプロキシにおいて、図１４（ｄ）に示すように、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダに上記の識別情報（例えば、００とする）を含めればよい。
【００９２】
また、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合に、解凍側（受信側）プロキシにおいて、メッセージ・ヘッダに含まれる何らかの情報によって当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断できるとき、あるいはメッセージ・ボディーが空（ｎｕｌｌ）のときに当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断するようにしたときなどには、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダには識別情報を含めないようにすることも可能である。
【００９３】
なお、非圧縮時や差分圧縮時には、図１４（ａ），（ｂ）の例では、メッセージに当該データに対するフィンガープリントを含ませなかったが、メッセージ・ヘッダにフィンガープリントを含ませるようにしてもよい（あるいは、メッセージ・ボディーに当該データに対するフィンガープリントを含ませるようにしてもよい）。図１５（ａ）〜（ｃ）は、非圧縮時や差分圧縮時には、メッセージ・ヘッダにフィンガープリントを含ませ、ＦＰ圧縮時には、メッセージ・ボディーにフィンガープリントを含ませる場合の一例である。このようにすれば、解凍側で当該データについてフィンガープリント・キャッシュの登録を行う際に、該フィンガープリントを利用することによって、あらためて当該データからフィンガープリントを求める手間が省ける。
【００９４】
なお、以上のいずれの場合においても、図１６に示すように、ＦＰ圧縮時のメッセージでは、メッセージ・ヘッダにフィンガープリント（ＦＰ）を含め、メッセージ・ボディーを空（ｎｕｌｌ）にしてもよい。
【００９５】
なお、以上の他にも、種々のメッセージ・フォーマットが可能である。
【００９６】
例えば、図１７では、（ａ）の非圧縮時のメッセージのヘッダに非圧縮フラグを記述し且つフィンガープリントは記述せず、（ｂ）の差分圧縮時のメッセージのヘッダに差分圧縮フラグを記述し且つフィンガープリントは記述せず、（ｃ）のＦＰ圧縮時のメッセージのヘッダにフィンガープリントは記述し且つボディーは空（ｎｕｌｌ）にする。
【００９７】
この場合には、メッセージ・ボディーが空（ｎｕｌｌ）であることあるいはメッセージのヘッダにフィンガープリントが記述されていることを検出するによって、当該メッセージがＦＰ圧縮時のメッセージであることを識別することができる。また、非圧縮時のメッセージや差分圧縮時のメッセージは、ヘッダに非圧縮フラグや差分圧縮フラグが記述されていることを検出することによって、識別することができる。
【００９８】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合には、圧縮側（送信側）のプロキシにおいて、図１８の（ａ），（ｂ）に示すように（（ａ）はデータが空（ｎｕｌｌ）でない場合、（ｂ）はデータが空（ｎｕｌｌ）である場合）、ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダに対象外フラグを含めればよい。
【００９９】
また、ＦＰ圧縮の適用対象外のメッセージが存在し得る構成の場合に、解凍側（受信側）プロキシにおいて、メッセージ・ヘッダに含まれる何らかの情報によって当該メッセージがＦＰ圧縮の適用対象外のメッセージであることを判断できるときなどには、図１８の（ｃ），（ｄ）に示すように（（ｃ）はデータが空（ｎｕｌｌ）でない場合、（ｄ）はデータが空（ｎｕｌｌ）である場合）ＦＰ圧縮の適用対象外のメッセージのメッセージ・ヘッダには対象外フラグを含めないようにすることも可能である。
【０１００】
以下では、まずサーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送するときにそのリプライデータをＦＰ圧縮・解凍する場合を中心に本実施形態について詳しく説明する。
【０１０１】
図１９に本実施形態におけるサーバ側プロキシ３０の構成例を示し、図２０に本実施形態におけるクライアント側プロキシ４０の構成例を示す。なお、図１９や図２０は、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する際の構成を中心に示してある。
【０１０２】
図１９のサーバ側プロキシ３０は、サーバセンター内ＬＡＮ１２または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部３１、転送メッセージに含まれるデータに対してＦＰ圧縮、差分圧縮を施すための処理部３２、サーバセンター内ＬＡＮ１２または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部３３、フィンガープリントとそのもととなったデータまたは差分圧縮データとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰキャッシュ）３４を備えている。また、処理部３２は、転送メッセージに含まれるデータを圧縮対象とすべきか否かを判定するためのフィンガープリント圧縮判定部（ＦＰ圧縮判定部）３２１、ＦＰキャッシュ３４に対する検索や登録などを行うためのフィンガープリント・キャッシュ管理部（ＦＰキャッシュ管理部）３２２、転送メッセージに含まれるデータを対応するフィンガープリントで置き換えるなどの処理を行うためのフィンガープリント圧縮処理部（ＦＰ圧縮処理部）３２３、転送メッセージに含まれるデータを差分圧縮データで置き換えるなどの処理を行うための差分圧縮処理部３２４を含む。
【０１０３】
図２０のクライアント側プロキシ４０は、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部４１、転送メッセージに含まれるデータに対してＦＰ解凍を施すための処理部４２、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部４３、フィンガープリントとそのもととなったデータまたは差分圧縮データとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰキャッシュ）４４を備えている。また、処理部４２は、転送メッセージに含まれるデータを圧縮対象とすべきか否か並びに転送メッセージに対するＦＰ圧縮および差分圧縮の有無を判定するためのフィンガープリント圧縮判定部（ＦＰ圧縮判定部）４２１、ＦＰキャッシュ４４に対する検索や登録などを行うためのフィンガープリント・キャッシュ管理部（ＦＰキャッシュ管理部）４２２、ＦＰ圧縮された転送メッセージに含まれるフィンガープリントから元のデータを解凍するなどの処理を行うためのフィンガープリント解凍処理部（ＦＰ解凍処理部）４２３、差分圧縮された転送メッセージに含まれる差分圧縮データから元のデータを解凍するなどの処理を行うための差分解凍処理部４２４を含む。
【０１０４】
なお、圧縮側のＦＰ圧縮判定部３２１と解凍側のＦＰ圧縮判定部４２１は、前述したようにメッセージが予め定められた条件を満たすか否かを調べることによって、そのメッセージに含まれるデータをＦＰ圧縮の適用対象とするか否かを判断する（全メッセージをＦＰ圧縮の適用対象にする場合には、圧縮側のＦＰ圧縮判定部３２１及び後に示す手順例の該当部分並びに解凍側のＦＰ圧縮判定部４２１の該当判断の部分及び後に示す手順例の該当部分は不要である）。また、解凍側のＦＰ圧縮判定部４２１は、ＦＰ圧縮の適用対象のメッセージについて、そのデータがＦＰ圧縮されたものか否かを判定する。以下では、ＦＰ圧縮の適用対象となるメッセージを転送する場合（ＦＰ圧縮の適用対象とすると判断された場合、または全メッセージをＦＰ圧縮の適用対象にする場合）を中心に説明する。
【０１０５】
図２１及び図２２に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。なお、図２１及び図２２は、１つのリプライメッセージを受けたときの処理を記述しているが、実際はサーバ側プロキシ３０が受け取ったリプライメッセージ全てに対して、図２１及び図２２に例示する処理を行う。
【０１０６】
サーバ側プロキシ３０は、受信部３１により、サーバ２０からリプライメッセージを受信する（ステップＳ１）。
【０１０７】
ＦＰ圧縮判定部３２１は、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（Ｓ２）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（Ｓ２）、受信したリプライメッセージを送信部３３からクライアント側プロキシ４０へ転送する（Ｓ１３）。
【０１０８】
ステップＳ２にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰキャッシュ管理部３２２にて、該リプライデータのフィンガープリントの値を計算し（Ｓ３）、該フィンガープリントの値をキーとしてＦＰキャッシュ３４を検索する（Ｓ４）。
【０１０９】
そして、該フィンガープリントの値とこれに対応するデータ（データ本体または差分圧縮データ）との組がＦＰキャッシュ３４に登録されていたならば（Ｓ５）、ＦＰ圧縮処理部３２３にて、受信したリプライメッセージを、該フィンガープリントの値を用いてＦＰ圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ６）。
【０１１０】
一方、ステップＳ４の検索の結果、該フィンガープリントの値とこれに対応するデータとの組がＦＰキャッシュ３４に登録されていなかったならば（Ｓ５）、差分圧縮処理部３２４にて、差分圧縮を行い（Ｓ７）、差分圧縮に成功したか否か判定する（Ｓ８）。
【０１１１】
差分圧縮に成功したか否かは、例えば、差分圧縮の対象とした元のデータのデータ量ｒ０と、差分圧縮データのデータ量ｒ１とを比較し、ｒ０−ｒ１＞ｄを満たすならば、成功したと判断する。ここで、定数ｄは、予め定められた０以上の整数である。
【０１１２】
ステップＳ８で差分圧縮に成功したと判断された場合、次の２つの作業を行う(1-1と1-2のいずれを先に行ってもよいし、並行して行ってもよい)。
（１−１）差分圧縮処理部３２４にて、受信したリプライメッセージを、（必要に応じて該フィンガープリントの値を用いて）差分圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ９）。
（１−２）ＦＰキャッシュ管理部３２２にて、該フィンガープリントの値と、ステップＳ７において生成された差分圧縮データとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ３４に登録する（Ｓ１０）。この際、登録するデータは差分圧縮データであるので、圧縮識別子を１にセットする。
【０１１３】
なお、上記（１−２）においては全ての差分圧縮データをＦＰキャッシュに登録するものとしたが、（ｉ）差分圧縮データのサイズと該差分圧縮データの元になったデータのサイズがほとんど変わらない場合は差分圧縮データではなく該差分圧縮データの元になったデータを保存する、（ｉｉ）差分圧縮データのサイズが該差分圧縮データの元になったデータのサイズに比べて非常に小さい場合は差分圧縮データは保存せず、該差分圧縮データの元になったデータも保存せず差分圧縮データ作成時に参照データとして用いたデータのＦＰキャッシュにおける登録を維持する、などの方法も可能である。その他にも種々のバリエーションがある。また、この点は、後で説明する他の処理手順例において差分圧縮データをＦＰキャッシュに登録する場合についても同様である（なお、後の説明でも、全ての差分圧縮データをＦＰキャッシュに登録するものとした場合を例にとって説明している）。
【０１１４】
一方、ステップＳ８で差分圧縮に失敗したと判断された場合、次の２つの作業を行う(2-1と2-2のいずれを先に行ってもよいし、並行して行ってもよい)。
(2-1)差分圧縮処理部３２４（あるいはＦＰ圧縮処理部３２３）にて、受信したリプライメッセージを、非圧縮時のフォーマットにして、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ１１）。
(2-2)ＦＰキャッシュ管理部３２２にて、該フィンガープリントの値と、該リプライメッセージとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ３４に登録する（Ｓ１２）。この際、登録するデータは差分圧縮データではないので、圧縮識別子を０にセットする。
【０１１５】
次に、図２３〜図２５に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のクライアント側プロキシ４０の処理手順の一例を示す。なお、図２３〜図２５は、１つのリクエストメッセージを受けたときの処理を記述しているが、実際はクライアント側プロキシ４０が受け取ったリクエストメッセージ全てに対して、図２３〜図２５に例示する処理を行う。
【０１１６】
クライアント側プロキシ４０は、受信部４１により、サーバ側プロキシ３０からリプライメッセージを受信する（ステップＳ２１）。
【０１１７】
ＦＰ圧縮判定部４２１は、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（Ｓ２２）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（Ｓ２２）、受信したリプライメッセージを送信部４３からクライアント５０へ転送する（Ｓ３８）。
【０１１８】
ステップＳ２２にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰ圧縮判定部４２１は、さらに、リプライデータがＦＰ圧縮されているか否か調べ、判断する（Ｓ２３）。
【０１１９】
ステップＳ２３にて該リプライメッセージのリプライデータがＦＰ圧縮されているものと判断されたならば、ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ２４）、該フィンガープリントの値をキーとしてＦＰキャッシュ４４を検索する（Ｓ２５）。
【０１２０】
次に、ステップＳ２５において検索の結果得られたデータが差分圧縮データかどうか、ＦＰキャッシュ管理部４２２にて該データの圧縮識別子を用いて調べ、判断する（Ｓ２６）。
【０１２１】
ステップＳ２６にて該データが差分圧縮データであると判断された（本例では、圧縮識別子が１）ならば、差分解凍処理部４２４にて、（ＦＰキャッシュ管理部４２２において参照データを検索・取得した後に）差分圧縮データを解凍して元のリプライデータを復元し（Ｓ２７）、該復元したリプライデータをリプライメッセージに付加し、またプロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除し、該リプライメッセージを送信部４３からクライアント５０へ送信する（Ｓ２８）。
【０１２２】
ステップＳ２６にて該データが差分圧縮データではないと判断された（本例では、圧縮識別子が０）ならば、ＦＰ解凍処理部４２３にて、受信リプライメッセージに対して、ＦＰキャッシュ４４から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（Ｓ２９）。
【０１２３】
一方、ステップＳ２３にて該リプライメッセージのリプライデータがＦＰ圧縮されていないものと判断されたならば、ＦＰ圧縮判定部４２１は、さらに、該リプライデータが差分圧縮されているか否か判定する（Ｓ３０）。
【０１２４】
ステップＳ３０で差分圧縮されていると判断された場合、次の２つの作業を行う(1-1と1-2のいずれを先に行ってもよいし、並行して行ってもよい)。
（１−１）差分解凍処理部４２４にて、（ＦＰキャッシュ管理部４２２により参照データを検索・取得した後に）差分圧縮データを解凍して元のリプライデータを復元し（Ｓ３１）、該復元したリプライデータをリプライメッセージに付加し、またプロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除し、該リプライメッセージを送信部４３からクライアント５０へ送信する（Ｓ３２）。
（１−２）ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ３３）、該フィンガープリントの値と、差分圧縮データとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ４４に登録する（Ｓ３４）。このとき、ＦＰキャッシュ４４への登録においては、リプライメッセージは差分圧縮データであるので、圧縮識別子は１にセットする。
【０１２５】
一方、ステップＳ３０で差分圧縮されてないと判断された場合、次の２つの作業を行う(2-1と2-2のいずれを先に行ってもよいし、並行して行ってもよい)。
(2-1)差分解凍処理部４２４（あるいはＦＰ解凍処理部４２３）にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（Ｓ３５）。
(2-2)ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（Ｓ３６）、該フィンガープリントの値と、該リプライメッセージとを対応付けて（フィンガープリントの値をキーにして）、ＦＰキャッシュ４４に登録する（Ｓ３７）。このとき、ＦＰキャッシュ４４への登録においては、リプライメッセージは差分圧縮データではないので、圧縮識別子は０にセットする。
【０１２６】
なお、ステップＳ２４／Ｓ３３／Ｓ３６では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リプライデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リプライデータをもとにフィンガープリントの値を計算する方法も可能である。また、ステップＳ２４／Ｓ３３／Ｓ３６は、フィンガープリントを使用する以前の他のタイミングで行って構わない。また、ステップＳ２２、Ｓ２３、Ｓ２６、Ｓ３０の判断の全部または一部を同時に行ってもよい。
【０１２７】
次に、差分圧縮を行う手順について説明する。
【０１２８】
図２６に、差分圧縮手順の一例を示す。これは、先に説明した３種類の指定を用いる場合の手順例である。
【０１２９】
ここでは、差分圧縮を行うために、フィンガープリント・キャッシュに入っているデータのうち、最近アクセスしたものを順に並べた履歴表を利用するものとする。この履歴表には、必ずしもフィンガープリント・キャッシュに入っている全てのデータのフィンガープリントが記録されている必要は無い。例えば、予め定められた個数が記録されていればよい（この場合、個数は、例えば差分圧縮の参照データとして使用するに有効な個数を想定して予め決定する）。
もちろん、履歴表への記録の基準として、最近のアクセスの順以外の１又は複数の基準を用いてもよいし、最近のアクセスの順の基準に加えて他に１又は複数の基準を併用してもよい。
【０１３０】
なお、履歴表は、フィンガープリント・キャッシュと一体化して構成する方法もある。
【０１３１】
（ステップＳ２３１）
まず、作業用のコピーバッファおよび指示バッファを空にする。
【０１３２】
このコピーバッファにコピーされた内容をもとに、図６（ａ）〜（ｃ）の指示が作成され、これが指示バッファに書き出される。最終的に、指示バッファに書き出された指示の並びが、差分圧縮データになる。
【０１３３】
（ステップＳ２３２）
差分圧縮の対象とするデータを文字列として扱い、その文字列上を指すポインタを用意する。まず、ポインタが当該文字列のうちの最初の文字を指すように設定する。
【０１３４】
以下では、ステップＳ２４１でポインタが当該文字列のうちの最後の文字に辿りついたと判断されるまで、ループ処理を実行することになる。
【０１３５】
（ステップＳ２３３）
履歴表に記録されているフィンガープリントに対応するデータを、新しいものから順に取り出し、その中に、差分圧縮したいデータの中のポインタの指す場所から予め定められた長さ以上マッチするデータを参照データとして取り出す。
【０１３６】
なお、参照データと決定方法としては、種々の方法がある。例えば、履歴表に記録されているフィンガープリントに対応するデータを最新の順に調べていき、最初に予め定めた長さ以上マッチしたデータを参照データとして取り出す方法、履歴表に記録されているフィンガープリントに対応するデータの全てを調べ、その中でマッチした長さが最も長かったデータ（ただし、予め定めた長さ以上マッチしたことを条件とする）を参照データとして取り出す方法などがある。
【０１３７】
（ステップＳ２３４）
参照データが見つけられたらならば、ステップＳ２３７へ移る。参照データが見つけられなかったならば、ステップＳ２３５へ移る。
【０１３８】
（ステップＳ２３７）
ステップＳ２３４にて参照データが見つけられた場合に、コピーバッファが空でなければ、コピーバッファ中の文字列に対応する、図６の（ｃ）の直接指定によるコピー指示を作成し、これを指示バッファに書き出す。コピーバッファは、空にする。
なお、コピーバッファが空ならば、何もしない。
【０１３９】
（ステップＳ２３８）
ステップＳ２３３にて見つかった参照データに対応する図６の（ａ）の参照データ定義が未だ指示バッファに書き出されていなければ、指示バッファに当該参照データ定義の指示を書き出す。
【０１４０】
（ステップＳ２３９）
参照データからマッチした文字列のコピー指示を、図６の（ｂ）のコピー指示として指示バッファに書き出す。
【０１４１】
（ステップＳ２４０）
ポインタを参照データとマッチした文字列の長さ分だけ進める。
【０１４２】
（ステップＳ２３５）
一方、ステップＳ２３４にて参照データが見つけられた場合に、ポインタの指す文字をコピーバッファに入れる。
【０１４３】
（ステップＳ２３６）
ポインタを１文字分だけ進める。
【０１４４】
（ステップＳ２４１）
差分圧縮の対象とするデータの最後までポインタが来ていなければ（処理していないデータ部分が残っていれば）、ステップＳ２３３へ戻る。差分圧縮の対象とするデータの最後までポインタが来ていたら（処理していないデータ部分が残っていなければ）、処理ループを抜けて、ステップＳ２４２へ移る。
【０１４５】
（ステップＳ２４２）
コピーバッファが空でなければ、コピーバッファ中の文字列に対応する、図６の（ｃ）の直接指定によるコピー指示を作成し、これを指示バッファに書き出す。コピーバッファは、空にする。
なお、コピーバッファが空ならば、何もしない。
【０１４６】
このときの指示バッファの内容が、差分圧縮データとなる。
【０１４７】
なお、前述のように、実際には、このようにして差分圧縮を行った後、差分圧縮を行った結果のデータサイズが、行う前のデータサイズよりも小さくなっている（あるいは一定基準（一定の圧縮量）を超えて小さくなっている）ことを確認する。差分圧縮によってデータサイズが小さくならない（あるいは一定基準（一定の圧縮量）を超えては小さくならない）場合には、差分圧縮しない方が良いので、データはそのまま転送する。
【０１４８】
ところで、上記の差分圧縮の処理において、ステップＳ２３３の予め定められた長さ以上マッチする文字列を持つ最新のデータを選び出す処理が、最も時間がかかる処理であると考えられる。この処理をより高速化するために、ハッシュ表を利用することができる。履歴表に入れるデータから、その中の全ての予め定められた長さの文字列を取り出し、そのハッシュ値（例えば、全ての文字のコードを足したものなど）を計算し、ハッシュ表に登録しておく。このハッシュ表は、同じハッシュ値を持つデータがあればより最新のデータによって上書きされるようにしておく。
このハッシュ表を使って、差分圧縮したいデータの現在のポインタの位置から予め定められた長さの文字列のハッシュ値を求め、そのハッシュ値を使ってハッシュ表を引いて求めたデータが、ステップＳ２３３で選ぶべきデータの第１の候補になる。ここで、異なる文字列でも同じハッシュ値を生成する場合があるので、本当に同じかどうかは文字列を実際に比較して確認し、同じでなければ、履歴表のデータを順に見るなど方法で次の候補を探す。
【０１４９】
ステップＳ２３３の処理を高速化する他の方法は、行を単位として比較処理を行う方法である。図２６の手順では文字を単位として比較処理をしていたが、履歴表にあるすべてのデータに対して、そのデータ内の各行のハッシュ値の列を計算しておく。差分圧縮したいデータからも、まず、各行のハッシュ値の列を計算する。以降は、図２６の手順と同様であるが、比較は文字単位ではなく、行のハッシュ値を単位として行う。この方法は、行を単位としているため、文字単位よりも比較回数を減らすことができる。ただし、ハッシュ値で比較するために、異なる行でも同じハッシュ値を持つ場合があるので、最終的にはハッシュ値が同じだと判断した後に、実際に行の中も比較して本当に同じかどうかを判断するのが望ましい。
もちろん、このように行を単位として比較する構成についても、上記のハッシュ技法を組み合わせることができる。この場合、連続する複数行を組み合わせて、予め定められた長さと同じか長くなる最少の行数を単位としてハッシュ表に登録すればよい。
【０１５０】
次に、図２７に、差分圧縮手順の他の例を示す。これは、フィンガープリント・キャッシュに登録されているデータのうちの１つを参照データとし、プロキシ間では、参照データに対応するフィンガープリントの値と、転送データと参照データとの差分を示す情報とを転送する場合の手順例である。
【０１５１】
ここでも、前述したような履歴表を用いるものとする。
【０１５２】
まず、履歴表に記録されているフィンガープリントに対応するデータのうち、所定の基準を満たす一つを、参照データとして選択する（ステップＳ２４５）。
【０１５３】
所定の基準は、例えば、差分圧縮の対象とするデータのうち、参照データとするデータとの間でマッチしなかった部分のデータ量が、予め定められたデータ量以下であって、かつ、参照データをそのマッチしなかった部分によって複数の塊に分断したときにおけるその分断された塊の数が、予め定められた数以下である場合に、これを参照データとして選択可能とする。
【０１５４】
そして、参照データとして決定する方法としては、前述のように、例えば、履歴表に記録されているフィンガープリントに対応するデータを最新の順に調べていき、最初に予め定めた長さ以上マッチしたデータを参照データとして取り出す方法、履歴表に記録されているフィンガープリントに対応するデータの全てを調べ、その中でマッチしなかったデータ量や分断数が最も少なかったデータを参照データとして取り出す方法など、種々の方法がある。
【０１５５】
参照データが見つけられたらならば（Ｓ２４６）、参照データ定義の指示（例えば図６の（ａ））を、指示バッファに書き出す（Ｓ２４７）。
【０１５６】
参照データのうち、マッチしなかった部分（直接指定データで置換する部分）を示す指示（例えば図６の（ｂ）と同じフォーマットの指示で１バイト目の指示識別子を変えたもの）を、指示バッファに書き出す（Ｓ２４８）。
【０１５７】
参照データのマッチしなかった部分に嵌め込むべきデータを示す直接指定する指示（例えば図６の（ｃ））を、指示バッファに書き出す（Ｓ２４９）。
【０１５８】
なお、置換部分が複数個所ある場合には、その分だけステップＳ２４８とステップＳ２４９を実行する。
【０１５９】
このときの指示バッファの内容が、差分圧縮データとなる。
【０１６０】
一方、参照データが見つけられたらならば（Ｓ２４６）、差分圧縮はしないことになる。
【０１６１】
なお、上記の図２６や図２７の説明では、履歴表をフィンガープリント・キャッシュとは別に設けるものとしたが、履歴表は、フィンガープリント・キャッシュと一体化して構成する方法もある。
【０１６２】
また、上記の説明では、履歴表を用いるものとしたが、履歴表を用いない方法もある。例えば、フィンガープリント・キャッシュを所定の順番で（例えば、エントリ順にあるいはランダムに）予め定められた上限数だけ調べ、それらのうちで最良のものを使用するようにする方法や、フィンガープリント・キャッシュを所定の順番で（例えば、エントリ順にあるいはランダムに）調べ、予め定められた条件を満たす参照データが初めて得られた時点で、参照データを決定してしまう方法など、種々の方法がある。
【０１６３】
また、履歴表またはフィンガープリント・キャッシュに、フィンガープリントに加えて、そのフィンガープリントを登録したときに元となったリプライデータを含んでいたリプライメッセージについてのＵＲＬをも保持しておき、参照データを探索する際に、まず差分圧縮対象のリプライデータを含むリプライメッセージについてのＵＲＬと同じＵＲＬを持つデータが、履歴表またはフィンガープリント・キャッシュに登録されていないかどうか調べ、登録されているならば当該ＵＲＬと同じＵＲＬを持つデータを他のものよりも優先して、参照データとして使用できないかどうか調べるようにしてもよい。
【０１６４】
もちろん、図２６や図２７の他にも、種々の差分圧縮の手順が可能である。
【０１６５】
なお、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際にはフィンガープリント・キャッシュを用いないものとする場合には、サーバ側プロキシ３０は、図２８に例示するように、クライアント側プロキシ４０からリクエストメッセージを受信し（ステップＳ６０）、これをサーバ２０へ送信する（ステップＳ６１）、という手順で構わない。同様に、クライアント側プロキシ４０は、図２９に例示するように、クライアント５０からリクエストメッセージを受信し（ステップＳ６２）、これをサーバ側プロキシ３０へ送信する（ステップＳ６３）、という手順で構わない。
【０１６６】
以下では、図３０〜図３２を参照しながら、フィンガープリント・キャッシュを利用したデータ転送についてより具体的に説明する。
【０１６７】
まず、図３０を参照しながら、サーバ側プロキシ３０からクライアント側プロキシ４０へ、フィンガープリント・キャッシュ登録されていないデータであって且つ差分圧縮も成功しなかったデータを転送するとともに、該データについてフィンガープリント・キャッシュ登録する場合の動作について説明する。
【０１６８】
（１）クライアント５０上のブラウザ等は、例えば“/A.cgi”というＵＲＬでサーバ２０に、ＰＯＳＴメソッドのリクエストメッセージを出したとする。サーバ２０へのリクエストメッセージは、まず、クライアント側プロキシ４０に送られるように、ブラウザ等を設定しておく。
【０１６９】
（２）クライアント５０からリクエストメッセージを受け取ったクライアント側プロキシ４０は、そのリクエストメッセージをサーバ側プロキシ３０に転送する。
【０１７０】
（３）リクエストメッセージを受け取ったサーバ側プロキシ３０は、そのリクエストメッセージをサーバ２０へ転送する。
【０１７１】
（４）サーバ２０は、該リクエストメッセージに対する処理を行った後、サーバ側プロキシ３０に、そのリプライメッセージを送り返す。
【０１７２】
（５）リプライメッセージを受け取ったサーバ側プロキシ３０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここでは、入っておらず、初めてのデータ（一旦フィンガープリント・キャッシュ登録されたものがその後に削除あるいは無効化されることがある構成の場合に、一旦フィンガープリント・キャッシュ登録されたが削除あるいは無効化され、その後において初めてである場合を含む）であるので、そのデータをフィンガープリントを名前としてＦＰキャッシュ３４に入れる（登録する）。なお、ここでは、リプライデータを差分圧縮してデータ量を減らすことができなかったものとする。このとき、ＦＰキャッシュ３４への登録においては、該データが差分圧縮データではないので、圧縮識別子は０にセットする。
【０１７３】
（６）サーバ側プロキシ３０は、データを載せたリプライメッセージをクライアント側プロキシ４０に転送する。なお、リプライデータから計算したフィンガープリントの値を、リプライヘッダ等に入れて送ると、クライアント側プロキシ４０で再度フィンガープリントを計算する手間を省くことが出来る。
【０１７４】
（７）リプライメッセージを受け取ったクライアント側プロキシ４０は、初めてのデータであるので、リプライデータをＦＰキャッシュ４４に登録する。このとき、ＦＰキャッシュ４４への登録においては、該リプライデータが差分圧縮データではないので、圧縮識別子は０にセットする。なお、前述したように、リプライデータからフィンガープリントを計算するか、あるいはサーバ側プロキシがリプライヘッダ等に入れたフィンガープリントを取り出し、これを名前として入れる。
【０１７５】
（８）クライアント側プロキシ４０は、（リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除した後に、）リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１７６】
なお、サーバ側プロキシ３０において、上記の（５）のフィンガープリント・キャッシュ登録は、（６）の動作の後に行っても構わない。また、クライアント側プロキシ４０において、（７）のフィンガープリント・キャッシュ登録は、（８）の動作の後に行っても構わない。
【０１７７】
次に、図３１を参照しながら、サーバ側プロキシ３０からクライアント側プロキシ４０へ、フィンガープリント・キャッシュ登録されていないデータであって且つ差分圧縮が成功したデータを転送するとともに、該データについてフィンガープリント・キャッシュ登録する場合の動作について説明する。
【０１７８】
（１）〜（４）は、図３０を参照して説明した動作における（１）〜（４）と同様である。
【０１７９】
（５）リプライメッセージを受け取ったサーバ側プロキシ３０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここでは、入っておらず、初めてのデータであることを判断する。そして、圧縮対象になるデータをＦＰ圧縮できなかった場合には、差分圧縮処理を行い、リプライデータを差分圧縮してデータ量を減らすことができるならば、差分圧縮する。ここでは、フィンガープリントが“７１Ｆ０…７３Ｅ６”のデータを参照データとした場合に、リプライデータを差分圧縮してデータ量を減らすことができたものとする。リプライデータを差分圧縮データに置き換え、リプライヘッダ等に差分圧縮したことを示す情報を入れる。
【０１８０】
（６）サーバ側プロキシ３０は、（５）において生成された差分圧縮データを同じく（５）で計算したフィンガープリントを名前としてＦＰキャッシュ３４へ入れる（登録する）。このとき、ＦＰキャッシュ３４への登録においては、該データが差分圧縮データであるので、圧縮識別子を１にセットする。
【０１８１】
（７）サーバ側プロキシ３０は、リプライメッセージをクライアント側プロキシ４０に転送する。
【０１８２】
（８）クライアント側プロキシ４０は、リプライヘッダ等を見て、リプライデータが差分圧縮されていることを知り、圧縮の解凍を行う。このとき、まず、圧縮されたデータ内に指定されている参照データのフィンガープリント“７１Ｆ０…７３Ｅ６”を取り出し、次に、該フィンガープリントに対応するデータをＦＰキャッシュ４４から取り出して使用する。そして解凍したデータをリプライデータに入れ、リプライヘッダのコンテンツサイズなど必要なヘッダを書き換える。
【０１８３】
（９）また、リプライメッセージを受け取ったクライアント側プロキシ４０は、初めてのデータであるので、サーバ側プロキシ３０から受信した差分圧縮データをＦＰキャッシュ４４に登録する。このとき、ＦＰキャッシュ４４への登録においては、登録するデータが差分圧縮データであるので、圧縮識別子を１にセットする。また、リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除する。なお、前述したように、リプライデータ（差分圧縮データから解凍して得られたデータ）からフィンガープリントを計算するか、あるいはサーバ側プロキシがリプライヘッダ等に入れたフィンガープリントを取り出し、これを名前として入れる。
【０１８４】
（１０）クライアント側プロキシ４０は、リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１８５】
なお、上記の（５）では、圧縮対象で未登録のデータは、すべてフィンガープリント・キャッシュに登録するものとし、また、上記の（６）で参照データに用いたデータは、すべてフィンガープリント・キャッシュの登録を維持するものとしたが、参照データに唯一のデータを使用した場合であって、かつ、差分圧縮対象となったデータと、その差分圧縮に用いた参照データとが、ほとんど同じ内容（例えば、両者でマッチしないデータ量が基準以下）である場合には、（ｉ）圧縮対象で未登録のデータはフィンガープリント・キャッシュに登録せず、参照データはフィンガープリント・キャッシュの登録を維持する、あるいは（ii）圧縮対象で未登録のデータをフィンガープリント・キャッシュに登録し、参照データはフィンガープリント・キャッシュから削除する、などの方法も可能である。また、参照データに唯一のデータを使用した場合であって、かつ、差分圧縮対象となったデータと、その差分圧縮に用いた参照データとが、ほとんど同じ内容であって、かつ、ＵＲＬが同一の場合には、データが更新されたものとして、圧縮対象で未登録のデータをフィンガープリント・キャッシュに登録し、参照データはフィンガープリント・キャッシュから削除する、などの方法も可能である。その他にも種々のバリエーションがある。
【０１８６】
次に、図３２を参照しながら、図３０または図３１の動作が行われてキャッシュ登録されているデータを、サーバ側プロキシ３０からクライアント側プロキシ４０へ転送する場合の動作について説明する。
【０１８７】
（１）〜（４）は、図３０を参照して説明した動作における（１）〜（４）と同様である。
【０１８８】
（５）サーバ５０からリプライメッセージを受け取ったサーバ側プロキシ４０は、まず、受信リプライメッセージの持つリプライデータのフィンガープリントを計算し、そのフィンガープリント名を持ったデータがＦＰキャッシュ３４に入っているかどうかを調べる。ここではフィンガープリント・キャッシュ登録されているので、（例えばフィンガープリントの値をリプライヘッダ等に入れ且つリプライボディを空にするなどして）リプライボディのデータをフィンガープリントで置き換える。
【０１８９】
（６）サーバ側プロキシ３０は、リプライボディをフィンガープリントで置き換えたリプライメッセージをクライアント側プロキシ４０に転送する。
【０１９０】
（７）リプライメッセージを受け取ったクライアント側プロキシ４０は、リプライデータがフィンガープリントで置き換えられていることを検出し、（前述したように例えばリプライヘッダなどにて）指定されたフィンガープリントを使ってＦＰキャッシュ４４から対応するデータを取り出す。
ここで、該データの圧縮識別子が０である場合には、該データは差分圧縮データではないので、これをリプライボディに入れる。一方、該データの圧縮識別子は１である場合には、該データは差分圧縮データであるので、これを解凍してもとのリプライデータを復元し、これをリプライボディに入れる。なお、図３２は、前者の場合を例示している。
また、リプライヘッダ等にフィンガープリントの値などのサーバ側プロキシ３０とクライアント側プロキシ４０との間だけで使用される情報が存在する構成の場合には、これを削除する。
【０１９１】
（８）そして、クライアント側プロキシ３０は、リプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０１９２】
ところで、サーバ側プロキシ３０およびクライアント側プロキシ４０のフィンガープリント・キャッシュは、その容量に上限があるため、所定のアルゴリズムに従いガベージコレクションを行って、例えば古いデータや使いそうに無いデータを消して行くのが好ましい。
【０１９３】
ただし、このようにすると、サーバ側プロキシ３０のＦＰキャッシュ３４は持っていてもクライアント側プロキシ４０のＦＰキャッシュ４４では既に消されているようなデータが発生し得ることになるので、図３２を参照して説明した動作における（７）で、クライアント側プロキシ４０において、フィンガープリントをもとにしてＦＰキャッシュ４４からリプライデータを置き換えるべきデータを得ようとしたが、ＦＰキャッシュ４４に該当するフィンガープリントとデータの組が存在しない場合がある。このような場合には、例えば、クライアント側プロキシ４０は、サーバ側プロキシ３０に対して、指定したフィンガープリントのデータを送るように依頼し、依頼されたサーバ側プロキシ３０は、指定されたフィンガープリントのデータをＦＰキャッシュ３４から取り出して送り返すような仕組みを設ければよい。
【０１９４】
なお、逆に、サーバ側プロキシ３０のＦＰキャッシュ３４では既に消されているがクライアント側プロキシ４０のＦＰキャッシュ４４はまだ持っているようなデータが存在する場合には、図３０を参照して説明した動作における（７）や図３１を参照して説明した動作における（９）で、クライアント側プロキシ４０において、フィンガープリント／データをＦＰキャッシュ４４に登録する際に、その時点で登録されていたフィンガープリント／リプライデータに対して上書きしてもよい。
【０１９５】
図３２を参照して説明した動作における（５）で、サーバ側プロキシ３０において、リプライデータのフィンガープリントを求め、該フィンガープリントがＦＰキャッシュ３４に入っていれば、当該プライデータと同じデータが該フィンガープリントと組になってＦＰキャッシュ３４に入っているものとみなして処理している。実用上、異なるデータから同じフィンガープリントが生成されないことを前提にすれば、この方法で十分であるが、非常に小さな確率で異なるデータのフィンガープリントが偶々同じ値になってしまった場合に生じるエラーを取り除くようにする方法もある。この場合には、リプライデータから求めたフィンガープリントがＦＰキャッシュ３４に入っているときに、該フィンガープリントと組になってＦＰキャッシュ３４に入っているデータと、当該プライデータとを比較して、同じか否かを判断するようにすればよい。このとき、もしフィンガープリントは同じであるが内容が異なるデータが登録されていると判断された場合の処理は、以下に例示するような方法が考えられる。
・そのフィンガープリントは以降使用しないものとする（そのフィンガープリントを与えるデータは以後キャッシュされないことになる）
・先に登録されているフィンガープリント／データを優先する（登録中のフィンガープリントと同じ値のフィンガープリントを与える他のデータは、その登録中はキャッシュされないことになる）
・現在登録対象となっているフィンガープリント／データを優先する（登録中のフィンガープリント／データは、同じ値のフィンガープリントを与える他のデータによって次々と更新されていくことになる）
ところで、これまで説明した例では、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライデータを転送する際にフィンガープリント・キャッシュを利用するものとし、あるデータとこれに対するフィンガープリントとの組をフィンガープリント・キャッシュに登録するタイミングは、そのデータが初めてサーバ側プロキシ３０からクライアント側プロキシ４０へ転送されるときとしている。しかし、例えばＷｅｂベースのＡＳＰのような利用法では、データはまずユーザオフィス等で作成されてサーバに登録され、それをブラウザ等からアクセスするような場合が多いため、このような場合には、当該データを（データ本体または差分圧縮データとして）サーバに登録する時点でクライアント側プロキシおよびサーバ側プロキシのフィンガープリント・キャッシュに登録しておくと、それ以降のアクセスを高速化することができる。そこで、サーバが送信するリプライデータが、もともとはクライアントからサーバへ転送されたデータ（ただし、この転送のときはリクエストデータ）である場合には、登録タイミングを、該リプライデータとなる元のリクエストデータが初めてクライアント側プロキシ４０からサーバ側プロキシ３０へ転送されるときとするようにしてもよい（この場合、当該データがリプライデータとなって初めてサーバ側プロキシ３０からクライアント側プロキシ４０へ転送される際には、すでにフィンガープリント・キャッシュへの登録が完了していることになるので、リプライデータとしては初めての転送であっても、フィンガープリント・キャッシュを利用して、転送データ量を削減することができる）。
【０１９６】
さて、これまで説明した例では、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライデータを転送するときに、該リプライデータがフィンガープリント・キャッシュに登録されているデータと同じものである場合には、該リプライデータに代えて、対応するフィンガープリントを転送し、または差分圧縮データを転送することで、ネットワークのトラフィックを軽減しているが、本発明は、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストデータを転送する場合についてさらに適用することが可能である。
【０１９７】
なお、ＦＰ圧縮を両方に適用する場合に、差分圧縮をいずれか一方についてのみ適用することも可能である。
【０１９８】
また、ＦＰ圧縮および差分圧縮を、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストデータを転送する場合についてのみ適用することも可能である。
【０１９９】
ＦＰ圧縮および差分圧縮をクライアント側プロキシ４０からサーバ側プロキシ３０へのリクエストデータ転送に適用する場合、すでに説明したリプライデータに対するサーバ側プロキシ３０とクライアント側プロキシ４０との役割を逆にすればよいので、ＦＰ圧縮および差分圧縮を両データ転送に適用する場合には、サーバ側プロキシ３０は図１９の構成に加えて、更に処理部３２にフィンガープリント解凍処理部および差分解凍処理部を備え、クライアント側プロキシ４０は図２０の構成に加えて、更に処理部４２にフィンガープリント圧縮処理部および差分圧縮処理部を備えればよい。
【０２００】
なお、いずれのプロキシにおいても、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せて、フィンガープリント（ＦＰ）圧縮・解凍処理部としてもよい。同様に、差分圧縮処理部と差分解凍処理部とを併せて、差分圧縮・解凍処理部としてもよい。
【０２０１】
また、サーバ側プロキシ３０やクライアント側プロキシ４０は、リプライデータ転送に対するフィンガープリント・キャッシュとは独立にリクエストデータ転送に対するフィンガープリント・キャッシュを設けてもよいが、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用してもよい。なお、差分圧縮の際に前述した履歴表を使用する構成の場合には、履歴表についても同様に独立して設けてもよいし、共用してもよい。
【０２０２】
図３３に、リプライデータ転送とクエストデータ転送とで同じフィンガープリント・キャッシュを共用する場合のプロキシ（サーバ側プロキシ、クライアント側プロキシ）の構成例を示す。
【０２０３】
また、図３４及び図３５に、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際のクライアント側プロキシ４０の処理手順の一例を示す。図３４及び図３５は、図２１及び図２２において、転送するメッセージがリプライメッセージからリクエストメッセージになり、メッセージ送信元がサーバからクライアントになり、メッセージ送信先がクライアントからサーバになり、サーバ側プロキシ３０の動作とクライアント側プロキシ４０の動作とを入れ替えたものに相当する。
【０２０４】
また、図３６〜図３８に、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。
【０２０５】
図３６〜図３８は、図２３〜図２５において、転送するメッセージがリプライメッセージからリクエストメッセージになり、メッセージ送信元がサーバからクライアントになり、メッセージ送信先がクライアントからサーバになり、サーバ側プロキシ３０の動作とクライアント側プロキシ４０の動作とを入れ替えたものに相当する。
【０２０６】
このようにリクエストデータに対してもフィンガープリントまたは差分圧縮データで置き換えられるように実施すると、例えば、同じファイルを何度もサーバにアップロードするときには、２回目以降フィンガープリントを送るだけで済むので、ネットワークのトラフィックを軽減させることができる。
【０２０７】
なお、本実施形態では、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージや、サーバ側プロキシからクライアント側プロセスへ転送されるリプライメッセージを対象とする場合について示してきたが、あるプロキシに、リクエストメッセージを送信する装置とリプライメッセージを送信する装置との両方、あるいはリクエストメッセージおよびリプライメッセージの両方を送信する装置が接続されている場合には、もちろん、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージおよびリプライメッセージならびにサーバ側プロキシからクライアント側プロセスへ転送されるリクエストメッセージおよびリプライメッセージを対象とすることや、クライアント側プロセスからサーバ側プロキシへ転送されるリクエストメッセージおよびサーバ側プロキシからクライアント側プロセスへ転送されるリクエストメッセージのみ対象とすることなども可能である。
【０２０８】
ところで、これまでは１つのサーバ側プロキシと１つのクライアント側プロキシとの間の１対１の通信に着目して説明してきたが、本発明の適用範囲はもちろんサーバ側プロキシとクライアント側プロキシとが１対１で通信するシステムには限定されるものではなく、サーバ側プロキシとクライアント側プロキシとが１対多で通信するシステム、サーバ側プロキシとクライアント側プロキシとが多対１で通信するシステム、あるいはサーバ側プロキシとクライアント側プロキシとが多対多で通信するシステムにも適用可能である。例えば、図３９のように、複数のユーザオフィスに設置したクライアント側プロキシや、モバイルユーザが利用する個人用プロキシなどがサーバ側プロキシを共有して使用するように実施することも可能である。
【０２０９】
また、これまでは、１つのメッセージに含まれるデータ全体をＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にしていたが、例えば、１つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、１つのメッセージに含まれる一部の単位データのみＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にする構成も可能である。
【０２１０】
ところで、本実施形態のサーバ側プロキシあるいはクライアント側プロキシ（一方でも両方でもよい）に、プロキシの共有キャッシュ機構でキャッシュ可能とされているリプライデータについて、クライアントが出したリクエストメッセージにおいて指定されていたＵＲＬと、該リクエストメッセージに対応するリプライメッセージに含まれていたリプライデータと、該リプライデータに対応するフィンガープリントと、該リプライメッセージのリプライ・ヘッダに入れられて来たＭＩＭＥタイプなどのリクエスト・ヘッダを構成するのに必要な情報や有効期間の判定に使うためのタイムスタンプなどの情報を対応付けてキャッシュしておき（フィンガープリント・キャッシュにすべて保持してもよいし、リプライデータを除く情報（ＵＲＬとフィンガープリントと他の情報）を保持する対応テーブルを別途設けてもよい）、これとフィンガープリント・キャッシュとを併用することで、プロキシサーバの共有キャッシュの動作をも行うようにすることができる。例えば、クライアント側プロキシに該キャッシュ機能を設けた場合、クライアントが送信したリクエストメッセージにて指定されているＵＲＬに対するリプライデータがキャッシュされており且つ該データが有効である場合には、該クライアント側プロキシが、ＵＲＬに対応するデータをフィンガープリント・キャッシュから取得して、リプライメッセージを作成して、これをクライアントに応答することができる。
【０２１１】
この機能は、個々のサーバ側プロキシ３０毎に、また個々のクライアント側プロキシ４０毎に、設けるか否かを定めることができる。
【０２１２】
まず、上記機能を設けたクライアント側プロキシ４０について説明する。
【０２１３】
図４０に、この場合のクライアント側プロキシ４０の構成例を示す。このクライアント側プロキシ４０は、図２０の構成・機能に加えて、更に過去にアクセスしたＵＲＬと、そのリプライデータのフィンガープリントとの対応を保持するＵＲＬ・フィンガープリント・テーブル（ＵＲＬ・ＦＰテーブル）４５と、ＵＲＬキャッシュ処理部４２７とを備えている。
【０２１４】
なお、ＵＲＬ・ＦＰテーブル４５には、ＵＲＬおよびフィンガープリント以外に、そのＵＲＬでアクセスしたときにリプライヘッダに入れられて来たＭＩＭＥタイプや、有効期間の判定に使うためのタイムスタンプなどの情報も併せて記録する。また、ＵＲＬ・ＦＰテーブル４５には、従来の共有キャッシュがキャッシュできる場合にのみ必要な情報を記録する。
【０２１５】
図４１に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のクライアント側プロキシ４０の処理手順例を示す。
【０２１６】
なお、この場合の処理手順は、図２３〜図２５の手順の端子４および端子６およびステップＳ３８の後に追加される以外は、図２３〜図２５の手順と同じであり、図４１では、図２３〜図２５の手順の端子４および端子６およびステップＳ３８より後の処理手順の部分を示してある。ここでは、図２３〜図２５で説明した手順に追加する部分を中心に説明する。
【０２１７】
クライアント側プロキシ４０は、送信部４３により、クライアント５０にリプライメッセージを送信（図２３〜図２５のステップＳ２８、Ｓ２９、Ｓ３２、Ｓ３５またはＳ３８）した後、ＵＲＬキャッシュ処理部４２７にて、該リプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ３９）。キャッシュ対象であると判断されたならば、ＵＲＬキャッシュ処理部４２７にて、ＵＲＬとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて（ＵＲＬをキーにして）をＵＲＬ・ＦＰテーブル４５に登録する（Ｓ４０）。キャッシュ対象でないと判断されたならば、何もしない。
【０２１８】
なお、ステップＳ３９の判断およびステップＳ４０のＵＲＬ・ＦＰテーブルへの登録は、ステップＳ２３とステップＳ２８あるいはＳ２９、ステップＳ２３とステップＳ３２あるいはステップＳ３５の間にて行うようにしても構わない。
【０２１９】
なお、登録時の受信リプライメッセージがキャッシュ対象のものであるか否かの判断方法は、従来の登録時の手法と同様で構わない（例えば、ＧＥＴメソッドのリプライデータであって、かつ、そのヘッダにキャッシュ不可を示す情報が記述されていないものをキャッシュ対象とする等）。
【０２２０】
次に、図４２および図４３に、クライアント２５０から受信したリクエストメッセージをクライアント側プロキシ４０からサーバ側プロキシ３０へ転送する際のクライアント側プロキシ４０におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【０２２１】
クライアント側プロキシ４０は、受信部４１により、クライアント５０からリクエストメッセージを受信する（ステップＳ１４１）。
【０２２２】
ＵＲＬキャッシュ処理部４２７は、リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１４２）。なお、応答時のキャッシュ対象か否かの判断方法は、従来の応答時の手法と同様で構わない（例えば、受信リクエストメッセージがＧＥＴメソッドのものであるか否か）。
【０２２３】
リクエストデータがキャッシュ対象外のものと判断されたならば（Ｓ１４２）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。
【０２２４】
ステップＳ１４２にて該リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであると判断されたならば、ＵＲＬキャッシュ処理部４２７は、さらに、該リクエストメッセージに指定されているＵＲＬを取り出し（Ｓ１４３）、そのＵＲＬをキーとしてＵＲＬ・ＦＰテーブル４５を検索する（Ｓ１４４）。
【０２２５】
そのＵＲＬに対応するリプライデータのフィンガープリントがキャッシュされていなければ（Ｓ１４５）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。このとき、現在保持しているデータのタイムスタンプをリクエストメッセージのIf-Modified-Sinceヘッダに記入してサーバ側プロキシ３０へ転送し、サーバ側プロキシ３０から現在保持しているデータが有効であるとのリプライメッセージを受け取ると、ステップＳ１４７へ行くように実施することもできる。
【０２２６】
また、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されていても（Ｓ１４５）、併せて保持されている有効期間の判定のための情報に基づいてそのデータが無効になっていると判断されれば（Ｓ１４６）、受信したリクエストメッセージを送信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５１）。
【０２２７】
一方、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されており（Ｓ１４５）、かつ、併せて保持されている有効期間の判定のための情報に基づいてそのデータが有効であると判断されれば（Ｓ１４６）、ＵＲＬキャッシュ処理部４２７は、ＵＲＬ・ＦＰテーブル４５からリプライデータを構成するのに必要な情報を得るとともに、当該ＵＲＬに対応するリプライデータのフィンガープリントをキーとしてＦＰキャッシュ４４を検索する（Ｓ１４７）。
【０２２８】
次に、ＦＰキャッシュ管理部４２２は、ステップＳ１４７にて取得したデータが差分圧縮データであるかどうかを、圧縮識別子が０または１のいずれであるかをもって判断する（Ｓ１４８）。圧縮識別子が０であれば、差分圧縮データではないと判断され、１であれば、差分圧縮データであると判断される。
【０２２９】
該データが差分圧縮データであることが判明した場合（Ｓ１４８）、差分解凍処理部４２４は該データを解凍し、リプライデータを生成する（Ｓ１４９）。そして、該リプライデータからリプライメッセージを生成し、送信部４３からクライアントへ転送する（Ｓ１５０）。
【０２３０】
一方、該データが差分圧縮データでないことが判明した場合（Ｓ１４８）、ＦＰ圧縮解凍部４２３は、該データからリプライデータを生成し、送信部４３からクライアントへ転送する（Ｓ１５０）。
【０２３１】
以下では、図４４（応答時）を参照しながら、共有キャッシュの動作についてより具体的に説明する。
【０２３２】
（１）クライアント５０上のブラウザ等は、例えば“/C.html”というＵＲＬでサーバ２０に、ＧＥＴメソッドのリクエストメッセージを出したとする。
【０２３３】
（２）新しいＵＲＬでリクエストが来たときに、そのＵＲＬがＵＲＬ・ＦＰテーブル４５に載っていれば、従来の共有キャッシュと同様に有効期間の判定を行い、有効と判断できれば、そのＵＲＬに対応するフィンガープリントをＵＲＬ・ＦＰテーブル４５を引いて求め、それを名前とするデータをＦＰキャッシュ４４から取り出す。そして、圧縮識別子により、該データが差分圧縮データかどうか調べる。図４４の例では、圧縮識別子が１であるので差分圧縮データである。すると、差分圧縮を解凍し（図４４では、差分圧縮データ内に、フィンガープリントが“７１Ｆ０…７３Ｅ６”であるデータへの参照情報があるため、既にキャッシュされている該データが参照され、解凍される）、これをリプライデータとする。さらに、ＵＲＬ・ＦＰテーブル４５からＭＩＭＥタイプ等のリプライヘッダを構成するのに必要な情報を取り出してリプライヘッダを作成する。
【０２３４】
（３）作成したリプライメッセージを、クライアント５０（上で動作するブラウザ等）へ送り返す。
【０２３５】
なお、キャッシュの内容が指定した時間以降に更新されている場合にのみデータを送ることを依頼するIf-Modified-Sinceヘッダを持つリクエストメッセージの場合も、まずＵＲＬ・ＦＰテーブルを参照し更新されていないことが判断できれば、そこでリプライメッセージを作成して返し、そうでなければサーバまで再びIf-Modified-Sinceの情報を書き直して聞きに行くように実施することもできる。
【０２３６】
次に、キャッシュ機能を設けたサーバ側プロキシ３０について説明する。
【０２３７】
上記ではクライアント側プロキシ４０のキャッシュ機能について説明したが、サーバ側プロキシ３０も同様に実施可能である。
【０２３８】
この場合、クライアント側プロキシ４０に対するメッセージ転送元のクライアント５０とメッセージ転送先のサーバ側プロキシ３０が、サーバ側プロキシ３０に対してはそれぞれクライアント側プロキシ４０（転送元）とサーバ２０（転送先）になり、キャッシュに関係する構成・手順は同様である。
【０２３９】
図４５に、この場合のサーバ側プロキシ３０の構成例を示す。このサーバ側プロキシ３０は、図１９の構成・機能に加えて、更に過去にアクセスしたＵＲＬと、そのリプライデータのフィンガープリントとの対応を保持するＵＲＬ・フィンガープリント・テーブル（ＵＲＬ・ＦＰテーブル）３５と、ＵＲＬキャッシュ処理部３２７とを備えている。
【０２４０】
図４６に、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送する際のサーバ側プロキシ３０の処理手順の一例を示す。
【０２４１】
なお、この場合の処理手順は、図２１及び図２２の手順のステップＳ６および端子２およびＳ１３の後に追加される以外は、図２１及び図２２の手順と同じであり、図４６では、図２１及び図２２の手順のステップＳ６および端子２およびＳ１３より後の処理手順の部分を示してある。ここでは、図２１及び図２２で説明した手順と相違する部分を中心に説明する。
【０２４２】
サーバ側プロキシ３０は、送信部３３により、クライアント側プロキシ４０にリプライメッセージを送信（図２１及び図２２のステップＳ６、Ｓ９、Ｓ１１、またはＳ１３）した後、ＵＲＬキャッシュ処理部３２７にて、該リプライメッセージのリプライデータがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１４）。キャッシュ対象であると判断されたならば、ＵＲＬキャッシュ処理部３２７にて、ＵＲＬとフィンガープリントとリプライヘッダを構成するのに必要な情報等を対応付けて（ＵＲＬをキーにして）をＵＲＬ・ＦＰテーブル３５に登録する（Ｓ１５）。キャッシュ対象でないと判断されたならば、何もしない。
【０２４３】
もちろん、前述と同様に、この手順も種々変形することが可能である。
【０２４４】
図４７に、クライアント側プロキシ４０から受信したリクエストメッセージをサーバ側プロキシ３０からサーバ２０へ転送する際のサーバ側プロキシ３０におけるプロキシサーバの共有キャッシュの動作に関する処理手順の一例を示す。
【０２４５】
サーバ側プロキシ３０は、受信部３１により、クライアント側プロキシ４０からリクエストメッセージを受信する（ステップＳ１６１）。
【０２４６】
ＵＲＬキャッシュ処理部３２７は、リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであるか否か調べ、判断する（Ｓ１６２）。なお、応答時のキャッシュ対象か否かの判断方法は、従来の応答時の手法と同様で構わない（例えば、受信リクエストメッセージがGETメソッドのものであるか否か）。
【０２４７】
リクエストデータがキャッシュ対象外のものと判断されたならば（Ｓ１６２）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。
【０２４８】
ステップＳ１６２にて該リクエストメッセージに対するリプライメッセージがキャッシュ対象のものであると判断されたならば、ＵＲＬキャッシュ処理部３２７は、さらに、該リクエストメッセージに指定されているＵＲＬを取り出し（Ｓ１６３）、そのＵＲＬをキーとしてＵＲＬ・ＦＰテーブル３５を検索する（Ｓ１６４）。
【０２４９】
そのＵＲＬに対応するリプライデータのフィンガープリントがキャッシュされていなければ（Ｓ１６５）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。このとき、現在保持しているデータのタイムスタンプをリクエストメッセージのIf-Modified-Sinceヘッダに記入してサーバ２０へ転送し、サーバ２０から現在保持しているデータが有効であるとのリプライメッセージを受け取ると、ステップＳ１６７へ行くように実施することもできる。
【０２５０】
また、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されていても（Ｓ１６５）、併せて保持されている有効期間の判定のための情報に基づいてそのデータが無効になっていると判断されれば（Ｓ１６６）、受信したリクエストメッセージを送信部３３からサーバ２０へ転送する（Ｓ１６９）。
【０２５１】
一方、そのＵＲＬに対応するリプライデータのフィンガープリントが登録されており（Ｓ１６５）、かつ、併せて保持されている有効期間の判定のための情報に基づいてそのデータが有効であると判断されれば（Ｓ１６６）、ＵＲＬキャッシュ処理部３２７は、ＵＲＬ・ＦＰテーブル３５からリプライデータを構成するのに必要な情報を得るとともに、当該ＵＲＬに対応するリプライデータのフィンガープリントをキーとしてＦＰキャッシュ３４を検索する（Ｓ１６７）。
【０２５２】
ＦＰキャッシュ管理部３２２は、ＦＰキャッシュ３４から取得したデータから、該フィンガープリントの値を用いてリプライメッセージをＦＰ圧縮時のフォーマットで生成し、送信部３３から、クライアント側プロキシ４０へ送信する（Ｓ１６８）。
【０２５３】
このように、サーバ側プロキシにもＵＲＬ・ＦＰテーブル表を持ってキャッシュの処理をする構成は、一つのサーバ側プロキシが複数のクライアント側プロキシから使われているときに有効に働く。すなわち、あるクライアント側プロキシから要求のあったキャッシュ可能なデータが既に他のクライアント側プロキシによってアクセスされている場合には、サーバ側プロキシにもキャッシュされているので、そのデータを送り返すだけで処理が完了する。
【０２５４】
このように、サーバ側プロキシにもＵＲＬ・ＦＰテーブル表を持ってキャッシュの処理をする構成は、一つのサーバ側プロキシが複数のクライアント側プロキシから使われているときに有効に働く。すなわち、あるクライアント側プロキシから要求のあったキャッシュ可能なデータが既に他のクライアント側プロキシによってアクセスされている場合には、サーバ側プロキシにもキャッシュされているので、そのデータを送り返すだけで処理が完了する。
【０２５５】
なお、以上では、ＵＲＬ・ＦＰテーブル表をフィンガープリント・キャッシュとは別途に設ける場合について説明したが、ＵＲＬ・ＦＰテーブル表をフィンガープリント・キャッシュと一体化して構成することも可能である。
【０２５６】
なお、いずれのプロキシにおいても、フィンガープリント圧縮処理部とフィンガープリント解凍処理部とを併せて、フィンガープリント（ＦＰ）圧縮・解凍処理部としてもよい。また、いずれのプロキシにおいても、差分圧縮処理部と差分解凍処理部とを併せて、差分圧縮・解凍処理部としてもよい。図４８に、この場合のプロキシ（サーバ側プロキシ、クライアント側プロキシ）の構成例を示す。
【０２５７】
ＦＰ圧縮を該リクエストデータ転送のみに適用した場合、ＦＰ圧縮を該リプライデータ転送のみに適用した場合、ＦＰ圧縮を該リクエストデータ転送および該リプライデータ転送に適用した場合のいずれにおいても、リクエストメッセージが指定するＵＲＬに対応するリプライデータに対する共用キャッシュ機能に関する構成をクライアント側プロキシのみに設けることも、サーバ側プロキシのみに設けることも、両プロキシに設けることも可能である。
【０２５８】
なお、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することも、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０２５９】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０２６０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０２６１】
【発明の効果】
本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を保持しているデータについては、データ本体を転送する代わりに対応する名前を転送することで、データ転送装置間の転送データ量を削減させることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワーク・システムの構成例を示す図
【図２】同実施形態に係るネットワーク・システムの他の構成例を示す図
【図３】同実施形態に係るネットワーク・システムのさらに他の構成例を示す図
【図４】フィンガープリントについて説明するための図
【図５】同実施形態に係るフィンガープリント・キャッシュについて説明するための図
【図６】同実施形態で使用する差分圧縮の指示方法について説明するための図
【図７】同実施形態の差分圧縮の具体例について説明するための図
【図８】同実施形態の差分圧縮の具体例について説明するための図
【図９】同実施形態の差分圧縮の具体例について説明するための図
【図１０】同実施形態の差分圧縮の他の具体例について説明するための図
【図１１】同実施形態の差分圧縮の他の具体例について説明するための図
【図１２】同実施形態の差分圧縮の他の具体例について説明するための図
【図１３】同実施形態の差分圧縮の他の具体例について説明するための図
【図１４】同実施形態で使用するメッセージ・フォーマットの一例を示す図
【図１５】同実施形態で使用するメッセージ・フォーマットの他の例を示す図
【図１６】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１７】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１８】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１９】同実施形態に係るサーバ側プロキシの構成例を示す図
【図２０】同実施形態に係るクライアント側プロキシの構成例を示す図
【図２１】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２２】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２３】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２４】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２５】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２６】同実施形態の差分圧縮の処理手順の一例を示すフローチャート
【図２７】同実施形態の差分圧縮の処理手順の他の例を示すフローチャート
【図２８】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図２９】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図３０】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３１】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３２】同実施形態に係るプロキシ間のデータ転送について説明するための図
【図３３】同実施形態にプロキシの他の構成例を示す図
【図３４】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図３５】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図３６】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３７】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３８】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図３９】同実施形態に係るネットワーク・システムのさらに他の構成例を示す図
【図４０】同実施形態に係るクライアント側プロキシの他の構成例を示す図
【図４１】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４２】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４３】同実施形態に係るクライアント側プロキシの他の手順例を示すフローチャート
【図４４】同実施形態に係るクライアントとクライアント側プロキシとの間のデータ転送について説明するための図
【図４５】同実施形態に係るサーバ側プロキシの他の構成例を示す図
【図４６】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図４７】同実施形態に係るサーバ側プロキシの他の手順例を示すフローチャート
【図４８】同実施形態に係るプロキシのさらに他の構成例を示す図
【図４９】従来のコンピュータ・ネットワーク・システムについて説明するための図
【符号の説明】
２…ＡＳＰサーバセンター
４…ユーザオフィス
１２…ＡＳＰサーバセンター内ＬＡＮ
１４…ＷＡＮ
１６…ユーザオフィス内ＬＡＮ
２０…サーバ装置
３０…サーバ側プロキシ装置
４０…クライアント側プロキシ装置
３１，４１…受信部
３２，４２…処理部
３３，４３…送信部
３４，４４…フィンガープリント・キャッシュ
３５，４５…ＵＲＬ・ＦＰテーブル
３２１，４２１…ＦＰ圧縮判定部
３２２，４２２…フィンガープリント・キャッシュ管理部
３２３…ＦＰ圧縮処理部
４２３…ＦＰ解凍処理部
３２４…差分圧縮処理部
４２４…差分解凍処理部
３２５，４２５…ＦＰ圧縮・解凍処理部
３２６，４２６…差分圧縮・解凍処理部
３２７，４２７…ＵＲＬキャッシュ処理部
５０…クライアント装置
Claims (10)
- サーバ装置と、該サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置との通信を中継するデータ転送装置において、
サーバ装置から受信して他のデータ転送装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、
前記サーバ装置がクライアント装置を宛先として送信した第２の完全データを受信する受信手段と、
前記第１の完全データと前記第２の完全データとの差分である差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記差分データが差分データであることを示す第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とするデータ転送装置。 - 前記送信手段は、
前記第２のフィンガープリントが前記第１のフィンガープリントと一致する場合には、前記第２のフィンガープリントと、前記第２のフィンガープリントがフィンガープリントであることを示す第３の識別情報とを前記クライアント装置宛に送信し、
前記第２のフィンガープリントが前記第１のフィンガープリントと一致しない場合には、前記差分データと、前記第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを前記クライアント装置宛に送信することを特徴とする請求項１に記載のデータ転送装置。 - 前記第２のフィンガープリントが第１のフィンガープリントと一致しない場合に、前記第２の完全データから前記差分データを差し引いたデータ量の差が所定の値より大きくなるかどうかを判断する判断手段を更に備え、
前記送信手段は、
前記第２のフィンガープリントが前記第１のフィンガープリントと一致する場合には、前記第２のフィンガープリントと、前記第２のフィンガープリントがフィンガープリントであることを示す第３の識別情報とを前記クライアント装置宛に送信し、
前記第２のフィンガープリントが前記第１のフィンガープリントと一致しない場合であってかつ前記判断手段が前記第２の完全データから前記差分データを差し引いたデータ量の差が所定の値より大きくなると判断した場合には、前記差分データと、前記第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを前記クライアント装置宛に送信し、
前記第２のフィンガープリントが前記第１のフィンガープリントと一致しない場合であってかつ前記判断手段が前記第２の完全データから前記差分データを差し引いたデータ量の差が所定の値より大きくならないと判断した場合には、前記第２の完全データと、前記第２のフィンガープリントと、前記第２の完全データが完全データであることを示す前記第１の識別情報とを対応付けて前記保持手段に保持させるとともに、前記第２の完全データと前記第１の識別情報とを前記クライアント装置宛に送信することを特徴とする請求項１に記載のデータ転送装置。 - サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置と、前記クライアント装置との通信を中継するデータ転送装置において、
他のデータ転送装置から受信してクライアント装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持する保持手段と、
前記クライアント装置が宛先とされた、前記第１の完全データと第２の完全データとの 差分である差分データと、該差分データが差分データであることを示す第２の識別情報とを受信する受信手段と、
前記第１の完全データと前記差分データとを用いて前記第２の完全データを生成し、該差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、該第２の完全データを、前記クライアント装置を宛先として送信する送信手段とを備えたことを特徴とするデータ転送装置。 - 前記送信手段は、
前記受信手段が前記第１の識別情報を受信した場合は、前記第１の識別情報に付随して受信した第３の完全データを前記クライアント装置宛に送信し、
前記受信手段が第３のフィンガープリントと前記第３のフィンガープリントがフィンガープリントであることを示す第３の識別情報とを受信した場合であってかつ、前記第３のフィンガープリントが前記第１のフィンガープリントと一致する場合には、前記第１のフィンガープリントに対応付けられた前記第１の完全データを前記クライアント装置宛に送信し、
前記受信手段が前記第３のフィンガープリントと前記第３の識別情報とを受信した場合であってかつ、前記第３のフィンガープリントが前記第２のフィンガープリントと一致する場合には、前記第１のフィンガープリントに対応付けられた前記第１の完全データと前記第２のフィンガープリントに対応付けられた前記差分データとを用いて生成した前記第２の完全データを前記クライアント装置宛に送信することを特徴とする請求項４に記載のデータ転送装置。 - 前記名前は、前記データに所定のハッシュ関数を適用して得られた値であることを特徴とする請求項１ないし５のいずれか１項に記載のデータ転送装置。
- サーバ装置と、該サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置との通信を中継するデータ転送装置におけるデータ転送方法であって、
サーバ装置から受信して他のデータ転送装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持手段に保持するステップと、
前記サーバ装置がクライアント装置を宛先として送信した第２の完全データを受信するステップと、
前記第１の完全データと前記第２の完全データとの差分である差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記差分データが差分データであることを示す第２の識別情報とを対応付けて前記保持手段に保持させるとともに、前記差分データと前記第２の識別情報とを、前記クライアント装置を宛先として送信するステップとを有することを特徴とするデータ転送装置。 - サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置と、前記クライアント装置との通信を中継するデータ転送装置におけるデータ転送方法であって、
他のデータ転送装置から受信してクライアント装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて保持手段に保持するステップと、
前記クライアント装置が宛先とされた、前記第１の完全データと第２の完全データとの差分である差分データと該差分データが差分データであることを示す第２の識別情報とを受信するステップと、
前記第１の完全データと前記差分データとを用いて前記第２の完全データを生成し、該 差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記保持手段に保持させるとともに、該第２の完全データを、前記クライアント装置を宛先として送信するステップとを有することを特徴とするデータ転送方法。 - サーバ装置と、該サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置との通信を中継するデータ転送装置としてコンピュータを機能させるためのプログラムであって、
サーバ装置から受信して他のデータ転送装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて記憶装置に保持する機能と、
前記サーバ装置がクライアント装置を宛先として送信した第２の完全データを受信する受信機能と、
前記第１の完全データと前記第２の完全データとの差分である差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記差分データが差分データであることを示す第２の識別情報とを対応付けて前記記憶装置に保持させるとともに、前記差分データと前記第２の識別情報とを、前記クライアント装置を宛先として送信する機能とをコンピュータに実現させるためのプログラム。 - サーバ装置がクライアント装置宛に送信するデータを中継する他のデータ転送装置と、前記クライアント装置との通信を中継するデータ転送装置としてコンピュータを機能させるためのプログラムであって、
他のデータ転送装置から受信してクライアント装置へ送信した第１の完全データと、該第１の完全データをもとに生成した第１のフィンガープリントと、前記第１の完全データが完全データであることを示す第１の識別情報とを対応付けて記憶装置に保持する機能と、
前記クライアント装置が宛先とされた、前記第１の完全データと第２の完全データとの差分である差分データと、該差分データが差分データであることを示す第２の識別情報とを受信する機能と、
前記第１の完全データと前記差分データとを用いて前記第２の完全データを生成し、該差分データと、該第２の完全データをもとに生成した第２のフィンガープリントと、前記第２の識別情報とを対応付けて前記記憶装置に保持させるとともに、該第２の完全データを、前記クライアント装置を宛先として送信する機能とをコンピュータに実現させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002149131A JP3848209B2 (ja) | 2002-05-23 | 2002-05-23 | データ転送装置、データ転送方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002149131A JP3848209B2 (ja) | 2002-05-23 | 2002-05-23 | データ転送装置、データ転送方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003345708A JP2003345708A (ja) | 2003-12-05 |
| JP3848209B2 true JP3848209B2 (ja) | 2006-11-22 |
Family
ID=29767399
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002149131A Expired - Fee Related JP3848209B2 (ja) | 2002-05-23 | 2002-05-23 | データ転送装置、データ転送方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3848209B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150099425A (ko) * | 2014-02-12 | 2015-08-31 | 레지피 에스.에이. | 구성 관련 데이터를 검색하기 위한 네트워크 시스템 |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7555531B2 (en) * | 2004-04-15 | 2009-06-30 | Microsoft Corporation | Efficient algorithm and protocol for remote differential compression |
| US9639554B2 (en) | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
| US8321439B2 (en) | 2004-12-17 | 2012-11-27 | Microsoft Corporation | Quick filename lookup using name hash |
| US8606830B2 (en) | 2004-12-17 | 2013-12-10 | Microsoft Corporation | Contiguous file allocation in an extensible file system |
| US7873596B2 (en) | 2006-05-23 | 2011-01-18 | Microsoft Corporation | Extending cluster allocations in an extensible file system |
| JP4587312B2 (ja) * | 2005-09-16 | 2010-11-24 | 株式会社リコー | 符号変換装置及び符号変換方法 |
| JP2007226635A (ja) * | 2006-02-24 | 2007-09-06 | Victor Co Of Japan Ltd | リモートデスクトップシステムのサーバ装置及びクライアント装置 |
| JP4784909B2 (ja) * | 2007-03-13 | 2011-10-05 | 日本電気株式会社 | トランザクションアクセラレータ、通信システム、通信方法及びプログラム |
| JP4766025B2 (ja) * | 2007-10-05 | 2011-09-07 | 日本電気株式会社 | 電子メール送受信システム |
| CN101494658B (zh) | 2008-01-24 | 2013-04-17 | 华为技术有限公司 | 指纹技术的实现方法、装置及系统 |
| JP5131915B2 (ja) * | 2008-03-31 | 2013-01-30 | 国立大学法人 東京大学 | パケット符号化方法および装置ならびに復号方法および装置 |
| JP6378601B2 (ja) * | 2014-10-02 | 2018-08-22 | 日本電信電話株式会社 | コンテンツ解析装置、コンテンツ解析方法、及びプログラム |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5931904A (en) * | 1996-10-11 | 1999-08-03 | At&T Corp. | Method for reducing the delay between the time a data page is requested and the time the data page is displayed |
| JP3313604B2 (ja) * | 1997-02-25 | 2002-08-12 | 中部日本電気ソフトウェア株式会社 | インターネットのホームページ管理システム |
| JP2002055870A (ja) * | 2000-08-15 | 2002-02-20 | Fuji Xerox Co Ltd | データ提供装置、データ取得装置及びデータ処理システム |
-
2002
- 2002-05-23 JP JP2002149131A patent/JP3848209B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150099425A (ko) * | 2014-02-12 | 2015-08-31 | 레지피 에스.에이. | 구성 관련 데이터를 검색하기 위한 네트워크 시스템 |
| KR102344121B1 (ko) * | 2014-02-12 | 2021-12-28 | 레지피 에스.에이. | 구성 관련 데이터를 검색하기 위한 네트워크 시스템 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003345708A (ja) | 2003-12-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3990115B2 (ja) | サーバ側プロキシ装置及びプログラム | |
| US7054912B2 (en) | Data transfer scheme using caching technique for reducing network load | |
| US8024484B2 (en) | Caching signatures | |
| US7383348B2 (en) | Data transfer scheme using caching technique for reducing network load | |
| JP3848209B2 (ja) | データ転送装置、データ転送方法及びプログラム | |
| JP4671332B2 (ja) | ユーザ識別情報を変換するファイルサーバ | |
| US20050027731A1 (en) | Compression dictionaries | |
| JP2013512514A (ja) | キャッシュを利用した効率的なメディア配信のためのシステム及び方法 | |
| US20090049243A1 (en) | Caching Dynamic Content | |
| JP3984086B2 (ja) | キャッシュサーバ、データ転送装置及びプログラム | |
| JP2004310371A (ja) | ファイル共有システム及び方法、ファイル共有サーバ、ファイル共有サービスのクライアント端末、ファイル共有プログラム、ファイル共有プログラムを記録した記録媒体 | |
| JP4031516B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
| JP3983987B2 (ja) | サーバ側プロキシ装置、データ転送方法及びプログラム | |
| JP4053269B2 (ja) | データ転送装置およびデータ転送方法 | |
| US20020107986A1 (en) | Methods and systems for replacing data transmission request expressions | |
| JP3943867B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
| JP3943868B2 (ja) | サーバ側プロキシ、データ転送方法及びプログラム | |
| JP4157585B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム | |
| JP3913508B2 (ja) | データ転送装置およびデータ転送方法 | |
| JP2003108464A (ja) | データ転送装置およびデータ転送方法 | |
| JP4041157B2 (ja) | クライアント側プロキシ装置、データ転送方法及びプログラム | |
| JP3977601B2 (ja) | サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
| JP3977651B2 (ja) | データ転送方法、サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム | |
| JP4300220B2 (ja) | データ転送装置およびデータ転送方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060424 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060516 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060718 |
|
| 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: 20060822 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060824 |
|
| LAPS | Cancellation because of no payment of annual fees |