JP4099108B2 - ネットワーク及びサーバの負荷低減ルータ - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はネットワーク及びサーバの負荷低減ルータに関し、更に詳しくは、インターネット、イントラネット上に設置されたクライアントサーバ型サービスの利用に際し、サーバの輻輳によりサーバへのアクセスが遅延するような状況において、ユーザがサーバへの不用意なアクセスリトライを行なうことによるネットワークの輻輳を避けると共に、サーバの負荷を軽減し、サーバ輻輳状態を早期に復旧させるルータに関する。
【０００２】
【従来の技術】
ルータ（ｒｏｕｔｅｒ）とは、ネットワークパケットをネットワーク層でルーティングする装置のことである。データリンク層では隣接ノード間若しくは同一セグメント上でしかデータの伝達ができないが、ルータはデータリンク層でのデータ転送機能を組み合わせて、ネットワーク上のあらゆるノード間同士でのデータ転送を担当する。ルータは、通常、ルーティングできるプロトコルが固定的に決まっている。図２８はルータの概念図である。図において、ＮＷ１〜ＮＷ３はネットワーク、Ｃ１〜Ｃ３は各ネットワーク間を接続する回線、Ｒ１〜Ｒ３は各回線Ｃ１〜Ｃ３に接続されるルータである。ルータＲ１〜Ｒ３と回線Ｃ１〜Ｃ３の間には回線インタフェースＩＮＴが設けられている。ルータＲ１〜Ｒ３は、ネットワークを結ぶため、複数の回線インタフェースＩＮＴを持っており、回線インタフェースＩＮＴから受信したパケットを宛先に応じて、適切な回線Ｃ１〜Ｃ３へ出力する。
【０００３】
図２９は、従来のルータの概念を示す図である。このルータは、クライアントとサーバの間に配置され、クライアントとサーバ相互間のデータの送受信を制御する機能を持つ。図において、１はＬＡＮフレームを受信するＬＡＮフレーム受信部、２は該ＬＡＮフレーム受信部１の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部、３は該トラフィックエンジニアリング制御部２の出力を受けてルーティング処理を行なうルーティング処理部、４は該ルーティング処理部３の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部である。
【０００４】
図３０はＬＡＮフレーム受信部、ＬＡＮフレーム送信部、ルーティング処理部の説明図である。図２８，図２９と同一のものは、同一の符号を付して示す。回線インタフェースＩＮＴからのパケットをＬＡＮフレーム受信部１で受信する。この受信したパケットはルーティング処理部３に入る。該ルーティング処理部３は、ルータ間の制御メッセージのやりとりにてルーティング情報を交換しあい、「どの回線の先にどのような経路があるか」というルーティング情報を持っている。５はルーティング情報を記憶するルーティング情報データベースである。ＬＡＮフレーム受信部１で受信したパケットは、ルーティング処理部３で宛先に応じた出側回線インタフェースＩＮＴを決定し、出側回線のＬＡＮフレーム送信部４へパケットを送信する。
【０００５】
図３１はトラフィックエンジニアリング制御部の説明図である。図２８，図２９と同一のものは、同一の符号を付して示す。通常のルータでは、ルーティング情報に従ってパケットを転送する。トラフィックエンジニアリング機能を備えたルータでは、例えばパケットの宛先アドレスに対する出力インタフェースが複数あるような場合、次のような制御を実施する。
・帯域を均等分散させるために、パケット毎に出力インタフェースを振り分ける。
・複数ある出力インタフェース候補の中から、特定のインタフェースのみに出力する。
・出力するインタフェースの帯域を制御し、各インタフェースを指定した分の帯域だけ使用するように出力インタフェースの振り分けを制御する。トラフィックエンジニアリング制御部２の上記のような動作は、コマンド入力により設定される。以降、ルータがパケットを受信すると、ルーティング処理部で経路を検索し、トラフィックエンジニアリング制御部２と連携して出力インタフェースを決定し、パケットを回線に出力する。
【０００６】
現在のＷＷＷやＦＴＰ等のクライアントサーバ型のネットワークシステムにおいて、特定のサーバへの要求が集中することにより、当該サーバの処理輻輳が発生してサーバからクライアントへの応答が遅延した場合、クライアント側が処理を中断してサーバへのアクセスリトライを行なうことで、更にサーバへの要求が増え、ネットワークシステム内のトラフィックが増大すると共に、サーバ負荷も上昇し、サーバのさらなる処理輻輳が発生してしまうという問題がある。
【０００７】
サーバの処理輻輳を解消するため、サーバを複数設置してサーバの負荷を分散することにより、サーバの処理能力を向上させ、サーバ側の輻輳を解消する手法が広く用いられている。しかしながら、このサーバ追加による解決方法は、サーバ設置者へのコスト負担が増加する。更に、現実のネットワークにおいては、既に複数のサーバが存在しており、それぞれのサーバの処理輻輳を解消するには、各サーバ毎に追加用サーバを個々に導入する必要があるため、ネットワーク全体では追加するサーバ数が更に増加し、サーバ追加に対するコストが増大する。
【０００８】
また、例えばチケット抽選システムやネットワークを利用したマルチユーザゲームアプリケーション等、サーバの用途によってはデータの一貫性保持のために分散処理が困難なものも存在し、サーバの台数を増やして負荷分散する方法をとることができない分野もある。
【０００９】
利用途中における切断の発生を防止して、ユーザのサービスの向上を図る技術がある（例えば特許文献１参照）。また、トラフィックの輻輳を検出して過大なトラフィックが流れないようにする制御する技術がある（例えば特許文献２参照）。また、サーバ／クライアントシステムにおいて、サーバが輻輳時にクライアントの要求を抑止する技術がある（例えば特許文献３参照）。更に、サーバ／クライアントシステムにおいて、受け付け／アクセス制御／サービスとサーバの機能分割を実施し、クライアントの要求を抑止する技術がある（例えば特許文献４参照）。
【００１０】
【特許文献１】
特開２００１−３２０４２３号公報（第４頁、第５頁、図１）
【特許文献２】
特開２００１−３４５８６１号公報（第３頁、第４頁、図１）
【特許文献３】
特開２００１−６７３１４号公報（第４頁、第５頁、図１）
【特許文献４】
特開２００２−１４１９３６号公報（第５、第６頁、図１）
【００１１】
【発明が解決しようとする課題】
特許文献１に記載の発明は、サービス構成要素に「開始」、「継続」、「終了」の識別子を与え、輻輳中は「開始」要求をリジェクトすることにより、利用中ユーザのサービス向上を行なう。しかしながら、本方式はサービス構成要素に識別を与える必要があるため、コンテンツに対しての加工が必要であり、既に運用中のサービスにそのまま本方式を適用することができないという問題がある。
【００１２】
特許文献２に記載の発明は、ネットワークの輻輳時にパケットのキュー長をダイナミックに変更し、ネットワークの負荷を下げる。また、プロキシサーバの機能も具備し、特定のＷＷＷサーバへのアクセスを禁止することができる。しかしながら、サーバの輻輳を検出することで、当該サーバへのアクセスを制御する機能は具備していない。
【００１３】
特許文献３に記載の発明は、サーバがクライアント（ユーザ端末）に対して、リトライ抑止を制御する。しかしながら、サーバが輻輳中で非常に処理負荷が高い状況において個々のクライアントに対して要求を抑止する制御を実施すると、サーバ自体の負荷が更に上昇し、ネットワークの負荷に対して輻輳を解除するまでの時間が非常に長くなってしまう。また、サーバ／クライアントのアプリケーションがこの方式に対応している必要がある。
【００１４】
特許文献４に記載の発明は、サービス提供サーバと受け付けサーバ、アクセス制御サーバで役割を分担し、アクセス制御サーバがルータに対してフィルタリング設定を実施する。しかしながら、この方法ではサーバ側に機能を盛り込む必要があり、ネットワークに接続された不特定多数のサーバに対して輻輳を回避することは困難である。また、アクセス制御サーバがクライアントを収容するルータを認識することと、ルータでフィルタ関連の処理を実施するためのコマンド等をサーバが把握しておく必要があり、管理が煩雑となる。
【００１５】
以上、説明したように、輻輳しているサーバに対してユーザがアクセスリトライを繰り返すことでさらなるサーバ輻輳が発生している状態において、従来技術では、クライアント／サーバのアプリケーションに特別な機能を持たない限り、サーバへのリトライを抑止してサーバ負荷を減少することはできず、ネットワークに不要なトラフィックが流入していた。
【００１６】
本発明はこのような課題に鑑みてなされたものであって、ルータに収容される全てのサーバに対して、サーバ側に特殊な機能を盛り込むことなく、自動的にサーバの輻輳を検出することができ、クライアントを収容するルータと連携することで、サーバ及びネットワーク全体の輻輳回避が容易に実現できるネットワーク及びサーバの負荷低減ルータを提供することを目的としている。
【００１７】
【課題を解決するための手段】
本発明では、ネットワークトラフィック自体を動的に制御できるルータにて、クライアントの流入トラフィックを制御することにより、既存のサーバ／クライアント自体には輻輳制御用に特に処理を必要としない方式であり、既存のサーバ／クライアントのままで当該サーバに対するユーザ要求自体をネットワーク内へ流入するのを制御でき、ネットワーク負荷を下げると共に、輻輳中のサーバの処理効率向上を可能とする。
【００１８】
また、ルータにて制御するため、ネットワークを含めたシステム全体の追加投入コストやシステム構築の変更等が非常に少なくて済むというメリットがある。これは、通常のサーバでＩＰパケットの監視を実施するにはネットワークの転送速度を悪化させないよう、サーバに対してネットワーク処理を高速に実現するためのハードウェアを追加する必要があるが、本来、ネットワークの転送速度を悪化させることなくＩＰパケットの内容を高速に検査しているルータにおいて本制御を実現するには更に特殊なハードウェアを追加する必要がなく、ルータのＩＰパケット転送処理部への処理追加のみで実現できるためである。
【００１９】
また、クライアント／サーバ間での制御では、そのソフトウェアが適用されたクライアント／サーバ自体の輻輳回避しかできないが、当機能を具備したルータを導入することにより、クライアント毎の優先度に従ってトラフィックエンジニアリング（Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ）制御を行なうことで、ネットワーク全体としての輻輳回避も可能となる。図１は本発明の原理ブロック図である。図２９と同一のものは、同一の符号を付して示す。図において、１はＬＡＮフレームを受信するＬＡＮフレーム受信部、２は該ＬＡＮフレーム受信部１の出力を受けて帯域制御や迂回回路を設定するトラフィックエンジニアリング制御部、３は該トラフィックエンジニアリング制御部２の出力を受けてルーチング処理を行なうルーティング処理部、４は該ルーティング処理部３の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部である。
【００２０】
１０はＬＡＮフレーム受信部１、トラフィックエンジニアリング制御部２、ＬＡＮフレーム送信部４と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段である。
【００２１】
このように構成すれば、サーバの輻輳を検出したサーバ輻輳手段１０は、サーバの輻輳制御を行なって、サーバの輻輳を低減することができる。
（１）請求項１記載の発明は、サーバとクライアントが設置されるネットワークシステム上のルータであって、ＬＡＮフレームを受信するＬＡＮフレーム受信部と、該ＬＡＮフレーム受信部の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部と、該トラフィックエンジニアリング制御部の出力を受けてルーティング処理を行なうルーティング処理部と、該ルーティング処理部の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部とを具備するものにおいて、前記各構成要素と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段を設け、サーバ宛のパケットの応答遅延を監視してサーバの輻輳を自動的に検出するサーバ輻輳監視手段と、サーバの輻輳／輻輳解除検出時に輻輳原因となっているパケットの廃棄／中継を、クライアントを収容するルータに対して要求する輻輳原因パケット廃棄要求手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする
【００２２】
このように構成すれば、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避することができる。
（２）請求項２記載の発明は、サーバを収容しているルータで、輻輳しているサーバのサービスを特定する輻輳サービス特定手段と、クライアントを収容しているルータで、輻輳しているサーバのサービスに関するパケットのみを廃棄する輻輳原因パケット廃棄手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２３】
このように構成すれば、輻輳原因となっているパケットを、宛先サーバのアドレスやプロトコルで識別するだけでなく、ＷｅｂページのＵＲＬやＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰで用いられるファイル転送プロトコル）のディレクトリ等の輻輳しているサービスに関するパケットのみの廃棄を可能とすることができる。
（３）請求項３記載の発明は、クライアント−サーバ間のパケットを監視し、サーバ−クライアント間のパケット通信量や最終通信時刻等の統計情報を記録する通信統計記録手段と、サーバ輻輳時に、クライアントを収容するルータに対してパケット廃棄を要求する時に、新たに通信を開始するクライアントや通信量が規定量を超えているクライアントのパケット通信を制限するクライアントを決定する通信制御クライアント決定手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２４】
このように構成すれば、特定のクライアントのみの通信を規制することを可能とし、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することができる。
（４）請求項４記載の発明は、サーバの輻輳検出時に、輻輳原因となるパケットを廃棄すると同時に、クライアントに対してサーバ輻輳を通知するサーバ輻輳通知手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２５】
このように構成すれば、ユーザが通信タイムアウトを持たずサーバ輻輳及び輻輳に関する情報を認識することを可能とし、ユーザの利便性を向上させることができる。
【００２６】
この発明において、サーバ輻輳の履歴を管理するサーバ輻輳履歴管理手段を前記サーバ輻輳制御手段内に設け、前記サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することを特徴とする。
【００２７】
このように構成すれば、サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することで、サーバ側に特殊な機能を必要とせずにユーザの利便性を向上させることができる。
【００２８】
また、この発明において、優先／非優先にすべきクライアントの持つクラスを事前に設定し、そのクラスに応じたパケットに対する挙動を決定する通信優先度決定手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２９】
このように構成すれば、トラフィックエンジニアリング制御（帯域制御や適切な迂回経路やウェイトによる適切な破棄を実施すること）を用いた優先接続等の制御を可能とする。
【００３０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。図２は本発明の一実施の形態例のネットワーク構成を示す図である。図１と同一のものは、同一の符号を付して示す。図において、１１はＬＡＮフレーム受信部１及びＬＡＮフレーム送信部４と接続されるサーバ輻輳監視手段、１２はＬＡＮフレーム送信部４及びサーバ輻輳監視手段１１と接続される輻輳原因パケット廃棄要求手段、１３はＬＡＮフレーム受信部１と接続される輻輳原因パケット廃棄手段である。
【００３１】
１４はＬＡＮフレーム受信部１と接続される通信統計統計記録手段、１５は輻輳原因パケット廃棄手段１３及び通信統計記録手段１４及び輻輳原因パケット廃棄要求手段１２と接続される通信規制クライアント決定手段、１６は輻輳原因パケット廃棄手段１３、ＬＡＮフレーム送信部４及び輻輳原因パケット廃棄要求手段１２と接続されるサーバ輻輳通知手段、１７はサーバ輻輳監視手段１１と接続されるサーバ輻輳履歴管理手段、１８はサーバ輻輳監視手段１１と接続される輻輳サービス特定手段、１９はトラフィックエンジニアリング制御部２、輻輳原因パケット廃棄手段１３及び通信規制クライアント決定手段１５と接続される通信優先度決定手段である。以下、これらの構成要素について詳しく説明する。
（サーバ輻輳監視手段１１）
当該ルータに接続されているサーバについて、クライアントからの要求に対するサーバからの応答の遅延時間を監視し、サーバの輻輳状態を検出するものである。
（輻輳原因パケット廃棄要求手段１２）
サーバ輻輳検出時に、クライアントを収容しているルータに対して、輻輳原因となっているパケットの廃棄を要求する。本機能は、クライアントを収容しているルータのフィルタ機能を利用して、コマンドラインインタフェース等を使用して、輻輳しているサーバのＩＰアドレスやＴＣＰポート番号等によるフィルタの登録／削除を行なうことで実現可能である。
【００３２】
また、クライアントを収容しているルータに輻輳原因パケット廃棄手段１３を持つことで、例えば輻輳しているサーバの特定ＵＲＬ宛パケットのみを廃棄する等、きめ細かな指定も可能である。
【００３３】
また、クライアントを収容しているルータの特定方法として、ルータが本来の中継機能のために持っているＯＳＰＦ／ＢＧＰ等の経路情報を利用することで、クライアントを収容するルータを自動的に認識することも可能である。ここで、ＯＳＰＦとはＯｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔの略であり、ＢＧＰとはＢｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌの略であり、双方共にインターネットの経路制御プロトコルである。
（輻輳原因パケット廃棄手段１３）
サーバを収容するルータの輻輳原因パケット廃棄要求手段１２からの要求を受けて、指定されたパケットの廃棄／中継を制御する。
（通信統計記録手段１４）
クライアント−サーバ間の通信を監視し、サーバからクライアント宛のパケット通信量やクライアントからサーバ宛の最終通信時刻等の統計情報を記録する。
（通信規制クライアント決定手段１５）
サーバ輻輳時に、通信統計記録手段１４で収集された情報を参照し、サーバ輻輳及びネットワーク輻輳を回避するために通信を規制するクライアントを決定する。最終通信時刻が閾値よりも古いクライアントを規制対象とすることで、通信を継続しているクライアントを規制対象から外すことが可能である。
【００３４】
また、サーバからクライアント宛の通信量が閾値よりも大きいクライアントのみを規制対象とすることで、大量の画像や音楽データ等を長時間ダウンロードし続ける等、サーバやネットワーク負荷の原因となっているクライアントのみに限定して規制をかけることも可能である。
（サーバ輻輳通知手段１６）
サーバ輻輳時に、パケットを廃棄するだけでなく、クライアントに対してサーバ輻輳を通知する。通知方法としては、各プロトコルに従った相手ビジーに相当するエラー通知パケットをサーバの代わりにクライアントに送信する方法がある。また、例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ＷＷＷで用いるプロトコル）であれば、サーバの輻輳度合いを表示するＷｅｂページのＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇａｇｅ：Ｗｅｂページで使用される言語体系）イメージをクライアントに送信することも可能である。
【００３５】
更に、サーバ輻輳履歴管理手段１７のサーバ輻輳履歴をクライアントに送信することで、どのくらいの時間をおいてサーバにアクセスすれば輻輳状態が回避されている可能性が高いか等をユーザが判断することが可能となる。
（サーバ輻輳履歴管理手段１７）
サーバ輻輳監視手段１１が監視しているサーバの輻輳情報を履歴管理する。
（輻輳サービス特定手段１８）
サーバ輻輳監視手段１１の一部として、ＨＴＴＰのＵＲＬや、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ファイル転送プロトコル）のディレクトリ等の単位でサーバの応答遅延時間を監視することで、サーバ単位ではなくサーバの部位単位で輻輳を監視し、輻輳検出時は、輻輳原因パケット廃棄要求手段１２に対して、輻輳部位の識別情報を渡し、クライアントを収容するルータの輻輳原因パケット廃棄手段１３に通知する。
（通信優先度決定手段１９）
クライアントを収容しているルータに対して事前にクライアントの優先度を設定しておくことで、輻輳原因パケット廃棄手段１３でそのクライアントが廃棄対象となった場合でも、単なる廃棄ではなく帯域制御やベストエフォート（Ｂｅｓｔ Ｅｆｆｏｒｔ）な経路への迂回等のトラフィックエンジニアリングサービスを決定し、トラフィックエンジニアリング制御部２へ処理要求を行ないネットワーク全体の輻輳を回避する。
（ａ）第１の実施の形態例（請求項２に対応）の動作概要
サーバを収容するルータ（出側ルータ）のサーバ輻輳監視手段１１は、サーバ宛のパケットに対するサーバからの応答の遅延時間を常時監視し、遅延時間が予め決められた輻輳閾値を超えた場合にサーバ輻輳と見なす。輻輳原因パケット廃棄要求手段１２は、サーバ輻輳時に、クライアントを収容しているルータ（入側ルータ）を特定し、当該ルータに対して輻輳を検出したサーバのＩＰアドレス及びＴＣＰのポート番号等を指定してフィルタの設定要求を行なう。
【００３６】
サーバ輻輳を検出したサーバ輻輳監視手段１１は、当該サーバの監視を継続し、応答遅延時間が輻輳解除閾値を切った時点で、サーバ輻輳解除と見なす。輻輳原因パケット廃棄要求手段１２は、サーバ輻輳解除時に、輻輳時に入側ルータに設定したフィルタを解除する。
【００３７】
これにより、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避若しくは低減することが可能となる。
（ｂ）第２の実施の形態例（請求項３に対応）の動作概要
出側ルータの輻輳サービス特定手段１８は、サーバ輻輳監視手段１１の一部として、ＷｅｂページのＵＲＬやＦＴＰのディレクトリ等の単位で、サーバの応答遅延時間を監視し、サーバ輻輳時は、輻輳原因パケット廃棄要求手段１２により、輻輳サービスの識別情報と共にサーバの輻輳を入側ルータの輻輳原因パケット廃棄手段１３に通知する。
【００３８】
入側ルータの輻輳原因パケット廃棄手段１３は、宛先ＩＰアドレス、ＴＣＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ポート番号、輻輳しているＵＲＬ等のフィルタの条件で、輻輳原因となっているパケットの廃棄を行なう。
【００３９】
これにより、通常のルータではサポートされていないような特殊なフィルタリング条件を使用して、パケット廃棄を行なうことが可能となり、例えば同一サーバで実現されている特定のＵＲＬのサービスのみが輻輳している場合に、当該ＵＲＬ宛のパケットのみを廃棄する等、きめ細かな輻輳制御を行ない、サーバの輻輳を効率よく回避することが可能となる。
（ｃ）第３の実施の形態例（請求項４に対応）の動作概要
入側ルータ又は出側ルータにおいて、通信統計記録手段１４は、クライアント−サーバ間の通信を監視し、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号等で特定されるサーバ輻輳の監視単位に、パケット通信量や最終通信時刻等の統計情報を記録する。
【００４０】
サーバ輻輳時、出側ルータの輻輳原因パケット廃棄要求手段１２又は入側ルータの輻輳原因パケット廃棄手段１３が、通信規制クライアント決定手段１５に問い合わせて、通信を規制するクライアントを決定し、決定したクライアントに対してのみパケット廃棄を行なう。
【００４１】
通信規制クライアント決定手段１５は、クライアント決定時に、通信統計記録手段１４に問い合わせて最終通信時刻を参照し、最終通信時刻と輻輳時の時刻との差分が、予め決められた閾値時間以上のものや、パケット通信量が規定量を超えているものを通信規制の対象と決定する。
【００４２】
これにより、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することが可能となる。
（ｄ）第４の実施の形態例（請求項５に対応）の動作概要
サーバ輻輳時に、出側ルータの輻輳原因パケット廃棄要求手段１２又は入側ルータの輻輳原因パケット廃棄手段１３は、サーバ輻輳通知手段１６にサーバ輻輳通知を要求する。
【００４３】
サーバ輻輳通知手段１６は、サーバに成り代わり、各プロトコルに従ったエラー通知パケット又はＨＴＴＰのＷｅｂページのＨＴＭＬイメージ等をクライアントに送信することで、クライアントにサーバ輻輳及び輻輳に関する情報を通知する。
【００４４】
これにより、ユーザが通信タイムアウトを待たずサーバ輻輳及び、どのくらいの時間にサーバにアクセスすれば輻輳が解除されているか等の輻輳に関する情報を認識することができ、ユーザの利便性を向上させることが可能となる。
（ｅ）第５の実施の形態例
出側ルータのサーバ輻輳履歴管理手段１７は、サーバ輻輳監視手段１１により認識したサーバの輻輳具合を履歴管理する。本情報は、ルータの運用コマンド等を使用してネットワーク管理者が読み出すことが可能であり、また、前記サーバ輻輳通知手段１６により、サーバ輻輳時にクライアントに通知することで、サーバ利用者が参照することも可能である。
【００４５】
これにより、サーバの集中管理が可能となり、また、サーバ側に特別な機能を必要とせずに、サーバの輻輳履歴をユーザが認識することが可能となる。
（ｆ）第６の実施の形態例
入側ルータの通信優先度決定手段１９は、サーバを収容するルータの輻輳原因パケット廃棄要求手段１２からの要求を受けて輻輳原因パケット廃棄手段１３によって決定した廃棄対象のクライアントのうち、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号等で事前に設定された優先度条件に合致するクライアントがあるか検索を行なう。
【００４６】
優先度条件に合致するクライアントに対しては、トラフィックエンジニアリングを利用して使用帯域の制限や、ベストエフォート経路への迂回等を実施することにより、サーバ輻輳の回避と共に、ネットワーク内の負荷についても輻輳を回避することが可能となる。
【００４７】
以下に、本発明を利用し、クライアントサーバ型のアプリケーションとして広く用いられているＷｅｂサーバの輻輳を検出し、Ｗｅｂサーバの輻輳及びネットワークの輻輳を低減する例を説明する。
【００４８】
図３は本発明の第１の実施の形態例のネットワーク構成を示す図である。クライアントＣ１はルータＲ１に接続され、クライアントＣ２はルータＲ２に接続され、サーバＳ１とサーバＳ２はルータＲ３に接続されている。ルータＲ１とルータＲ３の間、及びルータＲ２とルータＲ３の間には更に複数のルータを経由していてもよい。このネットワーク構成における第１の実施の形態例について、図４を用いて説明する。
【００４９】
図４は本発明の第１の実施の形態例の動作を示すシーケンス図である。図３と同一のものは、同一の符号を付して示す。Ｃ１,Ｃ２はクライアント、Ｒ１,Ｒ２,Ｒ３はルータ、Ｓ１,Ｓ２はサーバである。図３のルータＲ１とＲ２は、図２のサーバ輻輳監視手段１１、輻輳原因パケット廃棄手段１３を具備し、ルータＲ３は図２のサーバ輻輳監視手段１１、輻輳原因パケット廃棄要求手段１２及び輻輳原因パケット廃棄手段１３を具備する。
（輻輳の検出方法）
クライアントＣ１がサーバＳ１へアクセスする状況において、クライアントＣ１からサーバＳ１へのパケットを中継し、サーバＳ１と接続するルータＲ３はＬＡＮフレーム受信部１で要求メッセージ１０１のＩＰパケットを受信し、サーバ輻輳監視手段１１へ受信したＩＰパケットの内容を通知する。更に、ルータＲ３では、サーバＳ１からクライアントＣ１に対する応答メッセージ１０１についてもＬＡＮフレーム受信部１で受信し、サーバ輻輳監視手段１１へＩＰパケットの内容を通知する。
【００５０】
サーバ輻輳監視手段１１は、ＩＰパケットがＨＴＴＰであるかどうかを判別する。プロトコルの判別は、ＩＰパケット内のポート番号（ＨＴＴＰであればＴＣＰの８０番、ＦＴＰであればＴＣＰの２１番）を参照することで可能である。サーバ輻輳監視手段１１は、更にＨＴＴＰのＩＰパケットがＨＴＴＰの要求メッセージか応答メッセージであるかを判別し、要求メッセージ１０１と応答メッセージ１０１のレスポンス時間を測定する。
【００５１】
ＨＴＴＰはテキスト形式でプロトコルメッセージのやりとりをするため、ＨＴＴＰのパケットの内容を参照すれば、要求メッセージと応答メッセージを判別することができる。本発明の対象となるようなキャリア網で使用されるルータでは、ネットワークプロセッサ（Ｎｅｔｗｏｒｋ Ｐｒｏｃｅｓｓｏｒ：ネットワーク処理に特化し、パケット転送動作をプログラム可能なプロセッサ。通常、ＩＰパケットの転送処理をＧｉｇａｂｉｔ Ｅｔｈｅｒ等のワイヤスピードにて実施可能である）にてＩＰパケットの転送をハードウェア的に行なう方法がほとんどであり、この場合、ネットワークプロセッサ部のプログラムを追加することでＩＰパケットの転送能力を悪化させることなく実現することができる。ＩＰパケットの転送をＡＳＩＣ（特定用途向けＩＣ）でハードウェア的に実現しているルータであれば、ＡＳＩＣへのロジックを追加することで実現することができる。
【００５２】
サーバ輻輳監視手段１１は、クライアントのＩＰアドレスとサーバのＩＰアドレスの組み合わせに対応するＨＴＴＰのレスポンス時間のデータとして「サーバ輻輳状態監視データ」を作成する。図５はサーバ輻輳状態監視データの例を示す図である。この図は、クライアントＣ１とクライアントＣ２がサーバＳ１に要求を行ない、クライアントＣ１がサーバＳ２へ要求を行なっている状態でのレスポンス時間のデータを表している。図では、監視対象サーバと、要求発生クライアントと、要求時刻と、現在時刻と、要求送信後の経過時刻と、輻輳検出閾値をそれぞれ示している。この図は、クライアントＣ１とクライアントＣ２がサーバＳ１に要求を行ない、クライアントＣ１がサーバＳ２へ要求を行なっている状態でのレスポンス時間のデータを表している。
【００５３】
また、このデータはサーバの輻輳を検出することが目的であるため、一つのサーバに対して全てのクライアントに対する「サーバ輻輳状態監視データ」のエントリを作成せず、サーバ毎にクライアント−サーバ間の通信をサンプリングしてレスポンス時間を測定してもよい。
【００５４】
サーバ輻輳監視手段１１は、図５のレスポンス時間を監視し、クライアントＣ１からサーバＳ１に送信した要求に対するサーバＳ１からの応答が、予め輻輳検出閾値として設定していた時間内になかった場合、サーバＳ１が輻輳状態であると判定する。図３に示すように、ネットワークに複数のサーバが存在する場合、全サーバに同一の閾値を適用して監視してもよいし、サーバ毎に異なる閾値を設定してもよい。ちなみに、図５の場合は、要求送信後経過時間レスポンスが５００ｍｓｅｃであるのに対して、閾値は１０００ｍｓｅｃであり、輻輳は生じていない。
【００５５】
ここでは、サーバの輻輳状態を判定する基準として要求に対するレスポンス時間を用いたが、予めネットワーク負荷に対するサーバの負荷の対応が分かっていれば、サーバの応答時間ではなく、規定時間内にサーバＳ１宛にルータＲ３を通過するパケット数等を用いてもよい。通常、ルータは統計情報として、転送したパケット数やサイズを収集しているため、ルータに特殊な装置を追加することなく、またＩＰパケットの転送速度を悪化させることなく実現することができる。
【００５６】
サーバ輻輳監視手段１１がサーバの輻輳を検出していない状態では、サーバ輻輳監視手段１１は、受信した要求メッセージ１０１をルーティング処理部３へ通知し、ルーティング処理部３はＩＰルーティング処理を実行の上、ＬＡＮフレーム送信部４からサーバＳ１へ要求１０１を送信する。これにより、クライアントＣ１はサーバＳ１へのアクセスができる。
（輻輳時の動作）
ルータＲ３のサーバ輻輳監視手段１１において、クライアントＣ１からサーバＳ１への要求１０２に対する輻輳を検出すると、ルータＲ３のサーバ輻輳監視手段１１はクライアントＣ１へ棄却メッセージ１０２を送信する。更にルータＲ３のサーバ輻輳監視手段１１は、ルータＲ３の輻輳原因パケット廃棄要求手段１２へ通知する。通知する情報として、ＨＴＴＰ要求がタイムアウトしたＩＰパケットのＩＰＳＡ（ＩＰ Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）とＩＰＤＡ（ＩＰ Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）を通知すれば、この情報より、クライアントＣ１のＩＰアドレス、サーバＳ１のＩＰアドレスが分かる。
【００５７】
ルータＲ３の輻輳原因パケット廃棄要求手段１２は、クライアントＣ１を接続しているルータＲ１へ輻輳通知メッセージ１０３を送信する。輻輳通知メッセージは、本発明の機能を具備するルータ間でやりとりするメッセージで、アクセスを規制するサーバのＩＰアドレスを格納している。
【００５８】
ルータＲ３からルータＲ１へ輻輳通知メッセージ１０３を送信するにあたり、ＩＰパケットとしてＲ３からＲ１へ送信するが、元々のクライアントＣ１からサーバＳ１へのＩＰパケット情報にはルータＲ１のＩＰアドレスは含まれないので、ルータＲ３にはルータＲ１のＩＰアドレスは、転送しているＩＰパケットの情報からだけでは分からない。
【００５９】
この場合には、ルータＲ３からルータＲ１への輻輳通知メッセージ１０３をＩＰパケットとして送信する際には、ＩＰＤＡとして既判明であるクライアントＣ１のＩＰアドレスを設定し、ルータＲ３が保持するＯＳＰＦ／ＢＧＰ等のルーティング情報を元にクライアントＣ１へ向けて適切な経路にて送信する。
【００６０】
また、ネットワークで用いるルーティングプロトコルによっては、ルータＲ１のＩＰアドレスが分かる場合がある。例えば、ＯＳＰＦの場合、クライアントＣ１が属するネットワークプレフィクスを広報しているルータのループバックアドレスがルータＲ１のＩＰアドレスであると、ルータＲ３にて知ることができる。この場合は、ルータＲ３からルータＲ１のＩＰアドレスを直接指定して輻輳通知メッセージを送信すると、ルータＲ１の処理を省略することかできる。
【００６１】
図６はこの例における輻輳通知メッセージの例を示す図である。図に示すように、輻輳通知メッセージはＩＰヘッダと、メッセージ識別子と、サーバＩＰアドレスとから構成されている。ＩＰヘッダは、ＩＰＤＡとしてクライアントＣ１のアドレスを設定し、ＩＰＳＡとしてルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスを示す。
【００６２】
輻輳通知メッセージ１０３を送信したルータＲ３の輻輳原因パケット廃棄要求手段１２は、どのクライアントに対して、どのサーバに対する輻輳通知メッセージを送ったか、輻輳通知メッセージ管理データとして保持しておく。
【００６３】
ここで、ルータはＯＳＰＦやＢＧＰをはじめとするダイナミックルーティングプロトコルにより、自分が接続するネットワークの接続状況（トポロジー）を把握している。このため、図７の輻輳通知メッセージ管理データに登録しているクライアントが属するネットワークが（切断された等の理由により）到達不可能になったこと、或いは再び到達可能になったことを、ルーティング情報により知ることができる。
【００６４】
ネットワークのルーティング情報の変化を元に、図７に示す輻輳通知メッセージ管理データに登録してあるクライアントの有効／無効を制御することで、後に説明する輻輳解除通知をネットワーク的に到達不可能なクライアントに向けて送信することがなくなり、ネットワークに無駄なトラフィックを発生させることもない。図７には、輻輳通知メッセージ管理データが、監視対象サーバと、要求発生クライアントと、輻輳通知状態と、クライアント状態から構成されていることが示されている。
【００６５】
クライアントＣ１宛の輻輳通知メッセージ１０３を受信したルータＲ１では、ＯＳＰＦ／ＢＧＰ等のルーティングプロトコルにより保持しているルーティング情報を参照し、ルータＲ１の輻輳原因パケット廃棄手段１３において、受信したのは自分が接続するクライアントＣ１に対する輻輳通知メッセージであることを検出する。
【００６６】
ルータＲ１は、受信した輻輳通知メッセージ１０３がクライアントＣ１宛の場合、自分の先に更にルータが存在しないため、クライアントＣ１へは輻輳通知メッセージを転送せずに、自分で終端する。更に、ルータＲ１では輻輳通知メッセージ１０３の内容を確認して、サーバＳ１へのアクセスが規制されていることを認識し、ルータＲ１内の輻輳原因パケット廃棄手段１３へサーバＳ１のＩＰアドレスを通知する。
【００６７】
ルータＲ１の輻輳原因パケット廃棄手段１３は、保持している図８に示す「アクセス規制サーバデータ」に、サーバＳ１のＩＰアドレスを登録する。以降、クライアントＣ１からサーバＳ１に対する要求１０４は、ルータＲ１の輻輳原因パケット廃棄手段１３において棄却され、ネットワーク内にサーバＳ１への要求が流れ込むことはない。
【００６８】
ルータＲ３がサーバＳ１の輻輳を検出している状況において、異なるクライアントＣ２からのサーバＳ１に対する要求１０５があった場合、ルータＲ３の輻輳原因パケット廃棄手段１３は要求を棄却すると共に、ルータＲ３の輻輳原因パケット廃棄手段１３はクライアントＣ２のＩＰアドレスをＩＰＤＡとして輻輳通知メッセージ１０６を送信することによってルータＲ２の輻輳原因パケット廃棄手段１３へサーバＳ１の輻輳を通知し、以後、クライアントＣ２からサーバＳ１に対する要求はルータＲ３によって棄却される。
【００６９】
以上、ルータＲ３が入側のルータＲ１へのフィルタを設定するために専用の制御メッセージを送信する方法を説明したが、これ以外にもルータＲ３がルータＲ１にテルネット（ｔｅｌｎｅｔ）で接続され、既存のコマンドラインインタフェースにてフィルタを設定するという例もある。ルータＲ３がＯＳＰＦ／ＢＧＰ等のダイナミックルーティングプロトコルにより、ネットワークのトポロジ情報を保持している場合であれば、クライアントＣ１を収容しているルータＲ１のＩＰアドレスを知ることができる。
【００７０】
このように、ルータ同士が交換しているルーティング情報を利用することで、ネットワーク内のルータは互いに認識しあい、ＩＰアドレスに関する情報を取得できるので、ルータＲ３はルータＲ１のＩＰアドレスにテルネットすることで、ルータＲ１のフィルタ設定を実施することができる。また、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）プロトコルによって定義変更が可能なルータであれば、ルータＲ３からルータＲ１へＳＮＭＰセットリクエストを送信してルータＲ１へ設定を実施することも可能である。
【００７１】
なお、ルータＲ３においてはサーバ毎に輻輳の状況を監視するため、サーバＳ１が輻輳状態でクライアントからＳ１に対する要求が規制されている状態であっても、サーバＳ２の輻輳は検出されておらず、ルータＲ１,Ｒ２においてアクセスを規制することはないため、クライアントＣ１,Ｃ２からサーバＳ２に対する要求１０８,１０９が転送され、クライアントからサーバＳ２に対する通信には影響がない。
（輻輳解除時の動作）
ルータＲ３においてサーバＳ１の輻輳を検出すると、ルータＲ３のサーバ輻輳監視手段１１はサーバの輻輳状態が解除されたかを監視し始め、サーバの輻輳状態を知るために、定期的にサーバへ要求メッセージ１１０の送信を行なう。サーバの輻輳状態を知るのに、サーバが提供しているサービスに対してプロトコルレイヤ上、低位レイヤのリクエストであるｐｉｎｇ（ＩＣＭＰ Ｅｃｈｏ Ｒｅｑｕｅｓｔ）を用いると、輻輳しているサービスとは関係なく、サーバから即時に応答がきてしまう可能性があり、アプリケーションレベルでの輻輳を検出できない。
【００７２】
このため、サーバの提供しているアプリケーションの輻輳状態が分かる要求を送信するほうがよく、具体的にはＨＴＴＰでＷｅｂページの取得要求を行なう。取得要求としては、例えばサーバ輻輳監視手段１１でレスポンスを監視していた、クライアントＣ１からサーバＳ１に対する要求メッセージを参照し、同じＵＲＬに対する取得要求をルータＲ３のサーバ輻輳監視手段１１がサーバＳ１に対して送信する。
【００７３】
ルータＲ３のサーバ輻輳監視手段１１においてサーバＳ１の輻輳解除を検出すると、保持している図７の輻輳通知メッセージ管理データを参照し、サーバＳ１に関する輻輳通知を過去に送信しているクライアントＣ１とクライアントＣ２に対し、サーバＳ１の輻輳が解除されたという輻輳解除通知メッセージ１１１,１１２を送信する。
【００７４】
図９は輻輳解除通知メッセージの例を示す図である。図に示すように、ＩＰヘッダと、メッセージ識別子と、サーバＩＰアドレスとを示している。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定する。また、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳解除通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が解消したサーバＳ１のＩＰアドレスである。
【００７５】
輻輳解除通知メッセージ１１１,１１２を受信したルータＲ１及びルータＲ２では、輻輳原因パケット廃棄要求手段１２において、サーバＳ１へのアクセス規制が解除されたことを認識し、更にルーティング情報を参照することで受信した輻輳解除通知メッセージが自分に接続されているクライアントに対する輻輳解除通知メッセージであることを検出し、ルータＲ１及びＲ２は受信した輻輳解除通知メッセージ１１１,１１２をクライアントに転送しないようにする。
【００７６】
以降、クライアントＣ１及びＣ２からサーバＳ１に対する要求１１３,１１４は、ルータＲ１及びＲ２の輻輳原因パケット廃棄手段１３において棄却されることはなくなり、クライアントＣ１及びクライアントＣ２からサーバＳ１へ再びアクセスすることが可能となる。
【００７７】
以上説明したような方法で、ネットワークに接続されているサーバにて輻輳状態が発生した場合、サーバを接続するルータとクライアントを接続するルータが保持する情報を交換して連携することにより、輻輳しているサーバに対する要求がネットワークに対して流入せず、サーバとネットワークの輻輳を回避することができる。
【００７８】
以下、本発明の第２の実施の形態例について説明する。図１０は本発明の第２の実施の形態例のネットワーク構成を示す図である。図において、クライアントＣ１はルータＲ１に接続され、サーバＳ１はルータＲ３に接続され、ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成における第２の実施の形態例において、図１１を用いて説明する。
【００７９】
図１１は本発明の第２の実施の形態例の動作を示すシーケンス図である。図１０のルータＲ１は図２中の輻輳原因パケット廃棄手段１３を具備し、ルータＲ３は、サーバ輻輳監視手段１１、輻輳原因パケット廃棄要求手段１２、輻輳原因パケット廃棄手段１３及び輻輳サービス特定手段１８を具備する。
【００８０】
クライアントＣ１がサーバＳ１へアクセスする状況において、クライアントＣ１からサーバＳ１へのパケットを中継し、サーバＳ１と接続するルータＲ３はＬＡＮフレーム受信部１で要求メッセージ２０１のＩＰパケットを受信し、サーバ輻輳監視手段１１へ受信したＩＰパケットの内容を通知する。更に、ルータＲ３では、サーバＳ１からクライアントＣ１に対する応答メッセージ２０１についてもＬＡＮフレーム受信部１で受信し、サーバ輻輳監視手段１１へＩＰパケットの内容を通知する。
【００８１】
ルータＲ３のサーバ輻輳監視手段１１は、受信した要求メッセージと応答メッセージの内容をルータＲ３の輻輳サービス特定手段１８に通知する。輻輳サービス特定手段１８では、ＩＰパケット内の各プロトコル毎の情報を精査し、サーバの輻輳を監視する。具体的にはＨＴＴＰの場合、サーバの負荷が同一であっても、ＵＲＬによって要求に対する応答の時間が異なる。
【００８２】
例えば、各種データベースへのアクセスが必要なＵＲＬや各種情報をユーザにあわせて検索・加工して表示するＵＲＬではサーバの負荷が低い状況であっても応答に一定の時間がかかる。一方では、単純なディスクアクセスのみでよいＵＲＬではサーバの負荷が低い状況においては応答時間は短い。
【００８３】
このような状況において、サーバのＩＰアドレス単位に応答時間を測定する方法では、サーバの輻輳状態を正確に監視できない場合がある。このため、ルータＲ３の輻輳サービス特定手段１８では、ＵＲＬ毎にサーバの応答時間を監視することで、サーバの輻輳状態を正確に監視する。
【００８４】
ＵＲＬ毎に応答を監視するには、ルータＲ３の輻輳サービス特定手段１８において、転送するＩＰパケット内のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：ネットワークのトランスポート層の通信プロトコル）のプロトコルを判定し、更にＴＣＰパケット内を検査し、ＨＴＴＰプロトコルの内容を判定する必要があるが、第１の実施の形態例で説明したように、ルータのネットワークプロセッサのプログラム処理を追加することで、ルータに更に特殊な装置を追加することなく、かつＩＰパケットの転送速度を悪化させることなく実現することができる。
【００８５】
図１２はＵＲＬ毎のサーバ輻輳状態監視データの例を示す図である。図に示すように、監視対象ＵＲＬ、要求発生クライアント、要求時刻、現在時間、要求送信後の経過時間及び輻輳検出閾値より構成されている。同図は、クライアントＣ１がサーバＳ１に要求を行なっている状態でのレスポンス時間のデータを表している。
【００８６】
輻輳サービス特定手段１８では、サーバＳ１のＵＲＬ単位に輻輳を監視しており、ＵＲＬ単位に輻輳検出閾値を設定可能であるため、サーバの応答時間がＵＲＬ単位に異なる場合においても、サーバのＩＰアドレス単位に応答時間を測定するよりも、正確にサーバの輻輳を検出することができる。
【００８７】
ルータＲ３で特定のＵＲＬのみが輻輳しているのを検出すると（２０２）、ルータＲ３はルータＲ１へ特定のＵＲＬに対する要求のみを廃棄するメッセージを送信する（２０３）。ルータＲ１において、ＵＲＬ指定の輻輳通知を受信すると、ルータＲ１の輻輳原因パケット廃棄手段１３は特定のＵＲＬに対する要求のみを廃棄することができる（２０４）。
【００８８】
通常、ルータはフィルタリング機能を有しており、特定のＩＰパケットを選択的に廃棄することができる。廃棄するパケットを選択するのは、前述の通りルータが具備するネットワークプロセッサの機能を利用することにより、ＩＰパケット転送能力を悪化させることなく、ＩＰパケットが廃棄対象のＵＲＬ宛の要求であるかチェックすることが可能である。
【００８９】
図１３はＵＲＬ指定の輻輳通知メッセージの例を示す図である。図に示すように、ＩＰヘッダと、メッセージ識別子と、サーバのＵＲＬから構成されている。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が発生したサーバのＵＲＬである。
【００９０】
特定のＵＲＬが輻輳し、クライアントからの要求が規制されている状況においても、同一サーバの異なるＵＲＬ宛の要求は規制されず、クライアントからの通信が可能である（２０５）。このような動作により、サーバの特定ＵＲＬのサービスが輻輳している場合においても、きめ細かくトラフィックを制御することができ、サーバの輻輳を効率よく回避することが可能となる。
【００９１】
図１４は本発明の第３の実施の形態例のネットワーク構成を示す図である。クライアントＣ１及びＣ２はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成における第３の実施の形態例について図１５を用いて説明する。図１５は本発明の第３の実施の形態例の動作を示すシーケンス図である。
【００９２】
図１４のルータＲ１は、図２のブロック図中の輻輳原因パケット廃棄手段１３、通信統計記録手段１４、通信規制クライアント決定手段１５とを具備し、ルータＲ３はサーバ輻輳監視手段１１及び輻輳原因パケット廃棄要求手段１２を具備する。
【００９３】
クライアントＣ１からサーバＳ１への要求を中継するルータＲ１において、ルータＲ１の通信統計記録手段１４は、クライアントからサーバに対する通信を監視し、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号、転送時刻、転送データ量の統計情報を記録する（３０１）。記録する統計情報の例を図１６に示す。図１６はクライアント要求状態監視データの例を示す図である。図に示すように、要求発生クライアントと、監視対象サーバと、ＴＣＰポート番号と、転送データ量と、要求時刻と、現在時刻とから構成されている。
【００９４】
一般的に、ルータはＩＰパケットを転送するという機能を実現するため、ＩＰパケット内の送信元ＩＰアドレス、宛先ＩＰアドレスを参照し、大半のルータがフィルタリング機能としてＴＣＰのポート番号を参照する機能を有する。更に統計機能として転送したデータ量の統計情報を保持しているものがほとんどである。このため、通信統計記録手段１４はルータのＩＰパケットの転送性能を悪化させることなく、図１６の情報をメモリ領域に保持するのみで、既存のルータに容易に追加することができる。
【００９５】
第１の実施の形態例で説明したルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳状態を検出すると（３０２）、ルータＲ３の輻輳原因パケット廃棄要求手段１２は、ルータＲ１の輻輳原因パケット廃棄手段１３へサーバＳ１宛の要求を規制するように通知する（３０３）。
【００９６】
クライアントＣ１からサーバＳ１への要求をルータＲ１が受信すると、ルータＲ１の輻輳原因パケット廃棄手段１３は、クライアントＣ１からの要求を転送するか棄却するかをルータＲ１の通信規制クライアント決定手段１５へ問い合わせる。
【００９７】
通信規制クライアント決定手段１５は、通信統計記録手段１４が記録している統計情報を参照し、応答を棄却するクライアントを決定し、棄却対象のクライアントＣ１からの要求は棄却し（３０４）、棄却対象外のクライアントＣ２からの要求は転送する（３０５）。
【００９８】
規制するクライアントを決定する方法として、例えば最終通信時刻と、現在時刻との差分が大きいクライアントからの要求を規制する方法がある。この方法を使用すると、クライアントＣ１がＷｅｂサービスを利用していた際にサーバの輻輳が検出されても、クライアントＣ１の通信は棄却されることなく継続され、新しくＷｅｂサービスを利用しようとしていたクライアントＣ２かの要求が棄却される。
【００９９】
ランダムに通信を規制する方法では、サーバ輻輳時にＷｅｂサービスを利用していたクライアントの通信が途中で規制され、サービスが途中で異常終了してしまう状況が発生するが、本実施の形態例の方法では、サービスを利用していたクライアントの通信が継続され、新規にサービスを利用しようとするクライアントの通信を規制するため、サーバが効率的にＷｅｂサービスを提供することができる。
【０１００】
また、規制するクライアントを決定する方法として、例えば通信データ量が多いクライアントからの要求を規制する方法もある。ある特定ユーザが大量のデータを長時間にわたりダウンロードする等、サーバ及びネットワークの輻輳の原因となっている場合には、クライアントの通信をランダムに規制するのではなく、転送データ量の多いクライアントの通信を規制することで特定のユーザがサーバ資源やネットワーク資源を占有することを回避して効率的にサーバ及びネットワークを使用することができる。
【０１０１】
図１７は本発明の第４の実施の形態例のネットワーク構成を示す図である。クライアントＣ１、Ｃ２はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成の動作を図１８に示すシーケンス図を用いて説明する。図１８は本発明の第４の実施の形態例の動作を示すシーケンス図である。
【０１０２】
図１７のルータＲ３は、図２に示すブロック図中のサーバ輻輳監視手段１１、サーバ輻輳通知手段１６を具備し、ルータＲ１はサーバ輻輳通知手段１６を具備する。
【０１０３】
クライアントＣ１からルータＲ１に対して要求４０１を送信する。この要求４０１はサーバＳ１まで伝わり、サーバＳ１はこの要求４０１に対する応答４０１を返送する。この返送応答４０１は、クライアントＣ１に伝わる。クライアントＣ１からサーバＳ１への要求を中継するルータＲ３において、クライアントＣ１からサーバＳ１に対する要求４０２のレスポンス時間の情報から、第１の実施の形態例で説明したルータＲ３のサーバ輻輳監視手段１１にてサーバＳ１が輻輳状態と判定された場合、ルータＲ３のサーバ輻輳監視手段１１は、ルータＲ３のサーバ輻輳通知手段１６にサーバＳ１が輻輳していることを通知する。
【０１０４】
ルータＲ３のサーバ輻輳通知手段１６は、ＨＴＭＬ形式でサーバが輻輳しているというメッセージのドキュメントを作成し、クライアントＣ１からＨＴＴＰリクエストに対する応答として、クライアントＣ１へ送信する（４０２）。
【０１０５】
更に、ルータＲ３の輻輳原因パケット廃棄要求手段１２は、ルータＲ１のサーバ輻輳通知手段１６へサーバＳ１の応答時間Ｔａを付加した輻輳通知メッセージを通知する（４０３）。ルータＲ１のサーバ輻輳通知手段１６は、輻輳しているサーバの一覧とその応答時間を保持しておく。
【０１０６】
図１９はサーバの応答時間付き輻輳通知メッセージの例を示す図である。ＩＰヘッダには、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表わす識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスである。サーバ応答時間は、現時点でのサーバＳ１の応答時間である。
【０１０７】
図２０はサーバの応答時間付きアクセス規制サーバデータの例を示す図である。このデータは、ルータＲ１のサーバ輻輳通知手段１６が管理する、サーバの応答時間付きアクセス規制サーバデータの例を示す。図には、アクセス規制サーバ（サーバＳ１のＩＰアドレス）と、対応する応答時間が示されている。
【０１０８】
以降、ルータＲ１のサーバ輻輳通知手段１６がサーバの輻輳解除通知を受信するまで、ルータＲ１に接続されているクライアントＣ１から輻輳しているサーバＳ１に対しての要求を受信すると、ルータＲ１のサーバ輻輳通知手段１６は、図２０のサーバの応答時間付きアクセス規制サーバデータ内の応答時間Ｔａを表示するＨＴＭＬ形式のドキュメントを生成し、現在のサーバ輻輳状態として、要求を行なったクライアントＣ１へ送信する（４０４）。
【０１０９】
この状況において、異なるクライアントＣ２からサーバＳ１に対する要求があった場合にも、サーバＳ１の応答時間ＴａをＨＴＭＬ形式のＷｅｂページとして生成し、クライアントＣ２へ通知する（４０５）。
【０１１０】
ルータＲ３のサーバ輻輳監視手段１１は、サーバＳ１の輻輳状態を検出すると、第１の実施の形態例で説明した方法により、サーバＳ１の輻輳状態を定期的に監視する（４０６）。サーバＳ１の応答時間が設定した閾値以上変化した場合、ルータＲ１のサーバ輻輳通知手段１６へ最新の応答時間を通知する（４０７）。ルータＲ１のサーバ輻輳通知手段１６は、保持しているサーバＳ１の応答時間を更新する。ルータＲ１が、クライアントＣ１からの要求を棄却する際には、サーバ輻輳通知手段１６が最新の応答時間Ｔｂをクライアントへ通知する（４０８）。
【０１１１】
ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳解除を検出すると（４０９）、ルータＲ１のサーバ輻輳通知手段１６へ輻輳解除を通知する（４１０）。ルータＲ１のサーバ輻輳通知手段１６は、管理している図２０のデータから、サーバＳ１のエントリを削除する。以降、クライアントＣ１からサーバＳ１に対する要求は転送される。
【０１１２】
以上説明した方法で、サーバ輻輳時に本発明のルータによってクライアントからの要求が規制された場合、要求を発生させた利用者にサーバの輻輳度合いに関する情報が通知されるので、ユーザはサーバの輻輳状態を認識することができ、時間をおいてリトライする（輻輳しない状況での無意味なリトライをやめる）のを促すことができ、サーバが輻輳している状況を緩和させることができる。
【０１１３】
図２１は本発明の第５の実施の形態例のネットワーク構成を示す図である。クライアントＣ１はルータＲ１に接続され、クライアントＣ２はルータＲ２に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間、及びルータＲ２とルータＲ３の間には更に複数のルータを経由してもよい。ルータＲ３は、図２のブロック図のサーバ輻輳履歴管理手段１７を具備する。
（サーバ輻輳時における履歴の記録）
クライアントＣ１がサーバＳ１へアクセスする状況において、ルータＲ３におけるサーバ輻輳監視手段１１が、サーバＳ１が輻輳状態に陥ったと判定した場合を考える。サーバＳ１の輻輳が検出されると、ルータＲ３の輻輳原因パケット廃棄要求手段１２によってクライアントＣ１に対してサーバＳ１の輻輳検出閾値等の情報を付加した輻輳通知メッセージが送信される。
【０１１４】
図２２は輻輳通知メッセージ例を示す図である。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表わす識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスを示し、輻輳検出閾値はサーバＳ１が輻輳検出するための閾値である。
【０１１５】
通知を受け取ったルータＲ１では、「サーバ輻輳履歴データ」を参照し、過去にクライアントＣ１とサーバＳ１間の通信において輻輳が発生したかどうかを判定する。クライアントＣ１−サーバＳ１用の「サーバ輻輳履歴データ」が存在しない、つまりはじめての輻輳発生であれば、新規に「サーバ輻輳履歴データ」を作成し、受信した輻輳通知メッセージの情報を元にクライアントＣ１のＩＰアドレス、サーバＳ１のＩＰアドレス、輻輳検出閾値を「サーバ輻輳履歴データ」内に設定する。
【０１１６】
図２３はサーバ輻輳履歴データの構成例を示す図である。この図は、クライアントＣ１−サーバＳ１間のサーバ輻輳履歴データを示している。図に示すように、監視対象サーバと、要求発生クライアントと、輻輳検出閾値と、検出種別と、検出時刻から構成されている。
【０１１７】
次に、ルータＲ１が輻輳通知メッセージを受信した時刻を輻輳時刻として「サーバ輻輳履歴データ」内に記録する。２回目以降の輻輳発生時は、この輻輳時刻のみを「サーバ輻輳履歴データ」に追加していく。
（サーバ輻輳解除時における履歴の記録）
クライアントＣ１がサーバＳ１へアクセスする状況において、ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳を検出後、サーバＳ１の輻輳解除を検出した場合を考える。ルータＲ３がサーバＳ２の輻輳解除を検出すると、サーバ輻輳監視手段１１によってクライアントＣ１に対し輻輳解除通知メッセージが送信されるが、通知を受け取ったルータＲ１では、初回の輻輳時に生成されたクライアントＣ１−サーバＳ１用の「サーバ輻輳履歴データ」内に輻輳解除時刻を記録する。
【０１１８】
以降は、サーバで輻輳解除が検出される度にサーバ輻輳履歴管理手段１７が該当クライアント−サーバ間のデータ内に輻輳解除時刻を追加する。図２３にサーバ輻輳解除時におけるルータＲ１の「サーバ輻輳履歴データ」の例を示す。以上により、ルータＲ１ではサーバＳ１の情報や輻輳／輻輳解除時刻が「サーバ輻輳履歴データ」に記録される。
【０１１９】
また、サーバ輻輳履歴データの情報をルータＲ１のサーバ輻輳通知手段１６を用いてクライアントＣ１側へ転送することにより、クライアント側からの要求に応じてサーバＳ１の輻輳情報（クライアントＣ１とサーバＳ２のＩＰアドレス、輻輳発生／輻輳解除の回数・時刻、設定された輻輳閾値等）をクライアント側の画面に表示することができる。
【０１２０】
このように、アクセス対象となるサーバの履歴をユーザに提示することにより、そのサーバで輻輳発生が頻発する時間帯や輻輳の程度をユーザが知ることが可能になり、影響を受けない時間帯でのアクセスをユーザに促すことで未然にサーバの輻輳発生を防ぐことが可能となる。
【０１２１】
図２４は本発明の第６の実施の形態例のネットワーク構成を示す図である。図のルータＲ１は、図２のブロック図中の通信優先度決定手段１９を具備する。クライアントＣ１とクライアントＣ２とクライアントＣ３はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよく、例えばＲ１−Ｒ２−Ｒ３のルートと、Ｒ１−Ｒ４−Ｒ３の２種類のルートが存在しているものとする。
【０１２２】
また、従来のトラフィックエンジニアリング技術により、Ｒ１−Ｒ２−Ｒ３のルート上には帯域保証されたパス（Ｐａｔｈ）１が設定されており、一方のＲ１−Ｒ４−Ｒ３のルート上には帯域保証のないベストエフォート（Ｂｅｓｔ Ｅｆｆｏｒｔ）なパス（Ｐａｔｈ）２が設定されているものとする。
【０１２３】
ここで、ルータＲ１のコマンドライン上等でフィルタ条件を設定することにより、ルータＲ１に入ってきたパケットが事前に設定されたフィルタ条件に合致すると、Ｐａｔｈ１やＰａｔｈ２のルート上へとパケットを転送することがトラフィックエンジニアリング機能を備えたルータでは可能となっている。設定できるフィルタ条件としては、ＩＰヘッダ内のＩＰＤＡ／ＩＰＳＡ／ＴＯＳ／プロトコル種別、ＴＣＰヘッダ内のポート番号等から任意のパラメータを指定可能である。
【０１２４】
図２５はルータＲ１におけるフィルタ条件設定の入力例を示す図である。▲１▼のコマンドは、クライアントＣ１（ＩＰアドレス＝ＸＸ．ＸＸ．ＸＸ．ＸＸ）からサーバＳ１（ＩＰアドレス＝ＹＹ．ＹＹ．ＹＹ．ＹＹ）宛のパケットを許容する条件に対し、“ｌｉｓｔ−１”という名前を付与している。▲２▼のコマンドは、クライアントＣ２（ＩＰアドレス＝ＺＺ．ＺＺ．ＺＺ．ＺＺ）からサーバＳ１（ＩＰアドレス＝ＹＹ．ＹＹ．ＹＹ．ＹＹ）宛のパケットを許容する条件に対し“ｌｉｓｔ−２”という名前を付与している。
【０１２５】
▲３▼のコマンドは、条件“ｌｉｓｔ−１”の内容に合致するパケットがルータＲ１に流れ込んだ場合は、Ｐａｔｈ１のルート上にパケットを転送するよう設定を行なっている。▲４▼のコマンドは、条件“ｌｉｓｔ−２”の内容に合致するパケットがルータＲ１に流れ込んだ場合は、Ｐａｔｈ２のルート上にパケットを転送するよう設定を行なっている。上記の設定が入力されると、ルータＲ１では、図２６に示すような「フィルタ条件データ」が作成される。
【０１２６】
図２６はルータＲ１におけるフィルタ条件データを示す図である。図に示すように、送信元ＩＰアドレスと、送信元マスクと、送信先ＩＰアドレスと、送信先マスクと、プロトコル種別と、ＴＯＳ値と、送信元ポート番号と、送信先ポート番号と、対応Ｐａｔｈから構成されている。
【０１２７】
既存のトラフィックエンジニアリング技術を用いた上記の条件で、クライアントＣ１とクライアントＣ２がサーバＳ１へアクセスする状況にある場合、サーバＳ１の輻輳時にルータＲ１の通信優先度決定手段１９がクライアントの優先度に従ってサーバＳ１宛のパケットの振る舞いを決定することができる。
【０１２８】
先ず、ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳を検出すると、輻輳原因パケット廃棄要求手段１２がルータＲ１に対して輻輳通知メッセージを送信する。そして、通知を受けたルータＲ１の輻輳原因パケット廃棄手段１３により廃棄対象となるクライアント（Ｃ１及びＣ２）が決定されるが、その際に輻輳原因パケット廃棄手段１３は通信優先度決定手段１９に問い合わせを行ない、ルータＲ１が保持しているフィルタ条件データと比較する。
【０１２９】
Ｐａｔｈ１のような帯域保証されたパスと関連付けられたクライアントＣ１は高優先、Ｐａｔｈ２のようなベストエフォートなパスと関連付けられたパスは中優先とみなし、これらは転送すべきパケットとして廃棄対象から外す。この結果、サーバＳ１が輻輳状態にある場合でも、クライアントＣ１及びＣ２からのパケットについてはルータＲ１で一律破棄を行なうのではなく、クライアントＣ１からのパケットは帯域保証されたＰａｔｈ１ルートに流し、クライアントＣ２からのパケットはベストエフォートなＰａｔｈ２ルートに継続して流すことが可能となる。
【０１３０】
但し、ルータＲ１配下に存在するＣ１とＣ２以外のクライアントは低優先とみなし廃棄対象となるため、例えばクライアントＣ３がサーバＳ１との通信を行おうとした場合は、ルータＲ１においてパケットは一律破棄される。
【０１３１】
また、優先クライアントの使用するパスについて、ルータの持つトラフィックエンジニアリング機能を利用し事前に迂回経路を設定しておけば、優先クライアントのパス上でノード／リンク障害が起きた場合でも、クライアント側で特に意識することなくサーバへ向けた転送を継続することができる。
【０１３２】
例えば、図２７に示すように、ルータＲ１とルータＲ３間にルータＲ５を経由するもう１本のパス“Ｐａｔｈ”３がされているとすると、ルータＲ１においてトラフィックエンジニアリング機能によりＰａｔｈ１の迂回経路としてＰａｔｈ３を設定しておけば、Ｐａｔｈ１で障害が発生した場合でも、瞬時にＰａｔｈ３へ切り替えることが可能であり、優先すべきクライアントについてパケットロスの影響なく通信可能となる。但し、迂回経路を設定しない場合は、ＯＳＰＦ等のルーティングプロトコルの優先経路に従ったベストエフォートな経路に従ったルートで転送される。
【０１３３】
このように、サーバの輻輳時に全クライアントのパケットを無作為に破棄するのではなく、トラフィックエンジニアリング機能を備えたルータの持つ、フィルタ条件に従ったパス選択機能と連携させることで、クライアント毎のパケットの扱いをルータ側できめ細かく制御することが可能となる。
【０１３４】
例えば、あるＷｅｂサイトを有するサーバで輻輳が発生した場合でも、ＩＳＰと優先サービスを契約した顧客に対してはアクセスを拒否することなく安定したサービスを料金に応じて段階的に提供するが、契約外の通常の顧客に対してはアクセス拒否を行なうといったサービスの差別化を、ルータを保有するＩＳＰ（インターネットサービス事業者）側で提供することが可能となる。
【０１３５】
例えば、ルータが１００台あり、各ルータに１０台ずつのサーバが接続されているネットワークがあり、この合計１０００台のサーバ輻輳回避及びこのネットワークの輻輳回避を行なう場合、１０００台のサーバに対して、輻輳回避に関する機能追加が必要であり、仮にルータと制御サーバの性能が同じだと仮定すると、１台の制御サーバで１０台の処理サーバの輻輳制御ができるとした場合、１００台の制御サーバが必要となる。
【０１３６】
ハードルーティングが可能なルータの場合、安定状態ではＣＰＵは空いているので、専用のプロセッサを積む必要はなく、制御サーバでできる程度の輻輳制御であれば、特にコストを上げずに既存のルータで実現できるため、１００台の制御サーバの費用＋１０００台の処理サーバに機能を盛り込むための費用が浮くことになる。
【０１３７】
本発明によれば、以下に示すような効果が得られる。
１．サーバ側に特別な機能を持つことなく、本発明のルータに接続されたサーバの輻輳回避が可能である。
２．サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳回避が可能である。
３．サーバを収容しているルータと、クライアントを収容しているルータが連携することで、ＷｅｂページのＵＲＬやＦＴＰのディレクトリ等の単位で輻輳制御を行ない、特定のサービスのみが輻輳している場合には、当該サービスのパケットのみを廃棄することで、サーバの輻輳を効果的に回避することが可能となる。
４．クライアント／サーバに特別な機能を持つことなく、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することが可能となる。
５．サーバ輻輳時に、ユーザが通信タイムアウトを持たずに、サーバ輻輳及びどのくらいの時間にサーバにアクセスすれば空いているか等の輻輳に関する情報を認識することで、ユーザの利便性を向上させることが可能となる。
６．サーバ側に特別な機能を持つことなく、ルータに収容されている全てのサーバの輻輳履歴を集中管理することが可能となる。
７．ＩＳＰ等の多数のサーバが接続されたネットワークにおいて、従来技術のようにアクセス制御サーバが全サーバの輻輳を監視し、クライアントが接続された多数のルータに対してフィルタを設定するためには、サーバ数、ネットワーク規模に応じた多数のアクセス制御サーバが必要となるが、本発明ではルータのみの導入で輻輳制御が実現可能である。
８．ハードルーティングを行なうルータの場合、安定動作中のＣＰＵは殆ど動作していないが、アクセス制御サーバと同様の処理をルータのソフトウェアで実現することで、ルータのＣＰＵを有効利用し、ＩＳＰ等の大規模ネットワークにおける全体のコストを低く抑えることが可能である。
９．本発明の輻輳制御をルータのハード機能で実現することにより、アクセス制御サーバのソフトウェアで実現する場合に比較して、けた違いに多数のサーバを１台のルータで制御することが可能である。
１０．ルータ側にクライアント毎の優先度を設定しておくことにより、輻輳したサーバへの通信を行なうクライアントに対し、入側ルータでの廃棄対象とするか、帯域制御により回線帯域を制限するか、迂回経路を使用するか、等の提供サービスの差別化を行なうことが可能である。
【０１３８】
（付記１） サーバとクライアントが設置されるネットワークシステム上のルータであって、
ＬＡＮフレームを受信するＬＡＮフレーム受信部と、該ＬＡＮフレーム受信部の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部と、該トラフィックエンジニアリング制御部の出力を受けてルーティング処理を行なうルーティング処理部と、該ルーティング処理部の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部とを具備するものにおいて、
前記各構成要素と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段
を設けたことを特徴とするネットワーク及びサーバの負荷低減ルータ。
【０１３９】
（付記２） サーバ宛のパケットの応答遅延を監視してサーバの輻輳を自動的に検出するサーバ輻輳監視手段と、
サーバの輻輳／輻輳解除検出時に、輻輳原因となっているパケットの廃棄／中継を、クライアントを収容するルータに対して要求する輻輳原因パケット廃棄要求手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする付記１記載のネットワーク及びサーバの負荷低減ルータ。
【０１４０】
（付記３） サーバを収容しているルータで、輻輳しているサーバのサービスを特定する輻輳サービス特定手段と、クライアントを収容しているルータで、輻輳しているサーバのサービスに関するパケットのみを廃棄する輻輳原因パケット廃棄手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４１】
（付記４） クライアント−サーバ間のパケットを監視し、サーバ−クライアント間のパケット通信量や最終通信時刻等の統計情報を記録する通信統計記録手段と、サーバ輻輳時に、クライアントを収容するルータに対してパケット廃棄を要求する時に、新たに通信を開始するクライアントや通信量が規定量を超えているクライアントのパケット通信を制限するクライアントを決定する通信制御クライアント決定手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４２】
（付記５） サーバの輻輳検出時に、輻輳原因となるパケットを廃棄すると同時に、クライアントに対してサーバ輻輳を通知するサーバ輻輳通知手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４３】
（付記６） サーバ輻輳の履歴を管理するサーバ輻輳履歴管理手段を前記サーバ輻輳制御手段内に設け、前記サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することを特徴とする付記５記載のネットワーク及びサーバの負荷低減ルータ。
【０１４４】
（付記７） 優先／非優先にすべきクライアントの持つクラスを事前に設定し、そのクラスに応じたパケットに対する挙動を決定する通信優先度決定手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４５】
【発明の効果】
以上、説明したように、本発明によれば、以下のような効果が得られる。
（１）請求項１記載の発明によれば、サーバの輻輳を検出したサーバ輻輳制御手段１０は、サーバの輻輳制御を行なって、サーバの輻輳を低減することができる。
（２）請求項２記載の発明によれば、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避することができる。
（３）請求項３記載の発明によれば、輻輳原因となっているパケットを、宛先サーバのアドレスやプロトコルで識別するだけでなく、ＷｅｂページのＵＲＬやＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰで用いられるファイル転送プロトコル）のディレクトリ等の輻輳しているサービスに関するパケットのみの廃棄を可能とすることができる。
（４）請求項４記載の発明によれば、特定のクライアントのみの通信を規制することを可能とし、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することができる。
（５）請求項５記載の発明によれば、ユーザが通信タイムアウトを持たずサーバ輻輳及び輻輳に関する情報を認識することを可能とし、ユーザの利便性を向上させることができる。
【０１４６】
このように、本発明によれば、ルータに収容される全てのサーバに対して、サーバ側に特殊な機能を盛り込むことなく、自動的にサーバの輻輳を検出することができ、クライアントを収容するルータと連携することで、サーバ及びネットワーク全体の輻輳回避が容易に実現することができるネットワーク及びサーバの負荷軽減ルータを提供することができる。
【図面の簡単な説明】
【図１】本発明の原理ブロック図である。
【図２】本発明の第１一実施の形態例を示すブロック図である。
【図３】本発明の第１の実施の形態例のネットワーク構成を示す図である。
【図４】本発明の第１の実施の形態例の動作を示すシーケンス図である。
【図５】サーバ輻輳状態監視データの例を示す図である。
【図６】輻輳通知メッセージの例を示す図である。
【図７】輻輳通知メッセージ管理データの例を示す図である。
【図８】アクセス規制サーバデータの例を示す図である。
【図９】輻輳解除通知メッセージの例を示す図である。
【図１０】本発明の第２の実施の形態例のネットワーク構成を示す図である。
【図１１】本発明の第２の実施の形態例の動作を示すシーケンス図である。
【図１２】ＵＲＬ毎のサーバ輻輳状態監視データの例を示す図である。
【図１３】ＵＲＬ指定の輻輳通知メッセージの例を示す図である。
【図１４】本発明の第３の実施の形態例のネットワーク構成を示す図である。
【図１５】本発明の第３の実施の形態例を示すシーケンス図である。
【図１６】クライアント要求状態監視データの例を示す図である。
【図１７】本発明の第４の実施の形態例のネットワーク構成を示す図である。
【図１８】本発明の第４の実施の形態例の動作を示すシーケンス図である。
【図１９】サーバの対応時間付き輻輳通知メッセージの例を示す図である。
【図２０】サーバの応答時間付きアクセス規制サーバデータの例を示す図である。
【図２１】本発明の第５の実施の形態例のネットワーク構成を示す図である。
【図２２】第５の実施の形態例における輻輳通知メッセージ例を示す図である。
【図２３】サーバ輻輳履歴データの構成例を示す図である。
【図２４】本発明の第６の実施の形態例のネットワーク構成を示す図である。
【図２５】ルータＲ１におけるフィルタ条件設定の入力例を示す図である。
【図２６】ルータＲ１におけるフィルタ条件データを示す図である。
【図２７】転送ルートの障害切り替え動作例を示す図である。
【図２８】ルータの概念図である。
【図２９】従来のルータの概念を示すブロック図である。
【図３０】ＬＡＮフレーム受信部、ＬＡＮフレーム送信部、ルーティング処理部の説明図である。
【図３１】トラフィックエンジニアリング制御部の説明図である。
【符号の説明】
１ ＬＡＮフレーム受信部
２ トラフィックエンジニアリング制御部
３ ルーティング処理部
４ ＬＡＮフレーム送信部
１０ サーバ輻輳制御手段

Claims (4)

1. サーバとクライアントが設置されるネットワークシステム上のルータであって、ＬＡＮフレームを受信するＬＡＮフレーム受信部と、該ＬＡＮフレーム受信部の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部と、該トラフィックエンジニアリング制御部の出力を受けてルーティング処理を行なうルーティング処理部と、該ルーティング処理部の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部とを具備するものにおいて、
   前記各構成要素と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段を設け、
   サーバ宛のパケットの応答遅延を監視してサーバの輻輳を自動的に検出するサーバ輻輳監視手段と、サーバの輻輳／輻輳解除検出時に輻輳原因となっているパケットの廃棄／中継を、クライアントを収容するルータに対して要求する輻輳原因パケット廃棄要求手段とを前記サーバ輻輳制御手段内に設けたことを特徴とするネットワーク及びサーバの負荷低減ルータ。
2. サーバを収容しているルータで、輻輳しているサーバのサービスを特定する輻輳サービス特定手段と、クライアントを収容しているルータで、輻輳しているサーバのサービスに関するパケットのみを廃棄する輻輳原因パケット廃棄手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする請求項１記載のネットワーク及びサーバの負荷低減ルータ。
3. クライアント−サーバ間のパケットを監視し、サーバ−クライアント間のパケット通信量や最終通信時刻等の統計情報を記録する通信統計記録手段と、サーバ輻輳時に、クライアントを収容するルータに対してパケット廃棄を要求する時に、新たに通信を開始するクライアントや通信量が規定量を超えているクライアントのパケット通信を制限するクライアントを決定する通信制御クライアント決定手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする請求項１記載のネットワーク及びサーバの負荷低減ルータ。
4. サーバの輻輳検出時に、輻輳原因となるパケットを廃棄すると同時に、クライアントに対してサーバ輻輳を通知するサーバ輻輳通知手段を前記サーバ輻輳制御手段内に設けたことを特徴とする請求項１記載のネットワーク及びサーバの負荷低減ルータ。

Images