JP4736407B2 - 中継装置 - Google Patents

Description

本発明は、輻輳制御方法に係り、特に、クライアントとサーバ間のデータ通信における輻輳制御方法に関する。

インターネットが急速に普及し、チケット予約や銀行・証券取引等、従来営業店窓口で行われていたサービスもインターネットを介して提供されるようになってきた。また、通信技術も進歩し、家庭やオフィスからだけでなく携帯電話などからでもサービスを享受できる環境が整ってきた。

しかし、各クライアントが直接サーバにサービス要求をする従来の方式では、クライアントの要求がサーバに集中する。その結果、数多くの利用者からの要求に通信回線容量や処理するサーバ装置の能力が対応できず、時間帯やアクセス先によっては、利用者がいくら要求をしてもなかなか応答が返ってこないという場合が発生するようになってきた。

この点に関しては、一般に、Ｗｅｂ通信中継装置を設置することで改善できる。クライアントからの要求は、Ｗｅｂ通信中継装置と呼ばれる中継処理装置を経由して処理する。Ｗｅｂ通信中継装置では、過去の通信内容の一部を記憶（キャッシュという）する記憶部（キャッシングモジュール）を設置することにより、記憶した通信に関しては、サーバへ接続することなく要求を処理できる。プロキシ装置は、その有効性から多数の通信システムで導入されている。

現在では、１０００万人規模のユーザを対象とする通信システムに大規模Ｗｅｂ通信中継装置が設置されるようになってきた。このような通信システムでは、大規模Ｗｅｂ通信中継装置に対する要求が過剰に集中する。要求の集中が起こると、通信路の混雑や装置の負荷が上昇するため、ユーザは通信システムが提供するサービスを利用しにくくなる。また、過度な集中が継続すると大規模Ｗｅｂ通信中継装置に障害（輻輳）が発生し動作を停止する可能性がある。大規模Ｗｅｂ通信中継装置の動作が停止すると通信システムとして機能しなくなり、通信システムを利用する全ユーザがサービスを利用できなくなる。

本発明では、以上の点を鑑み、大規模Ｗｅｂ通信中継装置を主としたＷｅｂ通信中継装置に発生する障害を回避、軽減することを目的とする。

上記の課題を解決するため、本発明では、例えば、Ｗｅｂ通信中継装置がユーザの要求する通信内容ごとに要求処理の制御を変更する機構を設ける。Ｗｅｂ通信中継装置の負荷が上昇するのを避けるために、実施する制御を判定する機構は、新たな処理部を設けるのではなく、Ｗｅｂ通信中継装置に従来から存在する記憶部（キャッシングモジュール）を利用する。

Ｗｅｂ通信中継装置は、現在装置が行っている通信内容と装置の状態を検証したうえで、新たに到着した要求に対する処理方針を決定する。これにより、省略できる通信を検出でき、通信量の削減することで、Ｗｅｂ通信中継装置が輻輳状態に陥ることを回避する。また、輻輳の原因となる通信処理を通常の処理とは異なる方法で処理する。例えば、輻輳の原因となる通信を優先的に記憶する。これによりＷｅｂ通信中継装置が輻輳状態に陥るのを回避する。

Ｗｅｂ通信中継装置は、要求に対する制御を決定する過程で、輻輳状態に近づいている通信を検出する。輻輳状態に近い通信に関しては、輻輳が改善されるまで処理をせず、ユーザに対して通信を控えるようアナウンスする。これにより、輻輳状態の悪化を防止し、Ｗｅｂ通信中継装置が障害で利用不能となるのを回避する。

本発明の大規模Ｗｅｂ通信中継装置では、ユーザが送信する要求を負荷分散装置で受信する。負荷分散装置は、大規模Ｗｅｂ通信中継装置内に設置した複数のＷｅｂ通信中継装置に負荷を分散して送信する。Ｗｅｂ通信中継装置では、キャッシングモジュールがユーザの要求を判断し、Ｗｅｂ通信中継装置が行う制御を決定する。輻輳制御の種類としては、要求集約、優先キャッシュ、アクセス抑止、アクセス監視および規制の４つがある。

複数のユーザがキャッシュ可能なサービスの要求を行い、かつ、Ｗｅｂ通信中継装置がサーバに通信する必要がある場合、Ｗｅｂ通信中継装置は、サーバに対しては複数の要求が１つの要求に集約して通信する。これにより、Ｗｅｂ通信中継装置とサーバ間の通信量が削減する。また、サーバに対する要求が減少するため、サーバの負荷が上昇するのを防止する。Ｗｅｂ通信中継装置がサーバに対して行う輻輳を回避し、負荷も軽減するため、Ｗｅｂ通信中継装置は、ユーザに迅速に応答できる。

本発明のＷｅｂ通信中継装置は、特定のサービスを優先的にキャッシングする方法を提供する。この方法を利用して、通信システム提供者は輻輳の原因となるサービスを優先的にキャッシングするよう登録できる。従来の方法では、キャッシングするデータに優先、非優先の区別がないため、重要なデータをＷｅｂ通信中継装置内で保持しつづけることができなかった。しかし、この方法により、Ｗｅｂ通信中継装置は、ユーザが必要とするデータを保持できる。ユーザは、より多くのサービスを高速に受けることできる。

本発明のＷｅｂ通信中継装置は、特定のサービスをユーザが利用するのを抑止する方法を提供する。この方法を利用して、通信システム提供者は、輻輳の原因となり通信システムが提供すべきではないサービスをユーザに提供しないことができる。提供しないサービスに関する要求には、Ｗｅｂ通信中継装置がユーザに対して提供できない旨の返答を行い要求処理が終了する。

従来では、抑止機構を持たないため、Ｗｅｂ通信中継装置は不要なサーバとの通信に資源を浪費していた。また、ユーザは、要求したサービスが提供されないまま待ち続けたり、何度も通信を試みる可能性があった。本発明の方法を利用することで、サービスが提供されないことが迅速に把握できる。

本発明のＷｅｂ通信中継装置は、サービス接続数が確認できる要求について、その接続数を計測する。要求集約が不可能な要求にもかかわらず、同一の要求が非常に多い場合は、一定数以上の要求を接続不可として処理できる。この際、Ｗｅｂ通信中継装置は、ユーザに対して要求結果として接続不可の理由を通知する。これにより、サーバの負荷を軽減するとともにＷｅｂ通信中継装置の輻輳を回避する。また、ユーザは、要求したサービスが提供されないまま待つことなく、サービスの提供状況を把握できる。

本発明の第１の解決手段によると、クライアント端末とサーバ装置の間に設けられた通信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッシュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクライアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッドチェックステップと、前記メソッドチェックステップによりキャッシュ可であると判断された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行いキャッシュ可又は不可かを判断する第１ＵＲＩチェックステップと、前記第１ＵＲＩチェックステップによる判断に従い、キャッシュ可であれば、ＵＲＩハッシュの検索を行い、通常キャッシュ、優先キャッシュ又はアクセス抑止のいずれかの処理が行われるか決定する第１ＵＲＩハッシュ検索ステップと、前記第１ＵＲＩハッシュ検索ステップによる決定に従い、通常キャッシュ処理、優先キャッシュ処理又はアクセス抑止処理のいずれかの処理を行うステップとを含む輻輳制御方法を提供する。

本発明の第２の解決手段によると、クライアント端末とサーバ装置の間に設けられた通信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッシュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクライアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッドチェックステップと、前記メソッドチェックステップによりキャッシュ不可であると判断された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行う第２ＵＲＩチェックステップと、ＵＲＩハッシュの検索を行い、アクセス抑止又はアクセス監視・規制のいずれかの処理が行われるか決定する第２ＵＲＩハッシュ検索ステップと、前記第２ＵＲＩハッシュ検索ステップによる決定に従い、アクセス抑止処理又はアクセス監視・規制処理のいずれかの処理を行うステップとを含む輻輳制御方法を提供する。

本発明の第３の解決手段によると、クライアント端末とサーバ装置の間に設けられた通信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッシュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクライアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッドチェックステップと、前記メソッドチェックステップによりキャッシュ可であると判断された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行いキャッシュ可又は不可かを判断する第１ＵＲＩチェックステップと、前記第１ＵＲＩチェックステップによる判断に従い、キャッシュ可であれば、ＵＲＩハッシュの検索を行い、通常キャッシュ又は優先キャッシュのいずれかの処理が行われるか決定する第１ＵＲＩハッシュ検索ステップと、前記メソッドチェックステップによりキャッシュ不可であると判断された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行う第２ＵＲＩチェックステップと、前記第１ＵＲＩチェックステップによる判断によりキャッシュ不可である場合又は前記第２ＵＲＩチェックステップを経て移行され、ＵＲＩハッシュの検索を行い、アクセス抑止又はアクセス監視・規制のいずれかの処理が行われるか決定する第２ＵＲＩハッシュ検索ステップと、前記第１又は第２ＵＲＩハッシュ検索ステップによる決定に従い、通常キャッシュ処理、優先キャッシュ処理、アクセス抑止処理、アクセス監視・規制処理のいずれかの処理を行うステップとを含む輻輳制御方法を提供する。

本発明を利用することにより、通信システム提供者は、従来よりも信頼性のある通信システムをユーザに提供することができる。また、ユーザは、従来よりも少ない待ち時間で応答の得られる通信システムを利用できる。

Ａ．ハード構成と概略構成
図１に、通信システムの構成図を示す。通信システム１００は、例えば、クライアント端末１−１〜１−ｉと、大規模Ｗｅｂ通信中継装置２と、Ｗｅｂ通信装置３−１〜３−ｊとを含む。クライアント端末１−１〜１−ｉは、例えば、Ｗｅｂコンテンツの取得（アクセス）要求、データ送受信、画面表示等を行うユーザ用（端末）装置である。Ｗｅｂ通信装置３−１〜３−ｊは、例えば、クライアント端末１−１〜１−ｉからの要求に応じてＷｅｂコンテンツを送出する装置であって、ディスク容量を上限としてコンテンツデータを格納している。なお、本実施の形態では、主に大規模なＷｅｂ通信装置について説明しているが、これに限らず、本発明は、適宜の規模の通信装置に適用することができる。

大規模Ｗｅｂ通信中継装置２は、例えば、データ中継装置２１と、認証装置２２と、システム管理装置２３と、レイヤ７負荷分散装置２４と、Ｗｅｂ通信中継装置２５−１〜２５−ｎと、アクセス規制装置２６とを備える。

データ中継装置２１は、例えば、大規模Ｗｅｂ通信中継装置２内外の各装置、Ｗｅｂ通信装置３−１〜３−ｊ及びクライアント端末１−１〜１−ｉとの間でデータ送受信を中継する装置であって、送受信データパケットのヘッダーに記された宛先装置へパケットを転送する。認証装置２２は、大規模Ｗｅｂ通信中継装置２が提供する中継サービスが、予め登録された（正規の）クライアント端末１−１〜１−ｉと正規のＷｅｂ通信装置３−１〜３−ｊ間のものであることを認証するための装置であって、ユーザ情報やサービス情報を登録したデータベースを備える。システム管理装置２３は、例えば、大規模Ｗｅｂ通信中継装置２内の各装置を集中的に管理するための装置である。

レイヤ７負荷分散装置２４は、例えば、複数のクライアント端末１−１〜１−ｉからのＷｅｂコンテンツ取得要求を、複数のＷｅｂ通信中継装置２５−１〜２５−ｎに振分け、中継処理の負荷を分散する装置であって、送受信パケットヘッダーや、Ｗｅｂコンテンツ要求・送信ヘッダーに記された宛先等の記述を解釈して振分け経路を定め、受信したデータパケットをその経路へ送信する。Ｗｅｂ通信中継装置２５−１〜２５−ｎは、例えば、クライアント端末１−１〜１−ｉからのＷｅｂコンテンツ取得要求を受け付け、Ｗｅｂ通信装置３−１〜３−ｊに要求を中継したり、クライアント端末１−１〜１−ｉとＷｅｂ通信装置３−１〜３−ｊ間のデータ送受信を中継する装置である。アクセス規制装置２６は、例えば、多量のＷｅｂコンテンツ取得要求が短時間に集中した場合に、大規模Ｗｅｂ通信中継装置２の処理限界を超えないよう、アクセス量（取得要求量）を規制するための装置である。

図２に、Ｗｅｂ通信中継装置の構成図を示す。Ｗｅｂ通信中継装置２５−１は、例えば、主記憶装置３０と、この主記憶装置３０に記憶されたＷｅｂ通信中継ソフトウェア３１と、入出力装置３２と、プロセッサ３３と、レイヤ７負荷分散装置２４とデータパケットの送受信を行う通信装置３４と、二次記憶装置３５と、これらの各部材を相互の接続するバス３６とを備える。

二次記憶装置３５は、例えば、磁気ディスクなどの装置（不揮発性記憶装置）であって、プログラム及び各種の設定ファイルを記憶する。二次記憶装置３５は、以下のような役割を担う。
（１）Ｗｅｂ通信中継装置２５−１のＯＳ（オペレーティングシステム）データを格納し、装置起動時にそのデータが主記憶装置３０にロードされる。
（２）ＯＳ上で動作する様々なアプリケーションプログラム（データ・設定ファイル）を格納し、アプリケーションの起動時に主記憶装置３０にロードされる。
（３）Ｗｅｂ通信中継装置２５−１が中継するＷｅｂコンテンツデータをキャッシュデータとして格納する。

なお、実施例のＷｅｂ通信中継装置では、クライアントからの要求をセッションと呼ばれる処理単位で処理している（１つの要求が１つのセッションに対応する）。セッションがキャッシュを用いる際にキャッシュエントリを確保する。セッションがサーバと通信してキャッシングをするときは、キャッシュエントリを所有している必要がある。本輻輳制御方式は、個々のセッション処理の中で行われる。

図３は、大規模Ｗｅｂ通信中継装置におけるデータの送受信についての説明図である。なお、説明の便宜上、上述した部材と同一部材には同一符号を付し、構成、機能は同様である。また、各Ｗｅｂ通信中継装置２５−１〜２５−ｎは同様の構成であるので、ここでは、Ｗｅｂ通信中継装置２５−１について説明する。

Ｗｅｂ通信中継ソフトウェア３１は、Ｗｅｂ通信中継装置２５−１に記憶されており、例えば、ＨＴＴＰモジュール４１と、キャッシングモジュール４２と、プロキシエンジン４３とを含む。ここで、図中のデータａ〜ｄは、ａ：クライアント端末１−１〜１−ｉの要求、ｂ：Ｗｅｂ通信中継ソフトウェア３１の応答、ｃ：Ｗｅｂ通信中継ソフトウェア３１の要求、ｄ：Ｗｅｂ通信装置３−１〜３−ｊの応答をそれぞれ示す。

なお、キャッシュヒットのときは、データａ、ｂのみが通信路を流れる（図４参照）。また、キャッシュミスヒットのときは、データａ、ｃ、ｄ，ｂの順でデータが通信路を流れる（図５参照）。以下に各処理について概略説明する。

ａ：クライアントの要求
まず、クライアント端末１−１〜１−ｉからクライアント要求が送信されると、大規模Ｗｅｂ通信中継装置２は、それを受信する。大規模Ｗｅｂ通信中継装置２のデータ中継装置２１では、要求をレイヤ７負荷分散装置２４に転送し、レイヤ７負荷分散装置２４は、いずれかのＷｅｂ通信中継装置（ここでは、Ｗｅｂ中継装置２５−１）に送る。Ｗｅｂ通信中継装置２５−１内のＷｅｂ通信中継ソフトウェア３１では、プロキシエンジン４３を経て、ＨＴＴＰモジュール４１とキャッシングモジュール４２が、そのクライアント要求を受信する。

ｂ：Ｗｅｂ通信中継ソフトウェアの応答
つぎに、クライアント要求を受信したＷｅｂ通信中継装置２５−１は、通信内容を解析する。ここで、Ｗｅｂ中継装置２５−１が、クライアント要求に対応しているＷｅｂページをキャッシュで記憶している場合、その内容をレイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１へ送信する。

ｃ：Ｗｅｂ通信中継ソフトウェアの応答
一方、Ｗｅｂ中継装置２５−１が、クライアント要求に対応しているＷｅｂページをキャッシュで記憶していない場合、及び／又はクライアント要求にキャッシュ利用不可の指示がある場合、Ｗｅｂ中継装置２５−１は、クライアント要求に関する情報を、レイヤ７負荷分散装置２４、データ中継装置２１を経て、Ｗｅｂ通信装置３−１〜３−ｊの該当する装置へ送信する。

ｄ：Ｗｅｂ通信装置の応答
Ｗｅｂ通信装置３−１〜３−ｊは、クライアント要求を受信すると、クライアント端末に、データ中継装置２１を介してクライアント要求に対応するＷｅｂページを応答する。さらに、データ中継装置２１は、レイヤ７負荷分散装置２４を経てＷｅｂ中継装置２５−１に、その通信内容やＷｅｂページを転送する。Ｗｅｂ中継装置２５−１では、そのＷｅｂページをキャッシングモジュール４２にキャッシュする。

図４は、キャッシュヒット時の説明図及びシーケンス図である。なお、ここでのシーケンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉからの要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシングモジュール４２に入力され、ここで、キャッシュヒットと判定される。つぎに、Ｗｅｂページは、Ｗｅｂ通信中継ソフトウェア３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１〜１−ｉに送信される。

図５は、キャッシュミスヒット時の説明図及びシーケンス図である。なお、ここでのシーケンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉからの要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシングモジュール４２に入力され、ここで、キャッシュミスヒットと判定される。つぎに、Ｗｅｂ通信中継ソフトウェア３１の要求信号（データｃ）が、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、Ｗｅｂ通信装置３−１〜３−ｊに送信される。さらに、これに応答してＷｅｂ通信装置３−１〜３−ｊのＷｅｂページを含む応答信号（データｄ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシングモジュール４２に入力される。つぎに、Ｗｅｂページは、Ｗｅｂ通信中継ソフトウェア３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１〜１−ｉに送信される。

図６は、輻輳時の説明図及びシーケンス図である。なお、ここでのシーケンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉからの要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシングモジュール４２に入力される。

ここで、Ｗｅｂ通信中継ソフトウェア３１は、例えば、Ｗｅｂ通信装置３−１〜３−ｊが輻輳中の場合、規制コンテンツを生成する。ここで、例えば、ある一定以上の要求がひとつのＷｅｂページに集中した場合、輻輳と判断される。この規制コンテンツは、データｂに含まれ、クライアント端末１−１〜１−ｉに送信される。その際、規制コンテンツは、Ｗｅｂ通信中継ソフトウェア３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１〜１−ｉに送信される。

図７は、アクセス抑止対象コンテンツが要求された場合の説明図及びシーケンス図である。なお、ここでのシーケンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉからのアクセス抑止対象コンテンツを含む要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシングモジュール４２に入力される。ここで、Ｗｅｂ通信中継ソフトウェア３１は、例えば、クライアント端末１−１〜１−ｉからアクセス抑止対象コンテンツが要求されている、抑止アナウンスを生成する。この抑止アナウンスは、データｂに含まれ、クライアント端末１−１〜１−ｉに送信される。その際、抑止アナウンスは、Ｗｅｂ通信中継ソフトウェア３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１〜１−ｉに送信される。

図８は、Ｗｅｂ通信中継ソフトウェア３１の内部構成についての説明図である。Ｗｅｂ通信中継ソフトウェア３１は、主記憶装置３０に記憶される。Ｗｅｂ通信中継ソフトウェア３１は、例えば、データ領域５０と、セッション処理プロセス４５とを含む。セッション処理プロセス４５は、例えば、ＨＴＴＰモジュール４１、キャッシングモジュール４２、プロキシエンジン４３を含む。プロキシエンジン４３は、Ｗｅｂ通信中継ソフトウェア３１の基本機能を実現し、通信データ送受信やセッション管理などを行う。ＨＴＴＰモジュール４１は、ＨＴＴＰパケットの処理を行う。キャッシングモジュール４２は、ＨＴＴＰのキャッシングと輻輳制御を行う。また、データ領域は、例えば、プロキシエンジン使用領域、ＨＴＴＰモジュール使用領域、キャッシングモジュール使用領域を含む。さらに、キャッシングモジュール使用領域は、例えば、ＵＲＩハッシュ、ＵＲＩエントリ及びＵＲＩ文字列、アクセス規制／抑止、メッセージ及びフォーマット、キャッシュエントリ領域、キャッシュデータ領域を含む。

図９は、ＵＲＩハッシュとＵＲＩエントリによるＵＲＩ管理についての説明図である。ＵＲＩハッシュ７０は、例えば、Ｋｅｙ０〜ｎのＵＲＩエントリのリスト７０−０〜７０−ｎを含む。Ｋｅｙ０のＵＲＩエントリのリスト７０−０は、例えば、ＵＲＩエントリ７１として、ＵＲＩ１（監視・規制）７１−１と、ＵＲＩ２（抑止）７１−２とを含む。また、Ｋｅｙ２のＵＲＩエントリのリスト７０−２は、例えば、ＵＲＩエントリ７１として、ＵＲＩ３（監視・規制）７１−３と、ＵＲＩ４（通常キャッシュ）７１−４と、ＵＲＩ５（優先キャッシュ）７１−５とを含む。Ｋｅｙ ｎのＵＲＩエントリのリスト７０−ｎは、例えば、ＵＲＩｘ（通常キャッシュ）７１−ｘを含む。

ここで、ＵＲＩ４（通常キャッシュ）７１−４とＵＲＩｘ（通常キャッシュ）７１−ｘは、通常キャッシュエントリに通常キャッシュデータを含む。また、ＵＲＩ５（優先キャッシュ）７１−５は、優先キャッシュエントリに優先キャッシュデータを含む。ここで、ＵＲＩ管理について詳細に説明する。ＵＲＩエントリは、ＵＲＩをハッシュ関数にかけて算出したハッシュキーを元にして、同一ハッシュキーでリスト化して管理している。この例では、Ｋｅｙ０にはＵＲＩ１（監視・規制）７１−１、ＵＲＩ２（抑止）７１−２、Ｋｅｙ２にはＵＲＩ３（監視・規制）７１−３、ＵＲＩ４（通常キャッシュ）７１−４、…のＵＲＩエントリがリストされている。また、リスト中の各々のＵＲＩは、要求集約で監視規制対象になっていたり、オペレータ指示で抑止対象や優先キャッシュ対象になっていたり、通常キャッシュであったり、渾然一体となってリスト化されている。このうち、例えば、通常キャッシュであるＵＲＩ４（通常キャッシュ）７１−４のエントリは、通常キャッシュエントリの特定のアドレスを示し、同様に、優先キャッシュであるＵＲＩ５（優先キャッシュ）７１−５のエントリは、優先キャッシュエントリの特定のアドレスを示している。

また、主記憶装置３０上のＷｅｂ通信中継ソフトウェア内キャッシングモジュール使用領域には、例えば、通常キャッシュエントリ領域、優先キャッシュエントリ領域、キャッシュデータ領域が設けてあり、それぞれ所定の大きさに区切って準備されている。実際のＵＲＩ４（通常キャッシュ）７１−４のコンテンツデータは、ＵＲＩ４（通常キャッシュ）７１−４のキャッシュエントリで示されたアドレスの通常キャッシュエントリ領域に格納され、コンテンツの大きさによって必要な量だけ通常キャッシュデータ領域が追加される。同様に、実際のＵＲＩ５（優先キャッシュ）７１−５のコンテンツデータは、ＵＲＩ５（優先キャッシュ）７１−５のキャッシュエントリで示されたアドレスの優先キャッシュエントリ領域に格納され、コンテンツの大きさによって必要な量だけ優先キャッシュデータ領域が追加される。

つぎに、主記憶装置３０に記憶されるキャッシングモジュール使用領域について説明する。なお、キャッシングモジュール使用領域は、主記憶装置３０以外の適宜の記憶装置内に設けることができる。図１０は、キャッシングモジュール使用領域内のデータ構造についての説明図（１）である。キャッシングモジュール使用領域は、例えば、ＵＲＩエントリ７１、キャッシュエントリ７２とを含む。ここで、ＵＲＩエントリ７１としては、例えば、ＵＲＩ（例：http://www.abcde.co.jp/index.html）、制御タイプ（例：通常キャッシュ）、アクセスカウンタ（例：３）、キャッシュエントリ情報を含む。

キャッシュエントリ７２は、例えば、ＵＲＩエントリ情報（例：http://www.abcde.co.jp/index.htmlに関するＵＲＩエントリ）、キャッシュエントリタイプ（例：通常キャッシュ）、キャッシュの状態（例：キャッシング中）、オーナーセッション（例：セッションＮｏ．ｎ）、応答待ちセッションリスト（例：セッションＮｏ．ｘ，Ｎｏ．ｙ）、キャッシュデータ情報を含む。なお、優先キャッシュエントリと通常キャッシュエントリは、キャッシュエントリタイプの値が異なるが、内容は同様である。また、キャッシングモジュール４２内では、優先キャッシュエントリは、運用者の要求がない限り削除されない。但し、通常キャッシュエントリは、資源が不足すると削除される。

図１１は、キャッシングモジュール使用領域内のデータ構造についての説明図（２）である。キャッシングモジュール使用領域は、また、例えば、キャッシュデータ７３を含む。キャッシュデータ７３は、例えば、キャッシュエントリ情報（例：http://www.abcde.co.jp/index.htmlに関するキャッシュエントリ）、キャッシュデータタイプ（例：通常キャッシュ）、キャッシュデータを参照しているセッション数（例：３）、次のキャッシュデータ情報、キャッシュデータを含む。なお、優先キャッシュデータと通常キャッシュデータは、キャッシュデータタイプの値が異なるが、内容は同様である。また、キャッシングモジュール４２内では、優先キャッシュデータは、運用者の要求がない限り削除されない。但し、通常キャッシュデータは、資源が不足すると削除される。

Ｂ．詳細動作
つぎに、キャッシング及び輻輳制御処理を説明する。図１２は、キャッシング及び輻輳制御処理について基本的な処理を示すフローチャートである。まず、Ｗｅｂ通信中継ソフトウェア３１は、キャッシュチェックおよび制御種別判定を行う（Ｓ２０１）。Ｗｅｂ通信中継ソフトウェア３１は、この判定結果に応じて、例えば、通常キャッシュの制御（Ｓ２０３）、優先キャッシュの制御（Ｓ２０５）、アクセス抑止の制御（Ｓ２０７）、アクセス監視・規制の制御（Ｓ２０９）、制御なし（Ｓ２１１）のいずれか又は複数の制御を行い、処理を終了する。

以下に、キャッシュチェックおよび輻輳制御処理判定について詳細に説明する。図１３は、キャッシュチェックおよび輻輳制御処理判定についてのフローチャートである。まず、Ｗｅｂ通信中継ソフトウェア３１に含まれるキャッシングモジュール４２は、キャッシュ可又は不可か制御不可能かに関してメソッドチェックを行い（Ｓ１０１）、キャッシュ可であれば、ＵＲＩのチェック（１）を行う（Ｓ１０３）。キャッシングモジュール４２は、ステップＳ１０３でキャッシュ可であれば、ＵＲＩハッシュ検索（１）（Ｓ１０７）を行い、通常キャッシュ（Ｓ１１１）、優先キャッシュ（Ｓ１１３）、アクセス抑止（Ｓ１１５）のいずれかの処理の決定を行う。

また、キャッシングモジュール４２は、ステップＳ１０１のメソッドチェックにおいてキャッシュ不可であれば、ＵＲＩのチェック（２）（Ｓ１０５）を行い、さらに、ＵＲＩハッシュ検索（２）（Ｓ１０９）を行い、アクセス抑止（Ｓ１１５）、アクセス監視・規制（Ｓ１１７）のいずれかの処理の決定を行う。なお、このＵＲＩハッシュ検索（２）は、ステップＳ１０３でキャッシュ不可である場合でも行われる。また、ＨＴＴＰモジュール４１又はキャッシングモジュール４２は、ステップＳ１０１のメソッドチェックで制御不可能である場合は、制御なし（Ｓ１１９）に決定する。ここで、上述の各処理について詳細に説明する。

（Ｓ１０１のメソッドチェック）
メソッドチェックでは、次のような処理が実行される。
（ａ）まず、クライアントのＨＴＴＰ要求のリクエストメソッドを取得する。
（ｂ）ここで、リクエストメソッドがＧＥＴ、ＨＥＡＤなら「キャッシュ可」の場合の処理を行う。
（ｃ）一方、リクエストメソッドがＯＰＴＩＯＮＳ、ＰＯＳＴ、ＤＥＬＥＴＥ、ＴＲＡＣＥ、ＣＯＮＮＥＣＴなら「キャッシュ不可」の場合の処理を行う。
（ｄ）さらに、リクエストメソッドがＲＦＣ２６１６で定義されていない拡張メソッドである場合は、「制御不可能」の場合の処理を行う。

図１４は、クライアントのＨＴＴＰ要求についての説明図である。クライアントのＨＴＴＰ要求８０は、例えば、図示のように、リクエストメソッド（ここでは、ＧＥＴ）と、ＵＲＩ（ここでは、http://www.abcde.co.jp/）とを含む。この例では、上述の処理（ａ）でリクエストメソッドとしてＧＥＴ'が取得され、「キャッシュ可」の処理に移行する。

（ステップＳ１０３、１０５のＵＲＩチェック（１）（２））
（ａ） ここでは、まず、スキームがＨＴＴＰであることを確認する。
（ｂ） つぎに、パスをチェックし、文字「？」を含んでいるかどうか検査する。
（ｃ） また、パスをチェックし、.cgi,.asp を含んでいるかどうか検査する。
（ｄ） さらに、クエリ有無を判断して、クエリを外す加工処理を行う。なお、「クエリが有る」とは、”？”がついていることを指す。
（ｅ） （ｂ），（ｃ）で該当するものがあった場合は「ＵＲＩの加工」をおこなった文字列を共用メモリに確保する。
（ｆ） （ｂ），（ｃ）で該当した場合は、「キャッシュ不可」の場合の処理を行い、一方、（ｂ）、（ｃ）で該当しなかった場合は、「キャッシュ可」の場合で処理を進める。

図１５は、ＵＲＩの加工についての説明図である。ＵＲＩは、例えば、図示のように、ＵＲＩ（例えば、http: //www.abcde.co.jp/index.html）のうち、「http:」をスキーム、「//www.abcde.co.jp/index.html」をパスとする。また、ＵＲＩの加工とは、例えば、図示のように、ＵＲＩ（例えば、http://www.abcde.co.jp/a.cgi?a1=arg1&a2=arg2）に付加されているクエリを外すことである。この例では、クエリは、?a1=arg1&a2=arg2'であり、これを除いて、http://www.abcde.co.jp/a.cgi とする。

このように、ＵＲＩチェックでは、ＵＲＩハッシュ検索の前に、ＣＧＩなど動的に生成されるページのチェックを行う。具体的には、ＵＲＩで示されたファイルの識別子と、ＣＧＩ特有のパラメータ（引数）の有無によって判定を行い、ＣＧＩなど動的に生成されるページであると判定した場合には、引数の省略処理を行って、簡略化した短いＵＲＩを生成する。これにより、さまざまなクエリを持つＣＧＩを、クエリを含めた別々のＵＲＩとして処理するのではなく、１つのＵＲＩとして処理し、アクセスの監視・規制を実現する。また、ＵＲＩのチェック（１）では、上記判定と共に、キャッシュ可否の判定を行う。一方、ＵＲＩのチェック（２）では、予めキャッシュ不可のＵＲＩであることが分かっているため、キャッシュ可否判定処理を行わない。

（ステップＳ１０７、１０９のＵＲＩハッシュ検索（１）（２））
ステップＳ１０７のＵＲＩハッシュ検索（１）では、次のような処理を実行する。例えば、メモリ上にキャッシュの領域があり、クライアント端末と通信しているＵＲＩはメモリ上に記憶されており、そのメモリテーブルをＵＲＩハッシュとすることができる。
（ａ）ＵＲＩハッシュを検索する。
（ｂ）ＵＲＩエントリにヒットした場合は、ＵＲＩエントリの制御タイプを参照し、そこに記述されている制御に決定する。
（ｃ）ＵＲＩエントリにヒットしなかった場合は、「通常キャッシュ」処理に決定する。

ステップＳ１０９のＵＲＩハッシュ検索（２）では、
（ａ）「ＵＲＩの加工」が行われなかった場合は、ＨＴＴＰ要求にあるＵＲＩを使ってＵＲＩハッシュを検索する。
（ｂ）ＵＲＩエントリにヒットした場合は、ＵＲＩエントリの制御フラグを参照し、そこに記述されている制御に決定する。
（ｃ）ＵＲＩエントリにヒットしなかった場合は、「アクセス監視・規制」処理に決定する。

（ステップＳ１１１の通常キャッシュに決定）
図１６は、通常キャッシュ処理についてのフローチャートである。
（１）まず、キャッシュヒットを判定する（Ｓ１１１−１）。
（１−１）ヒットしなかった場合は、最初のアクセス要求としてＷｅｂサーバへ要求を中継する処理に移り、キャッシングモジュール４２は、例えば、（ａ）通常ＵＲＩエントリの作成、（ｂ）通常キャッシュエントリの作成、（ｃ）ＵＲＩハッシュへ登録、（ｄ）キャッシュエントリにオーナの設定、等を行う通常キャッシング前処理を行う（Ｓ１１１−１１）。つぎに、Ｗｅｂサーバへ要求を転送し（Ｓ１１１−１２）、Ｗｅｂサーバから応答を受信し（Ｓ１１１−１３）、さらに、クライアントへ応答を転送する（Ｓ１１１−１４）。つぎに、キャッシングモジュール４２は、通常キャッシングを行う（ステップＳ１１１−１５）。ここで、ステップＳ１１１−１５の通常キャッシングでは、例えば、次の処理が行われる。
（ａ）通常キャッシュデータの確保。
（ｂ）Ｗｅｂ通信装置の応答をコピー。
（ｃ） （ａ）、（ｂ）をデータがあるまで続ける。
（ｄ）応答待ちセッションリストに登録があるか検査する。
（ｅ） （ｄ）で応答待ちセッションがある場合は、処理開始指示を送る。
（ｆ）オーナの設定を解除する。

（１−２）ヒットした場合、要求集約判定に移る（Ｓ１１１−２）。ここでは、キャッシングモジュール４２は、例えば、Ｗｅｂサーバへのアクセス負荷を軽減するため、キャッシュできるコンテンツに対して、アクセス要求を一つに集約する機能を備える。この機能は、Ｗｅｂサーバから応答が戻る前に、同一コンテンツに対して複数の要求が重複した場合、最初の要求だけＷｅｂサーバへ中継し、残りの要求は一旦処理待ち状態とし、最初の要求に対する応答が戻ってから処理を再開するものである。具体的には、集約処理を以下のように行う。ここで、ステップＳ１１１−２の集約判定処理では、（ａ）キャッシュの状態は、準備完了となっているかを判定し、準備完了となっているのであれば、Ｎｏとする。また、（ｂ）キャッシュエントリのオーナは、現在判定処理を行っているセッションかを判定し、他のセッションがオーナである場合は、Ｙｅｓとし、そうでなければ、Ｎｏとする。

（２）要求集約判定でＹｅｓの場合、Ｗｅｂサーバへ中継した要求の処理が終わるまで、処理を中止する（Ｓ１１１−３）。ここで、ステップＳ１１１−３の処理可能となるまで待機する処理では、（ａ）キャッシュエントリの応答待ちセッションリストにセッションを登録し、（ｂ）呼び出されるまで待機する。

（３）つぎに、ステップＳ１１１−３の後、処理が可能になると、又は、ステップＳ１１１−２で集約を行わない場合、キャッシュ有効期限判定に移る（Ｓ１１１−４）。ここで、ステップＳ１１１−４のキャッシュ有効期限の判定では、キャッシュ中のＲＦＣ２６１６に記述されている通りに有効期限を計算し、期限内であれば、Ｙｅｓとし、期限切れであれば、Ｎｏとする。

キャッシュ有効期限判定でＹｅｓの場合、キャッシュからデータを取り出す（Ｓ１１１−５）。ここで、ステップＳ１１１−５のキャッシュ取出しでは、（ａ）必要な分だけキャッシュデータをアクセスする。つぎに、ステップＳ１１１−５で取り出したデータを、クライアントへデータを転送する（Ｓ１１１−６）。なお、通常、このケースでは、直前に新鮮なデータがキャッシュされている確率が高い（何故なら、最初の要求がＷｅｂサーバからデータを取ってくるのを待っていた）ので、キャッシュが有効期限内にある確率も高い。結果として、Ｗｅｂサーバへのアクセス要求数が減り、アクセス負荷を軽減できる。

（４）一方、キャッシュ有効期限判定でＮｏの場合、Ｗｅｂサーバへ要求を転送し（Ｓ１１１−７）、Ｗｅｂサーバから応答を受信し（Ｓ１１１−８）、さらに、クライアントへ応答を転送する（Ｓ１１１−９）。つぎに、キャッシングモジュール４２は、通常キャッシングを行う（Ｓ１１１−１０）。なお、（１−１）で、最初のアクセスとして処理した要求は、通常キャッシング処理（Ｓ１１１−１０）で、処理が中止になっている要求が存在するか検査する。存在した場合は、処理の再開指示を出す。

なお、ステップＳ１１１−１の前に、後述のような監視・規制の処理を追加することもできる。その際、後述のように、まず、監視・規制前処理（Ｓ１１７−１）を追加して、その後に、規制を行うか否か判定する（Ｓ１１７−２）。ここで、規制を行わない場合、ステップＳ１１１−１に移行する。一方、規制を行う場合、規制メッセージを取得する処理（Ｓ１１７−３）、規制メッセージよりコンテンツを作成する処理（Ｓ１１７−４）、及び、クライアントへコンテンツを転送する処理（Ｓ１１７−５）を実行する。さらに、ステップＳ１１１−６、Ｓ１１１−１０、Ｓ１１１−１５の後に、監視・規制後処理（１１７−９）が追加され、その実行後、処理終了となる。

図１７は、Ｗｅｂ通信装置のＨＴＴＰ応答の説明図である。このＷｅｂ通信装置のＨＴＴＰ応答８５は、例えば、ステップＳ１１１−８、１３に含まれるものである。

図１８は、Ｗｅｂコンテンツデータの管理についての説明図である。まず、Ｗｅｂ通信中継ソフトウェア３１内のキャッシングモジュール４２は、Ｗｅｂ通信装置ＨＴＴＰ応答８５を受信する。キャッシングモジュール４２は、Ｗｅｂ通信装置ＨＴＴＰ応答８５を、例えば、Ｗｅｂ通信装置ＨＴＴＰ応答Ｐａｒｔ １を含むキャッシュエントリ５５−１と、Ｗｅｂ通信装置応答データＰａｒｔ ２を含むキャッシュデータ５５−２と、Ｗｅｂ通信装置応答データＰａｒｔ ｎを含むキャッシュデータ５５−ｎとに区分し、キャッシングモジュール使用領域に格納する。

（ステップＳ１１３の優先キャッシュに決定）図１９は、優先キャッシュ処理についてのフローチャートである。なお、ここでのフローチャートは、上述したステップＳ１１１の通常キャッシュ処理と比較して、通常キャッシュが優先キャッシュとなったことで変更された処理以外は、同様である。まず、キャッシングモジュール４２は、キャッシュはヒットしたか否かを判定し（Ｓ１１３−１）、キャッシュヒットがあれば、集約を行うか否かを判定する（Ｓ１１３−２）。ここで、ステップＳ１１３−２の集約判定処理では、（ａ）キャッシュの状態は、準備完了となっているかを判定し、準備完了となっているのであれば、Ｎｏする。また、（ｂ）優先キャッシュエントリのオーナは、現在判定処理を行っているセッションかを判定し、他のセッションが持ち主である場合は、Ｙｅｓとし、そうでなければ、Ｎｏとする。

つぎに、キャッシングモジュール４２は、ステップＳ１１３−２で集約を行う場合、処理可能になるまで待つ（Ｓ１１３−３）。ここで、ステップＳ１１３−３の処理可能になるまで待つ処理では、（ａ）キャッシュエントリの応答待ちセッションリストにセッションを登録し、（ｂ）呼び出されるまで待機する。つぎに、キャッシングモジュール４２は、キャッシュは有効期限内か否かを判定する（Ｓ１１３−４）。ここで、ステップＳ１１３−４のキャッシュ有効期限の判定では、ＲＦＣ２６１６に記述されている通りに有効期限を計算し、期限内であれば、Ｙｅｓとし、期限切れであれば、Ｎｏとする。ここで、キャッシュが有効期限内であれば、キャッシュを取出す（Ｓ１１３−５）。ここで、ステップＳ１１３−５のキャッシュ取出しでは、（ａ）必要な分だけキャッシュデータをアクセスする。つぎに、キャッシングモジュール４２は、クライアントへキャッシュを転送する（Ｓ１１３−６）。

また、キャッシングモジュール４２は、ステップＳ１１３−４でキャッシュが有効期限内でない場合、Ｗｅｂサーバへ要求を転送し（Ｓ１１３−７）、Ｗｅｂサーバから応答を受信し（Ｓ１１３−８）、さらに、クライアントへ応答を転送する（Ｓ１１３−９）。つぎに、キャッシングモジュール４２は、優先キャッシングを行う（Ｓ１１３−１０）。ここで、ステップＳ１１３−１０の優先キャッシングでは、（ａ）優先キャッシュデータの確保、（ｂ）Ｗｅｂ通信装置の応答をコピー、（ｃ） （ａ）、（ｂ）をデータがあるまで続ける、（ｄ）応答待ちセッションリストに登録があるか検査する、（ｅ） （ｄ）で応答待ちセッションがある場合は、処理開始指示を送る、（ｆ）オーナの設定を解除する、等を行う。

また、キャッシングモジュール４２は、ステップＳ１１３−１でキャッシュがヒットしなかった場合、通常キャッシング前処理を行う（Ｓ１１３−１１）。ここで、ステップＳ１１３−１１の優先キャッシング前処理としては、例えば、（ａ）優先ＵＲＩエントリの作成、（ｂ）優先キャッシュエントリの作成、（ｃ）ＵＲＩハッシュへ登録、（ｄ）優先キャッシュエントリにオーナを設定することが挙げられる。

また、キャッシングモジュール４２は、ステップＳ１１３−１１の後、Ｗｅｂサーバへ要求を転送し（Ｓ１１３−１２）、Ｗｅｂサーバから応答を受信し（Ｓ１１３−１３）、さらに、クライアントへ応答を転送する（Ｓ１１３−１４）。つぎに、キャッシングモジュール４２は、優先キャッシングを行う（Ｓ１１３−１５）。なお、ステップＳ１１３−１５での優先キャッシングは、ステップＳ１１３−１０での処理と同様である。

なお、ステップＳ１１３−１の前に、後述のような監視・規制の処理を追加することもできる。その際、後述のように、まず、監視・規制前処理（Ｓ１１７−１）を実行し、その後に、規制を行うか否か判定する（Ｓ１１７−２）。ここで、規制を行わない場合、ステップＳ１１１−１に移行する。一方、規制を行う場合、規制メッセージを取得する処理（Ｓ１１７−３）、規制メッセージよりコンテンツを作成する処理（Ｓ１１７−４）、及び、クライアントへコンテンツを転送する処理（Ｓ１１７−５）を実行する。さらに、ステップＳ１１３−６、Ｓ１１３−１０、Ｓ１１３−１５の後に、監視・規制後処理（１１７−９）が追加され、その実行後、処理終了となる。

（ステップＳ１１５のアクセス抑止に決定）
アクセス抑止コンテンツの作成方法としては、例えば、アクセス抑止メッセージとアクセス抑止コンテンツのフォーマットを用意して動的に生成する。例えば、上に、アクセス抑止メッセージ群とアクセス抑止コンテンツのフォーマットを格納しておく。キャッシングモジュール４２は、状態に応じてふさわしいメッセージを取り出し、アクセス抑止コンテンツフォーマットに挿入することでアクセス抑止コンテンツを生成する。例えば、以下の図に示すように、抑止時の一般的なメッセージ９３「要求されたコンテンツは利用できません」を使って、アクセス抑止メッセージフォーマットに挿入し、アクセス抑止コンテンツを生成している。

図２０は、アクセス抑止処理についてのフローチャートである。まず、キャッシングモジュール４２は、抑止メッセージを取得し（Ｓ１１５−１）、抑止メッセージよりコンテンツを作成して（Ｓ１１５−２）、クライアントへコンテンツを転送する（Ｓ１１５−３）。

図２１は、抑止メッセージ、抑止コンテンツの説明図である。抑止メッセージ９１は、例えば、「要求されたコンテンツはご利用できません」と対応させて表示されるものである。また、抑止コンテンツ９３は、例えば、図示のように、表示される。

（ステップＳ１１７のアクセス監視・規制の決定）
図２２は、アクセス監視・規制処理についてのフローチャートである。まず、キャッシングモジュール４２は、監視・規制前処理を行う（Ｓ１１７−１）。ここで、ステップＳ１１７−１の監視・規制前処理では、次の処理を行う。
（ａ）ＵＲＩエントリを作成していなければ作成する。
（ｂ）（ａ）を実行した場合は、ＵＲＩハッシュに登録する。
（ｃ）ＵＲＩエントリ中のアクセスカウントを１増やす。

つぎに、キャッシングモジュール４２は、規制を行うか否かを判定する（Ｓ１１７−２）。ここで、ステップＳ１１７−２の規制判定処理では、（ａ）ＵＲＩエントリのアクセスカウンタ、（ｂ）ＵＲＩエントリの規制実行フラグ、（ｃ）装置に設定された規制開始接続数、（ｄ）装置に設定された規制終了接続数を参照して、（ｂ）の規制実行フラグが設定されていない場合、（ａ）＞（ｃ）ならばＹｅｓとし、そうでなければＮｏとする。一方、（ｂ）の規制実行フラグが設定されている場合、（ａ）＞（ｄ）ならばＹｅｓとし、そうでなければＮｏとする。

キャッシングモジュール４２は、ステップＳ１１７−２で規制を行う場合、規制メッセージを取得し（Ｓ１１７−３）、規制メッセージよりコンテンツを作成して（Ｓ１１７−４）、クライアントへコンテンツを転送する（Ｓ１１７−５）。一方、ステップＳ１１７−２で規制を行わない場合、キャッシングモジュール４２は、Ｗｅｂサーバへ要求を転送し（Ｓ１１７−６）、Ｗｅｂサーバから応答を受信して（Ｓ１１７−７）、クライアントへ応答を転送する（Ｓ１１７−８）。

また、キャッシングモジュール４２は、ステップＳ１１７−５、８の後、監視・規制後処理を行う（Ｓ１１７−９）。ここで、ステップＳ１１７−９の監視・規制後処理では、次の処理が行われる。
（ａ）ＵＲＩエントリ中のアクセスカウントを１減らす。
（ｂ）アクセスカウンタが０ならば、ＵＲＩハッシュから削除する。
（ｃ）（ｂ）で削除を実行した場合は、ＵＲＩエントリを削除する。

図２３は、規制メッセージ、規制コンテンツの説明図である。アクセス規制メッセージの作成方法についても、上述したアクセス抑止コンテンツの作成方法と同様である。規制メッセージ９５は、例えば、「現在、混み合っているため後でご利用ください」と対応させて表示されるものである。また、規制コンテンツ９７は、例えば、図示のように表示される。

なお、キャッシングモジュール４２では、例えば、ステップＳ１１７−２において、以下のような処理を行い、規制を行うか否かの判断基準としてもよい。
Ａ．ＵＲＩエントリ新たなパラメータを追加する。
Ｂ．パラメータには、過去にＷｅｂ通信中継装置がサーバに当該ＵＲＩの要求を送信したときの応答時間の平均を入れる。
Ｃ．アクセス数が１以上のときは、Ａ．で追加したパラメータも考慮し、例えば、アクセス数がある程度存在し、通信に設定時間以上かかりそうな場合は、上述の規制開始接続数に満たなくても規制する。

（ステップＳ１１９の制御なしに決定）図２４は、制御なし処理についてのフローチャートである。まず、キャッシングモジュール４２は、Ｗｅｂサーバへ要求を転送し（Ｓ１１９−１）、Ｗｅｂサーバから応答を受信して（Ｓ１１９−２）、クライアントへ応答を転送する（Ｓ１１９−３）。ここで、ガベージコレクション（装置内資源の再利用）について説明すると、キャッシュ領域に空きが無くなると、データ格納が古かったり、アクセス回数が低い領域を消去して再利用するために、ガベージコレクション処理を行う。ガベージコレクション処理の際には、優先キャッシュエントリは対象外とし、さらに優先キャッシュフラグを参照して、優先キャッシュとして使用されているデータ領域も処理の対象外とする追加判定を行っている。

なお、通信システムがＲＦＣ２６１６に未定義のリクエストメソッドに対応しないときは、制御なし（Ｓ１１９、Ｓ２１１）を設置することなく発明の効果が得られる。また、通信システムがＨＥＡＤメソッドをキャッシュとして処理しない場合は、ステップＳ１０１におけるＨＥＡＤメソッドの処理を（ｂ）ではなく（ｃ）で処理することで対応できる。以下に、アクセス監視・規制に用いる規制開始接続数と規制終了接続数を動的に変更する場合について説明する。

図２５は、拡張したＵＲＩエントリを示す図である。ＵＲＩエントリを図２５に示すように拡張することで、アクセス監視・規制に用いる規制開始接続数と規制終了接続数は、あらかじめ装置に設定した値だけでなく、動的に変更した値を利用できる。例えば、規制開始時刻と規制終了時刻により、次回の規制開始接続数と規制終了接続数を定める。

図２６は、規制開始接続数と規制終了接続数の動的な変更を示す説明図である。ここでは、規制開始接続数と規制終了接続数を動的に決定する場合の一例で、ＵＲＩ１とＵＲＩ２に対する接続数の変化を示している。ここでは、ＵＲＩ１およびＵＲＩ２とも、図２５に示したＵＲＩエントリを利用しており、規制開始接続数と規制終了接続数にそれぞれ初期の接続数が設定されている。図２６では、ＵＲＩ１とＵＲＩ２が時刻ｔ１にアクセス規制の制御が開始されている。この例では、規制開始を行うときにそれぞれのＵＲＩエントリに規制開始時刻ｔ１を記憶する。規制が終了すると、ｔ１と規制終了時刻ｔ２およびｔ３を利用して、規制実施時間を求める。ＵＲＩ１の規制実施時間Ｔ１はｔ２−ｔ１、ＵＲＩ２の規制実施時間Ｔ２はｔ３−ｔ１となる。これを、通信システムが想定している標準規制実施時間Ｔと比較し、次の規制開始接続数と規制終了接続数を定める。この例では、Ｔ１の値がＴより非常に小さいので、ＵＲＩ１の規制開始接続数と規制終了接続数を一定数増加している。また、Ｔ２は、Ｔとそれほど変わらないため、値を変更していない。

また、図２５のように拡張したＵＲＩエントリでは、アクセス監視・規制を異なる方法で実施できる。Ｗｅｂ通信ソフトウェア３１内部のプロキシエンジン利用領域には、Ｗｅｂ通信ソフトウェア３１がＷｅｂ通信装置３−１〜３−ｎに対して要求した際の平均応答時間が保存されている。さらにＵＲＩエントリには、ＵＲＩごとの平均応答時間が記憶されている。ＵＲＩに対して一定数の要求がある場合、Ｗｅｂ通信ソフトウェア３１全体の平均応答時間とＵＲＩごとの平均応答時間を比較し、ＵＲＩごとの平均応答時間の応答時間が著しく大きい場合は、アクセス規制処理を行うことで輻輳を回避できる。

通信システムの構成図。 Ｗｅｂ通信中継装置の構成図。 大規模Ｗｅｂ通信中継装置におけるデータの送受信についての説明図。 キャッシュヒット時の説明図及びシーケンス図。 キャッシュミスヒット時の説明図及びシーケンス図。 輻輳時の説明図及びシーケンス図。 アクセス抑止対象コンテンツが要求された場合の説明図及びシーケンス図。 Ｗｅｂ通信中継ソフトウェア３１の内部構成についての説明図。 ＵＲＩハッシュとＵＲＩエントリによるＵＲＩ管理についての説明図。 共用メモリ５５内のデータ構造についての説明図（１）。 共用メモリ５５内のデータ構造についての説明図（２）。 キャッシング及び輻輳制御処理について基本的な処理を示すフローチャート。 キャッシュチェックおよび輻輳制御処理判定についてのフローチャート。 クライアントのＨＴＴＰ要求についての説明図。 ＵＲＩの加工についての説明図。 通常キャッシュ処理についてのフローチャート。 Ｗｅｂ通信装置のＨＴＴＰ応答の説明図。 Ｗｅｂコンテンツデータの管理についての説明図。 優先キャッシュ処理についてのフローチャート。 アクセス抑止処理についてのフローチャート。 抑止メッセージ、抑止コンテンツの説明図。 アクセス監視・規制処理についてのフローチャート。 規制メッセージ、規制コンテンツの説明図。 制御なし処理についてのフローチャート。 拡張したＵＲＩエントリを示す図。 規制開始接続数と規制終了接続数の動的な変更を示す説明図。

符号の説明

１−１〜１−ｉ クライアント端末
２ 大規模Ｗｅｂ通信中継装置
３−１〜３−ｊ Ｗｅｂ通信装置
２１ データ中継装置
２２ 認証装置
２３ システム管理装置
２４ レイヤ７負荷分散装置
２５−１〜２５−ｎ Ｗｅｂ通信中継装置
２６ アクセス規制装置
３１ Ｗｅｂ通信中継ソフトウェア
４１ ＨＴＴＰモジュール
４２ キャッシングモジュール
４３ プロキシエンジン
１００ 通信システム

Claims (7)

1. 一つ以上のサーバ装置と接続され，要求元装置から受信した前記一つ以上のサーバ装置のいずれかを宛先に含む要求を，前記要求の宛先となるサーバ装置へ送信し，
   前記要求に対する前記サーバ装置からの応答を，前記要求元装置へ送信する中継装置であって，
   受信した前記要求を対象として，前記要求の宛先別に，応答の送信前である前記要求数を監視し，
   前記監視の対象であり，前記応答の送信前である要求数が予め定めた規制開始値を超えた宛先について，予め定めた規制終了値を下回るまでに受信した当該宛先への前記要求は，規制対象として当該宛先へ送信せず，
   前記宛先へ送信しなかった前記要求に対する応答として，当該要求が規制対象となったことを示す情報を，前記要求元装置へ送信する
   ことを特徴とする中継装置。
2. 請求項１に記載の中継装置であって，
   受信した前記要求に含まれる，当該要求の内容を示すメソッドをチェックし，
   当該メソッドが予め定めた種類であれば，当該要求を，前記応答の送信前である要求数の監視の対象とする
   ことを特徴とする中継装置。
3. 請求項１または２に記載の中継装置であって，
   前記監視の対象であり前記応答の送信前である要求数が，予め定めた規制開始値を超えた後，予め定めた規制終了値より小さくなった宛先について，
   前記監視の対象であり前記応答の送信前である前記要求数が，前記規制終了値より小さくなってから前記規制開始値を超えるまでに受信した，前記宛先への前記監視の対象である前記要求を，規制対象とせずに，前記宛先が示す前記提供装置へ送信し，
   前記宛先が示すサーバ装置から応答を受信し，
   前記要求に対する前記応答として，前記要求元装置へ送信する
   ことを特徴とする中継装置。
4. 請求項１ないし３いずれか一に記載の中継装置であって，
   前記監視の対象であり前記要求に対する前記応答の送信前である要求数の前記監視処理に於いて，
   前記要求を受信したら，前記監視の対象であり前記応答の送信前である要求数のカウントを増やし，
   前記応答を送信したら，前記監視の対象であり前記応答の送信前である前記要求数のカウントを減らす
   ことを特徴とする中継装置。
5. 請求項１ないし４いずれか一に記載の中継装置であって，
   予め定めた規制開始値を超えた前記宛先について，
   前記規制開始値を超えてから，前記規制終了値を下回るまでの規制実施時間に基づき，
   前記規制開始値と前記規制終了値の変更要否を決定する
   ことを特徴とする中継装置。
6. 請求項１ないし５いずれか一に記載の中継装置であって，
   前記監視の対象となる要求に宛先として含まれるＵＲＩについて，異なる複数のＵＲＩを一つのＵＲＩとして処理するための簡略化処理を行い，
   前記簡略化したＵＲＩを対象として，応答の送信前である要求数の前記監視を行う
   ことを特徴とする中継装置。
7. 請求項６に記載の中継装置であって，
   前記ＵＲＩは，パスとクエリとを含み，
   前記簡略化処理において，複数の前記ＵＲＩのパスが同じであれば，前記クエリを取り除くことにより，複数の前記ＵＲＩを一つのＵＲＩと見なす
   ことを特徴とする中継装置。

Images