JP2010268368A - ネットワークにおけるサーバ選択方法,選択システム及びプログラム - Google Patents

ネットワークにおけるサーバ選択方法,選択システム及びプログラム Download PDF

Info

Publication number
JP2010268368A
JP2010268368A JP2009119878A JP2009119878A JP2010268368A JP 2010268368 A JP2010268368 A JP 2010268368A JP 2009119878 A JP2009119878 A JP 2009119878A JP 2009119878 A JP2009119878 A JP 2009119878A JP 2010268368 A JP2010268368 A JP 2010268368A
Authority
JP
Japan
Prior art keywords
server
client
packet
service
ttl
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009119878A
Other languages
English (en)
Other versions
JP5283271B2 (ja
Inventor
Akihiko Machizawa
朗彦 町澤
Yasushi Toriyama
裕史 鳥山
Tsukasa Iwama
司 岩間
Haruo Saito
春夫 齊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National Institute of Information and Communications Technology
Original Assignee
National Institute of Information and Communications Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Institute of Information and Communications Technology filed Critical National Institute of Information and Communications Technology
Priority to JP2009119878A priority Critical patent/JP5283271B2/ja
Publication of JP2010268368A publication Critical patent/JP2010268368A/ja
Application granted granted Critical
Publication of JP5283271B2 publication Critical patent/JP5283271B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】本発明は最寄りサーバの選択方法,選択システム及びプログラムに関し,同一サービスを提供する複数のサーバの中かクライアントがサーバ・クライアント間の往復の経路の実際のホップ数を確実に求め,最短のサーバを選択することを目的とする。
【解決手段】クライアントがサーバへのサービス要求が発生すると,各サーバを宛先とする要求パケットのヘッダのTTLの初期値として所定のホップ数を設定して要求パケットを送信し,宛先の各サーバは要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのTTLとして受信パケットのTTLの値を複写してクライアントへ送信し,クライアントは受信したサービスパケットのTTLの値から往復ホップ数を検出して保持し,保持した中から最小の往復ホップ数であるサーバを識別し,宛先のサーバとして選択するよう構成する。
【選択図】図1

Description

本発明はネットワークに接続されたクライアントにより同一サービスを提供する複数のサーバの中から最短の(最寄り)サーバを選択するサーバの選択方法,選択システム及びプログラムに関する。
情報通信社会の進展に伴い,インターネット等のネットワークのトラヒックの増大が続いており,回線速度は光技術の進歩によって年々伸びており,今後も更に伸びると予想されるが,従来の電子式パケット交換の更なる高速化は困難となってきており,より高速な光パケット交換技術は研究段階である。ネットワークには膨大な数のパーソナルコンピュータ,ワークステーションや携帯端末等のクライアントがLAN(Local Area Network) 等に設けたルータ等のネットワークインタフェースを介して接続され,同様にネットワークに接続された各種の情報サービスを提供するサーバの中から目的とする一つのサーバにアクセスし,サーバとの間で情報を送受することにより各種の情報について情報処理のサービスを受けることができる。しかし,サーバの中には,提供する情報が多くのクライアントが必要としたり,多くの人が関心を寄せる情報を提供するサーバがあり,そのようサーバには負荷がかかるため,同じ情報を提供することができる複数のサーバを設けて負荷を分散する方法をとることが従来から採用されている。
このような,複数サーバにより同じ情報を提供する例としては,例えば,ネットワークに所属するサーバやクライアントの時刻を標準時刻に同期させるための時刻情報を提供するNICT(National Institute of Information and Communications Technology) 公開のNTP(Network Time Protocol)サービスや,要求(リクエスト)に応じて映像等を多数のユーザに提供するCDN(Contents Delivery Network:コンテンツ配信ネットワーク)サービス等の各種の情報を提供するサーバがある。
上記のような標準時刻を提供するNTPサーバや,コンテンツを提供するCDNサーバ等では,ネットワークのサーバの負荷分散を行うためのサーバ選択方法の一つとして,DNS(Domain Name Server) ラウンドロビン方式がある。DNSは,サービスを提供するサーバのドメイン名を指定したクライアントからの要求(リクエスト)に対して,ドメイン名をIPアドレスに変換してクライアントに提供するサービスを行うが,DNSラウンドロビン方式では,一つのドメイン名に対して複数のサーバが設けられ,それぞれのサーバに異なる複数のIPアドレスが設定されている場合に,そのドメイン名へのアクセス要求に対して,複数のサーバのIPアドレスを順番に一つずつクライアントに割り当て,各クライアントはそれぞれ異なるサーバ(設定されたサーバの個数の範囲内)にアクセスすることになる。
しかし,DNSラウンドロビン方式ではサーバとクライアント間の距離を考慮したものではないことは明かであり,最寄りのサーバを選択するものではない。
また,負荷分散の技術として,ネットワークに多数のサーバと,サーバのグループ間で網トラヒックと負荷を平衡させる複数の負荷バランスサーバを設け,更にサーバのグループのために負荷を平衡させる役割を担う負荷バランスサーバセレクタを設け,クライアントからの通信要求は負荷バランスサーバセレクタに照会され,負荷バランスサーバセレクタは要求に対する適切な負荷バランスサーバを決定し,決定した負荷バランスサーバはクライアント要求を受信するとサーバグループ間で負荷をバランスさせるためのサーバを選択し,選択されたサーバはクライアントにより要求されたタスクを実行する方法がある(特許文献1)。また,同じ情報をホスティングするウエブサーバである複数のノードによりクラスタを構成し,その中の一つのノードをマスターノードとして指定し,マスターノードはクラスタ内の他のノードの状態情報(負荷率,接続数)を収集し,クライアントからのDNS問合せに対して負荷のバランスをとるようにノードを選択してクライアントに応答する方法もある(特許文献2)。
このような複数のサーバの負荷を分散する方式では,交換機の負荷軽減に寄与するが,最寄りのサーバを選択することを目的とするものではなく,伝送距離を考慮するものではない。
同じサービスを提供する複数のサーバからユーザ(クライアント)が最寄りのサーバを選択する際には伝搬距離よりも経由する交換機(主にルータ)の段数(ホップ数)を尺度とするのが適している。
一方,AS(Autonomous System:統一したポリシーで運用管理されるネットワークの集まり) 間の経路情報データベース(RADIXと呼ばれる)を元にドメインネームの名前解決をするTENBINが提案されている(非特許文献1)。しかし,この方式では経路の情報を使用するために必ずしもホップ数が最小とはならない。しかも,ネットワークセキュリティの観点から不要なポートを閉じることが多く,ICMP(Internet Control Message Protocol) を利用できない環境が増えてきている。
複数のホスト(ミラーホスト)についてホップ数を計測するために,ICMPのping(Packet InterNetwork Groper: エコー要求メッセージとエコー応答メッセージとによる確認を行うためのツール) を用いたnetselectというツールがある(非特許文献2)。その実行結果として,推定ping時間とホップ数(接続要求が目的地に到達するまでに経由したホスト数)を計算した値を得ることができるが,そのツールでは往路のホップ数しか調べることができない。また,tracerouteというコマンドも知られており,このコマンドはTTLの初期値を1から順番に1つずつ増加させたパケットをサーバに向けて送信し,TTLが0となるルータから返送される“Time Exeeded”パケットを解析することにより,経路上のルータを順番に探索した結果を表示する。しかし,このコマンドもホストまでの往路のルータを検出するものである。
また,ネットワーク内の時刻を同期させるために基準時刻を持つNTP(Network Time Protocol)サーバの時刻に同期させるためのプログラムとしてntpd(Network Time Protocol Daemon)があるが,これによるとサーバの時刻安定度と遅延時間のジッタからサーバの選択が行われており,ホップ数は考慮されていない。
このように,まだ正確な距離に対応したサーバ選択方式は提案されていない。
特開2000−311130号公報 特開2008−537400号公報
下川,中川,山本,吉川「広域分散Webサーバにおける経路情報を用いたサーバ選択」,電子情報通信学会技術研究報告,IA,インターネットアーキテクチャ,101,440,PP49-56,2001年
上記特許文献1や特許文献2に開示された方法では,複数のサーバの負荷をバランスすることを目的とするもので,クライアントからサーバまでの経路やホップ数を考慮するものではない。
また,従来のpingを応用したnetselectや,traceroute等のツールを用いた方法も往路のホップ数を検出したり,往路の経路のルータを表示するものであり,往復の経路の正確なホップ数を検出するものではない。
本発明は同一サービスを提供する複数のサーバの中かクライアントから往復の経路が短いサーバを選択することが可能なサーバの選択方法,選択システム及びプログラムを提供することを目的とする。
本発明のサーバ選択方法は,ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するため,クライアントでサーバへのサービス要求が発生すると,各サーバを宛先とする要求パケットのヘッダのTTL(生存時間)の初期値として所定のホップ数を設定して要求パケットを送信し,要求パケットを受信する宛先の各サーバは要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのTTLとして受信した要求パケットが保持するTTLの値を複写してサービスパケットをクライアントへ送信し,クライアントは各サーバから受信したサービスパケットのTTLの値からクライアントとサーバとの間の往復ホップ数を検出して保持し,保持した各サーバに対応する往復ホップ数の値の中から最小の往復ホップ数であるサーバを識別し,識別したサーバを宛先のサーバとして選択するものである。
また,本発明のサーバ選択システムは,クライアントからのサーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成すると共にそのヘッダのTTL(生存時間)としてネットワークの片道の最大のホップ数の2倍以上の値を設定する要求パケット生成部を備え,要求パケットを受信する各サーバは,クライアントからの要求パケットを受信すると該クライアントへのサービスパケットを生成すると共にそのヘッダのTTLとして受信した要求パケットが保持するTTLの値を複写して設定するサービスパケット生成部を備え,クライアントは更に,各サーバからのサービスパケットを受信すると,受信サービスパケットのTTLの値から各サーバ別の往復ホップ数を検出してメモリに格納する往復ホップ数検出手段と,メモリに格納した各サーバ別の往復ホップ数から最小数のサーバを選択する手段を備えるよう構成したものである。
更に,本発明によるプログラムは,クライアントのコンピュータを,サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成する時にそのヘッダのTTL(生存時間)としてネットワークの所定の値の初期値を設定して送信する手段と,要求パケットを受信した各サーバからの受信した要求パケットが保持するTTLの値を複写したサービスパケットを受信する手段と,サーバから受信したサービスパケットのTTLの値と前記初期値とから往復ホップ数を検出する手段と,検出した各サーバに対応する往復ホップ数の値の中から最小の値であるサーバを識別して最短のサーバとして選択する手段と,して機能させるよう構成したものである。
本発明により,クライアントから同じサービスを提供する複数のサーバの中から要求パケットの往路の経路のホップ数と,要求パケットに応答するサービスパケットの経路のホップ数が最小である,すなわち最短である可能性が高いサーバを選択することができる。これにより,クライアントは同一サービスを提供する複数のサーバの中から最短距離のサーバからの情報を得ることができ,従って最も遅延が少ないサーバからの情報を取得することが可能となる。
そして,同じサービスを提供するサーバが標準の時刻情報をサービスする時刻サーバである場合,最短距離で時刻情報を得ることができるため精度の高い時刻情報によりクライアント(またはサーバ)のシステムを運用することができる。
また,クライアントがコンテンツデリバティネットワークのサーバからコンテンツを得る場合,近距離のサーバからのサービスを受けることで,ユーザへのサービス品質を向上することが可能となる。また,各クライアントがそれぞれ同一サービスを提供するサーバの中からネットワークの最短のルートを通るサーバを選択してパケットを送受信することにより,ネットワークの余分なルートを通らなくなるため他のユーザのパケットの通信への影響をなくすことが可能となる。
本発明による原理構成を示す図である。 クライアントとサーバ間のホップ数の説明図である。 クライアントとサーバのハードウェア構成を示す図である。 クライアント及びサーバにおけるフローチャートを示す図である。 受信パケットのTTL値の分布を示す図である。 TTL値の累積分布を示す図である。 解析に利用したホスト数の推定ホップ数分布を示す図である。 ホップ数と擬似遅延のジッタの関係を示す図である。
図1は本発明による原理構成を示す図であり,図中,1はクライアント,10は制御部,11は要求パケット生成部,12は送信部,13はインターネットのようなネットワークとのプロトコルに基づく通信を実行する通信インタフェース(通信IF),14は受信部,15は往復ホップ数検出部,16はメモリ,17は最寄りサーバ選択部である。2は同一サービスを提供する複数のサーバの中の一つのサーバ,20は制御部,21は受信部,22は受信した要求パケット中のTTLをサービスパケットのヘッダのTTLの値として設定するTTL複写手段,23は通信インタフェース(通信IF),24はサービスパケット生成部,25は送信部である。3はネットワークである。図1にはネットワーク3にクライアント1とサーバ2が1台だけ接続されているが,サーバ2と同一サービスを提供する他の複数のサーバや,他の多数のクライアントが図示省略されているが接続され,ネットワーク3には図示省略された多数のルータが配置されている。
ここで,TTLについて説明すると,TTLはIPv4(Internet Protocol version 4)のヘッダではデータグラムがインターネットのネットワーク上で生存可能な時間を意味する生存時間(TTL:Time to Live) を指定するフィールドとして使用され,当初は生存時間が0になるとそのパケットが廃棄されることになっていたが,現在ではルータを経由する度にTTLの値を1つ減らすように実装されるようになり,経由するルータの可能ホップ数として使用され,その後に提案されたIPv6 (Internet Protocol version 6)のヘッダではホップリミット(Hop Limit)フィールドとして使用され,ルータを通過するたびに1つずつ減らされ,その値が0になった時点でパケットを廃棄することが知られている。本願発明の以下の説明,「TTL」という用語は,IPv4のヘッダのTTLとIPv6のヘッダのホップリミットの両方を表すものとして使用する。
図1において,ネットワーク3には同一サービスを提供する複数サーバとクライアントが接続され相互にルータにより接続されており,その中の一つのクライアント1から同一サービスを提供する複数サーバに対してサービスを要求する場合,制御部10から要求パケット生成部11を駆動する。なお,複数のサーバ(サーバ2を含む)のそれぞれの宛先は予め登録されているものとし,要求パケットのヘッダにはTTLの初期値として通常のTTLより大きな値(通常の2倍以上)を設定する。要求パケットは送信部12から通信IF13を介してネットワーク3へ送信される。ネットワーク3を通る要求パケットのTTLの値は,1つのルータを経由する毎に1だけ減算される。サーバ2で要求パケットを受信すると,通信IF23を通って受信部21で受信される。制御部20で要求パケットについて識別し,要求された情報をサービスパケット生成部24に設定し,TTL複写手段22が受信部21内の要求パケットに含まれているTTLをそのままサービスパケットのヘッダのTTLとして複写し,要求パケットの送信元であるクライアント1を宛先とし,サービスパケットを送信部25から通信IF23を介して送信する。
このサービスパケットはネットワーク3を通る時,往路と同じ経路を通るとは限らないが,そのTTLの値は1つのルータを通る毎に1だけ減算されて,宛先のクライアント1に送られる。このサービスパケットがクライアント1の通信IF13を介して受信部14で受信されると,往復ホップ数検出部15で受信パケット内のTTLを検出する。このTTLの値はクライアント1から送信される時の初期値がサーバ2に到達するまでの往路のホップ数だけ減算され,更にサーバ2からのサービスパケットがクライアント1へ到達するまでの復路のホップ数の分だけ減算されるため,往復のホップ数を検出することができ,その往復ホップ数をメモリ16に格納する。
クライアント1から送信される要求パケット中のTTL値の初期値をTo ,サーバ2から受信したサービスパケットのTTL値をTr とし,往復ホップ数をHとすると,Hは次の式で得られる。
H=To −Tr
こうして,クライアント1において複数の各サーバから受信したサービスパケットから,それぞれの往復ホップ数が検出されてメモリ16に格納された状態で最寄りサーバ選択部17はメモリ16に格納された各サーバ別の往復ホップ数の中から最小の数値を持つサーバを選択する。選択したサーバを新たな要求パケットの宛先として要求パケット生成部11のヘッダに設定する。これにより,新たな要求パケットは最も少ないルータを経由してサーバとの間を往復し,最短な経路を通ることになる。
本発明による相手サーバにおいて受信したパケットのTTL値をそのままクライアントへ送るパケットのTTL値として複写してクライアントへ送る方法を言い換えると,TTLの折り返し方法と表現することができる。この方法では,往復のホップ数の合計がTTLの初期値を越えると,途中のルータでパケットが廃棄されてしまうので,初期TTL値は十分に大きな値とすることにより廃棄されることを防止でき,具体的には,パケットの送出時のTTLの初期値として,インターネットのようなネットワークの直径(最長パス)の2倍程度がRFC1122,IETF(1989)で推奨値されており,その値を用いることにより往復ホップ数が0になることを防止できる。
図2はクライアントとサーバ間のホップ数の説明図である。図中,C1,C2はクライアント,S1,S2は同じサービスを提供するサーバ,Rはネットワークに設けられた3a〜3pで表すルータである。クライアントC1からサーバS1,S2に対して要求パケットを送信した場合,サーバS1へのパケットはルータ3a,3b,3cを経由するルート1−1を通ってサーバS1に到達し,サーバS2へのパケットがルータ3a,3k,3m,3o,3p,3gを経由するルート1−2を通ってサーバS2に到達し,各サーバS1,S2からサービスパケットが送り返されてきた場合がある。なお,この図2では往復のルートが同じであるものとしているが,実際には同じであるとは限らない。このルート1−1では往復ホップ数は6であり,ルート1−2は往復ホップ数は12となり,最小の往復ホップ数が6であるサーバS1が選択される。クライアントC2からサーバS1,S2に対して要求パケットを送った場合にも,図2に示すルート2−1,2−2を通ってサーバS1,S2に送られ,そこから送り返されたサービスパケットをクライアントC2で受け取ることで,往復ホップ数を検出することで,ルート2−2が最小の往復ホップ数となって,クライアントC2はサーバS2を選択することになる。
図3はクライアントとサーバのハードウェア構成を示す。図中,4はクライアント(またはサーバ),40はプロセッサ,41はメモリでありデータやプログラムを保持し,42−1,42−2はインターネットのようなネットワークと接続してパケットの送受信を行う通信インタフェース,43は外部記憶装置である。
図4はクライアント及びサーバにおけるフローチャートであり,図3に示す構成を備えたクライアント及びサーバのプロセッサにおいて実行される。
クライアントでは,図4のA.に示すように要求パケットを発生する指示がアプリケーション等から発生すると,要求パケットが生成され(図4のS10),そのパケットのヘッダのTTLに初期値(To )を設定する(同S11)。上記の要求パケットは予め要求に対応するサービスを提供する複数(N個とする)のサーバのアドレスが当該クライアントに登録されているものとし,各サーバ(1〜N)に向けて要求パケットが生成されて,通信インタフェースを介してインターネットのようなネットワークに送信される(図4のS12)。この後,サーバからのサービスパケットを受信したか判別する処理が実行され(図4のS13),受信されるとサービパケットからTTLの抽出をする(同S14)。このTTLの値はTr (k) とする。但し,kはサーバの番号とし,kは1〜Nの何れかである。次にサーバ(k)との往復ホップ数(H(k) とする)を計算する(図4のS15)。すなわち,サーバkについてのホップ数は,H(k) =To −Tr (k) の計算により求められる。
このようにして各サーバについてのホップ数を求めてメモリに格納した後,その中から最小のホップ数H(k0)を求める,その計算はmin {H(k) |k =1,...N}の式により表す(図4のS16)。こうして,番号(k0)のサーバが最寄りサーバとして決定される(図4のS17)。クライアントでは決定した最寄りサーバを宛先として要求パケットの送信を行うことになる。
クライアントからの要求パケットを受け取る各サーバ(kとする)では,図4のB.に示す処理を実行する。サーバにおいて要求パケットを受信したか判別し(図4のS20),要求パケットを受信したことを判別すると,要求パケットからTTLを抽出する(同S21)。この場合のTTLの値をTs (k) とする。次に要求された情報を含むサービスパケットを生成し(図4のS22),そのヘッダのTTLに返送値(Ts (k) )を設定し(同S23),サービスパケットを要求パケットを送ってきたクライアントに送出する(同S24)。この後,ステップS20に戻って,他の要求パケットの受信を判別する処理を実行する。
ここで,情報サービスを提供するサーバの一つである上記NTPサーバで受信した要求パケットを解析した結果として受信パケットのTTL値の分布を図5に示す。また,TTL値の累積分布を図6に示す。図5,図6の横軸は受信時のパケットのTTL値を示し,ビン幅(bin:度数分布を作る際のデータの刻みを表す)は“1”であり,図5の縦軸は各受信時TTL値となるホストの割合を示し,対数スケールであり,図6の縦軸は累積ホストの割合を表し,対数スケールである。このNTPサーバには100万台以上のホストからの利用があり,パーソナルコンピュータ(PC)だけでなく,ルータやその他の組込機器からも利用されている。図5により,ホストのTTL値は4つの分布に分かれているが,それぞれの分布の幅は32程度である。分布の幅は,クライアントからサーバへの往路のホップ数の分布を示していると考えられるため,このNTPサーバのユーザエリアの直径は32ホップ程度と推定される。従って,初期TTL値がIANA(Internet Assigned Numbers Authority)の推奨値「64」以上であれば,往復でもパケットが廃棄されることは稀であるが,インターネットのネットワーク全体の直径は「32」以上よりも大きいと考えられ,初期TTL値は「128」または「256」とすることが望ましい。
次に最寄りサーバを利用することによる通信品質を改善することができる理由を説明する。NICT公開のNTPサーバとクライアントの間の片方向遅延のジッタ尺度として,品質を評価すると,遅延時間の計測としてNTPのリクエストパケット中の送信時刻フィールドとNTPサーバでの受信時刻を比較した結果,両者の差には遅延時間だけでなく,送信側の時計と受信側の時計の差を含んでいるため,この観測量を擬似遅延と呼ぶ。遅延ジッタ(遅延のゆれ)が大きいと,時計の同期精度も劣化するため,NTPリクエストを用いた擬似遅延計測は遅延ジッタの評価に適している。そのため,まず100万台を越えるNICT公開NTPサービス利用のホストの中から,十分な回数のポーリング(時刻問合わせ)を行っているホストを抜き出す。ポーリング頻度が高いほど時刻同期精度は向上し,データが少ないと統計処理で誤差が生じ安い。
NICT公開NTPサービスでは,一般の利用者に対して1日当たりのポーリング回数を一定数(480回)以内とするようにしているため,その回数以上のポーリング回数のホストの擬似遅延を統計処理すると,対象となるホストは2751台有り,NTPサーバ到着時のTTL値から,ホスト数の経由ホップ数分布を推定した結果が図7である。図7は解析に利用したホスト数の推定ホップ数分布を示す図である。到着時のTTLは上記図5に示したように0〜255の範囲に分布しているが,4つの分布に分かれているため,それぞれの分布に対して,初期TTL値がそれぞれ,32,64,128,255だったと仮定して,経由ホップ数を推定した。対象ホストが100台以上あるホップ数は11から19の範囲であり,それ以外では急速に減少する。
ホップ数と擬似遅延のジッタの関係を図8に示す。図8では,横軸はホップ数,縦軸は各ホストの1日の擬似遅延の標準偏差を対数目盛で示し,図中“All”は対象としているホスト全てのデータであり,“Min”はデータ数が豊富なホップ数11から19に対して最小値を示している。さらに,NTPサーバが接続しているL2スイッチに接続しているホストのデータをホップ数0として加えている。最小値データは,ホップ数に対して直線上に乗っていることが分かる。図8の“Min”データは各ホップ数における同期精度の限界を示しており,“Min”データについて回帰分析し,ホップ数hに対するジッタの最小値σmin (h) に関して次の実験式が得られる。但し,σ0 は同一セグメントでのジッタを表し,αは1段のホップ増加に伴う劣化度を表し,α=1.15,σ0 =11.5×10-6とする。
σmin (h) =αh σ0
ここで注目する点は,擬似遅延のジッタはホップ数に対して加算的(または比例関係)ではなく,べき乗の関係を有していることであり,ホップ数が大きくなると指数関数的に品質が劣化してしまうことが理解でき,本発明によりクライアントから同一サービスを提供する複数のサーバの中から往復ホップ数が少ないサーバを選択することにより,通信品質の向上を実現することができることは明かである。
1 クライアント
10 制御部
11 要求パケット生成部
12 送信部
13 通信インタフェース(通信IF)
14 受信部
15 往復ホップ数検出部
16 メモリ
17 最寄りサーバ選択部
2 サーバ
20 制御部
21 受信部
22 TTL複写手段
23 通信インタフェース(通信IF)
24 サービスパケット生成部
25 送信部
3 ネットワーク

Claims (3)

  1. ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するサーバ選択方法において,
    クライアントで前記サーバへのサービス要求が発生すると,各サーバを宛先とする要求パケットのヘッダのTTL(生存時間)の初期値として所定のホップ数を設定して要求パケットを送信し,
    前記要求パケットを受信する前記宛先の各サーバで前記要求パケットの送信元のクライアントへのサービスパケットの生成時にそのヘッダのTTLとして前記受信した要求パケットが保持するTTLの値を複写してサービスパケットを前記クライアントへ送信し,
    前記クライアントは前記各サーバから受信したサービスパケットのTTLの値から当該クライアントと前記サーバとの間の往復ホップ数を検出して保持し,保持した各サーバに対応する往復ホップ数の中から最小の往復ホップ数であるサーバを識別し,前記識別したサーバを宛先のサーバとして選択することを特徴とするサーバ選択方法。
  2. ネットワークに接続するクライアントと同一サービスを提供する複数サーバとで構成され,複数サーバの中から最短のサーバを選択するサーバ選択システムにおいて,
    前記クライアントは前記サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成すると共にそのヘッダのTTL(生存時間)としてネットワークの片道の最大のホップ数の2倍以上の値を設定する要求パケット生成部を備え,
    前記要求パケットを受信する各サーバは,前記クライアントからの要求パケットを受信すると該クライアントへのサービスパケットを生成する共にそのヘッダのTTLとして前記受信した要求パケットが保持するTTLの値を複写して設定するサービスパケット生成部を備え,
    前記クライアントは更に,前記各サーバからのサービスパケットを受信すると,受信サービスパケットのTTLの値から各サーバ別の往復ホップ数を検出してメモリに格納する往復ホップ数検出手段と,前記メモリに格納した各サーバ別の往復ホップ数から最小数のサーバを選択する手段を備える,
    ことを特徴とするサーバ選択システム。
  3. ネットワークに接続するクライアントにより同一サービスを提供する複数サーバの中から最短のサーバを選択するためのプログラムであって,
    前記クライアントのコンピュータを, 前記サーバへのサービス要求に応じて各サーバを宛先とする要求パケットを生成する時にそのヘッダのTTL(生存時間)としてネットワークの所定の値の初期値を設定して送信する手段と,
    前記要求パケットを受信した各サーバからの前記受信した要求パケットが保持するTTLの値を複写したサービスパケットを受信する手段と,
    前記サーバから受信したサービスパケットのTTLの値と前記初期値とから往復ホップ数を検出する手段と,
    前記検出した各サーバに対応する往復ホップ数の値の中から最小の値であるサーバを識別して最短のサーバとして選択する手段と,
    として機能させることを特徴とするプログラム。
JP2009119878A 2009-05-18 2009-05-18 ネットワークにおけるサーバ選択方法,選択システム及びプログラム Active JP5283271B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009119878A JP5283271B2 (ja) 2009-05-18 2009-05-18 ネットワークにおけるサーバ選択方法,選択システム及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009119878A JP5283271B2 (ja) 2009-05-18 2009-05-18 ネットワークにおけるサーバ選択方法,選択システム及びプログラム

Publications (2)

Publication Number Publication Date
JP2010268368A true JP2010268368A (ja) 2010-11-25
JP5283271B2 JP5283271B2 (ja) 2013-09-04

Family

ID=43364954

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009119878A Active JP5283271B2 (ja) 2009-05-18 2009-05-18 ネットワークにおけるサーバ選択方法,選択システム及びプログラム

Country Status (1)

Country Link
JP (1) JP5283271B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509007A (ja) * 2011-02-15 2014-04-10 プレヴィクス リミテッド マルウェアに対処するための方法及び装置
WO2018145537A1 (zh) * 2017-02-13 2018-08-16 北京奇虎科技有限公司 一种直播数据的处理方法和装置
US10547690B2 (en) 2015-05-26 2020-01-28 Ntt Communications Corporation Connection destination server instruction apparatus, service use system, client terminal, connection destination server instruction method, and program

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216163B1 (en) * 1997-04-14 2001-04-10 Lucent Technologies Inc. Method and apparatus providing for automatically restarting a client-server connection in a distributed network
JP2002071778A (ja) * 2000-08-25 2002-03-12 Matsushita Electric Works Ltd Gps受信システム
JP2005318606A (ja) * 2004-04-29 2005-11-10 Avaya Technology Corp メディア・ストリームのためのトレースルートおよびタイミング情報を提供するための方法および装置
JP2007324642A (ja) * 2006-05-30 2007-12-13 Matsushita Electric Ind Co Ltd 情報処理システム、情報処理装置、サーバ、及び情報処理方法
JP2008124576A (ja) * 2006-11-08 2008-05-29 Ntt Docomo Inc 基地局及び通信方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6216163B1 (en) * 1997-04-14 2001-04-10 Lucent Technologies Inc. Method and apparatus providing for automatically restarting a client-server connection in a distributed network
JP2002071778A (ja) * 2000-08-25 2002-03-12 Matsushita Electric Works Ltd Gps受信システム
JP2005318606A (ja) * 2004-04-29 2005-11-10 Avaya Technology Corp メディア・ストリームのためのトレースルートおよびタイミング情報を提供するための方法および装置
JP2007324642A (ja) * 2006-05-30 2007-12-13 Matsushita Electric Ind Co Ltd 情報処理システム、情報処理装置、サーバ、及び情報処理方法
JP2008124576A (ja) * 2006-11-08 2008-05-29 Ntt Docomo Inc 基地局及び通信方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014509007A (ja) * 2011-02-15 2014-04-10 プレヴィクス リミテッド マルウェアに対処するための方法及び装置
US10547690B2 (en) 2015-05-26 2020-01-28 Ntt Communications Corporation Connection destination server instruction apparatus, service use system, client terminal, connection destination server instruction method, and program
WO2018145537A1 (zh) * 2017-02-13 2018-08-16 北京奇虎科技有限公司 一种直播数据的处理方法和装置

Also Published As

Publication number Publication date
JP5283271B2 (ja) 2013-09-04

Similar Documents

Publication Publication Date Title
JP5889914B2 (ja) ロードバランサーコンポーネント間の状態の同期
US10200402B2 (en) Mitigating network attacks
US9794281B1 (en) Identifying sources of network attacks
US9742795B1 (en) Mitigating network attacks
Vu et al. Dmap: A shared hosting scheme for dynamic identifier to locator mappings in the global internet
Pathak et al. A measurement study of internet delay asymmetry
TWI398149B (zh) 網域名稱解析之方法、裝置、系統、指令及軟體
EP2466810B1 (en) Method and router for a service dependent routing
US7058706B1 (en) Method and apparatus for determining latency between multiple servers and a client
US7675861B2 (en) Active probe target management
US7711800B2 (en) Network connectivity determination
US20090135728A1 (en) User datagram protocol traceroute probe extension
WO2018121589A1 (zh) 数据链路的检测方法、装置及系统
US11283757B2 (en) Mapping internet routing with anycast and utilizing such maps for deploying and operating anycast points of presence (PoPs)
JP2004159146A (ja) 通信ネットワーク及びパケット転送装置
JP5283271B2 (ja) ネットワークにおけるサーバ選択方法,選択システム及びプログラム
JP5871908B2 (ja) ネットワーク内部のデータ通信を制御するための方法およびシステム
Agarwal et al. Content distribution architecture using network layer anycast
JP5662779B2 (ja) 通信システム及びノード装置
WO2003024007A1 (en) System and method for information object routing in computer networks
CN115118700A (zh) 一种通信方法及通信系统
Hendriks Improving anycast census at scale
Tomic et al. Implementation and efficiency analysis of composite DNS-metric for dynamic server selection
KR20150049821A (ko) 서버 및 이를 이용한 부하 분산 방법
Valera et al. Leveraging Hybrid Information Centric Networking for Broker-Free Publish/Subscribe in IoT

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120420

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130228

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130305

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130521

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130527

R150 Certificate of patent or registration of utility model

Ref document number: 5283271

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250