ネットワークシステム
【課題】
従来は、エッジ装置を特定して負荷情報を取得し、ＷＥＢ検索結果に表示することが難しかった。
【解決手段】
本発明は、メッシュ状のネットワークを構成する複数のスイッチ装置と、ＷＥＢサービスを提供するサイトサーバと、ネットワークに接続される端末装置のＷＥＢ検索要求に応じてサイトサーバのＵＲＬ情報をＷＥＢ検索結果として端末装置に提供する検索サーバと、複数のスイッチ装置の状態を監視する監視サーバとを有し、検索サーバは、端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する各サイトサーバ直近のスイッチ装置の負荷情報を監視サーバから取得してＷＥＢ検索結果の各ＵＲＬに関連付けて端末装置に提供することを特徴とする。
従来は、エッジ装置を特定して負荷情報を取得し、ＷＥＢ検索結果に表示することが難しかった。
【解決手段】
本発明は、メッシュ状のネットワークを構成する複数のスイッチ装置と、ＷＥＢサービスを提供するサイトサーバと、ネットワークに接続される端末装置のＷＥＢ検索要求に応じてサイトサーバのＵＲＬ情報をＷＥＢ検索結果として端末装置に提供する検索サーバと、複数のスイッチ装置の状態を監視する監視サーバとを有し、検索サーバは、端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する各サイトサーバ直近のスイッチ装置の負荷情報を監視サーバから取得してＷＥＢ検索結果の各ＵＲＬに関連付けて端末装置に提供することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、エッジ装置に接続されるサイトサーバにアクセスするネットワークの輻輳状態を確認できるネットワークシステムに関する。
【背景技術】
【０００２】
近年のインターネットの普及により、様々な情報を簡単に収集できるようになってきた。これに伴って検索サーバの検索技術や検索結果の表示技術は大きく進歩し、ますます効率的に情報収集が行えるようになってきた。一方、インターネットのインフラである基幹ネットワークを構成するＬ２ＳＷ（レイヤ２のスイッチ装置）には、流れるデータの情報やデータ量を統計的に保持する機能を有する装置が普及している（例えば、特許文献１参照）。さらに、これらの装置を遠隔から監視するシステムも同時に進歩してきた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−２３６１９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術では、メッシュ状のネットワークを構成する複数のスイッチ装置のうちＷＥＢサービスを提供するサイトサーバ直近に接続されているスイッチ装置（エッジ装置と称する）を特定することができないので、エッジ装置自体の負荷状態（アクセス頻度などを含むものとする）を知ることができないという問題があった。また、他の基幹ネットワークにサイトサーバがある場合は、ユーザが属する基幹ネットワークの監視サーバは他の基幹ネットワークの負荷情報は知ることができないという問題があった。
【０００５】
上記課題に鑑み、本発明の目的は、エッジ装置を特定して、エッジ装置の負荷情報を取得し、ＷＥＢ検索結果に関連付けて表示できるネットワークシステムを提供することである。
【課題を解決するための手段】
【０００６】
本発明に係るネットワークシステムは、メッシュ状のネットワークを構成する複数のスイッチ装置と、ＷＥＢサービスを提供するサイトサーバと、前記ネットワークに接続される端末装置のＷＥＢ検索要求に応じて前記サイトサーバのＵＲＬ情報をＷＥＢ検索結果として前記端末装置に提供する検索サーバと、前記複数のスイッチ装置の状態を監視する監視サーバとを有し、前記検索サーバは、前記端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供することを特徴とする。
【０００７】
また、前記スイッチ装置は、フレームを送受信する送受信処理部と、前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、前記負荷情報を蓄積するデータベースと、自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部とを有することを特徴とする。
【０００８】
さらに、前記スイッチ装置のエッジ判別処理部は、前記フレームの中のＨＴＴＰリクエストフレームを格納するＩＰフレームまたはＴＣＰフレームのヘッダ部にカウンタを設けて、前記ＩＰフレームまたは前記ＴＣＰフレームを転送する毎に前記カウンタをカウントアップし、前記ＨＴＴＰリクエストフレームを送信時の前記カウンタ値を第１カウンタ値として保持し、前記ＨＴＴＰリクエストフレームに対するＨＴＴＰレスポンスフレームを格納する前記ＩＰフレームまたは前記ＴＣＰフレームのヘッダ部の前記カウンタ値を第２カウンタ値として前記第１カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断することを特徴とする。
【０００９】
特に、前記スイッチ装置は、レイヤ２スイッチであることを特徴とする。
【００１０】
また、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値であることを特徴とする。
【００１１】
或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間であることを特徴とする。
【００１２】
または、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度であることを特徴とする。
【００１３】
或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値であることを特徴とする。
【００１４】
特に、前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供することを特徴とする。
【００１５】
また、前記サイトサーバが前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークにある場合、前記第２基幹ネットワークの検索サーバは、前記第１基幹ネットワークの監視サーバの情報と前記第２基幹ネットワークの監視サーバの情報とを取得することを特徴とする。
【００１６】
特に、前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記第１基幹ネットワークの検索サーバが前記第２基幹ネットワークの監視サーバの情報を持っていない場合、前記第１基幹ネットワークの監視サーバは、前記第２基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得することを特徴とする。
【００１７】
さらに、前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断することを特徴とする。
【発明の効果】
【００１８】
本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別し、検索サーバはエッジ装置から取得した負荷情報とＵＲＬとを対応させたＷＥＢ検索結果を端末装置に提供することができる。
【図面の簡単な説明】
【００１９】
【図１】ネットワークシステム１００の構成例を示す図である。
【図２】検索サーバＫ１が提供する検索サイトで検索キーワードを入力する例を示す図である。
【図３】一般的なＷＥＢ検索結果画面例を示す図である。
【図４】負荷情報として使用帯域を表示するＷＥＢ検索結果画面例を示す図である。
【図５】負荷情報として使用帯域履歴を表示するＷＥＢ検索結果画面例を示す図である。
【図６】負荷情報として応答時間を表示するＷＥＢ検索結果画面例を示す図である。
【図７】負荷情報としてアクセス頻度を表示するＷＥＢ検索結果画面例を示す図である。
【図８】エッジ装置、検索サーバＫ１および監視サーバＡ１間の情報の流れを示す図である。
【図９】ユーザＰＣ１によるＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までの流れを示す図である。
【図１０】装置Ｅの構成例を示す図である。
【図１１】装置Ｅのその他の構成例を示す図である。
【図１２】装置Ｅのその他の構成例を示す図である。
【図１３】ＩＰヘッダの構成を示す図である。
【図１４】ＴＣＰヘッダの構成を示す図である。
【図１５】オプション領域のフォーマットを示す図である。
【図１６】本実施形態に係るネットワークシステム１００におけるエッジ装置判定の一例を示す図である。
【図１７】本実施形態の機能に対応しない装置がある場合のエッジ装置判定の一例を示す図である。
【図１８】カウンタによるエッジ装置判定の処理を示すフローチャートである。
【図１９】カウンタによるエッジ装置判定の処理を示すフローチャートである。
【図２０】複数の基幹ネットワークを有するネットワークシステム１００ａの構成例を示す図である。
【図２１】ネットワークシステム１００ａにおけるユーザＰＣ１によるＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までの流れを示す図である。
【図２２】ネットワークシステム１００ａにおける監視サーバＡ１の処理例を示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明に係るネットワークシステムの実施形態について詳しく説明する。
【００２１】
図１は、本実施形態に係るネットワークシステム１００の構成例を示す図である。図１において、ネットワークシステム１００は、メッシュ状のネットワーク１０１を構成する複数のＬ２スイッチ装置（図１の例では装置Ｅ１から装置Ｅ１１）と、検索サーバＫ１と、監視サーバＡ１と、サイトサーバＳ１とを有する。尚、装置Ｅ１から装置Ｅ１１に共通の事項を説明する場合は装置Ｅと表記する。また、本実施形態における動作説明では、サイトサーバＳ１の動作について説明するが、実際には点線で示したように、サイトサーバＳ２およびサイトサーバＳ３などの複数のサイトサーバが用いられる。ここで、サイトサーバとは、ｈｔｔｐ対応のホームページなどを提供するサーバでＷＥＢサーバとも呼ばれている。また、検索サーバとは、装置Ｅに接続されるユーザ端末装置（図１の例ではユーザＰＣ１またはユーザＰＣ２）から送信される検索キーワードを含む情報を公開しているサイトサーバのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を検索して、検索結果（ＵＲＬリストなど）をユーザ端末装置に返信するサーバである。さらに、監視サーバとは、管轄する基幹ネットワーク（図１の例ではネットワーク１０１）内の全装置Ｅの動作設定や動作状態の監視および制御などを行うためのサーバである。また、図１では、１つのネットワーク１０１内に閉じているが、複数の基幹ネットワークが装置Ｅを介して接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。尚、複数の基幹ネットワークを有する場合の実施形態については後で詳しく説明する。
【００２２】
図１において、ユーザＰＣ１は装置Ｅ１を介してネットワーク１０１に接続され、ユーザＰＣ２は装置Ｅ２を介してネットワーク１０１に接続されている。また、サイトサーバＳ１は装置Ｅ９を介してネットワーク１０１に接続され、検索サーバＫ１および監視サーバＡ１は装置Ｅ３および装置Ｅ４を介してそれぞれネットワーク１０１に接続されている。尚、検索サーバＫ１と監視サーバＡ１は別のネットワークで接続されていてもよい。
【００２３】
先ず、ユーザＰＣ１から検索サーバＫ１に検索キーワードを送信して検索キーワードが含まれる情報を公開しているサイトサーバのＵＲＬを検索する場合の動作について説明する。例えばユーザＰＣ１は一般に用いられているＤＮＳサーバ（図１には記載せず）を介して検索サーバＫ１に接続する。そして、ユーザＰＣ１の画面には、図２に示すように、検索サーバＫ１から受信する検索画面が表示される。ユーザが検索キーワード（図２の例では「食品Ａ レシピ」）を入力して検索ボタンを押下すると、検索キーワードが検索サーバＫ１に送られる。そして、検索サーバＫ１は受信する検索キーワードに該当する情報を有するサイトサーバ（図１の例ではサイトサーバＳ１，Ｓ２，Ｓ３など）へアクセスするためのＵＲＬを検索し、ＵＲＬリストなどの検索結果をユーザＰＣ１に送信する。
【００２４】
図３は検索サーバＫ１から受信した検索結果の画面例を示す図である。検索結果には、検索キーワードを含む公開情報２０１やサイトサーバのＵＲＬ２０２ａ（ｗｗｗ．ａｂｃｄｅｆ．ｃｏｍ／ａａａ１２３／・・・）などが表示される。ここで、例えばＵＲＬ２０２ａはサイトサーバＳ１のＵＲＬ、ＵＲＬ２０２ｂはサイトサーバＳ２のＵＲＬ、ＵＲＬ２０２ｃはサイトサーバＳ３のＵＲＬのようにそれぞれ対応する。そして、ユーザＰＣ１で例えばＵＲＬ２０２ａを選択（マウスカーソルでクリック）すると、ユーザＰＣ１からネットワーク１０１を介してサイトサーバＳ１に接続され、サイトサーバＳ１から当該ＵＲＬに対応するホームページなどが表示される。
【００２５】
このようにして、ユーザＰＣ１は、見たい情報を提供するサイトサーバのＵＲＬを検索サーバＫ１を介して検索し、検索結果の中から選択したＵＲＬのサイトサーバから必要な情報を得ることができる。
【００２６】
ところが、図３の例では、検索結果の画面から各ＵＲＬを提供するサイトサーバにアクセスする際の負荷状態（サイトサーバの混雑状態やサイトサーバに接続する経路の混雑状態などを含む）をユーザーは知ることができない。
【００２７】
そこで、本実施形態に係るネットワークシステム１００では、検索サーバＫ１が作成してユーザＰＣ１に送信する検索結果の各ＵＲＬ毎に負荷情報を表示できるようになっている。例えば図４では、負荷情報として、当該サイトサーバにアクセスする際の使用帯域を表示する様子を示している。図４の場合、ＵＲＬ２０２ａの使用帯域２０３ａは３０％程度で空いているが、ＵＲＬ２０２ｂの使用帯域２０３ｂは８０％以上で混雑していることをユーザは検索結果の画面を見て知ることができる。これにより、例えばユーザは、アクセスが遅くなる可能性が高いＵＲＬ２０２ｂの選択を避けて、ＵＲＬ２０２ａやＵＲＬ２０２ｃなどを選択することができる。ここで、使用帯域（或いは帯域使用率）は、現帯域使用量（送信量または受信量）／最大帯域使用量（ポート毎に決められた最大送信量または最大受信量）（％）により求めることができる。
【００２８】
また、図５の例では、図４で説明した使用帯域の過去の履歴（図５の例では２日前までの履歴）を検索結果画面の各ＵＲＬ毎に表示する。これにより、例えばユーザは、ＵＲＬ２０２ａは過去の使用帯域２０４ａから本日だけ混雑していること、ＵＲＬ２０２ｂは過去の使用帯域２０４ｂからいつも空いていること、などの負荷情報を知ることができる。
【００２９】
さらに、図６の例では、応答時間を検索結果画面の各ＵＲＬ毎に表示する。尚、応答時間は、サイトサーバが接続されるエッジ装置Ｅとサイトサーバとの間の回線帯域とサイトサーバ自体の処理負荷を含むので、実際にアクセスした時のレスポンスが速さを知ることができる。これにより、例えばユーザは、ＵＲＬ２０２ａは応答時間２０５ａが０．３秒なのでレスポンスが速い、ＵＲＬ２０２ｂは応答時間２０５ｂが５．３秒なのでレスポンスが遅い、などの判断を行うことができる。
【００３０】
また、図７の例では、統計情報として直近のアクセス頻度（１時間当りのアクセス件数）を検索結果画面の各ＵＲＬ毎に表示する。尚、従来技術として過去のアクセス件数を表示するものもあるが、図７の場合は直近のアクセス頻度を表示することができる。これにより、例えばユーザは、ＵＲＬ２０２ａの直近の１時間のアクセス件数が５１０００件で、ＵＲＬ２０２ｂの直近の１時間のアクセス件数は１０００件なので、ＵＲＬ２０２ａの方がレスポンスが遅い可能性があるという判断を行うことができる。
【００３１】
このようにして、本実施形態に係るネットワークシステム１００では、検索サーバの検索結果画面から各ＵＲＬを提供するサイトサーバにアクセスする際の負荷状態をアクセスする前に知ることができる。これにより、ユーザは、比較的レスポンスが速いサイトサーバのＵＲＬを選択することができる。尚、負荷情報は、過去の同時刻の装置の負荷情報からその平均値を表示するようにしてもよい。
【００３２】
次に、本実施形態に係るネットワークシステム１００において、各装置Ｅと検索サーバＫ１および監視サーバＡ１との間で送受信される情報について図８のシーケンス図を用いて説明する。尚、ネットワークシステム１００はＳＮＭＰプロトコルに対応し、制御情報を送受信する。
【００３３】
図８において、監視サーバＡ１は、管轄するネットワーク１０１内の全装置Ｅから各装置Ｅに接続されるサイトサーバのＵＲＬ情報を収集する。ＵＲＬ情報の収集は、例えば監視サーバＡ１が全装置Ｅに対して定期的にポーリングを行って収集してもよいし、ポーリング対象の装置Ｅを自装置がエッジ装置であるという通知をしてきた装置Ｅに限定してもよい。或いは、ポーリングを行わずに装置Ｅから自装置がエッジ装置であるという通知を受けたときだけ、当該装置からＵＲＬ情報を収集するようにしてもよい。
【００３４】
ここで、後で説明するように装置Ｅは自装置があるサイトサーバのエッジ装置であるか否かを判別する機能を有している。そして、装置Ｅは、自装置がエッジ装置であると判断した場合に監視サーバＡ１に自装置がエッジ装置であることを通知する。装置Ｅは、自装置に接続されるサイトサーバのＵＲＬ情報を蓄積したＨＴＴＰデータベース１５４や帯域使用率やアクセス件数などの統計情報を蓄積する統計情報データベース１５７を有している。尚、いずれか１つのデータベースでもよいし、両方の情報を１つのデータベースに集約してもよい。監視サーバＡ１は装置Ｅに対して「ＳＮＭＰ ＧＥＴ」コマンドを送信してポーリングを行い、装置Ｅは自装置内のＨＴＴＰデータベース１５４に蓄積されたＵＲＬ情報を「ＳＮＭＰレスポンス」として監視サーバＡ１に返信する。監視サーバＡ１は、各装置Ｅから収集したＵＲＬ情報を各装置Ｅの装置ＩＤに対応付けて、監視サーバＡ１内の監視サーバデータベース３０１に保持する。これにより、監視サーバＡ１は、どの装置ＥがどのＵＲＬについての情報を保持しているかを管理することができる。
【００３５】
同様に検索サーバＫ１は、複数の監視サーバに対してＳＮＭＰによる定期的なポーリングを行い、各ＵＲＬ毎にどの監視サーバの配下のどの装置Ｅに属しているのかを示す情報を得ることができる。図８の例では、検索サーバＫ１は監視サーバＡ１から収集した情報を自身の検索サーバデータベース３０２に蓄積する。尚、図８の例では、検索サーバＫ１は監視サーバＡ１を介して装置Ｅの情報を直接収集するようにしてもよい。これにより、装置情報を収集する時に検索サーバＫ１と監視サーバＡ１との間で情報を送受信する必要が無くなるため、装置Ｅの負荷情報をより速く検索画面に表示できる。
【００３６】
次に、図８で説明したシーケンスにより、監視サーバＡ１と検索サーバＫ１とにＵＲＬに関する情報が蓄積された状態にある場合に、ユーザＰＣ１が検索サーバＫ１に検索キーワードを含むＨＴＴＰリクエストフレームを送信すると、検索サーバＫ１は検索キーワードを含むＷＥＢページを有するサイトサーバのＵＲＬを検索する。この処理は、一般的に行われている検索サーバの情報検索サービスと同じである。従来の検索サーバでは、この時点の検索結果をＨＴＴＰレスポンスとしてユーザ側に返信して検索結果画面がユーザＰＣ１に表示されていた（図３）。
【００３７】
これに対して、本実施形態に係るネットワークシステム１００では、図９に示すように、検索サーバＫ１は、自身の検索サーバデータベース３０２を参照して、検索結果の各ＵＲＬに対応するエッジ装置Ｅを管轄する監視サーバＡ１に対して「ＳＮＭＰ ＧＥＴ」コマンドを送信し、目的のＵＲＬを持つサイトサーバに接続されるエッジ装置Ｅのポートの負荷情報（例えば帯域使用率やアクセス頻度など）を要求する。そして、この要求を受けた装置Ｅは自身が保持しているＨＴＴＰデータベース１５４や統計情報データベース１５７を参照して、要求された負荷情報を求める。例えば負荷情報がアクセス頻度である場合は、エッジ装置Ｅから当該ＵＲＬに相当するサイトサーバへのアクセス数（例えばＨＴＴＰの＜ｈｏｓｔ＞までの部分一致検索でヒットするもの）を取得する。尚、＜ｈｏｓｔ＞は、フォーマット（ｈｔｔｐ：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞？＜ｓｅａｒｃｈｐａｒｔ＞）で示されるＵＲＬの一部でＲＦＣ１７３８に定められている。
【００３８】
アクセス数は、装置自身が保持しているＨＴＴＰデータベース１５４に格納しているデータベースの中からＨＴＴＰリクエストフレームにあるＵＲＬに該当するデータのうち、種別がＨＴＴＰフレームのヘッダ情報がＧＥＴであり、且つ、装置Ｅからサイトサーバへの送信時刻が現在時刻から１時間以内であるデータの個数をアクセス頻度として求める。そして、求めたアクセス頻度を「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」に格納して監視サーバＡ１に送信する。同様に、要求された負荷情報が帯域使用率の場合は、統計情報データベース１５７に蓄積されている装置Ｅのサイトサーバが接続されているポートの送信量（または受信量）を設定されている最大送信量（または最大受信量）で割って帯域使用率（％）を求め、これを「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」に格納して監視サーバＡ１に送信する。監視サーバＡ１は装置Ｅから受信した「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」の負荷情報を検索サーバＫ１に送信し、検索サーバＫ１は監視サーバＡ１から受信した負荷情報を先に検索した検索結果の該当するＵＲＬに対応付けた「ＨＴＴＰレスポンス」をユーザＰＣ１に送信する。尚、この場合は送信量／最大送信量と受信量／最大受信量の２つの値の大小を比較して、大きい値を監視サーバＡ１に送信するようにしても構わない。
【００３９】
このようにして、ユーザＰＣ１では、先に図４、図５、図６および図７で説明したように、負荷情報を含む検索結果画面を閲覧することができる。
［装置Ｅの構成］
次に装置Ｅの構成例について図１０を用いて説明する。尚、図１０は図１の一部分を抜き出した図で、図１におけるサイトサーバＳ１に接続されるエッジ装置（装置Ｅ９）と、装置Ｅ９に接続される装置Ｅ８を示している。また、図１０では、装置Ｅ９の構成例を描いてあるが、他の装置Ｅについても同様に構成される。
【００４０】
図１０において、装置Ｅ９は、送受信処理部１５１と、フレーム解析処理部１５２と、データベース格納処理部１５３と、ＨＴＴＰデータベース１５４と、統計情報処理部１５５と、統計情報格納処理部１５６と、統計情報データベース１５７と、エッジ判別処理部１５８とで構成される。尚、フレーム解析処理部１５２とデータベース格納処理部１５３および統計情報処理部１５５と統計情報格納処理部１５６は、負荷情報を求めるためのブロック（負荷情報処理部１５９）として１つにまとめてもよい。同様に、ＨＴＴＰデータベース１５４および統計情報データベース１５７を負荷情報データベース１６０として１つにまとめてもよい。そして、負荷情報処理部１５９は、フレーム解析処理部１５２で送受信されるフレーム情報や統計情報などから得られる負荷情報を負荷情報データベース１６０に蓄積する処理や、負荷情報データベース１６０に蓄積された負荷情報を監視サーバＡ１や検索サーバＫ１からの要求に応じて送信する処理などを行う。
【００４１】
尚、図１０では、統計情報データベース１５７に蓄積される統計情報を用いて算出する送信量や受信量などの負荷情報と、ＨＴＴＰデータベース１５４に蓄積されるフレーム情報を用いて算出される応答時間などの負荷情報との両方に対応する構成を描いてあるが、例えばＨＴＴＰデータベース１５４に蓄積されたフレーム情報から求められる負荷情報のみを用いる場合は、図１１に示したように、フレーム解析処理部１５２、データベース格納処理部１５３およびＨＴＴＰデータベース１５４のみを搭載する構成であってもよい。逆に、図１２に示すように、統計情報処理部１５５、統計情報格納処理部１５６および統計情報データベース１５７のみを搭載する構成であってもよい。尚、図１２では、図１０に示した統計情報の送信量および受信量を直近、１日前、２日前のように過去の送信量の平均および受信量の平均を統計情報処理部１５５で求めて統計情報データベース１５７に蓄積する例を示している。
【００４２】
送受信処理部１５１は、装置Ｅ８とサイトサーバＳ１との間でフレーム（ＴＣＰ／ＩＰフレーム）を送受信する。尚、図１０では、サイトサーバＳ１と装置Ｅ８との間でフレームを送受信するが、サイトサーバＳ１に直接接続されない装置Ｅの場合は、サイトサーバＳ１ではなく、隣接する装置Ｅ間でフレームを送受信する。装置Ｅは複数のポートを有し、送受信処理部１５１はフレームの宛先に応じて各ポート間でフレームを送受信する。図１０の例では、装置Ｅ８はポート１にサイトサーバＳ１はポート１０にそれぞれ接続されており、他の装置Ｅ４、装置Ｅ６および装置Ｅ１１についてもそれぞれ他のポートに接続されている。
【００４３】
フレーム解析処理部１５２は、送受信処理部１５１で送受信されるフレームの内容を解析してＨＴＴＰデータであるか否かを判断する。そして、フレームがＨＴＴＰフレームである場合は、ＨＴＴＰヘッダに格納されているコマンド種別（ＲＦＣ２６１６に定義されているメソッド（ＧＥＴなど）やステータスコード（２００ＯＫなど））やＵＲＬ、送信元ＩＰおよび宛先ＩＰ、送信ポートおよび受信したフレームを送信ポートから出力する時刻などを抽出する。
【００４４】
データベース格納処理部１５３は、フレーム解析処理部１５２が抽出したＵＲＬ、種別、送信元ＩＰ、宛先ＩＰ、送信ポート、送信時刻などの情報をＨＴＴＰデータベース１５４に格納する。
【００４５】
ＨＴＴＰデータベース１５４は、装置Ｅ内のデータベースで、フレーム解析処理部１５２が抽出したＵＲＬ、種別、送信元ＩＰ、宛先ＩＰ、送信ポート、送信時刻などの情報が蓄積する。図１０の例では、サイトサーバＳ１に対応するＵＲＬ：ａａａの装置Ｅ８からサイトサーバＳ１へのＨＴＴＰリクエストフレーム（送信元ＩＰ：Ａ、宛先ＩＰ：Ｂ、コマンド：ＧＥＴ）は送信ポート１０（サイトサーバＳ１に接続されているポート）から送信時刻：ｔ２に送信されたことがＨＴＴＰデータベース１５４に蓄積される。そして、時刻ｔ２の後の時刻ｔ３では、時刻ｔ２のＨＴＴＰリクエストフレームの応答としてサイトサーバＳ１から受信するＨＴＴＰレスポンスフレーム（送信元ＩＰ：Ｂ、宛先ＩＰ：Ａ、コマンド：２００ＯＫ）をポート１から装置Ｅ８に送信されたことがＨＴＴＰデータベース１５４に蓄積される。ここで、ｔ２−ｔ１＝Ｔｒｅｓは、サイトサーバＳ１にＨＴＴＰリクエストフレームを送信してから装置Ｅ８にサイトサーバＳ１から受信したＨＴＴＰレスポンスフレームを送信するまでの時間に相当するので、装置Ｅ９での処理時間を無視すると、ＴｒｅｓはサイトサーバＳ１から情報を取得するまでの応答時間に相当する。
【００４６】
統計情報処理部１５５は、送受信処理部１５１で送受信されるフレームの統計解析を行う。例えば装置ＥのサイトサーバＳ１が接続されるポート１０や、装置Ｅ８が接続されるポート１におけるフレームの送受信量を統計処理する。図１０の例では、ポート１の送信量が１００Ｍｂｐｓおよび受信量が２００Ｍｂｐｓで、ポート１０の送信量が１００Ｍｂｐｓおよび受信量が５７００Ｍｂｐｓであることが統計情報データベース１５７からわかる。
【００４７】
統計情報格納処理部１５６は、統計情報処理部１５５が求めた統計情報を統計情報データベース１５７に蓄積する処理を行う。
【００４８】
統計情報データベース１５７は、装置Ｅ内のデータベースで、統計情報処理部１５５が求めた統計情報を蓄積する。図１０の例では、各ポートに対応する送信量と受信料とが蓄積される。
【００４９】
エッジ判別処理部１５８は、送受信処理部１５１で送受信されるフレームのヘッダに格納されるカウンタ値から自装置がサイトサーバＳ１のエッジ装置であるか否かの判別を行う。そして、エッジ装置である場合は監視サーバＡ１や検索サーバＫ１に通知する。尚、エッジ装置であるか否かの判別処理については、後で詳しく説明する。
【００５０】
負荷情報処理部１５９は、検索サーバＫ１および監視サーバＡ１からの要求に応じて、ＨＴＴＰデータベース１５４または統計情報データベース１５７に蓄積された情報から負荷情報を求めて監視サーバＡ１および検索サーバＫ１に送受信処理部１５１を介して送信する。負荷情報処理部１５９は、先に説明したように、ＨＴＴＰデータベース１５４に蓄積されたフレーム情報から応答時間やアクセス頻度などを負荷情報として算出したり、統計情報データベース１５７に蓄積された統計情報から使用帯域（或いは帯域使用率）などを負荷情報として算出して、負荷情報データベース１６０（ＨＴＴＰデータベース１５４や統計情報データベース１５７）に記憶する。そして、検索サーバＫ１は、装置Ｅから負荷情報を取得して、ＷＥＢ検索結果の画面に使用帯域や過去の使用帯域履歴、或いは応答時間やアクセス頻度などの負荷情報を表示することができる。尚、ここでは応答時間の算出や統計情報の処理を装置Ｅ側で行うようにしたが、基本的な情報（データ送受信量や送信時刻／受信時刻など）のみを装置Ｅ側の負荷情報データベース１６０に蓄積し、これらの基本的な情報を取得した検索サーバＫ１側で情報を適宜加工してＷＥＢ検索結果に表示するようにしてもよい。
【００５１】
このように、装置Ｅは構成され、送受信するフレームの解析や統計処理を行って送受信されるフレームの情報や統計情報を蓄積し、監視サーバＡ１や検索サーバＫ１からの要求に応じて、負荷情報を提供する。特に、装置Ｅは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバＡ１は管轄する全ての装置Ｅについてエッジ装置であるか否かの情報を予め保持しておく必要がなく、また、装置Ｅが増設されたり、サイトサーバＳ１が新たに装置Ｅに接続された場合でも常に最新のエッジ装置情報を得ることができる。
［エッジ装置の判別方法］
次に装置Ｅにおいて、自装置がサイトサーバのエッジ装置であるか否かを判別する方法について説明する。本実施形態に係るネットワークシステム１００に用いられる装置Ｅは、送受信するＴＣＰ／ＩＰフレームが本実施形態に係るネットワークシステム１００の機能に対応する場合に、ＩＰヘッダまたはＴＣＰヘッダにオプション領域を設け、受信したフレームを送信する時にオプション領域のカウンタをインクリメント（＋１）する。ここで、送信したフレームに対して受信するレスポンスフレームのカウント値が送信時のカウント値に一致する場合に自装置が当該フレームのＵＲＬに対応するサイトサーバのエッジ装置であると判断する。
【００５２】
尚、ＩＰフレームについて説明する。図１３はＲＦＣ−７９１に規定されるＩＰフレームの構成を示す図である。ＩＰフレームはヘッダ部とデータ部とを有し、ＩＰヘッダには、バージョン、ヘッダ長、サービスタイプ（ＴＯＳ）、データグラム長、ＩＤ、フラグ、フラグメント・オフセット、ＴＴＬ、プロトコル番号、ヘッダチェックサム、送信元ＩＰアドレス、宛先ＩＰアドレスが含まれている。さらに、オプションとして、オプションタイプ、レングス、ベンダーＩＤ、カウンタ６４ビットなどの情報をヘッダ部に付加することができる。ＩＰヘッダのオプション領域は０−４０ｂｙｔｅの可変領域で、オプションタイプのオクテットは、”１ｂｉｔのコピーフラグ”（０＝コピーしない／１＝コピーする）、“２ｂｉｔｓのオプションクラス”、”５ｂｉｔｓのオプションナンバー”を有する。
［ＩＰヘッダのオプション領域の使用例］
次に、本実施形態に係るネットワークシステム１００におけるＩＰヘッダのオプション領域の使用例を示す。尚、ここではＲＦＣ−２７８０に定義されていないタイプ値を使用する。
（１）オプションタイプ
・コピーフラグ：０（コピーしない）
・オプションクラス：２（デバックと計測を使用する）
・オプションナンバー：１６
（２）レングス：オプションタイプからカウンタまでの長さ
（３）ベンダーＩＤ（６ビット）：装置Ｅの製造メーカーのＩＤ
（４）カウンタ（６４ビットカウンタ）：装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは２の６４乗−１であり、上限値までカウントされた場合は、そのままカウントは停止する。そして、次の装置への転送時はそのままの上限値に固定する。また、装置ステップ数カウンタの上限値（２の６４乗−１）を最後にカウントした装置は、その時点で自装置がエッジ装置とみなし、監視サーバＡ１に通知する。２の６４乗−１は非常に大きな数字なので現実的には上限値に固定されることは少ないと考えられるが、上限値に達した時点でエッジ装置として判断するようにしてもよい。この場合、上限値のフレームを受信した装置以降に転送される装置は、カウントアップせずにそのまま転送する。尚、これらの装置はエッジ装置とはみなさないものとする。
【００５３】
また、エッジ装置として判定する条件は以下の通りである。
（１）カウントが変化していない場合。（尚、フォーマットは正しいものとする。）
（２）応答フレームのオプション領域の全てに０パディングされている場合。
（３）応答フレームのオプション領域が除去されている場合。
（４）本実施形態に係るネットワークシステム１００で指定したオプション領域のフォーマットに適合していない場合。
【００５４】
上記の（２）、（３）および（４）の場合は、本実施形態に係るネットワークシステム１００の装置Ｅ以外の機器を経由しているとみなす。
【００５５】
尚、自装置がエッジ装置であると判定された場合、且つ、本実施形態に係るネットワークシステム１００の装置Ｅ以外の機器を経由し、オプション領域に変更が加わっている場合（上記（１）〜（３）の場合）は、改めてオプション領域を付加し、カウンタ値に自装置が送信した時のカウンタを＋１した値を設定して次の装置に転送する。これにより、自装置以降の装置Ｅがエッジ装置であると誤判定することを防止できる。
［ＴＣＰヘッダのオプション領域の使用例］
上記の説明ではＩＰヘッダを利用したが、ＩＰヘッダではなくＴＣＰヘッダを利用しても構わない。ＴＣＰフレームはＩＰフレームのデータ部に格納され、ヘッダ部とデータ部とを有する。図１４はＲＦＣ−７９３に規定されるＴＣＰフレームの構成を示す図である。ＴＣＰヘッダには、送信元ポート、送信先ポート、シーケンス番号、ＡＣＫ番号、データオフセット、フラグ、ウィンドウサイズ、チェックサム、緊急ポインタなどが含まれる。さらに、オプションとして、オプション種別、レングス、ベンダーＩＤ、カウンタ６４ビットなどの情報をヘッダ部に付加することができる。ＴＣＰヘッダのオプション領域は０−４０ｂｙｔｅの可変領域である。オプションタイプの最初のオクテットはＫｉｎｄ（種類）を表す。
【００５６】
例えばＨＴＴＰフレームにおいて、ＩＰヘッダの代わりにＴＣＰヘッダのオプション領域の６４ビットカウンタを装置ステップ数カウンタとして用い、ＩＰヘッダの場合と同様にカウンタ値を判断することで自装置がエッジ装置であるか否かを判定する。
［ＴＣＰヘッダのオプション領域の使用例］
次に、本実施形態に係るネットワークシステム１００におけるＴＣＰヘッダのオプション領域の使用例を示す。尚、ここではＲＦＣ−２７８０に定義されていないタイプ値を使用する。
（１）オプションタイプ
・Ｋｉｎｄ：８０
（２）レングス：オプションタイプからカウンタまでの長さ
（３）ベンダーＩＤのフィールド：装置Ｅの製造メーカーのＩＤ
（４）カウンタ（６４ビットカウンタ）：装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは２の６４乗−１であり、上限値までカウントされた場合の動作は、ＩＰヘッダで説明した内容と同じである。
【００５７】
図１５は、ＩＰヘッダおよびＴＣＰヘッダのオプション領域の詳細フォーマット示す図である。本実施形態に係るネットワークシステム１００では、ＩＰヘッダのオプションタイプやＴＣＰヘッダのオプション種別が８０の時に本実施形態特有の機能に対応するフレームであることを示す。ベンダーＩＤは例えばネットワークシステム１００を構築する会社のＩＤなどが記載される。カウンタ６４ビットは、８Ｂｙｔｅのカウンタで、本実施形態に係るネットワークシステム１００では、オプションタイプが８０のフレームを受信して再び送信する時にカウンタを＋１する。或いは、オプション領域が無いフレームやオプション領域があってもオプションタイプが８０ではないときは、カウンタを１に設定する。
【００５８】
このようにして、本実施形態に係るネットワークシステム１００では、ＴＣＰ／ＩＰフレームを利用し、特にオプション領域のオプションタイプ（オプション種別）が８０の場合に本実施形態で説明する動作に対応する。尚、他社が別の目的にオプションタイプ（オプション種別）を８０にして使用する可能性があるので、ベンダーＩＤとオプションタイプ（オプション種別）の両方が予め設定した値に設定されている場合に本実施形態特有の動作に対応するようにしてもよい。そして、本実施形態に係るネットワークシステム１００では、カウンタを利用してサイトサーバＳ１の直近の装置Ｅであるか否かの判別を行う。
【００５９】
［カウンタによるエッジ装置判別の具体例］
次に、ＴＣＰ／ＩＰフレームのオプション領域のカウンタを用いて装置Ｅがサイトサーバの直近のエッジ装置であるか否かを判別する具体例について説明する。ここでは、本実施形態に係るネットワークシステム１００の機能を有する装置を経由する場合と有さない装置を経由する場合とに分けて説明する。
（本実施形態の機能を有する装置を経由する場合）
図１６は、説明がわかり易いように、図１で説明したネットワークシステム１００のネットワーク１０１の構成を簡略化した図である。図１６の例では、装置Ｅ２０,Ｅ２１，Ｅ２２，Ｅ２３、Ｅ２４の５台の装置Ｅがメッシュ状のネットワーク１０１を構成する。また、ユーザＰＣ１からサイトサーバＳ１までの経路は、例えばユーザＰＣ１から装置Ｅ２０を介してネットワーク１０１に接続し、ネットワーク１０１内では装置Ｅ２２を経由して装置Ｅ２３を介してサイトサーバＳ１に接続される。この場合は、装置Ｅ２３がサイトサーバＳ１の直近のエッジ装置に該当する。ここで、装置Ｅ２３自らがサイトサーバＳ１のエッジ装置であることを判別する流れについて説明する。
＜リクエスト時＞
（１）先ず、ユーザＰＣ１はＨＴＴＰリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。
（２）次に、装置Ｅ２０は、ユーザＰＣ１からＨＴＴＰリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを８０、カウンタを１、さらにレングスとベンダＩＤも設定して次の装置Ｅ２２に送信する。
（３）次に、装置Ｅ２２は、装置Ｅ２０からオプション領域（オプションタイプ：８０、カウンタ：１）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝２となる）して次の装置Ｅ２３に送信する。
（４）次に、装置Ｅ２３は、装置Ｅ２２からオプション領域（オプションタイプ：８０、カウンタ：２）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝３となる）して次の転送先に送信する。尚、この時点で装置Ｅ２３は次の送信先がサイトサーバＳ１であることを認識していない。
（５）そして、装置Ｅ２３からＨＴＴＰリクエストフレームを受信したサイトサーバＳ１は、ＨＴＴＰリクエストフレームに対応するＨＴＴＰレスポンスフレームを装置Ｅ２３に送信する。ここで、ＨＴＴＰレスポンスフレームのヘッダのオプション領域にはＨＴＴＰリクエストフレームのオプション領域の値がそのまま折り返される。
＜レスポンス時＞
（６）装置Ｅ２３は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値は３であり、先に送信したＨＴＴＰリクエストフレームのオプション領域のカウンタ値（＝３）と同じなので、自装置がエッジ装置であると認識する。そして、カウンタを＋１（カウンタ＝４となる）して次の装置Ｅ２２に送信する。また、監視サーバＡ１にこれを通知する。この時に監視サーバＡ１に通知する情報は、例えばサイトサーバＳ２のＭＡＣアドレスが含まれる。
（７）次の装置Ｅ２２は、装置Ｅ２３からオプション領域（オプションタイプ：８０、カウンタ：４）が設定されたＨＴＴＰレスポンスフレームを受信すると、受信したＨＴＴＰレスポンスフレームに対応するＨＴＴＰリクエストフレームの送信時のカウンタ値（＝２）と比較する。カウンタ値が異なるので、自装置はエッジ装置ではないとを認識して、カウンタ値を＋１してカウンタ値＝５として受信したＨＴＴＰレスポンスフレームを次の装置Ｅ２０に送信する。
（８）装置Ｅ２０は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値（＝５）と、送信時のＨＴＴＰリクエストフレームのカウンタ値（＝２）と異なるので、自装置がエッジ装置ではないと認識する。そして、カウンタを＋１（カウンタ＝６となる）にしてユーザＰＣ１に送信する。
【００６０】
このように、ＩＰヘッダまたはＴＣＰヘッダのカウンタを利用して各装置Ｅ自らがエッジ装置であるか否かを判別する。
（本実施形態の機能を有さない装置を経由する場合）
図１７は、図１６に対応する図で、同符号のものは同じものを示す。図１６と異なるのは、サイトサーバＳ２は装置Ｅ２４から本実施形態の機能に対応しないルータＲ１を介して接続されていることである。図１７において、ユーザＰＣ１からサイトサーバＳ２までの経路は、例えばユーザＰＣ１から装置Ｅ２０を介してネットワーク１０１に接続し、ネットワーク１０１内では装置Ｅ２０から装置Ｅ２４を経由してルータＲ１に接続され、ルータＲ１を介してサイトサーバＳ２に接続される。この場合は、装置Ｅ２４がサイトサーバＳ２の直近のエッジ装置に該当する。ここで、装置Ｅ２４自らがエッジ装置であることを判別する流れについて説明する。
＜リクエスト時＞
（１）先ず、ユーザＰＣ１はＨＴＴＰリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。
（２）次に、装置Ｅ２０は、ユーザＰＣ１からＨＴＴＰリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを８０、カウンタを１、さらにレングスとベンダＩＤも設定して次の装置Ｅ２２に送信する。
（３）次に、装置Ｅ２４は、装置Ｅ２０からオプション領域（オプションタイプ：８０、カウンタ：１）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝２となる）して次のルータＲ１に送信する。尚、この時点で装置Ｅ２４はエッジ装置であることを認識していない。
（４）次に、本実施形態の機能を有さないルータＲ１は、オプション領域に全て”０”パディングしてサイトサーバＳ２に送信する。
（５）そして、サイトサーバＳ２は、受信したＨＴＴＰリクエストフレームに対応するＨＴＴＰレスポンスフレームを返信する。ここで、ＨＴＴＰレスポンスフレームのヘッダのオプション領域はそのままＨＴＴＰリクエストフレームのオプション領域に格納され、そのまま折り返される。
＜レスポンス時＞
（６）本実施形態の機能を有さないルータＲ１は、サイトサーバＳ２から受信するＨＴＴＰレスポンスフレームのオプション領域に全て”０”パディングして装置Ｅ２４に送信する。
（７）次の装置Ｅ２４は、ルータＲ１から受信するＨＴＴＰレスポンスフレームのオプション領域が全て”０”なので、装置Ｅ２４以降に新たな装置Ｅが存在しないと判断し、自らがエッジ装置であると認識する。そして、監視サーバＡ１にこれを通知する。この時に監視サーバＡ１に通知する情報は、例えばサイトサーバＳ２のＭＡＣアドレスが含まれる。そして、装置Ｅ２４は、再び、オプション領域を付加すると同時に、オプションタイプを８０、カウンタを３、さらにレングスとベンダＩＤも設定して次の装置Ｅ２０に送信する。ここで、カウンタ値を初期化（１に設定）せずに、ＨＴＴＰリクエストフレームを転送時（上記の（２）の処理）のカウンタ値（＝２）を＋１したカウンタ値（＝３）をＨＴＴＰレスポンスフレームに格納して次の装置Ｅ２０に送信する。
（８）装置Ｅ２０は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値（＝３）と、送信時のＨＴＴＰリクエストフレームのカウンタ値（＝１）とを比較して、一致しないので自装置がエッジ装置ではないと判断する。そして、カウンタを＋１（＝４）にしてユーザＰＣ１に送信する。
【００６１】
このように、ＩＰヘッダまたはＴＣＰヘッダのカウンタを利用して装置Ｅ自らがエッジ装置であるか否かを判別する。
【００６２】
［装置Ｅの処理］
次に、装置Ｅの処理について、図１８および図１９のフローチャートを用いて説明する。図１８は、ＨＴＴＰリクエスト時の処理を示すフローチャートである。先ず、ユーザＰＣ１は、ＨＴＴＰリクエストフレームを送信する。このＨＴＴＰリクエストフレームには、オプション領域は設定されておらず、ヘッダとデータのみで構成される通常のＩＰフレームである。
【００６３】
（ステップＳ１０１）装置Ｅは、ユーザＰＣ１から受信したＨＴＴＰリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件とは、本実施形態に係るネットワークシステム１００の機能に対応するフレームの条件（オプションタイプ＝８０、レングス／ベンダＩＤ内容、カウンタ値など）である。例えば所定条件が以下の（１）から（３）のいずれかに該当する場合（Ｙｅｓ）はステップＳ１０２に進み、いずれにも該当しない場合（Ｎｏ）はステップＳ１０３に進む。
（１）オプション領域が全て”０”パディングされている。
（２）オプション領域が存在しない。
（３）オプションタイプが８０ではない、ベンダＩＤが異なる、カウンタ値が”０”である、など本実施形態で予め定めたフォーマットに合っていない。
（ステップＳ１０２）装置Ｅは、オプション領域のカウンタ値を”１”に設定する。
（ステップＳ１０３）装置Ｅは、オプション領域のカウンタ値をインクリメント（＋１）する。
【００６４】
そして、オプション領域が設定されたＨＴＴＰリクエストフレームを次の装置Ｅに転送する。同様に、次の装置Ｅからその次の装置ＥにＨＴＴＰリクエストフレームを転送してサイトサーバＳ１まで送信する。
（ステップＳ１０４）装置Ｅは、オプション領域のカウンタ値を内部メモリやＨＴＴＰデータベース１５４などに保持する。上記の例では、カウンタ値＝１が保持される。
【００６５】
次に、ＨＴＴＰリクエストフレームを受信したサイトサーバＳ１は、ＨＴＴＰレスポンスフレームを返信する。返信時の処理について図１９のフローチャートを用いて説明する。サイトサーバＳ１が返信するＨＴＴＰレスポンスフレームは、装置Ｅから装置Ｅへ転送されながらユーザＰＣ１まで送信される。
（ステップＳ２０１）装置Ｅは、受信したＨＴＴＰリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件は先にステップＳ１０１で説明した条件と同じである。Ｙｅｓの場合はステップＳ２０２に進み、Ｎｏの場合はステップＳ２０３に進む。
（ステップＳ２０２）装置Ｅは、オプション領域を再設定して、ステップＳ１０４で保持したＨＴＴＰリクエストフレームのカウンタ値をインクリメント（＋１）した値を新たなカウンタ値として設定する。
（ステップＳ２０３）装置Ｅは、図１８のステップＳ１０４で保持したＨＴＴＰリクエストフレームのカウンタ値と、ＨＴＴＰレスポンスフレームのカウンタ値とが等しいか否かを判別する。Ｙｅｓの場合はステップＳ２０４に進み、Ｎｏの場合はステップＳ２０５に進む。
（ステップＳ２０４）装置Ｅは、自装置がエッジ装置であると認識して、監視サーバＡ１に自装置がエッジ装置であることを通知する。
（ステップＳ２０５）装置Ｅは、ＨＴＴＰレスポンスフレームのカウンタ値をインクリメント（＋１）する。そして、次の装置Ｅに転送する。図１９の例では、次の装置がユーザＰＣ１なので、ユーザＰＣ１にＨＴＴＰレスポンスフレームを送信する。
【００６６】
このようにして、ユーザＰＣ１から送信されたＨＴＴＰリクエストフレームは、オプション領域が設定され、カウンタ値を設定またはインクリメントしながらサイトサーバＳ１に送信され、サイトサーバＳ１から返信されるＨＴＴＰレスポンスフレームについても同様にオプション領域のカウンタ値を再設定またはインクリメントしながらユーザＰＣ１まで送信される。そして、ＨＴＴＰリクエストフレームを送信する際のカウンタ値と、受信するＨＴＴＰレスポンスフレームのカウンタ値とが等しい場合に自装置がエッジ装置であると判断して、監視サーバＡ１に自装置がエッジ装置であることを通知する。
【００６７】
このように、装置Ｅは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバＡ１は管轄する全ての装置Ｅがエッジ装置であるかの情報を予め保持しておく必要がなく、また、装置Ｅが増設されたり、サイトサーバＳ１が新たに装置Ｅに接続された場合でも常に最新のエッジ装置情報を得ることができる。
【００６８】
［複数の基幹ネットワークが接続されている場合］
先に説明した図１のネットワークシステム１００は、１つのネットワーク１０１内に監視サーバＡ１、検索サーバＫ１、サイトサーバＳ１が配置されているので、監視サーバＡ１はネットワーク１０１を構成する全ての装置Ｅの状態を監視することができた。しかし実際には、ネットワーク１０１のような複数の基幹ネットワークが装置Ｅを介して互いに接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。ここでは、複数の基幹ネットワークを有する場合の例について説明する。
【００６９】
図２０は、基幹ネットワークＡの装置Ｘを介して基幹ネットワークＢに接続されたネットワークシステム１００ａの構成例を示した図である。図２０において、基幹ネットワーク１０１ａは、先に説明したネットワーク１０１に対応し、ユーザＰＣ１と、検索サーバＫ１と、監視サーバＡ１とがネットワーク１０１に接続されている。そして、装置Ｘを介して基幹ネットワーク１０１ｂに接続され、ネットワーク１０１ｂには、監視サーバＡ２と、サイトサーバＳ２とが接続されている。
【００７０】
ここで、ユーザＰＣ１が検索サーバＫ１に検索キーワードを含む検索要求を送信し、検索サーバＫ１は自分が持っている情報などから検索キーワードに該当する情報を公開している基幹ネットワーク１０１ｂのサイトサーバＳ２（ＵＲＬ）が抽出される。そして、検索サーバＫ１は監視サーバＡ１に該当するサイトサーバＳ２の情報（ＵＲＬ）があるか否かを問い合わせる。監視サーバＡ１に該当するサイトサーバＳ２の情報（ＵＲＬ）がない場合は、検索サーバＫ１は監視サーバＡ１に他の監視サーバＡ２に対してサイトサーバＳ２の情報（ＵＲＬ）を持っているか否かを問い合わせる。
【００７１】
問い合わせを受けた監視サーバＡ２はサイトサーバＳ２の情報（ＵＲＬ）があるか否かを検索し、ある場合は監視サーバＡ１に対して応答する。応答を受けた監視サーバＡ１は、応答を返した監視サーバＡ２に対してサイトサーバＳ２のエッジ装置の負荷情報を要求する。要求を受けた監視サーバＡ２は、保持しているサイトサーバＳ２のエッジ装置Ｙの負荷情報を監視サーバＡ１に応答する。
これを受けた監視サーバＡ１は、その負荷情報を検索サーバＫ１に送信する。
【００７２】
このようにして、異なる基幹ネットワーク１０１ａおよび基幹ネットワーク１０１ｂが接続される場合でも、それぞれのネットワークの監視サーバＡ１および監視サーバＡ２とが連携して該当するサイトサーバのエッジ装置から負荷情報を取得して、要求元の検索サーバＫ１に負荷情報を送信するので、検索サーバＫ１は、先の実施形態と同様に、検索結果のＵＲＬに対応する負荷情報をユーザＰＣ１に提供することができる。
【００７３】
次に、複数の基幹ネットワークを有する場合のネットワークシステム１００１ａの動作シーケンスについて図２１を用いて説明する。図２１において、ユーザＰＣ１は検索サーバＫ１に検索キーワードを含む検索要求（ＨＴＴＰリクエスト）を送信する。検索サーバＫ１は、自身の検索サーバデータベース３０２を参照して、検索キーワードを含むＵＲＬリストを抽出する。そして、検索結果の各ＵＲＬに対応する負荷情報を取得するためにサイトサーバの情報を持っているか否かを監視サーバＡ１に問い合わせる。図２０の例では、基幹ネットワーク１０１ａを管轄する監視サーバＡ１は、基幹ネットワーク１０１ｂに配置されているサイトサーバＳ２の情報を持っていないので、検索サーバＫ１にサイトサーバＳ２の情報無しの応答を行う。これを受けた検索サーバＫ１は、監視サーバＡ１にサイトサーバＳ２の情報を取得するように依頼する。
【００７４】
一方、監視サーバＡ１は、サイトサーバＳ２の情報を取得するように検索サーバＫ１から依頼を受けると、他の基幹ネットワークに監視サーバＡ２、監視サーバＡ３および監視サーバＡ４などにサイトサーバＳ２の情報を持っているか否かの問い合わせを行う。そして、図２０の例では、基幹ネットワーク１０１ｂの監視サーバＡ２がサイトサーバＳ２に接続されるエッジ装置Ｙを管轄しているので、サイトサーバＳ２の情報を持っていることを監視サーバＡ１に応答する。尚、監視サーバＡ２は、先の実施形態で説明したように、サイトサーバＳ２のエッジ装置が装置Ｙであることを装置Ｙ自身から通知されているので、サイトサーバＳ２のＵＲＬに対応するエッジ装置が装置Ｙであることを認識している。また、サイトサーバＳ２の情報を持っていない監視サーバＡ３および監視サーバＡ４からは応答されない。
【００７５】
そして、監視サーバＡ２からサイトサーバＳ２の情報を持っているという応答を受信した監視サーバＡ１は、監視サーバＡ２に対してエッジ装置の負荷情報を要求する。これを受けた監視サーバＡ２は、先の実施形態で説明した手順でエッジ装置ＹからサイトサーバＳ２が接続されているポートの負荷情報を取得して監視サーバＡ１に応答する。そして、監視サーバＡ１から検索サーバＫ１にエッジ装置Ｙの負荷情報が送信され、検索サーバＫ１で検索結果のＵＲＬに対応する負荷情報を表示してユーザＰＣ１に検索結果として提供する。
【００７６】
このようにして、サイトサーバＳ２がユーザＰＣ１および検索サーバＫ１が接続される基幹ネットワーク１０１ａとは異なる基幹ネットワーク１０１ｂにある場合でも、基幹ネットワーク１０１ａの監視サーバＡ１から基幹ネットワーク１０１ｂの監視サーバＡ２に問い合わせることによって、先の実施形態と同様に、ユーザＰＣ１で検索結果のＵＲＬ毎に負荷情報が表示された画面を確認することができる。
【００７７】
［異なる基幹ネットワークに接続する装置の処理］
次に、図２０で説明したネットワークシステム１００ａにおいて、基幹ネットワーク１０１ａの装置Ｘは、基幹ネットワーク１０１ｂへの接続口になっている。このため、装置Ｘは、先に説明した図１７のルータＲ１に接続される装置Ｅ２４の場合と同様に、自装置がエッジ装置であると判断し、監視サーバＡ１にこれを通知することが考えられる。この場合は、図２２に示すように、監視サーバＡ１内の監視サーバデータベース３０１に他の基幹ネットワークに接続している装置リストを予め登録しておくことにより、装置Ｘから自装置がエッジ装置であると通知してきた場合でも、エッジ装置ではないと判断できる。そして、図２１で説明したように、他の基幹ネットワークの監視サーバに対して問い合わせを行い、実際にサイトサーバに接続されているエッジ装置から負荷情報を取得することができる。
【００７８】
このようにして、他の基幹ネットワークに接続している装置リストを監視サーバに予め登録しておくことにより、他の基幹ネットワークへの接続口の装置がエッジ装置であると誤認識した場合でも、当該装置が真のエッジ装置であるか否かの判断を行うことができ、必要に応じて他の基幹ネットワークの監視サーバから真のエッジ装置の負荷情報を取得することができる。
【００７９】
以上、各実施形態において説明してきたように、本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別してサイトサーバのＵＲＬに対する負荷情報を蓄積し、検索サーバはエッジ装置から取得した負荷情報と検索結果のＵＲＬとを対応させたＷＥＢ検索結果を端末装置に提供することができる。
【００８０】
尚、本発明に係る設定情報参照起動型の制御装置および設定情報管理方法について、各実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。
【符号の説明】
【００８１】
１００・・・ネットワークシステム
１０１・・・ネットワーク
１５１・・・送受信処理部
１５２・・・フレーム解析処理部
１５３・・・データベース格納処理部
１５４・・・ＨＴＴＰデータベース
１５５・・・統計情報処理部
１５６・・・統計情報格納処理部
１５７・・・統計情報データベース
１５８・・・エッジ判別処理部
１５９・・・負荷情報処理部
１６０・・・負荷情報データベース
３０１・・・監視サーバデータベース
３０２・・・検索サーバデータベース
ＰＣ１，ＰＣ２・・・ユーザＰＣ（パソコン）
Ｅ１〜Ｅ１１，Ｅ２０〜Ｅ２４，Ｘ，Ｙ・・・装置（Ｌ２スイッチ装置）
Ａ１，Ａ２，Ａ３，Ａ４・・・監視サーバ
Ｋ１・・・検索サーバ
Ｓ１，Ｓ２，Ｓ３・・・サイトサーバ
【技術分野】
【０００１】
本発明は、エッジ装置に接続されるサイトサーバにアクセスするネットワークの輻輳状態を確認できるネットワークシステムに関する。
【背景技術】
【０００２】
近年のインターネットの普及により、様々な情報を簡単に収集できるようになってきた。これに伴って検索サーバの検索技術や検索結果の表示技術は大きく進歩し、ますます効率的に情報収集が行えるようになってきた。一方、インターネットのインフラである基幹ネットワークを構成するＬ２ＳＷ（レイヤ２のスイッチ装置）には、流れるデータの情報やデータ量を統計的に保持する機能を有する装置が普及している（例えば、特許文献１参照）。さらに、これらの装置を遠隔から監視するシステムも同時に進歩してきた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−２３６１９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術では、メッシュ状のネットワークを構成する複数のスイッチ装置のうちＷＥＢサービスを提供するサイトサーバ直近に接続されているスイッチ装置（エッジ装置と称する）を特定することができないので、エッジ装置自体の負荷状態（アクセス頻度などを含むものとする）を知ることができないという問題があった。また、他の基幹ネットワークにサイトサーバがある場合は、ユーザが属する基幹ネットワークの監視サーバは他の基幹ネットワークの負荷情報は知ることができないという問題があった。
【０００５】
上記課題に鑑み、本発明の目的は、エッジ装置を特定して、エッジ装置の負荷情報を取得し、ＷＥＢ検索結果に関連付けて表示できるネットワークシステムを提供することである。
【課題を解決するための手段】
【０００６】
本発明に係るネットワークシステムは、メッシュ状のネットワークを構成する複数のスイッチ装置と、ＷＥＢサービスを提供するサイトサーバと、前記ネットワークに接続される端末装置のＷＥＢ検索要求に応じて前記サイトサーバのＵＲＬ情報をＷＥＢ検索結果として前記端末装置に提供する検索サーバと、前記複数のスイッチ装置の状態を監視する監視サーバとを有し、前記検索サーバは、前記端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供することを特徴とする。
【０００７】
また、前記スイッチ装置は、フレームを送受信する送受信処理部と、前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、前記負荷情報を蓄積するデータベースと、自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部とを有することを特徴とする。
【０００８】
さらに、前記スイッチ装置のエッジ判別処理部は、前記フレームの中のＨＴＴＰリクエストフレームを格納するＩＰフレームまたはＴＣＰフレームのヘッダ部にカウンタを設けて、前記ＩＰフレームまたは前記ＴＣＰフレームを転送する毎に前記カウンタをカウントアップし、前記ＨＴＴＰリクエストフレームを送信時の前記カウンタ値を第１カウンタ値として保持し、前記ＨＴＴＰリクエストフレームに対するＨＴＴＰレスポンスフレームを格納する前記ＩＰフレームまたは前記ＴＣＰフレームのヘッダ部の前記カウンタ値を第２カウンタ値として前記第１カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断することを特徴とする。
【０００９】
特に、前記スイッチ装置は、レイヤ２スイッチであることを特徴とする。
【００１０】
また、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値であることを特徴とする。
【００１１】
或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間であることを特徴とする。
【００１２】
または、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度であることを特徴とする。
【００１３】
或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値であることを特徴とする。
【００１４】
特に、前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供することを特徴とする。
【００１５】
また、前記サイトサーバが前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークにある場合、前記第２基幹ネットワークの検索サーバは、前記第１基幹ネットワークの監視サーバの情報と前記第２基幹ネットワークの監視サーバの情報とを取得することを特徴とする。
【００１６】
特に、前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記第１基幹ネットワークの検索サーバが前記第２基幹ネットワークの監視サーバの情報を持っていない場合、前記第１基幹ネットワークの監視サーバは、前記第２基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得することを特徴とする。
【００１７】
さらに、前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断することを特徴とする。
【発明の効果】
【００１８】
本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別し、検索サーバはエッジ装置から取得した負荷情報とＵＲＬとを対応させたＷＥＢ検索結果を端末装置に提供することができる。
【図面の簡単な説明】
【００１９】
【図１】ネットワークシステム１００の構成例を示す図である。
【図２】検索サーバＫ１が提供する検索サイトで検索キーワードを入力する例を示す図である。
【図３】一般的なＷＥＢ検索結果画面例を示す図である。
【図４】負荷情報として使用帯域を表示するＷＥＢ検索結果画面例を示す図である。
【図５】負荷情報として使用帯域履歴を表示するＷＥＢ検索結果画面例を示す図である。
【図６】負荷情報として応答時間を表示するＷＥＢ検索結果画面例を示す図である。
【図７】負荷情報としてアクセス頻度を表示するＷＥＢ検索結果画面例を示す図である。
【図８】エッジ装置、検索サーバＫ１および監視サーバＡ１間の情報の流れを示す図である。
【図９】ユーザＰＣ１によるＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までの流れを示す図である。
【図１０】装置Ｅの構成例を示す図である。
【図１１】装置Ｅのその他の構成例を示す図である。
【図１２】装置Ｅのその他の構成例を示す図である。
【図１３】ＩＰヘッダの構成を示す図である。
【図１４】ＴＣＰヘッダの構成を示す図である。
【図１５】オプション領域のフォーマットを示す図である。
【図１６】本実施形態に係るネットワークシステム１００におけるエッジ装置判定の一例を示す図である。
【図１７】本実施形態の機能に対応しない装置がある場合のエッジ装置判定の一例を示す図である。
【図１８】カウンタによるエッジ装置判定の処理を示すフローチャートである。
【図１９】カウンタによるエッジ装置判定の処理を示すフローチャートである。
【図２０】複数の基幹ネットワークを有するネットワークシステム１００ａの構成例を示す図である。
【図２１】ネットワークシステム１００ａにおけるユーザＰＣ１によるＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までの流れを示す図である。
【図２２】ネットワークシステム１００ａにおける監視サーバＡ１の処理例を示す図である。
【発明を実施するための形態】
【００２０】
以下、本発明に係るネットワークシステムの実施形態について詳しく説明する。
【００２１】
図１は、本実施形態に係るネットワークシステム１００の構成例を示す図である。図１において、ネットワークシステム１００は、メッシュ状のネットワーク１０１を構成する複数のＬ２スイッチ装置（図１の例では装置Ｅ１から装置Ｅ１１）と、検索サーバＫ１と、監視サーバＡ１と、サイトサーバＳ１とを有する。尚、装置Ｅ１から装置Ｅ１１に共通の事項を説明する場合は装置Ｅと表記する。また、本実施形態における動作説明では、サイトサーバＳ１の動作について説明するが、実際には点線で示したように、サイトサーバＳ２およびサイトサーバＳ３などの複数のサイトサーバが用いられる。ここで、サイトサーバとは、ｈｔｔｐ対応のホームページなどを提供するサーバでＷＥＢサーバとも呼ばれている。また、検索サーバとは、装置Ｅに接続されるユーザ端末装置（図１の例ではユーザＰＣ１またはユーザＰＣ２）から送信される検索キーワードを含む情報を公開しているサイトサーバのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を検索して、検索結果（ＵＲＬリストなど）をユーザ端末装置に返信するサーバである。さらに、監視サーバとは、管轄する基幹ネットワーク（図１の例ではネットワーク１０１）内の全装置Ｅの動作設定や動作状態の監視および制御などを行うためのサーバである。また、図１では、１つのネットワーク１０１内に閉じているが、複数の基幹ネットワークが装置Ｅを介して接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。尚、複数の基幹ネットワークを有する場合の実施形態については後で詳しく説明する。
【００２２】
図１において、ユーザＰＣ１は装置Ｅ１を介してネットワーク１０１に接続され、ユーザＰＣ２は装置Ｅ２を介してネットワーク１０１に接続されている。また、サイトサーバＳ１は装置Ｅ９を介してネットワーク１０１に接続され、検索サーバＫ１および監視サーバＡ１は装置Ｅ３および装置Ｅ４を介してそれぞれネットワーク１０１に接続されている。尚、検索サーバＫ１と監視サーバＡ１は別のネットワークで接続されていてもよい。
【００２３】
先ず、ユーザＰＣ１から検索サーバＫ１に検索キーワードを送信して検索キーワードが含まれる情報を公開しているサイトサーバのＵＲＬを検索する場合の動作について説明する。例えばユーザＰＣ１は一般に用いられているＤＮＳサーバ（図１には記載せず）を介して検索サーバＫ１に接続する。そして、ユーザＰＣ１の画面には、図２に示すように、検索サーバＫ１から受信する検索画面が表示される。ユーザが検索キーワード（図２の例では「食品Ａ レシピ」）を入力して検索ボタンを押下すると、検索キーワードが検索サーバＫ１に送られる。そして、検索サーバＫ１は受信する検索キーワードに該当する情報を有するサイトサーバ（図１の例ではサイトサーバＳ１，Ｓ２，Ｓ３など）へアクセスするためのＵＲＬを検索し、ＵＲＬリストなどの検索結果をユーザＰＣ１に送信する。
【００２４】
図３は検索サーバＫ１から受信した検索結果の画面例を示す図である。検索結果には、検索キーワードを含む公開情報２０１やサイトサーバのＵＲＬ２０２ａ（ｗｗｗ．ａｂｃｄｅｆ．ｃｏｍ／ａａａ１２３／・・・）などが表示される。ここで、例えばＵＲＬ２０２ａはサイトサーバＳ１のＵＲＬ、ＵＲＬ２０２ｂはサイトサーバＳ２のＵＲＬ、ＵＲＬ２０２ｃはサイトサーバＳ３のＵＲＬのようにそれぞれ対応する。そして、ユーザＰＣ１で例えばＵＲＬ２０２ａを選択（マウスカーソルでクリック）すると、ユーザＰＣ１からネットワーク１０１を介してサイトサーバＳ１に接続され、サイトサーバＳ１から当該ＵＲＬに対応するホームページなどが表示される。
【００２５】
このようにして、ユーザＰＣ１は、見たい情報を提供するサイトサーバのＵＲＬを検索サーバＫ１を介して検索し、検索結果の中から選択したＵＲＬのサイトサーバから必要な情報を得ることができる。
【００２６】
ところが、図３の例では、検索結果の画面から各ＵＲＬを提供するサイトサーバにアクセスする際の負荷状態（サイトサーバの混雑状態やサイトサーバに接続する経路の混雑状態などを含む）をユーザーは知ることができない。
【００２７】
そこで、本実施形態に係るネットワークシステム１００では、検索サーバＫ１が作成してユーザＰＣ１に送信する検索結果の各ＵＲＬ毎に負荷情報を表示できるようになっている。例えば図４では、負荷情報として、当該サイトサーバにアクセスする際の使用帯域を表示する様子を示している。図４の場合、ＵＲＬ２０２ａの使用帯域２０３ａは３０％程度で空いているが、ＵＲＬ２０２ｂの使用帯域２０３ｂは８０％以上で混雑していることをユーザは検索結果の画面を見て知ることができる。これにより、例えばユーザは、アクセスが遅くなる可能性が高いＵＲＬ２０２ｂの選択を避けて、ＵＲＬ２０２ａやＵＲＬ２０２ｃなどを選択することができる。ここで、使用帯域（或いは帯域使用率）は、現帯域使用量（送信量または受信量）／最大帯域使用量（ポート毎に決められた最大送信量または最大受信量）（％）により求めることができる。
【００２８】
また、図５の例では、図４で説明した使用帯域の過去の履歴（図５の例では２日前までの履歴）を検索結果画面の各ＵＲＬ毎に表示する。これにより、例えばユーザは、ＵＲＬ２０２ａは過去の使用帯域２０４ａから本日だけ混雑していること、ＵＲＬ２０２ｂは過去の使用帯域２０４ｂからいつも空いていること、などの負荷情報を知ることができる。
【００２９】
さらに、図６の例では、応答時間を検索結果画面の各ＵＲＬ毎に表示する。尚、応答時間は、サイトサーバが接続されるエッジ装置Ｅとサイトサーバとの間の回線帯域とサイトサーバ自体の処理負荷を含むので、実際にアクセスした時のレスポンスが速さを知ることができる。これにより、例えばユーザは、ＵＲＬ２０２ａは応答時間２０５ａが０．３秒なのでレスポンスが速い、ＵＲＬ２０２ｂは応答時間２０５ｂが５．３秒なのでレスポンスが遅い、などの判断を行うことができる。
【００３０】
また、図７の例では、統計情報として直近のアクセス頻度（１時間当りのアクセス件数）を検索結果画面の各ＵＲＬ毎に表示する。尚、従来技術として過去のアクセス件数を表示するものもあるが、図７の場合は直近のアクセス頻度を表示することができる。これにより、例えばユーザは、ＵＲＬ２０２ａの直近の１時間のアクセス件数が５１０００件で、ＵＲＬ２０２ｂの直近の１時間のアクセス件数は１０００件なので、ＵＲＬ２０２ａの方がレスポンスが遅い可能性があるという判断を行うことができる。
【００３１】
このようにして、本実施形態に係るネットワークシステム１００では、検索サーバの検索結果画面から各ＵＲＬを提供するサイトサーバにアクセスする際の負荷状態をアクセスする前に知ることができる。これにより、ユーザは、比較的レスポンスが速いサイトサーバのＵＲＬを選択することができる。尚、負荷情報は、過去の同時刻の装置の負荷情報からその平均値を表示するようにしてもよい。
【００３２】
次に、本実施形態に係るネットワークシステム１００において、各装置Ｅと検索サーバＫ１および監視サーバＡ１との間で送受信される情報について図８のシーケンス図を用いて説明する。尚、ネットワークシステム１００はＳＮＭＰプロトコルに対応し、制御情報を送受信する。
【００３３】
図８において、監視サーバＡ１は、管轄するネットワーク１０１内の全装置Ｅから各装置Ｅに接続されるサイトサーバのＵＲＬ情報を収集する。ＵＲＬ情報の収集は、例えば監視サーバＡ１が全装置Ｅに対して定期的にポーリングを行って収集してもよいし、ポーリング対象の装置Ｅを自装置がエッジ装置であるという通知をしてきた装置Ｅに限定してもよい。或いは、ポーリングを行わずに装置Ｅから自装置がエッジ装置であるという通知を受けたときだけ、当該装置からＵＲＬ情報を収集するようにしてもよい。
【００３４】
ここで、後で説明するように装置Ｅは自装置があるサイトサーバのエッジ装置であるか否かを判別する機能を有している。そして、装置Ｅは、自装置がエッジ装置であると判断した場合に監視サーバＡ１に自装置がエッジ装置であることを通知する。装置Ｅは、自装置に接続されるサイトサーバのＵＲＬ情報を蓄積したＨＴＴＰデータベース１５４や帯域使用率やアクセス件数などの統計情報を蓄積する統計情報データベース１５７を有している。尚、いずれか１つのデータベースでもよいし、両方の情報を１つのデータベースに集約してもよい。監視サーバＡ１は装置Ｅに対して「ＳＮＭＰ ＧＥＴ」コマンドを送信してポーリングを行い、装置Ｅは自装置内のＨＴＴＰデータベース１５４に蓄積されたＵＲＬ情報を「ＳＮＭＰレスポンス」として監視サーバＡ１に返信する。監視サーバＡ１は、各装置Ｅから収集したＵＲＬ情報を各装置Ｅの装置ＩＤに対応付けて、監視サーバＡ１内の監視サーバデータベース３０１に保持する。これにより、監視サーバＡ１は、どの装置ＥがどのＵＲＬについての情報を保持しているかを管理することができる。
【００３５】
同様に検索サーバＫ１は、複数の監視サーバに対してＳＮＭＰによる定期的なポーリングを行い、各ＵＲＬ毎にどの監視サーバの配下のどの装置Ｅに属しているのかを示す情報を得ることができる。図８の例では、検索サーバＫ１は監視サーバＡ１から収集した情報を自身の検索サーバデータベース３０２に蓄積する。尚、図８の例では、検索サーバＫ１は監視サーバＡ１を介して装置Ｅの情報を直接収集するようにしてもよい。これにより、装置情報を収集する時に検索サーバＫ１と監視サーバＡ１との間で情報を送受信する必要が無くなるため、装置Ｅの負荷情報をより速く検索画面に表示できる。
【００３６】
次に、図８で説明したシーケンスにより、監視サーバＡ１と検索サーバＫ１とにＵＲＬに関する情報が蓄積された状態にある場合に、ユーザＰＣ１が検索サーバＫ１に検索キーワードを含むＨＴＴＰリクエストフレームを送信すると、検索サーバＫ１は検索キーワードを含むＷＥＢページを有するサイトサーバのＵＲＬを検索する。この処理は、一般的に行われている検索サーバの情報検索サービスと同じである。従来の検索サーバでは、この時点の検索結果をＨＴＴＰレスポンスとしてユーザ側に返信して検索結果画面がユーザＰＣ１に表示されていた（図３）。
【００３７】
これに対して、本実施形態に係るネットワークシステム１００では、図９に示すように、検索サーバＫ１は、自身の検索サーバデータベース３０２を参照して、検索結果の各ＵＲＬに対応するエッジ装置Ｅを管轄する監視サーバＡ１に対して「ＳＮＭＰ ＧＥＴ」コマンドを送信し、目的のＵＲＬを持つサイトサーバに接続されるエッジ装置Ｅのポートの負荷情報（例えば帯域使用率やアクセス頻度など）を要求する。そして、この要求を受けた装置Ｅは自身が保持しているＨＴＴＰデータベース１５４や統計情報データベース１５７を参照して、要求された負荷情報を求める。例えば負荷情報がアクセス頻度である場合は、エッジ装置Ｅから当該ＵＲＬに相当するサイトサーバへのアクセス数（例えばＨＴＴＰの＜ｈｏｓｔ＞までの部分一致検索でヒットするもの）を取得する。尚、＜ｈｏｓｔ＞は、フォーマット（ｈｔｔｐ：／／＜ｈｏｓｔ＞：＜ｐｏｒｔ＞／＜ｐａｔｈ＞？＜ｓｅａｒｃｈｐａｒｔ＞）で示されるＵＲＬの一部でＲＦＣ１７３８に定められている。
【００３８】
アクセス数は、装置自身が保持しているＨＴＴＰデータベース１５４に格納しているデータベースの中からＨＴＴＰリクエストフレームにあるＵＲＬに該当するデータのうち、種別がＨＴＴＰフレームのヘッダ情報がＧＥＴであり、且つ、装置Ｅからサイトサーバへの送信時刻が現在時刻から１時間以内であるデータの個数をアクセス頻度として求める。そして、求めたアクセス頻度を「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」に格納して監視サーバＡ１に送信する。同様に、要求された負荷情報が帯域使用率の場合は、統計情報データベース１５７に蓄積されている装置Ｅのサイトサーバが接続されているポートの送信量（または受信量）を設定されている最大送信量（または最大受信量）で割って帯域使用率（％）を求め、これを「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」に格納して監視サーバＡ１に送信する。監視サーバＡ１は装置Ｅから受信した「ＳＮＭＰ ＲＥＳＰＯＮＳＥ」の負荷情報を検索サーバＫ１に送信し、検索サーバＫ１は監視サーバＡ１から受信した負荷情報を先に検索した検索結果の該当するＵＲＬに対応付けた「ＨＴＴＰレスポンス」をユーザＰＣ１に送信する。尚、この場合は送信量／最大送信量と受信量／最大受信量の２つの値の大小を比較して、大きい値を監視サーバＡ１に送信するようにしても構わない。
【００３９】
このようにして、ユーザＰＣ１では、先に図４、図５、図６および図７で説明したように、負荷情報を含む検索結果画面を閲覧することができる。
［装置Ｅの構成］
次に装置Ｅの構成例について図１０を用いて説明する。尚、図１０は図１の一部分を抜き出した図で、図１におけるサイトサーバＳ１に接続されるエッジ装置（装置Ｅ９）と、装置Ｅ９に接続される装置Ｅ８を示している。また、図１０では、装置Ｅ９の構成例を描いてあるが、他の装置Ｅについても同様に構成される。
【００４０】
図１０において、装置Ｅ９は、送受信処理部１５１と、フレーム解析処理部１５２と、データベース格納処理部１５３と、ＨＴＴＰデータベース１５４と、統計情報処理部１５５と、統計情報格納処理部１５６と、統計情報データベース１５７と、エッジ判別処理部１５８とで構成される。尚、フレーム解析処理部１５２とデータベース格納処理部１５３および統計情報処理部１５５と統計情報格納処理部１５６は、負荷情報を求めるためのブロック（負荷情報処理部１５９）として１つにまとめてもよい。同様に、ＨＴＴＰデータベース１５４および統計情報データベース１５７を負荷情報データベース１６０として１つにまとめてもよい。そして、負荷情報処理部１５９は、フレーム解析処理部１５２で送受信されるフレーム情報や統計情報などから得られる負荷情報を負荷情報データベース１６０に蓄積する処理や、負荷情報データベース１６０に蓄積された負荷情報を監視サーバＡ１や検索サーバＫ１からの要求に応じて送信する処理などを行う。
【００４１】
尚、図１０では、統計情報データベース１５７に蓄積される統計情報を用いて算出する送信量や受信量などの負荷情報と、ＨＴＴＰデータベース１５４に蓄積されるフレーム情報を用いて算出される応答時間などの負荷情報との両方に対応する構成を描いてあるが、例えばＨＴＴＰデータベース１５４に蓄積されたフレーム情報から求められる負荷情報のみを用いる場合は、図１１に示したように、フレーム解析処理部１５２、データベース格納処理部１５３およびＨＴＴＰデータベース１５４のみを搭載する構成であってもよい。逆に、図１２に示すように、統計情報処理部１５５、統計情報格納処理部１５６および統計情報データベース１５７のみを搭載する構成であってもよい。尚、図１２では、図１０に示した統計情報の送信量および受信量を直近、１日前、２日前のように過去の送信量の平均および受信量の平均を統計情報処理部１５５で求めて統計情報データベース１５７に蓄積する例を示している。
【００４２】
送受信処理部１５１は、装置Ｅ８とサイトサーバＳ１との間でフレーム（ＴＣＰ／ＩＰフレーム）を送受信する。尚、図１０では、サイトサーバＳ１と装置Ｅ８との間でフレームを送受信するが、サイトサーバＳ１に直接接続されない装置Ｅの場合は、サイトサーバＳ１ではなく、隣接する装置Ｅ間でフレームを送受信する。装置Ｅは複数のポートを有し、送受信処理部１５１はフレームの宛先に応じて各ポート間でフレームを送受信する。図１０の例では、装置Ｅ８はポート１にサイトサーバＳ１はポート１０にそれぞれ接続されており、他の装置Ｅ４、装置Ｅ６および装置Ｅ１１についてもそれぞれ他のポートに接続されている。
【００４３】
フレーム解析処理部１５２は、送受信処理部１５１で送受信されるフレームの内容を解析してＨＴＴＰデータであるか否かを判断する。そして、フレームがＨＴＴＰフレームである場合は、ＨＴＴＰヘッダに格納されているコマンド種別（ＲＦＣ２６１６に定義されているメソッド（ＧＥＴなど）やステータスコード（２００ＯＫなど））やＵＲＬ、送信元ＩＰおよび宛先ＩＰ、送信ポートおよび受信したフレームを送信ポートから出力する時刻などを抽出する。
【００４４】
データベース格納処理部１５３は、フレーム解析処理部１５２が抽出したＵＲＬ、種別、送信元ＩＰ、宛先ＩＰ、送信ポート、送信時刻などの情報をＨＴＴＰデータベース１５４に格納する。
【００４５】
ＨＴＴＰデータベース１５４は、装置Ｅ内のデータベースで、フレーム解析処理部１５２が抽出したＵＲＬ、種別、送信元ＩＰ、宛先ＩＰ、送信ポート、送信時刻などの情報が蓄積する。図１０の例では、サイトサーバＳ１に対応するＵＲＬ：ａａａの装置Ｅ８からサイトサーバＳ１へのＨＴＴＰリクエストフレーム（送信元ＩＰ：Ａ、宛先ＩＰ：Ｂ、コマンド：ＧＥＴ）は送信ポート１０（サイトサーバＳ１に接続されているポート）から送信時刻：ｔ２に送信されたことがＨＴＴＰデータベース１５４に蓄積される。そして、時刻ｔ２の後の時刻ｔ３では、時刻ｔ２のＨＴＴＰリクエストフレームの応答としてサイトサーバＳ１から受信するＨＴＴＰレスポンスフレーム（送信元ＩＰ：Ｂ、宛先ＩＰ：Ａ、コマンド：２００ＯＫ）をポート１から装置Ｅ８に送信されたことがＨＴＴＰデータベース１５４に蓄積される。ここで、ｔ２−ｔ１＝Ｔｒｅｓは、サイトサーバＳ１にＨＴＴＰリクエストフレームを送信してから装置Ｅ８にサイトサーバＳ１から受信したＨＴＴＰレスポンスフレームを送信するまでの時間に相当するので、装置Ｅ９での処理時間を無視すると、ＴｒｅｓはサイトサーバＳ１から情報を取得するまでの応答時間に相当する。
【００４６】
統計情報処理部１５５は、送受信処理部１５１で送受信されるフレームの統計解析を行う。例えば装置ＥのサイトサーバＳ１が接続されるポート１０や、装置Ｅ８が接続されるポート１におけるフレームの送受信量を統計処理する。図１０の例では、ポート１の送信量が１００Ｍｂｐｓおよび受信量が２００Ｍｂｐｓで、ポート１０の送信量が１００Ｍｂｐｓおよび受信量が５７００Ｍｂｐｓであることが統計情報データベース１５７からわかる。
【００４７】
統計情報格納処理部１５６は、統計情報処理部１５５が求めた統計情報を統計情報データベース１５７に蓄積する処理を行う。
【００４８】
統計情報データベース１５７は、装置Ｅ内のデータベースで、統計情報処理部１５５が求めた統計情報を蓄積する。図１０の例では、各ポートに対応する送信量と受信料とが蓄積される。
【００４９】
エッジ判別処理部１５８は、送受信処理部１５１で送受信されるフレームのヘッダに格納されるカウンタ値から自装置がサイトサーバＳ１のエッジ装置であるか否かの判別を行う。そして、エッジ装置である場合は監視サーバＡ１や検索サーバＫ１に通知する。尚、エッジ装置であるか否かの判別処理については、後で詳しく説明する。
【００５０】
負荷情報処理部１５９は、検索サーバＫ１および監視サーバＡ１からの要求に応じて、ＨＴＴＰデータベース１５４または統計情報データベース１５７に蓄積された情報から負荷情報を求めて監視サーバＡ１および検索サーバＫ１に送受信処理部１５１を介して送信する。負荷情報処理部１５９は、先に説明したように、ＨＴＴＰデータベース１５４に蓄積されたフレーム情報から応答時間やアクセス頻度などを負荷情報として算出したり、統計情報データベース１５７に蓄積された統計情報から使用帯域（或いは帯域使用率）などを負荷情報として算出して、負荷情報データベース１６０（ＨＴＴＰデータベース１５４や統計情報データベース１５７）に記憶する。そして、検索サーバＫ１は、装置Ｅから負荷情報を取得して、ＷＥＢ検索結果の画面に使用帯域や過去の使用帯域履歴、或いは応答時間やアクセス頻度などの負荷情報を表示することができる。尚、ここでは応答時間の算出や統計情報の処理を装置Ｅ側で行うようにしたが、基本的な情報（データ送受信量や送信時刻／受信時刻など）のみを装置Ｅ側の負荷情報データベース１６０に蓄積し、これらの基本的な情報を取得した検索サーバＫ１側で情報を適宜加工してＷＥＢ検索結果に表示するようにしてもよい。
【００５１】
このように、装置Ｅは構成され、送受信するフレームの解析や統計処理を行って送受信されるフレームの情報や統計情報を蓄積し、監視サーバＡ１や検索サーバＫ１からの要求に応じて、負荷情報を提供する。特に、装置Ｅは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバＡ１は管轄する全ての装置Ｅについてエッジ装置であるか否かの情報を予め保持しておく必要がなく、また、装置Ｅが増設されたり、サイトサーバＳ１が新たに装置Ｅに接続された場合でも常に最新のエッジ装置情報を得ることができる。
［エッジ装置の判別方法］
次に装置Ｅにおいて、自装置がサイトサーバのエッジ装置であるか否かを判別する方法について説明する。本実施形態に係るネットワークシステム１００に用いられる装置Ｅは、送受信するＴＣＰ／ＩＰフレームが本実施形態に係るネットワークシステム１００の機能に対応する場合に、ＩＰヘッダまたはＴＣＰヘッダにオプション領域を設け、受信したフレームを送信する時にオプション領域のカウンタをインクリメント（＋１）する。ここで、送信したフレームに対して受信するレスポンスフレームのカウント値が送信時のカウント値に一致する場合に自装置が当該フレームのＵＲＬに対応するサイトサーバのエッジ装置であると判断する。
【００５２】
尚、ＩＰフレームについて説明する。図１３はＲＦＣ−７９１に規定されるＩＰフレームの構成を示す図である。ＩＰフレームはヘッダ部とデータ部とを有し、ＩＰヘッダには、バージョン、ヘッダ長、サービスタイプ（ＴＯＳ）、データグラム長、ＩＤ、フラグ、フラグメント・オフセット、ＴＴＬ、プロトコル番号、ヘッダチェックサム、送信元ＩＰアドレス、宛先ＩＰアドレスが含まれている。さらに、オプションとして、オプションタイプ、レングス、ベンダーＩＤ、カウンタ６４ビットなどの情報をヘッダ部に付加することができる。ＩＰヘッダのオプション領域は０−４０ｂｙｔｅの可変領域で、オプションタイプのオクテットは、”１ｂｉｔのコピーフラグ”（０＝コピーしない／１＝コピーする）、“２ｂｉｔｓのオプションクラス”、”５ｂｉｔｓのオプションナンバー”を有する。
［ＩＰヘッダのオプション領域の使用例］
次に、本実施形態に係るネットワークシステム１００におけるＩＰヘッダのオプション領域の使用例を示す。尚、ここではＲＦＣ−２７８０に定義されていないタイプ値を使用する。
（１）オプションタイプ
・コピーフラグ：０（コピーしない）
・オプションクラス：２（デバックと計測を使用する）
・オプションナンバー：１６
（２）レングス：オプションタイプからカウンタまでの長さ
（３）ベンダーＩＤ（６ビット）：装置Ｅの製造メーカーのＩＤ
（４）カウンタ（６４ビットカウンタ）：装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは２の６４乗−１であり、上限値までカウントされた場合は、そのままカウントは停止する。そして、次の装置への転送時はそのままの上限値に固定する。また、装置ステップ数カウンタの上限値（２の６４乗−１）を最後にカウントした装置は、その時点で自装置がエッジ装置とみなし、監視サーバＡ１に通知する。２の６４乗−１は非常に大きな数字なので現実的には上限値に固定されることは少ないと考えられるが、上限値に達した時点でエッジ装置として判断するようにしてもよい。この場合、上限値のフレームを受信した装置以降に転送される装置は、カウントアップせずにそのまま転送する。尚、これらの装置はエッジ装置とはみなさないものとする。
【００５３】
また、エッジ装置として判定する条件は以下の通りである。
（１）カウントが変化していない場合。（尚、フォーマットは正しいものとする。）
（２）応答フレームのオプション領域の全てに０パディングされている場合。
（３）応答フレームのオプション領域が除去されている場合。
（４）本実施形態に係るネットワークシステム１００で指定したオプション領域のフォーマットに適合していない場合。
【００５４】
上記の（２）、（３）および（４）の場合は、本実施形態に係るネットワークシステム１００の装置Ｅ以外の機器を経由しているとみなす。
【００５５】
尚、自装置がエッジ装置であると判定された場合、且つ、本実施形態に係るネットワークシステム１００の装置Ｅ以外の機器を経由し、オプション領域に変更が加わっている場合（上記（１）〜（３）の場合）は、改めてオプション領域を付加し、カウンタ値に自装置が送信した時のカウンタを＋１した値を設定して次の装置に転送する。これにより、自装置以降の装置Ｅがエッジ装置であると誤判定することを防止できる。
［ＴＣＰヘッダのオプション領域の使用例］
上記の説明ではＩＰヘッダを利用したが、ＩＰヘッダではなくＴＣＰヘッダを利用しても構わない。ＴＣＰフレームはＩＰフレームのデータ部に格納され、ヘッダ部とデータ部とを有する。図１４はＲＦＣ−７９３に規定されるＴＣＰフレームの構成を示す図である。ＴＣＰヘッダには、送信元ポート、送信先ポート、シーケンス番号、ＡＣＫ番号、データオフセット、フラグ、ウィンドウサイズ、チェックサム、緊急ポインタなどが含まれる。さらに、オプションとして、オプション種別、レングス、ベンダーＩＤ、カウンタ６４ビットなどの情報をヘッダ部に付加することができる。ＴＣＰヘッダのオプション領域は０−４０ｂｙｔｅの可変領域である。オプションタイプの最初のオクテットはＫｉｎｄ（種類）を表す。
【００５６】
例えばＨＴＴＰフレームにおいて、ＩＰヘッダの代わりにＴＣＰヘッダのオプション領域の６４ビットカウンタを装置ステップ数カウンタとして用い、ＩＰヘッダの場合と同様にカウンタ値を判断することで自装置がエッジ装置であるか否かを判定する。
［ＴＣＰヘッダのオプション領域の使用例］
次に、本実施形態に係るネットワークシステム１００におけるＴＣＰヘッダのオプション領域の使用例を示す。尚、ここではＲＦＣ−２７８０に定義されていないタイプ値を使用する。
（１）オプションタイプ
・Ｋｉｎｄ：８０
（２）レングス：オプションタイプからカウンタまでの長さ
（３）ベンダーＩＤのフィールド：装置Ｅの製造メーカーのＩＤ
（４）カウンタ（６４ビットカウンタ）：装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは２の６４乗−１であり、上限値までカウントされた場合の動作は、ＩＰヘッダで説明した内容と同じである。
【００５７】
図１５は、ＩＰヘッダおよびＴＣＰヘッダのオプション領域の詳細フォーマット示す図である。本実施形態に係るネットワークシステム１００では、ＩＰヘッダのオプションタイプやＴＣＰヘッダのオプション種別が８０の時に本実施形態特有の機能に対応するフレームであることを示す。ベンダーＩＤは例えばネットワークシステム１００を構築する会社のＩＤなどが記載される。カウンタ６４ビットは、８Ｂｙｔｅのカウンタで、本実施形態に係るネットワークシステム１００では、オプションタイプが８０のフレームを受信して再び送信する時にカウンタを＋１する。或いは、オプション領域が無いフレームやオプション領域があってもオプションタイプが８０ではないときは、カウンタを１に設定する。
【００５８】
このようにして、本実施形態に係るネットワークシステム１００では、ＴＣＰ／ＩＰフレームを利用し、特にオプション領域のオプションタイプ（オプション種別）が８０の場合に本実施形態で説明する動作に対応する。尚、他社が別の目的にオプションタイプ（オプション種別）を８０にして使用する可能性があるので、ベンダーＩＤとオプションタイプ（オプション種別）の両方が予め設定した値に設定されている場合に本実施形態特有の動作に対応するようにしてもよい。そして、本実施形態に係るネットワークシステム１００では、カウンタを利用してサイトサーバＳ１の直近の装置Ｅであるか否かの判別を行う。
【００５９】
［カウンタによるエッジ装置判別の具体例］
次に、ＴＣＰ／ＩＰフレームのオプション領域のカウンタを用いて装置Ｅがサイトサーバの直近のエッジ装置であるか否かを判別する具体例について説明する。ここでは、本実施形態に係るネットワークシステム１００の機能を有する装置を経由する場合と有さない装置を経由する場合とに分けて説明する。
（本実施形態の機能を有する装置を経由する場合）
図１６は、説明がわかり易いように、図１で説明したネットワークシステム１００のネットワーク１０１の構成を簡略化した図である。図１６の例では、装置Ｅ２０,Ｅ２１，Ｅ２２，Ｅ２３、Ｅ２４の５台の装置Ｅがメッシュ状のネットワーク１０１を構成する。また、ユーザＰＣ１からサイトサーバＳ１までの経路は、例えばユーザＰＣ１から装置Ｅ２０を介してネットワーク１０１に接続し、ネットワーク１０１内では装置Ｅ２２を経由して装置Ｅ２３を介してサイトサーバＳ１に接続される。この場合は、装置Ｅ２３がサイトサーバＳ１の直近のエッジ装置に該当する。ここで、装置Ｅ２３自らがサイトサーバＳ１のエッジ装置であることを判別する流れについて説明する。
＜リクエスト時＞
（１）先ず、ユーザＰＣ１はＨＴＴＰリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。
（２）次に、装置Ｅ２０は、ユーザＰＣ１からＨＴＴＰリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを８０、カウンタを１、さらにレングスとベンダＩＤも設定して次の装置Ｅ２２に送信する。
（３）次に、装置Ｅ２２は、装置Ｅ２０からオプション領域（オプションタイプ：８０、カウンタ：１）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝２となる）して次の装置Ｅ２３に送信する。
（４）次に、装置Ｅ２３は、装置Ｅ２２からオプション領域（オプションタイプ：８０、カウンタ：２）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝３となる）して次の転送先に送信する。尚、この時点で装置Ｅ２３は次の送信先がサイトサーバＳ１であることを認識していない。
（５）そして、装置Ｅ２３からＨＴＴＰリクエストフレームを受信したサイトサーバＳ１は、ＨＴＴＰリクエストフレームに対応するＨＴＴＰレスポンスフレームを装置Ｅ２３に送信する。ここで、ＨＴＴＰレスポンスフレームのヘッダのオプション領域にはＨＴＴＰリクエストフレームのオプション領域の値がそのまま折り返される。
＜レスポンス時＞
（６）装置Ｅ２３は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値は３であり、先に送信したＨＴＴＰリクエストフレームのオプション領域のカウンタ値（＝３）と同じなので、自装置がエッジ装置であると認識する。そして、カウンタを＋１（カウンタ＝４となる）して次の装置Ｅ２２に送信する。また、監視サーバＡ１にこれを通知する。この時に監視サーバＡ１に通知する情報は、例えばサイトサーバＳ２のＭＡＣアドレスが含まれる。
（７）次の装置Ｅ２２は、装置Ｅ２３からオプション領域（オプションタイプ：８０、カウンタ：４）が設定されたＨＴＴＰレスポンスフレームを受信すると、受信したＨＴＴＰレスポンスフレームに対応するＨＴＴＰリクエストフレームの送信時のカウンタ値（＝２）と比較する。カウンタ値が異なるので、自装置はエッジ装置ではないとを認識して、カウンタ値を＋１してカウンタ値＝５として受信したＨＴＴＰレスポンスフレームを次の装置Ｅ２０に送信する。
（８）装置Ｅ２０は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値（＝５）と、送信時のＨＴＴＰリクエストフレームのカウンタ値（＝２）と異なるので、自装置がエッジ装置ではないと認識する。そして、カウンタを＋１（カウンタ＝６となる）にしてユーザＰＣ１に送信する。
【００６０】
このように、ＩＰヘッダまたはＴＣＰヘッダのカウンタを利用して各装置Ｅ自らがエッジ装置であるか否かを判別する。
（本実施形態の機能を有さない装置を経由する場合）
図１７は、図１６に対応する図で、同符号のものは同じものを示す。図１６と異なるのは、サイトサーバＳ２は装置Ｅ２４から本実施形態の機能に対応しないルータＲ１を介して接続されていることである。図１７において、ユーザＰＣ１からサイトサーバＳ２までの経路は、例えばユーザＰＣ１から装置Ｅ２０を介してネットワーク１０１に接続し、ネットワーク１０１内では装置Ｅ２０から装置Ｅ２４を経由してルータＲ１に接続され、ルータＲ１を介してサイトサーバＳ２に接続される。この場合は、装置Ｅ２４がサイトサーバＳ２の直近のエッジ装置に該当する。ここで、装置Ｅ２４自らがエッジ装置であることを判別する流れについて説明する。
＜リクエスト時＞
（１）先ず、ユーザＰＣ１はＨＴＴＰリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。
（２）次に、装置Ｅ２０は、ユーザＰＣ１からＨＴＴＰリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを８０、カウンタを１、さらにレングスとベンダＩＤも設定して次の装置Ｅ２２に送信する。
（３）次に、装置Ｅ２４は、装置Ｅ２０からオプション領域（オプションタイプ：８０、カウンタ：１）が設定されたＨＴＴＰリクエストフレームを受信すると、オプションタイプが８０であることを確認して、カウンタを＋１（カウンタ＝２となる）して次のルータＲ１に送信する。尚、この時点で装置Ｅ２４はエッジ装置であることを認識していない。
（４）次に、本実施形態の機能を有さないルータＲ１は、オプション領域に全て”０”パディングしてサイトサーバＳ２に送信する。
（５）そして、サイトサーバＳ２は、受信したＨＴＴＰリクエストフレームに対応するＨＴＴＰレスポンスフレームを返信する。ここで、ＨＴＴＰレスポンスフレームのヘッダのオプション領域はそのままＨＴＴＰリクエストフレームのオプション領域に格納され、そのまま折り返される。
＜レスポンス時＞
（６）本実施形態の機能を有さないルータＲ１は、サイトサーバＳ２から受信するＨＴＴＰレスポンスフレームのオプション領域に全て”０”パディングして装置Ｅ２４に送信する。
（７）次の装置Ｅ２４は、ルータＲ１から受信するＨＴＴＰレスポンスフレームのオプション領域が全て”０”なので、装置Ｅ２４以降に新たな装置Ｅが存在しないと判断し、自らがエッジ装置であると認識する。そして、監視サーバＡ１にこれを通知する。この時に監視サーバＡ１に通知する情報は、例えばサイトサーバＳ２のＭＡＣアドレスが含まれる。そして、装置Ｅ２４は、再び、オプション領域を付加すると同時に、オプションタイプを８０、カウンタを３、さらにレングスとベンダＩＤも設定して次の装置Ｅ２０に送信する。ここで、カウンタ値を初期化（１に設定）せずに、ＨＴＴＰリクエストフレームを転送時（上記の（２）の処理）のカウンタ値（＝２）を＋１したカウンタ値（＝３）をＨＴＴＰレスポンスフレームに格納して次の装置Ｅ２０に送信する。
（８）装置Ｅ２０は、受信するＨＴＴＰレスポンスフレームのオプション領域のカウンタ値（＝３）と、送信時のＨＴＴＰリクエストフレームのカウンタ値（＝１）とを比較して、一致しないので自装置がエッジ装置ではないと判断する。そして、カウンタを＋１（＝４）にしてユーザＰＣ１に送信する。
【００６１】
このように、ＩＰヘッダまたはＴＣＰヘッダのカウンタを利用して装置Ｅ自らがエッジ装置であるか否かを判別する。
【００６２】
［装置Ｅの処理］
次に、装置Ｅの処理について、図１８および図１９のフローチャートを用いて説明する。図１８は、ＨＴＴＰリクエスト時の処理を示すフローチャートである。先ず、ユーザＰＣ１は、ＨＴＴＰリクエストフレームを送信する。このＨＴＴＰリクエストフレームには、オプション領域は設定されておらず、ヘッダとデータのみで構成される通常のＩＰフレームである。
【００６３】
（ステップＳ１０１）装置Ｅは、ユーザＰＣ１から受信したＨＴＴＰリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件とは、本実施形態に係るネットワークシステム１００の機能に対応するフレームの条件（オプションタイプ＝８０、レングス／ベンダＩＤ内容、カウンタ値など）である。例えば所定条件が以下の（１）から（３）のいずれかに該当する場合（Ｙｅｓ）はステップＳ１０２に進み、いずれにも該当しない場合（Ｎｏ）はステップＳ１０３に進む。
（１）オプション領域が全て”０”パディングされている。
（２）オプション領域が存在しない。
（３）オプションタイプが８０ではない、ベンダＩＤが異なる、カウンタ値が”０”である、など本実施形態で予め定めたフォーマットに合っていない。
（ステップＳ１０２）装置Ｅは、オプション領域のカウンタ値を”１”に設定する。
（ステップＳ１０３）装置Ｅは、オプション領域のカウンタ値をインクリメント（＋１）する。
【００６４】
そして、オプション領域が設定されたＨＴＴＰリクエストフレームを次の装置Ｅに転送する。同様に、次の装置Ｅからその次の装置ＥにＨＴＴＰリクエストフレームを転送してサイトサーバＳ１まで送信する。
（ステップＳ１０４）装置Ｅは、オプション領域のカウンタ値を内部メモリやＨＴＴＰデータベース１５４などに保持する。上記の例では、カウンタ値＝１が保持される。
【００６５】
次に、ＨＴＴＰリクエストフレームを受信したサイトサーバＳ１は、ＨＴＴＰレスポンスフレームを返信する。返信時の処理について図１９のフローチャートを用いて説明する。サイトサーバＳ１が返信するＨＴＴＰレスポンスフレームは、装置Ｅから装置Ｅへ転送されながらユーザＰＣ１まで送信される。
（ステップＳ２０１）装置Ｅは、受信したＨＴＴＰリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件は先にステップＳ１０１で説明した条件と同じである。Ｙｅｓの場合はステップＳ２０２に進み、Ｎｏの場合はステップＳ２０３に進む。
（ステップＳ２０２）装置Ｅは、オプション領域を再設定して、ステップＳ１０４で保持したＨＴＴＰリクエストフレームのカウンタ値をインクリメント（＋１）した値を新たなカウンタ値として設定する。
（ステップＳ２０３）装置Ｅは、図１８のステップＳ１０４で保持したＨＴＴＰリクエストフレームのカウンタ値と、ＨＴＴＰレスポンスフレームのカウンタ値とが等しいか否かを判別する。Ｙｅｓの場合はステップＳ２０４に進み、Ｎｏの場合はステップＳ２０５に進む。
（ステップＳ２０４）装置Ｅは、自装置がエッジ装置であると認識して、監視サーバＡ１に自装置がエッジ装置であることを通知する。
（ステップＳ２０５）装置Ｅは、ＨＴＴＰレスポンスフレームのカウンタ値をインクリメント（＋１）する。そして、次の装置Ｅに転送する。図１９の例では、次の装置がユーザＰＣ１なので、ユーザＰＣ１にＨＴＴＰレスポンスフレームを送信する。
【００６６】
このようにして、ユーザＰＣ１から送信されたＨＴＴＰリクエストフレームは、オプション領域が設定され、カウンタ値を設定またはインクリメントしながらサイトサーバＳ１に送信され、サイトサーバＳ１から返信されるＨＴＴＰレスポンスフレームについても同様にオプション領域のカウンタ値を再設定またはインクリメントしながらユーザＰＣ１まで送信される。そして、ＨＴＴＰリクエストフレームを送信する際のカウンタ値と、受信するＨＴＴＰレスポンスフレームのカウンタ値とが等しい場合に自装置がエッジ装置であると判断して、監視サーバＡ１に自装置がエッジ装置であることを通知する。
【００６７】
このように、装置Ｅは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバＡ１は管轄する全ての装置Ｅがエッジ装置であるかの情報を予め保持しておく必要がなく、また、装置Ｅが増設されたり、サイトサーバＳ１が新たに装置Ｅに接続された場合でも常に最新のエッジ装置情報を得ることができる。
【００６８】
［複数の基幹ネットワークが接続されている場合］
先に説明した図１のネットワークシステム１００は、１つのネットワーク１０１内に監視サーバＡ１、検索サーバＫ１、サイトサーバＳ１が配置されているので、監視サーバＡ１はネットワーク１０１を構成する全ての装置Ｅの状態を監視することができた。しかし実際には、ネットワーク１０１のような複数の基幹ネットワークが装置Ｅを介して互いに接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。ここでは、複数の基幹ネットワークを有する場合の例について説明する。
【００６９】
図２０は、基幹ネットワークＡの装置Ｘを介して基幹ネットワークＢに接続されたネットワークシステム１００ａの構成例を示した図である。図２０において、基幹ネットワーク１０１ａは、先に説明したネットワーク１０１に対応し、ユーザＰＣ１と、検索サーバＫ１と、監視サーバＡ１とがネットワーク１０１に接続されている。そして、装置Ｘを介して基幹ネットワーク１０１ｂに接続され、ネットワーク１０１ｂには、監視サーバＡ２と、サイトサーバＳ２とが接続されている。
【００７０】
ここで、ユーザＰＣ１が検索サーバＫ１に検索キーワードを含む検索要求を送信し、検索サーバＫ１は自分が持っている情報などから検索キーワードに該当する情報を公開している基幹ネットワーク１０１ｂのサイトサーバＳ２（ＵＲＬ）が抽出される。そして、検索サーバＫ１は監視サーバＡ１に該当するサイトサーバＳ２の情報（ＵＲＬ）があるか否かを問い合わせる。監視サーバＡ１に該当するサイトサーバＳ２の情報（ＵＲＬ）がない場合は、検索サーバＫ１は監視サーバＡ１に他の監視サーバＡ２に対してサイトサーバＳ２の情報（ＵＲＬ）を持っているか否かを問い合わせる。
【００７１】
問い合わせを受けた監視サーバＡ２はサイトサーバＳ２の情報（ＵＲＬ）があるか否かを検索し、ある場合は監視サーバＡ１に対して応答する。応答を受けた監視サーバＡ１は、応答を返した監視サーバＡ２に対してサイトサーバＳ２のエッジ装置の負荷情報を要求する。要求を受けた監視サーバＡ２は、保持しているサイトサーバＳ２のエッジ装置Ｙの負荷情報を監視サーバＡ１に応答する。
これを受けた監視サーバＡ１は、その負荷情報を検索サーバＫ１に送信する。
【００７２】
このようにして、異なる基幹ネットワーク１０１ａおよび基幹ネットワーク１０１ｂが接続される場合でも、それぞれのネットワークの監視サーバＡ１および監視サーバＡ２とが連携して該当するサイトサーバのエッジ装置から負荷情報を取得して、要求元の検索サーバＫ１に負荷情報を送信するので、検索サーバＫ１は、先の実施形態と同様に、検索結果のＵＲＬに対応する負荷情報をユーザＰＣ１に提供することができる。
【００７３】
次に、複数の基幹ネットワークを有する場合のネットワークシステム１００１ａの動作シーケンスについて図２１を用いて説明する。図２１において、ユーザＰＣ１は検索サーバＫ１に検索キーワードを含む検索要求（ＨＴＴＰリクエスト）を送信する。検索サーバＫ１は、自身の検索サーバデータベース３０２を参照して、検索キーワードを含むＵＲＬリストを抽出する。そして、検索結果の各ＵＲＬに対応する負荷情報を取得するためにサイトサーバの情報を持っているか否かを監視サーバＡ１に問い合わせる。図２０の例では、基幹ネットワーク１０１ａを管轄する監視サーバＡ１は、基幹ネットワーク１０１ｂに配置されているサイトサーバＳ２の情報を持っていないので、検索サーバＫ１にサイトサーバＳ２の情報無しの応答を行う。これを受けた検索サーバＫ１は、監視サーバＡ１にサイトサーバＳ２の情報を取得するように依頼する。
【００７４】
一方、監視サーバＡ１は、サイトサーバＳ２の情報を取得するように検索サーバＫ１から依頼を受けると、他の基幹ネットワークに監視サーバＡ２、監視サーバＡ３および監視サーバＡ４などにサイトサーバＳ２の情報を持っているか否かの問い合わせを行う。そして、図２０の例では、基幹ネットワーク１０１ｂの監視サーバＡ２がサイトサーバＳ２に接続されるエッジ装置Ｙを管轄しているので、サイトサーバＳ２の情報を持っていることを監視サーバＡ１に応答する。尚、監視サーバＡ２は、先の実施形態で説明したように、サイトサーバＳ２のエッジ装置が装置Ｙであることを装置Ｙ自身から通知されているので、サイトサーバＳ２のＵＲＬに対応するエッジ装置が装置Ｙであることを認識している。また、サイトサーバＳ２の情報を持っていない監視サーバＡ３および監視サーバＡ４からは応答されない。
【００７５】
そして、監視サーバＡ２からサイトサーバＳ２の情報を持っているという応答を受信した監視サーバＡ１は、監視サーバＡ２に対してエッジ装置の負荷情報を要求する。これを受けた監視サーバＡ２は、先の実施形態で説明した手順でエッジ装置ＹからサイトサーバＳ２が接続されているポートの負荷情報を取得して監視サーバＡ１に応答する。そして、監視サーバＡ１から検索サーバＫ１にエッジ装置Ｙの負荷情報が送信され、検索サーバＫ１で検索結果のＵＲＬに対応する負荷情報を表示してユーザＰＣ１に検索結果として提供する。
【００７６】
このようにして、サイトサーバＳ２がユーザＰＣ１および検索サーバＫ１が接続される基幹ネットワーク１０１ａとは異なる基幹ネットワーク１０１ｂにある場合でも、基幹ネットワーク１０１ａの監視サーバＡ１から基幹ネットワーク１０１ｂの監視サーバＡ２に問い合わせることによって、先の実施形態と同様に、ユーザＰＣ１で検索結果のＵＲＬ毎に負荷情報が表示された画面を確認することができる。
【００７７】
［異なる基幹ネットワークに接続する装置の処理］
次に、図２０で説明したネットワークシステム１００ａにおいて、基幹ネットワーク１０１ａの装置Ｘは、基幹ネットワーク１０１ｂへの接続口になっている。このため、装置Ｘは、先に説明した図１７のルータＲ１に接続される装置Ｅ２４の場合と同様に、自装置がエッジ装置であると判断し、監視サーバＡ１にこれを通知することが考えられる。この場合は、図２２に示すように、監視サーバＡ１内の監視サーバデータベース３０１に他の基幹ネットワークに接続している装置リストを予め登録しておくことにより、装置Ｘから自装置がエッジ装置であると通知してきた場合でも、エッジ装置ではないと判断できる。そして、図２１で説明したように、他の基幹ネットワークの監視サーバに対して問い合わせを行い、実際にサイトサーバに接続されているエッジ装置から負荷情報を取得することができる。
【００７８】
このようにして、他の基幹ネットワークに接続している装置リストを監視サーバに予め登録しておくことにより、他の基幹ネットワークへの接続口の装置がエッジ装置であると誤認識した場合でも、当該装置が真のエッジ装置であるか否かの判断を行うことができ、必要に応じて他の基幹ネットワークの監視サーバから真のエッジ装置の負荷情報を取得することができる。
【００７９】
以上、各実施形態において説明してきたように、本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別してサイトサーバのＵＲＬに対する負荷情報を蓄積し、検索サーバはエッジ装置から取得した負荷情報と検索結果のＵＲＬとを対応させたＷＥＢ検索結果を端末装置に提供することができる。
【００８０】
尚、本発明に係る設定情報参照起動型の制御装置および設定情報管理方法について、各実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。
【符号の説明】
【００８１】
１００・・・ネットワークシステム
１０１・・・ネットワーク
１５１・・・送受信処理部
１５２・・・フレーム解析処理部
１５３・・・データベース格納処理部
１５４・・・ＨＴＴＰデータベース
１５５・・・統計情報処理部
１５６・・・統計情報格納処理部
１５７・・・統計情報データベース
１５８・・・エッジ判別処理部
１５９・・・負荷情報処理部
１６０・・・負荷情報データベース
３０１・・・監視サーバデータベース
３０２・・・検索サーバデータベース
ＰＣ１，ＰＣ２・・・ユーザＰＣ（パソコン）
Ｅ１〜Ｅ１１，Ｅ２０〜Ｅ２４，Ｘ，Ｙ・・・装置（Ｌ２スイッチ装置）
Ａ１，Ａ２，Ａ３，Ａ４・・・監視サーバ
Ｋ１・・・検索サーバ
Ｓ１，Ｓ２，Ｓ３・・・サイトサーバ
【特許請求の範囲】
【請求項１】
メッシュ状のネットワークを構成する複数のスイッチ装置と、
ＷＥＢサービスを提供するサイトサーバと、
前記ネットワークに接続される端末装置のＷＥＢ検索要求に応じて前記サイトサーバのＵＲＬ情報をＷＥＢ検索結果として前記端末装置に提供する検索サーバと、
前記複数のスイッチ装置の状態を監視する監視サーバとを有し、
前記検索サーバは、前記端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供する
ことを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムにおいて、
前記スイッチ装置は、
フレームを送受信する送受信処理部と、
前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、
前記負荷情報を蓄積するデータベースと、
自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部と
を有する
ことを特徴とするネットワークシステム。
【請求項３】
請求項２に記載のネットワークシステムにおいて、
前記スイッチ装置のエッジ判別処理部は、前記フレームの中のＨＴＴＰリクエストフレームを格納するＩＰフレームまたはＴＣＰフレームのヘッダ部にカウンタを設けて、前記ＩＰフレームまたは前記ＴＣＰフレームを転送する毎に前記カウンタをカウントアップし、前記ＨＴＴＰリクエストフレームを送信時の前記カウンタ値を第１カウンタ値として保持し、前記ＨＴＴＰリクエストフレームに対するＨＴＴＰレスポンスフレームを格納する前記ＩＰフレームまたは前記ＴＣＰフレームのヘッダ部の前記カウンタ値を第２カウンタ値として前記第１カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断する
ことを特徴とするネットワークシステム。
【請求項４】
請求項１から３のいずれか一項に記載のネットワークシステムにおいて、
前記スイッチ装置は、レイヤ２スイッチであることを特徴とするネットワークシステム。
【請求項５】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値である
ことを特徴とするネットワークシステム。
【請求項６】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間である
ことを特徴とするネットワークシステム。
【請求項７】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度である
ことを特徴とするネットワークシステム。
【請求項８】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値である
ことを特徴とするネットワークシステム。
【請求項９】
請求項１から８のいずれか一項に記載のネットワークシステムにおいて、
前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供する
ことを特徴とするネットワークシステム。
【請求項１０】
請求項１から９いずれか一項に記載のネットワークシステムにおいて、
前記サイトサーバが前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークにある場合、前記第２基幹ネットワークの検索サーバは、前記第１基幹ネットワークの監視サーバの情報と前記第２基幹ネットワークの監視サーバの情報とを取得する
ことを特徴とするネットワークシステム。
【請求項１１】
請求項１から１０いずれか一項に記載のネットワークシステムにおいて、
前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記第１基幹ネットワークの検索サーバが前記第２基幹ネットワークの監視サーバの情報を持っていない場合、前記第１基幹ネットワークの監視サーバは、前記第２基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得する
ことを特徴とするネットワークシステム。
【請求項１２】
請求項１から１１いずれか一項に記載のネットワークシステムにおいて、
前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、
前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断する
ことを特徴とするネットワークシステム。
【請求項１】
メッシュ状のネットワークを構成する複数のスイッチ装置と、
ＷＥＢサービスを提供するサイトサーバと、
前記ネットワークに接続される端末装置のＷＥＢ検索要求に応じて前記サイトサーバのＵＲＬ情報をＷＥＢ検索結果として前記端末装置に提供する検索サーバと、
前記複数のスイッチ装置の状態を監視する監視サーバとを有し、
前記検索サーバは、前記端末装置のＷＥＢ検索要求を受け取って検索を実行し、そのＷＥＢ検索結果の各ＵＲＬに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供する
ことを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムにおいて、
前記スイッチ装置は、
フレームを送受信する送受信処理部と、
前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、
前記負荷情報を蓄積するデータベースと、
自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部と
を有する
ことを特徴とするネットワークシステム。
【請求項３】
請求項２に記載のネットワークシステムにおいて、
前記スイッチ装置のエッジ判別処理部は、前記フレームの中のＨＴＴＰリクエストフレームを格納するＩＰフレームまたはＴＣＰフレームのヘッダ部にカウンタを設けて、前記ＩＰフレームまたは前記ＴＣＰフレームを転送する毎に前記カウンタをカウントアップし、前記ＨＴＴＰリクエストフレームを送信時の前記カウンタ値を第１カウンタ値として保持し、前記ＨＴＴＰリクエストフレームに対するＨＴＴＰレスポンスフレームを格納する前記ＩＰフレームまたは前記ＴＣＰフレームのヘッダ部の前記カウンタ値を第２カウンタ値として前記第１カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断する
ことを特徴とするネットワークシステム。
【請求項４】
請求項１から３のいずれか一項に記載のネットワークシステムにおいて、
前記スイッチ装置は、レイヤ２スイッチであることを特徴とするネットワークシステム。
【請求項５】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値である
ことを特徴とするネットワークシステム。
【請求項６】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間である
ことを特徴とするネットワークシステム。
【請求項７】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度である
ことを特徴とするネットワークシステム。
【請求項８】
請求項１から４のいずれか一項に記載のネットワークシステムにおいて、
前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値である
ことを特徴とするネットワークシステム。
【請求項９】
請求項１から８のいずれか一項に記載のネットワークシステムにおいて、
前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記ＷＥＢ検索結果の各ＵＲＬに関連付けて前記端末装置に提供する
ことを特徴とするネットワークシステム。
【請求項１０】
請求項１から９いずれか一項に記載のネットワークシステムにおいて、
前記サイトサーバが前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークにある場合、前記第２基幹ネットワークの検索サーバは、前記第１基幹ネットワークの監視サーバの情報と前記第２基幹ネットワークの監視サーバの情報とを取得する
ことを特徴とするネットワークシステム。
【請求項１１】
請求項１から１０いずれか一項に記載のネットワークシステムにおいて、
前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記第１基幹ネットワークの検索サーバが前記第２基幹ネットワークの監視サーバの情報を持っていない場合、前記第１基幹ネットワークの監視サーバは、前記第２基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得する
ことを特徴とするネットワークシステム。
【請求項１２】
請求項１から１１いずれか一項に記載のネットワークシステムにおいて、
前記端末装置および前記監視サーバの属する第１基幹ネットワーク外の第２基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、
前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断する
ことを特徴とするネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１２−２３９０７５（Ｐ２０１２−２３９０７５Ａ）
【公開日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願番号】特願２０１１−１０７４５８（Ｐ２０１１−１０７４５８）
【出願日】平成２３年５月１２日（２０１１．５．１２）
【出願人】（０００２３７６６２）富士通テレコムネットワークス株式会社 (682)
【Ｆターム（参考）】
【公開日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願日】平成２３年５月１２日（２０１１．５．１２）
【出願人】（０００２３７６６２）富士通テレコムネットワークス株式会社 (682)
【Ｆターム（参考）】
[ Back to top ]