JP2001308939A

JP2001308939A - スループットを制御する通信システムおよび方法

Info

Publication number: JP2001308939A
Application number: JP2001034466A
Authority: JP
Inventors: Hideki Yamanaka; 英樹山中
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-02-17
Filing date: 2001-02-09
Publication date: 2001-11-02

Abstract

(57)【要約】【課題】遅延の大きなネットワークにおいて、低コス
トでクライアント−サーバ間のスループットを向上させ
ることが課題である。【解決手段】エージェント中継器１３とエージェント
中継器１４の間で、サーバ１１とクライアント１２の間
のアプリケーションプロトコルのコネクションを、巨大
な通信ウィンドウを持つ多重化プロトコルに変換して、
通信を中継する。また、エージェント中継器１３が大き
なバッファでサーバ１１からのデータを受信すること
で、サーバ１１がこのコネクションに割り当てるスルー
プットを増大させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアント−サ
ーバ間の通信、特に、大陸間、衛星中継等の遅延の大き
なインターネット通信において、スループットを制御す
る通信システムおよびその方法に関する。

【０００２】

【従来の技術および発明が解決しようとする課題】大陸
間、衛星中継等の遠距離のインターネット通信において
は、一般に、近距離の通信に比べて大きな遅延が発生
し、クライアント−サーバ間の通信スループットが低下
する。ここで、通信スループットとは、一定時間内に転
送される情報量を指している。このような遅延の大きな
ネットワークにおける通信ボトルネックを解消する従来
の方法としては、以下の２つの方法が挙げられる。（１）物理的に大容量のネットワークを構築する。（２）主サーバが提供する情報と同様のコンテンツを有
するミラーサーバをクライアントの近辺に分散配置し、
クライアントが最初に主サーバにアクセスした時点で、
主サーバからミラーサーバにアクセスをリダイレクトす
る。

【０００３】（１）の方法では、多くのユーザの通信を
賄うためにバンド幅を大きくすることはできるが、物理
的な距離により決まる遅延（物理的遅延）を小さくする
ことはできない。

【０００４】これに対して、（２）の方法では、主サー
バとクライアントの間の物理的遅延に拘束されることが
なく、近距離で安価な低遅延広帯域ネットワークを実現
できる。しかし、ミラーリングできるコンテンツに制約
があり、単純なオブジェクト（データ）のダウンロード
には非常に有効であるが、ＣＧＩ（common gateway int
erface）等を用いてサーバのデータベースを更新するよ
うな通信には使えない。

【０００５】また、ミラーサーバを設置するためのコス
トが高いという問題もある。近年の波長多重化による光
ファイバを使った大陸間通信のコスト低減は著しく、バ
ンド幅の改善だけのためにコストの高いミラーサーバを
多数設置することは、割に合わなくなり始めている。

【０００６】本発明の課題は、より低いコストで、クラ
イアント−サーバ間のスループットを向上させる通信シ
ステムおよびその方法を提供することである。

【０００７】

【課題を解決するための手段】図１は、本発明の通信シ
ステムの原理図である。本発明の第１の局面において、
通信システムは、バッファ手段１と転送手段２を備え、
サーバ３とクライアント４の間の通信を中継する。

【０００８】バッファ手段１は、サーバ３からクライア
ント４に送信されるデータをバッファしてサーバ３から
のデータの出力を加速することで、サーバ３がクライア
ント４とのコネクションに対して割り当てるスループッ
トを増大させる。転送手段２は、バッファ手段１に格納
されたデータをクライアント４に転送する。

【０００９】バッファ手段１は、例えば、クライアント
４の受信バッファより大きな容量を持ち、サーバ３がク
ライアント４に対して送出したデータを高速に受信す
る。これにより、サーバ３からのデータの送信速度が増
大する。転送手段２は、バッファ手段１が高速に受信し
たデータをクライアント４に転送する。

【００１０】サーバ３は、通常、ネットワーク遅延の小
さなコネクションに対して大きなスループットを割り当
てる制御を行うので、サーバ３の送信速度が増大するに
つれて、サーバ３とクライアント４のコネクションに割
り当てられるスループットが増大する。これにより、サ
ーバ３とクライアント４の間の遅延が大きい場合でも、
ミラーサーバを設置することなく、高速な通信を実現す
ることができる。

【００１１】また、本発明の第２の局面において、通信
システムは、受信手段５、変換手段６、および送信手段
７を備え、サーバ３とクライアント４の間の通信を中継
する。

【００１２】受信手段５は、サーバ３からクライアント
４に送信されるデータを受信する。変換手段６は、受信
したデータのプロトコルを、より大きなデータ量を一度
に転送可能なプロトコルに変換する。送信手段７は、変
換手段６により変換されたデータをネットワークに送信
する。

【００１３】変換手段６は、受信手段５が受信したデー
タのプロトコルを別のプロトコルに変換し、送信手段７
は、変換後のプロトコルに基づいて、元のプロトコルよ
り大きなデータ量を一度にネットワークに送信する。こ
れにより、クライアント４に向けて一度に転送されるデ
ータ量が増大し、ミラーサーバを設置しなくても、高速
な通信を実現することができる。

【００１４】また、本発明の第３の局面において、通信
システムは、受信手段８、変換手段９、および送信手段
１０を備え、サーバ３とクライアント４の間の通信を中
継する。

【００１５】受信手段８は、サーバ３からクライアント
４に送信されるデータのプロトコルを、より大きなデー
タ量を一度に転送可能なプロトコルに変換して得られた
データを、ネットワークから受信する。変換手段９は、
受信したデータのプロトコルを元のプロトコルに変換す
る。送信手段１０は、変換手段９により変換されたデー
タをクライアント４に送信する。

【００１６】受信手段８は、例えば、送信手段７により
送信されたデータをネットワークから受信し、変換手段
９は、受信したデータのプロトコルを変換して元のプロ
トコルに戻す。そして、送信手段１０は、元のプロトコ
ルに基づいて、データをクライアント４に送信する。こ
れにより、クライアント４に向けて送信手段７から受信
手段８に一度に転送されるデータ量が増大し、ミラーサ
ーバを設置しなくても、高速な通信を実現することがで
きる。

【００１７】例えば、図１のバッファ手段１と転送手段
２は、後述する図２のエージェント中継器１３に対応
し、図１の受信手段５、変換手段６、送信手段７、受信
手段８、変換手段９、および送信手段１０は、後述する
図７の受信モジュール３１、プロトコル変換モジュール
３２、送信モジュール３４、受信モジュール４１、プロ
トコル変換モジュール３９、および送信モジュール３８
に対応する。

【００１８】

【発明の実施の形態】以下、図面を参照しながら、本発
明の実施の形態を詳細に説明する。大陸間通信におい
て、コストの高いミラーサーバを分散配置することをあ
きらめた場合、遠距離通信の遅延によるクライアント側
のスループット低下という問題が後に残される。クライ
アント側スループット低下の原因は、次の３つに大別さ
れる。（１）物理的に決まる絶対遅延（２）通信プロトコルによる遅延（３）遅延の大きなコネクションに対するサーバのスル
ープット割り当て低減スケジューリング（１）の遅延は、超光速通信の実現を待たなければ解消
されない。（２）の遅延は、通信プロトコルや通信の枠
組みを置き換えることで、（１）に比して問題にならな
い程度まで小さくできる。また、（３）のスケジューリ
ングによれば、サーバは、サーバから見た遅延が大きな
コネクションに対しては、結果として小さなスループッ
トを割り当てるような制御を行う。そこで、トータルな
遅延ではなく、サーバから見たクライアントへのコネク
ションの遅延を小さくすれば、スループットを向上させ
ることができる。

【００１９】サーバから見たコネクションの遅延は、サ
ーバの出力ポートへの書き込みのブロック時間として現
れる。サーバの近辺という非常に低遅延な場所に中継器
を置き、サーバが書き込んだデータを、中継器が大きな
バッファを使って高速に読み込み、バッファに貯まった
データを、遅延の大きなクライアントとの間で緩やかに
転送する。これにより、サーバにとっては、そのクライ
アントとのコネクションが非常に低遅延なものに見え
る。

【００２０】また、通常のネットワーク通信において
は、１回の転送で送信可能な最大データ量を表す通信ウ
ィンドウが設定されており、最大通信スループットは、
ウィンドウサイズと遅延時間の比（ウィンドウサイズ／
遅延）により決まる。ただし、このウィンドウサイズ
は、送信側と受信側のバッファのサイズにより決めら
れ、ネットワークのバンド幅は、この最大通信スループ
ットより十分大きいものとする。

【００２１】このため、遅延の大きな通信であっても、
ウィンドウサイズが大きければ、ウィンドウサイズが小
さくて遅延の小さな通信と同等のスループットを得るこ
とができる。したがって、転送オブジェクトが比較的小
さくて、バッファに収まる程度である場合だけでなく、
ストリーミングデータのように、ほぼ同じ速度で連続的
に流れてくるオブジェクトの場合でも、サーバから見た
実効遅延は小さくなる。

【００２２】サーバが各クライアントとのコネクション
に割り当てるスループットは、ほとんどの場合、そのコ
ネクションの遅延とサーバの内部遅延のうち大きい方に
反比例する。サーバの内部遅延は、ディスクＩ／Ｏ（入
出力）、ネットワークＩ／Ｏ、ＣＰＵ（中央処理装置）
等におけるキューの待ち時間で決まり、リクエストが多
くてキューが長くなれば、それだけ内部遅延が大きくな
る。

【００２３】大きなサーバでは、オブジェクトを多くの
ディスクに分散したり、ストライピング等の方法でアク
セスを並列化して、ディスクＩ／Ｏの待ち時間をできる
だけ小さくしている。また、ネットワークＩ／Ｏについ
ても、高速ＬＡＮ（local area network）、ＷＡＮ（wi
de area network ）回線を用い、複数のＬＡＮアダプタ
を設ける等の工夫を施して、待ち時間を低減している。
さらに、ＣＰＵのキューに関しては、複数のＣＰＵを持
つ共有記憶型計算機、複数の計算機のクラスタ等を用い
て、待ち時間を低減している。

【００２４】近年の急激な周辺機器の価格低減により、
多くのサーバはこれらのリソースを豊富に持っているの
で、サーバの内部遅延はかなり小さくなってきている。
その結果、クライアントへのスループット割り当ては、
多くの場合、ネットワークの遅延により決まってくる。

【００２５】そこで、本実施形態では、サーバの近辺に
エージェント中継器を設置し、エージェント中継器が大
きなバッファでオブジェクトを受信することで、サーバ
から見たクライアントとのネットワーク遅延を実質的に
小さくする。

【００２６】サーバから見た遅延を実質的に小さくする
ことで、合計のネットワーク遅延が同じである他のクラ
イアントに比べて、より多くのスループットが本実施形
態のシステムを利用するクライアントに割り当てられ
る。さらに、たとえ地球の反対側からアクセスしてくる
クライアントであっても、サーバの近辺の高速ネットワ
ークで繋がったクライアントと同等のスループットを獲
得することができるようになる。

【００２７】図２は、このような通信システムの構成図
である。図２のシステムにおいては、Ｗｅｂサーバ１１
とＷｅｂクライアント１２の間にエージェント中継器１
３が設けられている。サーバ１１とクライアント１２の
間のネットワーク遅延はＲＴＴ₁であり、エージェント
中継器１３は、サーバ１１からのネットワーク遅延がＲ
ＴＴ₂で、クライアント１２からのネットワーク遅延が
ＲＴＴ₃の地点に設置されている。

【００２８】ただし、このネットワーク遅延は、送信側
から受信側に信号を送信して、受信側から送信側に応答
を返送するまでのラウンドトリップタイムを表し、ＲＴ
Ｔ₁＝ＲＴＴ₂＋ＲＴＴ₃であり、エージェント中継器
１３のデータ中継オーバヘッドは、ＲＴＴ₁に比べて無
視できるほど小さいものとする。

【００２９】サーバ１１の内部遅延をＤとし、サーバ１
１からクライアント１２へのデータ転送のウィンドウサ
イズをＢとすると、サーバ１１からクライアント１２へ
直接データを転送する場合の最大ダウンロード速度は、
ＤとＲＴＴ₁のうち大きい方の遅延とＢとの比率で決ま
り、Ｂ／ｍａｘ（Ｄ，ＲＴＴ₁）となる。ｍａｘ（ａ，
ｂ）は、ａとｂのうちの最大値を表す。通常は、Ｄ＜Ｒ
ＴＴ₁であるので、この最大ダウンロード速度は、Ｂ／
ＲＴＴ₁である。

【００３０】これに対して、エージェント中継器１３
が、プロキシクライアントとして、サーバ１１とクライ
アント１２の間でデータの中継を行う場合、サーバ１１
とエージェント中継器１３の間の最大ダウンロード速度
は、Ｂ／ｍａｘ（Ｄ，ＲＴＴ₂）となる。

【００３１】ここで、Ｄ＜ＲＴＴ₂となるようにエージ
ェント中継器１３を設置すると、サーバ１１とエージェ
ント中継器１３の間の最大ダウンロード速度は、Ｂ／Ｒ
ＴＴ ₂となる。このとき、サーバ１１から見たときの最
大ダウンロード速度は、直接通信する場合に比べて、
（Ｂ／ＲＴＴ₂）／（Ｂ／ＲＴＴ₁）＝ＲＴＴ₁／ＲＴ
Ｔ₂倍となる。言い換えれば、サーバ１１から見たとき
のクライアント１２との遅延がＲＴＴ₁からＲＴＴ₂に
減少し、サーバ１１がクライアント１２とのコネクショ
ンに割り当てるスループットがＲＴＴ₁／ＲＴＴ₂倍に
増加する。

【００３２】また、エージェント中継器１３とクライア
ント１２の間の最大ダウンロード速度は、サーバ１１と
エージェント中継器１３の間のダウンロード速度と、エ
ージェント中継器１３とクライアント１２の間のダウン
ロード速度のうち、遅い方の速度で決まり、ｍｉｎ（Ｂ
／ＲＴＴ₃，Ｂ／ｍａｘ（Ｄ，ＲＴＴ₂））となる。ｍ
ｉｎ（ａ，ｂ）は、ａとｂのうちの最小値を表す。

【００３３】ここで、ＲＴＴ₂＜ＲＴＴ₃となるように
エージェント中継器１３を設置し、Ｄ＜ＲＴＴ₃である
ものとすれば、Ｂ／ＲＴＴ₃はＢ／ｍａｘ（Ｄ，ＲＴＴ
₂）より小さくなる。したがって、エージェント中継器
１３とクライアント１２の間の最大ダウンロード速度
は、Ｂ／ＲＴＴ₃となる。

【００３４】このとき、クライアント１２から見たとき
の最大ダウンロード速度は、直接通信する場合に比べ
て、（Ｂ／ＲＴＴ₃）／（Ｂ／ＲＴＴ₁）＝ＲＴＴ₁／
ＲＴＴ ₃倍となる。ＲＴＴ₃＜ＲＴＴ₁であるから、直
接通信の場合より、エージェント中継器１３を用いた場
合の方が高速になることが分かる。

【００３５】このように、Ｄ＜ＲＴＴ₂＜ＲＴＴ₃のと
き、サーバ１１が割り当てるスループットがＲＴＴ₁／
ＲＴＴ₂倍になり、クライアント１２から見たときの最
大ダウンロード速度がＲＴＴ₁／ＲＴＴ₃＝ＲＴＴ₁／
（ＲＴＴ₁−ＲＴＴ₂）倍になる。つまり、ＲＴＴ₂が
小さいほど、サーバ１１から割り当てられるスループッ
トが増大し、ＲＴＴ₂が大きいほど、クライアント１２
に対する最大ダウンロード速度が増大する。

【００３６】したがって、ＲＴＴ₂をどの程度の値にす
るかは、スループットの割り当てと最大ダウンロード速
度のトレードオフにより決定される。特に、ＲＴＴ₂が
Ｄに近い値になるようにエージェント中継器１３を設置
すれば、直接通信する場合に比べて、スループットの割
り当てをＲＴＴ₁／Ｄ倍程度まで増大させることができ
る。

【００３７】このように、図２の通信システムによれ
ば、サーバの持つスループット特性を利用することで、
クライアント１２は、同時にアクセスする他のクライア
ントより有利なスループットを獲得することができる。

【００３８】また、サーバとクライアントの双方を改造
することなく、上述した通信プロトコルによる遅延を削
減するために、サーバの近辺とクライアントの近辺にそ
れぞれエージェント中継器を設けるシステムも考えられ
る。このシステムでは、これらのエージェント中継器が
プロトコル変換を行い、サーバとクライアントの間の通
信のほとんどの時間をこの変換されたプロトコルで中継
する。

【００３９】例えば、各クライアントのリモートエージ
ェントをサーバの近辺のエージェント中継器に仮想的に
設置し、そのエージェント中継器とクライアントの近辺
のエージェント中継器の間で、各クライアントとサーバ
の間のアプリケーションプロトコルのコネクションを多
重化プロトコルに変換して中継する。このようなプロト
コル変換により、２つのエージェント中継器間に巨大な
通信ウィンドウを設定することで、クライアントとサー
バの間のスループットが向上し、ネットワーク遅延が隠
蔽される。

【００４０】特に、ＨＴＴＰ（hypertext transfer pro
tocol ）通信のように、１つのリクエストを送ってその
応答を待つタイプの通信の場合、クライアントから送ら
れたリクエストに対して、信頼性を保ちつつ、１ラウン
ドトリップタイム程度で応答オブジェクトをサーバから
クライアントに転送するような、理論限界速度の中継プ
ロトコルを実現できる。

【００４１】この中継プロトコルでは、エージェント中
継器間のＴＣＰ（transmission control protocol ）通
信に巨大なＴＣＰウィンドウを設定し、ほとんどの大き
さのオブジェクト全体をウィンドウ内に収めて、１回の
転送で送信側から受信側に送ってしまう。そして、受信
側は、オブジェクトを受信したことを、１つのまとまっ
た受信通知（acknowledge ）で送信側に知らせる。

【００４２】図３は、このような通信システムの構成図
である。図３のシステムにおいては、サーバ１１の近辺
にエージェント中継器１３が設けられ、クライアント１
２の近辺にエージェント中継器１４が設けられている。
サーバ１１とクライアント１２の間、サーバ１１とエー
ジェント中継器１３の間、エージェント中継器１３とエ
ージェント中継器１４の間、エージェント中継器１４と
クライアント１２の間のネットワーク遅延は、それぞ
れ、ＲＴＴ₁、ＲＴＴ₂、ＲＴＴ₃、ＲＴＴ₄である。
ただし、ＲＴＴ₁＝ＲＴＴ₂＋ＲＴＴ₃＋ＲＴＴ₄であ
り、エージェント中継器１３、１４のデータ中継オーバ
ヘッドは、ＲＴＴ₁に比べて無視できるほど小さいもの
とする。

【００４３】通常、サーバ１１が１つのコネクションに
割り当てるネットワークＩ／Ｏバッファは、８ＫＢ（キ
ロバイト）程度のことが多い。この理由は、ＷＷＷ（wo
rldwide web）で転送されるオブジェクトの平均的な大
きさが１０〜２０ＫＢ程度であり、ＴＣＰの輻輳回避ア
ルゴリズムにより、ウィンドウが３ＫＢ、６ＫＢ、１２
ＫＢ、．．．のように徐々に開いていくので、Ｉ／Ｏバ
ッファを大きくしても、実際に使われるバッファは８Ｋ
Ｂ程度にしかならないからである。

【００４４】大きなバイナリデータを転送するときに大
きなバッファは有効であるが、平均すると８ＫＢを越え
た領域は使われないことが多いで、過大なバッファを割
り当てることは無駄である。

【００４５】このＩ／Ｏバッファを実効的に大きくする
方法は、ウィンドウが大きく開いた状態のコネクション
を多重化して、他のコネクションまたは他のクライアン
トと共有することである。この方法によれば、ウィンド
ウが大きいので実効スループットは向上し、他のコネク
ションのデータ転送にも用いられるので、小さなオブジ
ェクトの転送が多い場合でも、それらが一緒にウィンド
ウに詰め込まれて転送される。したがって、大きなバッ
ファを確保しても、実質的には無駄にならない。

【００４６】この方法は、２つのエージェント中継器１
３、１４でデータを中継するため、それらのオーバーヘ
ッドを必然的に含むことになるが、このオーバーヘッド
は、ハードウェアおよびソフトウェアを高性能化すれ
ば、それだけ小さくできるものである。これに対して、
物理的な絶対遅延は、ハードウェアおよびソフトウェア
の高性能化ではまったく小さくすることができず、光速
を越える通信手段が現れない限り解消されない。

【００４７】このような通信ウィンドウを設定するため
に、エージェント中継器１３、１４の間に、大きなＩ／
Ｏバッファを備えた信頼性のある通信トランスポートプ
ロトコルでコネクションを張る。そして、このコネクシ
ョンを多重化するプロトコルを用いて、サーバ１１とク
ライアント１２の間のアプリケーションプロトコルの通
信を、このコネクション上で中継（トンネリング）す
る。

【００４８】エージェント中継器１３、１４は、トラン
スポート層のパケットをそのまま中継するのではなく、
各アプリケーションプロトコルの性質を用いて、アプリ
ケーションプロトコルのパケットあるいはデータを、よ
り効率の良い多重化パケットに変換しながら、中継を行
う。このとき、エージェント中継器１３、１４に設けら
れたクライアント１２のエージェントは、例えば、プロ
グラムモジュールとして実装され、アプリケーションプ
ロトコルと多重化プロトコルの間のプロトコル変換／逆
変換を行うインタフェースの役割を果たす。

【００４９】エージェント中継器１３のエージェント
は、クライアント１２に代わって、大きなバッファでサ
ーバ１１から高速にオブジェクトを受信しながら、バッ
ファに貯まったオブジェクトを、多重化プロトコルでエ
ージェント中継器１４のエージェントに転送する。そし
て、エージェント中継器１４のエージェントは、多重化
プロトコルで受信したオブジェクトを、クライアント１
２と通信するためのアプリケーションプロトコルに変換
し、クライアント１２に転送する。

【００５０】また、逆に、エージェント中継器１４のエ
ージェントは、クライアント１２の送信するオブジェク
トを大きなバッファで受信しながら、多重化プロトコル
でエージェント中継器１３のエージェントに転送する。
そして、エージェント中継器１３のエージェントは、転
送されたオブジェクトを大きなバッファで受信しなが
ら、バッファに貯まったオブジェクトをサーバ１１に高
速に転送する。

【００５１】この多重化プロトコルで、単純にアプリケ
ーションプロトコルのトランスポートプロトコルパケッ
トを中継した場合、ネットワーク遅延は中継オーバーヘ
ッドの分だけ増大するだけであるが、上述のようなアプ
リケーションプロトコルレベルのプロトコル変換を用い
れば、ネットワーク遅延を実質的に削減（隠蔽）するこ
とができる。ここで、トランスポートプロトコルパケッ
トは、ＩＰ（Internetprotocol）パケット等に対応す
る。

【００５２】アプリケーションプロトコルレベルのプロ
トコル変換は、ＴＣＰ等の信頼性のある通信につきもの
であるデータ転送ウィンドウのウィンドウサイズを変換
することで行われる。信頼性のある通信の最大通信速度
はウィンドウサイズ／遅延で決まるので、通信速度が遅
延の小さな区間と同等になるように、遅延の大きな区間
のウィンドウサイズを大きく設定する。ただし、ネット
ワークのバンド幅は十分大きく、最大通信速度に影響を
与えないものとする。

【００５３】また、ＴＣＰ等では、輻輳回避のために、
転送開始の直後から少しずつウィンドウサイズを大きく
していくスロースタート機構を採用している。このスロ
ースタートによれば、アプリケーションプロトコルより
下位層にあるＴＣＰのようなデータ転送プロトコルのコ
ネクション毎にウィンドウが設定され、それが徐々に開
いていく。１つのコネクションが継続して使われ、転送
エラーが発生しない場合、このコネクションのウィンド
ウは、パケットの転送が成功する度に倍増し、小さな初
期値から指定された最大サイズまで指数関数的に開いて
いく。

【００５４】そこで、下位のプロトコルのコネクション
を継続して利用すれば、転送エラーが発生しない限り、
下位コネクションのウィンドウは最大サイズまで開き切
ることになる。また、転送エラーが発生する場合でも、
下位のプロトコルがウィンドウサイズを適切に自動調整
することで、ウィンドウサイズは、転送エラーがほとん
ど起こらないような最大のサイズに落ち着くことにな
る。ここでは、下位コネクションの継続利用のことを、
コネクションの多重化と呼んでいる。

【００５５】上位層のプロトコルの多重化コネクション
の使用を開始した時点では、下位コネクションのウィン
ドウが十分に開いていないので、通信は、下位コネクシ
ョンのスロースタートの影響を受ける。しかし、ウィン
ドウは指数関数的に開いていくので、短時間のうちに十
分に開き切り、多重化コネクションは、その使用時間の
ほとんどの間、ウィンドウが十分開いた状態の下位コネ
クションを使用することになる。

【００５６】このように、ウィンドウが大きく開いた状
態のコネクションを多重化して利用すると、常に最大の
ウィンドウサイズで通信が中継されるため、サーバ１１
とクライアント１２の間の通信には、実質的にスロース
タートが働かなくなる。また、多重化されたコネクショ
ンには輻輳制御が働くので、多重化によってイタズラに
輻輳を悪化させることはない。

【００５７】これに対して、多重化を利用しない通常の
場合、下位コネクションが毎回新たに設定されるため、
それより上位のプロトコルのコネクションに、下位コネ
クションのスロースタートの影響がそのまま現れる。

【００５８】ＴＣＰの場合、ウィンドウが標準的な最大
サイズである８ＫＢまで開くためには、１７ＫＢ程度以
上のオブジェクトをダウンロードしなければならない。
しかし、ＷＷＷ等のオブジェクトの典型的なサイズは３
ＫＢ程度なので、下位コネクションの能力を十分に利用
していないが実態である。

【００５９】例えば、多重化コネクションを利用して、
３ＫＢのオブジェクト１０個を連続してダウンロードす
る場合、６個程度ダウンロードした時点で、既にウィン
ドウが８ＫＢまで開き、それ以降のオブジェクトは、こ
の開いたウィンドウのままで転送される。これに対し
て、多重化しない場合は、オブジェクト毎にウィンドウ
を新たに開く動作を行うため、最後まで８ＫＢに達する
ことはない。

【００６０】このように、エージェント中継器１３、１
４間の通信においては、上位層のプロトコルの多重化コ
ネクションを使用するだけで、ほとんどの間、ウィンド
ウが開き切った状態になるため、スロースタートが働か
ない。また、下位コネクションの最大ウィンドウサイズ
を標準的な数値の１００倍以上に初期化するような制御
を行えば、コネクションを継続して利用しているだけ
で、通常ではあり得ない大きさにまでウィンドウを開く
ことができる。

【００６１】一般に、ネットワークのバンド幅がどんな
に大きくても、転送速度はウィンドウサイズ／遅延に抑
制されてしまう。このため、ウィンドウサイズを十分に
大きな値に設定しなければ、ネットワークリソースに大
きな投資を行っても、それが十分に活用されない無駄な
ものになってしまう恐れがある。この観点から見たと
き、上位層のプロトコルの多重化は、実質的な平均ウィ
ンドウサイズを容易に拡大する１つの方法を与えてい
る。

【００６２】図３のシステムにおいて、サーバ１１から
クライアント１２へ直接データを転送する場合の最大ダ
ウンロード速度は、図２のシステムと同様に、Ｂ／ｍａ
ｘ（Ｄ，ＲＴＴ₁）となる。

【００６３】次に、エージェント中継器１３、１４によ
り中継を行う場合、サーバ１１とエージェント中継器１
３の間の最大ダウンロード速度は、Ｂ／ｍａｘ（Ｄ，Ｒ
ＴＴ ₂）となる。

【００６４】また、エージェント中継器１３、１４の間
のデータ転送のウィンドウサイズＷは、サーバ１１およ
びクライアント１２のバッファサイズとは独立に任意に
設定できるので、例えば、Ｂの数倍〜数千倍の値に設定
しておく。

【００６５】エージェント中継器１３、１４の間の最大
ダウンロード速度は、サーバ１１とエージェント中継器
１３の間のダウンロード速度と、エージェント中継器１
３、１４の間のダウンロード速度のうち、遅い方の速度
で決まり、ｍｉｎ（Ｗ／ＲＴＴ₃，Ｂ／ｍａｘ（Ｄ，Ｒ
ＴＴ₂））となる。

【００６６】また、エージェント中継器１４とクライア
ント１２の間の最大ダウンロード速度は、サーバ１１と
エージェント中継器１３の間のダウンロード速度と、エ
ージェント中継器１３、１４の間のダウンロード速度
と、エージェント中継器１４とクライアント１２の間の
ダウンロード速度のうち、最も遅い速度で決まり、ｍｉ
ｎ（Ｂ／ＲＴＴ₄，Ｗ／ＲＴＴ₃，Ｂ／ｍａｘ（Ｄ，Ｒ
ＴＴ₂））となる。

【００６７】ここで、Ｄ＜ＲＴＴ₂＜ＲＴＴ₃、ＲＴＴ
₄＜ＲＴＴ₃となるようにエージェント中継器１３、１
４を設置し、Ｗ＝Ｂ×（ＲＴＴ₃／ＲＴＴ₂）とする
と、エージェント中継器１３、１４の間の最大ダウンロ
ード速度は、Ｂ／ＲＴＴ₂となり、エージェント中継器
１４とクライアント１２の間の最大ダウンロード速度
は、ｍｉｎ（Ｂ／ＲＴＴ₄，Ｂ／ＲＴＴ₂）となる。

【００６８】さらに、ＲＴＴ₂≧ＲＴＴ₄とすると、エ
ージェント中継器１４とクライアント１２の間の最大ダ
ウンロード速度は、Ｂ／ＲＴＴ₂となる。このとき、ク
ライアント１２から見たときの最大ダウンロード速度
は、直接通信する場合に比べて、（Ｂ／ＲＴＴ₂）／
（Ｂ／ＲＴＴ₁）＝ＲＴＴ₁／ＲＴＴ₂倍となる。ＲＴ
Ｔ ₂＜ＲＴＴ₁であるから、直接通信の場合より、エー
ジェント中継器１３、１４を用いた場合の方が高速にな
る。

【００６９】特に、エージェント中継器１３、１４を、
それぞれ、サーバ１１、クライアント１２に隣接して設
置すれば、ＲＴＴ₁とＲＴＴ₃が同じ程度の値になり、
ＲＴＴ₂はＲＴＴ₁に比べてはるかに小さくなる。この
とき、ＷはＢに比べてはるかに大きくなり、クライアン
ト１２から見たときの最大ダウンロード速度は、直接通
信の場合より、はるかに高速になる。したがって、サー
バ１１とクライアント１２の間のスループットが飛躍的
に増大する。

【００７０】また、図３のシステムにおいて、エージェ
ント中継器１３、１４のエージェントは、単に、スルー
プットを可能な限り高める制御を行うだけでなく、逆
に、故意にスループットを下げるような制御を行うこと
もできる。

【００７１】例えば、エージェント中継器１３、１４が
適当なタイミングでアイドリング動作を行うことで、デ
ータ転送のスロットリングが実現される。このとき、エ
ージェント中継器１３、１４は、多数のクライアントの
各々のエージェントが行うアイドリングを全体的にスケ
ジューリングし、クライアント単位でリソース割り当て
を記述することで、システムが各クライアントに割り当
てるスループットを意図的に制御することができる。

【００７２】図４は、このようなスロットリング制御を
示している。まず、クライアント側のエージェント中継
器１４のエージェントに、適当なスループット値をリソ
ース割り当てとして与えておく。次に、エージェント中
継器１４のエージェントは、この値をアイドリング時間
Ｉに変換して、サーバ側のエージェント中継器１３のエ
ージェントに通知する。そして、エージェント中継器１
３のエージェントは、データ転送の度に、時間Ｉのアイ
ドリング動作を実行する。

【００７３】ここで、エージェント中継器１３がサーバ
１１からデータを受信し、ＯＫの受信通知（acknowledg
e ）を返送してからアイドリングを行うものとすると、
サーバ１１とエージェント中継器１３の間の最大ダウン
ロード速度は、Ｄ、ＲＴＴ₂、およびＩのうち最大の時
間とＢとの比率で決まり、Ｂ／ｍａｘ（Ｄ，ＲＴＴ₂，
Ｉ）となる。

【００７４】また、エージェント中継器１３、１４の間
の最大ダウンロード速度は、ｍｉｎ（Ｗ／ＲＴＴ₃，Ｂ
／ｍａｘ（Ｄ，ＲＴＴ₂，Ｉ））となり、エージェント
中継器１４とクライアント１２の間の最大ダウンロード
速度は、ｍｉｎ（Ｂ／ＲＴＴ ₄，Ｗ／ＲＴＴ₃，Ｂ／ｍ
ａｘ（Ｄ，ＲＴＴ₂，Ｉ））となる。

【００７５】ここで、Ｗ＝Ｂ×（ＲＴＴ₃／ＲＴ
Ｔ₂）、Ｉ＞Ｄ、Ｉ＞ＲＴＴ₂、Ｉ＞ＲＴＴ₄とする
と、エージェント中継器１４とクライアント１２の間の
最大ダウンロード速度は、自動的にＢ／Ｉとなる。この
とき、クライアント１２から見たときの最大ダウンロー
ド速度は、直接通信する場合に比べて、（Ｂ／Ｉ）／
（Ｂ／ＲＴＴ₁）＝ＲＴＴ₁／Ｉ倍となる。

【００７６】したがって、Ｉ＜ＲＴＴ₁であれば、直接
通信の場合よりスループットが向上し、Ｉ＞ＲＴＴ₁で
あれば、直接通信の場合よりスループットが低下する。
このような制御によれば、クライアント単位でスループ
ットを増減することができ、クライアントの優先順位に
応じたデータ転送が実現される。

【００７７】次に、図３のシステムに基づくサービスの
例について説明する。図３のシステムによれば、２つの
ネットワーク間の遅延が大きいとき、これらのネットワ
ーク間にエージェント中継器を設置することで、多重化
コネクションを用いた高速な仮想トンネルが構築され
る。この仮想トンネルをバイパスとして用いることで、
ネットワーク間の遅延を実質的に隠蔽することができ
る。したがって、特別料金を支払うプレミアユーザに対
して高スループットを保証するようなサービスを提供す
ることが可能になる。

【００７８】このサービスでは、クライアント側のエー
ジェント中継器内に、各クライアントのＩＰアドレスを
あらかじめ登録しておき、エージェント中継器のエージ
ェントは、接続を試みるクライアントのＩＰアドレス
を、登録されているＩＰアドレスと比較することで、ユ
ーザ認証を行う。そして、クライアントのＩＰアドレス
が登録されていれば処理を続行し、それが登録されてい
なければ、処理を中断して接続を遮断する。

【００７９】このとき、クライアント側のエージェント
中継器は、プロキシサーバと互換の動作を行い、サーバ
側のエージェント中継器を用いた方が高速な場合にの
み、そのエージェント中継器にリクエストを中継し、そ
の他の場合は、プロキシサーバとして直接サーバに接続
する。

【００８０】また、ＨＴＴＰ通信の場合には、ＩＰアド
レスの代わりにクッキー（cookie）を用いて、ユーザ認
証を行うことができる。クッキーは、Ｗｅｂサイトの提
供者が、Ｗｅｂブラウザを通じて、サイトを訪れたクラ
イアントに一時的にデータを書き込んで保存させる技術
である。クッキーには、ユーザに関する情報やサイトを
訪れた日時、訪問回数等が記録される。

【００８１】この場合、各ユーザにあらかじめクッキー
を配布しておき、ネットワークへのアクセス時に、これ
をＨＴＴＰリクエストのヘッダに設定してもらう。ま
た、クライアント側のエージェント中継器内に、各ユー
ザのクッキーをあらかじめ登録しておく。そして、エー
ジェント中継器のエージェントは、各クライアントのＨ
ＴＴＰリクエストのヘッダをチェックし、登録されたク
ッキーがヘッダにあれば、処理を続行し、そのようなク
ッキーがなければ、処理を中断して接続を遮断する。

【００８２】図５は、このようなプレミアユーザサービ
スを行う通信システムを示している。日本の複数のプレ
ミアユーザのクライアント１２が米国の複数のサーバ１
１からサービスを受ける場合、米国、日本の適当な場所
に、それぞれ、エージェント中継器１３、１４を設置す
る。一般に、エージェント中継器１３、１４は、それぞ
れ複数設置される。また、多重化コネクションを用い
て、エージェント中継器１３とエージェント中継器１４
の間に仮想トンネル２１を構築し、アプリケーションプ
ロトコルを仮想的にトンネリングさせる。

【００８３】日本のプレミアユーザは、エージェント中
継器１４をプロキシサーバとして設定し、米国のサーバ
１１にアクセスする。エージェント中継器１４は、クラ
イアント１２からのリクエストを受け取ると、そのクラ
イアント１２用のエージェントを起動して、アクセス制
御および課金制御を行う。

【００８４】このエージェントは、ＩＰアドレス、クッ
キー等を用いて、コネクション毎にクライアント１２の
認証課金を行い、そのクライアント１２が事前に登録さ
れているプレミアユーザであるか否かをチェックする。
そして、認証が成功すると、米国に設置された複数のエ
ージェント中継器１３のうち最適なエージェント中継器
１３にリクエストを転送する。また、認証が失敗する
と、単にリクエストを廃棄して、コネクションを消去す
る。

【００８５】エージェント中継器１４のルーティングテ
ーブルには、あらかじめ米国のサーバ１１とエージェン
ト中継器１３が登録されており、このルーティングテー
ブルを検索することで、最適なエージェント中継器１３
へのルーティングが行われる。また、エージェント中継
器１３、１４の間で動的にルーティング情報を交換する
ことで、ルーティングテーブルが動的に更新される。

【００８６】リクエストを受け取ったエージェント中継
器１３は、クライアント１２用のエージェントを起動し
て、そのリクエストをサーバ１１に渡す。サーバ１１
は、これと逆のルートを辿って、リクエストされたオブ
ジェクトをクライアント１２に転送する。

【００８７】このサービスでは、エージェント中継器１
４のエージェントがクライアント認証時に同時に課金を
行うことで、パケット数等に応じた従量制料金をユーザ
に請求することができる。また、一定期間のサービス利
用料として、固定料金をユーザに請求する課金方法も考
えられる。

【００８８】このように、プレミアユーザサービスで
は、接続要求を送信したクライアント１２を特定し、そ
のクライアント１２と仮想トンネル２１の接続の可否を
決定する。接続を許可されたクライアント１２には、仮
想トンネル２１を通じて、通信スループットの増大とい
うプレミアサービスが提供される。

【００８９】特に、米国と日本の間のネットワーク遅延
は、日本国内および米国内のそれに比べて非常に大き
い。このため、プレミアユーザサービスにより、この間
のバンド幅を十分に大きくすることができれば、日本の
クライアント１２と米国のサーバ１１が直接通信する場
合に比べて、１０倍以上の高速化が期待できる。

【００９０】また、仮想トンネル２１によりネットワー
ク間の遅延を実質的に隠蔽することで、料金を支払うサ
ービス提供者のサーバ１１とそのユーザのクライアント
１２の間の通信に対して、高スループットを保証するサ
ービスを提供することも可能である。

【００９１】サービス提供者がミラーサーバを世界的に
分散配置するほどのコストを掛ける余裕がない場合、仮
想トンネル２１を利用することで、ミラーサーバを設置
した場合に相当するサービスを、より安価なコストで実
施することができる。

【００９２】この場合、エージェント中継器１３、１４
は、料金を支払ったサービス提供者のサーバ１１に限定
して、サーバ１１とクライアント１２の間の通信を中継
する。より具体的には、エージェント中継器１３、１４
は、接続してきたクライアント１２からのオブジェクト
のリクエストのうち、料金を支払った業者が登録したサ
ーバ１１に対するものだけを実際に中継し、それ以外の
サーバ１１へのリクエストを拒絶する。

【００９３】このとき、クライアント側のエージェント
中継器１４は、リモートサーバ１１と互換の動作を行い
ながら、リクエストをサーバ１１上のオブジェクトに転
送する。これにより、クライアント１２に対して、エー
ジェント中継器１４がミラーサーバと同様の動作を行っ
ているように見せることができ、クライアント１２の設
定を変更する必要がまったくない。

【００９４】図６は、このようなクライアントミラーリ
ングサービスを行う通信システムを示している。このシ
ステムでは、サービスの契約時に登録された米国の各サ
ーバ１１に対して、それぞれ、１つずつ専用のエージェ
ント中継器１３を設置し、各エージェント中継器１３と
日本に設置されたエージェント中継器１４をアプリケー
ションプロトコルの仮想トンネル２１で結ぶ。一般に、
エージェント中継器１４は複数設置される。

【００９５】エージェント中継器１４は、日本の一般ユ
ーザに高速ミラーサーバとして開放され、そのルーティ
ングテーブルには、各サーバ１１とエージェント中継器
１３の組が登録されている。エージェント中継器１４
は、クライアント１２からのリクエストを一旦受け取
り、リクエストされたオブジェクトをサービスしている
サーバ１１をルーティングテーブル内で検索する。そし
て、そのサーバ１１に結びつけられたエージェント中継
器１３を転送先として選択し、リクエストを転送する。

【００９６】リクエストを受け取ったエージェント中継
器１３は、エージェントを起動して、アクセス制御およ
び課金制御を行う。エージェントは、サーバ１１の認証
課金を行い、転送されてきたリクエストがそのエージェ
ント中継器１３に結び付けられたサーバ１１に対するも
のであるか否かをチェックする。

【００９７】そして、認証が成功すれば、リクエストを
サーバ１１に転送し、認証が失敗すれば、リクエストさ
れたオブジェクトが存在しない旨の通知をクライアント
１２に返送する。これにより、プログラムの誤動作等に
よって転送されたリクエストを拒絶することが可能にな
る。

【００９８】このサービスでは、エージェント中継器１
３のエージェントがサーバ認証時に同時に課金を行うこ
とで、図５のサービスと同様に、従量制料金をサービス
提供者に請求することができる。また、一定期間のサー
ビス利用料として、固定料金をサービス提供者に請求す
る課金方法も考えられる。

【００９９】このように、クライアントミラーリングサ
ービスでは、接続先のサーバ１１を特定し、そのサーバ
１１とクライアント１２を仮想トンネル２１により接続
するか否かを決定する。接続を許可されたクライアント
１２には、仮想トンネル２１を通じて、ミラーサーバに
よるミラーリングと同様の効果を持つサービスが提供さ
れる。このサービスにおいても、図５のサービスと同様
に、直接通信の場合に比べて１０倍以上の高速化が期待
できる。

【０１００】次に、図７から図１０までを参照しなが
ら、エージェント中継器１３、１４上で起動されるエー
ジェントの構成と動作を詳細に説明する。図７は、エー
ジェント中継器の構成図である。図７のエージェント中
継器は、コンピュータを用いて構成され、受信モジュー
ル３１、４１、プロトコル変換モジュール３２、３９、
多重化モジュール３３、４０、送信モジュール３４、３
８、認証課金部３５、スイッチモジュール３６、ルーテ
ィングテーブル３７を備える。これらのモジュールは、
例えば、プログラムモジュールとして実装され、プロト
コル変換モジュール３２、３９は、クライアント１２に
代わって処理を行うエージェントに対応する。

【０１０１】まず、クライアント側のエージェント中継
器１４において、受信モジュール３１は、クライアント
１２からのリクエストのアプリケーションプロトコルパ
ケットをネットワークから受信し、受信したパケットを
プロトコル変換モジュール３２に転送する。

【０１０２】プレミアユーザサービスの場合、プロトコ
ル変換モジュール３２は、パケットの送信元の認証課金
処理を認証課金部３５に依頼し、処理結果を受け取る。
その後、パケットをエージェントプロトコルパケットに
変換して、スイッチモジュール３６に渡す。ここで、エ
ージェントプロトコルは、エージェント中継器間の多重
化プロトコルに対応する。

【０１０３】スイッチモジュール３６は、ルーティング
テーブル３７を検索することで転送先のルートを決定
し、エージェントプロトコルパケットを多重化モジュー
ル３３に渡す。

【０１０４】多重化モジュール３３は、複数のコネクシ
ョンのエージェントプロトコルパケットを多重化し、送
信モジュール３４は、多重化されたパケットを、サーバ
側のエージェント中継器１３に向けて、ネットワーク上
に送出する。

【０１０５】次に、エージェント中継器１３において、
受信モジュール４１は、ネットワークから多重化された
パケットを受信し、多重化モジュール４０は、パケット
をデマルチプレクスして、個々のエージェントプロトコ
ルパケットに分離し、スイッチモジュール３６に渡す。

【０１０６】スイッチモジュール３６は、ルーティング
テーブル３７を検索することで転送先のルートを決定
し、エージェントプロトコルパケットをプロトコル変換
モジュール３９に渡す。

【０１０７】プロトコル変換モジュール３９は、受け取
ったエージェントプロトコルパケットをアプリケーショ
ンプロトコルパケットに変換する。さらに、クライアン
トミラーリングサービスの場合、送信先サーバの認証課
金処理を認証課金部３５に依頼し、処理結果を受け取
る。その後、アプリケーションプロトコルパケットを送
信モジュール３８に渡す。送信モジュール３８は、アプ
リケーションプロトコルパケットを、転送先のサーバ１
１に向けて、ネットワーク上に送出する。

【０１０８】次に、エージェント中継器１３において、
受信モジュール３１は、サーバ１１のオブジェクトのア
プリケーションプロトコルパケットをネットワークから
受信し、受信したパケットをプロトコル変換モジュール
３２に転送する。

【０１０９】プロトコル変換モジュール３２は、パケッ
トをエージェントプロトコルパケットに変換して、スイ
ッチモジュール３６経由で、多重化モジュール３３に渡
す。多重化モジュール３３は、複数のコネクションのエ
ージェントプロトコルパケットを多重化し、送信モジュ
ール３４は、多重化されたパケットを、クライアント側
のエージェント中継器１４に向けて、ネットワーク上に
送出する。

【０１１０】次に、エージェント中継器１４において、
受信モジュール４１は、ネットワークから多重化された
パケットを受信する。多重化モジュール４０は、パケッ
トをデマルチプレクスして、個々のエージェントプロト
コルパケットに分離し、スイッチモジュール３６経由
で、プロトコル変換モジュール３９に渡す。

【０１１１】プロトコル変換モジュール３９は、受け取
ったパケットをアプリケーションプロトコルパケットに
変換し、送信モジュール３８に渡す。送信モジュール３
８は、アプリケーションプロトコルパケットを、転送先
のクライアント１２に向けて、ネットワーク上に送出す
る。

【０１１２】こうして、サーバ１１にオブジェクトを要
求したクライアント１２に対して、エージェント中継器
１３、１４経由で、要求されたオブジェクトがダウンロ
ードされる。

【０１１３】図８は、認証課金部３５の構成図である。
図８の認証課金部３５は、認証課金モジュール５１、Ｉ
Ｐデータベース５２、および認証課金データベース５３
を含み、パケットに設定されたＩＰアドレスに基づいて
認証課金を行う。

【０１１４】まず、プレミアユーザサービスにおいて、
ＩＰデータベース５２には、各クライアント１２のＩＰ
アドレスとユーザ識別情報（ユーザＩＤ）からなるレコ
ードが格納され、認証課金データベース５３には、ユー
ザＩＤ、サービスの利用期限、および処理されたパケッ
トの数からなるレコードが格納される。

【０１１５】プロトコル変換モジュール３２は、アプリ
ケーションプロトコルパケットの送信元のＩＰアドレス
を認証課金モジュール５１に渡す。認証課金モジュール
５１は、そのＩＰアドレスをキーとしてＩＰデータベー
ス５２を検索し、そのＩＰアドレスを持つレコードがあ
れば、そのレコードのユーザＩＤを取得する。

【０１１６】次に、得られたユーザＩＤをキーとして認
証課金データベース５３を検索し、そのユーザＩＤを持
つレコードがあれば、そのレコードの利用期限をチェッ
クする。そして、現在の日時が利用期限内であれば、そ
のレコードのパケット数に１を加算し、認証が成功した
ことをプロトコル変換モジュール３２に通知する。

【０１１７】送信元のＩＰアドレスを持つレコードがＩ
Ｐデータベース５２にない場合、あるいは、サービスの
利用期限が過ぎている場合は、認証課金モジュール５１
は、認証が失敗したことをプロトコル変換モジュール３
２に通知する。

【０１１８】次に、クライアントミラーリングサービス
において、ＩＰデータベース５２には、各サーバ１１の
ＩＰアドレスとサービス提供者識別情報（サービス提供
者ＩＤ）からなるレコードが格納され、認証課金データ
ベース５３には、サービス提供者ＩＤ、サービスの利用
期限、および処理されたパケットの数からなるレコード
が格納される。

【０１１９】プロトコル変換モジュール３９は、エージ
ェントプロトコルパケットの送信先のＩＰアドレスを認
証課金モジュール５１に渡す。認証課金モジュール５１
は、プレミアユーザサービスの場合と同様の処理を行っ
て、認証の成功または失敗をプロトコル変換モジュール
３９に通知する。この場合、サービス提供者ＩＤがユー
ザＩＤと同様の役割を果たす。

【０１２０】図９および図１０は、図７のエージェント
中継器の処理のフローチャートである。各モジュール
は、処理すべきパケットをネットワークから受信したと
き、または、処理すべきパケットを他のモジュールから
入力されたときに、それぞれ、決められた処理を行う。

【０１２１】まず、スイッチモジュール３６は、プロト
コル変換モジュール３２または多重化モジュール４０か
らエージェントプロトコルパケットが入力されたか否か
をチェックする（図９のステップＳ１）。パケットが入
力されれば、ルーティングテーブル３７を検索して、対
応する転送先ルートが登録されているか否かをチェック
し（ステップＳ２）、転送先ルートが登録されていれ
ば、そのルートにパケットを転送する（ステップＳ
３）。その後、ステップＳ１以降の処理が繰り返され
る。

【０１２２】通常、プロトコル変換モジュール３２から
入力されたパケットは多重化モジュール３３に転送さ
れ、多重化モジュール４０から入力されたパケットはプ
ロトコル変換モジュール３９に転送される。転送先ルー
トが登録されていなければ、パケットを廃棄し、エラー
通知パケットを送信元に返送する（ステップＳ４）。そ
の後、ステップＳ１以降の処理が繰り返される。

【０１２３】スイッチモジュール３６にパケットが入力
されなければ、次に、受信モジュール４１は、ネットワ
ークからエージェントプロトコルパケットを受信したか
否かをチェックする（ステップＳ５）。パケットを受信
すれば、そのパケットを多重化モジュール４０に転送し
（ステップＳ６）、多重化モジュール４０は、パケット
をデマルチプレクスして（ステップＳ７）、スイッチモ
ジュール３６に転送する（ステップＳ８）。その後、ス
テップＳ１以降の処理が繰り返される。

【０１２４】受信モジュール４１がパケットを受信しな
ければ、次に、多重化モジュール３３は、スイッチモジ
ュール３６からエージェントプロトコルパケットが入力
されたか否かをチェックし（ステップＳ９）、パケット
が入力されれば、そのパケットを多重化して、送信モジ
ュール３４に転送する（ステップＳ１０）。そして、送
信モジュール３４は、パケットをネットワーク上に送出
する。その後、ステップＳ１以降の処理が繰り返され
る。

【０１２５】多重化モジュール３３にパケットが入力さ
れなければ、次に、受信モジュール３１は、ネットワー
クからアプリケーションプロトコルパケットを受信した
か否かをチェックする（図１０のステップＳ１１）。パ
ケットを受信すれば、そのパケットをプロトコル変換モ
ジュール３２に転送する（ステップＳ１２）。

【０１２６】プロトコル変換モジュール３２は、パケッ
トの送信元の認証課金処理を認証課金部３５に依頼し、
認証課金が成功したか否かをチェックする（ステップＳ
１３）。認証課金が成功すれば、そのパケットをエージ
ェントプロトコルパケットに変換して、スイッチモジュ
ール３６に転送する（ステップＳ１５）。その後、ステ
ップＳ１以降の処理が繰り返される。

【０１２７】認証課金が失敗すれば、パケットを廃棄
し、エラー通知パケットをスイッチモジュール３６経由
で送信元に返送する（ステップＳ１６）。その後、ステ
ップＳ１以降の処理が繰り返される。

【０１２８】受信モジュール３１がパケットを受信しな
ければ、次に、プロトコル変換モジュール３９は、スイ
ッチモジュール３６からエージェントプロトコルパケッ
トが入力されたか否かをチェックする（ステップＳ１
７）。パケットが入力されれば、そのパケットをアプリ
ケーションプロトコルパケットに逆変換し（ステップＳ
１８）、送信先の認証課金処理を認証課金部３５に依頼
して、認証課金が成功したか否かをチェックする（ステ
ップＳ１９）。

【０１２９】認証課金が成功すれば、パケットを送信モ
ジュール３８に転送し、送信モジュール３８は、パケッ
トをネットワーク上に送出する（ステップＳ２０）。そ
の後、ステップＳ１以降の処理が繰り返される。

【０１３０】認証課金が失敗すれば、パケットを廃棄
し、エラー通知パケットをスイッチモジュール３６経由
で送信元に返送する（ステップＳ２１）。その後、ステ
ップＳ１以降の処理が繰り返される。

【０１３１】図１１は、図８の認証課金モジュール５１
の処理のフローチャートである。まず、認証課金モジュ
ール５１は、プロトコル変換モジュール３２または３９
から認証課金が要求されたか否かをチェックする（ステ
ップＳ３１）。

【０１３２】プロトコル変換モジュール３２から認証課
金が要求されれば、その要求に含まれる送信元のＩＰア
ドレスをキーとしてＩＰデータベース５２を検索し、そ
のＩＰアドレスを持つレコードがあるか否かをチェック
する（ステップＳ３２）。

【０１３３】そのようなレコードがあれば、次に、その
レコードに含まれるユーザＩＤをキーとして認証課金デ
ータベース５３を検索し、そのユーザＩＤを持つレコー
ドの処理を行って、処理結果をチェックする（ステップ
Ｓ３３）。この処理では、レコードに含まれる利用期限
をチェックし、現在の日時が利用期限内であれば、その
レコードのパケット数に１を加算する。

【０１３４】このような処理が成功すれば、認証が成功
したことをプロトコル変換モジュール３２に通知する
（ステップＳ３４）。その後、ステップＳ３１以降の処
理が繰り返される。

【０１３５】ステップＳ３２において対応するレコード
がない場合、または、ステップＳ３３において対応する
レコードの処理が失敗した場合は、認証が失敗したこと
をプロトコル変換モジュール３２に通知する（ステップ
Ｓ３５）。ステップＳ３３においては、例えば、対応す
るレコードがないか、または利用期限が過ぎている場合
に、レコードの処理が失敗したものと判断される。その
後、ステップＳ３１以降の処理が繰り返される。

【０１３６】また、ステップＳ３１において、プロトコ
ル変換モジュール３９から認証課金が要求されれば、そ
の要求に含まれる送信先のＩＰアドレスをキーとしてＩ
Ｐデータベース５２を検索する。そして、ユーザＩＤの
代わりにサービス提供者ＩＤを取得して、同様の処理を
行い、結果をプロトコル変換モジュール３９に通知す
る。

【０１３７】ところで、図３のサーバ１１、クライアン
ト１２、エージェント中継器１３、１４は、例えば、図
１２に示すような情報処理装置（コンピュータ）を用い
て構成することができる。図１２の情報処理装置は、Ｃ
ＰＵ（中央処理装置）６１、メモリ６２、入力装置６
３、出力装置６４、外部記憶装置６５、媒体駆動装置６
６、およびネットワーク接続装置６７を備え、それらは
バス６８により互いに接続されている。

【０１３８】メモリ６２は、例えば、ＲＯＭ（read onl
y memory）、ＲＡＭ（random access memory）等を含
み、処理に用いられるプログラムとデータを格納する。
図７のルーティングテーブル３７と、図８のＩＰデータ
ベース５２および認証課金データベース５３は、例え
ば、メモリ６２に格納される。ＣＰＵ６１は、メモリ６
２を利用してプログラムを実行することにより、必要な
処理を行う。

【０１３９】図７の受信モジュール３１、４１、プロト
コル変換モジュール３２、３９、多重化モジュール３
３、４０、送信モジュール３４、３８、およびスイッチ
モジュール３６と、図８の認証課金モジュール５１は、
プログラムにより記述されたソフトウェアコンポーネン
トとしてメモリ６２に格納される。

【０１４０】入力装置６３は、例えば、キーボード、ポ
インティングデバイス、タッチパネル等であり、オペレ
ータ（ユーザ、サービス提供者、管理者等）からの指示
や情報の入力に用いられる。出力装置６４は、例えば、
ディスプレイ、プリンタ、スピーカ等であり、オペレー
タへの問い合わせや処理結果の出力に用いられる。

【０１４１】外部記憶装置６５は、例えば、磁気ディス
ク装置、光ディスク装置、光磁気ディスク（magneto-op
tical disk）装置、テープ装置等である。情報処理装置
は、この外部記憶装置６５に、上述のプログラムとデー
タを保存しておき、必要に応じて、それらをメモリ６２
にロードして使用する。

【０１４２】媒体駆動装置６６は、可搬記録媒体６９を
駆動し、その記録内容にアクセスする。可搬記録媒体６
９としては、メモリカード、フロッピー（登録商標）デ
ィスク、ＣＤ−ＲＯＭ（compact disk read only memor
y ）、光ディスク、光磁気ディスク等、任意のコンピュ
ータ読み取り可能な記録媒体が用いられる。オペレータ
は、この可搬記録媒体６９に上述のプログラムとデータ
を格納しておき、必要に応じて、それらをメモリ６２に
ロードして使用する。

【０１４３】ネットワーク接続装置６７は、通信ネット
ワークへの接続に用いられる。情報処理装置は、上述の
プログラムとデータをネットワーク接続装置６７を介し
て他の装置から受け取り、必要に応じて、それらをメモ
リ６２にロードして使用する。

【０１４４】図１３は、図１２の情報処理装置にプログ
ラムとデータを供給することのできるコンピュータ読み
取り可能な記録媒体を示している。可搬記録媒体６９や
外部のデータベース７０に保存されたプログラムとデー
タは、メモリ６２にロードされる。そして、ＣＰＵ６１
は、そのデータを用いてそのプログラムを実行し、必要
な処理を行う。

【０１４５】以上説明した実施形態では、エージェント
中継器１３、１４をサーバ１１、クライアント１２とは
別に設けているが、これらをそれぞれサーバ１１、クラ
イアント１２に組み込んでもよい。実際、サーバ側のエ
ージェント中継器１３は、サーバ１１と一体となって運
用されることが望ましい。

【０１４６】また、エージェント中継器１３、１４を複
数のプログラムモジュールにより構成する代わりに、ハ
ードウェアにより構成することもできる。図１４は、こ
のようなエージェント中継器の構成図である。図１４の
エージェント中継器は、受信機７１、８１、プロトコル
変換器７２、７９、多重化装置７３、８０、送信機７
４、７８、認証課金部７５、スイッチ７６、ルーティン
グテーブル７７を備える。各構成要素は、ハードウェア
回路として実装され、図７の各モジュールと同様の動作
を行う。

【０１４７】今日のＷｅｂ上では、プレゼンテーション
効果、ユーザのプロファイリング、Ｗｅｂページの動的
カスタム化等のため、コンテンツが静的なオブジェクト
から動的なオブジェクトに移行している。このため、転
送されるデータ量が増大し、キャッシュサーバ等による
トラフィック削減の効果が著しく低下している。

【０１４８】また、トラフィックを削減するために、ミ
ラーサーバを単に世界中に分散配置したのでは、ユーザ
プロファイルを一元管理することができない。このよう
に、Ｗｅｂのトレンドは、実質的なトラフィックにおい
て、情報の発信元であるサーバへの流れが増大する方向
にある。

【０１４９】本発明の通信システムによれば、キャッシ
ュやミラーオブジェクトを用意することなく、サーバと
クライアントの間の通信スループットを改善することが
できる。したがって、このシステムは、上述のようなＷ
ｅｂのトレンドにマッチし、今後益々有効性を増すもの
と考えられる。

【０１５０】また、本発明の通信システムによれば、ト
ンネリングの方法を用いて、インターネットのＩＰネッ
トワーク上に、実質的に通信速度が速いバイパスが作り
出される。このバイパスは、ユーザに対してプレミアサ
ービスを提供し、サービス提供者に対しては、ユーザを
引きつけ、自社のサービスを他社と差別化する手段を提
供する。

【０１５１】

【発明の効果】本発明によれば、大陸間、衛星中継等の
遅延の大きなインターネット通信において、多数のミラ
ーサーバを分散配置することなく、クライアント−サー
バ間のスループットを向上させることができる。

【図面の簡単な説明】

【図１】本発明の通信システムの原理図である。

【図２】第１の通信システムの構成図である。

【図３】第２の通信システムの構成図である。

【図４】スロットリング制御を示す図である。

【図５】プレミアユーザサービスを示す図である。

【図６】クライアントミラーリングサービスを示す図で
ある。

【図７】第１のエージェント中継器の構成図である。

【図８】認証課金部の構成図である。

【図９】エージェント中継器の処理のフローチャート
（その１）である。

【図１０】エージェント中継器の処理のフローチャート
（その２）である。

【図１１】認証課金処理のフローチャートである。

【図１２】情報処理装置の構成図である。

【図１３】記録媒体を示す図である。

【図１４】第２のエージェント中継器の構成図である。

【符号の説明】

１バッファ手段２転送手段３サーバ４クライアント５、８受信手段６、９変換手段７、１０送信手段１１Ｗｅｂサーバ１２Ｗｅｂクライアント１３、１４エージェント中継器２１仮想トンネル３１、４１受信モジュール３２、３９プロトコル変換モジュール３３、４０多重化モジュール３４、３８送信モジュール３５、７５認証課金部３６スイッチモジュール３７、７７ルーティングテーブル５１認証課金モジュール５２ＩＰデータベース５３認証課金データベース６１ＣＰＵ６２メモリ６３入力装置６４出力装置６５外部記憶装置６６媒体駆動装置６７ネットワーク接続装置６８バス６９可搬記録媒体７０データベース７１、８１受信機７２、７９プロトコル変換器７３、８０多重化装置７４、７８送信機７６スイッチ

Claims

【特許請求の範囲】

【請求項１】サーバとクライアントの間の通信を中継
する通信システムであって、前記サーバから前記クライアントに送信されるデータを
バッファして該サーバからのデータの出力を加速するこ
とで、該サーバが該クライアントとのコネクションに対
して割り当てるスループットを増大させるバッファ手段
と、前記バッファ手段に格納されたデータを前記クライアン
トに転送する転送手段とを備えることを特徴とする通信
システム。
【請求項２】サーバとクライアントの間の通信を中継
する通信システムであって、前記サーバから前記クライアントに送信されるデータを
受信する受信手段と、受信したデータのプロトコルを、より大きなデータ量を
一度に転送可能なプロトコルに変換する変換手段と、前記変換手段により変換されたデータをネットワークに
送信する送信手段とを備えることを特徴とする通信シス
テム。
【請求項３】前記変換手段により変換された複数のコ
ネクションのデータを多重化する多重化手段をさらに備
え、前記送信手段は、多重化されたデータを送信するこ
とを特徴とする請求項２記載の通信システム。
【請求項４】前記クライアントに割り当てられたリソ
ースに基づいて、アイドリング動作を行うアイドリング
手段をさらに備え、前記送信手段は、該アイドリング動
作が終了した後にデータを送信することを特徴とする請
求項２記載の通信システム。
【請求項５】前記サーバのサービス提供者に対する課
金処理を行う課金手段をさらに備え、前記受信手段は、
前記クライアントからの要求を前記ネットワークから受
信し、該課金手段は、該クライアントからの要求が該サ
ーバに対する要求であるか否かをチェックし、該クライ
アントからの要求が該サーバに対する要求であるとき、
前記送信手段は、該クライアントからの要求を該サーバ
に転送し、該課金手段は、該サービス提供者に対して課
金することを特徴とする請求項２記載の通信システム。
【請求項６】サーバとクライアントの間の通信を中継
する通信システムであって、前記サーバから前記クライアントに送信されるデータの
プロトコルを、より大きなデータ量を一度に転送可能な
プロトコルに変換して得られたデータを、ネットワーク
から受信する受信手段と、受信したデータのプロトコルを元のプロトコルに変換す
る変換手段と、前記変換手段により変換されたデータを前記クライアン
トに送信する送信手段とを備えることを特徴とする通信
システム。
【請求項７】多重化されたデータをデマルチプレクス
するデマルチプレクス手段をさらに備え、前記受信手段
は、プロトコルを変換した、複数のコネクションのデー
タを多重化することで得られたデータを受信し、該デマ
ルチプレクス手段は、受信したデータをデマルチプレク
スし、前記変換手段は、デマルチプレクスされたデータ
のプロトコルを変換することを特徴とする請求項６記載
の通信システム。
【請求項８】前記クライアントのユーザに対する課金
処理を行う課金手段をさらに備え、前記受信手段は、前
記サーバに対する要求を前記ネットワークから受信し、
該課金手段は、該サーバに対する要求が該クライアント
からの要求であるか否かをチェックし、該サーバに対す
る要求が該クライアントからの要求であるとき、前記送
信手段は、該サーバに対する要求を該サーバに転送し、
該課金手段は、該ユーザに対して課金することを特徴と
する請求項６記載の通信システム。
【請求項９】サーバとクライアントの間の通信を制御
するコンピュータのためのプログラムを記録した記録媒
体であって、前記プログラムは、前記サーバから前記クライアントに送信されるデータを
バッファして該サーバからのデータの出力を加速するこ
とで、該サーバが該クライアントとのコネクションに対
して割り当てるスループットを増大させ、バッファされたデータを前記クライアントに転送する処
理を前記コンピュータに実行させることを特徴とするコ
ンピュータ読み取り可能な記録媒体。
【請求項１０】サーバとクライアントの間の通信を制
御するコンピュータのためのプログラムを記録した記録
媒体であって、前記プログラムは、前記サーバから前記クライアントに送信されるデータを
受信し、受信したデータのプロトコルを、より大きなデータ量を
一度に転送可能なプロトコルに変換し、変換されたデータをネットワークに送信する処理を前記
コンピュータに実行させることを特徴とするコンピュー
タ読み取り可能な記録媒体。
【請求項１１】サーバとクライアントの間の通信を制
御するコンピュータのためのプログラムを記録した記録
媒体であって、前記プログラムは、前記サーバから前記クライアントに送信されるデータの
プロトコルを、より大きなデータ量を一度に転送可能な
プロトコルに変換して得られたデータを、ネットワーク
から受信し、受信したデータのプロトコルを元のプロトコルに変換
し、変換されたデータを前記クライアントに送信する処理を
前記コンピュータに実行させることを特徴とするコンピ
ュータ読み取り可能な記録媒体。
【請求項１２】サーバとクライアントの間に、ネット
ワーク遅延を隠蔽するための仮想トンネルを構築し、前記仮想トンネルを前記サーバと前記クライアントの間
の通信バイパスとして用いて、該サーバと該クライアン
トの間のスループットを増大させることを特徴とする通
信方法。
【請求項１３】前記仮想トンネルを用いた通信を利用
するクライアントのユーザに対して、料金を請求するこ
とを特徴とする請求項１２記載の通信方法。
【請求項１４】前記仮想トンネルを用いた通信を利用
するサーバのサービス提供者に対して、料金を請求する
ことを特徴とする請求項１２記載の通信方法。
【請求項１５】サーバとクライアントの間の通信を制
御するコンピュータのためのプログラムであって、前記サーバから前記クライアントに送信されるデータを
バッファして該サーバからのデータの出力を加速するこ
とで、該サーバが該クライアントとのコネクションに対
して割り当てるスループットを増大させ、バッファされたデータを前記クライアントに転送する処
理を前記コンピュータに実行させるためのプログラム。
【請求項１６】サーバとクライアントの間の通信を制
御するコンピュータのためのプログラムであって、前記サーバから前記クライアントに送信されるデータを
受信し、受信したデータのプロトコルを、より大きなデータ量を
一度に転送可能なプロトコルに変換し、変換されたデータをネットワークに送信する処理を前記
コンピュータに実行させるためのプログラム。
【請求項１７】サーバとクライアントの間の通信を制
御するコンピュータのためのプログラムであって、前記サーバから前記クライアントに送信されるデータの
プロトコルを、より大きなデータ量を一度に転送可能な
プロトコルに変換して得られたデータを、ネットワーク
から受信し、受信したデータのプロトコルを元のプロトコルに変換
し、変換されたデータを前記クライアントに送信する処理を
前記コンピュータに実行させるためのプログラム。