JP2006222631A - 輻輳制御装置、および、ネットワークの輻輳制御方法 - Google Patents

Abstract

【課題】ＩＰネットワークにおいて負荷の高いＷｅｂサーバへのアクセスを効率的に規制し、トータルのスループットを向上させ、Ｗｅｂサーバやシステムの停止を防止すると同時に、ユーザへのサービス効率の向上を実現する。
【解決手段】ＩＰネットワークに設置する輻輳制御装置において、ＩＰアドレスとホスト名との対応関係を記憶しておき、新たにクライアントからＷｅｂサーバに要求があったときに、ＤＮＳサーバによりＷｅｂサーバのＩＰアドレスを取得し、当該ＩＰアドレスのＷｅｂサーバが輻輳状態であると判定された場合には、記憶した対応関係の中の同じホスト名に対する輻輳状態でない異なるＩＰアドレスを検索して、そのＩＰアドレスのＷｅｂサーバに対して、クライアントからの要求を振り分ける。
【選択図】 図１

Description

本発明は、クライアントとＷｅｂサーバ間の通信を中継する輻輳制御装置、および、ネットワークの輻輳制御方法に係り、特に、ＷｅｂサーバがＤＮＳラウンドロビンによって複数のＩＰアドレスのＷｅｂサーバで構成されている際の輻輳制御に用いて好適な輻輳制御装置、および、ネットワークの輻輳制御方法に関する。

インターネットが急速に普及し、インターネットを通した情報提供・各種サービスが、より身近におこなわれるようになってきた。また、ＰＣ端末からだけでなく携帯端末からのアクセスも快適におこなえるようになり、携帯ユーザの増大に伴い、Ｗｅｂサーバへのアクセスも増加の傾向にある。

このようなネットワーク環境においては、各ユーザが直接Ｗｅｂサーバにアクセスするような従来方式では、特定のＷｅｂサーバ、例えば、チケット予約、証券取引や人気コンテンツのダウンロードといったサービスを提供するＷｅｂサーバへアクセスが集中する場合が多くある。その結果、集中するアクセス要求に、通信回線容量やＷｅｂサーバの処理能力が追い付かず、応答に時間がかかったり、無応答になったり、最悪の場合、Ｗｅｂサーバ自体がダウンしたりすることもある。

こういった問題に対して、Ｗｅｂサーバ側の対策として、ＤＮＳラウンドロビンを利用した負荷分散を用いる方法が以前よりおこなわれてきた。ＤＮＳラウンドロビンは、以下の非特許文献１に記載されているように、ホスト名の解決をおこなうＤＮＳサーバに、あるホスト名に対するＩＰアドレスを複数登録しておき、クライアントからホスト名解決の要求があった際には、順に異なるＩＰアドレスを回答することにより、実際にアクセスされるＷｅｂサーバを分散させる方法である。この方法により、登録したＩＰアドレスに対応した複数のＷｅｂサーバを設置することで負荷分散を実現することができる。

一方、インターネット環境を提供する側の対策として、クライアントとＷｅｂサーバとの間に輻輳制御装置と呼ばれる中継装置を設け、Ｗｅｂサーバへのアクセスを制御する方法が行われている。輻輳制御装置は、クライアントのＷｅｂサーバへのアクセスを中継する一方で、各Ｗｅｂサーバへの同時アクセス数や、レスポンス時間、タイムアウト回数等を監視し、各々予め設定した閾値を超えた場合、当該Ｗｅｂサーバを輻輳状態と判定し、以後、同時アクセス数や、レスポンス時間が閾値を下回る等、輻輳状態が解除されたと判定されるまで、クライアントへ輻輳メッセージを返信することにより、当該Ｗｅｂサーバへのアクセスを規制する。このようにして、Ｗｅｂサーバへの過剰なアクセス集中やサーバダウンを未然に防止することができる。

通常、輻輳制御装置は、Ｗｅｂサーバへのアクセス制御をホスト名単位で管理しているため、上記ＤＮＳラウンドロビンを用いたＷｅｂサーバへの輻輳制御の際、複数のＷｅｂサーバの一つが輻輳状態と判定された場合、他のＷｅｂサーバの状態に拘わらず、当該ホストへのリクエストは全て規制されてしまうという問題がある。

これに対しては、輻輳制御装置で、Ｗｅｂサーバへのアクセス制御をホスト名単位ではなく、ＩＰアドレス単位で管理する方法が用いられてきた。この方法により、ＤＮＳラウンドロビンを用いたＷｅｂサーバのＩＰアドレスの一つが輻輳状態と判定されても、同じホスト名で、異なるＩＰアドレスのＷｅｂサーバに対するアクセスに関しては通常通り処理できる。

また、別のアプローチとして、クライアント側やＤＮＳサーバ側で、ＤＮＳラウンドロビンにより構成される複数のＷｅｂサーバの負荷状態を常時または定期的に監視し、アドレス解決要求に対して、負荷の低い、あるいは接続要求の応答が速いサーバのＩＰアドレスを順に返信する方法がある。これにより、あるＷｅｂサーバが輻輳状態となった場合でも、当該ＷｅｂサーバのＩＰアドレスを避け、同一ホスト名に対する別のＩＰアドレスを返信することにより、輻輳状態と判定されたＷｅｂサーバへのアクセスを規制することができる。例として、以下の特許文献１には、クライアント側のリゾルバが、ＤＮＳサーバで解決された複数のＩＰアドレス全てに対してＴＣＰの接続要求をおこない、一番速く応答が返ってきたＩＰアドレスを選択するという技術が開示されている。

米国特許出願公開番号ＵＳ２００３／００５５９７９ RFC1034 "DOMAIN NAMES CONCEPTS AND FACILITIES"（http://www.rfc-editor.org/download.htmlよりダウンロード可）

上記従来技術のように、輻輳制御装置が、ＩＰアドレス単位で輻輳を制御管理している場合には、ＤＮＳラウンドロビンを用いた複数台のＷｅｂサーバのうちの１台が輻輳状態であると判定された場合、例えば、あるＷｅｂサーバのホスト名に対してｎ台のＷｅｂサーバで構成されていると、クライアントからのアクセスのＤＮＳに対するアドレス解決要求のうち、ｎ回に１回は輻輳状態であると判定されたＷｅｂサーバのＩＰアドレスが返されることになり、当該ＩＰアドレスが輻輳状態である期間中は、当該ホスト名に対する要求のｎ回に１回に対しては規制メッセージを返信することになってしまい、ユーザへのサービス効率が低下してしまうという問題がある。

また、クライアント側やＤＮＳサーバ側で、ＤＮＳラウンドロビンによる複数のＷｅｂサーバの負荷状態を常時または定期的に監視し、アドレス解決要求に対して、負荷の低いサーバのＩＰアドレスを順に返信する方法を実現するためには、個々のＷｅｂサーバの負荷状態をチェックするため、常時あるいは定期的に何らかの通信をおこなう必要があり、Ｗｅｂサーバが多数存在する場合、個々のＷｅｂサーバの負荷状態管理のための負荷が増大したり、負荷チェックのための通信でネットワークが混雑したりするという問題がある。

本発明は、上記問題点を解決するためになされたもので、その目的は、複数のＩＰアドレスに割り当てられたＷｅｂサーバの中で、輻輳を回避し、トータルのスループットを向上させることができ、サービスの信頼性を向上することができる輻輳制御装置を提供することにある。

さらに本発明の目的は、従来のＤＮＳサーバやクライアント、Ｗｅｂサーバに手を加えることなく、この輻輳制御装置のみで上記サービス効率の向上を実現することができ、導入コストを削減することができる輻輳制御装置を提供することにある。

上記課題を解決するため、本発明の輻輳制御装置は、クライアントからＷｅｂサーバ宛の要求メッセージを中継する際に、ＤＮＳサーバにより宛先ＷｅｂサーバのＩＰアドレスを取得し、宛先Ｗｅｂサーバのホスト名と取得したＩＰアドレスとの対応関係を記憶しておき、 ＤＮＳサーバによって、新たにクライアントから送信された要求メッセージの宛先Ｗｅｂサーバのホスト名より、ＩＰアドレスを取得し、そのＩＰアドレスのＷｅｂサーバが輻輳状態であると判定された場合には、別のＩＰアドレスを検索する。そして、検索された別のＩＰアドレスのＷｅｂサーバが輻輳していない場合に、輻輳していないその別のＩＰアドレスのＷｅｂサーバに要求メッセージを送信する。

これにより、ＤＮＳラウンドロビンで構成された複数のＩＰアドレスのＷｅｂサーバの中で、輻輳状態と判定されたＩＰアドレスのＷｅｂサーバ宛の要求メッセージを、輻輳していない別のＩＰアドレスのＷｅｂサーバ宛に振り分け、クライアントへ返す輻輳メッセージを減らし、クライアントに対するサービス効率を向上させることができる。

さらに、ＤＮＳサーバがＤＮＳ逆引き機能に対応している場合には、 検索された別のＩＰアドレスが現在ネットワーク上で有効か否かということをＤＮＳ逆引き機能により確認することもできる。これは、Ｗｅｂサーバ側のネットワークの構成変更に対応するためである。

また、あるＩＰアドレスのＷｅｂサーバが輻輳中のときには、再度、ＤＮＳサーバに対応するＷｅｂサーバを問い合わせて、その別のＩＰアドレスが現在ネットワーク上で有効かということを確認することもできる。この手法でも、Ｗｅｂサーバ側のネットワークの構成変更に対応することができる。また、このときに、再問い合わせの上限回数を規定しておいてもよい。

以上の本発明の輻輳制御装置により、ＤＮＳラウンドロビンで構成された複数のＩＰアドレスのＷｅｂサーバの中で、輻輳状態と判定したＩＰアドレスのＷｅｂサーバ宛の要求を、輻輳していない別のＩＰアドレスのＷｅｂサーバ宛に振り分けることができ、クライアントへ返す輻輳メッセージを減らし、クライアントに対するサービス効率を向上させることができると同時に、新たに振り分けるＩＰアドレスの有効性を確認することができ、サービスの信頼性を向上させることができる。

さらには、従来のＤＮＳサーバやクライアント、Ｗｅｂサーバに手を加えることなく、この輻輳制御装置のみで上記サービス効率の向上を実現することができ、導入コストを削減することができる。

本発明によれば、複数のＩＰアドレスに割り当てられたＷｅｂサーバの中で、輻輳を回避し、トータルのスループットを向上させることができ、サービスの信頼性を向上することができる輻輳制御装置を提供することができる。

さらに、本発明によれば、従来のＤＮＳサーバやクライアント、Ｗｅｂサーバに手を加えることなく、この輻輳制御装置のみで上記サービス効率の向上を実現することができ、導入コストを削減することができる。

以下、本発明に係る各実施形態について、図１ないし図８を用いて説明する。

なお、以下の各実施形態では、宛先ＷｅｂサーバのＩＰアドレスを取得する手段として、インターネット上で最も成功している名前解決データベースであるＤＮＳシステムのＤＮＳサーバを用いた形態について記述しているが、ＩＰアドレスを取得する手段としては、ＤＮＳサーバに限定したものではない。

〔輻輳制御装置の構成〕
先ず、図１および図２を用いて本実施形態に係る輻輳制御装置の構成について説明する。
図１は、本実施形態の輻輳制御装置を用いたネットワーク構成を示すブロック図である。
図２は、本実施形態に係る輻輳制御装置のハードウェア構成を示すブロック図である。

先ず、図１を用いて本実施形態の輻輳制御装置の機能構成とそれを用いたネットワーク構成について説明する。

本実施形態の輻輳制御装置１０３は、図１に示されるようにＷｅｂサーバ１０２、通信処理部１１２、ＨＴＴＰ処理部１１１、ＤＮＳ処理部１０５、ＩＰアドレスキャッシュ部１０７、輻輳制御管理部１０４、および内部通信路１１３から構成される。

通信処理部１１２は、クライアント１０１やＷｅｂサーバ１０２、ＤＮＳサーバ１０６と外部通信回線１１４を介して通信をおこない、ＩＰパケットのやり取りをおこなう。ＨＴＴＰ処理部１１１は、クライアント１０１やＷｅｂサーバ１０２間のＨＴＴＰ（HyperText Transfer Protocol）プロトコルを中継し、それに関する処理をおこなう。ＤＮＳ処理部１０５は、ＤＮＳに関する処理をおこなう。ＩＰアドレスキャッシュ部１０７は、ＤＮＳサーバで解決されたＩＰアドレスとホスト名の対応関係をキャッシュとして保持する。輻輳制御管理部１０４は、ＩＰアドレスごとに対応するＷｅｂサーバの輻輳状態を保持し管理する。内部通信路１１３は、各部を結ぶ通信のためのバスである。

Ｗｅｂサーバ１０２は、ＤＮＳサーバ１０６に登録されている複数のＩＰアドレスに割り当てられたＷｅｂサーバ１：１０８、Ｗｅｂサーバ２：１０９、…、Ｗｅｂサーバｎ：１１０で構成される。

そして、クライアント１０１からＷｅｂサーバ１０２にＷｅｂページ取得などの要求メッセージを送ると、輻輳制御装置１０３は、その要求メッセージのＩＰパケットを受信し、ＤＮＳサーバ１０６に問い合わせて、ホスト名からＩＰアドレスを求め、そのＩＰアドレスに対応するＷｅｂサーバ１、Ｗｅｂサーバ２、…、ＷｅｂサーバｎのいずれかのＷｅｂサーバに要求メッセージを転送する。

本実施形態の輻輳制御装置１０３のハードウェア構成としては、図２に示される通り、プロセッサ４０１、メモリ装置４０２、入力装置４０３、ディスク装置４０４、通信制御装置４０５、内部通信回線４０６、表示装置４０７から構成される。

プロセッサ４０１は、メモリ装置４０２に読み込まれたプログラムを実行し、入出力装置に関する動作の指令を与え、装置全体を制御する。メモリ装置４０２は、処理を実行するプログラムやデータを読み込んで一時的に保持したり、後述のＩＰアドレス管理表２０１や輻輳管理表３０１などのテーブルを、プログラムの実行中に読み書きするために記憶する。入力装置４０３は、輻輳制御設定等の指示や情報を入力するため装置であり、キーボード、マウスなどの装置がこれに含まれる。ディスク装置４０４は、この輻輳制御装置１０３で実行されるプログラム、ＩＰアドレス管理表２０１や輻輳管理表３０１のテーブル、その他の必要なデータを格納する装置であり、通常、メモリ装置４０２より大容量である。通信制御装置４０５は、輻輳制御装置１０３内部と外部通信回線１１４を介しておこなわれる外部とのデータのやり取りを制御する。内部通信回線４０６は、内部の構成要素間でデータのやり取りをおこなう。表示装置４０７は、入力情報、プログラムの実行状態、管理情報、各種データなどを表示させて確認をおこなうため装置である。

〔輻輳制御装置のデータ構造〕
次に、図３および図４を用いて本発明の輻輳制御装置で用いられるデータ構造について説明する。
図３は、ＩＰアドレス管理表２０１の一例を示す図である。
図４は、輻輳管理表３０１の一例を示す図である。

ＩＰアドレス管理表２０１は、ホスト名とそれに対応するＩＰアドレスを保持するテーブルであり、図３に示されるように、一つのホスト名２０２に複数のＩＰアドレス２０３が対応している。ここで、ＩＰアドレス管理表２０１のエントリとしては、一つのホスト名２０２に一つのＩＰアドレス２０３が対応していてもよいが、本発明においてメリットがあるのは、図３に示されるような一つのホスト名２０２に複数のＩＰアドレス２０３が対応している場合である。

再問い合わせ回数２０４は、後述の輻輳制御の処理例４でＤＮＳサーバ１０６に対して再度、問い合わせを実際におこなった回数であり、再問い合わせ規定回数２０５は、再問い合わせ回数の上限を規定する回数であり、再問い合わせの数は、この回数を超えないように制限される。

輻輳管理表３０１は、ＩＰアドレスごとに、Ｗｅｂサーバの輻輳状態を管理するためのテーブルであり、図４に示されているように、ＩＰアドレス３０２に対して当該ＩＰアドレス３０２に割り当てられたＷｅｂサーバの輻輳状態３０３が規定され、その管理情報として、輻輳と判定された回数３０４、当該ＩＰアドレス３０２宛に要求を振り分けた最新日時３０５を保持する。なお、この輻輳管理表３０１は、図１に示される輻輳制御管理部１０４で保持され、参照される。

〔輻輳制御の処理例１〕
次に、図５を用いて本実施形態の輻輳制御装置１０３の第一の処理例について説明する。
図５は、本実施形態の輻輳制御装置１０３の第一の処理例を示すフローチャートである。

なお、処理の説明中、適宜、上記の図１ないし図４を参照する。

先ず、図１に示される輻輳制御装置１０３がクライアント１０１からの要求メッセージ（以下、単に「リクエスト」ともいう）を通信処理部１１２を介して受信すると（５０１）、ＨＴＴＰ処理部１１１でリクエストの解析をおこない、 リクエストは、通常、Ｗｅｂサーバを指定するためにホスト名が含まれているが、 ＤＮＳ処理部１０５により、その宛先ホスト名のＩＰアドレスの解決をおこなうために、通信処理部１１２を介してＤＮＳサーバ１０６に問い合わせる（５０２）。

そして、通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、そのＩＰアドレスをＩＰアドレスキャッシュ部１０７にキャッシュし、当該ＩＰアドレスに対応するＷｅｂサーバ１０２が輻輳状態か否かを、輻輳制御管理部１０４で図４に示される輻輳管理表３０１のＩＰアドレス３０２と対応する輻輳状態３０３を用いて判定する（５０３）。

当該ＩＰアドレスに対応するＷｅｂサーバが輻輳状態でなかった場合には、ＨＴＴＰ処理部１１１により通信処理部１１２を介して当該ＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１にデータを送信する（５０８）。

ステップ５０３で、当該ＩＰアドレスが輻輳状態であった場合には、ＩＰアドレスキャッシュ部１０７で、図３に示されるＩＰアドレス対応表２０１を用いて、当該ＩＰアドレスのホスト名２０２に対応する異なるＩＰアドレス２０３で、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされているか否かを調べる（５０４）。当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされていない場合には、宛先のホスト名に対するＷｅｂサーバ１０２が輻輳状態として、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

一方、ステップ５０４で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされている場合には、その中の１つのＩＰアドレスを選択し（５０５）、ＨＴＴＰ処理部１１１により通信処理部１１２を介して、選択したＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１にデータを送信する（５０８）。

ステップ５０５で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものが複数キャッシュされていた場合には、例えば、図４に示された輻輳回数３０４の少ない順に、または、振り分け日時３０５の最新の順にＩＰアドレスを選択するなどのように決めておけばよい。

〔輻輳制御の処理例２〕
次に、図６を用いて本実施形態の輻輳制御装置１０３の第二の処理例について説明する。
図６は、本実施形態の輻輳制御装置１０３の第二の処理例を示すフローチャートである。

第二の処理例は、第一の処理例と全く同様の輻輳制御装置１０３の構成であって、第一の処理例のステップ５０５において、選択されたＩＰアドレスの有効性を、ＤＮＳサーバ１０６に対して逆引き問い合わせをおこなうことにより確認する形態となっている。もちろん、ＤＮＳサーバ１０６がＤＮＳ逆引き機能（ＩＰアドレスからホスト名を求める機能）を備えていることが前提となる。

このように、ＩＰアドレスの有効性をＤＮＳサーバ１０６に確認するのは、Ｗｅｂサーバ側で、構成変更によりＩＰアドレスの割り当てが変更になる場合がありうるから、そのような事態に対応するためである。

先ず、図６に示されるように、輻輳制御装置１０３がクライアント１０１からのリクエストを通信処理部１１２を介して受信すると（５０１）、ＨＴＴＰ処理部１１１でリクエストの解析を行い、ＤＮＳ処理部１０５により、リクエストの宛先ホスト名のＩＰアドレスの解決を、通信処理部１１２を介してＤＮＳサーバ１０６に問い合わせる（５０２）。

そして、通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、そのＩＰアドレスをＩＰアドレスキャッシュ部１０７にキャッシュし、当該ＩＰアドレスが輻輳状態か否かを、輻輳制御管理部１０４で図４の輻輳管理表３０１のＩＰアドレス３０２と対応する輻輳状態３０３を用いて判定する（５０３）。

当該ＩＰアドレスが輻輳状態でなかった場合には、ＨＴＴＰ処理部１１１により通信処理部１１２を介して当該ＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１にデータを送信する（５０８）。

ステップ５０３で、当該ＩＰアドレスが輻輳状態であった場合には、ＩＰアドレスキャッシュ部１０７で、図３に示されるＩＰアドレス対応表２０１を用いて、当該ＩＰアドレスのホスト名２０２に対応する異なるＩＰアドレス２０３で、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされているか否かを調べる（５０４）。当該ＩＰアドレスと異なるＩＰアドレスがキャッシュされていない場合には、宛先のホスト名に対するＷｅｂサーバ１０２が輻輳状態であるとして、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

一方、ステップ５０４で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされている場合には、その中の１つのＩＰアドレスを選択する（５０５）。

ステップ５０５で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものが複数キャッシュされていた場合には、例えば、図４に示される輻輳回数３０４の少ない順に、または、振り分け日時３０５の最新の順にＩＰアドレスを選択するなどのように決めておけばよい。

次に、ＤＮＳ処理部１０５により、ステップ５０５で選択されたＩＰアドレスの逆引き問い合わせを通信処理部１１２を介してＤＮＳサーバ１０６に対しておこない（６０１）、問い合わせが成功したか否かを判定し（６０２）、成功した場合には、ＨＴＴＰ処理部１１１により通信処理部１１２を介して、選択したＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１へデータを送信する（５０８）。

ステップ６０２において、選択されたＩＰアドレスの逆引き問い合わせが失敗した場合には、選択されたＩＰアドレスは有効でないことになる。すなわち、この場合には、Ｗｅｂサーバ側で構成変更があり、ＩＰアドレスの割り当てが変わり、このＩＰアドレスは使えなくなったことになる。この場合には、ステップ５０４へ戻ってさらに、異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされているか否かを調べる。以下同様に５０４ないし６０２のステップを繰り返すものとする。

〔輻輳制御の処理例３〕
次に、図７を用いて本実施形態の輻輳制御装置１０３の第三の処理例について説明する。
図７は、本実施形態の輻輳制御装置１０３の第三の処理例を示すフローチャートである。

第三の処理例は、第一の処理例と全く同様の輻輳制御装置の構成であって、ＤＮＳサーバ１０６が必ずしも逆引き問い合わせに対応していない場合に、第一の処理例のステップ５０５において、異なるＩＰアドレスを選択する代わりに、再度ＤＮＳサーバ１０６に対してＩＰアドレス解決をおこない、解決結果のＩＰアドレスがキャッシュされているＩＰアドレスに一致するか否かを判定することにより、異なるＩＰアドレスの有効性を確認する形態となっている。

このようにする趣旨は、第二の処理例と同様にＷｅｂサーバ側の構成変更に対応するためである。

先ず、図７に示されるように、輻輳制御装置１０３がクライアント１０１からのリクエストを通信処理部１１２を介して受信すると（５０１）、ＨＴＴＰ処理部１１１でリクエストの解析をおこない、ＤＮＳ処理部１０５により、リクエストの宛先ホスト名のＩＰアドレスの解決を、通信処理部１１２を介してＤＮＳサーバ１０６に問い合わせる（５０２）。

そして、通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、そのＩＰアドレスをＩＰアドレスキャッシュ部１０７にキャッシュし、当該ＩＰアドレスが輻輳状態か否かを、輻輳制御管理部１０４で図４に示される輻輳管理表３０１のＩＰアドレス３０２と対応する輻輳状態３０３を用いて判定する（５０３）。当該ＩＰアドレスが輻輳状態でなかった場合には、ＨＴＴＰ処理部１１１により通信処理部１１２を介して当該ＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１へデータを送信する（５０８）。

ステップ５０３で、当該ＩＰアドレスが輻輳状態であった場合、ＩＰアドレスキャッシュ部１０７で、図３に示されるＩＰアドレス対応表２０１を用いて、当該ＩＰアドレスのホスト名２０２に対応する異なるＩＰアドレス２０３で、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされているか否かを調べる（５０４）。当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされていない場合には、宛先のホスト名に対するＷｅｂサーバ１０２が輻輳状態であるとして、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

一方、ステップ５０４で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされている場合には、ＤＮＳ処理部１０５によりリクエストの宛先ホスト名のＩＰアドレスの解決を通信処理部１１２を介してＤＮＳサーバ１０６に再度問い合わせる（７０１）。通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、ＩＰアドレスキャッシュ部１０７でキャッシュし、そのＩＰアドレスが、ステップ５０２で最初に問い合わせた結果のＩＰアドレスと異なるＩＰアドレスか否かを判定し（７０２）、同一のＩＰアドレスであった場合、宛先のホスト名に対するＷｅｂサーバ１０２が輻輳状態であるとして、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

ステップ７０２で、異なるＩＰアドレスであった場合、再度問い合わせた結果のＩＰアドレスが輻輳状態でないか、すなわち通常状態か否かを輻輳制御管理部１０４で判定し（７０３）、輻輳状態の場合には、ステップ７０１へ戻ってリクエストの宛先ホスト名のＩＰアドレスの解決をＤＮＳサーバ１０６に再度問い合わせる。以下同様にステップ７０１ないし７０３の処理を繰り返すものとする。

ステップ７０３において、再度問い合わせた結果のＩＰアドレスに対応するＷｅｂサーバが輻輳状態でなかった場合、ＨＴＴＰ処理部１１１により通信処理部１１２を介して、再度問い合わせた結果のＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１へデータを送信する（５０８）。

〔輻輳制御の処理例４〕
次に、図８を用いて本実施形態の輻輳制御装置１０３の第四の処理例について説明する。
図８は、本実施形態の輻輳制御装置１０３の第四の処理例を示すフローチャートである。

第四の処理例は、第三の処理例と全く同様の構成であって、第三の処理例のステップ７０２において、ＤＮＳサーバ１０６に対して再度ＩＰアドレスの解決の問い合わせをおこなった結果、最初の問い合わせ結果と同じＩＰアドレスであった場合に、輻輳状態と判定しすぐに輻輳メッセージを送信するのではなく、一定回数まで問い合わせを繰り返す形態となっている。また、ステップ７０３において、再度問い合わせた結果のＩＰアドレスが輻輳状態であった場合に、再度問い合わせをおこなう回数を一定回数まで制限した形態となっている。

先ず、輻輳制御装置１０３がクライアント１０１からのリクエストを通信処理部１１２を介して受信すると（５０１）、ＨＴＴＰ処理部１１１でリクエストの解析を行い、ＤＮＳ処理部１０５により、リクエストの宛先ホスト名のＩＰアドレスの解決を、通信処理部１１２を介してＤＮＳサーバ１０６に問い合わせる（５０２）。通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、そのＩＰアドレスをＩＰアドレスキャッシュ部１０７でキャッシュし、当該ＩＰアドレスが輻輳状態か否かを、輻輳制御管理部１０４で図４に示される輻輳管理表３０１のＩＰアドレス３０２と対応する輻輳状態３０３を用いて判定する（５０３）。当該ＩＰアドレスが輻輳状態でなかった場合には、ＨＴＴＰ処理部１１１により通信処理部１１２を介して当該ＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１へデータを送信する（５０８）。

ステップ５０３で、当該ＩＰアドレスが輻輳状態であった場合には、ＩＰアドレスキャッシュ部１０７で、図３に示されるＩＰアドレス対応表２０１を用いて、当該ＩＰアドレスのホスト名２０２に対応する異なるＩＰアドレス２０３で、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされているか否かを調べる（５０４）。当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされていない場合には、宛先のホスト名に対するＷｅｂサーバ１０２が輻輳状態として、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信（５０９）する。

ステップ５０４で、当該ＩＰアドレスと異なるＩＰアドレスで、その異なるＩＰアドレス２０３に割り当てられたサーバが輻輳していないものがキャッシュされている場合には、ＤＮＳ処理部１０５によりリクエストの宛先ホスト名のＩＰアドレスの解決を通信処理部１１２を介してＤＮＳサーバ１０６に再度問い合わせ（７０１）、図３の宛先ホスト名に対応する再問い合わせ回数２０４を１増加させる（８０１）。通信処理部１１２を介して、解決されたＩＰアドレスを受信すると、ＩＰアドレスキャッシュ部１０７でキャッシュし、そのＩＰアドレスが、ステップ５０２で最初に問い合わせた結果のＩＰアドレスと異なるＩＰアドレスか否かを判定し（７０２）、同一のＩＰアドレスであった場合には、図３に示された再問い合わせ回数２０４が予め指定された再問い合わせ規定回数２０５に達しているか否かを調べ（８０２）、規定回数２０５に達している場合、Ｗｅｂサーバ１０２が輻輳状態であるとみなして、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

ステップ８０２で、再問い合わせ回数２０４が規定回数２０５未満であった場合、または、ステップ７０２で、異なるＩＰアドレスであった場合、再度問い合わせた結果のＩＰアドレスが輻輳状態でない、すなわち通常状態か否かを輻輳制御管理部１０４で判定し（７０３）、輻輳状態である場合には、図３に示される再問い合わせ回数２０４が規定回数２０５に達しているか否かを調べ（８０３）、規定回数２０５に達している場合には、Ｗｅｂサーバ１０２が輻輳状態として、ＨＴＴＰ処理部１１１で規制のための輻輳メッセージを作成し、通信処理部１１２を介してクライアント１０１に対して輻輳メッセージを送信する（５０９）。

ステップ８０３で、再問い合わせ回数２０４が規定回数２０５未満であった場合、ステップ７０１へ戻ってリクエストの宛先ホスト名のＩＰアドレスの解決をＤＮＳサーバ１０６に再度問い合わせる。以下同様に７０１ないし７０３のステップを繰り返すものとする。

ステップ７０３において、再度問い合わせた結果のＩＰアドレスに対応するＷｅｂサーバが輻輳状態でなかった場合、ＨＴＴＰ処理部１１１により通信処理部１１２を介して、再度問い合わせた結果のＩＰアドレスのＷｅｂサーバ１０２宛にリクエストを送信し（５０６）、Ｗｅｂサーバ１０２からのデータ受信（５０７）後、クライアント１０１にデータを送信する（５０８）。

本実施形態の輻輳制御装置を用いたネットワーク構成を示すブロック図である。 本実施形態に係る輻輳制御装置のハードウェア構成を示すブロック図である。 ＩＰアドレス管理表２０１の一例を示す図である。 輻輳管理表３０１の一例を示す図である。 本実施形態の輻輳制御装置１０３の第一の処理例を示すフローチャートである。 本実施形態の輻輳制御装置１０３の第二の処理例を示すフローチャートである。 本実施形態の輻輳制御装置１０３の第三の処理例を示すフローチャートである。 本実施形態の輻輳制御装置１０３の第四の処理例を示すフローチャートである。

符号の説明

１０１…クライアント
１０２…Ｗｅｂサーバ
１０３…輻輳制御装置
１０４…輻輳制御管理部
１０５…ＤＮＳ処理部
１０６…ＤＮＳサーバ
１０７…ＩＰアドレスキャッシュ部
１０８…Ｗｅｂサーバ１
１０９…Ｗｅｂサーバ２
１１０…Ｗｅｂサーバｎ
１１１…ＨＴＴＰ処理部
１１２…通信処理部
１１３…内部通信路
１１４…外部通信回線
２０１…ＩＰアドレス対応表
２０２…ホスト名
２０３…ＩＰアドレス
２０４…再問い合わせ回数
２０５…再問い合わせ規定回数
３０１…輻輳状態管理表
３０２…ＩＰアドレス
３０３…輻輳状態
３０４…輻輳回数
３０５…振り分け日時
４０１…プロセッサ
４０２…メモリ装置
４０３…入力装置
４０４…ディスク装置
４０５…通信制御装置
４０６…内部通信回線
４０７…表示装置
５０１…クライアントからの要求を受信
５０２…宛先のＷｅｂサーバのホスト名のＩＰアドレスをＤＮＳサーバに問い合わせ
５０３…解決されたＩＰアドレスが輻輳状態か否か判定
５０４…ＩＰアドレス対応表に輻輳状態でない異なるＩＰアドレスがあるか否かの判定
５０５…ＩＰアドレス対応表の輻輳状態でない異なるＩＰアドレスから一つを選択
５０６…選択したあるいは解決されたＩＰアドレス宛にリクエストを送信
５０７…Ｗｅｂサーバからデータを受信
５０８…クライアントへデータを送信
５０９…クライアントへ輻輳メッセージを送信
６０１…ＤＮＳサーバに対して選択したＩＰアドレスの逆引き問い合わせ
６０２…逆引き問い合わせしたＩＰアドレスが有効か否か判定
７０１…宛先のＷｅｂサーバのホスト名のＩＰアドレスをＤＮＳサーバに再度問い合わせ
７０２…最初に解決されたＩＰアドレスと異なるＩＰアドレスか否かの判定
７０３…再度解決されたＩＰアドレスが通常（輻輳でない）状態か否かの判定
８０１…ＤＮＳサーバに２回目以降問い合わせた回数をカウントアップ
８０２…ＤＮＳサーバに再度問い合わせた回数が規定回数未満か否か判定
８０３…ＤＮＳサーバに再度問い合わせた回数が規定回数未満か否か判定

Claims (8)

1. ネットワークを介してクライアントからサーバに送信される要求メッセージを受信し、前記サーバが輻輳状態のときには前記要求メッセージを前記サーバに転送せずに前記クライアントに輻輳メッセージを返信する輻輳制御装置において、
   前記要求メッセージに含まれるホスト名から前記サーバのＩＰアドレスを取得する手段と、
   前記サーバのホスト名とＩＰアドレスの対応関係の情報を保持する手段とを備え、
   前記要求メッセージに含まれるホスト名から前記サーバのＩＰアドレスを取得して、前記サーバのホスト名とＩＰアドレスの対応関係の情報より、そのＩＰアドレスに対応したサーバを求め、そのサーバが輻輳状態であるか否かを判定し、輻輳状態であるときには、輻輳状態であると判定されたサーバのホスト名に対応する別のＩＰアドレスが存在し、かつ、その別のＩＰアドレスが割り当てられたサーバが輻輳状態でないときに、その別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信することを特徴とする輻輳制御装置。
2. 前記ネットワーク上にＤＮＳ（Domain Name System）逆引き機能を有するＤＮＳサーバを有し、
   輻輳状態であると判定されたサーバのホスト名に対応する別のＩＰアドレスが存在し、かつ、その別のＩＰアドレスが割り当てられたサーバが輻輳状態でないときに、前記ＤＮＳサーバのＤＮＳ逆引き機能により、その別のＩＰアドレスの有効性を確認し、有効であると判定したときに、その別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信することを特徴とする請求項１記載の輻輳制御装置。
3. 前記ネットワーク上にＤＮＳサーバを有し、
   輻輳状態であると判定されたサーバのホスト名に対応する別のＩＰアドレスが存在し、かつ、その別のＩＰアドレスが割り当てられたサーバが輻輳状態でないときに、
   前記ＤＮＳサーバに対して、前記サーバのホスト名によるＩＰアドレスの問い合わせをおこなうことにより、前記別のＩＰアドレスの有効性を確認し、有効であると判定したときに、その別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信することを特徴とする請求項１記載の輻輳制御装置。
4. ＩＰパケットを送受信するネットワークにより、クライアントからＷｅｂサーバに送信される要求メッセージを、ＤＮＳサーバにより宛先のＷｅｂサーバを求めて、そのＷｅｂサーバに送信し、前記Ｗｅｂサーバが輻輳状態のときには前記要求メッセージを前記Ｗｅｂサーバに送信せずに前記クライアントに輻輳メッセージを返信する輻輳制御装置において、
   ネットワーク上のパケットの送受信を処理するための通信処理部と、
   前記Ｗｅｂサーバとのプロトコルを制御するＨＴＴＰ処理部と、
   前記ＤＮＳサーバとのプロトコルを制御するＤＮＳ処理部と、
   ホスト名とＩＰアドレスの対応情報を保持するＩＰアドレスキャッシュ部と、
   前記ＩＰアドレスごとに割り当てられたＷｅｂサーバの輻輳状態を保持する輻輳制御管理部とを有し、
   前記ＤＮＳ処理部は、前記ＤＮＳサーバに問い合わせて、前記要求メッセージに含まれるホスト名より対応するＩＰアドレスを求め、
   前記ＩＰアドレスキャッシュ部は、ホスト名とＩＰアドレスの対応を記録し、
   前記ＨＴＴＰ処理部は、前記輻輳制御管理部の保持する輻輳状態と前記ＩＰアドレスキャッシュ部の保持するホスト名とＩＰアドレスの対応情報とに従って、
   前記要求メッセージが送られるＩＰアドレスに割り当てられたＷｅｂサーバが輻輳状態のときには、輻輳状態であると判定されたＷｅｂサーバのホスト名に対応する別のＩＰアドレスを求め、その別のＩＰアドレスが割り当てられたＷｅｂサーバが、輻輳状態でないときに、その別のＩＰアドレスが割り当てられたＷｅｂサーバに対して、前記クライアントの要求メッセージを送信し、
   前記要求メッセージが送られるＩＰアドレスに割り当てられたＷｅｂサーバが輻輳状態でないときには、前記Ｗｅｂサーバに前記要求メッセージを送信することを特徴とする輻輳制御装置。
5. ネットワークを介してクライアントからサーバに送信される要求メッセージを受信し、前記サーバが輻輳状態のときには前記要求メッセージを前記サーバに転送せずに前記クライアントに輻輳メッセージを返信するネットワークの輻輳制御方法において、
   前記要求メッセージに含まれる情報から前記サーバのＩＰアドレスを取得する手順と、
   前記サーバのホスト名とＩＰアドレスの対応関係の情報を記録する手順と、
   前記要求メッセージに含まれる情報から前記サーバのＩＰアドレスを取得して、前記サーバのホスト名とＩＰアドレスの対応関係の情報より、そのＩＰアドレスに対応したサーバを求める手順と、
   そのサーバが輻輳状態であるか否かを判定し、輻輳状態であるときには、輻輳状態であると判定されたサーバのホスト名に対応する別のＩＰアドレスで、かつ、その別のＩＰアドレスが割り当てられたサーバが輻輳状態でないものを検索する手順と、
   検索されたその別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信する手順と、
   輻輳状態でないときには、そのＩＰアドレスに対応したホスト名を持つサーバにその要求メッセージを送信する手順とを有することを特徴とするネットワークの輻輳制御方法。
6. 前記ネットワーク上にＤＮＳ逆引き機能を有するＤＮＳサーバを有し、
   さらに、前記ＤＮＳサーバのＤＮＳ逆引き機能により、前記別のＩＰアドレスの有効性を確認する手順を有し、
   有効であると判定されたその別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信することを特徴とする請求項５記載のネットワークの輻輳制御方法。
7. 前記ネットワーク上にＤＮＳサーバを有し、
   さらに、前記ＤＮＳサーバに対して、前記サーバのホスト名によるＩＰアドレスの問い合わせをおこなうことにより、前記別のＩＰアドレスの有効性を確認する手順を有し、有効であると判定されたその別のＩＰアドレスが割り当てられたサーバに対して、前記クライアントの要求メッセージを送信することを特徴とする請求項５記載のネットワークの輻輳制御方法。
8. ＩＰアドレスごとに輻輳状態と、前記ＤＮＳサーバへの問い合わせ回数の上限数を保持し、その問い合わせ回数の上限数を超えない範囲で、前記ＤＮＳサーバへの問い合わせをおこなうことを特徴とする請求項７記載のネットワークの輻輳制御方法。
   

Images