JP4099108B2

JP4099108B2 - Network and server load reduction router

Info

Publication number: JP4099108B2
Application number: JP2003164770A
Authority: JP
Inventors: 真一倉成; 弘典落合; 義章堀之内; 伸一林; 成健居細工
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2003-06-10
Filing date: 2003-06-10
Publication date: 2008-06-11
Anticipated expiration: 2023-06-10
Also published as: JP2005005836A

Description

【０００１】
【発明の属する技術分野】
本発明はネットワーク及びサーバの負荷低減ルータに関し、更に詳しくは、インターネット、イントラネット上に設置されたクライアントサーバ型サービスの利用に際し、サーバの輻輳によりサーバへのアクセスが遅延するような状況において、ユーザがサーバへの不用意なアクセスリトライを行なうことによるネットワークの輻輳を避けると共に、サーバの負荷を軽減し、サーバ輻輳状態を早期に復旧させるルータに関する。
【０００２】
【従来の技術】
ルータ（ｒｏｕｔｅｒ）とは、ネットワークパケットをネットワーク層でルーティングする装置のことである。データリンク層では隣接ノード間若しくは同一セグメント上でしかデータの伝達ができないが、ルータはデータリンク層でのデータ転送機能を組み合わせて、ネットワーク上のあらゆるノード間同士でのデータ転送を担当する。ルータは、通常、ルーティングできるプロトコルが固定的に決まっている。図２８はルータの概念図である。図において、ＮＷ１〜ＮＷ３はネットワーク、Ｃ１〜Ｃ３は各ネットワーク間を接続する回線、Ｒ１〜Ｒ３は各回線Ｃ１〜Ｃ３に接続されるルータである。ルータＲ１〜Ｒ３と回線Ｃ１〜Ｃ３の間には回線インタフェースＩＮＴが設けられている。ルータＲ１〜Ｒ３は、ネットワークを結ぶため、複数の回線インタフェースＩＮＴを持っており、回線インタフェースＩＮＴから受信したパケットを宛先に応じて、適切な回線Ｃ１〜Ｃ３へ出力する。
【０００３】
図２９は、従来のルータの概念を示す図である。このルータは、クライアントとサーバの間に配置され、クライアントとサーバ相互間のデータの送受信を制御する機能を持つ。図において、１はＬＡＮフレームを受信するＬＡＮフレーム受信部、２は該ＬＡＮフレーム受信部１の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部、３は該トラフィックエンジニアリング制御部２の出力を受けてルーティング処理を行なうルーティング処理部、４は該ルーティング処理部３の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部である。
【０００４】
図３０はＬＡＮフレーム受信部、ＬＡＮフレーム送信部、ルーティング処理部の説明図である。図２８，図２９と同一のものは、同一の符号を付して示す。回線インタフェースＩＮＴからのパケットをＬＡＮフレーム受信部１で受信する。この受信したパケットはルーティング処理部３に入る。該ルーティング処理部３は、ルータ間の制御メッセージのやりとりにてルーティング情報を交換しあい、「どの回線の先にどのような経路があるか」というルーティング情報を持っている。５はルーティング情報を記憶するルーティング情報データベースである。ＬＡＮフレーム受信部１で受信したパケットは、ルーティング処理部３で宛先に応じた出側回線インタフェースＩＮＴを決定し、出側回線のＬＡＮフレーム送信部４へパケットを送信する。
【０００５】
図３１はトラフィックエンジニアリング制御部の説明図である。図２８，図２９と同一のものは、同一の符号を付して示す。通常のルータでは、ルーティング情報に従ってパケットを転送する。トラフィックエンジニアリング機能を備えたルータでは、例えばパケットの宛先アドレスに対する出力インタフェースが複数あるような場合、次のような制御を実施する。
・帯域を均等分散させるために、パケット毎に出力インタフェースを振り分ける。
・複数ある出力インタフェース候補の中から、特定のインタフェースのみに出力する。
・出力するインタフェースの帯域を制御し、各インタフェースを指定した分の帯域だけ使用するように出力インタフェースの振り分けを制御する。トラフィックエンジニアリング制御部２の上記のような動作は、コマンド入力により設定される。以降、ルータがパケットを受信すると、ルーティング処理部で経路を検索し、トラフィックエンジニアリング制御部２と連携して出力インタフェースを決定し、パケットを回線に出力する。
【０００６】
現在のＷＷＷやＦＴＰ等のクライアントサーバ型のネットワークシステムにおいて、特定のサーバへの要求が集中することにより、当該サーバの処理輻輳が発生してサーバからクライアントへの応答が遅延した場合、クライアント側が処理を中断してサーバへのアクセスリトライを行なうことで、更にサーバへの要求が増え、ネットワークシステム内のトラフィックが増大すると共に、サーバ負荷も上昇し、サーバのさらなる処理輻輳が発生してしまうという問題がある。
【０００７】
サーバの処理輻輳を解消するため、サーバを複数設置してサーバの負荷を分散することにより、サーバの処理能力を向上させ、サーバ側の輻輳を解消する手法が広く用いられている。しかしながら、このサーバ追加による解決方法は、サーバ設置者へのコスト負担が増加する。更に、現実のネットワークにおいては、既に複数のサーバが存在しており、それぞれのサーバの処理輻輳を解消するには、各サーバ毎に追加用サーバを個々に導入する必要があるため、ネットワーク全体では追加するサーバ数が更に増加し、サーバ追加に対するコストが増大する。
【０００８】
また、例えばチケット抽選システムやネットワークを利用したマルチユーザゲームアプリケーション等、サーバの用途によってはデータの一貫性保持のために分散処理が困難なものも存在し、サーバの台数を増やして負荷分散する方法をとることができない分野もある。
【０００９】
利用途中における切断の発生を防止して、ユーザのサービスの向上を図る技術がある（例えば特許文献１参照）。また、トラフィックの輻輳を検出して過大なトラフィックが流れないようにする制御する技術がある（例えば特許文献２参照）。また、サーバ／クライアントシステムにおいて、サーバが輻輳時にクライアントの要求を抑止する技術がある（例えば特許文献３参照）。更に、サーバ／クライアントシステムにおいて、受け付け／アクセス制御／サービスとサーバの機能分割を実施し、クライアントの要求を抑止する技術がある（例えば特許文献４参照）。
【００１０】
【特許文献１】
特開２００１−３２０４２３号公報（第４頁、第５頁、図１）
【特許文献２】
特開２００１−３４５８６１号公報（第３頁、第４頁、図１）
【特許文献３】
特開２００１−６７３１４号公報（第４頁、第５頁、図１）
【特許文献４】
特開２００２−１４１９３６号公報（第５、第６頁、図１）
【００１１】
【発明が解決しようとする課題】
特許文献１に記載の発明は、サービス構成要素に「開始」、「継続」、「終了」の識別子を与え、輻輳中は「開始」要求をリジェクトすることにより、利用中ユーザのサービス向上を行なう。しかしながら、本方式はサービス構成要素に識別を与える必要があるため、コンテンツに対しての加工が必要であり、既に運用中のサービスにそのまま本方式を適用することができないという問題がある。
【００１２】
特許文献２に記載の発明は、ネットワークの輻輳時にパケットのキュー長をダイナミックに変更し、ネットワークの負荷を下げる。また、プロキシサーバの機能も具備し、特定のＷＷＷサーバへのアクセスを禁止することができる。しかしながら、サーバの輻輳を検出することで、当該サーバへのアクセスを制御する機能は具備していない。
【００１３】
特許文献３に記載の発明は、サーバがクライアント（ユーザ端末）に対して、リトライ抑止を制御する。しかしながら、サーバが輻輳中で非常に処理負荷が高い状況において個々のクライアントに対して要求を抑止する制御を実施すると、サーバ自体の負荷が更に上昇し、ネットワークの負荷に対して輻輳を解除するまでの時間が非常に長くなってしまう。また、サーバ／クライアントのアプリケーションがこの方式に対応している必要がある。
【００１４】
特許文献４に記載の発明は、サービス提供サーバと受け付けサーバ、アクセス制御サーバで役割を分担し、アクセス制御サーバがルータに対してフィルタリング設定を実施する。しかしながら、この方法ではサーバ側に機能を盛り込む必要があり、ネットワークに接続された不特定多数のサーバに対して輻輳を回避することは困難である。また、アクセス制御サーバがクライアントを収容するルータを認識することと、ルータでフィルタ関連の処理を実施するためのコマンド等をサーバが把握しておく必要があり、管理が煩雑となる。
【００１５】
以上、説明したように、輻輳しているサーバに対してユーザがアクセスリトライを繰り返すことでさらなるサーバ輻輳が発生している状態において、従来技術では、クライアント／サーバのアプリケーションに特別な機能を持たない限り、サーバへのリトライを抑止してサーバ負荷を減少することはできず、ネットワークに不要なトラフィックが流入していた。
【００１６】
本発明はこのような課題に鑑みてなされたものであって、ルータに収容される全てのサーバに対して、サーバ側に特殊な機能を盛り込むことなく、自動的にサーバの輻輳を検出することができ、クライアントを収容するルータと連携することで、サーバ及びネットワーク全体の輻輳回避が容易に実現できるネットワーク及びサーバの負荷低減ルータを提供することを目的としている。
【００１７】
【課題を解決するための手段】
本発明では、ネットワークトラフィック自体を動的に制御できるルータにて、クライアントの流入トラフィックを制御することにより、既存のサーバ／クライアント自体には輻輳制御用に特に処理を必要としない方式であり、既存のサーバ／クライアントのままで当該サーバに対するユーザ要求自体をネットワーク内へ流入するのを制御でき、ネットワーク負荷を下げると共に、輻輳中のサーバの処理効率向上を可能とする。
【００１８】
また、ルータにて制御するため、ネットワークを含めたシステム全体の追加投入コストやシステム構築の変更等が非常に少なくて済むというメリットがある。これは、通常のサーバでＩＰパケットの監視を実施するにはネットワークの転送速度を悪化させないよう、サーバに対してネットワーク処理を高速に実現するためのハードウェアを追加する必要があるが、本来、ネットワークの転送速度を悪化させることなくＩＰパケットの内容を高速に検査しているルータにおいて本制御を実現するには更に特殊なハードウェアを追加する必要がなく、ルータのＩＰパケット転送処理部への処理追加のみで実現できるためである。
【００１９】
また、クライアント／サーバ間での制御では、そのソフトウェアが適用されたクライアント／サーバ自体の輻輳回避しかできないが、当機能を具備したルータを導入することにより、クライアント毎の優先度に従ってトラフィックエンジニアリング（ＴｒａｆｆｉｃＥｎｇｉｎｅｅｒｉｎｇ）制御を行なうことで、ネットワーク全体としての輻輳回避も可能となる。図１は本発明の原理ブロック図である。図２９と同一のものは、同一の符号を付して示す。図において、１はＬＡＮフレームを受信するＬＡＮフレーム受信部、２は該ＬＡＮフレーム受信部１の出力を受けて帯域制御や迂回回路を設定するトラフィックエンジニアリング制御部、３は該トラフィックエンジニアリング制御部２の出力を受けてルーチング処理を行なうルーティング処理部、４は該ルーティング処理部３の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部である。
【００２０】
１０はＬＡＮフレーム受信部１、トラフィックエンジニアリング制御部２、ＬＡＮフレーム送信部４と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段である。
【００２１】
このように構成すれば、サーバの輻輳を検出したサーバ輻輳手段１０は、サーバの輻輳制御を行なって、サーバの輻輳を低減することができる。
（１）請求項１記載の発明は、サーバとクライアントが設置されるネットワークシステム上のルータであって、ＬＡＮフレームを受信するＬＡＮフレーム受信部と、該ＬＡＮフレーム受信部の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部と、該トラフィックエンジニアリング制御部の出力を受けてルーティング処理を行なうルーティング処理部と、該ルーティング処理部の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部とを具備するものにおいて、前記各構成要素と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段を設け、サーバ宛のパケットの応答遅延を監視してサーバの輻輳を自動的に検出するサーバ輻輳監視手段と、サーバの輻輳／輻輳解除検出時に輻輳原因となっているパケットの廃棄／中継を、クライアントを収容するルータに対して要求する輻輳原因パケット廃棄要求手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする
【００２２】
このように構成すれば、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避することができる。
（２）請求項２記載の発明は、サーバを収容しているルータで、輻輳しているサーバのサービスを特定する輻輳サービス特定手段と、クライアントを収容しているルータで、輻輳しているサーバのサービスに関するパケットのみを廃棄する輻輳原因パケット廃棄手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２３】
このように構成すれば、輻輳原因となっているパケットを、宛先サーバのアドレスやプロトコルで識別するだけでなく、ＷｅｂページのＵＲＬやＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰで用いられるファイル転送プロトコル）のディレクトリ等の輻輳しているサービスに関するパケットのみの廃棄を可能とすることができる。
（３）請求項３記載の発明は、クライアント−サーバ間のパケットを監視し、サーバ−クライアント間のパケット通信量や最終通信時刻等の統計情報を記録する通信統計記録手段と、サーバ輻輳時に、クライアントを収容するルータに対してパケット廃棄を要求する時に、新たに通信を開始するクライアントや通信量が規定量を超えているクライアントのパケット通信を制限するクライアントを決定する通信制御クライアント決定手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２４】
このように構成すれば、特定のクライアントのみの通信を規制することを可能とし、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することができる。
（４）請求項４記載の発明は、サーバの輻輳検出時に、輻輳原因となるパケットを廃棄すると同時に、クライアントに対してサーバ輻輳を通知するサーバ輻輳通知手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２５】
このように構成すれば、ユーザが通信タイムアウトを持たずサーバ輻輳及び輻輳に関する情報を認識することを可能とし、ユーザの利便性を向上させることができる。
【００２６】
この発明において、サーバ輻輳の履歴を管理するサーバ輻輳履歴管理手段を前記サーバ輻輳制御手段内に設け、前記サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することを特徴とする。
【００２７】
このように構成すれば、サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することで、サーバ側に特殊な機能を必要とせずにユーザの利便性を向上させることができる。
【００２８】
また、この発明において、優先／非優先にすべきクライアントの持つクラスを事前に設定し、そのクラスに応じたパケットに対する挙動を決定する通信優先度決定手段を前記サーバ輻輳制御手段内に設けたことを特徴とする。
【００２９】
このように構成すれば、トラフィックエンジニアリング制御（帯域制御や適切な迂回経路やウェイトによる適切な破棄を実施すること）を用いた優先接続等の制御を可能とする。
【００３０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。図２は本発明の一実施の形態例のネットワーク構成を示す図である。図１と同一のものは、同一の符号を付して示す。図において、１１はＬＡＮフレーム受信部１及びＬＡＮフレーム送信部４と接続されるサーバ輻輳監視手段、１２はＬＡＮフレーム送信部４及びサーバ輻輳監視手段１１と接続される輻輳原因パケット廃棄要求手段、１３はＬＡＮフレーム受信部１と接続される輻輳原因パケット廃棄手段である。
【００３１】
１４はＬＡＮフレーム受信部１と接続される通信統計統計記録手段、１５は輻輳原因パケット廃棄手段１３及び通信統計記録手段１４及び輻輳原因パケット廃棄要求手段１２と接続される通信規制クライアント決定手段、１６は輻輳原因パケット廃棄手段１３、ＬＡＮフレーム送信部４及び輻輳原因パケット廃棄要求手段１２と接続されるサーバ輻輳通知手段、１７はサーバ輻輳監視手段１１と接続されるサーバ輻輳履歴管理手段、１８はサーバ輻輳監視手段１１と接続される輻輳サービス特定手段、１９はトラフィックエンジニアリング制御部２、輻輳原因パケット廃棄手段１３及び通信規制クライアント決定手段１５と接続される通信優先度決定手段である。以下、これらの構成要素について詳しく説明する。
（サーバ輻輳監視手段１１）
当該ルータに接続されているサーバについて、クライアントからの要求に対するサーバからの応答の遅延時間を監視し、サーバの輻輳状態を検出するものである。
（輻輳原因パケット廃棄要求手段１２）
サーバ輻輳検出時に、クライアントを収容しているルータに対して、輻輳原因となっているパケットの廃棄を要求する。本機能は、クライアントを収容しているルータのフィルタ機能を利用して、コマンドラインインタフェース等を使用して、輻輳しているサーバのＩＰアドレスやＴＣＰポート番号等によるフィルタの登録／削除を行なうことで実現可能である。
【００３２】
また、クライアントを収容しているルータに輻輳原因パケット廃棄手段１３を持つことで、例えば輻輳しているサーバの特定ＵＲＬ宛パケットのみを廃棄する等、きめ細かな指定も可能である。
【００３３】
また、クライアントを収容しているルータの特定方法として、ルータが本来の中継機能のために持っているＯＳＰＦ／ＢＧＰ等の経路情報を利用することで、クライアントを収容するルータを自動的に認識することも可能である。ここで、ＯＳＰＦとはＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔの略であり、ＢＧＰとはＢｏｒｄｅｒＧａｔｅｗａｙＰｒｏｔｏｃｏｌの略であり、双方共にインターネットの経路制御プロトコルである。
（輻輳原因パケット廃棄手段１３）
サーバを収容するルータの輻輳原因パケット廃棄要求手段１２からの要求を受けて、指定されたパケットの廃棄／中継を制御する。
（通信統計記録手段１４）
クライアント−サーバ間の通信を監視し、サーバからクライアント宛のパケット通信量やクライアントからサーバ宛の最終通信時刻等の統計情報を記録する。
（通信規制クライアント決定手段１５）
サーバ輻輳時に、通信統計記録手段１４で収集された情報を参照し、サーバ輻輳及びネットワーク輻輳を回避するために通信を規制するクライアントを決定する。最終通信時刻が閾値よりも古いクライアントを規制対象とすることで、通信を継続しているクライアントを規制対象から外すことが可能である。
【００３４】
また、サーバからクライアント宛の通信量が閾値よりも大きいクライアントのみを規制対象とすることで、大量の画像や音楽データ等を長時間ダウンロードし続ける等、サーバやネットワーク負荷の原因となっているクライアントのみに限定して規制をかけることも可能である。
（サーバ輻輳通知手段１６）
サーバ輻輳時に、パケットを廃棄するだけでなく、クライアントに対してサーバ輻輳を通知する。通知方法としては、各プロトコルに従った相手ビジーに相当するエラー通知パケットをサーバの代わりにクライアントに送信する方法がある。また、例えばＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ：ＷＷＷで用いるプロトコル）であれば、サーバの輻輳度合いを表示するＷｅｂページのＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇａｇｅ：Ｗｅｂページで使用される言語体系）イメージをクライアントに送信することも可能である。
【００３５】
更に、サーバ輻輳履歴管理手段１７のサーバ輻輳履歴をクライアントに送信することで、どのくらいの時間をおいてサーバにアクセスすれば輻輳状態が回避されている可能性が高いか等をユーザが判断することが可能となる。
（サーバ輻輳履歴管理手段１７）
サーバ輻輳監視手段１１が監視しているサーバの輻輳情報を履歴管理する。
（輻輳サービス特定手段１８）
サーバ輻輳監視手段１１の一部として、ＨＴＴＰのＵＲＬや、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ：ファイル転送プロトコル）のディレクトリ等の単位でサーバの応答遅延時間を監視することで、サーバ単位ではなくサーバの部位単位で輻輳を監視し、輻輳検出時は、輻輳原因パケット廃棄要求手段１２に対して、輻輳部位の識別情報を渡し、クライアントを収容するルータの輻輳原因パケット廃棄手段１３に通知する。
（通信優先度決定手段１９）
クライアントを収容しているルータに対して事前にクライアントの優先度を設定しておくことで、輻輳原因パケット廃棄手段１３でそのクライアントが廃棄対象となった場合でも、単なる廃棄ではなく帯域制御やベストエフォート（ＢｅｓｔＥｆｆｏｒｔ）な経路への迂回等のトラフィックエンジニアリングサービスを決定し、トラフィックエンジニアリング制御部２へ処理要求を行ないネットワーク全体の輻輳を回避する。
（ａ）第１の実施の形態例（請求項２に対応）の動作概要
サーバを収容するルータ（出側ルータ）のサーバ輻輳監視手段１１は、サーバ宛のパケットに対するサーバからの応答の遅延時間を常時監視し、遅延時間が予め決められた輻輳閾値を超えた場合にサーバ輻輳と見なす。輻輳原因パケット廃棄要求手段１２は、サーバ輻輳時に、クライアントを収容しているルータ（入側ルータ）を特定し、当該ルータに対して輻輳を検出したサーバのＩＰアドレス及びＴＣＰのポート番号等を指定してフィルタの設定要求を行なう。
【００３６】
サーバ輻輳を検出したサーバ輻輳監視手段１１は、当該サーバの監視を継続し、応答遅延時間が輻輳解除閾値を切った時点で、サーバ輻輳解除と見なす。輻輳原因パケット廃棄要求手段１２は、サーバ輻輳解除時に、輻輳時に入側ルータに設定したフィルタを解除する。
【００３７】
これにより、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避若しくは低減することが可能となる。
（ｂ）第２の実施の形態例（請求項３に対応）の動作概要
出側ルータの輻輳サービス特定手段１８は、サーバ輻輳監視手段１１の一部として、ＷｅｂページのＵＲＬやＦＴＰのディレクトリ等の単位で、サーバの応答遅延時間を監視し、サーバ輻輳時は、輻輳原因パケット廃棄要求手段１２により、輻輳サービスの識別情報と共にサーバの輻輳を入側ルータの輻輳原因パケット廃棄手段１３に通知する。
【００３８】
入側ルータの輻輳原因パケット廃棄手段１３は、宛先ＩＰアドレス、ＴＣＰ（ＴｒａｎｓｆｅｒＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）ポート番号、輻輳しているＵＲＬ等のフィルタの条件で、輻輳原因となっているパケットの廃棄を行なう。
【００３９】
これにより、通常のルータではサポートされていないような特殊なフィルタリング条件を使用して、パケット廃棄を行なうことが可能となり、例えば同一サーバで実現されている特定のＵＲＬのサービスのみが輻輳している場合に、当該ＵＲＬ宛のパケットのみを廃棄する等、きめ細かな輻輳制御を行ない、サーバの輻輳を効率よく回避することが可能となる。
（ｃ）第３の実施の形態例（請求項４に対応）の動作概要
入側ルータ又は出側ルータにおいて、通信統計記録手段１４は、クライアント−サーバ間の通信を監視し、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号等で特定されるサーバ輻輳の監視単位に、パケット通信量や最終通信時刻等の統計情報を記録する。
【００４０】
サーバ輻輳時、出側ルータの輻輳原因パケット廃棄要求手段１２又は入側ルータの輻輳原因パケット廃棄手段１３が、通信規制クライアント決定手段１５に問い合わせて、通信を規制するクライアントを決定し、決定したクライアントに対してのみパケット廃棄を行なう。
【００４１】
通信規制クライアント決定手段１５は、クライアント決定時に、通信統計記録手段１４に問い合わせて最終通信時刻を参照し、最終通信時刻と輻輳時の時刻との差分が、予め決められた閾値時間以上のものや、パケット通信量が規定量を超えているものを通信規制の対象と決定する。
【００４２】
これにより、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することが可能となる。
（ｄ）第４の実施の形態例（請求項５に対応）の動作概要
サーバ輻輳時に、出側ルータの輻輳原因パケット廃棄要求手段１２又は入側ルータの輻輳原因パケット廃棄手段１３は、サーバ輻輳通知手段１６にサーバ輻輳通知を要求する。
【００４３】
サーバ輻輳通知手段１６は、サーバに成り代わり、各プロトコルに従ったエラー通知パケット又はＨＴＴＰのＷｅｂページのＨＴＭＬイメージ等をクライアントに送信することで、クライアントにサーバ輻輳及び輻輳に関する情報を通知する。
【００４４】
これにより、ユーザが通信タイムアウトを待たずサーバ輻輳及び、どのくらいの時間にサーバにアクセスすれば輻輳が解除されているか等の輻輳に関する情報を認識することができ、ユーザの利便性を向上させることが可能となる。
（ｅ）第５の実施の形態例
出側ルータのサーバ輻輳履歴管理手段１７は、サーバ輻輳監視手段１１により認識したサーバの輻輳具合を履歴管理する。本情報は、ルータの運用コマンド等を使用してネットワーク管理者が読み出すことが可能であり、また、前記サーバ輻輳通知手段１６により、サーバ輻輳時にクライアントに通知することで、サーバ利用者が参照することも可能である。
【００４５】
これにより、サーバの集中管理が可能となり、また、サーバ側に特別な機能を必要とせずに、サーバの輻輳履歴をユーザが認識することが可能となる。
（ｆ）第６の実施の形態例
入側ルータの通信優先度決定手段１９は、サーバを収容するルータの輻輳原因パケット廃棄要求手段１２からの要求を受けて輻輳原因パケット廃棄手段１３によって決定した廃棄対象のクライアントのうち、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号等で事前に設定された優先度条件に合致するクライアントがあるか検索を行なう。
【００４６】
優先度条件に合致するクライアントに対しては、トラフィックエンジニアリングを利用して使用帯域の制限や、ベストエフォート経路への迂回等を実施することにより、サーバ輻輳の回避と共に、ネットワーク内の負荷についても輻輳を回避することが可能となる。
【００４７】
以下に、本発明を利用し、クライアントサーバ型のアプリケーションとして広く用いられているＷｅｂサーバの輻輳を検出し、Ｗｅｂサーバの輻輳及びネットワークの輻輳を低減する例を説明する。
【００４８】
図３は本発明の第１の実施の形態例のネットワーク構成を示す図である。クライアントＣ１はルータＲ１に接続され、クライアントＣ２はルータＲ２に接続され、サーバＳ１とサーバＳ２はルータＲ３に接続されている。ルータＲ１とルータＲ３の間、及びルータＲ２とルータＲ３の間には更に複数のルータを経由していてもよい。このネットワーク構成における第１の実施の形態例について、図４を用いて説明する。
【００４９】
図４は本発明の第１の実施の形態例の動作を示すシーケンス図である。図３と同一のものは、同一の符号を付して示す。Ｃ１,Ｃ２はクライアント、Ｒ１,Ｒ２,Ｒ３はルータ、Ｓ１,Ｓ２はサーバである。図３のルータＲ１とＲ２は、図２のサーバ輻輳監視手段１１、輻輳原因パケット廃棄手段１３を具備し、ルータＲ３は図２のサーバ輻輳監視手段１１、輻輳原因パケット廃棄要求手段１２及び輻輳原因パケット廃棄手段１３を具備する。
（輻輳の検出方法）
クライアントＣ１がサーバＳ１へアクセスする状況において、クライアントＣ１からサーバＳ１へのパケットを中継し、サーバＳ１と接続するルータＲ３はＬＡＮフレーム受信部１で要求メッセージ１０１のＩＰパケットを受信し、サーバ輻輳監視手段１１へ受信したＩＰパケットの内容を通知する。更に、ルータＲ３では、サーバＳ１からクライアントＣ１に対する応答メッセージ１０１についてもＬＡＮフレーム受信部１で受信し、サーバ輻輳監視手段１１へＩＰパケットの内容を通知する。
【００５０】
サーバ輻輳監視手段１１は、ＩＰパケットがＨＴＴＰであるかどうかを判別する。プロトコルの判別は、ＩＰパケット内のポート番号（ＨＴＴＰであればＴＣＰの８０番、ＦＴＰであればＴＣＰの２１番）を参照することで可能である。サーバ輻輳監視手段１１は、更にＨＴＴＰのＩＰパケットがＨＴＴＰの要求メッセージか応答メッセージであるかを判別し、要求メッセージ１０１と応答メッセージ１０１のレスポンス時間を測定する。
【００５１】
ＨＴＴＰはテキスト形式でプロトコルメッセージのやりとりをするため、ＨＴＴＰのパケットの内容を参照すれば、要求メッセージと応答メッセージを判別することができる。本発明の対象となるようなキャリア網で使用されるルータでは、ネットワークプロセッサ（ＮｅｔｗｏｒｋＰｒｏｃｅｓｓｏｒ：ネットワーク処理に特化し、パケット転送動作をプログラム可能なプロセッサ。通常、ＩＰパケットの転送処理をＧｉｇａｂｉｔＥｔｈｅｒ等のワイヤスピードにて実施可能である）にてＩＰパケットの転送をハードウェア的に行なう方法がほとんどであり、この場合、ネットワークプロセッサ部のプログラムを追加することでＩＰパケットの転送能力を悪化させることなく実現することができる。ＩＰパケットの転送をＡＳＩＣ（特定用途向けＩＣ）でハードウェア的に実現しているルータであれば、ＡＳＩＣへのロジックを追加することで実現することができる。
【００５２】
サーバ輻輳監視手段１１は、クライアントのＩＰアドレスとサーバのＩＰアドレスの組み合わせに対応するＨＴＴＰのレスポンス時間のデータとして「サーバ輻輳状態監視データ」を作成する。図５はサーバ輻輳状態監視データの例を示す図である。この図は、クライアントＣ１とクライアントＣ２がサーバＳ１に要求を行ない、クライアントＣ１がサーバＳ２へ要求を行なっている状態でのレスポンス時間のデータを表している。図では、監視対象サーバと、要求発生クライアントと、要求時刻と、現在時刻と、要求送信後の経過時刻と、輻輳検出閾値をそれぞれ示している。この図は、クライアントＣ１とクライアントＣ２がサーバＳ１に要求を行ない、クライアントＣ１がサーバＳ２へ要求を行なっている状態でのレスポンス時間のデータを表している。
【００５３】
また、このデータはサーバの輻輳を検出することが目的であるため、一つのサーバに対して全てのクライアントに対する「サーバ輻輳状態監視データ」のエントリを作成せず、サーバ毎にクライアント−サーバ間の通信をサンプリングしてレスポンス時間を測定してもよい。
【００５４】
サーバ輻輳監視手段１１は、図５のレスポンス時間を監視し、クライアントＣ１からサーバＳ１に送信した要求に対するサーバＳ１からの応答が、予め輻輳検出閾値として設定していた時間内になかった場合、サーバＳ１が輻輳状態であると判定する。図３に示すように、ネットワークに複数のサーバが存在する場合、全サーバに同一の閾値を適用して監視してもよいし、サーバ毎に異なる閾値を設定してもよい。ちなみに、図５の場合は、要求送信後経過時間レスポンスが５００ｍｓｅｃであるのに対して、閾値は１０００ｍｓｅｃであり、輻輳は生じていない。
【００５５】
ここでは、サーバの輻輳状態を判定する基準として要求に対するレスポンス時間を用いたが、予めネットワーク負荷に対するサーバの負荷の対応が分かっていれば、サーバの応答時間ではなく、規定時間内にサーバＳ１宛にルータＲ３を通過するパケット数等を用いてもよい。通常、ルータは統計情報として、転送したパケット数やサイズを収集しているため、ルータに特殊な装置を追加することなく、またＩＰパケットの転送速度を悪化させることなく実現することができる。
【００５６】
サーバ輻輳監視手段１１がサーバの輻輳を検出していない状態では、サーバ輻輳監視手段１１は、受信した要求メッセージ１０１をルーティング処理部３へ通知し、ルーティング処理部３はＩＰルーティング処理を実行の上、ＬＡＮフレーム送信部４からサーバＳ１へ要求１０１を送信する。これにより、クライアントＣ１はサーバＳ１へのアクセスができる。
（輻輳時の動作）
ルータＲ３のサーバ輻輳監視手段１１において、クライアントＣ１からサーバＳ１への要求１０２に対する輻輳を検出すると、ルータＲ３のサーバ輻輳監視手段１１はクライアントＣ１へ棄却メッセージ１０２を送信する。更にルータＲ３のサーバ輻輳監視手段１１は、ルータＲ３の輻輳原因パケット廃棄要求手段１２へ通知する。通知する情報として、ＨＴＴＰ要求がタイムアウトしたＩＰパケットのＩＰＳＡ（ＩＰＳｏｕｒｃｅＡｄｄｒｅｓｓ）とＩＰＤＡ（ＩＰＤｅｓｔｉｎａｔｉｏｎＡｄｄｒｅｓｓ）を通知すれば、この情報より、クライアントＣ１のＩＰアドレス、サーバＳ１のＩＰアドレスが分かる。
【００５７】
ルータＲ３の輻輳原因パケット廃棄要求手段１２は、クライアントＣ１を接続しているルータＲ１へ輻輳通知メッセージ１０３を送信する。輻輳通知メッセージは、本発明の機能を具備するルータ間でやりとりするメッセージで、アクセスを規制するサーバのＩＰアドレスを格納している。
【００５８】
ルータＲ３からルータＲ１へ輻輳通知メッセージ１０３を送信するにあたり、ＩＰパケットとしてＲ３からＲ１へ送信するが、元々のクライアントＣ１からサーバＳ１へのＩＰパケット情報にはルータＲ１のＩＰアドレスは含まれないので、ルータＲ３にはルータＲ１のＩＰアドレスは、転送しているＩＰパケットの情報からだけでは分からない。
【００５９】
この場合には、ルータＲ３からルータＲ１への輻輳通知メッセージ１０３をＩＰパケットとして送信する際には、ＩＰＤＡとして既判明であるクライアントＣ１のＩＰアドレスを設定し、ルータＲ３が保持するＯＳＰＦ／ＢＧＰ等のルーティング情報を元にクライアントＣ１へ向けて適切な経路にて送信する。
【００６０】
また、ネットワークで用いるルーティングプロトコルによっては、ルータＲ１のＩＰアドレスが分かる場合がある。例えば、ＯＳＰＦの場合、クライアントＣ１が属するネットワークプレフィクスを広報しているルータのループバックアドレスがルータＲ１のＩＰアドレスであると、ルータＲ３にて知ることができる。この場合は、ルータＲ３からルータＲ１のＩＰアドレスを直接指定して輻輳通知メッセージを送信すると、ルータＲ１の処理を省略することかできる。
【００６１】
図６はこの例における輻輳通知メッセージの例を示す図である。図に示すように、輻輳通知メッセージはＩＰヘッダと、メッセージ識別子と、サーバＩＰアドレスとから構成されている。ＩＰヘッダは、ＩＰＤＡとしてクライアントＣ１のアドレスを設定し、ＩＰＳＡとしてルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスを示す。
【００６２】
輻輳通知メッセージ１０３を送信したルータＲ３の輻輳原因パケット廃棄要求手段１２は、どのクライアントに対して、どのサーバに対する輻輳通知メッセージを送ったか、輻輳通知メッセージ管理データとして保持しておく。
【００６３】
ここで、ルータはＯＳＰＦやＢＧＰをはじめとするダイナミックルーティングプロトコルにより、自分が接続するネットワークの接続状況（トポロジー）を把握している。このため、図７の輻輳通知メッセージ管理データに登録しているクライアントが属するネットワークが（切断された等の理由により）到達不可能になったこと、或いは再び到達可能になったことを、ルーティング情報により知ることができる。
【００６４】
ネットワークのルーティング情報の変化を元に、図７に示す輻輳通知メッセージ管理データに登録してあるクライアントの有効／無効を制御することで、後に説明する輻輳解除通知をネットワーク的に到達不可能なクライアントに向けて送信することがなくなり、ネットワークに無駄なトラフィックを発生させることもない。図７には、輻輳通知メッセージ管理データが、監視対象サーバと、要求発生クライアントと、輻輳通知状態と、クライアント状態から構成されていることが示されている。
【００６５】
クライアントＣ１宛の輻輳通知メッセージ１０３を受信したルータＲ１では、ＯＳＰＦ／ＢＧＰ等のルーティングプロトコルにより保持しているルーティング情報を参照し、ルータＲ１の輻輳原因パケット廃棄手段１３において、受信したのは自分が接続するクライアントＣ１に対する輻輳通知メッセージであることを検出する。
【００６６】
ルータＲ１は、受信した輻輳通知メッセージ１０３がクライアントＣ１宛の場合、自分の先に更にルータが存在しないため、クライアントＣ１へは輻輳通知メッセージを転送せずに、自分で終端する。更に、ルータＲ１では輻輳通知メッセージ１０３の内容を確認して、サーバＳ１へのアクセスが規制されていることを認識し、ルータＲ１内の輻輳原因パケット廃棄手段１３へサーバＳ１のＩＰアドレスを通知する。
【００６７】
ルータＲ１の輻輳原因パケット廃棄手段１３は、保持している図８に示す「アクセス規制サーバデータ」に、サーバＳ１のＩＰアドレスを登録する。以降、クライアントＣ１からサーバＳ１に対する要求１０４は、ルータＲ１の輻輳原因パケット廃棄手段１３において棄却され、ネットワーク内にサーバＳ１への要求が流れ込むことはない。
【００６８】
ルータＲ３がサーバＳ１の輻輳を検出している状況において、異なるクライアントＣ２からのサーバＳ１に対する要求１０５があった場合、ルータＲ３の輻輳原因パケット廃棄手段１３は要求を棄却すると共に、ルータＲ３の輻輳原因パケット廃棄手段１３はクライアントＣ２のＩＰアドレスをＩＰＤＡとして輻輳通知メッセージ１０６を送信することによってルータＲ２の輻輳原因パケット廃棄手段１３へサーバＳ１の輻輳を通知し、以後、クライアントＣ２からサーバＳ１に対する要求はルータＲ３によって棄却される。
【００６９】
以上、ルータＲ３が入側のルータＲ１へのフィルタを設定するために専用の制御メッセージを送信する方法を説明したが、これ以外にもルータＲ３がルータＲ１にテルネット（ｔｅｌｎｅｔ）で接続され、既存のコマンドラインインタフェースにてフィルタを設定するという例もある。ルータＲ３がＯＳＰＦ／ＢＧＰ等のダイナミックルーティングプロトコルにより、ネットワークのトポロジ情報を保持している場合であれば、クライアントＣ１を収容しているルータＲ１のＩＰアドレスを知ることができる。
【００７０】
このように、ルータ同士が交換しているルーティング情報を利用することで、ネットワーク内のルータは互いに認識しあい、ＩＰアドレスに関する情報を取得できるので、ルータＲ３はルータＲ１のＩＰアドレスにテルネットすることで、ルータＲ１のフィルタ設定を実施することができる。また、ＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）プロトコルによって定義変更が可能なルータであれば、ルータＲ３からルータＲ１へＳＮＭＰセットリクエストを送信してルータＲ１へ設定を実施することも可能である。
【００７１】
なお、ルータＲ３においてはサーバ毎に輻輳の状況を監視するため、サーバＳ１が輻輳状態でクライアントからＳ１に対する要求が規制されている状態であっても、サーバＳ２の輻輳は検出されておらず、ルータＲ１,Ｒ２においてアクセスを規制することはないため、クライアントＣ１,Ｃ２からサーバＳ２に対する要求１０８,１０９が転送され、クライアントからサーバＳ２に対する通信には影響がない。
（輻輳解除時の動作）
ルータＲ３においてサーバＳ１の輻輳を検出すると、ルータＲ３のサーバ輻輳監視手段１１はサーバの輻輳状態が解除されたかを監視し始め、サーバの輻輳状態を知るために、定期的にサーバへ要求メッセージ１１０の送信を行なう。サーバの輻輳状態を知るのに、サーバが提供しているサービスに対してプロトコルレイヤ上、低位レイヤのリクエストであるｐｉｎｇ（ＩＣＭＰＥｃｈｏＲｅｑｕｅｓｔ）を用いると、輻輳しているサービスとは関係なく、サーバから即時に応答がきてしまう可能性があり、アプリケーションレベルでの輻輳を検出できない。
【００７２】
このため、サーバの提供しているアプリケーションの輻輳状態が分かる要求を送信するほうがよく、具体的にはＨＴＴＰでＷｅｂページの取得要求を行なう。取得要求としては、例えばサーバ輻輳監視手段１１でレスポンスを監視していた、クライアントＣ１からサーバＳ１に対する要求メッセージを参照し、同じＵＲＬに対する取得要求をルータＲ３のサーバ輻輳監視手段１１がサーバＳ１に対して送信する。
【００７３】
ルータＲ３のサーバ輻輳監視手段１１においてサーバＳ１の輻輳解除を検出すると、保持している図７の輻輳通知メッセージ管理データを参照し、サーバＳ１に関する輻輳通知を過去に送信しているクライアントＣ１とクライアントＣ２に対し、サーバＳ１の輻輳が解除されたという輻輳解除通知メッセージ１１１,１１２を送信する。
【００７４】
図９は輻輳解除通知メッセージの例を示す図である。図に示すように、ＩＰヘッダと、メッセージ識別子と、サーバＩＰアドレスとを示している。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定する。また、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳解除通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が解消したサーバＳ１のＩＰアドレスである。
【００７５】
輻輳解除通知メッセージ１１１,１１２を受信したルータＲ１及びルータＲ２では、輻輳原因パケット廃棄要求手段１２において、サーバＳ１へのアクセス規制が解除されたことを認識し、更にルーティング情報を参照することで受信した輻輳解除通知メッセージが自分に接続されているクライアントに対する輻輳解除通知メッセージであることを検出し、ルータＲ１及びＲ２は受信した輻輳解除通知メッセージ１１１,１１２をクライアントに転送しないようにする。
【００７６】
以降、クライアントＣ１及びＣ２からサーバＳ１に対する要求１１３,１１４は、ルータＲ１及びＲ２の輻輳原因パケット廃棄手段１３において棄却されることはなくなり、クライアントＣ１及びクライアントＣ２からサーバＳ１へ再びアクセスすることが可能となる。
【００７７】
以上説明したような方法で、ネットワークに接続されているサーバにて輻輳状態が発生した場合、サーバを接続するルータとクライアントを接続するルータが保持する情報を交換して連携することにより、輻輳しているサーバに対する要求がネットワークに対して流入せず、サーバとネットワークの輻輳を回避することができる。
【００７８】
以下、本発明の第２の実施の形態例について説明する。図１０は本発明の第２の実施の形態例のネットワーク構成を示す図である。図において、クライアントＣ１はルータＲ１に接続され、サーバＳ１はルータＲ３に接続され、ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成における第２の実施の形態例において、図１１を用いて説明する。
【００７９】
図１１は本発明の第２の実施の形態例の動作を示すシーケンス図である。図１０のルータＲ１は図２中の輻輳原因パケット廃棄手段１３を具備し、ルータＲ３は、サーバ輻輳監視手段１１、輻輳原因パケット廃棄要求手段１２、輻輳原因パケット廃棄手段１３及び輻輳サービス特定手段１８を具備する。
【００８０】
クライアントＣ１がサーバＳ１へアクセスする状況において、クライアントＣ１からサーバＳ１へのパケットを中継し、サーバＳ１と接続するルータＲ３はＬＡＮフレーム受信部１で要求メッセージ２０１のＩＰパケットを受信し、サーバ輻輳監視手段１１へ受信したＩＰパケットの内容を通知する。更に、ルータＲ３では、サーバＳ１からクライアントＣ１に対する応答メッセージ２０１についてもＬＡＮフレーム受信部１で受信し、サーバ輻輳監視手段１１へＩＰパケットの内容を通知する。
【００８１】
ルータＲ３のサーバ輻輳監視手段１１は、受信した要求メッセージと応答メッセージの内容をルータＲ３の輻輳サービス特定手段１８に通知する。輻輳サービス特定手段１８では、ＩＰパケット内の各プロトコル毎の情報を精査し、サーバの輻輳を監視する。具体的にはＨＴＴＰの場合、サーバの負荷が同一であっても、ＵＲＬによって要求に対する応答の時間が異なる。
【００８２】
例えば、各種データベースへのアクセスが必要なＵＲＬや各種情報をユーザにあわせて検索・加工して表示するＵＲＬではサーバの負荷が低い状況であっても応答に一定の時間がかかる。一方では、単純なディスクアクセスのみでよいＵＲＬではサーバの負荷が低い状況においては応答時間は短い。
【００８３】
このような状況において、サーバのＩＰアドレス単位に応答時間を測定する方法では、サーバの輻輳状態を正確に監視できない場合がある。このため、ルータＲ３の輻輳サービス特定手段１８では、ＵＲＬ毎にサーバの応答時間を監視することで、サーバの輻輳状態を正確に監視する。
【００８４】
ＵＲＬ毎に応答を監視するには、ルータＲ３の輻輳サービス特定手段１８において、転送するＩＰパケット内のＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ：ネットワークのトランスポート層の通信プロトコル）のプロトコルを判定し、更にＴＣＰパケット内を検査し、ＨＴＴＰプロトコルの内容を判定する必要があるが、第１の実施の形態例で説明したように、ルータのネットワークプロセッサのプログラム処理を追加することで、ルータに更に特殊な装置を追加することなく、かつＩＰパケットの転送速度を悪化させることなく実現することができる。
【００８５】
図１２はＵＲＬ毎のサーバ輻輳状態監視データの例を示す図である。図に示すように、監視対象ＵＲＬ、要求発生クライアント、要求時刻、現在時間、要求送信後の経過時間及び輻輳検出閾値より構成されている。同図は、クライアントＣ１がサーバＳ１に要求を行なっている状態でのレスポンス時間のデータを表している。
【００８６】
輻輳サービス特定手段１８では、サーバＳ１のＵＲＬ単位に輻輳を監視しており、ＵＲＬ単位に輻輳検出閾値を設定可能であるため、サーバの応答時間がＵＲＬ単位に異なる場合においても、サーバのＩＰアドレス単位に応答時間を測定するよりも、正確にサーバの輻輳を検出することができる。
【００８７】
ルータＲ３で特定のＵＲＬのみが輻輳しているのを検出すると（２０２）、ルータＲ３はルータＲ１へ特定のＵＲＬに対する要求のみを廃棄するメッセージを送信する（２０３）。ルータＲ１において、ＵＲＬ指定の輻輳通知を受信すると、ルータＲ１の輻輳原因パケット廃棄手段１３は特定のＵＲＬに対する要求のみを廃棄することができる（２０４）。
【００８８】
通常、ルータはフィルタリング機能を有しており、特定のＩＰパケットを選択的に廃棄することができる。廃棄するパケットを選択するのは、前述の通りルータが具備するネットワークプロセッサの機能を利用することにより、ＩＰパケット転送能力を悪化させることなく、ＩＰパケットが廃棄対象のＵＲＬ宛の要求であるかチェックすることが可能である。
【００８９】
図１３はＵＲＬ指定の輻輳通知メッセージの例を示す図である。図に示すように、ＩＰヘッダと、メッセージ識別子と、サーバのＵＲＬから構成されている。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表す識別子である。サーバＩＰアドレスは、輻輳が発生したサーバのＵＲＬである。
【００９０】
特定のＵＲＬが輻輳し、クライアントからの要求が規制されている状況においても、同一サーバの異なるＵＲＬ宛の要求は規制されず、クライアントからの通信が可能である（２０５）。このような動作により、サーバの特定ＵＲＬのサービスが輻輳している場合においても、きめ細かくトラフィックを制御することができ、サーバの輻輳を効率よく回避することが可能となる。
【００９１】
図１４は本発明の第３の実施の形態例のネットワーク構成を示す図である。クライアントＣ１及びＣ２はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成における第３の実施の形態例について図１５を用いて説明する。図１５は本発明の第３の実施の形態例の動作を示すシーケンス図である。
【００９２】
図１４のルータＲ１は、図２のブロック図中の輻輳原因パケット廃棄手段１３、通信統計記録手段１４、通信規制クライアント決定手段１５とを具備し、ルータＲ３はサーバ輻輳監視手段１１及び輻輳原因パケット廃棄要求手段１２を具備する。
【００９３】
クライアントＣ１からサーバＳ１への要求を中継するルータＲ１において、ルータＲ１の通信統計記録手段１４は、クライアントからサーバに対する通信を監視し、送信元ＩＰアドレス、宛先ＩＰアドレス、ＴＣＰポート番号、転送時刻、転送データ量の統計情報を記録する（３０１）。記録する統計情報の例を図１６に示す。図１６はクライアント要求状態監視データの例を示す図である。図に示すように、要求発生クライアントと、監視対象サーバと、ＴＣＰポート番号と、転送データ量と、要求時刻と、現在時刻とから構成されている。
【００９４】
一般的に、ルータはＩＰパケットを転送するという機能を実現するため、ＩＰパケット内の送信元ＩＰアドレス、宛先ＩＰアドレスを参照し、大半のルータがフィルタリング機能としてＴＣＰのポート番号を参照する機能を有する。更に統計機能として転送したデータ量の統計情報を保持しているものがほとんどである。このため、通信統計記録手段１４はルータのＩＰパケットの転送性能を悪化させることなく、図１６の情報をメモリ領域に保持するのみで、既存のルータに容易に追加することができる。
【００９５】
第１の実施の形態例で説明したルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳状態を検出すると（３０２）、ルータＲ３の輻輳原因パケット廃棄要求手段１２は、ルータＲ１の輻輳原因パケット廃棄手段１３へサーバＳ１宛の要求を規制するように通知する（３０３）。
【００９６】
クライアントＣ１からサーバＳ１への要求をルータＲ１が受信すると、ルータＲ１の輻輳原因パケット廃棄手段１３は、クライアントＣ１からの要求を転送するか棄却するかをルータＲ１の通信規制クライアント決定手段１５へ問い合わせる。
【００９７】
通信規制クライアント決定手段１５は、通信統計記録手段１４が記録している統計情報を参照し、応答を棄却するクライアントを決定し、棄却対象のクライアントＣ１からの要求は棄却し（３０４）、棄却対象外のクライアントＣ２からの要求は転送する（３０５）。
【００９８】
規制するクライアントを決定する方法として、例えば最終通信時刻と、現在時刻との差分が大きいクライアントからの要求を規制する方法がある。この方法を使用すると、クライアントＣ１がＷｅｂサービスを利用していた際にサーバの輻輳が検出されても、クライアントＣ１の通信は棄却されることなく継続され、新しくＷｅｂサービスを利用しようとしていたクライアントＣ２かの要求が棄却される。
【００９９】
ランダムに通信を規制する方法では、サーバ輻輳時にＷｅｂサービスを利用していたクライアントの通信が途中で規制され、サービスが途中で異常終了してしまう状況が発生するが、本実施の形態例の方法では、サービスを利用していたクライアントの通信が継続され、新規にサービスを利用しようとするクライアントの通信を規制するため、サーバが効率的にＷｅｂサービスを提供することができる。
【０１００】
また、規制するクライアントを決定する方法として、例えば通信データ量が多いクライアントからの要求を規制する方法もある。ある特定ユーザが大量のデータを長時間にわたりダウンロードする等、サーバ及びネットワークの輻輳の原因となっている場合には、クライアントの通信をランダムに規制するのではなく、転送データ量の多いクライアントの通信を規制することで特定のユーザがサーバ資源やネットワーク資源を占有することを回避して効率的にサーバ及びネットワークを使用することができる。
【０１０１】
図１７は本発明の第４の実施の形態例のネットワーク構成を示す図である。クライアントＣ１、Ｃ２はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよい。このネットワーク構成の動作を図１８に示すシーケンス図を用いて説明する。図１８は本発明の第４の実施の形態例の動作を示すシーケンス図である。
【０１０２】
図１７のルータＲ３は、図２に示すブロック図中のサーバ輻輳監視手段１１、サーバ輻輳通知手段１６を具備し、ルータＲ１はサーバ輻輳通知手段１６を具備する。
【０１０３】
クライアントＣ１からルータＲ１に対して要求４０１を送信する。この要求４０１はサーバＳ１まで伝わり、サーバＳ１はこの要求４０１に対する応答４０１を返送する。この返送応答４０１は、クライアントＣ１に伝わる。クライアントＣ１からサーバＳ１への要求を中継するルータＲ３において、クライアントＣ１からサーバＳ１に対する要求４０２のレスポンス時間の情報から、第１の実施の形態例で説明したルータＲ３のサーバ輻輳監視手段１１にてサーバＳ１が輻輳状態と判定された場合、ルータＲ３のサーバ輻輳監視手段１１は、ルータＲ３のサーバ輻輳通知手段１６にサーバＳ１が輻輳していることを通知する。
【０１０４】
ルータＲ３のサーバ輻輳通知手段１６は、ＨＴＭＬ形式でサーバが輻輳しているというメッセージのドキュメントを作成し、クライアントＣ１からＨＴＴＰリクエストに対する応答として、クライアントＣ１へ送信する（４０２）。
【０１０５】
更に、ルータＲ３の輻輳原因パケット廃棄要求手段１２は、ルータＲ１のサーバ輻輳通知手段１６へサーバＳ１の応答時間Ｔａを付加した輻輳通知メッセージを通知する（４０３）。ルータＲ１のサーバ輻輳通知手段１６は、輻輳しているサーバの一覧とその応答時間を保持しておく。
【０１０６】
図１９はサーバの応答時間付き輻輳通知メッセージの例を示す図である。ＩＰヘッダには、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表わす識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスである。サーバ応答時間は、現時点でのサーバＳ１の応答時間である。
【０１０７】
図２０はサーバの応答時間付きアクセス規制サーバデータの例を示す図である。このデータは、ルータＲ１のサーバ輻輳通知手段１６が管理する、サーバの応答時間付きアクセス規制サーバデータの例を示す。図には、アクセス規制サーバ（サーバＳ１のＩＰアドレス）と、対応する応答時間が示されている。
【０１０８】
以降、ルータＲ１のサーバ輻輳通知手段１６がサーバの輻輳解除通知を受信するまで、ルータＲ１に接続されているクライアントＣ１から輻輳しているサーバＳ１に対しての要求を受信すると、ルータＲ１のサーバ輻輳通知手段１６は、図２０のサーバの応答時間付きアクセス規制サーバデータ内の応答時間Ｔａを表示するＨＴＭＬ形式のドキュメントを生成し、現在のサーバ輻輳状態として、要求を行なったクライアントＣ１へ送信する（４０４）。
【０１０９】
この状況において、異なるクライアントＣ２からサーバＳ１に対する要求があった場合にも、サーバＳ１の応答時間ＴａをＨＴＭＬ形式のＷｅｂページとして生成し、クライアントＣ２へ通知する（４０５）。
【０１１０】
ルータＲ３のサーバ輻輳監視手段１１は、サーバＳ１の輻輳状態を検出すると、第１の実施の形態例で説明した方法により、サーバＳ１の輻輳状態を定期的に監視する（４０６）。サーバＳ１の応答時間が設定した閾値以上変化した場合、ルータＲ１のサーバ輻輳通知手段１６へ最新の応答時間を通知する（４０７）。ルータＲ１のサーバ輻輳通知手段１６は、保持しているサーバＳ１の応答時間を更新する。ルータＲ１が、クライアントＣ１からの要求を棄却する際には、サーバ輻輳通知手段１６が最新の応答時間Ｔｂをクライアントへ通知する（４０８）。
【０１１１】
ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳解除を検出すると（４０９）、ルータＲ１のサーバ輻輳通知手段１６へ輻輳解除を通知する（４１０）。ルータＲ１のサーバ輻輳通知手段１６は、管理している図２０のデータから、サーバＳ１のエントリを削除する。以降、クライアントＣ１からサーバＳ１に対する要求は転送される。
【０１１２】
以上説明した方法で、サーバ輻輳時に本発明のルータによってクライアントからの要求が規制された場合、要求を発生させた利用者にサーバの輻輳度合いに関する情報が通知されるので、ユーザはサーバの輻輳状態を認識することができ、時間をおいてリトライする（輻輳しない状況での無意味なリトライをやめる）のを促すことができ、サーバが輻輳している状況を緩和させることができる。
【０１１３】
図２１は本発明の第５の実施の形態例のネットワーク構成を示す図である。クライアントＣ１はルータＲ１に接続され、クライアントＣ２はルータＲ２に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間、及びルータＲ２とルータＲ３の間には更に複数のルータを経由してもよい。ルータＲ３は、図２のブロック図のサーバ輻輳履歴管理手段１７を具備する。
（サーバ輻輳時における履歴の記録）
クライアントＣ１がサーバＳ１へアクセスする状況において、ルータＲ３におけるサーバ輻輳監視手段１１が、サーバＳ１が輻輳状態に陥ったと判定した場合を考える。サーバＳ１の輻輳が検出されると、ルータＲ３の輻輳原因パケット廃棄要求手段１２によってクライアントＣ１に対してサーバＳ１の輻輳検出閾値等の情報を付加した輻輳通知メッセージが送信される。
【０１１４】
図２２は輻輳通知メッセージ例を示す図である。ＩＰヘッダは、ＩＰＤＡとして、クライアントＣ１のＩＰアドレスを設定し、ＩＰＳＡとして、ルータＲ３のＩＰアドレスを設定する。メッセージ識別子は、輻輳通知メッセージを表わす識別子である。サーバＩＰアドレスは、輻輳が発生したサーバＳ１のＩＰアドレスを示し、輻輳検出閾値はサーバＳ１が輻輳検出するための閾値である。
【０１１５】
通知を受け取ったルータＲ１では、「サーバ輻輳履歴データ」を参照し、過去にクライアントＣ１とサーバＳ１間の通信において輻輳が発生したかどうかを判定する。クライアントＣ１−サーバＳ１用の「サーバ輻輳履歴データ」が存在しない、つまりはじめての輻輳発生であれば、新規に「サーバ輻輳履歴データ」を作成し、受信した輻輳通知メッセージの情報を元にクライアントＣ１のＩＰアドレス、サーバＳ１のＩＰアドレス、輻輳検出閾値を「サーバ輻輳履歴データ」内に設定する。
【０１１６】
図２３はサーバ輻輳履歴データの構成例を示す図である。この図は、クライアントＣ１−サーバＳ１間のサーバ輻輳履歴データを示している。図に示すように、監視対象サーバと、要求発生クライアントと、輻輳検出閾値と、検出種別と、検出時刻から構成されている。
【０１１７】
次に、ルータＲ１が輻輳通知メッセージを受信した時刻を輻輳時刻として「サーバ輻輳履歴データ」内に記録する。２回目以降の輻輳発生時は、この輻輳時刻のみを「サーバ輻輳履歴データ」に追加していく。
（サーバ輻輳解除時における履歴の記録）
クライアントＣ１がサーバＳ１へアクセスする状況において、ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳を検出後、サーバＳ１の輻輳解除を検出した場合を考える。ルータＲ３がサーバＳ２の輻輳解除を検出すると、サーバ輻輳監視手段１１によってクライアントＣ１に対し輻輳解除通知メッセージが送信されるが、通知を受け取ったルータＲ１では、初回の輻輳時に生成されたクライアントＣ１−サーバＳ１用の「サーバ輻輳履歴データ」内に輻輳解除時刻を記録する。
【０１１８】
以降は、サーバで輻輳解除が検出される度にサーバ輻輳履歴管理手段１７が該当クライアント−サーバ間のデータ内に輻輳解除時刻を追加する。図２３にサーバ輻輳解除時におけるルータＲ１の「サーバ輻輳履歴データ」の例を示す。以上により、ルータＲ１ではサーバＳ１の情報や輻輳／輻輳解除時刻が「サーバ輻輳履歴データ」に記録される。
【０１１９】
また、サーバ輻輳履歴データの情報をルータＲ１のサーバ輻輳通知手段１６を用いてクライアントＣ１側へ転送することにより、クライアント側からの要求に応じてサーバＳ１の輻輳情報（クライアントＣ１とサーバＳ２のＩＰアドレス、輻輳発生／輻輳解除の回数・時刻、設定された輻輳閾値等）をクライアント側の画面に表示することができる。
【０１２０】
このように、アクセス対象となるサーバの履歴をユーザに提示することにより、そのサーバで輻輳発生が頻発する時間帯や輻輳の程度をユーザが知ることが可能になり、影響を受けない時間帯でのアクセスをユーザに促すことで未然にサーバの輻輳発生を防ぐことが可能となる。
【０１２１】
図２４は本発明の第６の実施の形態例のネットワーク構成を示す図である。図のルータＲ１は、図２のブロック図中の通信優先度決定手段１９を具備する。クライアントＣ１とクライアントＣ２とクライアントＣ３はルータＲ１に接続され、サーバＳ１はルータＲ３に接続されている。ルータＲ１とルータＲ３の間には更に複数のルータを経由してもよく、例えばＲ１−Ｒ２−Ｒ３のルートと、Ｒ１−Ｒ４−Ｒ３の２種類のルートが存在しているものとする。
【０１２２】
また、従来のトラフィックエンジニアリング技術により、Ｒ１−Ｒ２−Ｒ３のルート上には帯域保証されたパス（Ｐａｔｈ）１が設定されており、一方のＲ１−Ｒ４−Ｒ３のルート上には帯域保証のないベストエフォート（ＢｅｓｔＥｆｆｏｒｔ）なパス（Ｐａｔｈ）２が設定されているものとする。
【０１２３】
ここで、ルータＲ１のコマンドライン上等でフィルタ条件を設定することにより、ルータＲ１に入ってきたパケットが事前に設定されたフィルタ条件に合致すると、Ｐａｔｈ１やＰａｔｈ２のルート上へとパケットを転送することがトラフィックエンジニアリング機能を備えたルータでは可能となっている。設定できるフィルタ条件としては、ＩＰヘッダ内のＩＰＤＡ／ＩＰＳＡ／ＴＯＳ／プロトコル種別、ＴＣＰヘッダ内のポート番号等から任意のパラメータを指定可能である。
【０１２４】
図２５はルータＲ１におけるフィルタ条件設定の入力例を示す図である。▲１▼のコマンドは、クライアントＣ１（ＩＰアドレス＝ＸＸ．ＸＸ．ＸＸ．ＸＸ）からサーバＳ１（ＩＰアドレス＝ＹＹ．ＹＹ．ＹＹ．ＹＹ）宛のパケットを許容する条件に対し、“ｌｉｓｔ−１”という名前を付与している。▲２▼のコマンドは、クライアントＣ２（ＩＰアドレス＝ＺＺ．ＺＺ．ＺＺ．ＺＺ）からサーバＳ１（ＩＰアドレス＝ＹＹ．ＹＹ．ＹＹ．ＹＹ）宛のパケットを許容する条件に対し“ｌｉｓｔ−２”という名前を付与している。
【０１２５】
▲３▼のコマンドは、条件“ｌｉｓｔ−１”の内容に合致するパケットがルータＲ１に流れ込んだ場合は、Ｐａｔｈ１のルート上にパケットを転送するよう設定を行なっている。▲４▼のコマンドは、条件“ｌｉｓｔ−２”の内容に合致するパケットがルータＲ１に流れ込んだ場合は、Ｐａｔｈ２のルート上にパケットを転送するよう設定を行なっている。上記の設定が入力されると、ルータＲ１では、図２６に示すような「フィルタ条件データ」が作成される。
【０１２６】
図２６はルータＲ１におけるフィルタ条件データを示す図である。図に示すように、送信元ＩＰアドレスと、送信元マスクと、送信先ＩＰアドレスと、送信先マスクと、プロトコル種別と、ＴＯＳ値と、送信元ポート番号と、送信先ポート番号と、対応Ｐａｔｈから構成されている。
【０１２７】
既存のトラフィックエンジニアリング技術を用いた上記の条件で、クライアントＣ１とクライアントＣ２がサーバＳ１へアクセスする状況にある場合、サーバＳ１の輻輳時にルータＲ１の通信優先度決定手段１９がクライアントの優先度に従ってサーバＳ１宛のパケットの振る舞いを決定することができる。
【０１２８】
先ず、ルータＲ３のサーバ輻輳監視手段１１がサーバＳ１の輻輳を検出すると、輻輳原因パケット廃棄要求手段１２がルータＲ１に対して輻輳通知メッセージを送信する。そして、通知を受けたルータＲ１の輻輳原因パケット廃棄手段１３により廃棄対象となるクライアント（Ｃ１及びＣ２）が決定されるが、その際に輻輳原因パケット廃棄手段１３は通信優先度決定手段１９に問い合わせを行ない、ルータＲ１が保持しているフィルタ条件データと比較する。
【０１２９】
Ｐａｔｈ１のような帯域保証されたパスと関連付けられたクライアントＣ１は高優先、Ｐａｔｈ２のようなベストエフォートなパスと関連付けられたパスは中優先とみなし、これらは転送すべきパケットとして廃棄対象から外す。この結果、サーバＳ１が輻輳状態にある場合でも、クライアントＣ１及びＣ２からのパケットについてはルータＲ１で一律破棄を行なうのではなく、クライアントＣ１からのパケットは帯域保証されたＰａｔｈ１ルートに流し、クライアントＣ２からのパケットはベストエフォートなＰａｔｈ２ルートに継続して流すことが可能となる。
【０１３０】
但し、ルータＲ１配下に存在するＣ１とＣ２以外のクライアントは低優先とみなし廃棄対象となるため、例えばクライアントＣ３がサーバＳ１との通信を行おうとした場合は、ルータＲ１においてパケットは一律破棄される。
【０１３１】
また、優先クライアントの使用するパスについて、ルータの持つトラフィックエンジニアリング機能を利用し事前に迂回経路を設定しておけば、優先クライアントのパス上でノード／リンク障害が起きた場合でも、クライアント側で特に意識することなくサーバへ向けた転送を継続することができる。
【０１３２】
例えば、図２７に示すように、ルータＲ１とルータＲ３間にルータＲ５を経由するもう１本のパス“Ｐａｔｈ”３がされているとすると、ルータＲ１においてトラフィックエンジニアリング機能によりＰａｔｈ１の迂回経路としてＰａｔｈ３を設定しておけば、Ｐａｔｈ１で障害が発生した場合でも、瞬時にＰａｔｈ３へ切り替えることが可能であり、優先すべきクライアントについてパケットロスの影響なく通信可能となる。但し、迂回経路を設定しない場合は、ＯＳＰＦ等のルーティングプロトコルの優先経路に従ったベストエフォートな経路に従ったルートで転送される。
【０１３３】
このように、サーバの輻輳時に全クライアントのパケットを無作為に破棄するのではなく、トラフィックエンジニアリング機能を備えたルータの持つ、フィルタ条件に従ったパス選択機能と連携させることで、クライアント毎のパケットの扱いをルータ側できめ細かく制御することが可能となる。
【０１３４】
例えば、あるＷｅｂサイトを有するサーバで輻輳が発生した場合でも、ＩＳＰと優先サービスを契約した顧客に対してはアクセスを拒否することなく安定したサービスを料金に応じて段階的に提供するが、契約外の通常の顧客に対してはアクセス拒否を行なうといったサービスの差別化を、ルータを保有するＩＳＰ（インターネットサービス事業者）側で提供することが可能となる。
【０１３５】
例えば、ルータが１００台あり、各ルータに１０台ずつのサーバが接続されているネットワークがあり、この合計１０００台のサーバ輻輳回避及びこのネットワークの輻輳回避を行なう場合、１０００台のサーバに対して、輻輳回避に関する機能追加が必要であり、仮にルータと制御サーバの性能が同じだと仮定すると、１台の制御サーバで１０台の処理サーバの輻輳制御ができるとした場合、１００台の制御サーバが必要となる。
【０１３６】
ハードルーティングが可能なルータの場合、安定状態ではＣＰＵは空いているので、専用のプロセッサを積む必要はなく、制御サーバでできる程度の輻輳制御であれば、特にコストを上げずに既存のルータで実現できるため、１００台の制御サーバの費用＋１０００台の処理サーバに機能を盛り込むための費用が浮くことになる。
【０１３７】
本発明によれば、以下に示すような効果が得られる。
１．サーバ側に特別な機能を持つことなく、本発明のルータに接続されたサーバの輻輳回避が可能である。
２．サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳回避が可能である。
３．サーバを収容しているルータと、クライアントを収容しているルータが連携することで、ＷｅｂページのＵＲＬやＦＴＰのディレクトリ等の単位で輻輳制御を行ない、特定のサービスのみが輻輳している場合には、当該サービスのパケットのみを廃棄することで、サーバの輻輳を効果的に回避することが可能となる。
４．クライアント／サーバに特別な機能を持つことなく、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することが可能となる。
５．サーバ輻輳時に、ユーザが通信タイムアウトを持たずに、サーバ輻輳及びどのくらいの時間にサーバにアクセスすれば空いているか等の輻輳に関する情報を認識することで、ユーザの利便性を向上させることが可能となる。
６．サーバ側に特別な機能を持つことなく、ルータに収容されている全てのサーバの輻輳履歴を集中管理することが可能となる。
７．ＩＳＰ等の多数のサーバが接続されたネットワークにおいて、従来技術のようにアクセス制御サーバが全サーバの輻輳を監視し、クライアントが接続された多数のルータに対してフィルタを設定するためには、サーバ数、ネットワーク規模に応じた多数のアクセス制御サーバが必要となるが、本発明ではルータのみの導入で輻輳制御が実現可能である。
８．ハードルーティングを行なうルータの場合、安定動作中のＣＰＵは殆ど動作していないが、アクセス制御サーバと同様の処理をルータのソフトウェアで実現することで、ルータのＣＰＵを有効利用し、ＩＳＰ等の大規模ネットワークにおける全体のコストを低く抑えることが可能である。
９．本発明の輻輳制御をルータのハード機能で実現することにより、アクセス制御サーバのソフトウェアで実現する場合に比較して、けた違いに多数のサーバを１台のルータで制御することが可能である。
１０．ルータ側にクライアント毎の優先度を設定しておくことにより、輻輳したサーバへの通信を行なうクライアントに対し、入側ルータでの廃棄対象とするか、帯域制御により回線帯域を制限するか、迂回経路を使用するか、等の提供サービスの差別化を行なうことが可能である。
【０１３８】
（付記１）サーバとクライアントが設置されるネットワークシステム上のルータであって、
ＬＡＮフレームを受信するＬＡＮフレーム受信部と、該ＬＡＮフレーム受信部の出力を受けて帯域制御や迂回経路を設定するトラフィックエンジニアリング制御部と、該トラフィックエンジニアリング制御部の出力を受けてルーティング処理を行なうルーティング処理部と、該ルーティング処理部の出力を受けてＬＡＮフレームを送信するＬＡＮフレーム送信部とを具備するものにおいて、
前記各構成要素と接続され、サーバの輻輳を検出すると共に、サーバの輻輳を検出したら、サーバの輻輳制御を行なうサーバ輻輳制御手段
を設けたことを特徴とするネットワーク及びサーバの負荷低減ルータ。
【０１３９】
（付記２）サーバ宛のパケットの応答遅延を監視してサーバの輻輳を自動的に検出するサーバ輻輳監視手段と、
サーバの輻輳／輻輳解除検出時に、輻輳原因となっているパケットの廃棄／中継を、クライアントを収容するルータに対して要求する輻輳原因パケット廃棄要求手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする付記１記載のネットワーク及びサーバの負荷低減ルータ。
【０１４０】
（付記３）サーバを収容しているルータで、輻輳しているサーバのサービスを特定する輻輳サービス特定手段と、クライアントを収容しているルータで、輻輳しているサーバのサービスに関するパケットのみを廃棄する輻輳原因パケット廃棄手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４１】
（付記４）クライアント−サーバ間のパケットを監視し、サーバ−クライアント間のパケット通信量や最終通信時刻等の統計情報を記録する通信統計記録手段と、サーバ輻輳時に、クライアントを収容するルータに対してパケット廃棄を要求する時に、新たに通信を開始するクライアントや通信量が規定量を超えているクライアントのパケット通信を制限するクライアントを決定する通信制御クライアント決定手段とを前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４２】
（付記５）サーバの輻輳検出時に、輻輳原因となるパケットを廃棄すると同時に、クライアントに対してサーバ輻輳を通知するサーバ輻輳通知手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４３】
（付記６）サーバ輻輳の履歴を管理するサーバ輻輳履歴管理手段を前記サーバ輻輳制御手段内に設け、前記サーバ輻輳通知手段により輻輳履歴情報をクライアントに通知することを特徴とする付記５記載のネットワーク及びサーバの負荷低減ルータ。
【０１４４】
（付記７）優先／非優先にすべきクライアントの持つクラスを事前に設定し、そのクラスに応じたパケットに対する挙動を決定する通信優先度決定手段を前記サーバ輻輳制御手段内に設けたことを特徴とする付記２記載のネットワーク及びサーバの負荷低減ルータ。
【０１４５】
【発明の効果】
以上、説明したように、本発明によれば、以下のような効果が得られる。
（１）請求項１記載の発明によれば、サーバの輻輳を検出したサーバ輻輳制御手段１０は、サーバの輻輳制御を行なって、サーバの輻輳を低減することができる。
（２）請求項２記載の発明によれば、サーバ側に機能を持つことなく、ルータに収容された全てのサーバの輻輳回避を行なうと同時に、サーバ輻輳時のクライアントからのリトライによるネットワーク輻輳を回避することができる。
（３）請求項３記載の発明によれば、輻輳原因となっているパケットを、宛先サーバのアドレスやプロトコルで識別するだけでなく、ＷｅｂページのＵＲＬやＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ：ＴＣＰ／ＩＰで用いられるファイル転送プロトコル）のディレクトリ等の輻輳しているサービスに関するパケットのみの廃棄を可能とすることができる。
（４）請求項４記載の発明によれば、特定のクライアントのみの通信を規制することを可能とし、パケットを無作為に廃棄することによるサービス中断を防止し、輻輳原因となっている通信を効果的に規制することができる。
（５）請求項５記載の発明によれば、ユーザが通信タイムアウトを持たずサーバ輻輳及び輻輳に関する情報を認識することを可能とし、ユーザの利便性を向上させることができる。
【０１４６】
このように、本発明によれば、ルータに収容される全てのサーバに対して、サーバ側に特殊な機能を盛り込むことなく、自動的にサーバの輻輳を検出することができ、クライアントを収容するルータと連携することで、サーバ及びネットワーク全体の輻輳回避が容易に実現することができるネットワーク及びサーバの負荷軽減ルータを提供することができる。
【図面の簡単な説明】
【図１】本発明の原理ブロック図である。
【図２】本発明の第１一実施の形態例を示すブロック図である。
【図３】本発明の第１の実施の形態例のネットワーク構成を示す図である。
【図４】本発明の第１の実施の形態例の動作を示すシーケンス図である。
【図５】サーバ輻輳状態監視データの例を示す図である。
【図６】輻輳通知メッセージの例を示す図である。
【図７】輻輳通知メッセージ管理データの例を示す図である。
【図８】アクセス規制サーバデータの例を示す図である。
【図９】輻輳解除通知メッセージの例を示す図である。
【図１０】本発明の第２の実施の形態例のネットワーク構成を示す図である。
【図１１】本発明の第２の実施の形態例の動作を示すシーケンス図である。
【図１２】ＵＲＬ毎のサーバ輻輳状態監視データの例を示す図である。
【図１３】ＵＲＬ指定の輻輳通知メッセージの例を示す図である。
【図１４】本発明の第３の実施の形態例のネットワーク構成を示す図である。
【図１５】本発明の第３の実施の形態例を示すシーケンス図である。
【図１６】クライアント要求状態監視データの例を示す図である。
【図１７】本発明の第４の実施の形態例のネットワーク構成を示す図である。
【図１８】本発明の第４の実施の形態例の動作を示すシーケンス図である。
【図１９】サーバの対応時間付き輻輳通知メッセージの例を示す図である。
【図２０】サーバの応答時間付きアクセス規制サーバデータの例を示す図である。
【図２１】本発明の第５の実施の形態例のネットワーク構成を示す図である。
【図２２】第５の実施の形態例における輻輳通知メッセージ例を示す図である。
【図２３】サーバ輻輳履歴データの構成例を示す図である。
【図２４】本発明の第６の実施の形態例のネットワーク構成を示す図である。
【図２５】ルータＲ１におけるフィルタ条件設定の入力例を示す図である。
【図２６】ルータＲ１におけるフィルタ条件データを示す図である。
【図２７】転送ルートの障害切り替え動作例を示す図である。
【図２８】ルータの概念図である。
【図２９】従来のルータの概念を示すブロック図である。
【図３０】ＬＡＮフレーム受信部、ＬＡＮフレーム送信部、ルーティング処理部の説明図である。
【図３１】トラフィックエンジニアリング制御部の説明図である。
【符号の説明】
１ＬＡＮフレーム受信部
２トラフィックエンジニアリング制御部
３ルーティング処理部
４ＬＡＮフレーム送信部
１０サーバ輻輳制御手段[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a network and server load reduction router, and more particularly, in a situation where access to a server is delayed due to server congestion when using a client-server service installed on the Internet or an intranet. The present invention relates to a router that avoids network congestion due to inadvertent access retries to a server, reduces the load on the server, and quickly recovers the server congestion state.
[0002]
[Prior art]
A router is a device that routes network packets at the network layer. In the data link layer, data can be transmitted only between adjacent nodes or on the same segment, but the router is in charge of data transfer between all nodes on the network by combining data transfer functions in the data link layer. A router usually has a fixed protocol that can be routed. FIG. 28 is a conceptual diagram of a router. In the figure, NW1 to NW3 are networks, C1 to C3 are lines connecting the networks, and R1 to R3 are routers connected to the lines C1 to C3. A line interface INT is provided between the routers R1 to R3 and the lines C1 to C3. The routers R1 to R3 have a plurality of line interfaces INT to connect the networks, and output packets received from the line interfaces INT to appropriate lines C1 to C3 according to destinations.
[0003]
FIG. 29 is a diagram illustrating the concept of a conventional router. This router is arranged between the client and the server and has a function of controlling data transmission / reception between the client and the server. In the figure, 1 is a LAN frame receiving unit that receives a LAN frame, 2 is a traffic engineering control unit that receives the output of the LAN frame receiving unit 1 and sets bandwidth control and a detour path, and 3 is a traffic engineering control unit 2 A routing processing unit 4 that receives the output and performs a routing process is a LAN frame transmission unit 4 that receives the output of the routing processing unit 3 and transmits a LAN frame.
[0004]
FIG. 30 is an explanatory diagram of a LAN frame receiving unit, a LAN frame transmitting unit, and a routing processing unit. The same components as those in FIGS. 28 and 29 are denoted by the same reference numerals. The LAN frame receiving unit 1 receives a packet from the line interface INT. The received packet enters the routing processing unit 3. The routing processing unit 3 exchanges routing information by exchanging control messages between routers, and has routing information such as “what route is ahead of which line”. A routing information database 5 stores routing information. For the packet received by the LAN frame receiving unit 1, the routing processing unit 3 determines the outgoing line interface INT corresponding to the destination, and transmits the packet to the LAN frame transmitting unit 4 of the outgoing line.
[0005]
FIG. 31 is an explanatory diagram of the traffic engineering control unit. The same components as those in FIGS. 28 and 29 are denoted by the same reference numerals. A normal router transfers a packet according to routing information. In a router having a traffic engineering function, for example, when there are a plurality of output interfaces for a packet destination address, the following control is performed.
・ Distribute the output interface for each packet to distribute the bandwidth evenly.
-Output to a specific interface from among multiple output interface candidates.
-Control the output interface bandwidth and control the output interface distribution so that each interface uses only the specified bandwidth. The above-described operation of the traffic engineering control unit 2 is set by command input. Thereafter, when the router receives the packet, the routing processing unit searches the route, determines the output interface in cooperation with the traffic engineering control unit 2, and outputs the packet to the line.
[0006]
In current client-server network systems such as WWW and FTP, when requests to a specific server are concentrated, processing of the server occurs and the response from the server to the client is delayed. Suspending access and retrying access to the server further increases the demands on the server, increasing traffic in the network system, increasing the server load, and causing further processing congestion on the server There is.
[0007]
In order to eliminate server processing congestion, a method is widely used in which a plurality of servers are installed and the server load is distributed to improve server processing capability and to eliminate server-side congestion. However, this solution by adding a server increases the cost burden on the server installer. Furthermore, in an actual network, there are already multiple servers, and in order to eliminate the processing congestion of each server, it is necessary to introduce additional servers for each server. The number of servers to be added further increases, and the cost for adding servers increases.
[0008]
In addition, there are some servers that are difficult to perform distributed processing to maintain data consistency depending on the use of the server, such as a ticket lottery system or a multi-user game application using a network, and a method of distributing the load by increasing the number of servers There are some areas where it is not possible to take
[0009]
There is a technique for improving the service of a user by preventing the occurrence of disconnection during use (see, for example, Patent Document 1). In addition, there is a technique for detecting traffic congestion so as to prevent excessive traffic from flowing (see, for example, Patent Document 2). In addition, there is a technique in a server / client system that suppresses client requests when the server is congested (see, for example, Patent Document 3). Further, there is a technique for deterring client requests by performing reception / access control / service and server function division in a server / client system (see, for example, Patent Document 4).
[0010]
[Patent Document 1]
JP 2001-320423 A (4th page, 5th page, FIG. 1)
[Patent Document 2]
JP 2001-345861 A (page 3, page 4, FIG. 1)
[Patent Document 3]
JP 2001-67314 A (Page 4, Page 5, FIG. 1)
[Patent Document 4]
JP 2002-141936 A (5th and 6th pages, FIG. 1)
[0011]
[Problems to be solved by the invention]
The invention described in Patent Document 1 improves service for users in use by giving identifiers of “start”, “continue”, and “end” to service components and rejecting “start” requests during congestion. . However, since this method needs to give an identification to a service component, there is a problem that it is necessary to process content, and that this method cannot be applied to a service that is already in operation.
[0012]
The invention described in Patent Document 2 dynamically changes the packet queue length when the network is congested, thereby reducing the load on the network. In addition, it also has a proxy server function, and access to a specific WWW server can be prohibited. However, it does not have a function of controlling access to the server by detecting server congestion.
[0013]
In the invention described in Patent Literature 3, the server controls retry suppression for the client (user terminal). However, when the server is congested and the processing load is very high, if control is performed to suppress requests to individual clients, the load on the server itself further increases until the congestion is released against the network load. The time will be very long. Also, the server / client application needs to support this method.
[0014]
In the invention described in Patent Document 4, the service providing server, the receiving server, and the access control server share roles, and the access control server performs filtering setting on the router. However, in this method, it is necessary to incorporate functions on the server side, and it is difficult to avoid congestion for an unspecified number of servers connected to the network. In addition, the access control server needs to recognize the router that accommodates the client, and the server needs to know commands for executing filter-related processing in the router, which makes management complicated.
[0015]
As described above, the client / server application does not have a special function in the conventional technology in a state in which further server congestion occurs due to repeated access retries by the user on the congested server. As long as the retry to the server is not suppressed, the server load cannot be reduced, and unnecessary traffic flows into the network.
[0016]
The present invention has been made in view of such problems, and automatically detects server congestion without incorporating any special functions on the server side for all servers accommodated in the router. An object of the present invention is to provide a network and server load reduction router that can easily avoid congestion of the server and the entire network by cooperating with a router that accommodates clients.
[0017]
[Means for Solving the Problems]
In the present invention, the inflow traffic of the client is controlled by the router that can dynamically control the network traffic itself, so that the existing server / client itself does not require any special processing for congestion control. It is possible to control the flow of user requests for the server itself into the network while maintaining the server / client of the server, reducing the network load and improving the processing efficiency of the congested server.
[0018]
In addition, since the control is performed by the router, there is an advantage that the additional input cost of the entire system including the network and the change of the system construction can be extremely reduced. In order to monitor IP packets with a normal server, it is necessary to add hardware for realizing high-speed network processing to the server so as not to deteriorate the network transfer speed. In order to realize this control in the router that inspects the contents of the IP packet at high speed without deteriorating the transfer speed of the network, it is not necessary to add any special hardware, and to the IP packet transfer processing unit of the router. This is because it can be realized only by adding processing.
[0019]
In addition, the control between the client and the server can only avoid congestion of the client / server itself to which the software is applied. However, by introducing a router equipped with this function, traffic engineering (Traffic) according to the priority of each client. It is possible to avoid congestion as a whole network by performing (Engineering) control. . Figure 1 is a block diagram showing the principle of the present invention. The same components as those in FIG. 29 are denoted by the same reference numerals. In the figure, 1 is a LAN frame receiving unit that receives a LAN frame, 2 is a traffic engineering control unit that receives the output of the LAN frame receiving unit 1 and sets bandwidth control and a bypass circuit, and 3 is a traffic engineering control unit 2 A routing processing unit 4 that receives the output and performs a routing process is a LAN frame transmission unit 4 that receives the output of the routing processing unit 3 and transmits a LAN frame.
[0020]
A server congestion control unit 10 is connected to the LAN frame receiving unit 1, the traffic engineering control unit 2, and the LAN frame transmitting unit 4 to detect server congestion and to control server congestion when server congestion is detected. .
[0021]
If comprised in this way, the server congestion means 10 which detected server congestion can perform server congestion control, and can reduce server congestion.
( 1 Claim 1 The described invention A router on a network system in which a server and a client are installed, a LAN frame receiving unit that receives a LAN frame, and a traffic engineering control unit that sets a bandwidth control and a detour route by receiving an output of the LAN frame receiving unit; A routing processing unit that receives the output of the traffic engineering control unit and performs a routing process; and a LAN frame transmission unit that receives the output of the routing processing unit and transmits a LAN frame. Connected to detect server congestion, and when server congestion is detected, server congestion control means for controlling server congestion is provided, Server congestion monitoring means that automatically detects server congestion by monitoring the response delay of packets addressed to the server, and discard / relay of packets that cause congestion when server congestion / decongestion is detected A congestion cause packet discard requesting means for requesting the router to be provided is provided in the server congestion control means.
[0022]
With this configuration, it is possible to avoid congestion of all servers accommodated in the router without functioning on the server side, and at the same time, avoid network congestion due to retries from clients when the server is congested.
( 2 Claim 2 In the described invention, a congestion service specifying means for specifying a service of a congested server at a router accommodating a server and a packet relating to a service of a congested server at a router accommodating a client are only received. Congestion cause packet discarding means for discarding is provided in the server congestion control means.
[0023]
With this configuration, the packet causing the congestion is not only identified by the address and protocol of the destination server, but also the URL of the Web page and FTP (File Transfer Protocol: file transfer protocol used in TCP / IP). It is possible to discard only packets related to a congested service such as a directory.
( 3 Claim 3 The described invention includes a communication statistics recording means for monitoring a packet between a client and a server and recording statistical information such as a packet communication amount between the server and a client and a last communication time, and a router accommodating the client at the time of server congestion. A communication control client determining means for determining a client for newly starting communication and a client for restricting packet communication of a client whose communication volume exceeds a specified amount when requesting packet discarding in the server congestion control means. It is characterized by being provided in.
[0024]
If configured in this way, it is possible to regulate communications only for specific clients, prevent service interruption by randomly discarding packets, and effectively regulate communications that cause congestion. Can do.
( 4 Claim 4 The described invention is characterized in that server congestion notification means for notifying a client of server congestion at the same time as discarding a packet that causes congestion when server congestion is detected is provided in the server congestion control means.
[0025]
If comprised in this way, it will become possible for a user to recognize the information regarding server congestion and congestion, without having communication timeout, and a user's convenience can be improved.
[0026]
The present invention is characterized in that server congestion history management means for managing server congestion history is provided in the server congestion control means, and the congestion history information is notified to the client by the server congestion notification means.
[0027]
With this configuration, the server congestion notification means notifies the client of the congestion history information, so that the convenience of the user can be improved without requiring a special function on the server side.
[0028]
In the present invention, the server congestion control means includes a communication priority determining means for setting in advance a class of a client to be prioritized / non-prioritized and determining a behavior for a packet corresponding to the class. It is characterized by.
[0029]
With this configuration, it is possible to control priority connections and the like using traffic engineering control (performing appropriate discarding based on bandwidth control or an appropriate detour route or weight).
[0030]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 2 is a diagram showing a network configuration according to an embodiment of the present invention. The same components as those in FIG. 1 are denoted by the same reference numerals. In the figure, 11 is a server congestion monitoring unit connected to the LAN frame receiving unit 1 and the LAN frame transmitting unit 4, 12 is a congestion cause packet discard requesting unit connected to the LAN frame transmitting unit 4 and the server congestion monitoring unit 11, Is a congestion cause packet discarding means connected to the LAN frame receiving unit 1.
[0031]
14 is a communication statistics statistics recording means connected to the LAN frame receiver 1, 15 is a communication restriction client determination means connected to the congestion cause packet discard means 13, the communication statistics recording means 14 and the congestion cause packet discard request means 12, 16 Is a server congestion notifying unit connected to the congestion cause packet discarding unit 13, the LAN frame transmitting unit 4 and the congestion cause packet discard requesting unit 12, 17 is a server congestion history managing unit connected to the server congestion monitoring unit 11, and 18 is a server Congestion service specifying means 19 connected to the congestion monitoring means 11, 19 is a communication priority determining means connected to the traffic engineering control unit 2, congestion cause packet discarding means 13 and communication restriction client determining means 15. Hereinafter, these components will be described in detail.
(Server congestion monitoring means 11)
For a server connected to the router, a delay time of a response from the server to a request from a client is monitored to detect a server congestion state.
(Congestion cause packet discard request means 12)
When server congestion is detected, the router accommodating the client is requested to discard the packet causing the congestion. This function uses the filter function of the router that accommodates the client and uses a command line interface to register / delete a filter based on the IP address or TCP port number of a congested server. It is feasible.
[0032]
In addition, since the router that accommodates the client has the congestion cause packet discarding means 13, for example, detailed designation such as discarding only a packet addressed to a specific URL of a congested server is possible.
[0033]
In addition, as a method for identifying the router that accommodates the client, the router that accommodates the client is automatically recognized by using route information such as OSPF / BGP that the router has for the original relay function. It is also possible. Here, OSPF is an abbreviation for Open Shortest Path First, and BGP is an abbreviation for Border Gateway Protocol, both of which are Internet routing protocols.
(Congestion cause packet discarding means 13)
Upon receiving a request from the congestion cause packet discard request means 12 of the router accommodating the server, the discard / relay of the designated packet is controlled.
(Communication statistics recording means 14)
The communication between the client and the server is monitored, and statistical information such as the packet communication amount from the server to the client and the last communication time from the client to the server is recorded.
(Communication restriction client decision means 15)
When the server is congested, information collected by the communication statistics recording unit 14 is referred to, and a client for restricting communication is determined in order to avoid server congestion and network congestion. By setting a client whose last communication time is older than a threshold as a target of restriction, it is possible to remove a client that is continuing communication from the target of restriction.
[0034]
In addition, by restricting only clients whose traffic from the server to the client is larger than the threshold, clients that cause server and network loads such as downloading a large amount of images and music data for a long time. It is also possible to apply restrictions only to these.
(Server congestion notification means 16)
When the server is congested, not only is the packet discarded, but the client is notified of the server congestion. As a notification method, there is a method of transmitting an error notification packet corresponding to the other party busy according to each protocol to the client instead of the server. For example, in the case of HTTP (Hyper Text Transfer Protocol: protocol used in WWW), an HTML (Hyper Text Markup Language: language system used in the Web page) image of the Web page displaying the degree of server congestion is transmitted to the client. It is also possible to do.
[0035]
Further, by transmitting the server congestion history of the server congestion history management means 17 to the client, the user can determine how long it takes to access the server and that the congestion state is likely to be avoided. Is possible.
(Server congestion history management means 17)
The server congestion monitoring means 11 performs history management of the congestion information of the server monitored.
(Congestion service specifying means 18)
As part of the server congestion monitoring means 11, by monitoring the response delay time of the server in units of HTTP URLs, FTP (File Transfer Protocol) directories, etc., not the server unit but the server part unit The congestion is monitored, and when congestion is detected, identification information of the congestion part is passed to the congestion cause packet discard requesting means 12 and notified to the congestion cause packet discarding means 13 of the router accommodating the client.
(Communication priority determination means 19)
By setting the priority of the client in advance for the router accommodating the client, even if the client is discarded by the congestion cause packet discarding means 13, the bandwidth control or the best A traffic engineering service such as detouring to an effort (Best Effort) route is determined and a processing request is made to the traffic engineering control unit 2 to avoid congestion of the entire network.
(A) Outline of operation of the first embodiment (corresponding to claim 2)
The server congestion monitoring means 11 of the router accommodating the server (outgoing router) constantly monitors the delay time of the response from the server to the packet addressed to the server, and if the delay time exceeds a predetermined congestion threshold, Consider congestion. The congestion cause packet discard requesting means 12 identifies the router (incoming router) that accommodates the client when the server is congested, and designates the IP address and TCP port number of the server that detected the congestion for the router. To make a filter setting request.
[0036]
The server congestion monitoring unit 11 that has detected the server congestion continues to monitor the server, and considers the server congestion to be released when the response delay time has cut the congestion release threshold. The congestion cause packet discard request unit 12 cancels the filter set in the ingress router at the time of congestion when the server congestion is released.
[0037]
Accordingly, it is possible to avoid congestion of all servers accommodated in the router without having a function on the server side, and to avoid or reduce network congestion due to a retry from the client when the server is congested.
(B) Outline of operation of the second embodiment (corresponding to claim 3)
As a part of the server congestion monitoring unit 11, the congestion service specifying unit 18 of the outgoing router monitors the response delay time of the server in units of Web page URL, FTP directory, and the like. The packet discard request unit 12 notifies the congestion cause packet discard unit 13 of the incoming router together with the congestion information of the congestion service.
[0038]
The congestion cause packet discarding means 13 of the ingress router discards the packet causing the congestion based on filter conditions such as a destination IP address, a TCP (Transfer Control Protocol) port number, and a congested URL.
[0039]
This makes it possible to discard packets using special filtering conditions that are not supported by ordinary routers. For example, only a service with a specific URL implemented on the same server is congested. In this case, it is possible to perform fine congestion control such as discarding only the packet addressed to the URL and efficiently avoid server congestion.
(C) Outline of operation of the third embodiment (corresponding to claim 4)
In the ingress router or egress router, the communication statistics recording means 14 monitors the communication between the client and the server, and monitors the server congestion specified by the transmission source IP address, the destination IP address, the TCP port number, etc. Record statistical information such as packet traffic and last communication time.
[0040]
When the server is congested, the congestion cause packet discard requesting means 12 of the outgoing router or the congestion cause packet discarding means 13 of the incoming router inquires of the communication restriction client determining means 15 to determine a client for restricting communication, and the determined client Packet discard only for.
[0041]
When the client is determined, the communication restriction client determination unit 15 makes an inquiry to the communication statistics recording unit 14 to refer to the last communication time, and the difference between the last communication time and the time of congestion is greater than a predetermined threshold time. The packet communication amount exceeding the specified amount is determined as the target of communication restriction.
[0042]
As a result, it is possible to prevent service interruption caused by randomly discarding packets and to effectively restrict communication that causes congestion.
(D) Outline of operation of the fourth embodiment (corresponding to claim 5)
When the server is congested, the congestion cause packet discard requesting means 12 of the outgoing router or the congestion cause packet discarding means 13 of the incoming router requests the server congestion notification means 16 for server congestion notification.
[0043]
The server congestion notification means 16 replaces the server and notifies the client of information related to server congestion and congestion by transmitting an error notification packet according to each protocol or an HTML image of an HTTP Web page to the client.
[0044]
As a result, it is possible to recognize server congestion without waiting for a communication timeout, and how much time the server is accessed before the congestion is released, thereby improving user convenience. It becomes possible.
(E) Fifth embodiment
The server congestion history management means 17 of the outgoing router manages the history of server congestion recognized by the server congestion monitoring means 11. This information can be read by the network administrator using an operation command of the router, and the server user refers to the server by notifying the client when the server is congested by the server congestion notifying unit 16. It is also possible.
[0045]
As a result, the server can be centrally managed, and the user can recognize the congestion history of the server without requiring any special function on the server side.
(F) Sixth embodiment
The communication priority determination means 19 of the ingress router receives the request from the congestion cause packet discard request means 12 of the router that accommodates the server, and among the clients to be discarded determined by the congestion cause packet discard means 13, the source IP A search is performed as to whether or not there is a client that satisfies a priority condition set in advance by an address, a destination IP address, a TCP port number, or the like.
[0046]
For clients that meet the priority conditions, use of traffic engineering to limit the bandwidth used, bypass the best effort route, etc., thereby avoiding server congestion and congestion on the network. Can be avoided.
[0047]
The following describes an example of detecting congestion of a Web server widely used as a client server type application and reducing the congestion of the Web server and the network by using the present invention.
[0048]
FIG. 3 is a diagram showing a network configuration according to the first embodiment of the present invention. The client C1 is connected to the router R1, the client C2 is connected to the router R2, and the server S1 and the server S2 are connected to the router R3. A plurality of routers may be further routed between the router R1 and the router R3 and between the router R2 and the router R3. A first embodiment in this network configuration will be described with reference to FIG.
[0049]
FIG. 4 is a sequence diagram showing the operation of the first exemplary embodiment of the present invention. The same components as those in FIG. 3 are denoted by the same reference numerals. C1, C2 are clients, R1, R2, R3 are routers, and S1, S2 are servers. The routers R1 and R2 in FIG. 3 include the server congestion monitoring unit 11 and the congestion cause packet discarding unit 13 in FIG. 2, and the router R3 includes the server congestion monitoring unit 11, the congestion cause packet discard requesting unit 12, and the congestion cause in FIG. Packet discard means 13 is provided.
(Congestion detection method)
In a situation where the client C1 accesses the server S1, the packet from the client C1 to the server S1 is relayed, and the router R3 connected to the server S1 receives the IP packet of the request message 101 by the LAN frame receiving unit 1 and monitors the server congestion. The contents of the received IP packet are notified to the means 11. Further, in the router R3, the response message 101 from the server S1 to the client C1 is also received by the LAN frame receiving unit 1, and the contents of the IP packet are notified to the server congestion monitoring means 11.
[0050]
The server congestion monitoring unit 11 determines whether the IP packet is HTTP. The protocol can be discriminated by referring to the port number in the IP packet (TCP No. 80 for HTTP and TCP No. 21 for FTP). The server congestion monitoring unit 11 further determines whether the HTTP IP packet is an HTTP request message or a response message, and measures the response time of the request message 101 and the response message 101.
[0051]
Since HTTP exchanges protocol messages in text format, request messages and response messages can be discriminated by referring to the contents of HTTP packets. In a router used in a carrier network as an object of the present invention, a network processor (Network Processor: a processor that specializes in network processing and can program packet transfer operations. Usually, IP packet transfer processing such as Gigabit Ether is used. In most cases, the IP packet transfer method can be performed in hardware, and the IP packet transfer capability is not deteriorated by adding a network processor program. Can be realized. A router that implements IP packet transfer in hardware using an ASIC (application specific IC) can be implemented by adding logic to the ASIC.
[0052]
The server congestion monitoring unit 11 creates “server congestion state monitoring data” as HTTP response time data corresponding to the combination of the client IP address and the server IP address. FIG. 5 is a diagram illustrating an example of server congestion state monitoring data. This figure shows response time data when the client C1 and the client C2 make a request to the server S1, and the client C1 makes a request to the server S2. In the figure, a monitoring target server, a request generation client, a request time, a current time, an elapsed time after request transmission, and a congestion detection threshold are shown. This figure shows response time data when the client C1 and the client C2 make a request to the server S1, and the client C1 makes a request to the server S2.
[0053]
In addition, since this data is intended to detect server congestion, it does not create a “server congestion monitoring data” entry for all clients for one server, and does not create an entry between the client and server for each server. Response time may be measured by sampling communication.
[0054]
The server congestion monitoring unit 11 monitors the response time of FIG. 5 and if the response from the server S1 to the request transmitted from the client C1 to the server S1 is not within the time set as the congestion detection threshold in advance, It is determined that S1 is in a congestion state. As shown in FIG. 3, when there are a plurality of servers in the network, monitoring may be performed by applying the same threshold value to all servers, or different threshold values may be set for each server. Incidentally, in the case of FIG. 5, the elapsed time response after request transmission is 500 msec, whereas the threshold is 1000 msec, and no congestion occurs.
[0055]
Here, the response time for the request is used as a criterion for determining the server's congestion state. However, if the correspondence of the server load to the network load is known in advance, the server S1 is addressed within the specified time instead of the server response time. Alternatively, the number of packets passing through the router R3 may be used. Usually, since the router collects the number and size of transferred packets as statistical information, it can be realized without adding a special device to the router and without deteriorating the transfer rate of the IP packet.
[0056]
In a state where the server congestion monitoring unit 11 has not detected server congestion, the server congestion monitoring unit 11 notifies the received request message 101 to the routing processing unit 3, and the routing processing unit 3 executes the IP routing process. The request 101 is transmitted from the LAN frame transmission unit 4 to the server S1. Thereby, the client C1 can access the server S1.
(Operation during congestion)
When the server congestion monitoring unit 11 of the router R3 detects congestion on the request 102 from the client C1 to the server S1, the server congestion monitoring unit 11 of the router R3 transmits a rejection message 102 to the client C1. Further, the server congestion monitoring means 11 of the router R3 notifies the congestion cause packet discard requesting means 12 of the router R3. If the IPSA (IP Source Address) and IPDA (IP Destination Address) of the IP packet in which the HTTP request times out are notified as the information to be notified, the IP address of the client C1 and the IP address of the server S1 can be known from this information.
[0057]
The congestion cause packet discard requesting means 12 of the router R3 transmits a congestion notification message 103 to the router R1 connected to the client C1. The congestion notification message is a message exchanged between routers having the function of the present invention, and stores the IP address of a server that restricts access.
[0058]
When the congestion notification message 103 is transmitted from the router R3 to the router R1, it is transmitted as an IP packet from R3 to R1, but the IP packet information from the original client C1 to the server S1 does not include the IP address of the router R1. The router R3 does not know the IP address of the router R1 only from the information of the IP packet being transferred.
[0059]
In this case, when the congestion notification message 103 from the router R3 to the router R1 is transmitted as an IP packet, the IP address of the client C1 already known as IPDA is set, and OSPF / BGP etc. held by the router R3 Is transmitted to the client C1 through an appropriate route based on the routing information.
[0060]
Depending on the routing protocol used in the network, the IP address of the router R1 may be known. For example, in the case of OSPF, the router R3 can know that the loopback address of the router advertising the network prefix to which the client C1 belongs is the IP address of the router R1. In this case, if the congestion notification message is transmitted by directly specifying the IP address of the router R1 from the router R3, the processing of the router R1 can be omitted.
[0061]
FIG. 6 is a diagram showing an example of the congestion notification message in this example. As shown in the figure, the congestion notification message is composed of an IP header, a message identifier, and a server IP address. In the IP header, the address of the client C1 is set as IPDA, and the IP address of the router R3 is set as IPSA. The message identifier is an identifier representing a congestion notification message. The server IP address indicates the IP address of the server S1 where congestion has occurred.
[0062]
The congestion cause packet discard requesting means 12 of the router R3 that has transmitted the congestion notification message 103 holds, as congestion notification message management data, to which client the congestion notification message is sent to which server.
[0063]
Here, the router grasps the connection status (topology) of the network to which the router is connected by a dynamic routing protocol such as OSPF or BGP. Therefore, the routing information indicates that the network to which the client registered in the congestion notification message management data in FIG. 7 belongs becomes unreachable (due to disconnection or the like) or is reachable again. You can know more.
[0064]
A client that cannot reach a congestion release notification, which will be described later, on the network by controlling the validity / invalidity of the client registered in the congestion notification message management data shown in FIG. And no unnecessary traffic is generated on the network. FIG. 7 shows that the congestion notification message management data includes a monitoring target server, a request generation client, a congestion notification state, and a client state.
[0065]
The router R1 that has received the congestion notification message 103 addressed to the client C1 refers to the routing information held by the routing protocol such as OSPF / BGP, and the congestion cause packet discarding means 13 of the router R1 has received it. It is detected that the message is a congestion notification message for the client C1 to be connected.
[0066]
When the received congestion notification message 103 is addressed to the client C1, the router R1 terminates itself without transferring the congestion notification message to the client C1 because there is no further router ahead. Further, the router R1 confirms the content of the congestion notification message 103, recognizes that access to the server S1 is restricted, and notifies the congestion cause packet discarding means 13 in the router R1 of the IP address of the server S1. .
[0067]
The congestion cause packet discarding means 13 of the router R1 registers the IP address of the server S1 in the “access restriction server data” shown in FIG. Thereafter, the request 104 from the client C1 to the server S1 is discarded by the congestion cause packet discarding means 13 of the router R1, and the request to the server S1 does not flow into the network.
[0068]
In the situation where the router R3 detects the congestion of the server S1, if there is a request 105 for the server S1 from a different client C2, the congestion cause packet discarding means 13 of the router R3 rejects the request and the congestion of the router R3. The cause packet discarding means 13 notifies the congestion cause packet discarding means 13 of the router R2 of the congestion of the server S1 by transmitting the congestion notification message 106 with the IP address of the client C2 as IPDA. Thereafter, the request from the client C2 to the server S1 Is rejected by router R3.
[0069]
In the above, the method in which the router R3 transmits a dedicated control message to set the filter to the ingress router R1 has been described. In addition, the router R3 is connected to the router R1 by telnet, There is also an example of setting a filter with an existing command line interface. If the router R3 holds network topology information by a dynamic routing protocol such as OSPF / BGP, the IP address of the router R1 that accommodates the client C1 can be known.
[0070]
In this way, by using the routing information exchanged between the routers, routers in the network can recognize each other and acquire information on the IP address, so that the router R3 telnets to the IP address of the router R1. Thus, the filter setting of the router R1 can be performed. Further, if the router can be changed in definition by the SNMP (Simple Network Management Protocol) protocol, it is possible to transmit the SNMP set request from the router R3 to the router R1 and to set the router R1.
[0071]
The router R3 monitors the congestion status for each server. Therefore, even if the server S1 is in a congested state and a request from the client to S1 is restricted, the congestion of the server S2 is not detected. Since the routers R1 and R2 do not regulate access, the requests 108 and 109 for the server S2 are transferred from the clients C1 and C2, and the communication from the client to the server S2 is not affected.
(Operation when congestion is released)
When the congestion of the server S1 is detected in the router R3, the server congestion monitoring means 11 of the router R3 starts to monitor whether or not the server congestion state has been released, and periodically sends a request message 110 to the server in order to know the server congestion state. Is sent. If ping (ICMP echo request), which is a request in the lower layer on the protocol layer, is used for the service provided by the server to know the congestion state of the server, the server is independent of the congested service. May not be able to detect congestion at the application level.
[0072]
For this reason, it is better to send a request to know the congestion state of the application provided by the server, and specifically, a Web page acquisition request is made by HTTP. As an acquisition request, for example, a request message from the client C1 to the server S1 that was monitoring the response by the server congestion monitoring unit 11 is referred to, and the server congestion monitoring unit 11 of the router R3 sends an acquisition request for the same URL to the server S1. To send.
[0073]
When the server congestion monitoring means 11 of the router R3 detects the congestion release of the server S1, the client C1 and the client that have transmitted the congestion notification regarding the server S1 in the past with reference to the stored congestion notification message management data of FIG. Congestion release notification messages 111 and 112 that the congestion of the server S1 has been released are transmitted to C2.
[0074]
FIG. 9 is a diagram illustrating an example of a congestion release notification message. As shown in the figure, an IP header, a message identifier, and a server IP address are shown. The IP header sets the IP address of the client C1 as IPDA. Further, the IP address of the router R3 is set as IPSA. The message identifier is an identifier representing a congestion release notification message. The server IP address is the IP address of the server S1 whose congestion has been eliminated.
[0075]
In the router R1 and the router R2 that have received the congestion release notification messages 111 and 112, the congestion cause packet discard request unit 12 recognizes that the access restriction to the server S1 has been released, and further receives it by referring to the routing information. It is detected that the congestion cancellation notification message is a congestion cancellation notification message for the client connected to itself, and the routers R1 and R2 do not forward the received congestion cancellation notification messages 111 and 112 to the client.
[0076]
Thereafter, the requests 113 and 114 from the clients C1 and C2 to the server S1 are not discarded by the congestion cause packet discarding means 13 of the routers R1 and R2, and can be accessed again from the clients C1 and C2. It becomes.
[0077]
When congestion occurs in the server connected to the network using the method described above, congestion occurs by exchanging information held by the router that connects the server and the router that connects the client and collaborating. A request for a server that does not flow into the network does not flow into the network, and server and network congestion can be avoided.
[0078]
Hereinafter, a second embodiment of the present invention will be described. FIG. 10 is a diagram showing a network configuration according to the second embodiment of the present invention. In the figure, the client C1 is connected to the router R1, the server S1 is connected to the router R3, and a plurality of routers may be further passed between the router R1 and the router R3. A second embodiment in this network configuration will be described with reference to FIG.
[0079]
FIG. 11 is a sequence diagram showing the operation of the second exemplary embodiment of the present invention. The router R1 in FIG. 10 includes the congestion cause packet discarding means 13 in FIG. 2, and the router R3 includes the server congestion monitoring means 11, the congestion cause packet discard requesting means 12, the congestion cause packet discarding means 13, and the congestion service specifying means 18 It comprises.
[0080]
In a situation where the client C1 accesses the server S1, the packet from the client C1 to the server S1 is relayed, and the router R3 connected to the server S1 receives the IP packet of the request message 201 at the LAN frame receiving unit 1 to monitor the server congestion. The contents of the received IP packet are notified to the means 11. Further, in the router R3, the response message 201 from the server S1 to the client C1 is also received by the LAN frame receiving unit 1, and the contents of the IP packet are notified to the server congestion monitoring unit 11.
[0081]
The server congestion monitoring unit 11 of the router R3 notifies the content of the received request message and response message to the congestion service specifying unit 18 of the router R3. The congestion service specifying means 18 examines information for each protocol in the IP packet and monitors server congestion. Specifically, in the case of HTTP, even if the load on the server is the same, the response time for the request varies depending on the URL.
[0082]
For example, a URL that requires access to various databases and a URL that displays various types of information that are searched and processed according to the user take a certain amount of time to respond even if the load on the server is low. On the other hand, the response time is short in a situation where the load on the server is low with a URL that requires only simple disk access.
[0083]
In such a situation, the method of measuring the response time in units of server IP addresses may not be able to accurately monitor the server congestion state. For this reason, the congestion service specifying means 18 of the router R3 accurately monitors the congestion state of the server by monitoring the response time of the server for each URL.
[0084]
In order to monitor the response for each URL, the congestion service specifying means 18 of the router R3 determines the TCP (Transmission Control Protocol) protocol in the IP packet to be transferred, and further determines the TCP packet. Although it is necessary to check the contents of the HTTP protocol and determine the contents of the HTTP protocol, as described in the first embodiment, by adding the program processing of the network processor of the router, a more special device is added to the router. This can be realized without adding and without deteriorating the transfer rate of the IP packet.
[0085]
FIG. 12 is a diagram illustrating an example of server congestion state monitoring data for each URL. As shown in the figure, the URL includes a monitoring target URL, a request generation client, a request time, a current time, an elapsed time after request transmission, and a congestion detection threshold. The figure shows response time data in a state where the client C1 makes a request to the server S1.
[0086]
The congestion service specifying means 18 monitors the congestion for each URL of the server S1 and can set a congestion detection threshold value for each URL. Therefore, even when the response time of the server is different for each URL, the IP address of the server Rather than measuring response time in units, server congestion can be detected more accurately.
[0087]
When the router R3 detects that only a specific URL is congested (202), the router R3 transmits a message for discarding only the request for the specific URL to the router R1 (203). When the router R1 receives the URL-specified congestion notification, the congestion cause packet discarding means 13 of the router R1 can discard only the request for the specific URL (204).
[0088]
Usually, a router has a filtering function and can selectively discard a specific IP packet. The packet to be discarded is selected by checking whether the IP packet is a request addressed to the URL to be discarded without deteriorating the IP packet transfer capability by using the network processor function of the router as described above. Is possible.
[0089]
FIG. 13 is a diagram showing an example of a congestion notification message with URL designation. As shown in the figure, it is composed of an IP header, a message identifier, and a server URL. In the IP header, the IP address of the client C1 is set as IPDA, and the IP address of the router R3 is set as IPSA. The message identifier is an identifier representing a congestion notification message. The server IP address is the URL of the server where the congestion has occurred.
[0090]
Even in a situation where specific URLs are congested and requests from clients are restricted, requests addressed to different URLs of the same server are not restricted, and communication from clients is possible (205). By such an operation, even when the service of the specific URL of the server is congested, it is possible to finely control the traffic and efficiently avoid the server congestion.
[0091]
FIG. 14 is a diagram showing a network configuration according to the third embodiment of the present invention. Clients C1 and C2 are connected to router R1, and server S1 is connected to router R3. A plurality of routers may be further routed between the router R1 and the router R3. A third embodiment in this network configuration will be described with reference to FIG. FIG. 15 is a sequence diagram showing the operation of the third exemplary embodiment of the present invention.
[0092]
The router R1 in FIG. 14 includes the congestion cause packet discarding means 13, the communication statistics recording means 14, and the communication restriction client determining means 15 in the block diagram of FIG. 2, and the router R3 includes the server congestion monitoring means 11 and the congestion cause packet. Disposal request means 12 is provided.
[0093]
In the router R1 that relays a request from the client C1 to the server S1, the communication statistics recording unit 14 of the router R1 monitors communication from the client to the server, and transmits a source IP address, a destination IP address, a TCP port number, a transfer time, The statistical information of the transfer data amount is recorded (301). An example of the statistical information to be recorded is shown in FIG. FIG. 16 is a diagram illustrating an example of client request state monitoring data. As shown in the figure, it is composed of a request generation client, a monitoring target server, a TCP port number, a transfer data amount, a request time, and a current time.
[0094]
Generally, in order to realize a function of transferring an IP packet, a router refers to a source IP address and a destination IP address in an IP packet, and most routers have a function to refer to a TCP port number as a filtering function. Have. Further, most of them hold statistical information on the amount of data transferred as a statistical function. For this reason, the communication statistics recording means 14 can be easily added to the existing router only by holding the information of FIG. 16 in the memory area without deteriorating the IP packet transfer performance of the router.
[0095]
When the server congestion monitoring unit 11 of the router R3 described in the first embodiment detects the congestion state of the server S1 (302), the congestion cause packet discard request unit 12 of the router R3 discards the congestion cause packet of the router R1. The means 13 is notified to restrict the request addressed to the server S1 (303).
[0096]
When the router R1 receives the request from the client C1 to the server S1, the congestion cause packet discarding unit 13 of the router R1 inquires the communication restriction client determining unit 15 of the router R1 whether to transfer or reject the request from the client C1. .
[0097]
The communication restriction client determination unit 15 refers to the statistical information recorded by the communication statistics recording unit 14 to determine a client that rejects the response, rejects the request from the client C1 to be rejected (304), and rejects the request. The request from the outside client C2 is transferred (305).
[0098]
As a method for determining the client to be restricted, for example, there is a method for restricting a request from a client having a large difference between the last communication time and the current time. When this method is used, even if server congestion is detected when the client C1 is using the Web service, the communication of the client C1 is continued without being rejected, and the client C2 that has newly attempted to use the Web service. Such a request is rejected.
[0099]
In the method of restricting communication at random, there is a situation in which communication of a client using a Web service is restricted in the middle of server congestion and the service ends abnormally in the middle. Then, since the communication of the client who has used the service is continued and the communication of the client who intends to newly use the service is restricted, the server can efficiently provide the Web service.
[0100]
Further, as a method for determining a client to be regulated, there is a method for regulating a request from a client having a large amount of communication data, for example. When a specific user downloads a large amount of data over a long period of time, which causes server and network congestion, client communication with a large amount of data to be transferred is not regulated randomly. By restricting the above, it is possible to avoid the specific user from occupying the server resource and the network resource, and to use the server and the network efficiently.
[0101]
FIG. 17 is a diagram showing a network configuration according to the fourth embodiment of the present invention. The clients C1 and C2 are connected to the router R1, and the server S1 is connected to the router R3. A plurality of routers may be further routed between the router R1 and the router R3. The operation of this network configuration will be described with reference to the sequence diagram shown in FIG. FIG. 18 is a sequence diagram showing the operation of the fourth exemplary embodiment of the present invention.
[0102]
The router R3 in FIG. 17 includes the server congestion monitoring unit 11 and the server congestion notification unit 16 in the block diagram shown in FIG. 2, and the router R1 includes the server congestion notification unit 16.
[0103]
A request 401 is transmitted from the client C1 to the router R1. The request 401 is transmitted to the server S1, and the server S1 returns a response 401 to the request 401. The return response 401 is transmitted to the client C1. In the router R3 that relays the request from the client C1 to the server S1, the server congestion monitoring means 11 of the router R3 described in the first embodiment uses the response time information of the request 402 from the client C1 to the server S1. When the server S1 is determined to be in a congestion state, the server congestion monitoring unit 11 of the router R3 notifies the server congestion notification unit 16 of the router R3 that the server S1 is congested.
[0104]
The server congestion notification unit 16 of the router R3 creates a document of a message that the server is congested in the HTML format, and transmits it from the client C1 to the client C1 as a response to the HTTP request (402).
[0105]
Further, the congestion cause packet discard request unit 12 of the router R3 notifies the server congestion notification unit 16 of the router R1 of a congestion notification message with the response time Ta of the server S1 added (403). The server congestion notification means 16 of the router R1 keeps a list of servers that are congested and the response time.
[0106]
FIG. 19 is a diagram showing an example of a congestion notification message with a response time of the server. In the IP header, the IP address of the client C1 is set as IPDA, and the IP address of the router R3 is set as IPSA. The message identifier is an identifier representing a congestion notification message. The server IP address is the IP address of the server S1 where congestion has occurred. The server response time is the response time of the server S1 at the current time.
[0107]
FIG. 20 is a diagram illustrating an example of access restriction server data with a response time of the server. This data represents an example of access restriction server data with a response time of the server managed by the server congestion notification means 16 of the router R1. In the figure, the access restriction server (the IP address of the server S1) and the corresponding response time are shown.
[0108]
Thereafter, when a request for the congested server S1 is received from the client C1 connected to the router R1 until the server congestion notification means 16 of the router R1 receives the server congestion release notification, the server of the router R1 The congestion notification unit 16 generates an HTML document that displays the response time Ta in the access restriction server data with the response time of the server in FIG. 20, and transmits it as the current server congestion state to the requesting client C1. (404).
[0109]
In this situation, even when there is a request from the different client C2 to the server S1, the response time Ta of the server S1 is generated as a Web page in HTML format and notified to the client C2 (405).
[0110]
When detecting the congestion state of the server S1, the server congestion monitoring unit 11 of the router R3 periodically monitors the congestion state of the server S1 by the method described in the first embodiment (406). When the response time of the server S1 changes by more than the set threshold, the latest response time is notified to the server congestion notification means 16 of the router R1 (407). The server congestion notification means 16 of the router R1 updates the response time of the server S1 that is held. When the router R1 rejects the request from the client C1, the server congestion notification means 16 notifies the client of the latest response time Tb (408).
[0111]
When the server congestion monitoring means 11 of the router R3 detects the congestion release of the server S1 (409), it notifies the server congestion notification means 16 of the router R1 of the congestion release (410). The server congestion notification unit 16 of the router R1 deletes the entry of the server S1 from the managed data in FIG. Thereafter, the request from the client C1 to the server S1 is transferred.
[0112]
When the request from the client is regulated by the router of the present invention when the server is congested by the method described above, the user who has generated the request is notified of information on the degree of server congestion. Can be urged to be retried after a period of time (stopping meaningless retries in a non-congested situation), and the situation where the server is congested can be alleviated.
[0113]
FIG. 21 is a diagram showing a network configuration according to the fifth embodiment of the present invention. The client C1 is connected to the router R1, the client C2 is connected to the router R2, and the server S1 is connected to the router R3. A plurality of routers may be further routed between the router R1 and the router R3 and between the router R2 and the router R3. The router R3 includes server congestion history management means 17 shown in the block diagram of FIG.
(Recording history during server congestion)
Consider a case where the server congestion monitoring means 11 in the router R3 determines that the server S1 has entered a congestion state in a situation where the client C1 accesses the server S1. When congestion of the server S1 is detected, a congestion notification message to which information such as a congestion detection threshold of the server S1 is added is transmitted to the client C1 by the congestion cause packet discard request unit 12 of the router R3.
[0114]
FIG. 22 is a diagram illustrating an example of a congestion notification message. In the IP header, the IP address of the client C1 is set as IPDA, and the IP address of the router R3 is set as IPSA. The message identifier is an identifier representing a congestion notification message. The server IP address indicates the IP address of the server S1 where congestion has occurred, and the congestion detection threshold is a threshold for the server S1 to detect congestion.
[0115]
The router R1 that has received the notification refers to “server congestion history data” and determines whether or not congestion has occurred in the communication between the client C1 and the server S1 in the past. If the “server congestion history data” for the client C1-server S1 does not exist, that is, if congestion occurs for the first time, the “server congestion history data” is newly created, and the client C1 is created based on the information of the received congestion notification message. , The IP address of the server S1, and the congestion detection threshold are set in the “server congestion history data”.
[0116]
FIG. 23 is a diagram illustrating a configuration example of server congestion history data. This figure shows server congestion history data between the client C1 and the server S1. As shown in the figure, the server includes a monitoring target server, a request generation client, a congestion detection threshold, a detection type, and a detection time.
[0117]
Next, the time when the router R1 receives the congestion notification message is recorded in the “server congestion history data” as the congestion time. When congestion occurs for the second time and thereafter, only this congestion time is added to the “server congestion history data”.
(Recording history when server congestion is released)
Consider a situation where the server C1 monitors the congestion of the server S1 after the server congestion monitoring means 11 of the router R3 detects the congestion of the server S1 in the situation where the client C1 accesses the server S1. When the router R3 detects the congestion release of the server S2, the server congestion monitoring means 11 transmits a congestion release notification message to the client C1, but the router R1 that has received the notification receives the client C1- The congestion release time is recorded in the “server congestion history data” for the server S1.
[0118]
Thereafter, every time congestion release is detected in the server, the server congestion history management means 17 adds the congestion release time in the data between the corresponding client and server. FIG. 23 shows an example of “server congestion history data” of the router R1 when the server congestion is released. As described above, the information on the server S1 and the congestion / congestion release time are recorded in the “server congestion history data” in the router R1.
[0119]
Further, by transferring the server congestion history data information to the client C1 side using the server congestion notification means 16 of the router R1, the congestion information of the server S1 (the IP of the client C1 and the server S2) in response to a request from the client side. Address, congestion occurrence / congestion release time / time, set congestion threshold, etc.) can be displayed on the client-side screen.
[0120]
In this way, by presenting the history of the server to be accessed to the user, it becomes possible for the user to know the time zone in which congestion occurs frequently and the level of congestion, and in a time zone that is not affected. By prompting the user to access the server, it is possible to prevent the server from being congested.
[0121]
FIG. 24 is a diagram showing a network configuration according to the sixth embodiment of the present invention. The router R1 in the figure includes the communication priority determination means 19 in the block diagram in FIG. Client C1, client C2, and client C3 are connected to router R1, and server S1 is connected to router R3. A plurality of routers may be further passed between the router R1 and the router R3. For example, it is assumed that there are two types of routes, R1-R2-R3 and R1-R4-R3.
[0122]
Further, by the conventional traffic engineering technology, a path (Path) 1 whose bandwidth is guaranteed is set on the route R1-R2-R3, and there is no bandwidth guarantee on the route R1-R4-R3. It is assumed that a best effort path 2 is set.
[0123]
Here, when the filter condition is set on the command line of the router R1 or the like, and the packet entering the router R1 matches the preset filter condition, the packet is transferred to the path of Path1 and Path2. This is possible with routers equipped with traffic engineering functions. As a filter condition that can be set, an arbitrary parameter can be designated from IPDA / IPSA / TOS / protocol type in the IP header, a port number in the TCP header, and the like.
[0124]
FIG. 25 is a diagram illustrating an input example of the filter condition setting in the router R1. The command of {circle around (1)} is “list-1” for a condition permitting a packet addressed to the server S1 (IP address = YY.YY.YY.YY) from the client C1 (IP address = XX.XX.XX.XX). ". The command {circle around (2)} is “list-2” for a condition that allows a packet addressed to the server S1 (IP address = YY.YY.YY.YY) from the client C2 (IP address = ZZ.ZZ.ZZ.ZZ). The name is given.
[0125]
The command {circle around (3)} is set so that when a packet matching the content of the condition “list-1” flows into the router R1, the packet is transferred on the path of Path1. The command {circle around (4)} is set so that when a packet matching the content of the condition “list-2” flows into the router R1, the packet is transferred on the route of Path2. When the above settings are input, the router R1 creates “filter condition data” as shown in FIG.
[0126]
FIG. 26 is a diagram showing filter condition data in the router R1. As shown in the figure, the transmission source IP address, transmission source mask, transmission destination IP address, transmission destination mask, protocol type, TOS value, transmission source port number, transmission destination port number, and corresponding Path It is composed of
[0127]
When the client C1 and the client C2 are in a situation of accessing the server S1 under the above conditions using the existing traffic engineering technology, the communication priority determining means 19 of the router R1 determines the server according to the client priority when the server S1 is congested. It is possible to determine the behavior of the packet addressed to S1.
[0128]
First, when the server congestion monitoring unit 11 of the router R3 detects the congestion of the server S1, the congestion cause packet discard requesting unit 12 transmits a congestion notification message to the router R1. Then, the client (C1 and C2) to be discarded is determined by the congestion cause packet discard unit 13 of the router R1 that has received the notification. At this time, the congestion cause packet discard unit 13 makes an inquiry to the communication priority determination unit 19 And compare with the filter condition data held by the router R1.
[0129]
The client C1 associated with a bandwidth-guaranteed path such as Path1 is regarded as high priority, and the path associated with the best effort path such as Path2 is regarded as medium priority, and these are excluded from discard targets as packets to be transferred. As a result, even when the server S1 is in a congested state, the packets from the clients C1 and C2 are not uniformly discarded by the router R1, but the packets from the client C1 flow to the Path1 route with guaranteed bandwidth, and the client C2 Can be continuously sent to the best-effort Path 2 route.
[0130]
However, since clients other than C1 and C2 existing under the router R1 are regarded as low priority and are to be discarded, for example, when the client C3 tries to communicate with the server S1, the packet is uniformly discarded in the router R1. .
[0131]
In addition, if a detour route is set in advance using the traffic engineering function of the router for the path used by the priority client, even if a node / link failure occurs on the path of the priority client, Transfer to the server can be continued without awareness.
[0132]
For example, as shown in FIG. 27, if another path “Path” 3 passing through the router R5 is provided between the router R1 and the router R3, the path R3 as a detour path of the Path1 by the traffic engineering function in the router R1. Is set, even when a failure occurs in Path1, it is possible to switch to Path3 instantaneously, and communication with a client to be prioritized can be performed without being affected by packet loss. However, when the detour route is not set, the route is transferred by the route according to the best effort route according to the priority route of the routing protocol such as OSPF.
[0133]
In this way, instead of randomly discarding all client packets when the server is congested, the packet for each client is linked with the path selection function according to the filter conditions of the router equipped with the traffic engineering function. It is possible to finely control the handling at the router side.
[0134]
For example, even if congestion occurs on a server with a certain Web site, a stable service is provided step by step according to the fee without denying access to customers who have contracted with ISPs and priority services. Differentiating services such as denying access to outside regular customers can be provided on the ISP (Internet service provider) side that owns the router.
[0135]
For example, if there is a network in which there are 100 routers and 10 servers are connected to each router, and a total of 1000 server congestion avoidance and congestion avoidance of this network are performed, Assuming that functions related to congestion avoidance are necessary and the performance of the router and the control server is the same, if one control server can control the congestion of 10 processing servers, 100 control servers Is required.
[0136]
In the case of a router capable of hard routing, since the CPU is free in a stable state, it is not necessary to load a dedicated processor. If congestion control is possible to the extent possible with the control server, the existing router can be used without particularly increasing costs. Since it can be realized, the cost for incorporating the functions into the cost of 100 control servers + 1000 processing servers will rise.
[0137]
According to the present invention, the following effects can be obtained.
1. The server connected to the router of the present invention can avoid congestion without having a special function on the server side.
2. Network congestion can be avoided by retrying from the client when the server is congested.
3. When the router that accommodates the server and the router that accommodates the client cooperate to perform congestion control in units of Web page URL, FTP directory, etc., and only a specific service is congested In this case, it is possible to effectively avoid server congestion by discarding only the packet of the service.
4). Without having a special function in the client / server, it is possible to prevent service interruption caused by randomly discarding packets and to effectively restrict communication that causes congestion.
5. It is possible to improve user convenience by recognizing information related to congestion such as server congestion and how long it is necessary to access the server without having a communication timeout during server congestion. Become.
6). It is possible to centrally manage the congestion history of all servers accommodated in the router without having any special function on the server side.
7). In a network to which a large number of servers such as ISPs are connected, the access control server monitors congestion of all servers and sets a filter for a large number of routers to which clients are connected as in the prior art. Although a large number of access control servers corresponding to the number and the network scale are required, in the present invention, congestion control can be realized by introducing only a router.
8). In the case of a router that performs hard routing, the CPU that is operating stably is not operating, but by realizing the same processing as the access control server with the software of the router, the CPU of the router is effectively used, and a large number of ISPs or the like It is possible to keep the overall cost of the scale network low.
9. By implementing the congestion control of the present invention with the hardware function of the router, it is possible to control a large number of servers with a single router, as compared with the case of realizing with the software of the access control server.
10. By setting a priority for each client on the router side, clients that communicate with a congested server can be discarded at the ingress router, or the bandwidth can be limited by bandwidth control, or bypassed It is possible to differentiate provided services such as using routes.
[0138]
(Appendix 1) A router on a network system where a server and a client are installed,
A LAN frame receiving unit that receives a LAN frame, a traffic engineering control unit that sets bandwidth control and a detour route by receiving an output from the LAN frame receiving unit, and a routing that performs a routing process by receiving the output from the traffic engineering control unit In what comprises a processing unit and a LAN frame transmission unit that receives the output of the routing processing unit and transmits a LAN frame,
Server congestion control means connected to each of the above-described components to detect server congestion and to control server congestion when server congestion is detected
A network and server load reduction router characterized by comprising:
[0139]
(Appendix 2) Server congestion monitoring means for automatically detecting server congestion by monitoring response delay of packets addressed to the server;
Provided in the server congestion control means is a congestion cause packet discard requesting means for requesting the router accommodating the client to discard / relay the packet causing the congestion when detecting server congestion / congestion release. The network and server load reduction router according to appendix 1, wherein
[0140]
(Appendix 3) Congestion service identification means that identifies the server service that is congested in the router that accommodates the server and only packets related to the service of the server that is congested in the router that accommodates the client are discarded The network and server load reduction router according to appendix 2, characterized in that a congestion cause packet discarding means is provided in the server congestion control means.
[0141]
(Supplementary note 4) A communication statistics recording means for monitoring packets between a client and a server and recording statistical information such as a packet communication amount between the server and a client and a last communication time, and a router accommodating a client at the time of server congestion A communication control client determining means for determining a client for starting a new communication or a client for restricting the packet communication of a client whose communication volume exceeds a specified amount when requesting a packet discard in the server congestion control means. The network and server load reduction router according to appendix 2, which is provided.
[0142]
(Supplementary note 5) A server congestion notification means for notifying a client of server congestion at the same time as discarding a packet that causes congestion when detecting server congestion is provided in the server congestion control means. The described network and server load reduction router.
[0143]
(Supplementary note 6) The network according to supplementary note 5, wherein a server congestion history management means for managing a server congestion history is provided in the server congestion control means, and the congestion history information is notified to the client by the server congestion notification means. And server load reduction router.
[0144]
(Supplementary note 7) The server congestion control means includes a communication priority determination means for setting a class of a client to be prioritized / non-prioritized in advance and determining a behavior for a packet corresponding to the class. The network and server load reduction router according to appendix 2.
[0145]
【The invention's effect】
As described above, according to the present invention, the following effects can be obtained.
(1) According to the first aspect of the present invention, the server congestion control means 10 that has detected server congestion can perform server congestion control to reduce server congestion.
(2) According to the second aspect of the present invention, it is possible to avoid congestion of all servers accommodated in the router without having a function on the server side, and at the same time, to avoid network congestion due to a retry from the client when the server is congested It can be avoided.
(3) According to the invention described in claim 3, not only the packet causing the congestion is identified by the address and protocol of the destination server, but also the URL of the Web page or FTP (File Transfer Protocol: TCP / IP). It is possible to discard only packets related to a congested service such as a directory of a file transfer protocol (used).
(4) According to the invention described in claim 4, it is possible to restrict communication of only a specific client, prevent service interruption by randomly discarding packets, and prevent communication that causes congestion. It can be effectively regulated.
(5) According to the invention described in claim 5, it is possible for the user to recognize the server congestion and the information related to the congestion without having a communication timeout, and to improve the convenience for the user.
[0146]
Thus, according to the present invention, server congestion can be automatically detected for all servers accommodated in the router without incorporating special functions on the server side, and clients are accommodated. By cooperating with the router, it is possible to provide a network and server load reduction router that can easily avoid congestion of the server and the entire network.
[Brief description of the drawings]
FIG. 1 is a principle block diagram of the present invention.
FIG. 2 is a block diagram showing a first exemplary embodiment of the present invention.
FIG. 3 is a diagram illustrating a network configuration according to the first exemplary embodiment of the present invention.
FIG. 4 is a sequence diagram showing an operation of the first exemplary embodiment of the present invention.
FIG. 5 is a diagram illustrating an example of server congestion state monitoring data.
FIG. 6 is a diagram illustrating an example of a congestion notification message.
FIG. 7 is a diagram illustrating an example of congestion notification message management data.
FIG. 8 is a diagram illustrating an example of access restriction server data.
FIG. 9 is a diagram illustrating an example of a congestion release notification message.
FIG. 10 is a diagram showing a network configuration of a second exemplary embodiment of the present invention.
FIG. 11 is a sequence diagram showing an operation of the second exemplary embodiment of the present invention.
FIG. 12 is a diagram illustrating an example of server congestion state monitoring data for each URL.
FIG. 13 is a diagram illustrating an example of a URL notification congestion notification message.
FIG. 14 is a diagram showing a network configuration of a third exemplary embodiment of the present invention.
FIG. 15 is a sequence diagram showing a third exemplary embodiment of the present invention.
FIG. 16 is a diagram illustrating an example of client request state monitoring data.
FIG. 17 is a diagram showing a network configuration of a fourth exemplary embodiment of the present invention.
FIG. 18 is a sequence diagram showing an operation of the fourth exemplary embodiment of the present invention.
FIG. 19 is a diagram illustrating an example of a congestion notification message with a response time of a server.
FIG. 20 is a diagram illustrating an example of access restriction server data with a response time of the server.
FIG. 21 is a diagram showing a network configuration according to a fifth embodiment of the present invention.
FIG. 22 is a diagram showing an example of a congestion notification message in the fifth embodiment.
FIG. 23 is a diagram illustrating a configuration example of server congestion history data.
FIG. 24 is a diagram showing a network configuration of a sixth exemplary embodiment of the present invention.
FIG. 25 is a diagram illustrating an input example of filter condition setting in the router R1.
FIG. 26 is a diagram showing filter condition data in the router R1.
FIG. 27 is a diagram illustrating an example of a transfer route failure switching operation;
FIG. 28 is a conceptual diagram of a router.
FIG. 29 is a block diagram showing a concept of a conventional router.
FIG. 30 is an explanatory diagram of a LAN frame receiving unit, a LAN frame transmitting unit, and a routing processing unit.
FIG. 31 is an explanatory diagram of a traffic engineering control unit.
[Explanation of symbols]
1 LAN frame receiver
2 Traffic Engineering Control Department
3 Routing processor
4 LAN frame transmitter
10 Server congestion control means

Claims

A router on a network system in which a server and a client are installed, a LAN frame receiving unit that receives a LAN frame, and a traffic engineering control unit that sets a bandwidth control and a detour route by receiving an output of the LAN frame receiving unit A routing processing unit that receives the output of the traffic engineering control unit and performs a routing process; and a LAN frame transmission unit that receives the output of the routing processing unit and transmits a LAN frame.
Connected with each of the above-mentioned components, and detects server congestion, and when server congestion is detected, provides server congestion control means for performing server congestion control ,
Server congestion monitoring means that automatically detects server congestion by monitoring the response delay of packets addressed to the server, and discard / relay of packets that cause congestion when server congestion / decongestion is detected A load reducing router for a network and a server, characterized in that said server congestion control means includes a congestion cause packet discard request means for making a request to the router to be executed.

Congestion service identification means that identifies the server service that is congested in the router that houses the server, and the congestion cause packet that only discards packets related to the server service that is congested in the router that accommodates the client The network and server load reduction router according to claim 1 , wherein a discarding means is provided in the server congestion control means.

Monitors packets between the client and server and records statistical information such as the amount of packet communication between the server and client and the last communication time, and discards packets to the router that accommodates the client when the server is congested. The server congestion control means includes a communication control client determination means for determining a client that starts a new communication or a client that restricts packet communication of a client whose communication volume exceeds a specified amount when making a request. The network and server load reduction router according to claim 1, wherein:

When the server congestion detection, and at the same time discards the packet as a congestion cause, the network according to claim 1, characterized in that a server congestion notifying means for notifying the server congestion to the client to the server congestion control means And server load reduction router.