JP4300220B2

JP4300220B2 - データ転送装置およびデータ転送方法

Info

Publication number: JP4300220B2
Application number: JP2006121214A
Authority: JP
Inventors: 英昭佐藤; 達徳金井; 英樹吉田; 俊文關; 謙一郎吉井; 隆幸宮澤; 康浩木村; 春彦外山
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2006-04-25
Filing date: 2006-04-25
Publication date: 2009-07-22
Anticipated expiration: 2021-09-27
Also published as: JP2006216081A

Description

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

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

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

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

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

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

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

リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。

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

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

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

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

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

ＰＵＴメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない
。
特開平１１−０２５０１０号公報

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

しかしながら、ＷＥＢベースのＡＳＰ（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅＰ
ｒｏｖｉｄｅｒ）のように、ユーザがＷＥＢブラウザを使って、ネットワーク経由でサー
バ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来の
キャッシュ技術では対応できないデータが増加している。

・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデー
タが多い。

・バックエンドのデータベースを参照して生成する動的データが多い。
・帳票処理や検索などＰＯＳＴメソッドを使う場合が多い。

・グループ内の情報共有のためにＰＵＴメソッドを使う場合が多い。

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

上記課題を解決するために本発明のデータ転送装置は、第１の装置と第２の装置との通信を中継するデータ転送装置において、キャッシュデータと、該キャッシュデータの識別情報であるキャッシュ識別情報とを関連付けて記憶する識別情報キャッシュを行う識別情報キャッシュ手段と、第２の装置への所望データの送信要求を示し、リクエストヘッダを有するリクエストメッセージを、第１の装置から受信するリクエスト受信手段と、リクエストヘッダを解析し、識別情報キャッシュを行う識別情報キャッシュ装置をリクエストメッセージが経由してきたか否かを解析する解析手段と、リクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを示す経由情報を保持する保持手段と、リクエストメッセージを第２の装置へ送信するリクエスト送信手段と、リクエストメッセージに対応しリプライヘッダとリプライボディとを有するリプライメッセージを、第２の装置から受信するリプライ受信手段と、保持手段に保持された経由情報に基づいて、リプライメッセージに対応するリクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを判定する判定手段と、リプライメッセージに対応するリクエストメッセージが識別情報キャッシュ装置を経由してきたと判定された場合はリプライメッセージに対応するリプライボディ識別情報を求め、さらにキャッシュ識別情報のなかに求められたリプライボディ識別情報がある場合に、リプライヘッダに、リプライメッセージをキャッシュすべきでないことを示すＮｏ−ｃｈａｃｈｅ情報を与えるＮｏ−ｃｈａｃｈｅ情報付加手段と、リプライメッセージに対応するリクエストメッセージが識別情報キャッシュ装置を経由してきたと判定された場合はＮｏ−ｃｈａｃｈｅ情報が与えられたリプライヘッダを有するリプライメッセージであって前記Ｎｏ−ｃｈａｃｈｅ情報付加手段から受信したリプライメッセージのリプライボディを前記リプライボディ識別情報に変更し、変更されたリプライメッセージを第１の装置へ送信し、リプライメッセージに対応するリクエストメッセージが識別情報キャッシュ装置を経由しなかったと判定された場合はそのままリプライメッセージを第1の装置へ送信するリプライ送信手段とを備える。

これにより、リクエストメッセージに対応するリプライメッセージに、リクエストメッ
セージにおいて付加される情報を反映することができるようになった。

特に、システム構成等の問題点などが解消できるようになった。

また、誤動作することなく、複数のデータ転送装置間を接続するネットワークの負荷を
より軽減することができるキャッシュ技術・圧縮技術を備えることができる。

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

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

本発明によれば、データ転送装置間でデータとその名前との対応を保持し、この対応を
保持しているデータについては、データを転送する代わりに対応する名前を転送すること
で、データ転送装置間の転送データ量を削減することができる。

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

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

図１は、本発明を適用するコンピュータ・ネットワーク・システムの全体構成例を示す
ものであり、特にここでは様々なネッワーク形態があることを示すためにそれぞれ異なる
ネットワーク形態を備える３つの会社を例示している。

ＡＳＰサーバセンター２内のローカルエリアネットワーク（ＬＡＮ）１２と、各会社の
支社内のローカルエリアネットワーク（ＬＡＮ）１６との間はそれぞれ、インターネット
や専用回線などの広域ネットワーク（ＷＡＮ）１４、支社間を接続する全社のＬＡＮ１８
、通常プロキシ７０、クライアント側プロキシ４０等を介して接続されており、ＡＳＰサ
ーバセンター２内のサーバ２０と、各支社４内のクライアント５０とが、通信可能になっ
ている。ＡＳＰサーバセンター２内ＬＡＮ１２には１または複数のサーバが接続され、支
社内ＬＡＮ１６には１または複数のクライアントが接続される。また、各会社内の他のＬ
ＡＮ１８にも、通常プロキシ７０やクライアント側プロキシ４０を介して、または直接、
複数のクライアント（図示しない）が接続される。

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

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

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

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

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

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

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

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

また、クライアント側プロキシ４０は、例えば、ＷＡＮ１４とＬＡＮ１８との間に、Ｗ
ＡＮ１４とＬＡＮ１８との中継を行うとともに、本社の複数のクライアント５０（図示し
ない）のプロキシとして、更に設けられることもある（例えば、図１の真中の会社）。

通常プロキシ７０も、例えば、ＷＡＮ１４とＬＡＮ１８との間に、ＷＡＮ１４とＬＡＮ
１８との間の中継を行うとともに、本社の複数のクライアント５０（図示しない）のプロ
キシとして、更に設けられることもある（例えば、図１の上の会社）。なお、通常プロキ
シ７０は、現在一般的に用いられているＨＴＴＰプロキシサーバのことを指しており、一
方サーバ側プロキシ３０、クライアント側プロキシ４０は、後述するＦＰ圧縮を行って通
信データを削減する機能を有する新規のＨＴＴＰプロキシサーバのことを指している。

上記のコンピュータ・ネットワーク・システムにおいて、本実施の形態の概念的なフロ
ーについて、図４及び図５を用いて説明する。

図４は、サーバ２０上のＷｅｂコンテンツをサーバ側プロキシ３０およびクライアント
側プロキシ４０へキャッシュする際の動作フローを示している。

まず、ユーザは、支店４内のクライアント５０のブラウザから、所望のサーバ２０に記
憶されるＷｅｂコンテンツを読み出すために、そのＷｅｂコンテンツのＵＲＬを指定して
、リクエストを行う。

このリクエストは、ネットワークを介して、サーバ２０へ通知される（図４−１）。こ
の通知を受け取ったサーバ２０はリクエストされたＷｅｂコンテンツを読み出して、サー
バ側プロキシ３０へ送信する（図４−２）。サーバ側プロキシ３０は、受け取ったＷｅｂ
コンテンツのフィンガープリント（ＦＰ）を計算する（図４−３）。計算されたＦＰをＷ
ｅｂコンテンツと対応で受けて保存する（図４−４）。また、サーバ側プロキシ３０は受
け取ったＷｅｂコンテンツを支社へリプライする（図４−５）。

クライアント側プロキシ４０は、受け取ったＷｅｂコンテンツのフィンガープリント（
ＦＰ）を計算する（図４−６）。計算されたＦＰをＷｅｂコンテンツと対応で受けて保存
する（図４−７）。クライアント側プロキシ４０は、Ｗｅｂコンテンツをクライアント５
０へ送信する（図４−８）。以上により、Ｗｅｂコンテンツがサーバ側プロキシ３０およ
びクライアント側プロキシ４０へそれぞれキャッシュされる。

次に、図５は、Ｗｅｂコンテンツがサーバ側プロキシ３０およびクライアント側プロキ
シ４０に、既にキャッシュされている際の動作フローを示している。

まず、ユーザは、支店４内のクライアント５０のブラウザから、所望のサーバ２０に記
憶されるＷｅｂコンンテンツを読み出すために、そのＷｅｂコンテンツのＵＲＬを指定し
て、リクエストを行う。

このリクエストは、ネットワークを介して、サーバ２０へ通知される（図５−１）。こ
の通知を受け取ったサーバ２０はリクエストされたＷｅｂコンテンツを読み出して、サー
バ側プロキシ３０へ送信する（図５−２）。サーバ側プロキシ３０は、受け取ったＷｅｂ
ページのフィンガープリント（ＦＰ）を計算する（図５−３）。計算されたＦＰと同じＦ
Ｐが既にサーバ側プロキシ３０内に保存されているか否かの検索を行う（図５−４）。こ
こでは、計算されたＦＰと同じＦＰが保存済みであるため、サーバ側プロキシ３０は、受
け取ったＷｅｂコンテンツを支店へ送信するのではなく、代わりに、そのＦＰを支店へリ
プライする（図５−５）。クライアント側プロキシ４０は、受け取ったＦＰで自装置内を
検索する（図５−６）。検索されて見つかったＦＰに対応付けて保存されるＷｅｂコンテ
ンツを読み出す（図５−７）。クライアント側プロキシ４０は、自装置内から読み出した
Ｗｅｂページをクライアント５０へ送信する（図５−８）。以上により、サーバ側プロキ
シ３０からクライアント側プロキシ４０へ送信されるべきＷｅｂコンテンツを少量のＦＰ
に替えて送るから、特に、広域ネットワークのボトルネックを解消できる。

さて、ここでフィンガープリントについて、詳細に説明する。

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

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

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

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

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

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

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

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

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

ところで、クライアント５０−サーバ２０間では、図１の本発明を適用するコンピュー
タ・ネットワーク・システムの全体構成例にも示したように、支社４とＡＳＰサーバセン
ター２との中間には、様々な他のプロキシ装置が介在し、経由することが一般的である。
ここでは、例えば、図１においては、支社４とＡＳＰサーバセンター２との中間に、
１）通常プロキシを経由する場合（図１右上）、
２）クライアント側プロキシを経由する場合（図１右中）、
３）クライアント側プロキシ及び通常プロキシを経由する場合（図１右下）、
の３通りを示している。なお、図示しないが、ＷＡＮ１４と接続される別の会社におい
ては、クライアント側プロキシ４０を導入することなく通常プロキシ７０のみを介して複
数のクライアント（ブラウザ）が接続されるといった（現状の一般的なネットワーク形態
で構成される）、別の会社も存在しうる。

このように、支社４とＡＳＰサーバセンター２との中間にプロキシが介在する場合には
、支社４のクライアント側プロキシ４０とＡＳＰサーバセンター２のサーバ側プロキシ３
０で、単に上記で説明したようなフィンガープリント圧縮を適用するだけでは、以下のよ
うな問題が生じる。

ａ）リクエストに対するリプライメッセージを受け取ったサーバ側プロキシ３０は、リ
プライメッセージを（可能ならば）ＦＰに変換して送信すべきか、ＦＰに変換せずに送信
すべきか判断できない。つまり、リクエストが通常プロキシ７０だけを経由してきたので
あれば、通常プロキシ７０にはＦＰ機能が無いので、変換したものを送付してはいけない
が、クライアント側プロキシ４０を経由してきたものであれば、送信すべきリプライメッ
セージのＦＰを保存していれば、ＦＰを送ればよい。しかし、現状ではＦＰを送付すべき
か否かを判別することができない。

ｂ）更に、例えば、サーバ側プロキシ３０とクライアント側プロキシ４０との間に通常
プロキシ７０が介在している場合、通常プロキシ７０が備えるキャッシュ機能で、利用で
きないフィンガープリントをもキャッシュしてしまう。

ｃ）例えば、支社４とＡＳＰサーバセンター２との中間にクライアント側プロキシ４０
が介在している場合、その中間のクライアント側プロキシ４０は、自身が中間のプロキシ
であることを判別ができないため、復元して返してしまう。

そこで、本実施の形態のサーバ側プロキシ及びクライアント側プロキシは、これらの問
題点を解決するようにした。

図８、および図９に、本実施の形態のクライアント側プロキシ４０及びサーバ側プロキ
シ３０の機能ブロック図を示し、詳細に説明する。なお、図８や図９は、クライアント側
プロキシ４０とサーバ側プロキシ３０との間のデータ転送の際の機能構成を中心に示して
ある。

ここで、まず、リクエストメッセージおよびリプライメッセージについて説明する。

リクエストメッセージは、［従来の技術］欄で示したようにリクエストヘッダとリクエ
ストボディからなっており、リクエストヘッダには、予め決められた情報が格納される領
域の他に、利用者によって書き込む情報が定義可能な領域を含んでいる。本実施の形態で
は、この利用者によって定義可能な領域に、リクエストメッセージがクライアント側プロ
キシ４０によって転送される際に、ＦＰ圧縮を行うプロキシを通過した旨を示す情報を書
き込むようにした。ここではＦＰ＿ＵＳＥと書き込むようにし、これをＦＰ＿ＵＳＥヘッ
ダと呼ぶこととする。

リプライメッセージは、［従来の技術］欄で示したようにリプライヘッダとリプライボ
ディからなっており、リプライヘッダには、予め決められた情報が格納される領域に、Ｈ
ＴＴＰプロトコル対応の装置で認識可能なＮＯ＿ＣＡＣＨＥヘッダを付加することができ
る。このＮＯ＿ＣＡＣＨＥヘッダは、リプライボディのキャッシュを禁止する旨を意味す
る。本実施の形態では、サーバ側プロキシ３０が、この領域にＮＯ＿ＣＡＣＨＥと書き込
むようにした。よって、ＨＴＴＰプロトコル対応の装置は、受信したリプライメッセージ
にＮＯ＿ＣＡＣＨＥヘッダがあれば、ＦＰをキャッシュすることは無くなる。また、リプ
ライヘッダには、予め決められた情報が格納される領域の他に、利用者によって書き込む
情報が定義可能な領域を含んでいる。本実施の形態では、リプライボディを、ＦＰ圧縮を
行ったＦＰ値とする場合には、この利用者によって定義可能な領域に、ＦＰヘッダを付加
するようにした。

以下では図８を用い、クライアント側プロキシ４０の構成について説明する。

受信部４０１は、クライアント５０からのリクエストメッセージを受信するものである
。ヘッダ解析部４０２は、受信部４０１にて受信したリクエストメッセージを受け、リク
エストヘッダを解析し、前記ＦＰ＿ＵＳＥヘッダの有無を検出するものである。ヘッダ情
報保存部４０３は、ヘッダ解析部４０２でＦＰ＿ＵＳＥヘッダを備えたリクエストメッセ
ージを検出した際に、このリクエストメッセージがＦＰ＿ＵＳＥヘッダを備えていたこと
を示す情報を保存するものである。

ヘッダ付加部４０４は、ヘッダ解析部４０２で、ＦＰ＿ＵＳＥヘッダを備えていないリ
クエストメッセージを検出した際に、リクエストメッセージのリクエストヘッダにＦＰ＿
ＵＳＥヘッダを付加するものである。送信部４０５は、ヘッダ解析部４０２またはヘッダ
付加部４０４から送られてきたリクエストメッセージをサーバ２０へ向けて送信するもの
である。

受信部４０６は、リクエストメッセージに対する応答であるリプライメッセージを受信
するものである。ヘッダ判定部４０７は、リプライメッセージを受信すると、このリプラ
イメッセージに対応するリクエストメッセージにＦＰ＿ＵＳＥヘッダが含まれていたか否
かを、ヘッダ情報保存部４０３を参照し判定するものである。なお、ヘッダ情報保存部４
０３は、リクエストメッセージ時に示したように、リクエストメッセージのヘッダにＦＰ
＿ＵＳＥが含まれているときに保存されるものであるから、情報がヘッダ情報保存部４０
３にあるということは、このクライアント側プロキシ４０が、要求のあったクライアント
５０に最も近いクライアント側プロキシ４０ではないということを意味し、また、情報が
ヘッダ情報保存部４０３にないということは、このクライアント側プロキシ４０が、要求
のあったクライアント５０に最も近いクライアント側プロキシ４０であることを意味する
。

ヘッダ判定部４０７は、このクライアント側プロキシ４０が、クライアント５０に最も
近いクライアント側プロキシ４０でないと判断すれば、受け取ったリプライメッセージを
、そのまま送信部４１３へ送る。また、ヘッダ判定部４０７は、このクライアント側プロ
キシ４０が、クライアント５０に最も近いクライアント側プロキシ４０であると判断すれ
ば、そのリプライメッセージをＦＰ圧縮判定部４０８へ供給する。

ＦＰ圧縮判定部４０８は、受け取ったリプライメッセージにＦＰヘッダが含まれている
か否かを検出することによって、そのリプライメッセージがＦＰ圧縮されたものか否かを
判定するものである。ＦＰ圧縮判定部４０８は、ＦＰ圧縮されていれば、ＦＰキャッシュ
管理部４０９へ、ＦＰ圧縮されていなければＦＰ圧縮処理部４１４へリプライメッセージ
を送る。

ＦＰキャッシュ４１１は、以前にＦＰ圧縮したＦＰと、そのＦＰの圧縮前のコンテンツ
とを対応づけて記憶するものである。

ＦＰ圧縮処理部４１４は、フィンガープリント圧縮するものである。ＦＰ圧縮されたＦ
Ｐ値は、コンテンツと共にＦＰキャッシュ登録部４１０によって、ＦＰキャッシュ４１１
に登録される。

ＦＰキャッシュ管理部４０９は、そのリプライメッセージ内のＦＰでＦＰキャッシュ４
１１を検索し、検索されたＦＰに対応するコンテンツを得て、リプライメッセージのリプ
ライデータをこの得られたコンテンツに変更して、送信部４１３へ送るものである。ＦＰ
キャッシュ登録部４１０は、ＦＰ圧縮判定部４０８からのリプライメッセージを受け取り
、このリプライデータ（コンテンツ）のＦＰを求め、ＦＰとコンテンツとを対応付けてＦ
Ｐキャッシュ４１１に登録する。その後、リプライメッセージを送信部４１３へ送る。

送信部４１３は、受け取ったリプライメッセージをクライアント５０へ送信するもので
ある。

なお、機能ブロックとして、受信部４０１と受信部４０６、送信部４０５と送信部４１
３、を別々のブロック構成として図示したが、同じ構成であっても良く、また受信部４０
１と送信部４１３、受信部４０５と受信部４０６、を送受信部として同じ構成としても良
いことは勿論である。

以上が、クライアント側プロキシ４０の構成である。

次に、サーバ側プロキシ３０の構成について説明する。

受信部３０１は、リクエストメッセージを受信するものである。ヘッダ解析部３０２は
、リクエストメッセージのリクエストヘッダを解析し、ＦＰ＿ＵＳＥヘッダが付加されて
いるか否かを確認し、ＦＰ＿ＵＳＥヘッダが付加されている場合にヘッダ情報保存部３０
３へ通知するものである。

ヘッダ情報保存部３０３は、このリクエストメッセージにＦＰ＿ＵＳＥヘッダがついて
いる旨を示す情報を保存する。そして、リクエストメッセージは、送信部３０４からサー
バ２０へ送信される。なお、サーバ２０は、リクエストメッセージを受け取って、クライ
アント５０から要求された所望のコンテンツを取り出して、リプライメッセージとして、
クライアント５０へ向けて送信する。

受信部３０５は、サーバ２０からのリプライメッセージを受信部３０５で受信するもの
である。ヘッダ判定部３０６は、受信部３０５からリプライメッセージを受けると、ヘッ
ダ情報保存部３０３を参照し、そのリプライメッセージに対応するリクエストメッセージ
にＦＰ＿ＵＳＥヘッダが付加されていたか否かを判定するものである。この判定は、リク
エストメッセージが辿ってきた間に、クライアント側プロキシ４０が存在したか否かを判
定していることに相当する。ヘッダ判定部３０６は、ヘッダが無かった（クライアント側
プロキシが存在しなかった）場合には、そのままリプライメッセージを送信部３１１へ送
る。ヘッダ判定部３０６は、ヘッダがあったと判断した場合は、リプライメッセージをＦ
Ｐ圧縮処理部３０７へ送る。

ＦＰ圧縮処理部３０７は、先に説明したフィンガープリント圧縮の方法でＦＰ圧縮し、
ＦＰを生成するものである。ＦＰキャッシュ管理部３０８は、ＦＰ圧縮処理部３０７から
受け取ったＦＰでＦＰキャッシュ３０９を検索するものである。見つかった際に、リプラ
イメッセージのリプライデータをＦＰに変えてヘッダ付加部３１０へ送る。ＦＰキャッシ
ュ登録部３１２は、ＦＰキャッシュ管理部３０８でＦＰがＦＰキャッシュ３０９で見つか
らなかった場合に、ＦＰとデータとを対応付けてＦＰキャッシュ３０９へ登録し、リプラ
イメッセージをそのまま送信部３１１へ送る。ヘッダ付加部３１０は、ＦＰキャッシュ管
理部３０８からのリプライメッセージのヘッダにＮＯ＿ＣＡＣＨＥヘッダを付加し、送信
部３１１へ供給するものである。

以上が、サーバ側プロキシ３０の構成である。

図１０は、クライアントからの一つのリクエストメッセージを受けた際のクライアント
側プロキシ４０の処理手順の一例を示している。

クライアント側プロキシ４０は、受信部４０１により、クライアントからのリクエスト
メッセージをＬＡＮ１６、または、ＬＡＮ１８から受信する（ステップＳ１０１）。ヘッ
ダ解析部４０２は、受信したリクエストメッセージのリクエストヘッダを解析し、ＦＰ＿
ＵＳＥヘッダが付加されているか否かを検出する（ステップＳ１０２）。ステップＳ１０
２の結果、ＦＰ＿ＵＳＥヘッダが付加されていれば、ヘッダ情報保存部４０３は、このリ
クエストメッセージにＦＰ＿ＵＳＥヘッダがついていた旨を示す情報を保存し（ステップ
Ｓ１０３）、また、受信したリクエストメッセージをそのまま送信部４０５へ供給し、送
信部４０５は、このリクエストメッセージを、サーバ側プロキシ３０に向けて送信する。

一方、ステップＳ１０２の結果、ＦＰ＿ＵＳＥヘッダが付加されていなければ、ヘッダ
付加部４０４は、このリクエストメッセージのリクエストヘッダの所定エリアにＦＰ＿Ｕ
ＳＥヘッダを付加し、送信部４０５は、このＦＰ＿ＵＳＥを付加したリクエストメッセー
ジを、サーバ側プロキシ３０に向けて送信する（ステップＳ１０５）。

この実施の形態では、クライアント５０がリクエストメッセージを送信してから、リプ
ライメッセージを受けるまでコネクションが張られた状態を維持する通信方式を想定して
いる。そのため、ヘッダ情報保存部４０３ではリクエストメッセージにＦＰ＿ＵＳＥヘッ
ダがついていたか否かを示す最小１ビットのフラグを備えるようにすればよい。なお、こ
の通信方式に限定されること無く、複数のコネクションを並列的に切り替え処理して扱う
ような方式であれば、先のフラグとリクエストメッセージを識別する識別情報などとを対
応付けて保存するようにしても良い、等、様々な方法が適用可能である。

図１１は、一つのリクエストメッセージを、ＷＡＮ１４を介して受けた際のサーバ側プ
ロキシ３０の処理手順の一例を示している。

サーバ側プロキシ３０は、受信部３０１により、リクエストメッセージを受信する（ス
テップＳ２０１）。ヘッダ解析部３０２は、受信したリクエストメッセージのリクエスト
ヘッダを解析し、ＦＰ＿ＵＳＥヘッダが付加されているか否かを検出する（ステップＳ２
０２）。ステップＳ２０２の結果、ＦＰ＿ＵＳＥヘッダが付加されていれば、ヘッダ情報
保存部３０３は、このリクエストメッセージにＦＰ＿ＵＳＥヘッダがついていた旨を示す
情報を保存する（ステップＳ２０３）。受信したリクエストメッセージは、送信部３０４
からサーバ２０へ送信する（Ｓ２０４）。

サーバ２０は、リクエストメッセージを受け、既知の方法で処理を行って、リクエスト
メッセージが発行されたクライアントへ向けて、リプライメッセージを送信する。

図１２に、サーバ２０から一つのリプライメッセージを受けた際のサーバ側プロキシ３
０の処理手順の一例を示している。

サーバ側プロキシ３０は、受信部３０５により、サーバ２０からリプライメッセージを
受信する（ステップＳ３０１）。

ヘッダ判定部３０６は、ヘッダ情報保存部３０３を参照して（ステップＳ３０２）、こ
のリプライメッセージに対応するリクエストメッセージにＦＰ＿ＵＳＥヘッダが付加され
ていたか否かを判定する（ステップＳ３０３）。これはつまり、クライアント５０−サー
バ２０（サーバ側プロキシ３０）間にクライアント側プロキシ４０が少なとも１台は存在
しているか否かを判別している。

ステップＳ３０３の結果、ＦＰ＿ＵＳＥが付加されていないと判断すると、そのままリ
プライメッセージを送信部３１１によって、ＷＡＮ１４を介して、クライアント５０へ向
けて送信する（ステップＳ３０９）。

一方、ステップＳ３０３の結果、ＦＰ＿ＵＳＥが付加されていたと判断すると、ＦＰ圧
縮処理部３０７は、リプライメッセージのリプライデータ（＝コンテンツ）のＦＰを求め
る（ステップＳ３０４）。そして、ＦＰキャッシュ管理部３０８にて、求められた該ＦＰ
をキーとしてフィンガープリントキャッシュ３０９を検索し（ステップＳ３０５）、該Ｆ
Ｐの値とこれに対応するデータとの組がフィンガープリントキャッシュ３０９に登録され
ているか否かを確認する（ステップＳ３０６）。

ステップＳ３０６の結果、ＦＰキャッシュ３０９にＦＰが登録されていれば、ヘッダ付
加部３１０は、リプライメッセージのヘッダにＮＯ＿ＣＡＣＨＥを付加する（ステップＳ
３０７）。そして、リプライメッセージのリプライデータをステップＳ３０４で求められ
たＦＰに変更するとともに、ＦＰヘッダを付加して、送信部３１１は、ＷＡＮ１４を介し
て、クライアント５０へ向けて送信する（ステップＳ３０８）。

ステップＳ３０６の結果、ＦＰキャッシュ３０９にＦＰが登録されていなければ、Ｆ
Ｐキャッシュ登録部３１２は、該フィンガープリントの値と、該リプライデータとを対応
付けて（フィンガープリントの値をキーとして）、フィンガープリントキャッシュ３０９
に登録する（ステップＳ３１０）。そして、送信部３１１は、そのままリプライメッセー
ジを、ＷＡＮ１４を介して、クライアント５０へ向けて送信する（ステップＳ３１１）。

図１３に、一つのリプライメッセージを受けた際のクライアント側プロキシ４０の処理
手順の一例を示している。

クライアント側プロキシ４０は、受信部４０６により、リプライメッセージを受信する
（ステップＳ４０１）。

ヘッダ判定部４０７は、ヘッダ情報保存部４０３を参照して（ステップＳ４０２）、こ
のリプライメッセージに対応するリクエストメッセージにＦＰ＿ＵＳＥが付加されていた
か否かを判定する（ステップＳ４０３）。これはつまり、本クライアント側プロキシ４０
とクライアント５０との間にクライアント側プロキシ４０が存在しているか、いないかを
判別するものである。例えば、図１の右中の２つのクライアント側プロキシ４０のうち、
左側のクライアント側プロキシ４０のヘッダ情報保存部４０３には、ＦＰ＿ＵＳＥが付加
されていたことを保存しており、右側のクライアント側プロキシ４０のヘッダ情報保存部
４０３には、ＦＰ＿ＵＳＥが付加されていなかったので、何も保存しない。

ステップＳ４０３の結果、ＦＰ＿ＵＳＥが付加されていると判断すると、リプライメッ
セージをそのまま送信部４１３によって、ＬＡＮ１４等を介して、クライアント５０へ向
けて送信する（ステップＳ４１１）。

ステップＳ４０３の結果、ＦＰ＿ＵＳＥが付加されていないと判断すると、ＦＰ圧縮判
定部４０８は、リプライヘッダのＦＰヘッダの有無を確認することによって、リプライデ
ータがＦＰ圧縮されているか否かを判定する（Ｓ４０４）。ＮＯ＿ＣＡＣＨＥヘッダがあ
れば、ＦＰ圧縮されていることになる。

ステップＳ４０４の結果、ＦＰ圧縮されていれば、リプライメッセージのリプライデー
タはＦＰであるから、ＦＰキャッシュ管理部４０９にて、該リプライデータ（＝ＦＰ）を
キーとしてフィンガープリントキャッシュ４１１を検索する（ステップＳ４０５）。この
検索によって、見つけられた該フィンガープリントに対応するコンテンツを読み出し、リ
プライメッセージのリプライデータをこのコンテンツに変更する（ステップＳ４０６）。
送信部４１３は、この変更されたリプライメッセージをクライアント５０へ向けて送信す
る（ステップＳ４０７）。

ステップＳ４０４の結果、ＦＰ圧縮されていなければ、ＦＰ圧縮処理部４１４によって
、リプライデータ（＝コンテンツ）のＦＰを求める（ステップＳ４０８）。ＦＰキャッシ
ュ登録部４１０は、求めた該フィンガープリントと、該リプライデータ（＝コンテンツ）
とを対応付けて（フィンガープリントの値をキーとして）、フィンガープリントキャッシ
ュ４１１に登録する（ステップＳ４０９）。そして、送信部４１３は、そのままのリプラ
イメッセージを、クライアント５０へ向けて送信する（ステップＳ４１０）。

以上説明してきた本発明の実施形態によれば、上記したクライアント側プロキシ４０は
、その配置箇所に応じて動作する。例えば、クライアント側プロキシ４０がクライアント
５０に最も近い、クライアント側プロキシであれば、クライアントへ送信するリプライデ
ータは、必ず（ＦＰ非圧縮の）生のデータを供給する。また、例えば、クライアント側プ
ロキシ４０が中間プロキシであれば、リプライデータを何も処理することなく転送のみを
行うように動作する。このように動作するから、サーバ側プロキシ３０とクライアント側
プロキシ４０との間に、クライアント側プロキシ４０や、通常プロキシ７０などが接続さ
れても正常に動作するようなシステムが構築できるようになった。

また、通常プロキシが存在しても、誤ってＦＰデータをキャッシュすることなく、正常
に動作する。

なお、本実施の形態のクライアント側プロキシ４０は、リクエストメッセージにＦＰ＿
ＵＳＥヘッダが付いている時に、ＦＰ＿ＵＳＥヘッダがついていたことを示す情報を保存
するようにしたが、その逆で、リクエストメッセージにＦＰ＿ＵＳＥヘッダが付いていな
い時に、ＦＰ＿ＵＳＥヘッダが付いていないことを示す情報を保存するようにしても良い
。同様に、リクエストメッセージにＦＰ＿ＵＳＥヘッダが付いていない時に、（このクラ
イアント側プロキシ４０で）ＦＰ＿ＵＳＥヘッダを付けたことを示す情報を保存するよう
にしても良い。このような場合には、ヘッダ判定部４０７は、ヘッダ情報保存部４０３に
情報が保存されていたときに、クライアント５０に最も近いクライアント側プロキシ４０
として扱えば良い。また、ヘッダ情報保存部４０３を、ＦＰ＿ＵＳＥヘッダの有無を示す
ようなフラグとし、ヘッダ判定部４０７ではそのフラグのオン／オフによって、クライア
ント５０に最も近いクライアント側プロキシ４０であるか否かを判定するようにしても良
いだろう。

また、本実施の形態のサーバ側プロキシ３０は、送信するリプライメッセージにデータ
またはＦＰ値の何れかのみを付加して送付するようにしていたが、ＦＰ値を保存しデータ
を送信する場合（Ｓ３０６のＮＯの場合）、ＦＰ値もリプライメッセージに付けて送るよ
うにしても良い。このような構成にすれば、クライアント側プロキシ４０内には、受信し
たリプライメッセージからＦＰ値を抽出する機能を有する必要があるが、ＦＰ圧縮を行う
機能は不要となり、全体の速度の高速化が可能になるだろう。

ところで、これまでは、１つのメッセージに含まれるデータ全体をＦＰ圧縮する対象（
フィンガープリントキャッシュに登録する対象）にしていたが、例えば、１つのメッセー
ジに含まれるデータが所定の単位のデータの集合で構成される場合には、１つのメッセー
ジに含まれる一部の単位データのみＦＰ圧縮する対象（フィンガープリントキャッシュに
登録する対象）にする構成も可能である。

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

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

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

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

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

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

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

本発明の一実施形態に係るコンピュータ・ネットワーク・システムの構成例を示す図。同実施形態に係るコンピュータ・ネットワーク・システムの他の構成例を示す図。同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図。同実施形態に係るコンピュータ・ネットワーク・システムの基本概念を示す図。同実施形態に係るコンピュータ・ネットワーク・システムの基本概念を示す図。同実施の形態のフィンガープリントを示す図。同実施の形態のフィンガープリントキャッシュを示す図。同実施の形態のクライアント側プロキシ３０の機能ブロック図。同実施の形態のサーバ側プロキシ３０の機能ブロック図。同実施形態に係るクライアント側プロキシの手順例を示すフローチャート。同実施形態に係るサーバ側プロキシの手順例を示すフローチャート。同実施形態に係るサーバ側プロキシの手順例を示すフローチャート。同実施形態に係るクライアント側プロキシの手順例を示すフローチャート。

符号の説明

２…ＡＳＰサーバセンター
４…支社
１２、１６、１８…ＬＡＮ
１４…ＷＡＮ
１６…ユーザオフィス内ＬＡＮ
２０…サーバ装置
３０…サーバ側プロキシ装置
４０…クライアント側プロキシ装置
５０…クライアント装置
６０…通常プロキシ装置
３０１，３０５，４０１，４０６…受信部
３０２，４０２…ヘッダ解析部
３０３，４０３…ヘッダ情報保存部
３０４，３１１，４０５，４１３…送信部
３０６，４０７…ヘッダ判定部
３０７，４１４…ＦＰ圧縮処理部
３０８，４０９…フィンガープリントキャッシュ管理部
３０９，４１１…ＦＰキャッシュ
３１０，４０４…ヘッダ付加部
３１２，４１０…フィンガープリントキャッシュ登録部
４０８…フィンガープリント圧縮判定部

Claims

第１の装置と第２の装置との通信を中継するデータ転送装置において、
キャッシュデータと、該キャッシュデータの識別情報であるキャッシュ識別情報とを関連付けて記憶する識別情報キャッシュを行う識別情報キャッシュ手段と、
第２の装置への所望データの送信要求を示し、リクエストヘッダを有するリクエストメッセージを、前記第１の装置から受信するリクエスト受信手段と、
前記リクエストヘッダを解析し、識別情報キャッシュを行う識別情報キャッシュ装置を前記リクエストメッセージが経由してきたか否かを解析する解析手段と、
前記リクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを示す経由情報を保持する保持手段と、
前記リクエストメッセージを前記第２の装置へ送信するリクエスト送信手段と、
前記リクエストメッセージに対応しリプライヘッダとリプライボディとを有するリプライメッセージを、前記第２の装置から受信するリプライ受信手段と、
前記保持手段に保持された前記経由情報に基づいて、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたか否かを判定する判定手段と、
前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合は前記リプライメッセージに対応するリプライボディ識別情報を求め、さらに前記キャッシュ識別情報のなかに求められた前記リプライボディ識別情報がある場合に、前記リプライヘッダに、前記リプライメッセージをキャッシュすべきでないことを示すＮｏ−ｃｈａｃｈｅ情報を与えるＮｏ−ｃｈａｃｈｅ情報付加手段と、
前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合は前記Ｎｏ−ｃｈａｃｈｅ情報が与えられたリプライヘッダを有するリプライメッセージであって前記Ｎｏ−ｃｈａｃｈｅ情報付加手段から受信したリプライメッセージのリプライボディを前記リプライボディ識別情報に変更し、変更されたリプライメッセージを前記第１の装置へ送信し、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合はそのままリプライメッセージを前記第1の装置へ送信するリプライ送信手段と
を備えることを特徴とするデータ転送装置。
前記Ｎｏ−ｃｈａｃｈｅ情報は、ＨＴＴＰプロトコルを扱うことが可能な装置での前記リプライメッセージに含まれるデータのキャッシュを禁止する命令であることを特徴とする請求項１記載のデータ転送装置。
第１の装置と第２の装置との通信を中継するデータ転送方法において、
識別情報キャッシュ手段に、キャッシュデータと、該キャッシュデータの識別情報であるキャッシュ識別情報とを関連付けて記憶する識別情報キャッシュを行い、
リクエスト受信手段で、第２の装置への所望データの送信要求を示し、リクエストヘッダを有するリクエストメッセージを、前記第１の装置から受信し、
解析手段で、前記リクエストヘッダを解析し、識別情報キャッシュを行う識別情報キャッシュ装置を前記リクエストメッセージが経由してきたか否かを解析し、
保持手段で、前記リクエストメッセージが識別情報キャッシュ装置を経由してきたか否かを示す経由情報を保持し、
リクエスト送信手段で、前記リクエストメッセージを前記第２の装置へ送信し、
リプライ受信手段で、前記リクエストメッセージに対応しリプライヘッダとリプライボディとを有するリプライメッセージを、前記第２の装置から受信し、
判定手段で、前記保持手段に保持された前記経由情報に基づいて、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたか否かを判定し、
Ｎｏ−ｃｈａｃｈｅ情報付加手段で、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合は前記リプライメッセージに対応するリプライボディ識別情報を求め、さらに前記キャッシュ識別情報のなかに求められた前記リプライボディ識別情報がある場合に、前記リプライヘッダに、前記リプライメッセージをキャッシュすべきでないことを示すＮｏ−ｃｈａｃｈｅ情報を与え、
リプライ送信手段で、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由してきたと判定された場合は前記Ｎｏ−ｃｈａｃｈｅ情報が与えられたリプライヘッダを有するリプライメッセージであって前記Ｎｏ−ｃｈａｃｈｅ情報付加手段から受信したリプライメッセージのリプライボディを前記リプライボディ識別情報に変更し、変更されたリプライメッセージを前記第１の装置へ送信し、前記リプライメッセージに対応する前記リクエストメッセージが前記識別情報キャッシュ装置を経由しなかったと判定された場合はそのままリプライメッセージを前記第1の装置へ送信することを特徴とするデータ転送方法。