(57)【特許請求の範囲】
【請求項１】
クライアント端末とサーバ装置の間に設けられた通信中継装置における輻輳制御方法で
あって、クライアント端末からの要求に従い、キャッシュヒットした際は記憶されている
要求内容をクライアント端末に送信し、キャッシュヒットしなかった場合又はキャッシュ
を利用しない要求の場合、要求内容をサーバ装置から受信してクライアント端末に送信す
るための前記輻輳制御方法において、
入力されたクライアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可か
を判断するメソッドチェックステップと、
前記メソッドチェックステップによりキャッシュ可であると判断された場合、クライア
ント端末からの要求に含まれるＵＲＩのチェックを行いキャッシュ可又は不可かを判断す
る第１ＵＲＩチェックステップと、
前記第１ＵＲＩチェックステップによる判断に従い、キャッシュ可であれば、ＵＲＩハ
ッシュの検索を行い、通常キャッシュ、優先キャッシュ又はアクセス抑止のいずれかの処
理が行われるか決定する第１ＵＲＩハッシュ検索ステップと、
前記第１ＵＲＩハッシュ検索ステップによる決定に従い、通常キャッシュ処理、優先キ
ャッシュ処理又はアクセス抑止処理のいずれかの処理を行うステップとを含む輻輳制御方
法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、輻輳制御方法に係り、特に、クライアントとサーバ間のデータ通信における
輻輳制御方法に関する。
【背景技術】
【０００２】
インターネットが急速に普及し、チケット予約や銀行・証券取引等、従来営業店窓口で
行われていたサービスもインターネットを介して提供されるようになってきた。また、通
信技術も進歩し、家庭やオフィスからだけでなく携帯電話などからでもサービスを享受で
きる環境が整ってきた。
【０００３】
しかし、各クライアントが直接サーバにサービス要求をする従来の方式では、クライア
ントの要求がサーバに集中する。その結果、数多くの利用者からの要求に通信回線容量や
処理するサーバ装置の能力が対応できず、時間帯やアクセス先によっては、利用者がいく
ら要求をしてもなかなか応答が返ってこないという場合が発生するようになってきた。
【０００４】
この点に関しては、一般に、Ｗｅｂ通信中継装置を設置することで改善できる。クライ
アントからの要求は、Ｗｅｂ通信中継装置と呼ばれる中継処理装置を経由して処理する。
Ｗｅｂ通信中継装置では、過去の通信内容の一部を記憶（キャッシュという）する記憶部
（キャッシングモジュール）を設置することにより、記憶した通信に関しては、サーバへ
接続することなく要求を処理できる。プロキシ装置は、その有効性から多数の通信システ
ムで導入されている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
現在では、１０００万人規模のユーザを対象とする通信システムに大規模Ｗｅｂ通信中
継装置が設置されるようになってきた。このような通信システムでは、大規模Ｗｅｂ通信
中継装置に対する要求が過剰に集中する。要求の集中が起こると、通信路の混雑や装置の
負荷が上昇するため、ユーザは通信システムが提供するサービスを利用しにくくなる。ま
た、過度な集中が継続すると大規模Ｗｅｂ通信中継装置に障害（輻輳）が発生し動作を停
止する可能性がある。大規模Ｗｅｂ通信中継装置の動作が停止すると通信システムとして
機能しなくなり、通信システムを利用する全ユーザがサービスを利用できなくなる。
【０００６】
本発明では、以上の点を鑑み、大規模Ｗｅｂ通信中継装置を主としたＷｅｂ通信中継装
置に発生する障害を回避、軽減することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明では、例えば、Ｗｅｂ通信中継装置がユーザの要求
する通信内容ごとに要求処理の制御を変更する機構を設ける。Ｗｅｂ通信中継装置の負荷
が上昇するのを避けるために、実施する制御を判定する機構は、新たな処理部を設けるの
ではなく、Ｗｅｂ通信中継装置に従来から存在する記憶部（キャッシングモジュール）を
利用する。
【０００８】
Ｗｅｂ通信中継装置は、現在装置が行っている通信内容と装置の状態を検証したうえで
、新たに到着した要求に対する処理方針を決定する。これにより、省略できる通信を検出
でき、通信量の削減することで、Ｗｅｂ通信中継装置が輻輳状態に陥ることを回避する。
また、輻輳の原因となる通信処理を通常の処理とは異なる方法で処理する。例えば、輻輳
の原因となる通信を優先的に記憶する。これによりＷｅｂ通信中継装置が輻輳状態に陥る
のを回避する。
【０００９】
Ｗｅｂ通信中継装置は、要求に対する制御を決定する過程で、輻輳状態に近づいている
通信を検出する。輻輳状態に近い通信に関しては、輻輳が改善されるまで処理をせず、ユ
ーザに対して通信を控えるようアナウンスする。これにより、輻輳状態の悪化を防止し、
Ｗｅｂ通信中継装置が障害で利用不能となるのを回避する。
【００１０】
本発明の大規模Ｗｅｂ通信中継装置では、ユーザが送信する要求を負荷分散装置で受信
する。負荷分散装置は、大規模Ｗｅｂ通信中継装置内に設置した複数のＷｅｂ通信中継装
置に負荷を分散して送信する。Ｗｅｂ通信中継装置では、キャッシングモジュールがユー
ザの要求を判断し、Ｗｅｂ通信中継装置が行う制御を決定する。輻輳制御の種類としては
、要求集約、優先キャッシュ、アクセス抑止、アクセス監視および規制の４つがある。
【００１１】
複数のユーザがキャッシュ可能なサービスの要求を行い、かつ、Ｗｅｂ通信中継装置が
サーバに通信する必要がある場合、Ｗｅｂ通信中継装置は、サーバに対しては複数の要求
が１つの要求に集約して通信する。これにより、Ｗｅｂ通信中継装置とサーバ間の通信量
が削減する。また、サーバに対する要求が減少するため、サーバの負荷が上昇するのを防
止する。Ｗｅｂ通信中継装置がサーバに対して行う輻輳を回避し、負荷も軽減するため、
Ｗｅｂ通信中継装置は、ユーザに迅速に応答できる。
【００１２】
本発明のＷｅｂ通信中継装置は、特定のサービスを優先的にキャッシングする方法を提
供する。この方法を利用して、通信システム提供者は輻輳の原因となるサービスを優先的
にキャッシングするよう登録できる。従来の方法では、キャッシングするデータに優先、
非優先の区別がないため、重要なデータをＷｅｂ通信中継装置内で保持しつづけることが
できなかった。しかし、この方法により、Ｗｅｂ通信中継装置は、ユーザが必要とするデ
ータを保持できる。ユーザは、より多くのサービスを高速に受けることできる。
【００１３】
本発明のＷｅｂ通信中継装置は、特定のサービスをユーザが利用するのを抑止する方法
を提供する。この方法を利用して、通信システム提供者は、輻輳の原因となり通信システ
ムが提供すべきではないサービスをユーザに提供しないことができる。提供しないサービ
スに関する要求には、Ｗｅｂ通信中継装置がユーザに対して提供できない旨の返答を行い
要求処理が終了する。
【００１４】
従来では、抑止機構を持たないため、Ｗｅｂ通信中継装置は不要なサーバとの通信に資
源を浪費していた。また、ユーザは、要求したサービスが提供されないまま待ち続けたり
、何度も通信を試みる可能性があった。本発明の方法を利用することで、サービスが提供
されないことが迅速に把握できる。
【００１５】
本発明のＷｅｂ通信中継装置は、サービス接続数が確認できる要求について、その接続
数を計測する。要求集約が不可能な要求にもかかわらず、同一の要求が非常に多い場合は
、一定数以上の要求を接続不可として処理できる。この際、Ｗｅｂ通信中継装置は、ユー
ザに対して要求結果として接続不可の理由を通知する。これにより、サーバの負荷を軽減
するとともにＷｅｂ通信中継装置の輻輳を回避する。また、ユーザは、要求したサービス
が提供されないまま待つことなく、サービスの提供状況を把握できる。
【００１６】
本発明の第１の解決手段によると、クライアント端末とサーバ装置の間に設けられた通
信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッ
シュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒ
ットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から
受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクラ
イアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッ
ドチェックステップと、前記メソッドチェックステップによりキャッシュ可であると判断
された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行いキャッシュ
可又は不可かを判断する第１ＵＲＩチェックステップと、前記第１ＵＲＩチェックステッ
プによる判断に従い、キャッシュ可であれば、ＵＲＩハッシュの検索を行い、通常キャッ
シュ、優先キャッシュ又はアクセス抑止のいずれかの処理が行われるか決定する第１ＵＲ
Ｉハッシュ検索ステップと、前記第１ＵＲＩハッシュ検索ステップによる決定に従い、通
常キャッシュ処理、優先キャッシュ処理又はアクセス抑止処理のいずれかの処理を行うス
テップとを含む輻輳制御方法を提供する。
【００１７】
本発明の第２の解決手段によると、クライアント端末とサーバ装置の間に設けられた通
信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッ
シュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒ
ットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から
受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクラ
イアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッ
ドチェックステップと、前記メソッドチェックステップによりキャッシュ不可であると判
断された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行う第２ＵＲ
Ｉチェックステップと、ＵＲＩハッシュの検索を行い、アクセス抑止又はアクセス監視・
規制のいずれかの処理が行われるか決定する第２ＵＲＩハッシュ検索ステップと、前記第
２ＵＲＩハッシュ検索ステップによる決定に従い、アクセス抑止処理又はアクセス監視・
規制処理のいずれかの処理を行うステップとを含む輻輳制御方法を提供する。
【００１８】
本発明の第３の解決手段によると、クライアント端末とサーバ装置の間に設けられた通
信中継装置における輻輳制御方法であって、クライアント端末からの要求に従い、キャッ
シュヒットした際は記憶されている要求内容をクライアント端末に送信し、キャッシュヒ
ットしなかった場合又はキャッシュを利用しない要求の場合、要求内容をサーバ装置から
受信してクライアント端末に送信するための前記輻輳制御方法において、入力されたクラ
イアント端末からの要求に基づき、キャッシュ可又はキャッシュ不可かを判断するメソッ
ドチェックステップと、前記メソッドチェックステップによりキャッシュ可であると判断
された場合、クライアント端末からの要求に含まれるＵＲＩのチェックを行いキャッシュ
可又は不可かを判断する第１ＵＲＩチェックステップと、前記第１ＵＲＩチェックステッ
プによる判断に従い、キャッシュ可であれば、ＵＲＩハッシュの検索を行い、通常キャッ
シュ又は優先キャッシュのいずれかの処理が行われるか決定する第１ＵＲＩハッシュ検索
ステップと、前記メソッドチェックステップによりキャッシュ不可であると判断された場
合、クライアント端末からの要求に含まれるＵＲＩのチェックを行う第２ＵＲＩチェック
ステップと、前記第１ＵＲＩチェックステップによる判断によりキャッシュ不可である場
合又は前記第２ＵＲＩチェックステップを経て移行され、ＵＲＩハッシュの検索を行い、
アクセス抑止又はアクセス監視・規制のいずれかの処理が行われるか決定する第２ＵＲＩ
ハッシュ検索ステップと、前記第１又は第２ＵＲＩハッシュ検索ステップによる決定に従
い、通常キャッシュ処理、優先キャッシュ処理、アクセス抑止処理、アクセス監視・規制
処理のいずれかの処理を行うステップとを含む輻輳制御方法を提供する。
【発明の効果】
【００１９】
本発明を利用することにより、通信システム提供者は、従来よりも信頼性のある通信シ
ステムをユーザに提供することができる。また、ユーザは、従来よりも少ない待ち時間で
応答の得られる通信システムを利用できる。
【発明を実施するための最良の形態】
【００２０】
Ａ．ハード構成と概略構成
図１に、通信システムの構成図を示す。通信システム１００は、例えば、クライアント端
末１−１〜１−ｉと、大規模Ｗｅｂ通信中継装置２と、Ｗｅｂ通信装置３−１〜３−ｊと
を含む。クライアント端末１−１〜１−ｉは、例えば、Ｗｅｂコンテンツの取得（アクセ
ス）要求、データ送受信、画面表示等を行うユーザ用（端末）装置である。Ｗｅｂ通信装
置３−１〜３−ｊは、例えば、クライアント端末１−１〜１−ｉからの要求に応じてＷｅ
ｂコンテンツを送出する装置であって、ディスク容量を上限としてコンテンツデータを格
納している。なお、本実施の形態では、主に大規模なＷｅｂ通信装置について説明してい
るが、これに限らず、本発明は、適宜の規模の通信装置に適用することができる。
【００２１】
大規模Ｗｅｂ通信中継装置２は、例えば、データ中継装置２１と、認証装置２２と、シ
ステム管理装置２３と、レイヤ７負荷分散装置２４と、Ｗｅｂ通信中継装置２５−１〜２
５−ｎと、アクセス規制装置２６とを備える。
【００２２】
データ中継装置２１は、例えば、大規模Ｗｅｂ通信中継装置２内外の各装置、Ｗｅｂ通
信装置３−１〜３−ｊ及びクライアント端末１−１〜１−ｉとの間でデータ送受信を中継
する装置であって、送受信データパケットのヘッダーに記された宛先装置へパケットを転
送する。認証装置２２は、大規模Ｗｅｂ通信中継装置２が提供する中継サービスが、予め
登録された（正規の）クライアント端末１−１〜１−ｉと正規のＷｅｂ通信装置３−１〜
３−ｊ間のものであることを認証するための装置であって、ユーザ情報やサービス情報を
登録したデータベースを備える。システム管理装置２３は、例えば、大規模Ｗｅｂ通信中
継装置２内の各装置を集中的に管理するための装置である。
【００２３】
レイヤ７負荷分散装置２４は、例えば、複数のクライアント端末１−１〜１−ｉからの
Ｗｅｂコンテンツ取得要求を、複数のＷｅｂ通信中継装置２５−１〜２５−ｎに振分け、
中継処理の負荷を分散する装置であって、送受信パケットヘッダーや、Ｗｅｂコンテンツ
要求・送信ヘッダーに記された宛先等の記述を解釈して振分け経路を定め、受信したデー
タパケットをその経路へ送信する。Ｗｅｂ通信中継装置２５−１〜２５−ｎは、例えば、
クライアント端末１−１〜１−ｉからのＷｅｂコンテンツ取得要求を受け付け、Ｗｅｂ通
信装置３−１〜３−ｊに要求を中継したり、クライアント端末１−１〜１−ｉとＷｅｂ通
信装置３−１〜３−ｊ間のデータ送受信を中継する装置である。アクセス規制装置２６は
、例えば、多量のＷｅｂコンテンツ取得要求が短時間に集中した場合に、大規模Ｗｅｂ通
信中継装置２の処理限界を超えないよう、アクセス量（取得要求量）を規制するための装
置である。
【００２４】
図２に、Ｗｅｂ通信中継装置の構成図を示す。Ｗｅｂ通信中継装置２５−１は、例えば
、主記憶装置３０と、この主記憶装置３０に記憶されたＷｅｂ通信中継ソフトウェア３１
と、入出力装置３２と、プロセッサ３３と、レイヤ７負荷分散装置２４とデータパケット
の送受信を行う通信装置３４と、二次記憶装置３５と、これらの各部材を相互の接続する
バス３６とを備える。
【００２５】
二次記憶装置３５は、例えば、磁気ディスクなどの装置（不揮発性記憶装置）であって
、プログラム及び各種の設定ファイルを記憶する。二次記憶装置３５は、以下のような役
割を担う。
（１）Ｗｅｂ通信中継装置２５−１のＯＳ（オペレーティングシステム）データを格納し
、装置起動時にそのデータが主記憶装置３０にロードされる。
（２）ＯＳ上で動作する様々なアプリケーションプログラム（データ・設定ファイル）を
格納し、アプリケーションの起動時に主記憶装置３０にロードされる。
（３）Ｗｅｂ通信中継装置２５−１が中継するＷｅｂコンテンツデータをキャッシュデー
タとして格納する。
【００２６】
なお、実施例のＷｅｂ通信中継装置では、クライアントからの要求をセッションと呼ば
れる処理単位で処理している（１つの要求が１つのセッションに対応する）。セッション
がキャッシュを用いる際にキャッシュエントリを確保する。セッションがサーバと通信し
てキャッシングをするときは、キャッシュエントリを所有している必要がある。本輻輳制
御方式は、個々のセッション処理の中で行われる。
【００２７】
図３は、大規模Ｗｅｂ通信中継装置におけるデータの送受信についての説明図である。
なお、説明の便宜上、上述した部材と同一部材には同一符号を付し、構成、機能は同様で
ある。また、各Ｗｅｂ通信中継装置２５−１〜２５−ｎは同様の構成であるので、ここで
は、Ｗｅｂ通信中継装置２５−１について説明する。
【００２８】
Ｗｅｂ通信中継ソフトウェア３１は、Ｗｅｂ通信中継装置２５−１に記憶されており、
例えば、ＨＴＴＰモジュール４１と、キャッシングモジュール４２と、プロキシエンジン
４３とを含む。ここで、図中のデータａ〜ｄは、ａ：クライアント端末１−１〜１−ｉの
要求、ｂ：Ｗｅｂ通信中継ソフトウェア３１の応答、ｃ：Ｗｅｂ通信中継ソフトウェア３
１の要求、ｄ：Ｗｅｂ通信装置３−１〜３−ｊの応答をそれぞれ示す。
【００２９】
なお、キャッシュヒットのときは、データａ、ｂのみが通信路を流れる（図４参照）。
また、キャッシュミスヒットのときは、データａ、ｃ、ｄ，ｂの順でデータが通信路を流
れる（図５参照）。以下に各処理について概略説明する。
【００３０】
ａ：クライアントの要求
まず、クライアント端末１−１〜１−ｉからクライアント要求が送信されると、大規模Ｗ
ｅｂ通信中継装置２は、それを受信する。大規模Ｗｅｂ通信中継装置２のデータ中継装置
２１では、要求をレイヤ７負荷分散装置２４に転送し、レイヤ７負荷分散装置２４は、い
ずれかのＷｅｂ通信中継装置（ここでは、Ｗｅｂ中継装置２５−１）に送る。Ｗｅｂ通信
中継装置２５−１内のＷｅｂ通信中継ソフトウェア３１では、プロキシエンジン４３を経
て、ＨＴＴＰモジュール４１とキャッシングモジュール４２が、そのクライアント要求を
受信する。
【００３１】
ｂ：Ｗｅｂ通信中継ソフトウェアの応答
つぎに、クライアント要求を受信したＷｅｂ通信中継装置２５−１は、通信内容を解析す
る。ここで、Ｗｅｂ中継装置２５−１が、クライアント要求に対応しているＷｅｂページ
をキャッシュで記憶している場合、その内容をレイヤ７負荷分散装置２４、データ中継装
置２１を経て、クライアント端末１−１へ送信する。
【００３２】
ｃ：Ｗｅｂ通信中継ソフトウェアの応答
一方、Ｗｅｂ中継装置２５−１が、クライアント要求に対応しているＷｅｂページをキャ
ッシュで記憶していない場合、及び／又はクライアント要求にキャッシュ利用不可の指示
がある場合、Ｗｅｂ中継装置２５−１は、クライアント要求に関する情報を、レイヤ７負
荷分散装置２４、データ中継装置２１を経て、Ｗｅｂ通信装置３−１〜３−ｊの該当する
装置へ送信する。
【００３３】
ｄ：Ｗｅｂ通信装置の応答
Ｗｅｂ通信装置３−１〜３−ｊは、クライアント要求を受信すると、クライアント端末に
、データ中継装置２１を介してクライアント要求に対応するＷｅｂページを応答する。さ
らに、データ中継装置２１は、レイヤ７負荷分散装置２４を経てＷｅｂ中継装置２５−１
に、その通信内容やＷｅｂページを転送する。Ｗｅｂ中継装置２５−１では、そのＷｅｂ
ページをキャッシングモジュール４２にキャッシュする。
【００３４】
図４は、キャッシュヒット時の説明図及びシーケンス図である。なお、ここでのシーケ
ンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉ
からの要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、
レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュ
ール４１を経て、キャッシングモジュール４２に入力され、ここで、キャッシュヒットと
判定される。つぎに、Ｗｅｂページは、Ｗｅｂ通信中継ソフトウェア３１の応答信号（デ
ータｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ
７負荷分散装置２４、データ中継装置２１を経て、クライアント端末１−１〜１−ｉに送
信される。
【００３５】
図５は、キャッシュミスヒット時の説明図及びシーケンス図である。なお、ここでのシ
ーケンスは、構成図中の点線の矢印に対応している。まず、クライアント端末１−１〜１
−ｉからの要求信号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２
１、レイヤ７負荷分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモ
ジュール４１を経て、キャッシングモジュール４２に入力され、ここで、キャッシュミス
ヒットと判定される。つぎに、Ｗｅｂ通信中継ソフトウェア３１の要求信号（データｃ）
が、キャッシングモジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４
、データ中継装置２１を経て、Ｗｅｂ通信装置３−１〜３−ｊに送信される。さらに、こ
れに応答してＷｅｂ通信装置３−１〜３−ｊのＷｅｂページを含む応答信号（データｄ）
は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４を
経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシン
グモジュール４２に入力される。つぎに、Ｗｅｂページは、Ｗｅｂ通信中継ソフトウェア
３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモジ
ュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端末
１−１〜１−ｉに送信される。
【００３６】
図６は、輻輳時の説明図及びシーケンス図である。なお、ここでのシーケンスは、構成
図中の点線の矢印に対応している。まず、クライアント端末１−１〜１−ｉからの要求信
号（データａ）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷
分散装置２４を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経
て、キャッシングモジュール４２に入力される。
【００３７】
ここで、Ｗｅｂ通信中継ソフトウェア３１は、例えば、Ｗｅｂ通信装置３−１〜３−ｊ
が輻輳中の場合、規制コンテンツを生成する。ここで、例えば、ある一定以上の要求がひ
とつのＷｅｂページに集中した場合、輻輳と判断される。この規制コンテンツは、データ
ｂに含まれ、クライアント端末１−１〜１−ｉに送信される。その際、規制コンテンツは
、Ｗｅｂ通信中継ソフトウェア３１の応答信号（データｂ）として、再び、キャッシング
モジュール４２、ＨＴＴＰモジュール４１、レイヤ７負荷分散装置２４、データ中継装置
２１を経て、クライアント端末１−１〜１−ｉに送信される。
【００３８】
図７は、アクセス抑止対象コンテンツが要求された場合の説明図及びシーケンス図であ
る。なお、ここでのシーケンスは、構成図中の点線の矢印に対応している。まず、クライ
アント端末１−１〜１−ｉからのアクセス抑止対象コンテンツを含む要求信号（データａ
）は、大規模Ｗｅｂ通信中継装置２内のデータ中継装置２１、レイヤ７負荷分散装置２４
を経て、Ｗｅｂ通信中継ソフトウェア３１内のＨＴＴＰモジュール４１を経て、キャッシ
ングモジュール４２に入力される。ここで、Ｗｅｂ通信中継ソフトウェア３１は、例えば
、クライアント端末１−１〜１−ｉからアクセス抑止対象コンテンツが要求されている、
抑止アナウンスを生成する。この抑止アナウンスは、データｂに含まれ、クライアント端
末１−１〜１−ｉに送信される。その際、抑止アナウンスは、Ｗｅｂ通信中継ソフトウェ
ア３１の応答信号（データｂ）として、再び、キャッシングモジュール４２、ＨＴＴＰモ
ジュール４１、レイヤ７負荷分散装置２４、データ中継装置２１を経て、クライアント端
末１−１〜１−ｉに送信される。
【００３９】
図８は、Ｗｅｂ通信中継ソフトウェア３１の内部構成についての説明図である。Ｗｅｂ
通信中継ソフトウェア３１は、主記憶装置３０に記憶される。Ｗｅｂ通信中継ソフトウェ
ア３１は、例えば、データ領域５０と、セッション処理プロセス４５とを含む。セッショ
ン処理プロセス４５は、例えば、ＨＴＴＰモジュール４１、キャッシングモジュール４２
、プロキシエンジン４３を含む。プロキシエンジン４３は、Ｗｅｂ通信中継ソフトウェア
３１の基本機能を実現し、通信データ送受信やセッション管理などを行う。ＨＴＴＰモジ
ュール４１は、ＨＴＴＰパケットの処理を行う。キャッシングモジュール４２は、ＨＴＴ
Ｐのキャッシングと輻輳制御を行う。また、データ領域は、例えば、プロキシエンジン使
用領域、ＨＴＴＰモジュール使用領域、キャッシングモジュール使用領域を含む。さらに
、キャッシングモジュール使用領域は、例えば、ＵＲＩハッシュ、ＵＲＩエントリ及びＵ
ＲＩ文字列、アクセス規制／抑止、メッセージ及びフォーマット、キャッシュエントリ領
域、キャッシュデータ領域を含む。
【００４０】
図９は、ＵＲＩハッシュとＵＲＩエントリによるＵＲＩ管理についての説明図である。
ＵＲＩハッシュ７０は、例えば、Ｋｅｙ０〜ｎのＵＲＩエントリのリスト７０−０〜７０
−ｎを含む。Ｋｅｙ０のＵＲＩエントリのリスト７０−０は、例えば、ＵＲＩエントリ７
１として、ＵＲＩ１（監視・規制）７１−１と、ＵＲＩ２（抑止）７１−２とを含む。ま
た、Ｋｅｙ２のＵＲＩエントリのリスト７０−２は、例えば、ＵＲＩエントリ７１として
、ＵＲＩ３（監視・規制）７１−３と、ＵＲＩ４（通常キャッシュ）７１−４と、ＵＲＩ
５（優先キャッシュ）７１−５とを含む。Ｋｅｙ ｎのＵＲＩエントリのリスト７０−ｎ
は、例えば、ＵＲＩｘ（通常キャッシュ）７１−ｘを含む。
【００４１】
ここで、ＵＲＩ４（通常キャッシュ）７１−４とＵＲＩｘ（通常キャッシュ）７１−ｘ
は、通常キャッシュエントリに通常キャッシュデータを含む。また、ＵＲＩ５（優先キャ
ッシュ）７１−５は、優先キャッシュエントリに優先キャッシュデータを含む。ここで、
ＵＲＩ管理について詳細に説明する。ＵＲＩエントリは、ＵＲＩをハッシュ関数にかけて
算出したハッシュキーを元にして、同一ハッシュキーでリスト化して管理している。この
例では、Ｋｅｙ０にはＵＲＩ１（監視・規制）７１−１、ＵＲＩ２（抑止）７１−２、Ｋ
ｅｙ２にはＵＲＩ３（監視・規制）７１−３、ＵＲＩ４（通常キャッシュ）７１−４、…
のＵＲＩエントリがリストされている。また、リスト中の各々のＵＲＩは、要求集約で監
視規制対象になっていたり、オペレータ指示で抑止対象や優先キャッシュ対象になってい
たり、通常キャッシュであったり、渾然一体となってリスト化されている。このうち、例
えば、通常キャッシュであるＵＲＩ４（通常キャッシュ）７１−４のエントリは、通常キ
ャッシュエントリの特定のアドレスを示し、同様に、優先キャッシュであるＵＲＩ５（優
先キャッシュ）７１−５のエントリは、優先キャッシュエントリの特定のアドレスを示し
ている。
【００４２】
また、主記憶装置３０上のＷｅｂ通信中継ソフトウェア内キャッシングモジュール使用
領域には、例えば、通常キャッシュエントリ領域、優先キャッシュエントリ領域、キャッ
シュデータ領域が設けてあり、それぞれ所定の大きさに区切って準備されている。実際の
ＵＲＩ４（通常キャッシュ）７１−４のコンテンツデータは、ＵＲＩ４（通常キャッシュ
）７１−４のキャッシュエントリで示されたアドレスの通常キャッシュエントリ領域に格
納され、コンテンツの大きさによって必要な量だけ通常キャッシュデータ領域が追加され
る。同様に、実際のＵＲＩ５（優先キャッシュ）７１−５のコンテンツデータは、ＵＲＩ
５（優先キャッシュ）７１−５のキャッシュエントリで示されたアドレスの優先キャッシ
ュエントリ領域に格納され、コンテンツの大きさによって必要な量だけ優先キャッシュデ
ータ領域が追加される。
【００４３】
つぎに、主記憶装置３０に記憶されるキャッシングモジュール使用領域について説明す
る。なお、キャッシングモジュール使用領域は、主記憶装置３０以外の適宜の記憶装置内
に設けることができる。図１０は、キャッシングモジュール使用領域内のデータ構造につ
いての説明図（１）である。キャッシングモジュール使用領域は、例えば、ＵＲＩエント
リ７１、キャッシュエントリ７２とを含む。ここで、ＵＲＩエントリ７１としては、例え
ば、ＵＲＩ（例：http://www.abcde.co.jp/index.html）、制御タイプ（例：通常キャッ
シュ）、アクセスカウンタ（例：３）、キャッシュエントリ情報を含む。
【００４４】
キャッシュエントリ７２は、例えば、ＵＲＩエントリ情報（例：http://www.abcde.co.
jp/index.htmlに関するＵＲＩエントリ）、キャッシュエントリタイプ（例：通常キャッ
シュ）、キャッシュの状態（例：キャッシング中）、オーナーセッション（例：セッショ
ンＮｏ．ｎ）、応答待ちセッションリスト（例：セッションＮｏ．ｘ，Ｎｏ．ｙ）、キャ
ッシュデータ情報を含む。なお、優先キャッシュエントリと通常キャッシュエントリは、
キャッシュエントリタイプの値が異なるが、内容は同様である。また、キャッシングモジ
ュール４２内では、優先キャッシュエントリは、運用者の要求がない限り削除されない。
但し、通常キャッシュエントリは、資源が不足すると削除される。
【００４５】
図１１は、キャッシングモジュール使用領域内のデータ構造についての説明図（２）で
ある。キャッシングモジュール使用領域は、また、例えば、キャッシュデータ７３を含む
。キャッシュデータ７３は、例えば、キャッシュエントリ情報（例：http://www.abcde.c
o.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 とする。
【００５３】
このように、ＵＲＩチェックでは、ＵＲＩハッシュ検索の前に、ＣＧＩなど動的に生成
されるページのチェックを行う。具体的には、ＵＲＩで示されたファイルの識別子と、Ｃ
ＧＩ特有のパラメータ（引数）の有無によって判定を行い、ＣＧＩなど動的に生成される
ページであると判定した場合には、引数の省略処理を行って、簡略化した短いＵＲＩを生
成する。これにより、さまざまなクエリを持つＣＧＩを、クエリを含めた別々のＵＲＩと
して処理するのではなく、１つのＵＲＩとして処理し、アクセスの監視・規制を実現する
。また、ＵＲＩのチェック（１）では、上記判定と共に、キャッシュ可否の判定を行う。
一方、ＵＲＩのチェック（２）では、予めキャッシュ不可のＵＲＩであることが分かって
いるため、キャッシュ可否判定処理を行わない。
【００５４】
（ステップＳ１０７、１０９のＵＲＩハッシュ検索（１）（２））
ステップＳ１０７のＵＲＩハッシュ検索（１）では、次のような処理を実行する。例えば
、メモリ上にキャッシュの領域があり、クライアント端末と通信しているＵＲＩはメモリ
上に記憶されており、そのメモリテーブルをＵＲＩハッシュとすることができる。
（ａ）ＵＲＩハッシュを検索する。
（ｂ）ＵＲＩエントリにヒットした場合は、ＵＲＩエントリの制御タイプを参照し、そこ
に記述されている制御に決定する。
（ｃ）ＵＲＩエントリにヒットしなかった場合は、「通常キャッシュ」処理に決定する。
【００５５】
ステップＳ１０９のＵＲＩハッシュ検索（２）では、
（ａ）「ＵＲＩの加工」が行われなかった場合は、ＨＴＴＰ要求にあるＵＲＩを使ってＵ
ＲＩハッシュを検索する。
（ｂ）ＵＲＩエントリにヒットした場合は、ＵＲＩエントリの制御フラグを参照し、そこ
に記述されている制御に決定する。
（ｃ）ＵＲＩエントリにヒットしなかった場合は、「アクセス監視・規制」処理に決定す
る。
【００５６】
（ステップＳ１１１の通常キャッシュに決定）
図１６は、通常キャッシュ処理についてのフローチャートである。
（１）まず、キャッシュヒットを判定する（Ｓ１１１−１）。
（１−１）ヒットしなかった場合は、最初のアクセス要求としてＷｅｂサーバへ要求を中
継する処理に移り、キャッシングモジュール４２は、例えば、（ａ）通常ＵＲＩエントリ
の作成、（ｂ）通常キャッシュエントリの作成、（ｃ）ＵＲＩハッシュへ登録、（ｄ）キ
ャッシュエントリにオーナの設定、等を行う通常キャッシング前処理を行う（Ｓ１１１−
１１）。つぎに、Ｗｅｂサーバへ要求を転送し（Ｓ１１１−１２）、Ｗｅｂサーバから応
答を受信し（Ｓ１１１−１３）、さらに、クライアントへ応答を転送する（Ｓ１１１−１
４）。つぎに、キャッシングモジュール４２は、通常キャッシングを行う（ステップＳ１
１１−１５）。ここで、ステップＳ１１１−１５の通常キャッシングでは、例えば、次の
処理が行われる。
（ａ）通常キャッシュデータの確保。
（ｂ）Ｗｅｂ通信装置の応答をコピー。
（ｃ） （ａ）、（ｂ）をデータがあるまで続ける。
（ｄ）応答待ちセッションリストに登録があるか検査する。
（ｅ） （ｄ）で応答待ちセッションがある場合は、処理開始指示を送る。
（ｆ）オーナの設定を解除する。
【００５７】
（１−２）ヒットした場合、要求集約判定に移る（Ｓ１１１−２）。ここでは、キャッ
シングモジュール４２は、例えば、Ｗｅｂサーバへのアクセス負荷を軽減するため、キャ
ッシュできるコンテンツに対して、アクセス要求を一つに集約する機能を備える。この機
能は、Ｗｅｂサーバから応答が戻る前に、同一コンテンツに対して複数の要求が重複した
場合、最初の要求だけＷｅｂサーバへ中継し、残りの要求は一旦処理待ち状態とし、最初
の要求に対する応答が戻ってから処理を再開するものである。具体的には、集約処理を以
下のように行う。ここで、ステップＳ１１１−２の集約判定処理では、（ａ）キャッシュ
の状態は、準備完了となっているかを判定し、準備完了となっているのであれば、Ｎｏと
する。また、（ｂ）キャッシュエントリのオーナは、現在判定処理を行っているセッショ
ンかを判定し、他のセッションがオーナである場合は、Ｙｅｓとし、そうでなければ、Ｎ
ｏとする。
【００５８】
（２）要求集約判定でＹｅｓの場合、Ｗｅｂサーバへ中継した要求の処理が終わるまで
、処理を中止する（Ｓ１１１−３）。ここで、ステップＳ１１１−３の処理可能となるま
で待機する処理では、（ａ）キャッシュエントリの応答待ちセッションリストにセッショ
ンを登録し、（ｂ）呼び出されるまで待機する。
【００５９】
（３）つぎに、ステップＳ１１１−３の後、処理が可能になると、又は、ステップＳ１
１１−２で集約を行わない場合、キャッシュ有効期限判定に移る（Ｓ１１１−４）。ここ
で、ステップＳ１１１−４のキャッシュ有効期限の判定では、キャッシュ中のＲＦＣ２６
１６に記述されている通りに有効期限を計算し、期限内であれば、Ｙｅｓとし、期限切れ
であれば、Ｎｏとする。
【００６０】
キャッシュ有効期限判定でＹｅｓの場合、キャッシュからデータを取り出す（Ｓ１１１
−５）。ここで、ステップＳ１１１−５のキャッシュ取出しでは、（ａ）必要な分だけキ
ャッシュデータをアクセスする。つぎに、ステップＳ１１１−５で取り出したデータを、
クライアントへデータを転送する（Ｓ１１１−６）。なお、通常、このケースでは、直前
に新鮮なデータがキャッシュされている確率が高い（何故なら、最初の要求がＷｅｂサー
バからデータを取ってくるのを待っていた）ので、キャッシュが有効期限内にある確率も
高い。結果として、Ｗｅｂサーバへのアクセス要求数が減り、アクセス負荷を軽減できる
。
【００６１】
（４）一方、キャッシュ有効期限判定でＮｏの場合、Ｗｅｂサーバへ要求を転送し（Ｓ
１１１−７）、Ｗｅｂサーバから応答を受信し（Ｓ１１１−８）、さらに、クライアント
へ応答を転送する（Ｓ１１１−９）。つぎに、キャッシングモジュール４２は、通常キャ
ッシングを行う（Ｓ１１１−１０）。なお、（１−１）で、最初のアクセスとして処理し
た要求は、通常キャッシング処理（Ｓ１１１−１０）で、処理が中止になっている要求が
存在するか検査する。存在した場合は、処理の再開指示を出す。
【００６２】
なお、ステップＳ１１１−１の前に、後述のような監視・規制の処理を追加することも
できる。その際、後述のように、まず、監視・規制前処理（Ｓ１１７−１）を追加して、
その後に、規制を行うか否か判定する（Ｓ１１７−２）。ここで、規制を行わない場合、
ステップＳ１１１−１に移行する。一方、規制を行う場合、規制メッセージを取得する処
理（Ｓ１１７−３）、規制メッセージよりコンテンツを作成する処理（Ｓ１１７−４）、
及び、クライアントへコンテンツを転送する処理（Ｓ１１７−５）を実行する。さらに、
ステップＳ１１１−６、Ｓ１１１−１０、Ｓ１１１−１５の後に、監視・規制後処理（１
１７−９）が追加され、その実行後、処理終了となる。
【００６３】
図１７は、Ｗｅｂ通信装置のＨＴＴＰ応答の説明図である。このＷｅｂ通信装置のＨＴ
ＴＰ応答８５は、例えば、ステップＳ１１１−８、１３に含まれるものである。
【００６４】
図１８は、Ｗｅｂコンテンツデータの管理についての説明図である。まず、Ｗｅｂ通信
中継ソフトウェア３１内のキャッシングモジュール４２は、Ｗｅｂ通信装置ＨＴＴＰ応答
８５を受信する。キャッシングモジュール４２は、Ｗｅｂ通信装置ＨＴＴＰ応答８５を、
例えば、Ｗｅｂ通信装置ＨＴＴＰ応答Ｐａｒｔ １を含むキャッシュエントリ５５−１と
、Ｗｅｂ通信装置応答データＰａｒｔ ２を含むキャッシュデータ５５−２と、Ｗｅｂ通
信装置応答データＰａｒｔ ｎを含むキャッシュデータ５５−ｎとに区分し、キャッシン
グモジュール使用領域に格納する。
【００６５】
（ステップＳ１１３の優先キャッシュに決定）図１９は、優先キャッシュ処理について
のフローチャートである。なお、ここでのフローチャートは、上述したステップＳ１１１
の通常キャッシュ処理と比較して、通常キャッシュが優先キャッシュとなったことで変更
された処理以外は、同様である。まず、キャッシングモジュール４２は、キャッシュはヒ
ットしたか否かを判定し（Ｓ１１３−１）、キャッシュヒットがあれば、集約を行うか否
かを判定する（Ｓ１１３−２）。ここで、ステップＳ１１３−２の集約判定処理では、（
ａ）キャッシュの状態は、準備完了となっているかを判定し、準備完了となっているので
あれば、Ｎｏする。また、（ｂ）優先キャッシュエントリのオーナは、現在判定処理を行
っているセッションかを判定し、他のセッションが持ち主である場合は、Ｙｅｓとし、そ
うでなければ、Ｎｏとする。
【００６６】
つぎに、キャッシングモジュール４２は、ステップＳ１１３−２で集約を行う場合、処
理可能になるまで待つ（Ｓ１１３−３）。ここで、ステップＳ１１３−３の処理可能にな
るまで待つ処理では、（ａ）キャッシュエントリの応答待ちセッションリストにセッショ
ンを登録し、（ｂ）呼び出されるまで待機する。つぎに、キャッシングモジュール４２は
、キャッシュは有効期限内か否かを判定する（Ｓ１１３−４）。ここで、ステップＳ１１
３−４のキャッシュ有効期限の判定では、ＲＦＣ２６１６に記述されている通りに有効期
限を計算し、期限内であれば、Ｙｅｓとし、期限切れであれば、Ｎｏとする。ここで、キ
ャッシュが有効期限内であれば、キャッシュを取出す（Ｓ１１３−５）。ここで、ステッ
プＳ１１３−５のキャッシュ取出しでは、（ａ）必要な分だけキャッシュデータをアクセ
スする。つぎに、キャッシングモジュール４２は、クライアントへキャッシュを転送する
（Ｓ１１３−６）。
【００６７】
また、キャッシングモジュール４２は、ステップＳ１１３−４でキャッシュが有効期限
内でない場合、Ｗｅｂサーバへ要求を転送し（Ｓ１１３−７）、Ｗｅｂサーバから応答を
受信し（Ｓ１１３−８）、さらに、クライアントへ応答を転送する（Ｓ１１３−９）。つ
ぎに、キャッシングモジュール４２は、優先キャッシングを行う（Ｓ１１３−１０）。こ
こで、ステップＳ１１３−１０の優先キャッシングでは、（ａ）優先キャッシュデータの
確保、（ｂ）Ｗｅｂ通信装置の応答をコピー、（ｃ） （ａ）、（ｂ）をデータがあるま
で続ける、（ｄ）応答待ちセッションリストに登録があるか検査する、（ｅ） （ｄ）で
応答待ちセッションがある場合は、処理開始指示を送る、（ｆ）オーナの設定を解除する
、等を行う。
【００６８】
また、キャッシングモジュール４２は、ステップＳ１１３−１でキャッシュがヒットし
なかった場合、通常キャッシング前処理を行う（Ｓ１１３−１１）。ここで、ステップＳ
１１３−１１の優先キャッシング前処理としては、例えば、（ａ）優先ＵＲＩエントリの
作成、（ｂ）優先キャッシュエントリの作成、（ｃ）ＵＲＩハッシュへ登録、（ｄ）優先
キャッシュエントリにオーナを設定することが挙げられる。
【００６９】
また、キャッシングモジュール４２は、ステップＳ１１３−１１の後、Ｗｅｂサーバへ
要求を転送し（Ｓ１１３−１２）、Ｗｅｂサーバから応答を受信し（Ｓ１１３−１３）、
さらに、クライアントへ応答を転送する（Ｓ１１３−１４）。つぎに、キャッシングモジ
ュール４２は、優先キャッシングを行う（Ｓ１１３−１５）。なお、ステップＳ１１３−
１５での優先キャッシングは、ステップＳ１１３−１０での処理と同様である。
【００７０】
なお、ステップＳ１１３−１の前に、後述のような監視・規制の処理を追加することも
できる。その際、後述のように、まず、監視・規制前処理（Ｓ１１７−１）を実行し、そ
の後に、規制を行うか否か判定する（Ｓ１１７−２）。ここで、規制を行わない場合、ス
テップＳ１１１−１に移行する。一方、規制を行う場合、規制メッセージを取得する処理
（Ｓ１１７−３）、規制メッセージよりコンテンツを作成する処理（Ｓ１１７−４）、及
び、クライアントへコンテンツを転送する処理（Ｓ１１７−５）を実行する。さらに、ス
テップＳ１１３−６、Ｓ１１３−１０、Ｓ１１３−１５の後に、監視・規制後処理（１１
７−９）が追加され、その実行後、処理終了となる。
【００７１】
（ステップＳ１１５のアクセス抑止に決定）
アクセス抑止コンテンツの作成方法としては、例えば、アクセス抑止メッセージとアクセ
ス抑止コンテンツのフォーマットを用意して動的に生成する。例えば、上に、アクセス抑
止メッセージ群とアクセス抑止コンテンツのフォーマットを格納しておく。キャッシング
モジュール４２は、状態に応じてふさわしいメッセージを取り出し、アクセス抑止コンテ
ンツフォーマットに挿入することでアクセス抑止コンテンツを生成する。例えば、以下の
図に示すように、抑止時の一般的なメッセージ９３「要求されたコンテンツは利用できま
せん」を使って、アクセス抑止メッセージフォーマットに挿入し、アクセス抑止コンテン
ツを生成している。
【００７２】
図２０は、アクセス抑止処理についてのフローチャートである。まず、キャッシングモ
ジュール４２は、抑止メッセージを取得し（Ｓ１１５−１）、抑止メッセージよりコンテ
ンツを作成して（Ｓ１１５−２）、クライアントへコンテンツを転送する（Ｓ１１５−３
）。
【００７３】
図２１は、抑止メッセージ、抑止コンテンツの説明図である。抑止メッセージ９１は、
例えば、「要求されたコンテンツはご利用できません」と対応させて表示されるものであ
る。また、抑止コンテンツ９３は、例えば、図示のように、表示される。
【００７４】
（ステップＳ１１７のアクセス監視・規制の決定）
図２２は、アクセス監視・規制処理についてのフローチャートである。まず、キャッシン
グモジュール４２は、監視・規制前処理を行う（Ｓ１１７−１）。ここで、ステップＳ１
１７−１の監視・規制前処理では、次の処理を行う。
（ａ）ＵＲＩエントリを作成していなければ作成する。
（ｂ）（ａ）を実行した場合は、ＵＲＩハッシュに登録する。
（ｃ）ＵＲＩエントリ中のアクセスカウントを１増やす。
【００７５】
つぎに、キャッシングモジュール４２は、規制を行うか否かを判定する（Ｓ１１７−２
）。ここで、ステップＳ１１７−２の規制判定処理では、（ａ）ＵＲＩエントリのアクセ
スカウンタ、（ｂ）ＵＲＩエントリの規制実行フラグ、（ｃ）装置に設定された規制開始
接続数、（ｄ）装置に設定された規制終了接続数を参照して、（ｂ）の規制実行フラグが
設定されていない場合、（ａ）＞（ｃ）ならばＹｅｓとし、そうでなければＮｏとする。
一方、（ｂ）の規制実行フラグが設定されている場合、（ａ）＞（ｄ）ならばＹｅｓとし
、そうでなければＮｏとする。
【００７６】
キャッシングモジュール４２は、ステップＳ１１７−２で規制を行う場合、規制メッセ
ージを取得し（Ｓ１１７−３）、規制メッセージよりコンテンツを作成して（Ｓ１１７−
４）、クライアントへコンテンツを転送する（Ｓ１１７−５）。一方、ステップＳ１１７
−２で規制を行わない場合、キャッシングモジュール４２は、Ｗｅｂサーバへ要求を転送
し（Ｓ１１７−６）、Ｗｅｂサーバから応答を受信して（Ｓ１１７−７）、クライアント
へ応答を転送する（Ｓ１１７−８）。
【００７７】
また、キャッシングモジュール４２は、ステップＳ１１７−５、８の後、監視・規制後
処理を行う（Ｓ１１７−９）。ここで、ステップＳ１１７−９の監視・規制後処理では、
次の処理が行われる。
（ａ）ＵＲＩエントリ中のアクセスカウントを１減らす。
（ｂ）アクセスカウンタが０ならば、ＵＲＩハッシュから削除する。
（ｃ）（ｂ）で削除を実行した場合は、ＵＲＩエントリを削除する。
【００７８】
図２３は、規制メッセージ、規制コンテンツの説明図である。アクセス規制メッセージ
の作成方法についても、上述したアクセス抑止コンテンツの作成方法と同様である。規制
メッセージ９５は、例えば、「現在、混み合っているため後でご利用ください」と対応さ
せて表示されるものである。また、規制コンテンツ９７は、例えば、図示のように表示さ
れる。
【００７９】
なお、キャッシングモジュール４２では、例えば、ステップＳ１１７−２において、以
下のような処理を行い、規制を行うか否かの判断基準としてもよい。
Ａ．ＵＲＩエントリ新たなパラメータを追加する。
Ｂ．パラメータには、過去にＷｅｂ通信中継装置がサーバに当該ＵＲＩの要求を送信した
ときの応答時間の平均を入れる。
Ｃ．アクセス数が１以上のときは、Ａ．で追加したパラメータも考慮し、例えば、アクセ
ス数がある程度存在し、通信に設定時間以上かかりそうな場合は、上述の規制開始接続数
に満たなくても規制する。
【００８０】
（ステップＳ１１９の制御なしに決定）図２４は、制御なし処理についてのフローチャ
ートである。まず、キャッシングモジュール４２は、Ｗｅｂサーバへ要求を転送し（Ｓ１
１９−１）、Ｗｅｂサーバから応答を受信して（Ｓ１１９−２）、クライアントへ応答を
転送する（Ｓ１１９−３）。ここで、ガベージコレクション（装置内資源の再利用）につ
いて説明すると、キャッシュ領域に空きが無くなると、データ格納が古かったり、アクセ
ス回数が低い領域を消去して再利用するために、ガベージコレクション処理を行う。ガベ
ージコレクション処理の際には、優先キャッシュエントリは対象外とし、さらに優先キャ
ッシュフラグを参照して、優先キャッシュとして使用されているデータ領域も処理の対象
外とする追加判定を行っている。
【００８１】
なお、通信システムがＲＦＣ２６１６に未定義のリクエストメソッドに対応しないとき
は、制御なし（Ｓ１１９、Ｓ２１１）を設置することなく発明の効果が得られる。また、
通信システムがＨＥＡＤメソッドをキャッシュとして処理しない場合は、ステップＳ１０
１におけるＨＥＡＤメソッドの処理を（ｂ）ではなく（ｃ）で処理することで対応できる
。以下に、アクセス監視・規制に用いる規制開始接続数と規制終了接続数を動的に変更す
る場合について説明する。
【００８２】
図２５は、拡張したＵＲＩエントリを示す図である。ＵＲＩエントリを図２５に示すよ
うに拡張することで、アクセス監視・規制に用いる規制開始接続数と規制終了接続数は、
あらかじめ装置に設定した値だけでなく、動的に変更した値を利用できる。例えば、規制
開始時刻と規制終了時刻により、次回の規制開始接続数と規制終了接続数を定める。
【００８３】
図２６は、規制開始接続数と規制終了接続数の動的な変更を示す説明図である。ここで
は、規制開始接続数と規制終了接続数を動的に決定する場合の一例で、ＵＲＩ１とＵＲＩ
２に対する接続数の変化を示している。ここでは、ＵＲＩ１およびＵＲＩ２とも、図２５
に示したＵＲＩエントリを利用しており、規制開始接続数と規制終了接続数にそれぞれ初
期の接続数が設定されている。図２６では、ＵＲＩ１とＵＲＩ２が時刻ｔ１にアクセス規
制の制御が開始されている。この例では、規制開始を行うときにそれぞれのＵＲＩエント
リに規制開始時刻ｔ１を記憶する。規制が終了すると、ｔ１と規制終了時刻ｔ２およびｔ
３を利用して、規制実施時間を求める。ＵＲＩ１の規制実施時間Ｔ１はｔ２−ｔ１、ＵＲ
Ｉ２の規制実施時間Ｔ２はｔ３−ｔ１となる。これを、通信システムが想定している標準
規制実施時間Ｔと比較し、次の規制開始接続数と規制終了接続数を定める。この例では、
Ｔ１の値がＴより非常に小さいので、ＵＲＩ１の規制開始接続数と規制終了接続数を一定
数増加している。また、Ｔ２は、Ｔとそれほど変わらないため、値を変更していない。
【００８４】
また、図２５のように拡張したＵＲＩエントリでは、アクセス監視・規制を異なる方法
で実施できる。Ｗｅｂ通信ソフトウェア３１内部のプロキシエンジン利用領域には、Ｗｅ
ｂ通信ソフトウェア３１がＷｅｂ通信装置３−１〜３−ｎに対して要求した際の平均応答
時間が保存されている。さらにＵＲＩエントリには、ＵＲＩごとの平均応答時間が記憶さ
れている。ＵＲＩに対して一定数の要求がある場合、Ｗｅｂ通信ソフトウェア３１全体の
平均応答時間とＵＲＩごとの平均応答時間を比較し、ＵＲＩごとの平均応答時間の応答時
間が著しく大きい場合は、アクセス規制処理を行うことで輻輳を回避できる。
【図面の簡単な説明】
【００８５】
【図１】通信システムの構成図。
【図２】Ｗｅｂ通信中継装置の構成図。
【図３】大規模Ｗｅｂ通信中継装置におけるデータの送受信についての説明図。
【図４】キャッシュヒット時の説明図及びシーケンス図。
【図５】キャッシュミスヒット時の説明図及びシーケンス図。
【図６】輻輳時の説明図及びシーケンス図。
【図７】アクセス抑止対象コンテンツが要求された場合の説明図及びシーケンス図。
【図８】Ｗｅｂ通信中継ソフトウェア３１の内部構成についての説明図。
【図９】ＵＲＩハッシュとＵＲＩエントリによるＵＲＩ管理についての説明図。
【図１０】共用メモリ５５内のデータ構造についての説明図（１）。
【図１１】共用メモリ５５内のデータ構造についての説明図（２）。
【図１２】キャッシング及び輻輳制御処理について基本的な処理を示すフローチャート。
【図１３】キャッシュチェックおよび輻輳制御処理判定についてのフローチャート。
【図１４】クライアントのＨＴＴＰ要求についての説明図。
【図１５】ＵＲＩの加工についての説明図。
【図１６】通常キャッシュ処理についてのフローチャート。
【図１７】Ｗｅｂ通信装置のＨＴＴＰ応答の説明図。
【図１８】Ｗｅｂコンテンツデータの管理についての説明図。
【図１９】優先キャッシュ処理についてのフローチャート。
【図２０】アクセス抑止処理についてのフローチャート。
【図２１】抑止メッセージ、抑止コンテンツの説明図。
【図２２】アクセス監視・規制処理についてのフローチャート。
【図２３】規制メッセージ、規制コンテンツの説明図。
【図２４】制御なし処理についてのフローチャート。
【図２５】拡張したＵＲＩエントリを示す図。
【図２６】規制開始接続数と規制終了接続数の動的な変更を示す説明図。
【符号の説明】
【００８６】
１−１〜１−ｉ クライアント端末
２ 大規模Ｗｅｂ通信中継装置
３−１〜３−ｊ Ｗｅｂ通信装置
２１ データ中継装置
２２ 認証装置
２３ システム管理装置
２４ レイヤ７負荷分散装置
２５−１〜２５−ｎ Ｗｅｂ通信中継装置
２６ アクセス規制装置
３１ Ｗｅｂ通信中継ソフトウェア
４１ ＨＴＴＰモジュール
４２ キャッシングモジュール
４３ プロキシエンジン
１００ 通信システム
【図１】
0004687758.tif 000002
【図２】
0004687758.tif 000003
【図３】
0004687758.tif 000004
【図４】
0004687758.tif 000005
【図５】
0004687758.tif 000006
【図６】
0004687758.tif 000007
【図７】
0004687758.tif 000008
【図８】
0004687758.tif 000009
【図９】
0004687758.tif 000010
【図１０】
0004687758.tif 000011
【図１１】
0004687758.tif 000012
【図１２】
0004687758.tif 000013
【図１３】
0004687758.tif 000014
【図１４】
0004687758.tif 000015
【図１５】
0004687758.tif 000016
【図１６】
0004687758.tif 000017
【図１７】
0004687758.tif 000018
【図１８】
0004687758.tif 000019
【図１９】
0004687758.tif 000020
【図２０】
0004687758.tif 000021
【図２１】
0004687758.tif 000022
【図２２】
0004687758.tif 000023
【図２３】
0004687758.tif 000024
【図２４】
0004687758.tif 000025
【図２５】
0004687758.tif 000026
【図２６】
0004687758.tif 000027