JP3707927B2 - サーバスループット予約システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネット、イントラネット等で使われるＷｅｂ通信の仕組みにリソース予約機能を効果的に付加することができるサーバスループット予約システムに関する。
【０００２】
【従来の技術】
現在のＷｅｂ通信は、ハイパテキスト内に記述されたオブジェクトに対し、１本ずつのＴＣＰコネクションを張り、これを使って一つずつダウンロードしながら画面に表示する。しかし、逐次にダウンロードを実行すると、１本ずつのコネクションが帯域幅を全て使い尽くす程高速ではないので、効率が悪い。また、快適性のために、複数のオブジェクトを同時にダウンロードすることで、画面を同時描画することが望ましい。これらの解消手段として、ハイパテキスト内に記述された複数オブジェクトに対して並列にＴＣＰコネクションを張り、同時にダウンロードを実行することが行われる。
【０００３】
この方法は、各クライアントにとってはユーザを快適にするための戦略であるが、逆にサーバ側から見れば単なるリソースの無駄使いである。しかも、悪いことに並列に張るコネクションを多くする程ユーザは他のユーザより快適になるので、クライアントが競い合ってサーバのリソースを浪費することになる。
サーバは、過負荷状態に入ってしまうと極端に性能が低下するので、快適性のために浪費したリソースのためにかえってユーザは不快な状態に陥ることになってしまう。サーバ性能を最大限に引き出すためには、リソースの消費を一定の範囲に抑え続けることが要件であり、その戦略のためにはユーザに対するリソースの割り当てを行うのが通常である。このようにユーザの快適性のための戦略とサーバ性能を最大に保つための戦略が、相互に矛盾していて、現実にインターネットはＷｅｂの通信で慢性的な輻輳状態を引き起こしている。
【０００４】
【発明が解決しようとする課題】
しかしながら、現在のＷｅｂの仕組みは、サーバが不特定多数のユーザを扱わなければならないので、予めユーザ毎にリソースを割り当てることができない。また、Ｗｅｂのインフラであるインターネットは、学術ネットワークを基盤にしたこととインフラの費用を安く抑えるために、リソース割当の機能が省略されている。最近、インフラであるインターネットに帯域リソース予約機能を導入する動きもあるが、Ｗｅｂの仕組みはサーバ上のリソースの予約も同時に行う必要があるので、不十分である。
【０００５】
Ｗｅｂ環境でリソース予約機能を導入するとしても、以下の問題がある。
すなわち、通常のＷｅｂアクセスは、サーバとクライアントが直接ＴＣＰコネクションを確立し、１度に数ＫＢ程度のオブジェクトをＨＴＴＰプロトコル等のＷｅｂのプロトコルでアップロード、またはダウンロードし、最後にコネクションを消去すること（トランザクション処理）で行われる。
クライアントのリソース予約は、Ｗｅｂのプロトコルではできないので、Ｗｅｂプロトコル以外の別プロトコルを併用する必要がある。また、平均的にＷｅｂのＴＣＰコネクションは短命なので、各ＴＣＰコネクション単位でリソース予約を行っても、予約の効果が現れる前にコネクションが消去されることが多いので、単にオーバヘッドが大きくなるだけである。
本発明は上記事情に鑑みなされたものであって、その目的とするところは、クライアントとサーバがネットワークを介して接続されているシステムにリソース予約機能を導入し、サーバ負荷の最適化を図ることである。
【０００６】
【課題を解決するための手段】
図１は本発明の原理構成図である。同図においては、一般化のために、特にＷｅｂサーバ、クライアントと明記していないが、本発明は、基本的にＷｅｂ環境でのリソース予約システムとして最適に機能する。クライアント１として、通常のＷｅｂブラウザだけでなく、Ｗｅｂプロキシサーバも想定している。フロントエンドプロキシサーバ３とバックエンドプロキシサーバ４の中間に中継用予約サーバ５を置くこともできる。
【０００７】
Ｗｅｂのプロトコルではリソース予約が出来ず、リソース予約機能を導入するには、次のことが要求される。
▲１▼ Ｗｅｂのプロトコルとは別のプロトコルのコネクションで通信する必要がある。
▲２▼ 通常、そのために直接ユーザのクライアントプログラムを改変することは、コストの面、セキュリティの面で許されない。
▲３▼ ＨＴＴＰプロトコルは元々トランザクション処理に向かず性能が悪い。
以上のことから、本発明においては、図１に示すように、クライアントプログラム１とサーバ２との間でＷｅｂのプロトコルをトランザクション処理向けのリソース予約機能を持つプロトコルに変換するフロントエンドのプロキシサーバ３をクライアントの近辺に置く。また、このプロトコルのためにサーバ２を改変するのは既存のシステムとの互換性が悪く、開発効率も悪いので、サーバ２の前にもバックエンドのプロキシサーバ４を置く。
【０００８】
このバックエンドのプロキシサーバ１台をサーバ１台に対応付けることで、サーバ２上で直接リソース割り当てを行うのと同等の処理をバックエンドのプロキシサーバ４で行うことができる。
バックエンド・プロキシサーバ４のスループットがサーバスループットより小さいときには、バックエンド・プロキシサーバ複数台をサーバ２に対応付け、各プロキシサーバの性能を考慮してサーバスループットを分割して割り当てる。
そして、各フロントエンド・プロキシサーバ３からこの複数のバックエンド・プロキシサーバ４にコネクションを張り、負荷を分散させることでトータルのバックエンド・プロキシサーバ４のスループットを増大することができる。さらに、規模の大きなシステムではフロントエンド・プロキシサーバ３とバックエンド・プロキシサーバ４の間に中継用キャッシュ機能付きプロキシサーバ５を置くこともできる。
【０００９】
ここで導入するプロトコルは、Ｗｅｂのプロトコルの複数コネクションのリソース予約を同時に行うためと、トランザクション向きにＨＴＴＰプロトコルを最適化するため、Ｗｅｂのプロトコルをカプセル化しリソース予約が可能な多重化プロトコルである。プロキシサーバ間をＴＣＰコネクションで結び、この間をこの多重化プロトコルで通信することで、ＴＣＰコネクション中に同時に複数の仮想的なＷｅｂコネクションを張るとともに、リソース予約の通信も同時に行うことができる。
また、マルチキャストネットワーク６を設けることにより、各フロントエンド・プロキシサーバ３、バックエンド・プロキシサーバ４、中継用プロキシサーバ５は、上記マルチキャストネットワーク６を介して他サーバの構成情報等を獲得することができる。
【００１０】
スループット予約は以下のように行うことができる。
（１）予め測定したサーバの負荷とサーバスループット（サーバ側のトータルスループット）の特性を使って、サーバが過負荷状況に陥らないように、サーバが各クライアントのスループットを制約するように予約することで、クライアントからの要求によるリソースの浪費を押え込む。
また、クライアントスループット予約時にユーザを同定することで、各ユーザへのリソース割当を公平にし、ユーザ間のリソースの奪い合いを無効にする。逆に、特権を持つクライアントにはサーバスループットの予約を許し、他のクライアントによるリソースの奪取を防ぐ。
【００１１】
例えば、一般に、Ｗｅｂサーバの負荷（同時コネクション数）とサーバスループットの特性は、図２に示すように、ある一定の負荷が掛かるまで、サーバスループットがほぼ線形に増える。この点（Ｓ点）を越えるとサーバスループットは増加せず、ほとんど一定の値（最大スループット）を保つが、さらに負荷が大きくなると（Ｅ点）、逆にサーバスループットの低下が始まる。
つまり、Ｓ点に達する前の負荷が軽い状態では、クライアントのリソースを予約する必要がない。Ｓ点からＥ点の間は、負荷の変動に村してサーバスループットが一定であるので、各ユーザがサーバスループットを奪い合う競合状態になり、クライアントのリソース予約が必要である。Ｅ点を越える負荷状況は、サーバの危機的な状態なので、クライアントヘの新たなリソース割当を停止して、負荷が軽くなるのを待たなければならない。
【００１２】
リソース予約の仕組みは、サーバの直前のバックエンド・プロキシサーバ４で、サーバ２のスループットを計測し、サーバの負荷とサーバスループットのモデルに従いクライアント側のフロントエンド・プロキシサーバ３、中継プロキシサーバ５にスループットを以下のようにして予約する。
▲１▼ Ｓ点までの負荷状況では、クライアント側の全てのスループット予約を解除する。
▲２▼ Ｓ点からＥ点では各フロントエンド・プロキシサーバ３と中継プロキシサーバ５に予め与えられた重み、あるいは特権を持つフロントエンド・プロキシサーバと中継プロキシサーバが予約した重みに従ったサーバスループットの分割予約を行う。バックエンドプロキシサーバ４は、各フロントエンド・プロキシサーバ３、中継プロキシサーバ５にスループット予約を行うとともに、それらとの多重化コネクションのＩ／Ｏ頻度を重みに従った比で行う。
▲３▼ サーバ負荷がＥ点を越えた場合は、クライアント側のフロントエンド・プロキシサーバ３に新たな仮想Ｗｅｂコネクションを張らないようにリソースを予約する。サーバ負荷がＥ点より下がれば、新たな仮想Ｗｅｂコネクションを張れるようにリソース予約を解除する。
▲４▼ 中継プロキシサーバ５は、予約されたスループットをそのフロントエンド・プロキシサーバに対して、同様に分割予約して行く。
【００１３】
各フロントエンド・プロキシサーバ３は、そこに接続したコネクションのユーザを同定し、各ユーザのトータルのスループットが同じになるように各コネクションにスループットを割り当て、その値を越えないようにＩ／Ｏをスケジューリングする。
以上のようにサーバ負荷とサーバスループットは、原点からＳ点への線形領域の線分、Ｓ点からＥ点への水平な飽和領域の線分でモデル化できるので、これに基づき各クライアントのスループットを制限すれば、サーバスループットを最適に保持できる。
【００１４】
（２）サーバ負荷とサーバスループット特性は、実際のサーバのものである必要はない。また、サーバの特性とは違ったものを指定することができ、予め指定されたサーバ負荷とサーバスループット・モデルに基づき、負荷状況に応じて動的に各クライアントに対してスループットを予約することもできる。
サーバ負荷とサーバスループットの特性を測定する作業は、測定システム、装置の設置、設定、実際の測定等繁雑であるが、上記のようにすることにより、他の既に測定された同程度の性能と考えられるサーバ特性で代用させることが可能となる。また、実際にこの予約システムを運用したときに得られたシステムの統計データから、Ｓ点，Ｅ点をチューニングすることもできる。
【００１５】
（３）図１に示すように、予約サーバに、特権を持ったクライアントからの予約サーバヘのスループット予約を可能とする管理者制御インタフェースを設けることもできる。このインタフェースは、予め登録されたクライアントからのアクセスだけを許可する機能をもち、このクライアントに関するスループット予約命令だけを実行できる。
予約サーバの管理者は、この管理者制御インタフェースを使って、このサーバの任意のクライアントのスループット予約が可能である。また、予約サーバが備えるデフォルト予約テーブルを書き換えることで設定することができる。
Ｗｅｂの仕組みには、サーバのリソースを予約する機能がないが、上記のように予約サーバの管理者制御インターフェースを使えば、間接的にサーバのリソースが予約可能になる。このことにより、全てのＷｅｂクライアントを平等に扱うのではなく、特定のＷｅｂクライアント、ユーザのグループに優先的にリソースを割り当てることも可能となる。
【００１６】
（４）上記（１）をＷｅｂ通信に適用し、サーバへの負荷をバックエンド予約サーバで常に計測し、その負荷の変動に従ってフロントエンド予約サーバにサーバ負荷を増減させるスループット予約命令を発行する。
Ｗｅｂの仕組みには、サーバが自身に掛かる負荷を制御する機能がないが、本発明をＷｅｂ通信に適用し、予約サーバがサーバ負荷を常に監視し、クライアント側にサーバ負荷を動的に効果的に増減させる命令を送る仕組みを導入することにより、サーバ負荷を自律的に間接的に制御できる。さらに、サーバの負荷とスループットのモデルを組み込むことにより、Ｗｅｂ通信において、サーバのスループットを最適に保持できる。
【００１７】
【発明の実施の形態】
以下、本発明をＷｅｂ通信に適用した場合の実施例を説明する。
図３は本発明の実施例のシステムの構成を示す図、また、図４は図３のシステムに中継サーバ５０を設けた場合のシステムの構成を示す図である。
図３、図４において、３０はフロントエンド予約サーバ、４０はバックエンド予約サーバであり、予約サーバ３０，４０は各Ｗｅｂサーバ、Ｗｅｂプロキシサーバ２０のフロントエンド、バックエンドとして動作する。フロントエンド予約サーバ３０とバックエンド予約サーバ４０間は、前記しようにＴＣＰコネクションで結ばれ、この間を多重化プロトコルで通信することで、ＴＣＰコネクション中に同時に複数の収想的なＷｅｂコネクションを張るとともに、リソース予約の通信も同時に行う。
【００１８】
フロントエンド予約サーバ３０、バックエンド予約サーバ４０はマルチキャストネットワーク６に接続されており、これらのサーバが起動されると次のように動作する。
▲１▼ マルチキャスト通信により他の既に動作しているサーバの情報を獲得し、必要に応じて動的にこれらのサーバとの間に多重化プロトコルで通信可能なコネクションを張る（ある一定時間リクエストの通信がなければ、コネクションを消去する）。
▲２▼ Ｗｅｂクライアント１０は、リクエストを最も近くにあるフロントエンド予約サーバ３０に転送する。
▲３▼ リクエストを受けたフロントエンド予約サーバ３０は、Ｗｅｂサーバ２０の近くにあるバックエンド予約サーバ４０へ多重化プロトコルを使ってリクエストを中継する（もしくは中継サーバ５０を介してバックエンド予約サーバ４０へリクエストを中継する）。
▲４▼ バックエンド予約サーバ４０は、Ｗｅｂサーバ２０へリクエストを転送して、返事を受け取る。
▲５▼ バックエンド予約サーバ４０、フロントエンド予約サーバ３０（もしくは中継サーバ５０）は、リクエストが送られて来たパスを逆に辿って、返事をｗｅｂクライアント１０ヘ返す。
【００１９】
ここで、バックエンド予約サーバ４０は、Ｗｅｂサーバ２０のスループットを観測しながら、前記したようにＷｅｂサーバ２０の負荷とサーバスループットモデルに従って各フロントエンド予約サーバ３０（中継サーバ５０）にそのサーバに対するスループットを予約する。
各フロントエンド予約サーバ３０は、同一のＷｅｂサーバに接続している全てのコネクションのユーザを同定し（同一ＩＰアドレスを持つコネクションを１ユーザとする。あるいは、ｉｄｅｎｔ等のツールでユーザを同定する）、ユーザ単位で平等になるように各コネクションにスループットを割り当て、その値を越えないようにＩ／Ｏをスケジューリングする。
また、中継サーバ５０は前記したように、予約されたスループットをそのフロントエンド予約サーバに対して分割予約して行く。
【００２０】
図５、図６はフロントエンド予約サーバ、バックエンド予約サーバの構成を示す図であり、図５、図６は送受信器Ａ，Ｂ、スループット制御装置Ａ，Ｂ、多重化装置の左右の位置が入れ代わった点を除き同一である。また、図７は中継サーバの構成を示す図であり、図７は図５、図６から送受信器Ａ、スループット制御装置Ａを除去したものである。
図５、図６、図７において、３１，４１は送受信器Ａ、３６，４６，５６は送受信器Ｂ、３２，４２はスループット制御装置Ａであり、スループット制御装置Ａは、送受信器Ａで受信したパケットもしくは送受信器Ａから送信するパケットを一時的に保持し、スループット予約情報に基づき順次転送する。また、３５，４５，５５はスループット制御装置Ｂであり、スループット制御装置Ｂは、上記と同様、送受信器Ｂで受信したパケットもしくは送受信器Ｂから送信するパケットを一時的に保持し、スループット予約情報に基づき順次転送する。
【００２１】
３４，４４，５４は多重化装置、３３，４３，５３はパケットスイッチャであり、多重化装置３４，４４，５４はパケットスイッチャ３３，４３，５３の出力をマルチプレックスしてスループット制御装置Ｂに送出し、また、スループット制御装置Ｂの出力をディマルチプレックスしてパケットスイッチャ３３，４３，５３に送りだす。
３８，４８，５８はスループット予約装置であり、スループット予約装置３８，４８，５８には、スループット予約テーブルが設けられており、スループット予約テーブルには後述するように、システム構成情報（他サーバの負荷状態、サービスの内容等）、予約情報等が格納される。
３９，４９，５９はマルチキャスト送受信器であり、マルチキャスト送受信器３９，４９，５９によりマルチキャストネットワーク６から他サーバの構成情報を獲得し、また、マルチキャスト送受信器３９，４９，５９を介して自サーバの構成情報を他のサーバに送出する。
【００２２】
また、３７，４７，５７はデフォルトのスループット予約テーブルであり、スループット予約テーブル（デフォルト）３７，４７，５７には、システム構成情報、予約情報のデフォルト値が格納されており、システム起動時、スループット予約テーブル３７，４７，５７からデフォルト値が読み込まれ、スループット予約装置３８，４８，５８のスループット予約テーブルに設定される。
また、管理者制御インタフェースが設けられており、前記したように予約サーバの管理者は、上記管理者制御インタフェースを使用して、任意のクライアントのスループットを予約することができる。なお、上記デフォルトのスループット予約テーブル３７，４７，５７を書き換えることでスループットを設定することもできる。
【００２３】
図８は、フロントエンド予約サーバ３０、中継サーバ５０に設けられるスループット予約テーブルの一例を示す図である。フロントエンド予約サーバ３０、中継サーバ５０のスループット予約テーブルには、同図に示すように、サーバＩＤと、上記マルチキャストネットワークを介して受信した、サーバのサービス内容（プロトコル／ホスト名等）、負荷状態（稼働／非稼働状態も含む、例えば非稼働状態のとき”−１”を設定）、および、バックエンド予約サーバ４０から送られてくるスループット予約情報（同図の受信）、自サーバで設定されるスループット予約情報（同図の自設定）、および上記情報を受信した時点を示すタイムスタンプ等が格納される。なお、スループット予約情報としては、例えば、サーバ間のスループットのウェイト値、データの転送速度を示すＢＰＳ、パケットスイッチャの単位時間あたりのスイッチ回数等を設定することができる。
【００２４】
そして、フロントエンド予約サーバ３０、中継サーバ５０からバックエンド予約サーバ４０にパケットを送出する際には、上記テーブルの予約情報（受信）に基づく転送速度でパケットが送出され、また、フロントエンド予約サーバ３０、中継サーバ５０からクライアント１０側にパケットを送出する際には、上記予約情報（自設定）に基づく転送速度でパケットが送出される。
また、バックエンド予約サーバ４０のスループット予約テーブルには、リンクされているサーバ名と、自サーバの負荷状態により設定される予約情報（自設定）が格納される。なお、バックエンド予約サーバ４０の予約情報は、前記したように、サーバ負荷とサーバスループット特性に基づき動的に設定される。また、前記したように指定された負荷とサーバスループットモデルに基づき設定することも可能であり、上記サーバスループットモデルは前記した管理者制御インタフェースから与えることができる。
【００２５】
バックエンド予約サーバ４０は、上記スループット予約テーブルの予約情報を、パケットスイッチャ４３、多重化装置４４、スループット制御装置Ｂ、送受信器Ｂを経由してネットワークに送りだす。また、この予約情報がフロントエンド予約サーバ３０、中継サーバ５０で受信されると、受信した予約情報は、送受信器Ｂ、スループット制御装置Ｂ、多重化装置、パケットスイッチャ３３，５３を経由してスループット予約装置３８，５８に送られ、スループット予約テーブルに格納される。フロントエンド予約サーバ３０、中継サーバ５０は、前記したようにこの予約情報（受信）に基づきバックエンド予約サーバ４０にパケットを送出する。
【００２６】
図９〜図１１は本実施例の処理を示すフローチャートであり、同図を参照しながら、フロントエンド予約サーバ、中継サーバ、バックエンド予約サーバにおける処理について説明する。なお、図９〜図１１はフロントエンド予約サーバ、中継サーバ、バックエンド予約サーバで共通に使用されるフローチャートとして記述されており、一部の処理はフロントエンド予約サーバ、バックエンド予約サーバ特有の処理である。また、図５、図６、図７中に情報の流れとして矢印で示したａ〜ｊは、図９〜図１１中に示した（ａ）〜（ｊ）に対応している。
図９のステップＳ１において、各サーバにおいて、デフォルトのスループット予約情報、構成情報を設定し、ステップＳ２において、管理者制御があるかを調べる。管理者制御がある場合には、ステップＳ３において、管理者制御インタフェースから自サーバのスループット予約、構成情報の設定を行う。また、管理者制御がない場合には、ステップＳ４に行き、マルチキャスト受信があるかを調べ、マルチキャスト受信がある場合には、ステップＳ５において、他サーバの構成情報を獲得し、ステップＳ６において、スループット予約装置内の他のサーバの構成情報テーブルを更新する。
【００２７】
マルチキャスト受信がない場合には、ステップＳ７において、マルチキャスト送信があるかを調べ、マルチキャスト送信がある場合には、ステップＳ８において、スループット予約装置内の自サーバの構成情報をダンプし、ステップＳ９において、他サーバへマルチキャスト送信を行う。
マルチキャスト受信がない場合には、ステップＳ１０において、送受信器Ａで受信があるかを調べ、送受信器Ａで受信がある場合（フロントエンド予約サーバの場合にはクライアントからの受信、バックエンド予約サーバの場合にはサーバからの受信）には、ステップＳ１１において、スループット制御装置Ａの入力キューに受信したパケットを入れる（図５、図６のａ）。
送受信器Ａで受信がない場合には、図１０のステップＳ１２において、送受信器Ａで送信があるかを調べ、送受信器Ａで送信がある場合には、ステップＳ１３において、スループット制御装置Ａの出力キューからパケットを取り出し送信する（フロントエンド予約サーバの場合にはクライアントへの送信、バックエンド予約サーバの場合にはサーバへの送信：図５、図６のｂ）。
【００２８】
送受信器Ａで送信がない場合には、ステップＳ１４において、送受信器Ｂで受信があるかを調べ、送受信器Ｂで受信がある場合（ネットワークからの受信）には、ステップＳ１５において、スループット制御装置Ｂの入力キューにパケットを入れる（図５、図６、図７のｃ）。
送受信器Ｂで受信がない場合には、ステップＳ１６において、送受信器Ｂで送信があるかを調べ、送受信器Ｂで送信がある場合には、ステップＳ１７において、スループット制御装置Ｂの出力キューからパケットを取り出し送信する（ネットワークへの送信：図５、図６、図７のｄ）。
送受信器Ｂで送信がない場合には、図１１のステップＳ１８において、スループット制御装置Ａからパケットスイッチャに入力があるかを調べ、スループット制御装置Ａからパケットスイッチャに入力がある場合には、ステップＳ１９において、スループット制御装置Ａの入力キューからパケットを取り出す（図５、図６のｅ）。ついで、ステップＳ２０において、スループット予約装置のサーバ構成情報により、パケットの送り先を決め（例えばフロントエンド予約サーバの場合、サービス内容が一致し最も負荷が軽いサーバが選択される）、ステップＳ２１において、多重化装置を介してパケットをスループット制御装置Ｂの出力キューに入れる（図５、図６、図７のｆ）。
【００２９】
スループット制御装置Ａからパケットスイッチャに入力がない場合には、ステップＳ２２において、スループット制御装置Ｂから多重化装置を経由してパケットスイッチャに入力があるかを調べ、スループット制御装置Ｂからパケットスイッチャに入力がある場合には、ステップＳ２３においてスループット制御装置Ｂの入力キューからデマルチプレックスしたパケットを取り出す（図５、図６、図７のｇ）。ついで、ステップＳ２４において、スループット予約装置のサーバ構成情報により、パケットの送り先を決め、ステップＳ２１において、自サーバ宛のスループット予約であるかを調べる。
自サーバ宛のスループット予約の場合には、ステップＳ２６において、スループット予約装置で、指定されたスループットを予約する（この処理はフロントエンド予約サーバ、中継サーバのみで行われる）。
自サーバ宛のスループット予約でない場合には、ステップＳ３０において、スループット制御装置Ａの出力キューにパケットを入れる（フロントエンド予約サーバ、バックエンド予約サーバの場合：図５、図６のｈ）。あるいは、多重化装置を経由して制御装置Ｂの出力キューにパケットを入れる（中継サーバの場合：図７のｆ）。
【００３０】
スループット制御装置Ｂから多重化装置を経由してパケットスイッチャに入力がない場合には、ステップＳ２７において、自サーバの負荷変動によりスループット予約が必要であるかを調べる（以下の処理はバックエンド予約サーバのみで行われる）。予約が必要である場合には、ステップＳ２８において、スループット予約装置内のスループット予約テーブルを更新する。ついで、ステップＳ２９において、スループット予約装置から、パケットスイッチャ、多重化装置を経由してスループット制御装置Ｂの出力キューにスループット予約パケットを入れる（図６のｊ）。以上の処理が終わると、ステップＳ２に戻り上記処理を繰り返す。
なお、上記実施例では、フロントエンド予約サーバ、バックエンド予約サーバを別途設ける場合について説明したが、Ｉｎｔｒａｎｅｔ、ＩＳＰなどの既にプロキシサーバを導入しているネットワークでは、既存のプロキシサーバを、上記実施例で示したフロント予約サーバ、バックエンド予約サーバ等で互換性を保ちながら置き扱えることもできる。
【００３１】
【発明の効果】
持続的なＷｅｂ通信の急速な増大に対し、サーバ、ネットワークへの投資が追い付かず、恒常的な輻輳状態から脱出できない現状では、何らかの時点でリソース予約システムを導入してユーザ間のリソースの奪い合いを抑制する必要がある。無駄使いをするユーザがより快適になるという、正のフイードバックが掛かり続ければ、イントラネット、インターネットはユーザの強欲によって崩壊してしまう。
本発明においては、以上説明したように、クライアントとサーバ間のクライアントの近傍にリソース予約機能を持つフロントエンド・プロキシサーバを設けるとともに、サーバの近傍にリソース割り当てを行うバックエンド・プロキシサーバを設け、負荷状況に応じて動的に各クライアントに対してスループットを予約し、ユーザ単位で平等にリソースを割り当てるようにしたので、上記正のフイードバックを断ち切ることができ、サーバ負荷の最適化を図ることができる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】サーバスループットの特性を示す図である。
【図３】本発明の実施例のシステム構成図である。
【図４】本発明の実施例のシステム構成図（中継サーバを設けた場合）である。
【図５】フロントエンド予約サーバのブロック構成図である。
【図６】バックエンド予約サーバのブロック構成図である。
【図７】中継サーバのブロック構成図である。
【図８】スループット予約テーブルの構成例を示す図である。
【図９】スループット予約サーバの動作を説明するフローチャート（１）である。
【図１０】スループット予約サーバの動作を説明するフローチャート（２）である。
【図１１】スループット予約サーバの動作を説明するフローチャート（３）である。
【符号の説明】
１ クライアント
２ サーバ
３ フロントエンド・プロキシサーバ
４ バックエンド・プロキシサーバ
５ 中継用プロキシサーバ
６ マルチキャストネットワーク
１０ Ｗｅｂクライアント
２０ Ｗｅｂサーバ
３０ フロントエンド予約サーバ
４０ バックエンド予約サーバ
５０ 中継サーバ
３１，４１ 送受信器Ａ
３６，４６，５６ 送受信器Ｂ
３２，４２ スループット制御装置Ａ
３５，４５，５５ スループット制御装置Ｂ
３４，４４，５４ 多重化装置
３３，４３，５３ パケットスイッチャ
３８，４８，５８ スループット予約装置
３９，４９，５９ マルチキャスト送受信器
３７，４７，５７ スループット予約テーブル（デフォルト）

Claims (1)

1. クライアントとサーバがネットワークを介して接続されているネットワークシステムにおけるサーバスループット予約システムであって、
   クライアントからのリクエストを受けるフロントエンド・プロキシサーバと、
   前記フロントエンド・プロキシサーバ経由で受けたリクエストを対応するサーバへ転送するバックエンド・プロキシサーバと、
   を有し、
   更に、前記バックエンド・プロキシサーバは、該対応するサーバのスループットを計測し、該計測結果を元に、対応するサーバのスループット予約を前記フロントエンド・プロキシサーバに行う機能を有し、
   前記フロントエンド・プロキシサーバは、前記バックエンド・プロキシサーバによるスループット予約情報に基づき、クライアントから受けたリクエストをどのバックエンド・プロキシサーバへ送信するか決定する機能と、
   を有することを特徴とするサーバスループット予約システム。

Images