JP2003108464A - データ転送装置およびデータ転送方法 - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークの負荷を軽減できるプロキシ装
置を提供すること。 【解決手段】 サーバ側プロキシ３０からクライアント
側プロキシ４０へ新たな内容のリプライデータを転送す
るにあたって、サーバ側プロキシ３０で該データを分割
し、両プロキシにて、各分割データと各分割データにハ
ッシュ関数を適用して算出したフィンガープリント（Ｆ
Ｐ）とを対応付けて、ＦＰキャッシュに登録しておく。
ＦＰキャッシュに登録済みのＦＰと一部異なるＦＰを持
つリプライデータを転送するにあたっては、ＦＰが異な
る部分のみ該データを送り、同じ部分は該リプライデー
タの代わりに該ＦＰを転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、他の装置のために
データ転送を行うデータ転送装置およびデータ転送方法
に関する。

【０００２】

【従来の技術】ネットワークを介して様々なサービスを
提供するサーバと、所望のサービスをサーバに対して要
求するクライアントとから構成される、クライアント・
サーバ型の情報システムが広く利用されている。特に、
インターネット上でＨＴＴＰプロトコルを使って通信す
るＷＥＢサーバとクライアントとからなるＷＯＲＬＤＷ
ＩＤＥ ＷＥＢシステム（あるいは単にＷＥＢとも呼ば
れる）は、大変広く利用されているクライアント・サー
バ型の情報システムである。通常、サーバ上ではサーバ
プログラムが動作し、クライアント上ではブラウザなど
の所定のツール（プログラム）が動作する。インターネ
ット上で提供されるサービスの内容も多岐に渡ってお
り、ネットワーク経由で文字、静止画像、動画像、音声
等の情報（例えば、ホームページ、電子メール、デジタ
ルコンテンツなど）や、プログラムなどを提供、配信あ
るいは転送などするサービス、また商品を販売するため
の電子店舗サービス、座席や部屋等の予約サービス、種
々の契約の仲介サービスなど、種々のサービスが既に存
在し、また次々と新たな形態のサービスが出現してい
る。

【０００３】ところで、ＷＥＢのようなクライアント・
サーバ型の情報システムにおいては、提供されるサービ
スがどのような形態のものであろうと、基本的にはクラ
イアント・サーバ間でデータ転送が行われることによっ
てサービスが提供される。したがって、クライアントと
サーバとの間で通信に用いるネットワークの容量（バン
ド幅）が、システム全体のボトルネックになりやすい。
そこで、通常、ネットワークの負荷を軽減させるために
キャッシュ技術が用いられる。

【０００４】ＷＥＢシステムの場合、クライアント上で
動作するブラウザ等はキャッシュ機構を使用するものが
多く、最近アクセスしたデータをキャッシュしている。
ＷＥＢではＵＲＬと呼ばれる名前で情報やサービスを指
定してアクセスがなされるので、クライアント上のキャ
ッシュは、過去にＷＥＢサーバに要求した情報やサービ
スの結果として返されるデータのうちでキャッシュ可能
なものを、そのＵＲＬと対応させてキャッシュに記録し
ている。この場合、キャッシュ内にあるものと同じＵＲ
Ｌの情報やサービスのリクエストがあった際に、そのキ
ャッシュ内の応答データが古くなっていないと判断でき
るならば、そのデータを返すことで、ＷＥＢサーバとの
間の通信を無くすことができる。

【０００５】企業のオフィス内のＬＡＮあるいは研究機
関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数の
ユーザがいる場合、該ＬＡＮとインターネットとの間に
プロキシサーバを置き、プロキシサーバにキャッシュ機
構を設けるようにすることも多い。クライアント内のキ
ャッシュ（例えば、ブラウザのキャッシュ）は、当該ク
ライアント・ユーザに専用のキャッシュとして動作する
が、ＬＡＮ上のプロキシサーバのキャッシュは、複数の
クライアント・ユーザに共有のキャッシュとして動作す
る。そのため、後者では、過去に他人（他クライアン
ト）がアクセスしたＵＲＬに対してアクセスする際にも
キャッシュが効く。

【０００６】さて、ＷＥＢにおいて、クライアントとサ
ーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行わ
れる。ＨＴＴＰプロトコルは、クライアントからサーバ
へ送る「リクエストメッセージ」と、それに答えてサー
バからクライアントへ応答を返す「リプライメッセー
ジ」とが組になっている。

【０００７】リクエストメッセージは、「リクエストヘ
ッダ」と「リクエストボディ」からなる。リクエストヘ
ッダには、アクセスしたい情報やサービスを指定するＵ
ＲＬやアクセスの種類を示すメソッド名、その他アクセ
スに必要な各種の情報が入る。リクエストボディには、
サーバに送るデータを入れる。リクエストボディに入っ
ているデータを「リクエストデータ」とも呼ぶ。

【０００８】リプライメッセージは、「リプライヘッ
ダ」と「リプライボディ」からなる。リプライヘッダに
は、処理結果のステータスなどの情報が入り、リプライ
ボディには要求された情報や要求されたサービスの処理
結果などのデータが入る。リプライボディに入っている
データを「リプライデータ」とも呼ぶ。

【０００９】リクエストメッセージのメソッドとして
は、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユ
ーザの持つデータをサーバに書き込む「ＰＵＴメソッ
ド」、リクエストの応じて処理した結果を送り返しても
らう「ＰＯＳＴメソッド」が、情報やサービスのアクセ
スに用いられる主要なものである。その他、ＤＥＬＥＴ
Ｅなどのメソッドが定義されている。

【００１０】多くの場合、ＧＥＴメソッドのリクエスト
メッセージのリクエストボディ、ＰＵＴメソッドのリプ
ライメッセージのリプライボディは空である。ＰＯＳＴ
メソッドのリクエストメッセージのリクエストボディに
は、必要に応じてサーバ側での処理に用いる情報が入
り、ＰＯＳＴメソッドのリプライメッセージのリプライ
ボディには、その処理の結果のデータが入る。

【００１１】ＧＥＴメソッドでサーバから読み出すデー
タは、読み出す毎にサーバ側で生成する「動的データ」
と、既にサーバ側で記憶しているデータをそのまま送り
返す「静的データ」に分けることができる。これらのう
ち、動的データについては、同じＵＲＬでも読み出す度
に内容が異なる可能性があるので、多くの場合、サーバ
はキャッシュ不可の指定をそのリプライメッセージのヘ
ッダに入れて送り返す。したがって、ＷＥＢのデータで
キャッシュの対象になるのは、静的データの部分であ
る。この静的データは、不特定多数のユーザが参照して
構わない「共有データ」と、ユーザ認証することで特定
のユーザだけがアクセスできるようにアクセス制御を行
う「プライベートデータ」に分けることができる。前者
の共有データは、どのようなキャッシュでもキャッシュ
可能である。しかしながら、後者のプライベートデータ
は、プロキシサーバなどの共有キャッシュでは、キャッ
シュ不可である（プライベートデータは必ずサーバでユ
ーザを認証して送り返す必要があるので）。ただし、ブ
ラウザなどの個人専用のキャッシュの場合には、プライ
ベートデータでもキャッシュは可能である。

【００１２】ＰＯＳＴメソッドは、サーバ側で処理をし
た結果を返すので、一般的にサーバはキャッシュ不可の
指定をリプライメッセージのヘッダに入れて結果を送り
返す。そのため、通常はキャッシュの対象にはならな
い。

【００１３】ＰＵＴメソッドは、データをサーバに送る
ものなので、キャッシュは何も処理をしない。

【００１４】

【発明が解決しようとする課題】従来のＷＥＢのキャッ
シュは、静的コンテンツをキャッシュの対象にしてい
る。かつては、ＷＥＢで公開される情報やサービスに
は、情報の更新頻度がそれほど高くなく、不特定多数の
人に公開されているものが多かったため、静的コンテン
ツの割合は非常に高く、従来のキャッシュ技術でもネッ
トワークの負荷の軽減に有効であった。

【００１５】しかしながら、ＷＥＢベースのＡＳＰ（Ａ
ｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄ
ｅｒ）のように、ユーザがＷＥＢブラウザを使って、ネ
ットワーク経由でサーバ上の情報やサービスにアクセス
するシステムが普及するにつれて、下記のように従来の
キャッシュ技術では対応できないデータが増加してい
る。 ・ユーザの認証を行い、アクセスできるユーザを制限し
ているので、プライベートデータが多い。 ・バックエンドのデータベースを参照して生成する動的
データが多い。 ・帳票処理や検索などＰＯＳＴメソッドを使う場合が多
い。 ・グループ内の情報共有のためにＰＵＴメソッドを使う
場合が多い。

【００１６】この結果、キャッシュ技術のみではネット
ワークの負荷を軽減する手法として有効に機能しなくな
ってきている。

【００１７】ストリームデータのような大容量のコンテ
ンツをキャッシュする場合、全データを基にキャッシュ
すると一部のデータの更新でもキャッシュにヒットしな
くなり、再度全てのコンテンツを送信する必要が生じ
る。このため、大容量コンテンツを比較的小さな複数の
コンテンツに分割し、それぞれ毎にキャッシュすること
により、一部データの変更の場合でも、該当部分を含む
部分コンテンツ以外はキャッシュを効かせて効率的な転
送をすることが望まれる。

【００１８】本発明は、上記事情を考慮してなされたも
ので、データ転送装置間を接続するネットワークの負荷
をより軽減することができるキャッシュ技術・圧縮技術
を備えたデータ転送装置およびデータ転送方法を提供す
ることを目的とする。

【００１９】

【課題を解決するための手段】本発明のデータ転送装置
は、クライアント装置からのリクエストメッセージに応
答し、リクエストされたコンテンツを含むリプライメッ
セージを返信するサーバ装置から該リプライメッセージ
を受信するデータ転送装置であって、該リプライメッセ
ージを受信するリプライ受信手段と、受信した該リプラ
イメッセージに含まれるコンテンツを所定の分割方法に
よって、複数のデータに分割する分割手段と、分割され
たデータを所定方法で圧縮する圧縮手段と、前記分割手
段で分割された各データと、前記圧縮手段で圧縮された
各データとを対応付けて、該リプライメッセージを転送
するためのリプライメッセージとして送信する送信手段
とを備えた。

【００２０】また、クライアント装置からのリクエスト
メッセージに応答し、リクエストされたコンテンツを含
むリプライメッセージを返信するサーバ装置から該リプ
ライメッセージを受信するデータ転送装置であって、該
リプライメッセージを受信するリプライ受信手段と、受
信した該リプライメッセージに含まれるコンテンツを所
定の分割方法によって、複数のデータに分割する分割手
段と、分割されたデータを所定方法で圧縮する圧縮手段
と、圧縮前のデータと圧縮後のデータとを対応付けて、
記憶する記憶手段と、前記圧縮手段で圧縮したデータが
記憶手段に記憶されているか否かを判定する管理手段
と、前記管理手段で前記圧縮手段で圧縮されたデータが
記憶されていると判定された際に、前記分割手段で分割
されたデータを、前記圧縮手段で圧縮されたデータに変
更するよう処理する処理手段と、処理手段で変更された
圧縮されたデータを含むリプライメッセージを送信する
送信手段とを備えた。

【００２１】更に、上記のデータ転送装置から送信され
るリプライメッセージを受信し、クライアント装置対応
のリプライメッセージとしてクライアント装置へ転送す
るデータ転送装置であって、リプライメッセージを受信
する受信手段と、圧縮前のデータと圧縮後のデータとを
対応付けて、記憶する記憶手段と、リプライメッセージ
中の圧縮されたデータを抽出し、該圧縮されたデータ
で、前記記憶手段を検索し、該圧縮されたデータに対応
する圧縮前のデータを読み出す管理手段と、該リプライ
メッセージ中の圧縮されたデータを該管理手段で読み出
された該圧縮前のデータに変更する変更手段と、前記変
更手段で変更されたリプライメッセージを送信する送信
手段とを備えた。

【００２２】本発明によれば、データ転送装置間を接続
するネットワークの負荷をより軽減することができるキ
ャッシュ技術・圧縮技術を備えたデータ転送装置を提供
できる。特に、例えばストリームのような大容量コンテ
ンツを比較的小さな複数のコンテンツに分割し、それぞ
れ毎にキャッシュすることにより、一部データの変更の
場合でも、該当部分を含む部分コンテンツ以外はキャッ
シュを効かせて効率的な転送をすることができる。

【００２３】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。

【００２４】また、装置または方法に係る本発明は、コ
ンピュータに当該発明に相当する手順を実行させるため
の（あるいはコンピュータを当該発明に相当する手段と
して機能させるための、あるいはコンピュータに当該発
明に相当する機能を実現させるための）プログラムとし
ても成立し、該プログラムを記録したコンピュータ読取
り可能な記録媒体としても成立する。

【００２５】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。

【００２６】以下では、ＷＡＮがインターネットであ
り、クライアントはユーザオフィスＬＡＮに接続された
ものであり、ＨＴＴＰプロトコルが使用されるような場
合を例にとって説明するが、もちろん、本発明は、ＷＡ
Ｎがインターネット以外のものであっても、クライアン
トがオフィス以外の例えば家庭内ＬＡＮ等に設置された
ものであっても、ＨＴＴＰプロトコル以外のプロトコル
が使用されるものであっても適用可能である。

【００２７】図１６は、本発明を適用するコンピュータ
・ネットワーク・システムの基本的な構成例を示す。こ
の構成例では、ＡＳＰサーバセンター２内のローカルエ
リアネットワーク（ＬＡＮ）１２と、ユーザオフィス４
内のローカルエリアネットワーク（ＬＡＮ）１６との間
が、インターネットや専用回線などの広域ネットワーク
（ＷＡＮ）１４を介して接続されており、ＡＳＰサーバ
センター２内のサーバ２０と、ユーザオフィス４内のク
ライアント５０とが、ＬＡＮ１２・ＷＡＮ１４・ＬＡＮ
１６を介して通信可能になっている。ＡＳＰサーバセン
ター内ＬＡＮには１または複数のサーバが接続され、ユ
ーザオフィス内ＬＡＮには１または複数のクライアント
が接続される。

【００２８】ＷＥＢベースのＡＳＰは、サーバセンター
２に設置したサーバ２０から、ＷＡＮ１４を介して、様
々なアプリケーションプログラムによるサービスを提供
し、ユーザはオフィス４に設置されたクライアント上の
ＷＥＢブラウザ等を使ってそれらのサービスにアクセス
する。

【００２９】このような利用形態においては、ユーザオ
フィス内ＬＡＮ１６とサーバセンター内ＬＡＮ１２とを
つなぐネットワーク、特にインターネットなどの広域ネ
ットワーク１４の実効的な通信容量（バンド幅）は、サ
ーバセンター内ＬＡＮ１２やユーザオフィス内ＬＡＮ１
６よりも低く、そこが性能上のボトルネックになって通
信遅延が発生し、アプリケーションの応答性能が低下す
るという問題が発生する。

【００３０】そこで、本実施形態では、図１に示すよう
に、サーバセンター内ＬＡＮ１２とユーザオフィス内Ｌ
ＡＮ１６とをつなぐ広域ネットワーク１４の両端に、サ
ーバ側プロキシ３０およびクライアント側プロキシ４０
という２つのモジュールを設置し、それらの間で後述す
るフィンガープリント圧縮（ＦＰ圧縮）を行って通信デ
ータ量を低減することで、広域ネットワークのボトルネ
ックを解消する。

【００３１】本実施形態のサーバ２０、サーバ側プロキ
シ３０、クライアント側プロキシ４０、クライアント５
０は、いずれも、計算機上でソフトウェア（サーバ・プ
ログラム、サーバ側プロキシ・プログラム、クライアン
ト側プロキシ・プログラム、クライアント・プログラ
ム）を動作させる形で実現することができる。この場合
に、必要に応じて計算機所望の機能を有するＯＳやドラ
イバソフト、パケット通信用ソフト、暗号ソフト等とい
ったソフトウェア、あるいは通信インタフェース装置や
外部記憶装置や入出力装置等といったハードウェアが搭
載あるいは接続される。また、この場合に、ユーザある
いは管理者からの情報の入力やユーザへの情報の呈示等
のために、グラフィカル・ユーザ・インタフェース（Ｇ
ＵＩ）を用いると好ましい。

【００３２】サービスを利用するためにユーザが使用す
るクライアント５０上では、その目的に応じて例えばＷ
ＥＢブラウザ等のプログラムが動作する。ユーザは、例
えば、ＷＥＢブラウザからインターネットを介し情報転
送あるいは注文受付等の所望のサービスを提供するサー
バにリクエストメッセージを出し、リプライメッセージ
を受けることによって、またはこれを適宜繰り返すこと
によって、サービスを利用する。もちろん、ＷＥＢブラ
ウザ等の汎用のソフトウェアではなく、特定のサービス
を利用するための専用のソフトウェアなどの他のものが
用いられても構わない。また、クライアントは、汎用の
計算機ではなく、例えばインターネット機能を有する携
帯電話端末等でもよい。

【００３３】サーバ２０上では、所定のサーバ・プログ
ラムが動作し、クライアント２０のユーザに対して、当
該サーバ・サイトに固有のサービスを提供する。

【００３４】サーバ側プロキシ３０は、図１のように、
サーバセンター内ＬＡＮ１２とＷＡＮ１４との両方に接
続し、トランスペアレント・プロキシとして動作するよ
うに設置して実施することができる。また、図２のよう
に、サーバセンター内ＬＡＮ１２上に設置して実施する
こともできる。また、図３のように、サーバ側プロキシ
３０の機能をサーバ２０に内蔵するように実施すること
もできる。

【００３５】同様に、クライアント側プロキシ４０は、
図１のように、ユーザオフィス内ＬＡＮ１６とＷＡＮ１
４との両方に接続し、トランスペアレント・プロキシと
して動作するように設置して実施することができる。ま
た、図２のように、ユーザオフィス内ＬＡＮ１６上に設
置して実施することもできる。また、図３のように、ク
ライアント側プロキシ４０の機能をクライアント５０上
で動作するブラウザ等に内蔵するように実施することも
できる。あるいは、ブラウザ等の動作するクライアント
５０上に、個人用のクライアント側プロキシ４０を動作
させるように実施することもできる。

【００３６】なお、サーバ側プロキシ３０とクライアン
ト側プロキシ４０とは、図１〜図３などのように同じ形
態であってもよいし、異なる形態であってもよい。

【００３７】本実施形態のサーバ側プロキシ３０および
クライアント側プロキシ４０は、いずれも、フィンガー
プリント・キャッシュ（ＦＰキャッシュ）と呼ぶキャッ
シュ機構を持つ。フィンガープリント・キャッシュは、
フィンガープリント（ＦＰ）と呼ぶ名前によって、ＨＴ
ＴＰプロトコルでやりとりされるデータを記録・管理す
る。

【００３８】フィンガープリントは、図４に例示するよ
うに、ＨＴＴＰプロトコルでやり取りされるデータ（図
４の例ではコンテンツ）の内容から、あらかじめ決めら
れた計算方法（図４の例ではハッシュ関数）で決定され
る、短い数値である。この数値は、可変長でもよいが、
処理の容易さの観点では、固定長の数値の方が扱いやす
い。

【００３９】フィンガープリントを計算する方法として
は、良く知られているＭＤ−５やＳＨＡ−１などのハッ
シュ関数を用いることができる。これらのハッシュ関数
は、データに対する電子署名などに使われており、任意
のデータが与えられると、ＭＤ−５の場合は１２８ビッ
トの数値に、ＳＨＡ−１の場合は１６０ビットの数値
に、変換することができる。これらのハッシュ関数の特
徴は、２つのデータＸ１，Ｘ２が与えられ、データＸ１
とデータＸ２とが同じであれば、データＸ１に対して計
算したハッシュ値とデータＸ２に対して計算したハッシ
ュ値とは等しくなるが、異なる２つのデータＡ，Ｂが与
えられた場合には、データＡに対して計算したハッシュ
値とデータＢに対して計算したハッシュ値とは、非常に
高い確率で異なるものになることである（原理上は、異
なる２つのデータＡ，Ｂに対してそれぞれ計算したハッ
シュ値が同じになる場合があるが、その確率は実用上無
視できるくらいに小さい）。

【００４０】図５に示すように、サーバ側プロキシ３０
やクライアント側プロキシ４０の持つフィンガープリン
ト・キャッシュ（図中の６０）は、過去にＨＴＴＰプロ
トコルでやり取りされたデータ本体（図中の６１）を、
そのデータから計算して求めたフィンガープリントの値
（図中の６２）を名前として、記録・管理している。

【００４１】例えばＨＴＴＰプロトコルでサーバ側プロ
キシ３０からクライアント側プロキシ４０へデータを転
送するときに、サーバ側プロキシ３０は、当該データの
フィンガープリントを計算し、そのフィンガープリント
に対応するデータがフィンガープリント・キャッシュに
入っていれば、当該データ（と同じ内容のデータ）は過
去に転送したことがあるので、当該データを転送せず
に、対応するフィンガープリントの値を転送する。フィ
ンガープリントを受け取ったクライアント側プロキシ４
０は、当該フィンガープリントの値に対応するデータを
フィンガープリント・キャッシュから取り出すことで、
転送すべきデータを再現することができる。このような
方式（すなわち、データ圧縮→データ転送→データ解
凍）により、過去に送ったものと同じデータならばフィ
ンガープリントの値を送るだけでよいので、ネットワー
クを流れるデータ量を大幅に削減することができる。も
ちろん、クライアント側プロキシ４０からサーバ側プロ
キシ３０へデータを転送するときも同様である。

【００４２】説明上、サーバ側プロキシ３０とクライア
ント側プロキシ４０との間でのデータ転送にあたり、フ
ィンガープリント・キャッシュを利用してメッセージ・
ボディーのデータをフィンガープリントに置き換えて転
送情報量を圧縮することを、フィンガープリント圧縮
（ＦＰ圧縮）と呼ぶものとする。

【００４３】なお、サーバ側プロキシ３０とクライアン
ト側プロキシ４０との間において、すべてのメッセージ
をＦＰ圧縮を適用する対象（すなわち、フィンガープリ
ント・キャッシュを利用してデータをフィンガープリン
トに置き換えるための処理を行う対象）としてもよい
が、例えばフィンガープリント・キャッシュの効果が期
待できないものなどに対する適用を除外するために、予
め定められた条件を満たすメッセージについては、これ
をＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで
転送する）ようにしてもよい。

【００４４】この場合の予め定められた条件とは、例え
ば、メッセージ・ヘッダに予め定められた情報が記述さ
れていることである。具体的には、例えば、メッセージ
・ヘッダにＧＥＴメソッドを示す情報およびリクエスト
を示す情報が記述されていることである。また、予め定
められた条件の他の例としては、転送されるデータが空
（ｎｕｌｌ）あるいは非常に短いサイズであることであ
る。

【００４５】もちろん、それらの他にも種々のバリエー
ションがある。また、複数の条件を組み合わせて使用す
るようにしてもよい。

【００４６】次に、この実施の形態では、更にリプライ
時のデータを複数のパケットに分割して返信するように
している。そこで、まず図６、図７を参照しながら、サ
ーバ側プロキシ３０からクライアント側プロキシ４０へ
データ転送する際のプロキシ間メッセージ・フォーマッ
トについて説明する。

【００４７】なお、ＦＰ圧縮の適用対象外のメッセージ
は、ＦＰ圧縮については、何もせずにそのままの（ＦＰ
圧縮側（送信側）のプロキシが受信した際の）メッセー
ジ・フォーマットでプロキシ間を転送して構わない。あ
るいは、ＦＰ圧縮側（送信側）のプロキシが、例えばそ
のメッセージ・ヘッダに当該メッセージがＦＰ圧縮の適
用対象外を識別可能とする情報を持つようにして転送す
ることも可能である。

【００４８】さて、サーバ側プロキシ３０からクライア
ント側プロキシ４０へデータ転送する場合、ＦＰ圧縮の
適用対象のメッセージには、データがＦＰ圧縮されてフ
ィンガープリントに置き換えられたメッセージ（圧縮時
のメッセージ）と、ＦＰ圧縮されておらず、データが搭
載されているメッセージ（非圧縮時のメッセージ）とが
ある。

【００４９】非圧縮時のメッセージ・フォーマットは、
メッセージに含まれるデータがフィンガープリントキャ
ッシュに登録されていない場合に使用される。一方、圧
縮時のメッセージ・フォーマットは、メッセージに含ま
れるデータがフィンガープリントキャッシュに登録され
ている場合に使用される。

【００５０】解凍側（受信側）では、非圧縮時のフォー
マットのメッセージを受信したことを契機として、当該
データについてフィンガープリントキャッシュへの登録
を行うことができる。

【００５１】図６は、非圧縮時のリプライメッセージの
フォーマットであり、図７は、圧縮時のリプライメッセ
ージのフォーマットである。

【００５２】図６において、（ａ）は一連のリプライメ
ッセージ中の最初のパケットのフォーマットを示すもの
である。ヘッダ中にはＦＰ情報として、データがＦＰ圧
縮対象であるか否かを示す情報として、例えば、ＦＰ圧
縮適用対象の時“１”で、ＦＰ圧縮適用対象外の時
“０”とする。メッセージボディは、識別情報、ＦＰ
値、最終情報、長さ、データからなる。識別情報は、Ｆ
Ｐ圧縮されたデータかＦＰ非圧縮データかを示し、例え
ば“０”でＦＰ非圧縮データ、“１”でＦＰ圧縮データ
であるとする。ＦＰ値には、フィンガープリントの値が
入る。最終情報には、分割されたメッセージのうちの最
終パケットか否かを示す情報であり、例えば、最終パケ
ットの時“１”、そうでない時“０”とする。長さは、
以下に続くデータの長さを示し、続いてそのデータが保
存される。

【００５３】図６（ｂ）は、最初のパケットと最終パケ
ットを除く中間のパケットのフォーマットを示す図であ
り、ヘッダ部が無く、ボディ部のみである。そのボディ
部は、図６（ａ）のボディ部と同一のフォーマットとな
る。図６（ｃ）は、最終パケットのフォーマットであ
り、中間のパケットと同様、ボディ部のみであり、中間
のパケットと同様のフォーマットである。しかし、図６
（ｂ）とは、最終情報が“１”となって最終パケットで
あることを示す情報が異なっている。これによって最終
パケットであることが識別される。

【００５４】なお、図６において、識別情報、ＦＰ値、
最終情報、長さのそれぞれの順序は規定される必要は無
く、他の順番であっても構わないことは明らかである。

【００５５】図７は、ＦＰ圧縮時のリプライメッセージ
のフォーマットであり、（ａ）は最初の第１パケット
の、（ｂ）は最初と最後を除くパケットの、（ｃ）は最
終パケットのフォーマットを示すものである。ＦＰ圧縮
時のリプライメッセージのフォーマットは、図６に比べ
データの長さとそのデータを示す情報が付いていないこ
とだけが違いであり、その他は同じである。識別情報、
ＦＰ値、最終情報の順序を変えて構わないことも同様に
明らかである。

【００５６】リプライメッセージのヘッダにコンテンツ
の全体サイズがセットされている場合は、受信したメッ
セージの累積サイズを計算することによって、最終パケ
ットを判断することができるため、ボディ部の最終情報
を不要とすることもできる。さらに、個々のパケット内
のデータサイズを固定とすることによって、各パケット
のデータ長を示す長さの情報を不要とすることも可能と
なる。

【００５７】また、全てのコンテンツをＦＰ圧縮対象と
するならば、ヘッダからＦＰ情報をなくすこともでき
る。

【００５８】以下では、サーバ側プロキシ３０からクラ
イアント側プロキシ４０へリプライメッセージを転送す
るときにそのリプライデータをＦＰ圧縮・解凍する場合
を中心に本実施形態について詳しく説明する。

【００５９】図８に本実施形態のリプライメッセージ時
のサーバ側プロキシ３０の構成例を示し、図９に本実施
形態のリプライメッセージ時のクライアント側プロキシ
４０の構成例を示す。なお、図８や図９は、サーバ側プ
ロキシ３０からクライアント側プロキシ４０へデータを
転送する際の構成を中心に示してある。

【００６０】図８に示すようにサーバ側プロキシ30で
は、受信部31でサーバ20から送られたリプライメッセー
ジを受信し、処理部32でメッセージを複数のパケットに
分解して、それぞれのパケットの圧縮処理を行い、送信
部33からクライアント側プロキシに対して送信される。
処理部３２は、リプライメッセージに含まれるデータを
圧縮対象とすべきか否かを判定するためのフィンガープ
リント（ＦＰ）圧縮判定部321、リプライメッセージを
複数のパケットに分解するリプライデータ分割部324、
フィンガープリント(ＦＰ)キャッシュ34に対する検索や
登録などを行うためのフィンガープリントキャッシュ管
理部322、転送メッセージに含まれるデータを対応する
フィンガープリントで置換する等の処理を行うためのフ
ィンガープリント（ＦＰ）圧縮処理部323を含む。

【００６１】図９に示されるように、本クライアント側
プロキシ４０は、ユーザオフィス内ＬＡＮ１６または広
域ネットワーク１４から転送メッセージを受信するため
の処理を行う受信部４１、転送メッセージに含まれるデ
ータに対してＦＰ解凍を施すための処理部４２、ユーザ
オフィス内ＬＡＮ１６または広域ネットワーク１４へ転
送メッセージを送信するための処理を行う送信部４３、
フィンガープリントとそのもととなったデータとを対応
付けて記憶するためのフィンガープリント・キャッシュ
（ＦＰ・キャッシュ）４４を備えている。また、処理部
４２は、転送メッセージに含まれるデータを圧縮対象と
すべきか否かおよび転送メッセージに対するＦＰ圧縮の
有無を判定するためのフィンガープリント（ＦＰ）圧縮
判定部４２１、フィンガープリント・キャッシュ３４に
対する検索や登録などを行うためのフィンガープリント
・キャッシュ（ＦＰキャッシュ）管理部４２２、ＦＰ圧
縮された転送メッセージに含まれるフィンガープリント
から元のデータを解凍するなどの処理を行うためのフィ
ンガープリント（ＦＰ）解凍処理部４２３を含む。

【００６２】なお、圧縮側のＦＰ圧縮判定部３２１と解
凍側のＦＰ圧縮判定部４２１は、前述したようにメッセ
ージが予め定められた条件を満たすか否かを調べること
によって、そのメッセージに含まれるデータをＦＰ圧縮
の適用対象とするか否かを判断する（すべてのメッセー
ジをＦＰ圧縮の適用対象にする場合には、圧縮側のＦＰ
圧縮判定部３２１および後に示す手順例の該当部分は不
要であり、解凍側のＦＰ圧縮判定部４２１の該当判断の
部分および後に示す手順例の該当部分は不要である）。
また、解凍側のＦＰ圧縮判定部４２１は、ＦＰ圧縮の適
用対象のメッセージについて、そのデータがＦＰ圧縮さ
れたものか否かを判定する。

【００６３】以下では、ＦＰ圧縮の適用対象となるメッ
セージを転送する場合（ＦＰ圧縮の適用対象とすると判
断された場合、またはすべてのメッセージをＦＰ圧縮の
適用対象にする場合）を中心に説明する。

【００６４】図１０は、サーバ２０からリプライデータ
を受信したときのサーバ側プロキシ３０の処理の流れを
示す。サーバ側プロキシ３０の受信部３１にてサーバ２
０からのリプライメッセージを受信する（S1301）。こ
のとき、リプライメッセージとして、ヘッダ情報を受信
した後、ボディサイズを一定サイズまで受信する、もし
くは一定時間だけ受信する、さらにもしくは最後まで受
信する、といったような条件で部分的なリプライデータ
を受信する。ＦＰ圧縮判定部321では、リプライメッセ
ージがＦＰ圧縮対象のメッセージか否か判断する（S130
2）。ＦＰ圧縮対象外の時は、ヘッダのＦＰ情報にＦＰ
圧縮対象外であることを示す“０”をセットし、そのま
ま要求元クライアント側プロキシへ送信部33を経由して
データを転送する（S1314）。以降に続くリプライメッ
セージがある場合も、受信したメッセージをそのまま、
要求元クライアント側プロキシへデータを転送する（S1
315）。

【００６５】ＦＰ圧縮対象の時は、ヘッダのＦＰ情報に
ＦＰ圧縮対象であることを示す“１”をセットし、リプ
ライデータ分割部324で、最後までリプライメッセージ
を受信完了しているか判断し(S1303)、最後まで受信済
みの場合は最終情報を“１”（S1305）に、最後まで受
信完了していない時は最終情報を“０”にする（S130
4）。次にＦＰキャッシュ管理部322にて、該リプライデ
ータのフィンガープリントの値を計算し（S1306）、該
フィンガープリントの値をキーとしてフィンガープリン
トキャッシュ34を検索する（S1307）。

【００６６】そして、該フィンガープリントの値とこれ
に対応するデータとの組がフィンガープリント・キャッ
シュ34に登録されていたならば（S1308）、ＦＰ圧縮処
理部323にて、受信したリプライメッセージを、該フィ
ンガープリントの値を用いてＦＰ圧縮時のフォーマット
にして（例えば図７(a)等）、送信部33から、クライア
ント側プロキシへ送信する（S1309）。このとき、必要
に応じてリプライヘッダ内のデータ長を表すフィールド
（Content-Length:フィールド）の値を、ＦＰ圧縮時の
フォーマットに合わせて設定する。

【００６７】一方、ステップS1307の検索の結果、該フ
ィンガープリントの値とこれに対応するデータとの組が
フィンガープリントキャッシュ34に登録されていなかっ
たならば（S1308）,次の2つの処理を行う。 （１）ＦＰ圧縮処理部323にて、受信したリプライメッ
セージを、（必要に応じて該フィンガープリントの値を
用いて）非ＦＰ圧縮時のフォーマットにして（例えば、
図６(a)等）、送信部33から、クライアント側プロキシ4
0へ送信する（S1310）。 （２）ＦＰキャッシュ管理部322にて、該フィンガープ
リントの値と、該リプライデータとを対応付けて（フィ
ンガープリントの値をキーにして）、フィンガープリン
ト・キャッシュ34に登録する(S1311)。

【００６８】なお、上記、(1)と(2)は、いずれを先にや
っても良いし、並行してやっても良い。

【００６９】クライアント側プロキシへの送信完了後、
リプライデータ分割部324にて、最後までリプライメッ
セージを受信済みかを判定し(S1312)、最後まで受信完
了している場合は処理を終了する。しかし、まだ最後ま
でリプライメッセージを受信完了していない場合は、さ
らに次のリプライメッセージを受信する(S1313)。この
とき、リプライメッセージとして、ボディサイズを一定
サイズまで受信する、もしくは一定時間だけ受信する、
さらにもしくは最後まで受信する、といったような条件
で部分的なリプライデータを受信する。そして、受信し
たリプライメッセージが最後まで受信できたかをか判断
する（S1303）。

【００７０】以降は、最初のリプライメッセージを受信
した時と同じ処理を繰り返すが、クライアント側プロキ
シに対して転送する際のメッセージフォーマットが異な
る。即ち、第2パケット以降には、ヘッダ情報がつかな
いため、ＦＰ圧縮時のフォーマットは、例えば図７(b)
や(C)となり、ＦＰ非圧縮時のフォーマットは、例えば
図6(b)や(C)となる。最終パケットの場合は、図７(c)か
図6(c)となる。

【００７１】次に、図１１にクライアント側プロキシ４
０の処理の流れを示す。

【００７２】クライアント側プロキシ40は、受信部41に
より、サーバ側プロキシ30からリプライメッセージを受
信する（S1401）。

【００７３】ＦＰ圧縮判定部421は、該リプライメッセ
ージのリプライデータがＦＰ圧縮対象のものであるか否
かヘッダのＦＰ情報を参照し判断する(S1402)。リプラ
イデータのＦＰ情報によりＦＰ圧縮対象外のものと判断
されたならば（S1402）、受信したリプライメッセージ
を送信部43からクライアント50へ転送する(S1412)。以
降に続くリプライメッセージがある場合も、受信したメ
ッセージをそのまま、要求元のクライアント５０へ転送
する（S1413）。

【００７４】ステップS1402にて該リプライメッセージ
のリプライデータがヘッダのＦＰ情報を参照して、ＦＰ
圧縮対象のものであると判断されたならば、ＦＰ圧縮判
定部421は、さらに、リプライデータがＦＰ圧縮されて
いるか否か識別情報を参照して判断する（S1403）。

【００７５】ステップS1403にて該リプライメッセージ
のリプライデータがＦＰ圧縮されているものと判断され
たならば（例えば図7（a）等の場合）、ＦＰキャッシュ
管理部422にて、該リプライデータのフィンガープリン
トの値を求め（S140４）、該フィンガープリントの値を
キーとしてフィンガープリント・キャッシュ４４を検索
する（S140５）。

【００７６】そして、ＦＰ解凍処理部４２３にて、受信
リプライメッセージに対して、フィンガープリント・キ
ャッシュ３４から検索された該フィンガープリントの値
に対応するデータを付加し、プロキシ間で特別の情報を
使用する場合には該情報を削除した後に、これを送信部
４３からクライアント５０へ送信する（S1406）。この
とき、必要に応じて、リプライヘッダ内のデータ長を表
すフィールド（Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈ：フィー
ルド）の値を、該フィンガープリントの値に対応するデ
ータの長さに設定する。

【００７７】一方、ステップS140３にて該リプライメッ
セージのリプライデータがＦＰ圧縮されていないものと
判断されたならば（例えば図6（ａ）等の場合）、次の
２つの作業を行う。 （１）ＦＰ解凍処理部４２３にて、プロキシ間で特別の
情報を使用する場合には受信リプライメッセージから該
情報を削除した後に、これを送信部４３からクライアン
ト５０へ送信する（S1408） （２）ＦＰキャッシュ管理部４２２にて、該リプライデ
ータのフィンガープリントの値を求め（S1407）、該フ
ィンガープリントの値と、該リプライデータとを対応付
けて（フィンガープリントの値をキーにして）、フィン
ガープリント・キャッシュ３４に登録する（S140９）。

【００７８】なお、上記の（１）と（２）は、いずれを
先に行ってもよいし、並行して行ってもよい。

【００７９】クライアントへの送信完了後、リプライデ
ータに付加されている最終情報を参照して、１回のリク
エストに対する全てのリプライメッセージを転送したか
否か判定する（S1410）。最後まで受信完了している場
合は処理を終了する。しかし、まだ最後までリプライメ
ッセージを受信完了していない場合は、さらに次のリプ
ライメッセージを受信し(S1411)、リプライメッセージ
がＦＰ圧縮されているか判断する（S1403）。以降は、
最初のリプライメッセージを受信した時と同じ処理を繰
り返す。但し、サーバ側プロキシから受信するリプライ
メッセージのメッセージフォーマットが異なる。即ち、
第2パケット以降には、ヘッダ情報がつかないため、Ｆ
Ｐ圧縮時のフォーマットは、例えば図７(b)や(C)とな
り、ＦＰ非圧縮時のフォーマットは、例えば図6(b)や
(C)である。最終パケットの場合は、図７(c)か図6(c)と
なる。

【００８０】ところで、ステップS140４では、メッセー
ジにフィンガープリントが記述されている。しかし、ス
テップS140７では、メッセージにフィンガープリントが
記述されている場合に、該メッセージからフィンガープ
リントを得る方法と、メッセージにフィンガープリント
が記述されてない場合に、リプライデータをもとにハッ
シュ関数等によってフィンガープリントの値を計算する
方法とがある。なお、メッセージにフィンガープリント
が記述されている場合であっても、リプライデータをも
とにフィンガープリントの値を計算する方法も可能であ
る。また、ステップS140４／ステップS140７は、ステッ
プS140２とステップS140３の間にて行うようにしても構
わないし、ステップS140７は、ステップS140８とステッ
プS140９の間にて行うようにしても構わない。

【００８１】また、ステップS1402の判断とステップS14
03の判断は、同時に行ってもよい。

【００８２】なお、クライアント側プロキシ４０からサ
ーバ側プロキシ３０へリクエストメッセージを転送する
際にはフィンガープリント・キャッシュを用いないもの
とする場合には、サーバ側プロキシ３０は、図１２に例
示するように、クライアント側プロキシ４０からリクエ
ストメッセージを受信し（ステップＳ２１）、これをサ
ーバ２０へ送信する（ステップＳ２２）、という手順で
構わない。同様に、クライアント側プロキシ４０は、図
１３に例示するように、クライアント５０からリクエス
トメッセージを受信し（ステップＳ２３）、これをサー
バ側プロキシ３０へ送信する（ステップＳ２４）、とい
う手順で構わない。

【００８３】図１４、１５の説明においては、一回のサ
ーバからのリプライメッセージを、サーバ側プロキシに
て複数のパケットに分けてクライアント側プロキシへ返
信するところが異なる。即ち、サーバからのリプライメ
ッセージを3つのパケットに分割して送信する場合は、図
１４の段階では、ＦＰ圧縮されていないため、最初のパ
ケットは図６(a)のフォーマットで送られ、クライアン
ト側でそれを保存しながらクライアントへデータを転送
する。2パケット目は、図６(b)のフォーマットで、最後
の第3パケットは図６(C)のフォーマットでクライアント
側プロキシに送られ、そこでデータとＦＰを保存しなが
らクライアントへ転送する。

【００８４】図１５の段階においては、ＦＰ圧縮される
ので、最初のパケットは図７(a)のフォーマットで、第2
のパケットは図7(b)のフォーマットで、最後の第3パケ
ットは図7(C)のフォーマットでクライアント側プロキシ
に送られる。クライアント側プロキシでは、それぞれの
パケットに付加されたＦＰの値に対応するデータをＦＰ
キャッシュを参照して求めて、それをそれぞれクライア
ントへ転送することとなる。

【００８５】以下では、図１４（登録時すなわち非ＦＰ
圧縮時）および図１５（ＦＰ圧縮時）を参照しながら、
フィンガープリント・キャッシュを利用したデータ転送
についてより具体的に説明する。

【００８６】まず、図１４を参照しながら、サーバ側プ
ロキシ３０からクライアント側プロキシ４０へ、フィン
ガープリント・キャッシュ登録されていないデータを転
送するとともに、フィンガープリント・キャッシュ登録
する場合の動作について説明する。

【００８７】（１）クライアント５０上のブラウザ等
は、例えば“／Ａ．ｃｇｉ”というＵＲＬでサーバ２０
に、ＰＯＳＴメソッドのリクエストメッセージを出した
とする。サーバ２０へのリクエストメッセージは、ま
ず、クライアント側プロキシ４０に送られるように、ブ
ラウザ等を設定しておく。

【００８８】（２）クライアント５０からリクエストメ
ッセージを受け取ったクライアント側プロキシ４０は、
そのリクエストメッセージをサーバ側プロキシ３０に転
送する。

【００８９】（３）リクエストメッセージを受け取った
サーバ側プロキシ３０は、そのリクエストメッセージを
サーバ５０へ転送する。

【００９０】（４）サーバ２０は、該リクエストメッセ
ージに対する処理を行った後、サーバ側プロキシ３０
に、そのリプライメッセージを送り返す。

【００９１】（５）リプライメッセージを受け取ったサ
ーバ側プロキシ３０は、まず、受信リプライメッセージ
の持つリプライデータを分割する。まず、分割された最
初のデータのフィンガープリントを計算し、そのフィン
ガープリント名を持ったデータがフィンガープリント・
キャッシュ３４に入っているかどうかを調べる。入って
いなければ、初めてのデータ（一旦フィンガープリント
・キャッシュ登録されたものがその後に削除あるいは無
効化されることがある構成の場合に、一旦フィンガープ
リント・キャッシュ登録されたが削除あるいは無効化さ
れ、その後において初めてである場合を含む）であるの
で、そのデータをフィンガープリントを名前としてフィ
ンガープリント・キャッシュ３４に入れる（登録す
る）。次に、分割された２番目のデータの・・・。これ
を分割数だけ繰り返す。

【００９２】（６）サーバ側プロキシ３０は、リプライ
メッセージをクライアント側プロキシ４０に順次転送す
る。

【００９３】なお、前述したように、各データから計算
した各フィンガープリントの値を、図６のように各リプ
ライメッセージに入れて送ると、クライアント側プロキ
シ４０で再度フィンガープリントを計算する手間を省く
ことが出来る。

【００９４】（７）リプライメッセージを順次受け取っ
たクライアント側プロキシ４０は、それぞれが初めての
データであるので、各リプライデータをフィンガープリ
ント・キャッシュ４４に順次登録する。

【００９５】なお、前述したように、各リプライデータ
からフィンガープリントを計算するか、あるいはサーバ
側プロキシ３０がリプライヘッダ等に入れたフィンガー
プリントを取り出し、これを名前として入れる。

【００９６】（８）クライアント側プロキシ４０は、
（リプライヘッダ等にフィンガープリントの値などのサ
ーバ側プロキシ３０とクライアント側プロキシ４０との
間だけで使用される情報が存在する構成の場合には、こ
れを削除した後に、）リプライメッセージを、クライア
ント５０（上で動作するブラウザ等）へ送り返す。

【００９７】なお、サーバ側プロキシ３０において、上
記の（５）のフィンガープリント・キャッシュ登録は、
（６）の動作の後に行っても構わない。また、クライア
ント側プロキシ４０において、（７）のフィンガープリ
ント・キャッシュ登録は、（８）の動作の後に行っても
構わない。

【００９８】次に、図１５を参照しながら、図１４の動
作が行われてキャッシュ登録されているデータを、サー
バ側プロキシ３０からクライアント側プロキシ４０へ転
送する場合の動作について説明する。

【００９９】（１）〜（４）は、図１４を参照して説明
した動作における（１）〜（４）と同様である。

【０１００】（５）サーバ５０からリプライメッセージ
を受け取ったサーバ側プロキシ４０は、まず、受信リプ
ライメッセージを分割する。分割した最初のリプライデ
ータのフィンガープリントを計算し、そのフィンガープ
リント名を持ったデータがフィンガープリント・キャッ
シュ３４に入っているかどうかを調べる。入っていれ
ば、過去に送ったことのあるデータ（フィンガープリン
ト・キャッシュ登録されているデータ）なので、リプラ
イボディのデータをフィンガープリントで置き換える。
また、この図の例においては、３つに分割され、分割し
た２番目のリプライデータ（の一部）がサーバ２０上で
変更されていることを示している。従って、２番目のデ
ータは、初めてのデータであるので、そのデータをフィ
ンガープリントを名前としてフィンガープリント・キャ
ッシュ３４に入れる（登録する）。３番目（最終）リプ
ライデータは、最初のリプライデータと同様である。

【０１０１】（６）サーバ側プロキシ３０は、まず、分
割した最初のリプライデータをフィンガープリントで置
き換えたリプライメッセージをクライアント側プロキシ
４０に転送する。次に、分割した２番目のリプライデー
タのみ、ここでは変更されていると仮定しているので、
２番目のリプライデータのみ、図１４の（６）と同様、
リプライデータを備えたリプライメッセージをクライア
ント側プロキシ４０に転送する。分割した３番目のリプ
ライデータは最初のリプライデータと同様に処理され
る。

【０１０２】（７）リプライメッセージを受け取ったク
ライアント側プロキシ４０は、最初および最終（３番
目）のリプライデータがフィンガープリントで置き換え
られていることを検出し、指定されたフィンガープリン
トを使ってフィンガープリント・キャッシュ４４から対
応するデータを取り出し、これをリプライボディに入れ
る。なお、２番目のリプライデータは、図１４の（７）
と同様の処理を行う。

【０１０３】（８）そして、クライアント側プロキシ３
０は、（フィンガープリントの値などのサーバ側プロキ
シ３０とクライアント側プロキシ４０との間だけで使用
される情報が存在する構成の場合には、これを削除した
後に、）リプライメッセージを、クライアント（上で動
作するブラウザ等）へ送り返す。

【０１０４】以上説明してきた本実施の形態において
は、サーバ側プロキシとクライアント側プロキシとの間
で、リプライデータとそれら名前との対応を保持し、こ
れらの対応を保持しているリプライデータについては、
リプライデータを転送する代わりに対応する名前を転送
することで、データ転送装置間の転送データ量を削減す
ることができる。そして、特に大きなリプライデータを
扱う場合には、そのリプライデータを分割し、分割した
各データとそれら名前との対応を保持しておき、その後
そのリプライデータの一部のみ変更が行われた場合に
は、その変更箇所を含む一部のリプライデータのみ通常
のデータを送付し、データと名前の対応を保持している
データについては、データを転送する代わりに対応する
名前を転送することができるので、全てのデータを送リ
直すことに比べ、データ転送装置間の転送データ量を大
幅に削減することができる。

【０１０５】なお、これまでは１つのサーバ側プロキシ
と１つのクライアント側プロキシとの間の１対１の通信
に着目して説明してきたが、本発明の適用範囲はもちろ
んサーバ側プロキシとクライアント側プロキシとが１対
１で通信するシステムには限定されるものではなく、サ
ーバ側プロキシとクライアント側プロキシとが１対多で
通信するシステム、サーバ側プロキシとクライアント側
プロキシとが多対１で通信するシステム、あるいはサー
バ側プロキシとクライアント側プロキシとが多対多で通
信するシステムにも適用可能である。

【０１０６】なお、以上の各機能は、ソフトウェアとし
て実現可能である。

【０１０７】また、本実施形態は、コンピュータに所定
の手段を実行させるための（あるいはコンピュータを所
定の手段として機能させるための、あるいはコンピュー
タに所定の機能を実現させるための）プログラムとして
実施することもでき、該プログラムを記録したコンピュ
ータ読取り可能な記録媒体として実施することもでき
る。

【０１０８】なお、この発明の実施の形態で例示した構
成は一例であって、それ以外の構成を排除する趣旨のも
のではなく、例示した構成の一部を他のもので置き換え
たり、例示した構成の一部を省いたり、例示した構成に
別の機能あるいは要素を付加したり、それらを組み合わ
せたりすることなどによって得られる別の構成も可能で
ある。また、例示した構成と論理的に等価な別の構成、
例示した構成と論理的に等価な部分を含む別の構成、例
示した構成の要部と論理的に等価な別の構成なども可能
である。また、例示した構成と同一もしくは類似の目的
を達成する別の構成、例示した構成と同一もしくは類似
の効果を奏する別の構成なども可能である。

【０１０９】また、この発明の実施の形態で例示した各
種構成部分についての各種バリエーションは、適宜組み
合わせて実施することが可能である。

【０１１０】また、この発明の実施の形態は、個別装置
としての発明、関連を持つ２以上の装置についての発
明、システム全体としての発明、個別装置内部の構成部
分についての発明、またはそれらに対応する方法の発明
等、種々の観点、段階、概念またはカテゴリに係る発明
を包含・内在するものである。

【０１１１】従って、この発明の実施の形態に開示した
内容からは、例示した構成に限定されることなく発明を
抽出することができるものである。

【０１１２】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。

【０１１３】

【発明の効果】本発明によれば、大きなデータを扱う場
合のあるデータ転送装置間で、大きなデータはそれを分
割し、分割した各データとそれら名前との対応を保持
し、これらの対応を保持しているデータについては、デ
ータを転送するの代わりに対応する名前を転送すること
で、データ転送装置間の転送データ量を削減することが
できる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るコンピュータ・ネッ
トワーク・システムの構成例を示す図

【図２】同実施形態に係るコンピュータ・ネットワーク
・システムの他の構成例を示す図

【図３】同実施形態に係るコンピュータ・ネットワーク
・システムのさらに他の構成例を示す図

【図４】同実施形態で使用するフィンガープリントにつ
いて説明するための図

【図５】同実施形態で使用するフィンガープリント・キ
ャッシュについて説明するための図

【図６】同実施形態で使用するＦＰ非圧縮時のメッセー
ジ・フォーマットの一例を示す図

【図７】同実施形態で使用するＦＰ圧縮時のメッセージ
・フォーマットの他の例を示す図

【図８】同実施形態に係るサーバ側プロキシの構成例を
示す図

【図９】同実施形態に係るクライアント側プロキシの構
成例を示す図

【図１０】同実施形態に係るサーバ側プロキシの手順例
を示すフローチャート

【図１１】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図１２】同実施形態に係るサーバ側プロキシの手順例
を示すフローチャート

【図１３】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図１４】同実施形態に係るサーバ側プロキシとクライ
アント側プロキシとの間のデータ転送について説明する
ための図

【図１５】同実施形態に係るサーバ側プロキシとクライ
アント側プロキシとの間のデータ転送について説明する
ための図

【図１６】従来のコンピュータ・ネットワーク・システ
ムについて説明するための図

【符号の説明】

２…ＡＳＰサーバセンター ４…ユーザオフィス １２…ＡＳＰサーバセンター内ＬＡＮ １４…ＷＡＮ １６…ユーザオフィス内ＬＡＮ ２０…サーバ装置 ３０…サーバ側プロキシ装置 ４０…クライアント側プロキシ装置 ５０…クライアント装置 ３１，４１…受信部 ３２，４２…処理部 ３３，４３…送信部 ３４，４４…フィンガープリント・キャッシュ ３５，４５…ＵＲＬ・ＦＰテーブル ３２１，４２１…ＦＰ圧縮判定部 ３２２，４２２…フィンガープリント・キャッシュ管理
部 ３２３…ＦＰ圧縮処理部 ４２３…ＦＰ解凍処理部 ３２４…リプライデータ分割部 ３２５，４２５…ＦＰ解凍・解凍処理部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 吉田 英樹 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 關 俊文 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 吉井 謙一郎 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 宮澤 隆幸 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 木村 康浩 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 外山 春彦 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B082 GA01 HA02 HA05 HA08

Claims (6)

【特許請求の範囲】
1. 【請求項１】 クライアント装置からのリクエストメッ
   セージに応答し、リクエストされたコンテンツを含むリ
   プライメッセージを返信するサーバ装置から該リプライ
   メッセージを受信するデータ転送装置であって、 該リプライメッセージを受信するリプライ受信手段と、 受信した該リプライメッセージに含まれるコンテンツを
   所定の分割方法によって、複数のデータに分割する分割
   手段と、 分割されたデータを所定方法で圧縮する圧縮手段と、 前記分割手段で分割された各データと、前記圧縮手段で
   圧縮された各データとを対応付けて、該リプライメッセ
   ージを転送するためのリプライメッセージとして送信す
   る送信手段とを備えたことを特徴とするデータ転送装
   置。
2. 【請求項２】 クライアント装置からのリクエストメッ
   セージに応答し、リクエストされたコンテンツを含むリ
   プライメッセージを返信するサーバ装置から該リプライ
   メッセージを受信するデータ転送装置であって、 該リプライメッセージを受信するリプライ受信手段と、 受信した該リプライメッセージに含まれるコンテンツを
   所定の分割方法によって、複数のデータに分割する分割
   手段と、 分割されたデータを所定方法で圧縮する圧縮手段と、 圧縮前のデータと圧縮後のデータとを対応付けて、記憶
   する記憶手段と、 前記圧縮手段で圧縮したデータが記憶手段に記憶されて
   いるか否かを判定する管理手段と、 前記管理手段で前記圧縮手段で圧縮されたデータが記憶
   されていると判定された際に、前記分割手段で分割され
   たデータを、前記圧縮手段で圧縮されたデータに変更す
   るよう処理する処理手段と、 前記処理手段で変更された圧縮されたデータを含むリプ
   ライメッセージを送信する送信手段とを備えたことを特
   徴とするデータ転送装置。
3. 【請求項３】 請求項２記載のデータ転送装置から送信
   されるリプライメッセージを受信し、クライアント装置
   対応のリプライメッセージとしてクライアント装置へ転
   送するデータ転送装置であって、 リプライメッセージを受信する受信手段と、 圧縮前のデータと圧縮後のデータとを対応付けて、記憶
   する記憶手段と、 リプライメッセージ中の圧縮されたデータを抽出し、該
   圧縮されたデータで、前記記憶手段を検索し、該圧縮さ
   れたデータに対応する圧縮前のデータを読み出す管理手
   段と、 該リプライメッセージ中の圧縮されたデータを該管理手
   段で読み出された該圧縮前のデータに変更する変更手段
   と前記変更手段で変更されたリプライメッセージを送信
   する送信手段とを備えたことを特徴とするデータ転送装
   置。
4. 【請求項４】 クライアント装置からのリクエストメッ
   セージに応答し、リクエストされたコンテンツを含むリ
   プライメッセージを返信するサーバ装置から該リプライ
   メッセージを受信するデータ転送装置のデータ転送方法
   であって、 該リプライメッセージを受信し、 この受信した該リプライメッセージに含まれるコンテン
   ツを所定の分割方法によって、複数のデータに分割し、 この分割されたデータを所定方法で圧縮し、 前記分割された各データと、前記圧縮された各データと
   を対応付けて、該リプライメッセージを転送するための
   リプライメッセージとして送信することを特徴とするデ
   ータ転送方法。
5. 【請求項５】 クライアント装置からのリクエストメッ
   セージに応答し、リクエストされたコンテンツを含むリ
   プライメッセージを返信するサーバ装置から該リプライ
   メッセージを受信するデータ転送装置のデータ転送方法
   であって、 該リプライメッセージを受信し、この受信した該リプラ
   イメッセージに含まれるコンテンツを所定の分割方法に
   よって、複数のデータに分割し、この分割されたデータ
   を所定方法で圧縮し、圧縮前のデータと圧縮後のデータ
   とを対応付けて記憶部へ記憶し、該圧縮されたデータが
   記憶部に記憶されているか否かを判定し、該圧縮された
   データが記憶部に記憶されていると判定された際に、前
   記分割されたデータを、前記圧縮されたデータに変更
   し、変更されたリプライメッセージを送信することを特
   徴とするデータ転送方法。
6. 【請求項６】 請求項２記載のデータ転送装置から送信
   されるリプライメッセージを受信し、クライアント装置
   対応のリプライメッセージとしてクライアント装置へ転
   送するデータ転送装置のデータ転送方法であって、 リプライメッセージを受信し、圧縮前のデータと圧縮後
   のデータとを対応付けて、記憶部へ記憶し、リプライメ
   ッセージ中の圧縮されたデータを抽出し、該圧縮された
   データで、前記記憶部を検索し、該圧縮されたデータに
   対応する圧縮前のデータを読み出し、該リプライメッセ
   ージ中の圧縮されたデータを読み出された該圧縮前のデ
   ータに変更し、この変更されたリプライメッセージを送
   信するようにしたことを特徴とするデータ転送方法。