"メッシュ状のネットワークを構成する複数のスイッチ装置と、WEBサービスを提供するサイトサーバと、前記ネットワークに接続される端末装置のWEB検索要求に応じて前記サイトサーバのURL情報をWEB検索結果として前記端末装置に提供する検索サーバと、前記複数のスイッチ装置の状態を監視する監視サーバとを有し、前記検索サーバは、前記端末装置のWEB検索要求を受け取って検索を実行し、そのWEB検索結果の各URLに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記WEB検索結果の各URLに関連付けて前記端末装置に提供することを特徴とするネットワークシステム。請求項1に記載のネットワークシステムにおいて、前記スイッチ装置は、フレームを送受信する送受信処理部と、前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、前記負荷情報を蓄積するデータベースと、自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部とを有することを特徴とするネットワークシステム。請求項2に記載のネットワークシステムにおいて、前記スイッチ装置のエッジ判別処理部は、前記フレームの中のHTTPリクエストフレームを格納するIPフレームまたはTCPフレームのヘッダ部にカウンタを設けて、前記IPフレームまたは前記TCPフレームを転送する毎に前記カウンタをカウントアップし、前記HTTPリクエストフレームを送信時の前記カウンタ値を第1カウンタ値として保持し、前記HTTPリクエストフレームに対するHTTPレスポンスフレームを格納する前記IPフレームまたは前記TCPフレームのヘッダ部の前記カウンタ値を第2カウンタ値として前記第1カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断することを特徴とするネットワークシステム。請求項1から3のいずれか一項に記載のネットワークシステムにおいて、前記スイッチ装置は、レイヤ2スイッチであることを特徴とするネットワークシステム。請求項1から4のいずれか一項に記載のネットワークシステムにおいて、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値であることを特徴とするネットワークシステム。請求項1から4のいずれか一項に記載のネットワークシステムにおいて、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間であることを特徴とするネットワークシステム。請求項1から4のいずれか一項に記載のネットワークシステムにおいて、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度であることを特徴とするネットワークシステム。請求項1から4のいずれか一項に記載のネットワークシステムにおいて、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値であることを特徴とするネットワークシステム。請求項1から8のいずれか一項に記載のネットワークシステムにおいて、前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記WEB検索結果の各URLに関連付けて前記端末装置に提供することを特徴とするネットワークシステム。請求項1から9いずれか一項に記載のネットワークシステムにおいて、前記サイトサーバが前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークにある場合、前記第2基幹ネットワークの検索サーバは、前記第1基幹ネットワークの監視サーバの情報と前記第2基幹ネットワークの監視サーバの情報とを取得することを特徴とするネットワークシステム。請求項1から10いずれか一項に記載のネットワークシステムにおいて、前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークに前記サイトサーバがある場合、且つ、前記第1基幹ネットワークの検索サーバが前記第2基幹ネットワークの監視サーバの情報を持っていない場合、前記第1基幹ネットワークの監視サーバは、前記第2基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得することを特徴とするネットワークシステム。請求項1から11いずれか一項に記載のネットワークシステムにおいて、前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断することを特徴とするネットワークシステム。従来技術では、メッシュ状のネットワークを構成する複数のスイッチ装置のうちWEBサービスを提供するサイトサーバ直近に接続されているスイッチ装置エッジ装置と称するを特定することができないので、エッジ装置自体の負荷状態アクセス頻度などを含むものとするを知ることができないという問題があった。また、他の基幹ネットワークにサイトサーバがある場合は、ユーザが属する基幹ネットワークの監視サーバは他の基幹ネットワークの負荷情報は知ることができないという問題があった。上記課題に鑑み、本発明の目的は、エッジ装置を特定して、エッジ装置の負荷情報を取得し、WEB検索結果に関連付けて表示できるネットワークシステムを提供することである。本発明に係るネットワークシステムは、メッシュ状のネットワークを構成する複数のスイッチ装置と、WEBサービスを提供するサイトサーバと、前記ネットワークに接続される端末装置のWEB検索要求に応じて前記サイトサーバのURL情報をWEB検索結果として前記端末装置に提供する検索サーバと、前記複数のスイッチ装置の状態を監視する監視サーバとを有し、前記検索サーバは、前記端末装置のWEB検索要求を受け取って検索を実行し、そのWEB検索結果の各URLに対応する前記各サイトサーバ直近の前記スイッチ装置の負荷情報を前記監視サーバから取得して前記WEB検索結果の各URLに関連付けて前記端末装置に提供することを特徴とする。また、前記スイッチ装置は、フレームを送受信する送受信処理部と、前記送受信処理部で送受信するフレーム解析または統計情報処理を行って負荷情報を蓄積する負荷情報処理部と、前記負荷情報を蓄積するデータベースと、自装置がエッジ装置であるか否かを判別して、エッジ装置である場合は前記監視サーバに通知するエッジ判別処理部とを有することを特徴とする。さらに、前記スイッチ装置のエッジ判別処理部は、前記フレームの中のHTTPリクエストフレームを格納するIPフレームまたはTCPフレームのヘッダ部にカウンタを設けて、前記IPフレームまたは前記TCPフレームを転送する毎に前記カウンタをカウントアップし、前記HTTPリクエストフレームを送信時の前記カウンタ値を第1カウンタ値として保持し、前記HTTPリクエストフレームに対するHTTPレスポンスフレームを格納する前記IPフレームまたは前記TCPフレームのヘッダ部の前記カウンタ値を第2カウンタ値として前記第1カウンタ値と比較して、一致する場合は自装置が当該サイトサーバの直近の装置であると判断することを特徴とする。特に、前記スイッチ装置は、レイヤ2スイッチであることを特徴とする。また、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間で情報を送受信する際の使用帯域または過去の同時刻の使用帯域の平均値であることを特徴とする。或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバに情報を要求する要求フレームの送信時刻と前記要求フレームに対する応答フレームの受信時刻との差分から求めた応答時間であることを特徴とする。または、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置が前記サイトサーバとの間の所定時間内のアクセス頻度であることを特徴とする。或いは、前記負荷情報は、前記サイトサーバ直近の前記スイッチ装置で前記サイトサーバが接続されているポートの送信方向のデータ量と受信方向のデータ量のうち多い方の値であることを特徴とする。特に、前記検索サーバは、前記監視サーバを介さずに前記サイトサーバ直近の前記スイッチ装置から負荷情報を取得して前記WEB検索結果の各URLに関連付けて前記端末装置に提供することを特徴とする。また、前記サイトサーバが前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークにある場合、前記第2基幹ネットワークの検索サーバは、前記第1基幹ネットワークの監視サーバの情報と前記第2基幹ネットワークの監視サーバの情報とを取得することを特徴とする。特に、前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークに前記サイトサーバがある場合、且つ、前記第1基幹ネットワークの検索サーバが前記第2基幹ネットワークの監視サーバの情報を持っていない場合、前記第1基幹ネットワークの監視サーバは、前記第2基幹ネットワークの監視サーバから前記サイトサーバ直近の前記スイッチ装置の情報を取得することを特徴とする。さらに、前記端末装置および前記監視サーバの属する第1基幹ネットワーク外の第2基幹ネットワークに前記サイトサーバがある場合、且つ、前記監視サーバが他の基幹ネットワークへ接続する直近の前記スイッチ装置のリストを保持している場合、前記監視サーバは、前記リストに記載されている前記スイッチ装置から前記サイトサーバ直近の前記スイッチ装置である通知を受けても当該スイッチ装置は前記サイトサーバ直近のスイッチ装置ではないと判断することを特徴とする。本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別し、検索サーバはエッジ装置から取得した負荷情報とURLとを対応させたWEB検索結果を端末装置に提供することができる。以下、本発明に係るネットワークシステムの実施形態について詳しく説明する。図1は、本実施形態に係るネットワークシステム100の構成例を示す図である。図1において、ネットワークシステム100は、メッシュ状のネットワーク101を構成する複数のL2スイッチ装置図1の例では装置E1から装置E11と、検索サーバK1と、監視サーバA1と、サイトサーバS1とを有する。尚、装置E1から装置E11に共通の事項を説明する場合は装置Eと表記する。また、本実施形態における動作説明では、サイトサーバS1の動作について説明するが、実際には点線で示したように、サイトサーバS2およびサイトサーバS3などの複数のサイトサーバが用いられる。ここで、サイトサーバとは、http対応のホームページなどを提供するサーバでWEBサーバとも呼ばれている。また、検索サーバとは、装置Eに接続されるユーザ端末装置図1の例ではユーザPC1またはユーザPC2から送信される検索キーワードを含む情報を公開しているサイトサーバのURLUniformResourceLocatorを検索して、検索結果URLリストなどをユーザ端末装置に返信するサーバである。さらに、監視サーバとは、管轄する基幹ネットワーク図1の例ではネットワーク101内の全装置Eの動作設定や動作状態の監視および制御などを行うためのサーバである。また、図1では、1つのネットワーク101内に閉じているが、複数の基幹ネットワークが装置Eを介して接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。尚、複数の基幹ネットワークを有する場合の実施形態については後で詳しく説明する。図1において、ユーザPC1は装置E1を介してネットワーク101に接続され、ユーザPC2は装置E2を介してネットワーク101に接続されている。また、サイトサーバS1は装置E9を介してネットワーク101に接続され、検索サーバK1および監視サーバA1は装置E3および装置E4を介してそれぞれネットワーク101に接続されている。尚、検索サーバK1と監視サーバA1は別のネットワークで接続されていてもよい。先ず、ユーザPC1から検索サーバK1に検索キーワードを送信して検索キーワードが含まれる情報を公開しているサイトサーバのURLを検索する場合の動作について説明する。例えばユーザPC1は一般に用いられているDNSサーバ図1には記載せずを介して検索サーバK1に接続する。そして、ユーザPC1の画面には、図2に示すように、検索サーバK1から受信する検索画面が表示される。ユーザが検索キーワード図2の例では食品Aレシピを入力して検索ボタンを押下すると、検索キーワードが検索サーバK1に送られる。そして、検索サーバK1は受信する検索キーワードに該当する情報を有するサイトサーバ図1の例ではサイトサーバS1,S2,S3などへアクセスするためのURLを検索し、URLリストなどの検索結果をユーザPC1に送信する。図3は検索サーバK1から受信した検索結果の画面例を示す図である。検索結果には、検索キーワードを含む公開情報201やサイトサーバのURL202awww.abcdef.com/aaa123/などが表示される。ここで、例えばURL202aはサイトサーバS1のURL、URL202bはサイトサーバS2のURL、URL202cはサイトサーバS3のURLのようにそれぞれ対応する。そして、ユーザPC1で例えばURL202aを選択マウスカーソルでクリックすると、ユーザPC1からネットワーク101を介してサイトサーバS1に接続され、サイトサーバS1から当該URLに対応するホームページなどが表示される。このようにして、ユーザPC1は、見たい情報を提供するサイトサーバのURLを検索サーバK1を介して検索し、検索結果の中から選択したURLのサイトサーバから必要な情報を得ることができる。ところが、図3の例では、検索結果の画面から各URLを提供するサイトサーバにアクセスする際の負荷状態サイトサーバの混雑状態やサイトサーバに接続する経路の混雑状態などを含むをユーザーは知ることができない。そこで、本実施形態に係るネットワークシステム100では、検索サーバK1が作成してユーザPC1に送信する検索結果の各URL毎に負荷情報を表示できるようになっている。例えば図4では、負荷情報として、当該サイトサーバにアクセスする際の使用帯域を表示する様子を示している。図4の場合、URL202aの使用帯域203aは30程度で空いているが、URL202bの使用帯域203bは80以上で混雑していることをユーザは検索結果の画面を見て知ることができる。これにより、例えばユーザは、アクセスが遅くなる可能性が高いURL202bの選択を避けて、URL202aやURL202cなどを選択することができる。ここで、使用帯域或いは帯域使用率は、現帯域使用量送信量または受信量/最大帯域使用量ポート毎に決められた最大送信量または最大受信量により求めることができる。また、図5の例では、図4で説明した使用帯域の過去の履歴図5の例では2日前までの履歴を検索結果画面の各URL毎に表示する。これにより、例えばユーザは、URL202aは過去の使用帯域204aから本日だけ混雑していること、URL202bは過去の使用帯域204bからいつも空いていること、などの負荷情報を知ることができる。さらに、図6の例では、応答時間を検索結果画面の各URL毎に表示する。尚、応答時間は、サイトサーバが接続されるエッジ装置Eとサイトサーバとの間の回線帯域とサイトサーバ自体の処理負荷を含むので、実際にアクセスした時のレスポンスが速さを知ることができる。これにより、例えばユーザは、URL202aは応答時間205aが0.3秒なのでレスポンスが速い、URL202bは応答時間205bが5.3秒なのでレスポンスが遅い、などの判断を行うことができる。また、図7の例では、統計情報として直近のアクセス頻度1時間当りのアクセス件数を検索結果画面の各URL毎に表示する。尚、従来技術として過去のアクセス件数を表示するものもあるが、図7の場合は直近のアクセス頻度を表示することができる。これにより、例えばユーザは、URL202aの直近の1時間のアクセス件数が51000件で、URL202bの直近の1時間のアクセス件数は1000件なので、URL202aの方がレスポンスが遅い可能性があるという判断を行うことができる。このようにして、本実施形態に係るネットワークシステム100では、検索サーバの検索結果画面から各URLを提供するサイトサーバにアクセスする際の負荷状態をアクセスする前に知ることができる。これにより、ユーザは、比較的レスポンスが速いサイトサーバのURLを選択することができる。尚、負荷情報は、過去の同時刻の装置の負荷情報からその平均値を表示するようにしてもよい。次に、本実施形態に係るネットワークシステム100において、各装置Eと検索サーバK1および監視サーバA1との間で送受信される情報について図8のシーケンス図を用いて説明する。尚、ネットワークシステム100はSNMPプロトコルに対応し、制御情報を送受信する。図8において、監視サーバA1は、管轄するネットワーク101内の全装置Eから各装置Eに接続されるサイトサーバのURL情報を収集する。URL情報の収集は、例えば監視サーバA1が全装置Eに対して定期的にポーリングを行って収集してもよいし、ポーリング対象の装置Eを自装置がエッジ装置であるという通知をしてきた装置Eに限定してもよい。或いは、ポーリングを行わずに装置Eから自装置がエッジ装置であるという通知を受けたときだけ、当該装置からURL情報を収集するようにしてもよい。ここで、後で説明するように装置Eは自装置があるサイトサーバのエッジ装置であるか否かを判別する機能を有している。そして、装置Eは、自装置がエッジ装置であると判断した場合に監視サーバA1に自装置がエッジ装置であることを通知する。装置Eは、自装置に接続されるサイトサーバのURL情報を蓄積したHTTPデータベース154や帯域使用率やアクセス件数などの統計情報を蓄積する統計情報データベース157を有している。尚、いずれか1つのデータベースでもよいし、両方の情報を1つのデータベースに集約してもよい。監視サーバA1は装置Eに対してSNMPGETコマンドを送信してポーリングを行い、装置Eは自装置内のHTTPデータベース154に蓄積されたURL情報をSNMPレスポンスとして監視サーバA1に返信する。監視サーバA1は、各装置Eから収集したURL情報を各装置Eの装置IDに対応付けて、監視サーバA1内の監視サーバデータベース301に保持する。これにより、監視サーバA1は、どの装置EがどのURLについての情報を保持しているかを管理することができる。同様に検索サーバK1は、複数の監視サーバに対してSNMPによる定期的なポーリングを行い、各URL毎にどの監視サーバの配下のどの装置Eに属しているのかを示す情報を得ることができる。図8の例では、検索サーバK1は監視サーバA1から収集した情報を自身の検索サーバデータベース302に蓄積する。尚、図8の例では、検索サーバK1は監視サーバA1を介して装置Eの情報を直接収集するようにしてもよい。これにより、装置情報を収集する時に検索サーバK1と監視サーバA1との間で情報を送受信する必要が無くなるため、装置Eの負荷情報をより速く検索画面に表示できる。次に、図8で説明したシーケンスにより、監視サーバA1と検索サーバK1とにURLに関する情報が蓄積された状態にある場合に、ユーザPC1が検索サーバK1に検索キーワードを含むHTTPリクエストフレームを送信すると、検索サーバK1は検索キーワードを含むWEBページを有するサイトサーバのURLを検索する。この処理は、一般的に行われている検索サーバの情報検索サービスと同じである。従来の検索サーバでは、この時点の検索結果をHTTPレスポンスとしてユーザ側に返信して検索結果画面がユーザPC1に表示されていた図3。これに対して、本実施形態に係るネットワークシステム100では、図9に示すように、検索サーバK1は、自身の検索サーバデータベース302を参照して、検索結果の各URLに対応するエッジ装置Eを管轄する監視サーバA1に対してSNMPGETコマンドを送信し、目的のURLを持つサイトサーバに接続されるエッジ装置Eのポートの負荷情報例えば帯域使用率やアクセス頻度などを要求する。そして、この要求を受けた装置Eは自身が保持しているHTTPデータベース154や統計情報データベース157を参照して、要求された負荷情報を求める。例えば負荷情報がアクセス頻度である場合は、エッジ装置Eから当該URLに相当するサイトサーバへのアクセス数例えばHTTPの<host>までの部分一致検索でヒットするものを取得する。尚、<host>は、フォーマットhttp://<host>:<port>/<path><searchpart>で示されるURLの一部でRFC1738に定められている。アクセス数は、装置自身が保持しているHTTPデータベース154に格納しているデータベースの中からHTTPリクエストフレームにあるURLに該当するデータのうち、種別がHTTPフレームのヘッダ情報がGETであり、且つ、装置Eからサイトサーバへの送信時刻が現在時刻から1時間以内であるデータの個数をアクセス頻度として求める。そして、求めたアクセス頻度をSNMPRESPONSEに格納して監視サーバA1に送信する。同様に、要求された負荷情報が帯域使用率の場合は、統計情報データベース157に蓄積されている装置Eのサイトサーバが接続されているポートの送信量または受信量を設定されている最大送信量または最大受信量で割って帯域使用率を求め、これをSNMPRESPONSEに格納して監視サーバA1に送信する。監視サーバA1は装置Eから受信したSNMPRESPONSEの負荷情報を検索サーバK1に送信し、検索サーバK1は監視サーバA1から受信した負荷情報を先に検索した検索結果の該当するURLに対応付けたHTTPレスポンスをユーザPC1に送信する。尚、この場合は送信量/最大送信量と受信量/最大受信量の2つの値の大小を比較して、大きい値を監視サーバA1に送信するようにしても構わない。このようにして、ユーザPC1では、先に図4、図5、図6および図7で説明したように、負荷情報を含む検索結果画面を閲覧することができる。[装置Eの構成]次に装置Eの構成例について図10を用いて説明する。尚、図10は図1の一部分を抜き出した図で、図1におけるサイトサーバS1に接続されるエッジ装置装置E9と、装置E9に接続される装置E8を示している。また、図10では、装置E9の構成例を描いてあるが、他の装置Eについても同様に構成される。図10において、装置E9は、送受信処理部151と、フレーム解析処理部152と、データベース格納処理部153と、HTTPデータベース154と、統計情報処理部155と、統計情報格納処理部156と、統計情報データベース157と、エッジ判別処理部158とで構成される。尚、フレーム解析処理部152とデータベース格納処理部153および統計情報処理部155と統計情報格納処理部156は、負荷情報を求めるためのブロック負荷情報処理部159として1つにまとめてもよい。同様に、HTTPデータベース154および統計情報データベース157を負荷情報データベース160として1つにまとめてもよい。そして、負荷情報処理部159は、フレーム解析処理部152で送受信されるフレーム情報や統計情報などから得られる負荷情報を負荷情報データベース160に蓄積する処理や、負荷情報データベース160に蓄積された負荷情報を監視サーバA1や検索サーバK1からの要求に応じて送信する処理などを行う。尚、図10では、統計情報データベース157に蓄積される統計情報を用いて算出する送信量や受信量などの負荷情報と、HTTPデータベース154に蓄積されるフレーム情報を用いて算出される応答時間などの負荷情報との両方に対応する構成を描いてあるが、例えばHTTPデータベース154に蓄積されたフレーム情報から求められる負荷情報のみを用いる場合は、図11に示したように、フレーム解析処理部152、データベース格納処理部153およびHTTPデータベース154のみを搭載する構成であってもよい。逆に、図12に示すように、統計情報処理部155、統計情報格納処理部156および統計情報データベース157のみを搭載する構成であってもよい。尚、図12では、図10に示した統計情報の送信量および受信量を直近、1日前、2日前のように過去の送信量の平均および受信量の平均を統計情報処理部155で求めて統計情報データベース157に蓄積する例を示している。送受信処理部151は、装置E8とサイトサーバS1との間でフレームTCP/IPフレームを送受信する。尚、図10では、サイトサーバS1と装置E8との間でフレームを送受信するが、サイトサーバS1に直接接続されない装置Eの場合は、サイトサーバS1ではなく、隣接する装置E間でフレームを送受信する。装置Eは複数のポートを有し、送受信処理部151はフレームの宛先に応じて各ポート間でフレームを送受信する。図10の例では、装置E8はポート1にサイトサーバS1はポート10にそれぞれ接続されており、他の装置E4、装置E6および装置E11についてもそれぞれ他のポートに接続されている。フレーム解析処理部152は、送受信処理部151で送受信されるフレームの内容を解析してHTTPデータであるか否かを判断する。そして、フレームがHTTPフレームである場合は、HTTPヘッダに格納されているコマンド種別RFC2616に定義されているメソッドGETなどやステータスコード200OKなどやURL、送信元IPおよび宛先IP、送信ポートおよび受信したフレームを送信ポートから出力する時刻などを抽出する。データベース格納処理部153は、フレーム解析処理部152が抽出したURL、種別、送信元IP、宛先IP、送信ポート、送信時刻などの情報をHTTPデータベース154に格納する。HTTPデータベース154は、装置E内のデータベースで、フレーム解析処理部152が抽出したURL、種別、送信元IP、宛先IP、送信ポート、送信時刻などの情報が蓄積する。図10の例では、サイトサーバS1に対応するURL:aaaの装置E8からサイトサーバS1へのHTTPリクエストフレーム送信元IP:A、宛先IP:B、コマンド:GETは送信ポート10サイトサーバS1に接続されているポートから送信時刻:t2に送信されたことがHTTPデータベース154に蓄積される。そして、時刻t2の後の時刻t3では、時刻t2のHTTPリクエストフレームの応答としてサイトサーバS1から受信するHTTPレスポンスフレーム送信元IP:B、宛先IP:A、コマンド:200OKをポート1から装置E8に送信されたことがHTTPデータベース154に蓄積される。ここで、t2-t1=Tresは、サイトサーバS1にHTTPリクエストフレームを送信してから装置E8にサイトサーバS1から受信したHTTPレスポンスフレームを送信するまでの時間に相当するので、装置E9での処理時間を無視すると、TresはサイトサーバS1から情報を取得するまでの応答時間に相当する。統計情報処理部155は、送受信処理部151で送受信されるフレームの統計解析を行う。例えば装置EのサイトサーバS1が接続されるポート10や、装置E8が接続されるポート1におけるフレームの送受信量を統計処理する。図10の例では、ポート1の送信量が100Mbpsおよび受信量が200Mbpsで、ポート10の送信量が100Mbpsおよび受信量が5700Mbpsであることが統計情報データベース157からわかる。統計情報格納処理部156は、統計情報処理部155が求めた統計情報を統計情報データベース157に蓄積する処理を行う。統計情報データベース157は、装置E内のデータベースで、統計情報処理部155が求めた統計情報を蓄積する。図10の例では、各ポートに対応する送信量と受信料とが蓄積される。エッジ判別処理部158は、送受信処理部151で送受信されるフレームのヘッダに格納されるカウンタ値から自装置がサイトサーバS1のエッジ装置であるか否かの判別を行う。そして、エッジ装置である場合は監視サーバA1や検索サーバK1に通知する。尚、エッジ装置であるか否かの判別処理については、後で詳しく説明する。負荷情報処理部159は、検索サーバK1および監視サーバA1からの要求に応じて、HTTPデータベース154または統計情報データベース157に蓄積された情報から負荷情報を求めて監視サーバA1および検索サーバK1に送受信処理部151を介して送信する。負荷情報処理部159は、先に説明したように、HTTPデータベース154に蓄積されたフレーム情報から応答時間やアクセス頻度などを負荷情報として算出したり、統計情報データベース157に蓄積された統計情報から使用帯域或いは帯域使用率などを負荷情報として算出して、負荷情報データベース160HTTPデータベース154や統計情報データベース157に記憶する。そして、検索サーバK1は、装置Eから負荷情報を取得して、WEB検索結果の画面に使用帯域や過去の使用帯域履歴、或いは応答時間やアクセス頻度などの負荷情報を表示することができる。尚、ここでは応答時間の算出や統計情報の処理を装置E側で行うようにしたが、基本的な情報データ送受信量や送信時刻/受信時刻などのみを装置E側の負荷情報データベース160に蓄積し、これらの基本的な情報を取得した検索サーバK1側で情報を適宜加工してWEB検索結果に表示するようにしてもよい。このように、装置Eは構成され、送受信するフレームの解析や統計処理を行って送受信されるフレームの情報や統計情報を蓄積し、監視サーバA1や検索サーバK1からの要求に応じて、負荷情報を提供する。特に、装置Eは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバA1は管轄する全ての装置Eについてエッジ装置であるか否かの情報を予め保持しておく必要がなく、また、装置Eが増設されたり、サイトサーバS1が新たに装置Eに接続された場合でも常に最新のエッジ装置情報を得ることができる。[エッジ装置の判別方法]次に装置Eにおいて、自装置がサイトサーバのエッジ装置であるか否かを判別する方法について説明する。本実施形態に係るネットワークシステム100に用いられる装置Eは、送受信するTCP/IPフレームが本実施形態に係るネットワークシステム100の機能に対応する場合に、IPヘッダまたはTCPヘッダにオプション領域を設け、受信したフレームを送信する時にオプション領域のカウンタをインクリメント1する。ここで、送信したフレームに対して受信するレスポンスフレームのカウント値が送信時のカウント値に一致する場合に自装置が当該フレームのURLに対応するサイトサーバのエッジ装置であると判断する。尚、IPフレームについて説明する。図13はRFC-791に規定されるIPフレームの構成を示す図である。IPフレームはヘッダ部とデータ部とを有し、IPヘッダには、バージョン、ヘッダ長、サービスタイプTOS、データグラム長、ID、フラグ、フラグメントオフセット、TTL、プロトコル番号、ヘッダチェックサム、送信元IPアドレス、宛先IPアドレスが含まれている。さらに、オプションとして、オプションタイプ、レングス、ベンダーID、カウンタ64ビットなどの情報をヘッダ部に付加することができる。IPヘッダのオプション領域は0-40byteの可変領域で、オプションタイプのオクテットは、1bitのコピーフラグ0=コピーしない/1=コピーする、2bitsのオプションクラス、5bitsのオプションナンバーを有する。[IPヘッダのオプション領域の使用例]次に、本実施形態に係るネットワークシステム100におけるIPヘッダのオプション領域の使用例を示す。尚、ここではRFC-2780に定義されていないタイプ値を使用する。1オプションタイプコピーフラグ:0コピーしないオプションクラス:2デバックと計測を使用するオプションナンバー:162レングス:オプションタイプからカウンタまでの長さ3ベンダーID6ビット:装置Eの製造メーカーのID4カウンタ64ビットカウンタ:装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは2の64乗-1であり、上限値までカウントされた場合は、そのままカウントは停止する。そして、次の装置への転送時はそのままの上限値に固定する。また、装置ステップ数カウンタの上限値2の64乗-1を最後にカウントした装置は、その時点で自装置がエッジ装置とみなし、監視サーバA1に通知する。2の64乗-1は非常に大きな数字なので現実的には上限値に固定されることは少ないと考えられるが、上限値に達した時点でエッジ装置として判断するようにしてもよい。この場合、上限値のフレームを受信した装置以降に転送される装置は、カウントアップせずにそのまま転送する。尚、これらの装置はエッジ装置とはみなさないものとする。また、エッジ装置として判定する条件は以下の通りである。1カウントが変化していない場合。尚、フォーマットは正しいものとする。2応答フレームのオプション領域の全てに0パディングされている場合。3応答フレームのオプション領域が除去されている場合。4本実施形態に係るネットワークシステム100で指定したオプション領域のフォーマットに適合していない場合。上記の2、3および4の場合は、本実施形態に係るネットワークシステム100の装置E以外の機器を経由しているとみなす。尚、自装置がエッジ装置であると判定された場合、且つ、本実施形態に係るネットワークシステム100の装置E以外の機器を経由し、オプション領域に変更が加わっている場合上記1~3の場合は、改めてオプション領域を付加し、カウンタ値に自装置が送信した時のカウンタを1した値を設定して次の装置に転送する。これにより、自装置以降の装置Eがエッジ装置であると誤判定することを防止できる。[TCPヘッダのオプション領域の使用例]上記の説明ではIPヘッダを利用したが、IPヘッダではなくTCPヘッダを利用しても構わない。TCPフレームはIPフレームのデータ部に格納され、ヘッダ部とデータ部とを有する。図14はRFC-793に規定されるTCPフレームの構成を示す図である。TCPヘッダには、送信元ポート、送信先ポート、シーケンス番号、ACK番号、データオフセット、フラグ、ウィンドウサイズ、チェックサム、緊急ポインタなどが含まれる。さらに、オプションとして、オプション種別、レングス、ベンダーID、カウンタ64ビットなどの情報をヘッダ部に付加することができる。TCPヘッダのオプション領域は0-40byteの可変領域である。オプションタイプの最初のオクテットはKind種類を表す。例えばHTTPフレームにおいて、IPヘッダの代わりにTCPヘッダのオプション領域の64ビットカウンタを装置ステップ数カウンタとして用い、IPヘッダの場合と同様にカウンタ値を判断することで自装置がエッジ装置であるか否かを判定する。[TCPヘッダのオプション領域の使用例]次に、本実施形態に係るネットワークシステム100におけるTCPヘッダのオプション領域の使用例を示す。尚、ここではRFC-2780に定義されていないタイプ値を使用する。1オプションタイプKind:802レングス:オプションタイプからカウンタまでの長さ3ベンダーIDのフィールド:装置Eの製造メーカーのID4カウンタ64ビットカウンタ:装置ステップ数カウンタとして使用。尚、装置ステップ数カウンタの最大カウントは2の64乗-1であり、上限値までカウントされた場合の動作は、IPヘッダで説明した内容と同じである。図15は、IPヘッダおよびTCPヘッダのオプション領域の詳細フォーマット示す図である。本実施形態に係るネットワークシステム100では、IPヘッダのオプションタイプやTCPヘッダのオプション種別が80の時に本実施形態特有の機能に対応するフレームであることを示す。ベンダーIDは例えばネットワークシステム100を構築する会社のIDなどが記載される。カウンタ64ビットは、8Byteのカウンタで、本実施形態に係るネットワークシステム100では、オプションタイプが80のフレームを受信して再び送信する時にカウンタを1する。或いは、オプション領域が無いフレームやオプション領域があってもオプションタイプが80ではないときは、カウンタを1に設定する。このようにして、本実施形態に係るネットワークシステム100では、TCP/IPフレームを利用し、特にオプション領域のオプションタイプオプション種別が80の場合に本実施形態で説明する動作に対応する。尚、他社が別の目的にオプションタイプオプション種別を80にして使用する可能性があるので、ベンダーIDとオプションタイプオプション種別の両方が予め設定した値に設定されている場合に本実施形態特有の動作に対応するようにしてもよい。そして、本実施形態に係るネットワークシステム100では、カウンタを利用してサイトサーバS1の直近の装置Eであるか否かの判別を行う。[カウンタによるエッジ装置判別の具体例]次に、TCP/IPフレームのオプション領域のカウンタを用いて装置Eがサイトサーバの直近のエッジ装置であるか否かを判別する具体例について説明する。ここでは、本実施形態に係るネットワークシステム100の機能を有する装置を経由する場合と有さない装置を経由する場合とに分けて説明する。本実施形態の機能を有する装置を経由する場合図16は、説明がわかり易いように、図1で説明したネットワークシステム100のネットワーク101の構成を簡略化した図である。図16の例では、装置E20E21,E22,E23、E24の5台の装置Eがメッシュ状のネットワーク101を構成する。また、ユーザPC1からサイトサーバS1までの経路は、例えばユーザPC1から装置E20を介してネットワーク101に接続し、ネットワーク101内では装置E22を経由して装置E23を介してサイトサーバS1に接続される。この場合は、装置E23がサイトサーバS1の直近のエッジ装置に該当する。ここで、装置E23自らがサイトサーバS1のエッジ装置であることを判別する流れについて説明する。<リクエスト時>1先ず、ユーザPC1はHTTPリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。2次に、装置E20は、ユーザPC1からHTTPリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを80、カウンタを1、さらにレングスとベンダIDも設定して次の装置E22に送信する。3次に、装置E22は、装置E20からオプション領域オプションタイプ:80、カウンタ:1が設定されたHTTPリクエストフレームを受信すると、オプションタイプが80であることを確認して、カウンタを1カウンタ=2となるして次の装置E23に送信する。4次に、装置E23は、装置E22からオプション領域オプションタイプ:80、カウンタ:2が設定されたHTTPリクエストフレームを受信すると、オプションタイプが80であることを確認して、カウンタを1カウンタ=3となるして次の転送先に送信する。尚、この時点で装置E23は次の送信先がサイトサーバS1であることを認識していない。5そして、装置E23からHTTPリクエストフレームを受信したサイトサーバS1は、HTTPリクエストフレームに対応するHTTPレスポンスフレームを装置E23に送信する。ここで、HTTPレスポンスフレームのヘッダのオプション領域にはHTTPリクエストフレームのオプション領域の値がそのまま折り返される。<レスポンス時>6装置E23は、受信するHTTPレスポンスフレームのオプション領域のカウンタ値は3であり、先に送信したHTTPリクエストフレームのオプション領域のカウンタ値=3と同じなので、自装置がエッジ装置であると認識する。そして、カウンタを1カウンタ=4となるして次の装置E22に送信する。また、監視サーバA1にこれを通知する。この時に監視サーバA1に通知する情報は、例えばサイトサーバS2のMACアドレスが含まれる。7次の装置E22は、装置E23からオプション領域オプションタイプ:80、カウンタ:4が設定されたHTTPレスポンスフレームを受信すると、受信したHTTPレスポンスフレームに対応するHTTPリクエストフレームの送信時のカウンタ値=2と比較する。カウンタ値が異なるので、自装置はエッジ装置ではないとを認識して、カウンタ値を1してカウンタ値=5として受信したHTTPレスポンスフレームを次の装置E20に送信する。8装置E20は、受信するHTTPレスポンスフレームのオプション領域のカウンタ値=5と、送信時のHTTPリクエストフレームのカウンタ値=2と異なるので、自装置がエッジ装置ではないと認識する。そして、カウンタを1カウンタ=6となるにしてユーザPC1に送信する。このように、IPヘッダまたはTCPヘッダのカウンタを利用して各装置E自らがエッジ装置であるか否かを判別する。本実施形態の機能を有さない装置を経由する場合図17は、図16に対応する図で、同符号のものは同じものを示す。図16と異なるのは、サイトサーバS2は装置E24から本実施形態の機能に対応しないルータR1を介して接続されていることである。図17において、ユーザPC1からサイトサーバS2までの経路は、例えばユーザPC1から装置E20を介してネットワーク101に接続し、ネットワーク101内では装置E20から装置E24を経由してルータR1に接続され、ルータR1を介してサイトサーバS2に接続される。この場合は、装置E24がサイトサーバS2の直近のエッジ装置に該当する。ここで、装置E24自らがエッジ装置であることを判別する流れについて説明する。<リクエスト時>1先ず、ユーザPC1はHTTPリクエストフレームを送信する。このリクエストフレームはオプション領域が無いヘッダ部とデータ部のみで構成される。2次に、装置E20は、ユーザPC1からHTTPリクエストフレームを受信すると、オプション領域が無いのでオプション領域を付加し、オプションタイプを80、カウンタを1、さらにレングスとベンダIDも設定して次の装置E22に送信する。3次に、装置E24は、装置E20からオプション領域オプションタイプ:80、カウンタ:1が設定されたHTTPリクエストフレームを受信すると、オプションタイプが80であることを確認して、カウンタを1カウンタ=2となるして次のルータR1に送信する。尚、この時点で装置E24はエッジ装置であることを認識していない。4次に、本実施形態の機能を有さないルータR1は、オプション領域に全て0パディングしてサイトサーバS2に送信する。5そして、サイトサーバS2は、受信したHTTPリクエストフレームに対応するHTTPレスポンスフレームを返信する。ここで、HTTPレスポンスフレームのヘッダのオプション領域はそのままHTTPリクエストフレームのオプション領域に格納され、そのまま折り返される。<レスポンス時>6本実施形態の機能を有さないルータR1は、サイトサーバS2から受信するHTTPレスポンスフレームのオプション領域に全て0パディングして装置E24に送信する。7次の装置E24は、ルータR1から受信するHTTPレスポンスフレームのオプション領域が全て0なので、装置E24以降に新たな装置Eが存在しないと判断し、自らがエッジ装置であると認識する。そして、監視サーバA1にこれを通知する。この時に監視サーバA1に通知する情報は、例えばサイトサーバS2のMACアドレスが含まれる。そして、装置E24は、再び、オプション領域を付加すると同時に、オプションタイプを80、カウンタを3、さらにレングスとベンダIDも設定して次の装置E20に送信する。ここで、カウンタ値を初期化1に設定せずに、HTTPリクエストフレームを転送時上記の2の処理のカウンタ値=2を1したカウンタ値=3をHTTPレスポンスフレームに格納して次の装置E20に送信する。8装置E20は、受信するHTTPレスポンスフレームのオプション領域のカウンタ値=3と、送信時のHTTPリクエストフレームのカウンタ値=1とを比較して、一致しないので自装置がエッジ装置ではないと判断する。そして、カウンタを1=4にしてユーザPC1に送信する。このように、IPヘッダまたはTCPヘッダのカウンタを利用して装置E自らがエッジ装置であるか否かを判別する。[装置Eの処理]次に、装置Eの処理について、図18および図19のフローチャートを用いて説明する。図18は、HTTPリクエスト時の処理を示すフローチャートである。先ず、ユーザPC1は、HTTPリクエストフレームを送信する。このHTTPリクエストフレームには、オプション領域は設定されておらず、ヘッダとデータのみで構成される通常のIPフレームである。ステップS101装置Eは、ユーザPC1から受信したHTTPリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件とは、本実施形態に係るネットワークシステム100の機能に対応するフレームの条件オプションタイプ=80、レングス/ベンダID内容、カウンタ値などである。例えば所定条件が以下の1から3のいずれかに該当する場合YesはステップS102に進み、いずれにも該当しない場合NoはステップS103に進む。1オプション領域が全て0パディングされている。2オプション領域が存在しない。3オプションタイプが80ではない、ベンダIDが異なる、カウンタ値が0である、など本実施形態で予め定めたフォーマットに合っていない。ステップS102装置Eは、オプション領域のカウンタ値を1に設定する。ステップS103装置Eは、オプション領域のカウンタ値をインクリメント1する。そして、オプション領域が設定されたHTTPリクエストフレームを次の装置Eに転送する。同様に、次の装置Eからその次の装置EにHTTPリクエストフレームを転送してサイトサーバS1まで送信する。ステップS104装置Eは、オプション領域のカウンタ値を内部メモリやHTTPデータベース154などに保持する。上記の例では、カウンタ値=1が保持される。次に、HTTPリクエストフレームを受信したサイトサーバS1は、HTTPレスポンスフレームを返信する。返信時の処理について図19のフローチャートを用いて説明する。サイトサーバS1が返信するHTTPレスポンスフレームは、装置Eから装置Eへ転送されながらユーザPC1まで送信される。ステップS201装置Eは、受信したHTTPリクエストフレームのオプション領域が所定条件に適合しているか否かを判別する。ここで、所定条件は先にステップS101で説明した条件と同じである。Yesの場合はステップS202に進み、Noの場合はステップS203に進む。ステップS202装置Eは、オプション領域を再設定して、ステップS104で保持したHTTPリクエストフレームのカウンタ値をインクリメント1した値を新たなカウンタ値として設定する。ステップS203装置Eは、図18のステップS104で保持したHTTPリクエストフレームのカウンタ値と、HTTPレスポンスフレームのカウンタ値とが等しいか否かを判別する。Yesの場合はステップS204に進み、Noの場合はステップS205に進む。ステップS204装置Eは、自装置がエッジ装置であると認識して、監視サーバA1に自装置がエッジ装置であることを通知する。ステップS205装置Eは、HTTPレスポンスフレームのカウンタ値をインクリメント1する。そして、次の装置Eに転送する。図19の例では、次の装置がユーザPC1なので、ユーザPC1にHTTPレスポンスフレームを送信する。このようにして、ユーザPC1から送信されたHTTPリクエストフレームは、オプション領域が設定され、カウンタ値を設定またはインクリメントしながらサイトサーバS1に送信され、サイトサーバS1から返信されるHTTPレスポンスフレームについても同様にオプション領域のカウンタ値を再設定またはインクリメントしながらユーザPC1まで送信される。そして、HTTPリクエストフレームを送信する際のカウンタ値と、受信するHTTPレスポンスフレームのカウンタ値とが等しい場合に自装置がエッジ装置であると判断して、監視サーバA1に自装置がエッジ装置であることを通知する。このように、装置Eは自装置がエッジ装置であるか否かの判別を自らが行うので、監視サーバA1は管轄する全ての装置Eがエッジ装置であるかの情報を予め保持しておく必要がなく、また、装置Eが増設されたり、サイトサーバS1が新たに装置Eに接続された場合でも常に最新のエッジ装置情報を得ることができる。[複数の基幹ネットワークが接続されている場合]先に説明した図1のネットワークシステム100は、1つのネットワーク101内に監視サーバA1、検索サーバK1、サイトサーバS1が配置されているので、監視サーバA1はネットワーク101を構成する全ての装置Eの状態を監視することができた。しかし実際には、ネットワーク101のような複数の基幹ネットワークが装置Eを介して互いに接続され、それぞれの基幹ネットワーク内にも検索サーバ、監視サーバおよびサイトサーバが配置されている。ここでは、複数の基幹ネットワークを有する場合の例について説明する。図20は、基幹ネットワークAの装置Xを介して基幹ネットワークBに接続されたネットワークシステム100aの構成例を示した図である。図20において、基幹ネットワーク101aは、先に説明したネットワーク101に対応し、ユーザPC1と、検索サーバK1と、監視サーバA1とがネットワーク101に接続されている。そして、装置Xを介して基幹ネットワーク101bに接続され、ネットワーク101bには、監視サーバA2と、サイトサーバS2とが接続されている。ここで、ユーザPC1が検索サーバK1に検索キーワードを含む検索要求を送信し、検索サーバK1は自分が持っている情報などから検索キーワードに該当する情報を公開している基幹ネットワーク101bのサイトサーバS2URLが抽出される。そして、検索サーバK1は監視サーバA1に該当するサイトサーバS2の情報URLがあるか否かを問い合わせる。監視サーバA1に該当するサイトサーバS2の情報URLがない場合は、検索サーバK1は監視サーバA1に他の監視サーバA2に対してサイトサーバS2の情報URLを持っているか否かを問い合わせる。問い合わせを受けた監視サーバA2はサイトサーバS2の情報URLがあるか否かを検索し、ある場合は監視サーバA1に対して応答する。応答を受けた監視サーバA1は、応答を返した監視サーバA2に対してサイトサーバS2のエッジ装置の負荷情報を要求する。要求を受けた監視サーバA2は、保持しているサイトサーバS2のエッジ装置Yの負荷情報を監視サーバA1に応答する。これを受けた監視サーバA1は、その負荷情報を検索サーバK1に送信する。このようにして、異なる基幹ネットワーク101aおよび基幹ネットワーク101bが接続される場合でも、それぞれのネットワークの監視サーバA1および監視サーバA2とが連携して該当するサイトサーバのエッジ装置から負荷情報を取得して、要求元の検索サーバK1に負荷情報を送信するので、検索サーバK1は、先の実施形態と同様に、検索結果のURLに対応する負荷情報をユーザPC1に提供することができる。次に、複数の基幹ネットワークを有する場合のネットワークシステム1001aの動作シーケンスについて図21を用いて説明する。図21において、ユーザPC1は検索サーバK1に検索キーワードを含む検索要求HTTPリクエストを送信する。検索サーバK1は、自身の検索サーバデータベース302を参照して、検索キーワードを含むURLリストを抽出する。そして、検索結果の各URLに対応する負荷情報を取得するためにサイトサーバの情報を持っているか否かを監視サーバA1に問い合わせる。図20の例では、基幹ネットワーク101aを管轄する監視サーバA1は、基幹ネットワーク101bに配置されているサイトサーバS2の情報を持っていないので、検索サーバK1にサイトサーバS2の情報無しの応答を行う。これを受けた検索サーバK1は、監視サーバA1にサイトサーバS2の情報を取得するように依頼する。一方、監視サーバA1は、サイトサーバS2の情報を取得するように検索サーバK1から依頼を受けると、他の基幹ネットワークに監視サーバA2、監視サーバA3および監視サーバA4などにサイトサーバS2の情報を持っているか否かの問い合わせを行う。そして、図20の例では、基幹ネットワーク101bの監視サーバA2がサイトサーバS2に接続されるエッジ装置Yを管轄しているので、サイトサーバS2の情報を持っていることを監視サーバA1に応答する。尚、監視サーバA2は、先の実施形態で説明したように、サイトサーバS2のエッジ装置が装置Yであることを装置Y自身から通知されているので、サイトサーバS2のURLに対応するエッジ装置が装置Yであることを認識している。また、サイトサーバS2の情報を持っていない監視サーバA3および監視サーバA4からは応答されない。そして、監視サーバA2からサイトサーバS2の情報を持っているという応答を受信した監視サーバA1は、監視サーバA2に対してエッジ装置の負荷情報を要求する。これを受けた監視サーバA2は、先の実施形態で説明した手順でエッジ装置YからサイトサーバS2が接続されているポートの負荷情報を取得して監視サーバA1に応答する。そして、監視サーバA1から検索サーバK1にエッジ装置Yの負荷情報が送信され、検索サーバK1で検索結果のURLに対応する負荷情報を表示してユーザPC1に検索結果として提供する。このようにして、サイトサーバS2がユーザPC1および検索サーバK1が接続される基幹ネットワーク101aとは異なる基幹ネットワーク101bにある場合でも、基幹ネットワーク101aの監視サーバA1から基幹ネットワーク101bの監視サーバA2に問い合わせることによって、先の実施形態と同様に、ユーザPC1で検索結果のURL毎に負荷情報が表示された画面を確認することができる。[異なる基幹ネットワークに接続する装置の処理]次に、図20で説明したネットワークシステム100aにおいて、基幹ネットワーク101aの装置Xは、基幹ネットワーク101bへの接続口になっている。このため、装置Xは、先に説明した図17のルータR1に接続される装置E24の場合と同様に、自装置がエッジ装置であると判断し、監視サーバA1にこれを通知することが考えられる。この場合は、図22に示すように、監視サーバA1内の監視サーバデータベース301に他の基幹ネットワークに接続している装置リストを予め登録しておくことにより、装置Xから自装置がエッジ装置であると通知してきた場合でも、エッジ装置ではないと判断できる。そして、図21で説明したように、他の基幹ネットワークの監視サーバに対して問い合わせを行い、実際にサイトサーバに接続されているエッジ装置から負荷情報を取得することができる。このようにして、他の基幹ネットワークに接続している装置リストを監視サーバに予め登録しておくことにより、他の基幹ネットワークへの接続口の装置がエッジ装置であると誤認識した場合でも、当該装置が真のエッジ装置であるか否かの判断を行うことができ、必要に応じて他の基幹ネットワークの監視サーバから真のエッジ装置の負荷情報を取得することができる。以上、各実施形態において説明してきたように、本発明に係るネットワークシステムは、スイッチ装置自らがエッジ装置であるか否かを判別してサイトサーバのURLに対する負荷情報を蓄積し、検索サーバはエッジ装置から取得した負荷情報と検索結果のURLとを対応させたWEB検索結果を端末装置に提供することができる。尚、本発明に係る設定情報参照起動型の制御装置および設定情報管理方法について、各実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。"