(57)【要約】【課題】本発明は最寄りサーバの選択方法，選択システム及びプログラムに関し，同一サービスを提供する複数のサーバの中かクライアントがサーバ・クライアント間の往復の経路の実際のホップ数を確実に求め，最短のサーバを選択することを目的とする。【解決手段】クライアントがサーバへのサービス要求が発生すると，各サーバを宛先とする要求パケットのヘッダのＴＴＬの初期値として所定のホップ数を設定して要求パケットを送信し，宛先の各サーバは要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのＴＴＬとして受信パケットのＴＴＬの値を複写してクライアントへ送信し，クライアントは受信したサービスパケットのＴＴＬの値から往復ホップ数を検出して保持し，保持した中から最小の往復ホップ数であるサーバを識別し，宛先のサーバとして選択するよう構成する。【選択図】図１
2010268368.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するサーバ選択方法において，
クライアントで前記サーバへのサービス要求が発生すると，各サーバを宛先とする要求パケットのヘッダのＴＴＬ（生存時間）の初期値として所定のホップ数を設定して要求パケットを送信し，
前記要求パケットを受信する前記宛先の各サーバで前記要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのＴＴＬとして前記受信した要求パケットが保持するＴＴＬの値を複写してサービスパケットを前記クライアントへ送信し，
前記クライアントは前記各サーバから受信したサービスパケットのＴＴＬの値から当該クライアントと前記サーバとの間の往復ホップ数を検出して保持し，保持した各サーバに対応する往復ホップ数の中から最小の往復ホップ数であるサーバを識別し，前記識別したサーバを宛先のサーバとして選択することを特徴とするサーバ選択方法。
【請求項２】
ネットワークに接続するクライアントと同一サービスを提供する複数サーバとで構成され，複数サーバの中から最短のサーバを選択するサーバ選択システムにおいて，
前記クライアントは前記サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成すると共にそのヘッダのＴＴＬ（生存時間）としてネットワークの片道の最大のホップ数の２倍以上の値を設定する要求パケット生成部を備え，
前記要求パケットを受信する各サーバは，前記クライアントからの要求パケットを受信すると該クライアントへのサービスパケットを生成する共にそのヘッダのＴＴＬとして前記受信した要求パケットが保持するＴＴＬの値を複写して設定するサービスパケット生成部を備え，
前記クライアントは更に，前記各サーバからのサービスパケットを受信すると，受信サービスパケットのＴＴＬの値から各サーバ別の往復ホップ数を検出してメモリに格納する往復ホップ数検出手段と，前記メモリに格納した各サーバ別の往復ホップ数から最小数のサーバを選択する手段を備える，
ことを特徴とするサーバ選択システム。
【請求項３】
ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するためのプログラムであって，
前記クライアントのコンピュータを，                                              前記サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成する時にそのヘッダのＴＴＬ（生存時間）としてネットワークの所定の値の初期値を設定して送信する手段と，
前記要求パケットを受信した各サーバからの前記受信した要求パケットが保持するＴＴＬの値を複写したサービスパケットを受信する手段と，
前記サーバから受信したサービスパケットのＴＴＬの値と前記初期値とから往復ホップ数を検出する手段と，
前記検出した各サーバに対応する往復ホップ数の値の中から最小の値であるサーバを識別して最短のサーバとして選択する手段と，
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークに接続されたクライアントにより同一サービスを提供する複数のサーバの中から最短の（最寄り）サーバを選択するサーバの選択方法，選択システム及びプログラムに関する。
【背景技術】
【０００２】
情報通信社会の進展に伴い，インターネット等のネットワークのトラヒックの増大が続いており，回線速度は光技術の進歩によって年々伸びており，今後も更に伸びると予想されるが，従来の電子式パケット交換の更なる高速化は困難となってきており，より高速な光パケット交換技術は研究段階である。ネットワークには膨大な数のパーソナルコンピュータ，ワークステーションや携帯端末等のクライアントがＬＡＮ（Local Area Network) 等に設けたルータ等のネットワークインタフェースを介して接続され，同様にネットワークに接続された各種の情報サービスを提供するサーバの中から目的とする一つのサーバにアクセスし，サーバとの間で情報を送受することにより各種の情報について情報処理のサービスを受けることができる。しかし，サーバの中には，提供する情報が多くのクライアントが必要としたり，多くの人が関心を寄せる情報を提供するサーバがあり，そのようサーバには負荷がかかるため，同じ情報を提供することができる複数のサーバを設けて負荷を分散する方法をとることが従来から採用されている。
【０００３】
このような，複数サーバにより同じ情報を提供する例としては，例えば，ネットワークに所属するサーバやクライアントの時刻を標準時刻に同期させるための時刻情報を提供するＮＩＣＴ（National Institute  of Information and Communications Technology) 公開のＮＴＰ（Network Time Protocol)サービスや，要求（リクエスト）に応じて映像等を多数のユーザに提供するＣＤＮ（Contents Delivery Network:コンテンツ配信ネットワーク）サービス等の各種の情報を提供するサーバがある。
【０００４】
上記のような標準時刻を提供するＮＴＰサーバや，コンテンツを提供するＣＤＮサーバ等では，ネットワークのサーバの負荷分散を行うためのサーバ選択方法の一つとして，ＤＮＳ（Domain Name Server) ラウンドロビン方式がある。ＤＮＳは，サービスを提供するサーバのドメイン名を指定したクライアントからの要求（リクエスト）に対して，ドメイン名をＩＰアドレスに変換してクライアントに提供するサービスを行うが，ＤＮＳラウンドロビン方式では，一つのドメイン名に対して複数のサーバが設けられ，それぞれのサーバに異なる複数のＩＰアドレスが設定されている場合に，そのドメイン名へのアクセス要求に対して，複数のサーバのＩＰアドレスを順番に一つずつクライアントに割り当て，各クライアントはそれぞれ異なるサーバ（設定されたサーバの個数の範囲内）にアクセスすることになる。
【０００５】
しかし，ＤＮＳラウンドロビン方式ではサーバとクライアント間の距離を考慮したものではないことは明かであり，最寄りのサーバを選択するものではない。
【０００６】
また，負荷分散の技術として，ネットワークに多数のサーバと，サーバのグループ間で網トラヒックと負荷を平衡させる複数の負荷バランスサーバを設け，更にサーバのグループのために負荷を平衡させる役割を担う負荷バランスサーバセレクタを設け，クライアントからの通信要求は負荷バランスサーバセレクタに照会され，負荷バランスサーバセレクタは要求に対する適切な負荷バランスサーバを決定し，決定した負荷バランスサーバはクライアント要求を受信するとサーバグループ間で負荷をバランスさせるためのサーバを選択し，選択されたサーバはクライアントにより要求されたタスクを実行する方法がある（特許文献１）。また，同じ情報をホスティングするウエブサーバである複数のノードによりクラスタを構成し，その中の一つのノードをマスターノードとして指定し，マスターノードはクラスタ内の他のノードの状態情報（負荷率，接続数）を収集し，クライアントからのＤＮＳ問合せに対して負荷のバランスをとるようにノードを選択してクライアントに応答する方法もある（特許文献２）。
【０００７】
このような複数のサーバの負荷を分散する方式では，交換機の負荷軽減に寄与するが，最寄りのサーバを選択することを目的とするものではなく，伝送距離を考慮するものではない。
【０００８】
同じサービスを提供する複数のサーバからユーザ（クライアント）が最寄りのサーバを選択する際には伝搬距離よりも経由する交換機（主にルータ）の段数（ホップ数）を尺度とするのが適している。
【０００９】
一方，ＡＳ（Autonomous System:統一したポリシーで運用管理されるネットワークの集まり) 間の経路情報データベース（ＲＡＤＩＸと呼ばれる）を元にドメインネームの名前解決をするＴＥＮＢＩＮが提案されている（非特許文献１）。しかし，この方式では経路の情報を使用するために必ずしもホップ数が最小とはならない。しかも，ネットワークセキュリティの観点から不要なポートを閉じることが多く，ＩＣＭＰ(Internet Control Message Protocol) を利用できない環境が増えてきている。
【００１０】
複数のホスト（ミラーホスト）についてホップ数を計測するために，ＩＣＭＰのｐｉｎｇ（Packet InterNetwork Groper: エコー要求メッセージとエコー応答メッセージとによる確認を行うためのツール) を用いたｎｅｔｓｅｌｅｃｔというツールがある（非特許文献２）。その実行結果として，推定ｐｉｎｇ時間とホップ数（接続要求が目的地に到達するまでに経由したホスト数）を計算した値を得ることができるが，そのツールでは往路のホップ数しか調べることができない。また，ｔｒａｃｅｒｏｕｔｅというコマンドも知られており，このコマンドはＴＴＬの初期値を１から順番に１つずつ増加させたパケットをサーバに向けて送信し，ＴＴＬが０となるルータから返送される“Time Exeeded”パケットを解析することにより，経路上のルータを順番に探索した結果を表示する。しかし，このコマンドもホストまでの往路のルータを検出するものである。
【００１１】
また，ネットワーク内の時刻を同期させるために基準時刻を持つＮＴＰ（Network Time Protocol)サーバの時刻に同期させるためのプログラムとしてｎｔｐｄ（Network Time Protocol Daemon）があるが，これによるとサーバの時刻安定度と遅延時間のジッタからサーバの選択が行われており，ホップ数は考慮されていない。
【００１２】
このように，まだ正確な距離に対応したサーバ選択方式は提案されていない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０００−３１１１３０号公報
【特許文献２】特開２００８−５３７４００号公報
【非特許文献】
【００１４】
【非特許文献１】下川，中川，山本，吉川「広域分散Ｗｅｂサーバにおける経路情報を用いたサーバ選択」，電子情報通信学会技術研究報告，ＩＡ，インターネットアーキテクチャ，１０１，４４０，PP49-56,２００１年
【発明の概要】
【発明が解決しようとする課題】
【００１５】
上記特許文献１や特許文献２に開示された方法では，複数のサーバの負荷をバランスすることを目的とするもので，クライアントからサーバまでの経路やホップ数を考慮するものではない。
【００１６】
また，従来のｐｉｎｇを応用したｎｅｔｓｅｌｅｃｔや，ｔｒａｃｅｒｏｕｔｅ等のツールを用いた方法も往路のホップ数を検出したり，往路の経路のルータを表示するものであり，往復の経路の正確なホップ数を検出するものではない。
【００１７】
本発明は同一サービスを提供する複数のサーバの中かクライアントから往復の経路が短いサーバを選択することが可能なサーバの選択方法，選択システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明のサーバ選択方法は，ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するため，クライアントでサーバへのサービス要求が発生すると，各サーバを宛先とする要求パケットのヘッダのＴＴＬ（生存時間）の初期値として所定のホップ数を設定して要求パケットを送信し，要求パケットを受信する宛先の各サーバは要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのＴＴＬとして受信した要求パケットが保持するＴＴＬの値を複写してサービスパケットをクライアントへ送信し，クライアントは各サーバから受信したサービスパケットのＴＴＬの値からクライアントとサーバとの間の往復ホップ数を検出して保持し，保持した各サーバに対応する往復ホップ数の値の中から最小の往復ホップ数であるサーバを識別し，識別したサーバを宛先のサーバとして選択するものである。
【００１９】
また，本発明のサーバ選択システムは，クライアントからのサーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成すると共にそのヘッダのＴＴＬ（生存時間）としてネットワークの片道の最大のホップ数の２倍以上の値を設定する要求パケット生成部を備え，要求パケットを受信する各サーバは，クライアントからの要求パケットを受信すると該クライアントへのサービスパケットを生成すると共にそのヘッダのＴＴＬとして受信した要求パケットが保持するＴＴＬの値を複写して設定するサービスパケット生成部を備え，クライアントは更に，各サーバからのサービスパケットを受信すると，受信サービスパケットのＴＴＬの値から各サーバ別の往復ホップ数を検出してメモリに格納する往復ホップ数検出手段と，メモリに格納した各サーバ別の往復ホップ数から最小数のサーバを選択する手段を備えるよう構成したものである。
【００２０】
更に，本発明によるプログラムは，クライアントのコンピュータを，サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成する時にそのヘッダのＴＴＬ（生存時間）としてネットワークの所定の値の初期値を設定して送信する手段と，要求パケットを受信した各サーバからの受信した要求パケットが保持するＴＴＬの値を複写したサービスパケットを受信する手段と，サーバから受信したサービスパケットのＴＴＬの値と前記初期値とから往復ホップ数を検出する手段と，検出した各サーバに対応する往復ホップ数の値の中から最小の値であるサーバを識別して最短のサーバとして選択する手段と，して機能させるよう構成したものである。
【発明の効果】
【００２１】
本発明により，クライアントから同じサービスを提供する複数のサーバの中から要求パケットの往路の経路のホップ数と，要求パケットに応答するサービスパケットの経路のホップ数が最小である，すなわち最短である可能性が高いサーバを選択することができる。これにより，クライアントは同一サービスを提供する複数のサーバの中から最短距離のサーバからの情報を得ることができ，従って最も遅延が少ないサーバからの情報を取得することが可能となる。
【００２２】
そして，同じサービスを提供するサーバが標準の時刻情報をサービスする時刻サーバである場合，最短距離で時刻情報を得ることができるため精度の高い時刻情報によりクライアント（またはサーバ）のシステムを運用することができる。
【００２３】
また，クライアントがコンテンツデリバティネットワークのサーバからコンテンツを得る場合，近距離のサーバからのサービスを受けることで，ユーザへのサービス品質を向上することが可能となる。また，各クライアントがそれぞれ同一サービスを提供するサーバの中からネットワークの最短のルートを通るサーバを選択してパケットを送受信することにより，ネットワークの余分なルートを通らなくなるため他のユーザのパケットの通信への影響をなくすことが可能となる。
【図面の簡単な説明】
【００２４】
【図１】本発明による原理構成を示す図である。
【図２】クライアントとサーバ間のホップ数の説明図である。
【図３】クライアントとサーバのハードウェア構成を示す図である。
【図４】クライアント及びサーバにおけるフローチャートを示す図である。
【図５】受信パケットのＴＴＬ値の分布を示す図である。
【図６】ＴＴＬ値の累積分布を示す図である。
【図７】解析に利用したホスト数の推定ホップ数分布を示す図である。
【図８】ホップ数と擬似遅延のジッタの関係を示す図である。
【発明を実施するための形態】
【００２５】
図１は本発明による原理構成を示す図であり，図中，１はクライアント，１０は制御部，１１は要求パケット生成部，１２は送信部，１３はインターネットのようなネットワークとのプロトコルに基づく通信を実行する通信インタフェース（通信ＩＦ），１４は受信部，１５は往復ホップ数検出部，１６はメモリ，１７は最寄りサーバ選択部である。２は同一サービスを提供する複数のサーバの中の一つのサーバ，２０は制御部，２１は受信部，２２は受信した要求パケット中のＴＴＬをサービスパケットのヘッダのＴＴＬの値として設定するＴＴＬ複写手段，２３は通信インタフェース（通信ＩＦ），２４はサービスパケット生成部，２５は送信部である。３はネットワークである。図１にはネットワーク３にクライアント１とサーバ２が１台だけ接続されているが，サーバ２と同一サービスを提供する他の複数のサーバや，他の多数のクライアントが図示省略されているが接続され，ネットワーク３には図示省略された多数のルータが配置されている。
【００２６】
ここで，ＴＴＬについて説明すると，ＴＴＬはＩＰｖ４（Internet Protocol version 4)のヘッダではデータグラムがインターネットのネットワーク上で生存可能な時間を意味する生存時間（ＴＴＬ：Time to Live) を指定するフィールドとして使用され，当初は生存時間が０になるとそのパケットが廃棄されることになっていたが，現在ではルータを経由する度にＴＴＬの値を１つ減らすように実装されるようになり，経由するルータの可能ホップ数として使用され，その後に提案されたＩＰｖ6 （Internet Protocol version 6)のヘッダではホップリミット（Hop Limit)フィールドとして使用され，ルータを通過するたびに１つずつ減らされ，その値が０になった時点でパケットを廃棄することが知られている。本願発明の以下の説明，「ＴＴＬ」という用語は，ＩＰｖ４のヘッダのＴＴＬとＩＰｖ６のヘッダのホップリミットの両方を表すものとして使用する。
【００２７】
図１において，ネットワーク３には同一サービスを提供する複数サーバとクライアントが接続され相互にルータにより接続されており，その中の一つのクライアント１から同一サービスを提供する複数サーバに対してサービスを要求する場合，制御部１０から要求パケット生成部１１を駆動する。なお，複数のサーバ（サーバ２を含む）のそれぞれの宛先は予め登録されているものとし，要求パケットのヘッダにはＴＴＬの初期値として通常のＴＴＬより大きな値（通常の２倍以上）を設定する。要求パケットは送信部１２から通信ＩＦ１３を介してネットワーク３へ送信される。ネットワーク３を通る要求パケットのＴＴＬの値は，１つのルータを経由する毎に１だけ減算される。サーバ２で要求パケットを受信すると，通信ＩＦ２３を通って受信部２１で受信される。制御部２０で要求パケットについて識別し，要求された情報をサービスパケット生成部２４に設定し，ＴＴＬ複写手段２２が受信部２１内の要求パケットに含まれているＴＴＬをそのままサービスパケットのヘッダのＴＴＬとして複写し，要求パケットの送信元であるクライアント１を宛先とし，サービスパケットを送信部２５から通信ＩＦ２３を介して送信する。
【００２８】
このサービスパケットはネットワーク３を通る時，往路と同じ経路を通るとは限らないが，そのＴＴＬの値は１つのルータを通る毎に１だけ減算されて，宛先のクライアント１に送られる。このサービスパケットがクライアント１の通信ＩＦ１３を介して受信部１４で受信されると，往復ホップ数検出部１５で受信パケット内のＴＴＬを検出する。このＴＴＬの値はクライアント１から送信される時の初期値がサーバ２に到達するまでの往路のホップ数だけ減算され，更にサーバ２からのサービスパケットがクライアント１へ到達するまでの復路のホップ数の分だけ減算されるため，往復のホップ数を検出することができ，その往復ホップ数をメモリ１６に格納する。
【００２９】
クライアント１から送信される要求パケット中のＴＴＬ値の初期値をＴo ，サーバ２から受信したサービスパケットのＴＴＬ値をＴr とし，往復ホップ数をＨとすると，Ｈは次の式で得られる。
【００３０】
Ｈ＝Ｔo −Ｔr 
こうして，クライアント１において複数の各サーバから受信したサービスパケットから，それぞれの往復ホップ数が検出されてメモリ１６に格納された状態で最寄りサーバ選択部１７はメモリ１６に格納された各サーバ別の往復ホップ数の中から最小の数値を持つサーバを選択する。選択したサーバを新たな要求パケットの宛先として要求パケット生成部１１のヘッダに設定する。これにより，新たな要求パケットは最も少ないルータを経由してサーバとの間を往復し，最短な経路を通ることになる。
【００３１】
本発明による相手サーバにおいて受信したパケットのＴＴＬ値をそのままクライアントへ送るパケットのＴＴＬ値として複写してクライアントへ送る方法を言い換えると，ＴＴＬの折り返し方法と表現することができる。この方法では，往復のホップ数の合計がＴＴＬの初期値を越えると，途中のルータでパケットが廃棄されてしまうので，初期ＴＴＬ値は十分に大きな値とすることにより廃棄されることを防止でき，具体的には，パケットの送出時のＴＴＬの初期値として，インターネットのようなネットワークの直径（最長パス）の２倍程度がＲＦＣ１１２２，ＩＥＴＦ（１９８９）で推奨値されており，その値を用いることにより往復ホップ数が０になることを防止できる。
【００３２】
図２はクライアントとサーバ間のホップ数の説明図である。図中，Ｃ１，Ｃ２はクライアント，Ｓ１，Ｓ２は同じサービスを提供するサーバ，Ｒはネットワークに設けられた３ａ〜３ｐで表すルータである。クライアントＣ１からサーバＳ１，Ｓ２に対して要求パケットを送信した場合，サーバＳ１へのパケットはルータ３ａ，３ｂ，３ｃを経由するルート１−１を通ってサーバＳ１に到達し，サーバＳ２へのパケットがルータ３ａ，３ｋ，３ｍ，３ｏ，３ｐ，３ｇを経由するルート１−２を通ってサーバＳ２に到達し，各サーバＳ１，Ｓ２からサービスパケットが送り返されてきた場合がある。なお，この図２では往復のルートが同じであるものとしているが，実際には同じであるとは限らない。このルート１−１では往復ホップ数は６であり，ルート１−２は往復ホップ数は１２となり，最小の往復ホップ数が６であるサーバＳ１が選択される。クライアントＣ２からサーバＳ１，Ｓ２に対して要求パケットを送った場合にも，図２に示すルート２−１，２−２を通ってサーバＳ１，Ｓ２に送られ，そこから送り返されたサービスパケットをクライアントＣ２で受け取ることで，往復ホップ数を検出することで，ルート２−２が最小の往復ホップ数となって，クライアントＣ２はサーバＳ２を選択することになる。
【００３３】
図３はクライアントとサーバのハードウェア構成を示す。図中，４はクライアント（またはサーバ），４０はプロセッサ，４１はメモリでありデータやプログラムを保持し，４２−１，４２−２はインターネットのようなネットワークと接続してパケットの送受信を行う通信インタフェース，４３は外部記憶装置である。
【００３４】
図４はクライアント及びサーバにおけるフローチャートであり，図３に示す構成を備えたクライアント及びサーバのプロセッサにおいて実行される。
【００３５】
クライアントでは，図４のＡ．に示すように要求パケットを発生する指示がアプリケーション等から発生すると，要求パケットが生成され（図４のＳ１０），そのパケットのヘッダのＴＴＬに初期値（Ｔo ）を設定する（同Ｓ１１）。上記の要求パケットは予め要求に対応するサービスを提供する複数（Ｎ個とする）のサーバのアドレスが当該クライアントに登録されているものとし，各サーバ（１〜Ｎ）に向けて要求パケットが生成されて，通信インタフェースを介してインターネットのようなネットワークに送信される（図４のＳ１２）。この後，サーバからのサービスパケットを受信したか判別する処理が実行され（図４のＳ１３），受信されるとサービパケットからＴＴＬの抽出をする（同Ｓ１４）。このＴＴＬの値はＴr (k) とする。但し，ｋはサーバの番号とし，ｋは１〜Ｎの何れかである。次にサーバ（ｋ）との往復ホップ数（Ｈ(k) とする）を計算する（図４のＳ１５）。すなわち，サーバｋについてのホップ数は，Ｈ(k) ＝Ｔo −Ｔr (k) の計算により求められる。
【００３６】
このようにして各サーバについてのホップ数を求めてメモリに格納した後，その中から最小のホップ数Ｈ(k0)を求める，その計算はmin ｛Ｈ(k) ｜k ＝1,...N｝の式により表す（図４のＳ１６）。こうして，番号(k0)のサーバが最寄りサーバとして決定される（図４のＳ１７）。クライアントでは決定した最寄りサーバを宛先として要求パケットの送信を行うことになる。
【００３７】
クライアントからの要求パケットを受け取る各サーバ（ｋとする）では，図４のＢ．に示す処理を実行する。サーバにおいて要求パケットを受信したか判別し（図４のＳ２０），要求パケットを受信したことを判別すると，要求パケットからＴＴＬを抽出する（同Ｓ２１）。この場合のＴＴＬの値をＴs (k) とする。次に要求された情報を含むサービスパケットを生成し（図４のＳ２２），そのヘッダのＴＴＬに返送値（Ｔs (k) ）を設定し（同Ｓ２３），サービスパケットを要求パケットを送ってきたクライアントに送出する（同Ｓ２４）。この後，ステップＳ２０に戻って，他の要求パケットの受信を判別する処理を実行する。
【００３８】
ここで，情報サービスを提供するサーバの一つである上記ＮＴＰサーバで受信した要求パケットを解析した結果として受信パケットのＴＴＬ値の分布を図５に示す。また，ＴＴＬ値の累積分布を図６に示す。図５，図６の横軸は受信時のパケットのＴＴＬ値を示し，ビン幅（bin:度数分布を作る際のデータの刻みを表す）は“１”であり，図５の縦軸は各受信時ＴＴＬ値となるホストの割合を示し，対数スケールであり，図６の縦軸は累積ホストの割合を表し，対数スケールである。このＮＴＰサーバには１００万台以上のホストからの利用があり，パーソナルコンピュータ（ＰＣ）だけでなく，ルータやその他の組込機器からも利用されている。図５により，ホストのＴＴＬ値は４つの分布に分かれているが，それぞれの分布の幅は３２程度である。分布の幅は，クライアントからサーバへの往路のホップ数の分布を示していると考えられるため，このＮＴＰサーバのユーザエリアの直径は３２ホップ程度と推定される。従って，初期ＴＴＬ値がＩＡＮＡ（Internet Assigned Numbers Authority)の推奨値「６４」以上であれば，往復でもパケットが廃棄されることは稀であるが，インターネットのネットワーク全体の直径は「３２」以上よりも大きいと考えられ，初期ＴＴＬ値は「１２８」または「２５６」とすることが望ましい。
【００３９】
次に最寄りサーバを利用することによる通信品質を改善することができる理由を説明する。ＮＩＣＴ公開のＮＴＰサーバとクライアントの間の片方向遅延のジッタ尺度として，品質を評価すると，遅延時間の計測としてＮＴＰのリクエストパケット中の送信時刻フィールドとＮＴＰサーバでの受信時刻を比較した結果，両者の差には遅延時間だけでなく，送信側の時計と受信側の時計の差を含んでいるため，この観測量を擬似遅延と呼ぶ。遅延ジッタ（遅延のゆれ）が大きいと，時計の同期精度も劣化するため，ＮＴＰリクエストを用いた擬似遅延計測は遅延ジッタの評価に適している。そのため，まず１００万台を越えるＮＩＣＴ公開ＮＴＰサービス利用のホストの中から，十分な回数のポーリング（時刻問合わせ）を行っているホストを抜き出す。ポーリング頻度が高いほど時刻同期精度は向上し，データが少ないと統計処理で誤差が生じ安い。
【００４０】
ＮＩＣＴ公開ＮＴＰサービスでは，一般の利用者に対して１日当たりのポーリング回数を一定数（４８０回）以内とするようにしているため，その回数以上のポーリング回数のホストの擬似遅延を統計処理すると，対象となるホストは２７５１台有り，ＮＴＰサーバ到着時のＴＴＬ値から，ホスト数の経由ホップ数分布を推定した結果が図７である。図７は解析に利用したホスト数の推定ホップ数分布を示す図である。到着時のＴＴＬは上記図５に示したように０〜２５５の範囲に分布しているが，４つの分布に分かれているため，それぞれの分布に対して，初期ＴＴＬ値がそれぞれ，３２，６４，１２８，２５５だったと仮定して，経由ホップ数を推定した。対象ホストが１００台以上あるホップ数は１１から１９の範囲であり，それ以外では急速に減少する。
【００４１】
ホップ数と擬似遅延のジッタの関係を図８に示す。図８では，横軸はホップ数，縦軸は各ホストの１日の擬似遅延の標準偏差を対数目盛で示し，図中“Ａｌｌ”は対象としているホスト全てのデータであり，“Ｍｉｎ”はデータ数が豊富なホップ数１１から１９に対して最小値を示している。さらに，ＮＴＰサーバが接続しているＬ２スイッチに接続しているホストのデータをホップ数０として加えている。最小値データは，ホップ数に対して直線上に乗っていることが分かる。図８の“Ｍｉｎ”データは各ホップ数における同期精度の限界を示しており，“Ｍｉｎ”データについて回帰分析し，ホップ数ｈに対するジッタの最小値σmin (h) に関して次の実験式が得られる。但し，σ0 は同一セグメントでのジッタを表し，αは１段のホップ増加に伴う劣化度を表し，α＝1.15，σ0 ＝11.5×10-6とする。
【００４２】
σmin (h) ＝αh σ0 
ここで注目する点は，擬似遅延のジッタはホップ数に対して加算的（または比例関係）ではなく，べき乗の関係を有していることであり，ホップ数が大きくなると指数関数的に品質が劣化してしまうことが理解でき，本発明によりクライアントから同一サービスを提供する複数のサーバの中から往復ホップ数が少ないサーバを選択することにより，通信品質の向上を実現することができることは明かである。
【符号の説明】
【００４３】
１        クライアント
１０      制御部
１１      要求パケット生成部
１２      送信部
１３      通信インタフェース（通信ＩＦ）
１４      受信部
１５      往復ホップ数検出部
１６      メモリ
１７      最寄りサーバ選択部
２        サーバ
２０      制御部
２１      受信部
２２      ＴＴＬ複写手段
２３      通信インタフェース（通信ＩＦ）
２４      サービスパケット生成部
２５      送信部
３        ネットワーク  
【図１】
2010268368.tif 000003
【図２】
2010268368.tif 000004
【図３】
2010268368.tif 000005
【図４】
2010268368.tif 000006
【図５】
2010268368.tif 000007
【図６】
2010268368.tif 000008
【図７】
2010268368.tif 000009
【図８】
2010268368.tif 000010