JP4646931B2 - サーバ装置およびリクエスト整理方法 - Google Patents

Description

本発明は、クライアント・サーバシステムにおいて、リクエストを、その到着順に従って処理するための装置および方法に関する。なお、本明細書では、主にＷｅｂサーバに着目して説明するが、他のサーバ装置への本発明の適用を制限するものではない。

インターネットの普及に伴い、ネットワークを介して様々なサービスを利用できるようになっている。メール、ホームページの閲覧、検索、オンライン取引、ＩＰ電話、ビデオオンデマンドなどは、その一例である。これらのネットワークサービスは様々な形態で提供し得るが、近年、クライアント装置とのインタフェースとして、Ｗｅｂサーバの利用が主流となっている。

Ｗｅｂサーバを用いたサービス（Ｗｅｂサービス）の基本的な仕組みは以下のとおりである。まず、クライアント装置がＷｅｂサーバに対して、取得したいコンテンツを識別するＵＲＬ(Uniform Resource Locator)を付与したリクエストを送信する。Ｗｅｂサーバがリクエストを受け取ると、リクエスト中のＵＲＬに対応するコンテンツをレスポンスとしてクライアント装置に送り返す。Ｗｅｂサービスは、このリクエスト−レスポンスの繰り返しによって提供される。

リクエスト・レスポンスを転送する通信プロトコルとして、ＨＴＴＰ(Hyper Text
Transfer Protocol)が用いられる。本明細書では、Ｗｅｂサービスを行うサーバシステム全体をＷｅｂサーバ、また、Ｗｅｂサーバ上でＨＴＴＰプロトコルを処理する機能をＨＴＴＰサーバ、リクエストに応じたコンテンツを生成する機能をＷｅｂアプリケーションと呼ぶ。

Ｗｅｂサービスでは、クライアント装置のブラウザが１ページを表示するまでに複数のリクエストが必要となる場合がある。１つのページを表示するためのリクエストの繰り返しを、本明細書ではページ処理と呼ぶ。ページ処理の基本的な進行手順は以下のとおりである。

まず、クライアント装置はブラウザに対して取得したいページのルートとなるリソース（以下、ページルートリソース）のＵＲＬを入力する。次に、ブラウザは、入力されたＵＲＬに基づき、Ｗｅｂサーバに対してリクエストを送信し、ページルートリソースを取得する。このとき、ページルートリソースにはページ表示に必要となる他のリソースのＵＲＬが指し示される。次に、ブラウザは、指し示されるＵＲＬに対して自動的にリクエストを発行する。以上を、ページ表示に必要な全リソースを取得するまで再帰的に繰り返す。

Ｗｅｂサービスではさらに、複数ページに跨がって閲覧または情報入力することで、初めて１つのサービスが完了する場合がある。例えば、オンラインショッピングでは、購入すべき商品の選択あるいはクライアント情報の入力などをし、最後に購入内容の確認をすることで、初めて購入手続きが完了する。本明細書では、完了までに複数ページを要する処理をセッション処理と呼ぶ。

なお、このセッション処理と前述したページ処理とは、複数リクエストの処理を全て完了することにより初めて全体として一つの処理が完了するという点において共通していることから、以下では、説明を分り易くするために、一つにまとめてセッション処理と呼ぶことにする。

Ｗｅｂサービスが普及するにつれて、サービスを快適に利用していくための課題も明らかになりつつある。その課題の一つとして、サービス利用が集中した際の過剰トラヒックへの対応が挙げられる。サービス利用の集中の例として、人気の高い銘柄の株やチケットの売買によるリクエスト集中や、災害発生時の見舞呼などがある。また、悪意のあるクライアントによって、Ｆ５アタックなどの無意味なリクエストが大量に送信される場合もある。これらの要因によって、Ｗｅｂサーバにリクエストが過剰に送信されると、Ｗｅｂサーバのリクエスト処理性能の低下が生じたり、応答時間が著しく悪化したりする。

特許第３２３７５９２号 Ｂ．Ｌａｕｒｉｅ，Ｐ．Ｌａｕｒｉ，"Ａｐａｃｈｅハンドブック第２版"，オライリージャパン

過剰トラヒックによるサーバ性能低下を防ぐため、サーバ装置に送信されるトラヒック量を予め制限する手法が提案されている。トラヒック量を制限する指標として、（ａ）ＴＣＰコネクション数、（ｂ）サーバ負荷状態、（ｃ）帯域などが用いられる。そして、これらの値が予め定めている上限を超えると、トラヒック規制を実施する。

例えば、主要なＨＴＴＰサーバＡｐａｃｈｅでは、ＭａｘＣｌｉｅｎｔｓディレクティブを用いて、同時に接続できるＴＣＰコネクション数を制限する（例えば、非特許文献１参照）。

また、特許文献１では、ＣＰＵ使用率を監視し、その閾値を超えたら、ウィンドウサイズを縮小させたりする。しかし、これらのサーバ装置の容量を超えたトラヒックを一様に規制する方法では、クライアント装置の再アクセスによる負荷増加という問題が生じる。すなわち、サーバ装置とは確率的に接続できるようになるため、接続を拒絶されたクライアント装置が、何度も再アクセスを試みるようになる。この結果、サーバ装置が混雑すればするほど、よりアクセスが集中するという悪循環が生じる。

本発明は、このような背景の下に行われたものであって、サーバ装置が混雑している状況であっても、クライアント装置は、ユーザによる新たな操作無しでサーバ装置に接続することができるサーバ装置およびリクエスト整理方法を提供することを目的とする。

本発明では、サーバ装置が混雑している状態にあっても、クライアント装置はそのまま待機していれば、自然とサーバ装置と接続できるようにする。このとき、アクセスを試みても反応がないことによる再アクセスを防止するため、クライアント装置のブラウザに「只今接続中です。そのまま暫くお待ちください」といったビジーメッセージを表示させることが望ましい。

また、本発明では、このような仕組みを、ビジーメッセージ送信時に再接続用の予約をすることなく、ベストエフォートの枠組みで実現する。すなわち、リクエストを受信すると、まず、リクエストの到着順序を比較するための整理番号を付与する。そして、サーバ装置は、リクエストを処理可能になり次第、バッファから整理番号順にリクエストを取り出して順次処理する。

ただし、単純にバッファリングしているのみでは、クライアント装置からはサーバ装置が反応していないように見えるため、クライアント装置が再アクセスを試みてしまう。そこで、本発明では、バッファ中で所定時間を経過したリクエストに対しては、ビジーメッセージをクライアント装置に通知する。

ＨＴＴＰでは原則として、リクエストとレスポンスと１対１に対応する。このため、ビジーメッセージをクライアント装置に通知するには、バッファリングしているリクエストを消費し、レスポンスとして返送する必要がある。そこで、本発明では、ビジーメッセージの送信によって、クライアント装置との接続が切断されないように、ビジーメッセージにクライアント装置のブラウザにリクエストを再送させるための命令を埋め込む。

また、同時に、元々のリクエストの到着順序に従ってリクエストを処理するため、ビジーメッセージに整理番号を埋め込み、ブラウザにリクエストを再送する際に一緒に返送するように指示する。この結果、サーバ装置は、整理番号に基づいて、元のリクエストが到着した順番でリクエストを処理することができる。

本発明では、ビジーメッセージ送信時に再接続用の予約をせず、バッファ中のリクエストのうち、最も新しい予約番号を持つリクエストから順次処理していくのみである。このため、再接続の予約をしたリクエストの再送を待っている間、サーバ装置の空き時間を無駄にすることがない。この結果、サーバ装置のリソースをより効率良く活用できるようになる。

また、本発明では、ビジーメッセージの送信時に次の再送を要求する。このため、クライアント装置のユーザに意識させることなく、ＨＴＴＰの枠組みを使ってリクエストの再送を実現することができる。

本発明の欠点として、ブラウザがリクエストを再送している間に、バッファ中のより新しい整理番号を持つリクエストが先に処理される可能性がある。しかしながら、このような僅かな順番の狂いは、クライアント装置のユーザにとって十分許容できる範囲と考えられる。

すなわち、本発明は、クライアント装置から送信されたリクエストを受信して処理しその結果をレスポンスとして前記クライアント装置に返送するサーバ装置であって、本発明の特徴とするところは、リクエストが到着した順番を比較するための整理番号を到着したリクエストに対して付与する手段と、この整理番号を付与したリクエストをバッファリングしその処理を待ち合わせる手段と、バッファ中で待ち合わせているリクエストの内、古い整理番号を持つリクエストから優先的に処理する手段と、所定時間内に処理できなかったリクエストの送信元のクライアント装置に対して当該リクエストを前記整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信する手段とを備えたところにある。

これにより、サーバ装置が混雑している状況であっても、クライアント装置は、ユーザによる新たな操作無しでサーバ装置に接続することができる。

また、セッション処理に対しては、複数リクエストの処理を全て完了することにより初めて全体として一つの処理が完了するセッション処理を実行する手段と、リクエストをバッファリングしてその処理を待ち合わせる手段と、バッファ中で待ち合わせているリクエストの内、１番目のリクエストの処理が完了しているセッション処理のリクエストである開始済みリクエストを、セッション処理の１番目のリクエストである開始リクエストより優先して処理する手段と、開始リクエストが到着した順番を比較するための整理番号を開始リクエストに対して付与する手段と、開始リクエストの内、古い整理番号を有する開始リクエストほど優先的に処理する手段と、所定時間内に処理できなかった開始リクエストの送信元のクライアント装置に対して当該リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信する手段とを備えたことを特徴とする。

さらに、所定時間内に処理されなかったリクエストに対するビジーメッセージに、当該リクエストよりも古い整理番号を有し、処理を待ち合わせているリクエストの数である待機リクエスト数を付与する手段を備えることができる。これにより、クライアント装置において、待ち時間を予測することができる。

また、クライアント装置において、待ち時間を予測するのではなく、所定時間内に処理されなかったリクエストに対するビジーメッセージに、当該リクエストの予測待ち時間を付与する手段を備えることができる。この場合には、例えば、この予測待ち時間を、整理番号が付与された一つのリクエストが処理されてから整理番号が付与された次のリクエストが処理されるまでの平均間隔である平均リクエスト処理間隔と、予測待ち時間の計算対象となるリクエストよりも古い整理番号を有し、処理を待ち合わせているリクエストの数である待機リクエスト数との乗算により計算する手段を備える。

これによれば、クライアント装置における予測時間の計算が不要となり、クライアント装置の計算負荷を軽減させることができる。

あるいは、前記予測待ち時間を基にクライアント装置のブラウザに今回のリクエストの送信から次回のリクエストを再送するまでの待ち時間を指定する手段を備えてもよい。これによれば、クライアント装置は、単に、指定されたリクエストの再送時間になったときに再送を行えばよいため、クライアント装置の計算負荷および処理負荷を軽減させることができる。

また、本発明をリクエスト整理方法の観点から観ることもできる。すなわち、本発明は、本発明のサーバ装置が実行するリクエスト整理方法であって、本発明の特徴とするところは、リクエストが到着した順番を比較するための整理番号を到着したリクエストに対して付与し、この整理番号を付与したリクエストをバッファリングしその処理を待ち合わせ、バッファ中で待ち合わせているリクエストの内、古い整理番号を持つリクエストから優先的に処理し、所定時間内に処理できなかったリクエストの送信元のクライアント装置に対して当該リクエストを前記整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信するところにある。

また、セッション処理に対しては、複数リクエストの処理を全て完了することにより初めて全体として一つの処理が完了するセッション処理を実行する際に、リクエストをバッファリングしてその処理を待ち合わせ、バッファ中で待ち合わせているリクエストの内、１番目のリクエストの処理が完了しているセッション処理のリクエストである開始済みリクエストを、セッション処理の１番目のリクエストである開始リクエストより優先して処理し、開始リクエストが到着した順番を比較するための整理番号を開始リクエストに対して付与し、開始リクエストの内、古い整理番号を有する開始リクエストほど優先的に処理し、所定時間内に処理できなかった開始リクエストの送信元のクライアント装置に対して当該リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信することを特徴とする。

また、本発明をプログラムの観点から観ることもできる。すなわち、本発明は、汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、本発明のサーバ装置に相応する機能を実現させるプログラムである。

本発明のプログラムは記録媒体に記録されることにより、前記汎用の情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記汎用の情報処理装置に本発明のプログラムをインストールすることもできる。これにより、汎用の情報処理装置を用いて、本発明のサーバ装置に相応する機能を実現することができる。

なお、本発明のプログラムは、汎用の情報処理装置によって直接実行可能なものだけでなく、ハードディスクなどにインストールすることによって実行可能となるものも含む。また、圧縮されたり、暗号化されたりしたものも含む。

本発明によれば、サーバ装置が混雑している状況であっても、クライアント装置は、ユーザによる新たな操作無しでサーバ装置に接続することができる。

（第一実施例）
本発明のサーバ装置およびリクエスト整理方法を適用した本実施例のリクエスト整理システムの最良の実施形態について説明する。図１は本実施例のリクエスト整理システムの全体構成図である。本実施例は、一つ以上のクライアント装置１−１〜１−ｎと、クライアント装置１−１〜１−ｎと接続されたサーバ装置であるＷｅｂサーバ２とから構成される。図１の例では、クライアント装置１−１〜１−ｎとＷｅｂサーバ２とはインターネット５を介して接続されている。

クライアント装置１−１〜１−ｎは、一般的なブラウザ（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ）を使ってＷｅｂサーバ２にリクエストを送信する。そして、Ｗｅｂサーバ２から返送されるレスポンスをブラウザ上に表示する。

Ｗｅｂサーバ２は、クライアント装置１−ｉ（ｉは１〜ｎのいずれか）から受信したリクエストの処理順序を整理する整理部３と、リクエストを処理してレスポンスを生成するアプリケーション部４とからなる。ここで、一つの計算機で整理部３とアプリケーション部４とを実行させても、異なる計算機で実行させてもよい。異なる計算機で実行する場合は、整理部３を負荷分散装置、Ｗｅｂアクセラレータ、アプリケーションゲートウェイ、リバースプロキシといった前段装置に実装し、アプリケーション部４を一般のＰＣサーバ上に実装できる。

整理部３は、クライアント装置１−ｉから受信したリクエストに整理番号を付与し、整理番号を基に、リクエストのアプリケーション部４への転送を制御する。

図２は本発明のリクエスト整理の基本的な流れを示している。

（１）
整理部は、クライアント装置からリクエストを受信すると、リクエスト間の到着順序を比較するための整理番号をリクエストに対して発行する。整理番号は、リクエストを受信するたびに１つずつカウントアップされるカウンタ値でもよい。また、リクエストを受信した時刻（タイムスタンプ）を用いてもよい。

また、間接的にリクエストの到着順序が比較可能であるならば、必ずしも整理番号自体が、リクエストの到着順序を表さなくてもよい。すなわち、リクエストを送信したクライアントを一意に識別できる識別子（クライアント識別子）を発行し、それを整理番号として用いてもよい。

この場合は、整理番号（すなわち、クライアントの識別子）から当該リクエストのカウンタ値やタイムスタンプを参照するための表を別途用意しておく。また、クライアントの識別子を第三者が偽装できないように複雑化しておく（例えば、十分に長いランダムに生成された文字列など）ことで、第三者が整理番号を不正利用する危険性を解消できる。

図２の例では、整理番号としてカウンタ値を用いるものとする。そして、受信したリクエストに、整理番号“１０”を割り振る。

（２）
バッファに受信したリクエストを格納する。アプリケーション部がリクエストを処理可能であるならば、バッファからリクエストを取り出し、アプリケーション部に転送する。このとき、バッファ中のリクエストのうち、最も古い整理番号を有するリクエストから優先的に選択する。すなわち、より長く実行を待ち合わせているリクエストから処理する。一方、アプリケーション部が処理可能でないならば、バッファ中で処理を待ち合わせる。

（３）
バッファで所定時間以上、待ち合わせているリクエストに関しては、バッファからリクエストを取り出し、送信元のクライアント装置に対してビジーメッセージを通知する。ビジーメッセージとして、サーバが混雑していること、および、このまま待機していれば自動的にサーバと接続されることが通知される。また、待機しているリクエスト数や予想待ち時間を併せて通知してもよい。ビジーメッセージにはさらに、リクエストの整理番号、そしてブラウザにリクエストの再送を促す命令が埋め込まれる。

（４）
クライアント装置のブラウザが、ビジーメッセージの内容を表示する。これにより、クライアントは、後どれくらい待てばリクエストが処理開始されるのかを知ることができる。故に、クライアント装置は、いつ接続できるかわからない状態で接続を待ち続けることのストレスから解放される。

（５）
ビジーメッセージに埋め込まれたリクエスト再送命令に従って、クライアント装置のブラウザはリクエストをＷｅｂサーバに対して自動再送する。これにより、クライアント装置のユーザが手動で再アクセスする手間を削減できる。同時に、クライアント装置のユーザが再アクセスを繰り返すことによるＷｅｂサーバの負荷上昇を回避できる。

（６）
再送されたリクエストをバッファに格納する。再送されたリクエストには整理番号が既に付与されているため、新たな整理番号を付与しない。また、図２のように、再送されたリクエストに対して再度ビジーメッセージを送信し、ブラウザの画面を更新させてもよい。

（７）
整理番号が最も古いリクエストとして、当該クライアント装置のリクエスト（整理番号“１０”）を選択し、アプリケーション部に転送する。

（８）
リクエストを処理してクライアント装置に対してレスポンスを返送する。

図２の例では、リクエストが再送された場合を除いて、全てのリクエストに対して整理番号を付与している。これに対してＷｅｂサービスでは、複数のリクエストの処理が完了することで、初めて全体として一つの処理が完了するセッション処理が存在する。このような処理に対して図２の方法をそのまま適用すると、以下の問題が生じる。
（リクエストレベルの応答時間とクライアント装置のユーザが体感できる応答時間との不一致）
セッション処理を構成する個々のリクエストを処理するたびに処理待ちが発生する。この結果、１つのセッション処理に要するリクエスト数が多いほど、セッション処理を完了するまでの時間が長くなる。

例えば、あるクライアント装置が、およそ１０リクエストから構成されるページにアクセスしたとする。このとき、リクエストの予想待ち時間を３０秒とする。この場合には、クライアント装置には、Ｗｅｂサーバからビジーメッセージが送られ、３０秒後にクライアント装置の順番が回ってくることが通知される。しかしながら、この３０秒という待ち時間は、１番目のリクエストが処理されるまでの待ち時間である。ブラウザがページの表示を完了するまでには、さらに３０秒×９リクエスト分の待ち時間が発生する。

このように実際に体感する待ち時間が通知された待ち時間より大きくなることは、殆どのクライアント装置のユーザに許容されないと考えられる。

（ビジーメッセージ表示における制限）
ブラウザの表示方法の制約から、セッション処理の２つ目以降のリクエストに対して返されたビジーメッセージの内容を、クライアント装置のブラウザに表示させることは困難である。

（計算コストの増加）
全てのリクエストをアプリケーション部に転送する際に、バッファから最も整理番号が古いリクエストを選び出す処理が必要となる。故に、リクエストを整理しない場合と比較して計算コストが増大する。

そこで本発明では、図２の実施例をセッション処理向きに拡張する。すなわち、整理部において、リクエストをセッション処理の１番目のリクエスト（以下、開始リクエスト）であるか、２つ目以降のリクエスト（以下、開始済みリクエスト）であるかを分類する。そして、開始リクエストに対してのみ、図２と同様にリクエストの処理順序を整理する。また、開始済みリクエストを、開始リクエストより優先的にアプリケーション部に転送する。

まず、開始済みリクエストを開始リクエストより優先的に処理させることで、サーバ混雑時において、新しいページ処理またはセッション処理の開始がブロッキングされる。このため、既に開始済みのページ処理またはセッション処理のリクエスト（すなわち、開始済みリクエスト）を、その応答時間を増加させることなく処理することができる。

ここで、前述の例のように、およそ１０リクエストから構成されるページがあったとする。この場合においても、開始リクエストの処理が待たされることがあっても、一旦、開始リクエストの処理が完了すると、残りの９リクエストの処理を、待たせることなく即時に完了できる。この結果、ビジーメッセージで通知した待ち時間と、実際にページが完了するまでの待ち時間とを、ほぼ等しくすることができる。

また、本手法では、開始済みリクエストにビジーメッセージが返されることがない。故に、ブラウザがページ処理の２つ目以降のリクエストに対するビジーメッセージを表示できなくても、その影響を受けない。さらに、多くの場合には、１つのページ、１つのセッションあたり数十以上ものリクエストから構成される。故に、全てのリクエストに対して処理順序を整理する場合と比較してその計算コストを大幅に削減できる。

本発明の整理部の実施例を詳述する。本実施手順は、セッション処理毎にリクエストの処理順序を整理する場合を示す。ただし、本実施手順のセッション処理を構成するリクエストが１つのみである場合、すなわち、全てのリクエストが開始リクエストとなる場合は、図２で示したようにリクエスト毎に処理順序を整理することに等しい。

図３は、整理部３のブロック図と、リクエストおよびレスポンスの主な流れを示している。整理部３は４つのブロックからなる。

（リクエスト受信部６）
リクエストを受信し、バッファ１０に格納する。このとき、セッション処理の開始リクエストに対して整理番号を付与する。

（リクエスト送信部７）
バッファ１０からリクエストを選択し、アプリケーション部４に転送する。

（ビジーメッセージ送信部８）
バッファ１０からリクエストを取り出し、ビジーメッセージをクライアント装置に返送する。

（レスポンス送信部９）
アプリケーション部４から受け取ったレスポンスを、そのリクエストの送信元に返送する。

図４はリクエスト受信部６の処理手順を示している。リクエスト受信部６は、整理部３と同時に起動され、「リクエスト受信待ち合わせ（Ｓ１）」にて、リクエストを受信するまで待ち合わせる。リクエストを受信する、「開始リクエスト？（Ｓ２）」に進む。

「開始リクエスト？（Ｓ２）」では、受信したリクエストがセッション処理の開始リクエストであるか否かを検証する。そして、開始リクエストである場合は「整理番号がある？（Ｓ３）」に進み、開始リクエストではない場合は「バッファにリクエストを格納（Ｓ５）」に進む。

セッション処理の開始リクエストであるか否かを判定する方法として、以下が挙げられる。

（ＵＲＬ）
セッション処理の開始リクエストに対応するＵＲＬを予め表に登録しておく。そして、受信したリクエストのＵＲＬが表中のリクエストのいずれかと一致した場合は、そのリクエストをセッション処理の開始リクエストであるとみなす。

（セッションＩＤの有無）
多くのＷｅｂアプリケーションでは、セッション処理を開始するときセッションを識別するためのＩＤ、すなわちセッションＩＤを発行してクライアント装置に通知する。そして、クライアント装置は、Ｗｅｂサーバにリクエストを送信する際にセッションＩＤも併せて送信する。これにより、Ｗｅｂアプリケーションは、クライアント装置から送信されてきたリクエストがいずれのセッションに属するかを知ることができる。

ＨＴＴＰでは、セッションＩＤをＣｏｏｋｉｅという仕組みを使って送受信することが典型である。そこで本発明では、受信したリクエストにセッションＩＤが付与されているか否かに基づいて開始リクエストであるか否かを判定する。

また、アプリケーション部４によって発行され、レスポンスと一緒に返送されたセッションＩＤを整理部３でキャッシュすることもできる。そして、クライアント装置から送信されたセッションＩＤをキャッシュしたセッションＩＤと比較することで、そのセッションＩＤが正しいか否かを検証できる。

また、セッションＩＤは、アプリケーション部４ではなく整理部３で発行してもよい。すなわち、あるクライアント装置から送信された１番目のリクエストを開始リクエスト、２つ目以降のリクエストを開始済みリクエストとみなす。そして、セッションＩＤを持たないリクエストの処理がアプリケーション部４で完了すると、セッションＩＤを発行し、そのレスポンスに挿入する。

開始リクエストである場合には「整理番号がある？（Ｓ３）」が実行される。「整理番号がある？（Ｓ３）」では、受信したリクエストに既に整理番号が付与されているか否かを判定する。ビジーメッセージ送信部８の説明にて詳述するが、整理番号はリクエストのＣｏｏｋｉｅヘッダフィールドやＵＲＬのクエリ部に格納される。

これらの箇所を検査し、整理番号が含まれていなかった場合は「整理番号を発行（Ｓ４）」に進む。整理番号が含まれていた場合は「バッファにリクエストを格納（Ｓ５）」に進む。

「整理番号を発行（Ｓ４）」では、整理番号が無いリクエストに対して整理番号を発行する。整理番号としては、図２の説明にて前述したように、カウンタ値、タイムスタンプなどが利用できる。

最後に「バッファにリクエストを格納（Ｓ５）」にて、受信したリクエストをバッファ１０に格納する。なお、バッファ１０中のリクエストの送信元のクライアント装置が、ＷｅｂサーバとのＴＣＰ接続を切断した場合は、バッファ１０中のリクエストも速やかに削除されるものとする。

次に、リクエスト送信部７の実行手順を図５に示す。

リクエスト送信部７は、整理部３と同時に起動され、「リクエストを処理可能となるまで待ち合わせ（Ｓ１０）」にて、アプリケーション部４がリクエストを処理可能となるまで待ち合わせる。アプリケーション部４がリクエストを処理可能であるか否かの判定法を以下に列挙する。

・アプリケーション部４のシステム使用率（ＣＰＵ使用率、メモリ使用量など）を定期的に測定する。システム使用率が予め定めた上限を超えていないならば、アプリケーション部４はリクエストを処理可能であると判定する。

・アプリケーション部４にリクエストを送信済みであるが、アプリケーション部４からレスポンスが返されていないリクエスト（以下、応答待ちリクエスト）の数が、予め定めた上限を超えていないならば、アプリケーション部４はリクエストを処理可能であると判定する。

・アプリケーション部４に接続されるＴＣＰコネクションの数が、予め定めた上限を超えていないならば、アプリケーション部４はリクエストを処理可能であると判定する。

アプリケーション部４がリクエストを処理可能になると、次に、「バッファにリクエストが存在？（Ｓ１１）」にて、バッファ１０中にリクエストが存在するか否かを検査する。バッファ１０にリクエストが格納されている場合は、「開始済みリクエストが存在？（Ｓ１４）」に進む。リクエストが格納されていない場合は、「バッファにリクエストが存在するまで待ち合わせ（Ｓ１２）」に進む。

「バッファにリクエストが存在するまで待ち合わせ（Ｓ１２）」では、リクエスト受信部６がバッファ１０に新しいリクエストを格納するまで実行を待ち合わせる。バッファ１０にリクエストが格納されると、「リクエストを処理可能？（Ｓ１３）」に進む。

「リクエストを処理可能？（Ｓ１３）」では、リクエストを待ち合わせている間にアプリケーション部４の負荷が変化し、リクエストを処理できない状態になっていないか再検査する。引き続きリクエストを処理可能である場合は、「開始済みリクエストが存在？（Ｓ１４）」に進む。処理可能でないならば、「リクエストを処理可能となるまで待ち合わせ（Ｓ１０）」に戻る。

「開始済みリクエストが存在？（Ｓ１４）」ではバッファ１０中に開始済みリクエストが存在するか否かを検査する。開始済みリクエストを優先的にアプリケーション部４で処理させるため、開始済みリクエストが存在する場合は「開始済みリクエストの選択（Ｓ１５）」に進む。存在しない場合は、「開始リクエストの選択（Ｓ１６）」に進む。

「開始済みリクエストの選択（Ｓ１５）」では、バッファ１０中の開始済みリクエストを一つ選択し、バッファ１０から取り出す。開始済みリクエストの選択基準として、ＦＩＦＯ(First In First Out)に従ってもよく、また、ＥＤＦ(Earliest Dead Line First)、Ｐｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇ、ＷＲＲ／ＷＦＱ(Weighted
Round Robin/Weighted Fair Queuing)などの優先制御アルゴリズムを用いてもよい。

「開始リクエストの選択（Ｓ１６）」では、バッファ１０中の開始リクエストを一つ選択し、バッファ１０から取り出す。このとき、リクエストの選択基準として、最も古い整理番号を有するリクエストを選択する。これにより、元の開始リクエストを受信した順番にほぼ従って、開始リクエストを処理していくことが可能になる。

最後に「選択したリクエストを送信（Ｓ１７）」にて、選択したリクエストをアプリケーション部４に送信する。

図６にビジーメッセージ送信部８の処理手順を示す。ビジーメッセージ送信部８は、整理部３と同時に起動される。そして、定期的にバッファ１０中の開始リクエストを対象として、ビジーメッセージを送信すべきか否かを検査する。所定の条件を充足する開始リクエストを見つけると、その送信元のクライアント装置にビジーメッセージを送信する。ビジーメッセージには、サーバ装置の現在の混雑状況に関するメッセージ、整理番号、そしてクライアント装置との接続を維持するためのリクエスト再送命令が埋め込まれる。

まず、定期的に検査を実施するため、「所定時間待ち合わせ（Ｓ２０）」にて、次の検査実施まで待ち合わせる。所定時間が経過すると「未検査の開始リクエストを選択（Ｓ２１）」からのループで、バッファ１０中の全ての開始リクエストに対し、ビジーメッセージの送信の是非を判定する。

まず、「未検査の開始リクエストを選択（Ｓ２１）」にて、バッファ１０から検査が済んでいない開始リクエストを一つ選択する。

次に「ビジーメッセージ送信すべき？（Ｓ２２）」にて、当該開始リクエストに対してビジーメッセージを送信すべきか否かを判定する。ビジーメッセージを送信すべきと判定された開始リクエストについては「選択したリクエストの取り出し（Ｓ２３）」に進む。送信すべきでないと判定された場合は、「全開始リクエストを検査？（Ｓ２５）」に進む。ビジーメッセージ送信の是非を判定するための方法を以下に列挙する。

（バッファ１０に格納され続けている時間）
バッファ１０に格納され続けている時間が所定の時間を越えている場合に、ビジーメッセージを送信すべきと判定する。クライアント装置のユーザはＷｅｂサーバにアクセスしても暫く反応が無い場合には再アクセスを試みたり、接続を遮断して他のサイトに移動してしまったりする。このような事態を避けるため、クライアント装置のユーザに、サーバ装置が混雑していること、および接続を試みている最中であることを継続的に認識させる必要がある。

故に、本発明では、バッファ１０で格納されている時間（すなわち、クライアント装置に対して反応を返していない時間）が所定時間を越えるたびに、ビジーメッセージをクライアント装置に通知し、ブラウザ上の画面を更新させる。

なお、注目するリクエストが、クライアント装置が最初に送ったリクエストであるが、ビジーメッセージによって再送されたリクエストであるかに応じてバッファ１０に格納できる時間を変更してもよい。例えば、クライアント装置が最初に送ったリクエストについては、Ｗｅｂサーバの混雑を迅速に通知するため、数秒以内にクライアント装置にビジーメッセージを送ることができる。

その一方で、再送されたリクエストに対してはクライアント装置は、既にサーバ装置の混雑を知っているため、数十秒おきにビジーメッセージを送る（または、ビジーメッセージを送らない）こともできる。

（バッファ１０に格納されているリクエスト数）
バッファ溢れを防ぐため、バッファ１０中の開始リクエスト数がその上限を越えている場合には、越えている分の開始リクエストに対してビジーメッセージを通知する。このとき、整理番号が新しい開始リクエストからビジーメッセージを返すようにする。

例えば、バッファ１０に格納できるリクエストの上限をＳとし、現在の開始リクエストの数をＳｃとする。また、ある開始リクエストＲｉ（ｉ＝１、…、Ｓｃ）の整理番号の順番をＯｉ（Ｏｉ＝０、…、Ｓｃ）としたとする。このとき、Ｏｉ＞Ｓであるリクエストに対してビジーメッセージを通知すべきと判定する。

「選択したリクエストの取り出し（Ｓ２３）」では、ビジーメッセージを送信すべきと判定された開始リクエストをバッファ１０から取り出す。「ビジーメッセージの作成と送信（Ｓ２４）」に進む。

「ビジーメッセージの作成と送信（Ｓ２４）」では、ビジーメッセージを作成し、リクエストの送信元であるクライアント装置に返送する。このとき、ビジーメッセージに含むことができる項目を以下に列挙する。

（リクエスト再送命令：必須項目）
クライアント装置とＷｅｂサーバとの間の接続を維持するため、ビジーメッセージにリクエスト再送命令が埋め込まれる。クライアント装置のブラウザは、サーバ装置の混雑状況を表示後、リクエスト再送命令に従って、Ｗｅｂサーバに対してリクエストを再送する。ブラウザにリクエストを再送させる方法として、３００番台のステータスコードを返す方法、ｍｅｔａタグを返す方法、およびＪａｖａ（登録商標）Ｓｃｒｉｐｔを使う方法などが利用できる。

ブラウザは、３０２、３０３、３０７のステータスコードを持つレスポンスを受信すると、レスポンスのＬｏｃａｔｉｏｎヘッダフィールドの指示されるＵＲＬに対して再アクセスを試みる。故に、ビジーメッセージのステータスコードとして３０２、３０３、３０７を用いることで、ブラウザにリクエストの再送を指示できる。また、ｍｅｔａタグを利用する場合は、返送するビジーメッセージに、ｈｔｔｐ−ｅｑｕｉｖ属性が“Ｒｅｆｒｅｓｈ”であるｍｅｔａタグを埋め込んでおけばよい。

例えば、ビジーメッセージの中にｍｅｔａタグとして＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝″Ｒｅｆｒｅｓｈ″ｃｏｎｔｅｎｔ＝″１５：ＵＲＬ＝“開始リクエストのＵＲＬ”＞を埋め込んだとする。この場合にブラウザは、ビジーメッセージ受信後１５秒後に、開始リクエストのＵＲＬに対して再アクセスを試みる。

また、ＪａｖａＳｃｒｉｐｔを利用する場合は、関数ｌｏｃａｔｉｏｎ．ｒｅｌｏａｄ（）と関数ｓｅｔＴｉｍｅｏｕｔ（）を組み合わせることで、所定の時間後にＷｅｂサーバに対して再アクセスすることが可能である。

また、クライアント装置のユーザが操作する手間が増えるが、クライアント装置のユーザに再送の是非を判断させることもできる。例えば、ブラウザに「只今大変混雑しています。順番待ちをされる場合は、以下のＵＲＬをクリックしてください。」というようなメッセージを表示させる。そして、クリックした際のリンク先ＵＲＬとして、リクエストの再送先を指定すればよい。

（整理番号：必須項目）
当該リクエストの整理番号をビジーメッセージに埋め込む。そして、クライアント装置がリクエストを再送する際に、当該整理番号もリクエストに付与されるようにする。整理番号をクライアント装置に送り返すための手法として、Ｃｏｏｋｉｅ、ＵＲＬの書換えなどが利用できる。

Ｃｏｏｋｉｅを使用する場合は、ビジーメッセージのＳｅｔ−Ｃｏｏｋｉｅヘッダフィールドに、整理番号をセットするのみでよい。クライアント装置のブラウザがＣｏｏｋｉｅに対応している限り、セットした整理番号がリクエストのＣｏｏｋｉｅヘッダフィールドに付与されて返送される。

Ｃｏｏｋｉｅによる実装は容易であるが、クライアント装置がＣｏｏｋｉｅに非対応である場合がある。この問題を解消するため、リクエスト再送先ＵＲＬに整理番号を埋め込む方法も考えられる。例えば、リクエストの再送先として、元のリクエストのＵＲＬのクエリに整理番号を付加したＵＲＬを指定すればよい。

すなわち、元のリクエストのＵＲＬをｗｗｗ．ｘｘｘ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌとし、整理番号が１０であったとする。また、整理番号を表す変数名をｒｅｃｖ＿ｎｏとすると、再送先のＵＲＬはｗｗｗ．ｘｘｘ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ？ｒｅｃｖ＿ｎｏ＝１０となる。そして、整理部３からアプリケーション部４にリクエストを送信する際に、ＵＲＬに付加されている整理番号を削除する。

（待機リクエスト数：オプション）
バッファ１０中の開始リクエストのうち、当該開始リクエストより古い整理番号を有する開始リクエストの数をクライアント装置に通知する。

（予想待ち時間：オプション）
ある開始リクエストがアプリケーション部４に送信されてから、次の開始リクエストがアプリケーション部４に送信されるまでの平均間隔（以下、平均リクエスト処理間隔）を計測しておく。そして、予測待ち時間として、
平均リクエスト処理間隔×待機リクエスト数

をクライアント装置に通知する。また、リクエスト再送命令でブラウザに再接続するまでの待ち時間を指定できる場合（ｍｅｔａタグ、ＪａｖａＳｃｒｉｐｔを使用する場合）は、待ち時間として（ｋ×予想待ち時間）を指定してもよい。ここでｋは任意の定数とする。予測待ち時間を基に再接続すべき時間を制御することで、バッファ１０中に蓄積されるリクエスト数や、リクエストが再送される回数を削減することができる。

最後に、「全開始リクエストを検査？（Ｓ２５）」にて、バッファ１０中の全ての開始リクエストの検査が完了したか判定する。未検査の開始リクエストが存在する場合は、「未検査の開始リクエストを選択（Ｓ２１）」に戻り、検査を継続する。全リクエストの検査を完了した場合は、「所定時間待ち合わせ（Ｓ２０）」に戻り、次の検査実施まで待ち合わせる。

レスポンス送信部９は、アプリケーション部４から受信したレスポンスを、リクエストの送信元であるクライアント装置に対して転送する。

（プログラムの実施例）
汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、本実施例のＷｅｂサーバに相応する機能を実現させるプログラムとしての実施例を例示することができる。

ここで、汎用の情報処理装置とは、例えば、前述した計算機である。前述したように、一つの計算機で整理部３とアプリケーション部４とを実行させても、異なる計算機で実行させてもよい。異なる計算機で実行する場合は、整理部３を負荷分散装置、Ｗｅｂアクセラレータ、アプリケーションゲートウェイ、リバースプロキシといった前段装置に実装し、アプリケーション部４を一般のＰＣサーバ上に実装できる。

本実施例のプログラムは記録媒体に記録されることにより、前記汎用の情報処理装置は、この記録媒体を用いて本実施例のプログラムをインストールすることができる。あるいは、本実施例のプログラムを保持するサーバ装置からネットワークを介して直接前記汎用の情報処理装置に本実施例のプログラムをインストールすることもできる。

これにより、汎用の情報処理装置を用いて、本実施例のＷｅｂサーバに相応する機能を実現することができる。

なお、本実施例のプログラムは、汎用の情報処理装置によって直接実行可能なものだけでなく、ハードディスクなどにインストールすることによって実行可能となるものも含む。また、圧縮されたり、暗号化されたりしたものも含む。

本発明によれば、サーバ装置が混雑している状況であっても、クライアント装置は、ユーザによる新たな操作無しでサーバ装置に接続することができる。これにより、ユーザにとってはサービス品質の向上を図ることができる。また、ユーザによる無計画なリクエスト再送の繰り返しや他サイトへの移行を回避できるので、ネットワーク運営者にとっては効率の良いネットワーク運営を図ることができる。

本実施例のリクエスト整理システムの全体構成図。 リクエストの流れを示す図。 整理部のブロック構成およびリクエスト・レスポンスの主な流れを示す図。 リクエスト受信部の処理手順を示すフローチャート。 リクエスト送信部の処理手順を示すフローチャート。 ビジーメッセージ送信部の処理手順を示すフローチャート。

符号の説明

１−１〜１−ｎ クライアント装置
２ Ｗｅｂサーバ
３ 整理部
４ アプリケーション部
５ インターネット
６ リクエスト受信部
７ リクエスト送信部
８ ビジーメッセージ送信部
９ レスポンス送信部
１０ バッファ

Claims (6)

1. クライアント装置から送信されたリクエストを受信して処理しその結果をレスポンスとして前記クライアント装置に返送するサーバ装置において、
   クライアント装置から受信したリクエストに整理番号が付与されているか否かを判定する判定手段と、
   リクエストが到着した順番を比較するための整理番号を、前記判定手段の結果に基づいて整理番号が付与されていないリクエストに対して付与する手段と、
   この整理番号を付与したリクエストを格納できるリクエスト数に上限が設けられているバッファに格納しその処理を待ち合わせる手段と、
   バッファに格納されているリクエスト数がその上限値を超えた場合にはより新しい整理番号を持つリクエストをバッファから取り出す手段と、
   バッファから取り出されたリクエストの送信元のクライアント装置に対して、当該リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信する手段と、
   バッファ中で待ち合わせているリクエストの内、古い整理番号を持つリクエストから優先的に処理する手段と、
   を備えることを特徴とするサーバ装置。
2. クライアント装置から送信されたリクエストを受信して処理しその結果をレスポンスとして前記クライアント装置に返送し、かつ複数リクエストの処理を全て完了することにより初めて全体として一つの処理が完了するセッション処理を実行するサーバ装置において、
   クライアント装置から受信したリクエストが、前記セッション処理の１番目のリクエストであるセッション処理の開始リクエストであるか、２番目以降のリクエストであるセッション処理の開始済みリクエストであるかを、受信したリクエストのＵＲＬ、または受信したリクエストに付与されたセッションＩＤの有無に基づき判断する手段と、
   セッション処理の開始リクエストに整理番号が付与されているか否かを判定する手段と、
   セッション処理の開始リクエストが到着した順番を比較するための整理番号を、リクエスト受信時に整理番号が付与されていなかったセッション処理の開始リクエストに対して付与する手段と、
   クライアントから受信したリクエストを格納できるリクエスト数に上限が設けられているバッファに格納しその処理を待ち合わせる手段と、
   バッファに格納されているリクエスト数がその上限値を超えた場合により新しい整理番号を持つセッション処理の開始リクエストをバッファから取り出す手段と、
   バッファから取り出されたセッション処理の開始リクエストの送信元のクライアント装置に対して、当該セッション処理の開始リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信する手段と、
   バッファ中で待ち合わせているリクエストの内、セッション処理の開始済みリクエストをセッション処理の開始リクエストより優先して処理し、さらにセッション処理の開始リクエスト同士の間では、より古い整理番号を有するセッション処理の開始リクエストほど優先的に処理する手段と、
   を備えることを特徴とするサーバ装置。
3. 所定時間内に処理されなかったリクエストに対するビジーメッセージに、当該リクエストの予測待ち時間を付与する手段と、
   整理番号が付与された一つのリクエストが処理されてから整理番号が付与された次のリクエストが処理されるまでの平均間隔である平均リクエスト処理間隔とを計測し、また処理を待ち合わせているリクエストのうち当該リクエストよりも古い整理番号を有するリクエストの数である待機リクエスト数を計測し、前記予測待ち時間を前記平均リクエスト処理間隔と前記待機リクエスト数との乗算により計算する手段と
   を備えたことを特徴とする請求項１または２記載のサーバ装置。
4. クライアント装置から送信されたリクエストを受信して処理しその結果をレスポンスとして前記クライアント装置に返送するサーバ装置が実行するリクエスト整理方法において、
   クライアント装置から受信したリクエストに整理番号が付与されているか否かを判定するステップと、
   リクエストが到着した順番を比較するための整理番号を、前記判定手段の結果に基づいて整理番号が付与されていないリクエストに対して付与するステップと、
   この整理番号を付与したリクエストを格納できるリクエスト数に上限が設けられたバッファに格納しその処理を待ち合わせるステップと、
   バッファに格納されているリクエスト数がその上限値を超えた場合にはより新しい整理番号を持つリクエストをバッファから取り出し、またはバッファ内で待ち合わせている時間がその閾値を超えたリクエストをバッファから取り出すステップと、
   バッファから取り出されたリクエストの送信元のクライアント装置に対して、当該リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信するステップと、
   バッファ中で待ち合わせているリクエストの内、古い整理番号を持つリクエストから優先的に処理するステップと、
   を実行することを特徴とするリクエスト整理方法。
5. クライアント装置から送信されたリクエストを受信して処理しその結果をレスポンスとして前記クライアント装置に返送し、かつ複数リクエストの処理を全て完了することにより初めて全体として一つの処理が完了するセッション処理を実行するサーバ装置が実行するリクエスト整理方法において、
   クライアント装置から受信したリクエストが、前記セッション処理の１番目のリクエストである開始リクエストであるか、２番目以降のリクエストであるセッション処理の開始済みリクエストであるかを、受信したリクエストのＵＲＬ、または受信したリクエストに付与されたセッションＩＤの有無に基づき判断するステップと、
   セッション処理の開始リクエストに整理番号が付与されているか否かを判定するステップと、
   セッション処理の開始リクエストが到着した順番を比較するための整理番号を、リクエスト受信時に整理番号が付与されていなかったセッション処理の開始リクエストに対して付与するステップと、
   クライアントから受信したリクエストを格納できるリクエスト数に上限が設けられているバッファに格納しその処理を待ち合わせるステップと、
   バッファに格納されているリクエスト数がその上限値を超えた場合により新しい整理番号を持つセッション処理の開始リクエストをバッファから取り出すステップと、
   バッファから取り出されたセッション処理の開始リクエストの送信元のクライアント装置に対して、当該セッション処理の開始リクエストを整理番号を付与した状態で再送させる命令を埋め込んだビジーメッセージを返信するステップと、
   バッファ中で待ち合わせているリクエストの内、セッション処理の開始済みリクエストをセッション処理の開始リクエストより優先して処理し、さらにセッション処理の開始リクエスト同士の間では、より古い整理番号を有するセッション処理の開始リクエストほど優先的に処理するステップと、
   を実行することを特徴とするリクエスト整理方法。
6. 汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、請求項１ないし３のいずれか記載のサーバ装置に相応する機能を実現させることを特徴とするプログラム。

Images