特許 5797591 中継装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5797591

(24)【登録日】2015年8月28日

(45)【発行日】2015年10月21日

(54)【発明の名称】中継装置

(51)【国際特許分類】

   H04L 12/70 20130101AFI20151001BHJP

   H04L 12/66 20060101ALI20151001BHJP

   H04L 12/46 20060101ALI20151001BHJP

【ＦＩ】

   H04L12/70 B

   H04L12/66 A

   H04L12/46 E

【請求項の数】4

【全頁数】11

(21)【出願番号】特願2012-58585(P2012-58585)

(22)【出願日】2012年3月15日

(65)【公開番号】特開2013-192156(P2013-192156A)

(43)【公開日】2013年9月26日

【審査請求日】2014年8月11日

(73)【特許権者】

【識別番号】399041158

【氏名又は名称】西日本電信電話株式会社

(74)【代理人】

【識別番号】100074206

【弁理士】

【氏名又は名称】鎌田 文二

(74)【復代理人】

【識別番号】100130513

【弁理士】

【氏名又は名称】鎌田 直也

(74)【代理人】

【識別番号】100084858

【弁理士】

【氏名又は名称】東尾 正博

(74)【代理人】

【識別番号】100112575

【弁理士】

【氏名又は名称】田川 孝由

(72)【発明者】

【氏名】明石 健吾

(72)【発明者】

【氏名】川邉 隆伸

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特開２００９−２０６５６２（ＪＰ，Ａ）

【文献】 特開２００４−３５０１３３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／２８，１２／４４−１２／９５５

(57)【特許請求の範囲】

【請求項1】

ユーザ端末とウェブサーバとの間に設け、上記ユーザ端末が上記ウェブサーバへアクセスするにあたってＦＱＤＮの名前解決のために上記ユーザ端末がＤＮＳサーバとの間で行うＤＮＳ要求及び解決されたＩＰアドレスの通信をＩＰｖ４とＩＰｖ６の両方のバージョンについて中継するＤＮＳ−ｐｒｏｘｙ機能部を有する中継装置であって、
上記ＤＮＳ−ｐｒｏｘｙ機能部は、上記ＤＮＳサーバから受け取ったＩＰｖ４及びＩＰｖ６のＩＰアドレスのそれぞれを、上記ユーザ端末に返送する前に、上記中継装置内の応答性計測部に渡し、
上記応答性計測部は、ＩＰｖ４とＩＰｖ６とのそれぞれのバージョンのＩＰアドレスを用いて、途中にＩＰｖ４又はＩＰｖ６のいずれかのみに対応するネットワークが介在している上記ウェブサーバへ実際に接続して応答性を計測し、その応答性計測結果を上記ＤＮＳ−ｐｒｏｘｙ機能部へ渡し、
上記ＤＮＳ−ｐｒｏｘｙ機能部は、受け取った上記応答性計測結果が応答性を確認できたものであるバージョンのＩＰアドレスを上記ユーザ端末に返送する中継装置。

【請求項2】

上記応答性計測部は応答性を計測するにあたり、応答性計測パケットを、一定間隔を空けて、予め定めた回数送信して、応答が返ってくるかを試みる再計測手段を実行し、
応答が返ってこないバージョンのIPアドレスでの二度目の送信に対する応答が返ってくると想定される時間を経過したら、上記ＤＮＳ−ｐｒｏｘｙ機能部へ上記応答性計測結果の返答を行う、請求項１に記載の中継装置。

【請求項3】

上記応答性の計測が、ｐｉｎｇの送信、ＴＣＰのセッションの確立、又はその両方である請求項１又は２に記載の中継装置。

【請求項4】

ユーザ端末とウェブサーバとの間に設け、上記ユーザ端末が上記ウェブサーバへアクセスするにあたってＦＱＤＮの名前解決のために上記ユーザ端末がＤＮＳサーバとの間で行うＤＮＳ要求及び解決されたＩＰアドレスの通信をＩＰｖ４とＩＰｖ６の両方のバージョンについて中継する上記ＤＮＳ−ｐｒｏｘｙ機能部を有する中継装置が、上記ユーザ端末に優先的に接続させるバージョンを選択するにあたり、
上記ＤＮＳ−ｐｒｏｘｙ機能部は、上記ＤＮＳサーバから受け取ったＩＰｖ４及びＩＰｖ６のＩＰアドレスのそれぞれを、上記ユーザ端末に返送する前に、上記中継装置内の応答性計測部に渡し、
上記応答性計測部は、ＩＰｖ４とＩＰｖ６とのそれぞれのバージョンのＩＰアドレスを用いて、途中にＩＰｖ４又はＩＰｖ６のいずれかのみに対応するネットワークが介在している上記ウェブサーバへ応答性を計測し、その応答性計測結果を上記ＤＮＳ−ｐｒｏｘｙ機能部へ渡し、
上記ＤＮＳ−ｐｒｏｘｙ機能部は、上記応答性計測部を受けたバージョンのＩＰアドレスを上記ユーザ端末に返送することで、
上記ユーザ端末は上記応答性計測結果が応答を確認できたバージョンのＩＰで上記ウェブサーバとの間のセッションを構築可能となる最適経路の選択方法。
。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、ＩＰｖ４及びＩＰｖ６の混在環境で用いるＤＮＳ−ｐｒｏｘｙ装置に関する。

【背景技術】

【0002】

ＩＰｖ６の普及に伴い、従来のＩＰｖ４とＩＰｖ６との両方のＩＰアドレスを保有するサーバが増えてきている。しかし、未だにＩＰｖ４にしか対応していないネットワークも多く残っており、ＩＰｖ６のみでは応答性が保証できない環境が多い。

【0003】

この環境の概念図を図５に示し、この環境における従来の通信シーケンスを図６に示す。ユーザ端末１２は、インターネットブラウザなどでＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）を用いたアドレスへアクセスする際に、そのＦＱＤＮに対応するＩＰアドレスを取得しなければならない。このため最初にユーザ端末１２は、ＤＮＳ−ｐｒｏｘｙ機能を有する中継装置１１へＤＮＳ要求を送信する（Ｓ１１）。実際にはこのＤＮＳ要求は一つではなく、ＩＰｖ４とＩＰｖ６のどちらにも対応できるように、ＩＰｖ４とＩＰｖ６の両方についての問い合わせを行う。ＩＰｖ６とＩＰｖ４のどちらが優先されるかは環境によって異なるため、ＩＰｖ４とＩＰｖ６のいずれのＤＮＳ要求を先に送信するかは特に決まっていない。

【0004】

ＤＮＳ−ｐｒｏｘｙ機能を有する中継装置１１は、ユーザ端末１２からのＤＮＳ要求を中継してＤＮＳサーバへ送信する（Ｓ１２）。ＤＮＳ要求を受けたＤＮＳサーバ１３は、自身が有する情報によるか、又は他のＤＮＳキャッシュサーバへの問い合わせにより、要求されたＦＱＤＮに対応するＩＰアドレスを返答する（Ｓ１３）。これがＩＰｖ４とＩｐｖ６との両方について行われる。中継装置１１は、ＤＮＳサーバ１３から返ってきたＩＰアドレスを順にユーザ端末１２へ返送する（Ｓ１４）。

【0005】

なお、図では同一のＤＮＳサーバ１３へのアクセスとなっているが、ＩＰｖ４とＩＰｖ６とでは別々のサーバである場合もある。特に、別々のサーバである場合には、ＩＰｖ４とＩＰｖ６のどちらのＤＮＳ要求が先に返ってくるかは一定しないことが多くなる。

【0006】

ここで、ＩＰｖ６についての名前の解決が先にされたとする。するとユーザ端末１２はＩＰｖ６のＩＰアドレスでの接続を開始する（Ｓ２１）。このとき、中継装置１１は、特に調査することなくその接続要求を転送する（Ｓ２２）。しかし、ＩＰｖ４とＩＰｖ６との両方に対応したネットワーク１５ａが通過できても、ＩＰｖ４のみに対応したネットワーク１６は、ＩＰｖ６によるＩＰアドレスでの通信は通過できずにここで接続が失敗することになる（Ｓ２３）。接続に成功しない場合、ユーザ端末１２は接続要求を何度か繰り返して送信するが、この時間はユーザにとっては接続待機状態に見えることになる（Ｓ２４）。

【0007】

所定の回数失敗したところで、ＩＰｖ６での接続は不可能であると判断し、先に遅れて到着したＩＰｖ４のＩＰアドレスを用いての接続要求を改めて行うこととなる（Ｓ２５）。ＩＰｖ４による接続要求であれば、上記のＩＰｖ４のみのネットワーク１６を通過して、次のＩＰｖ４とＩＰｖ６との両方に対応したネットワーク１５ｂも通過して、ウェブサーバ１４との接続が成功する（Ｓ２６）。

【0008】

しかし、このうちＳ２４のステップでユーザは待たされるため、回線のレスポンスが低下しているように見えることになる。

【0009】

また、ＩＰｖ６とＩＰｖ４とが上記の概念図及びシーケンス図と逆のケースも起こりえる。すなわち、ＩＰｖ４のアドレスが枯渇した後にはＩＰｖ４ではアクセスできずＩＰｖ６のみでしかアクセスできないネットワーク領域が増加し始める。この場合には、ＩＰｖ４でのＤＮＳ要求が先に解決されてしまった場合には、ＩＰｖ４では到達できずに接続失敗となり、ＩＰｖ６で改めて接続しなければならなくなるケースが生じる。

【0010】

このようなＩＰｖ６／ＩＰｖ４のデュアルスタック問題に対して、いくつかの方法が検討されている。例えば、中継装置１１がＴＣＰリセッタを送出することで、強制的にＩＰｖ６通信を遮断して、速やかにＩＰｖ４へ移行させる方法や、特許文献１にあるように、中継装置１１がそもそもＩＰｖ６でのＤＮＳサーバ１３へのＤＮＳ要求を全て無効にするといった方法が挙げられる。

【先行技術文献】

【特許文献】

【0011】

【特許文献1】特開２００９−１３０５０１号公報

【発明の概要】

【発明が解決しようとする課題】

【0012】

しかしながら、ＴＣＰリセッタによるＩＰｖ４へのフォールバックは、待ち時間を多少短縮することはできるものの、無くなるわけではないため、根本的な解決にならなかった。また、ＴＣＰのプロトコルにしか対応していないため、ＵＤＰなどその他のプロトコルへの汎用性が無かった。

【0013】

さらに、特許文献１の方法では全てのＩＰｖ６ＤＮＳの名前が解決されなくなるため、ＩＰｖ６アドレスにしか対応していないサーバへは通信できなくなるという問題があった。

【0014】

さらにまた、従来の方法では、仮にＩＰｖ４とＩＰｖ６との一方で接続が成功したら、もしもう一方のバージョンのＩＰならより高速で通信できたとしても、そのままのバージョンのＩＰで通信し続けるため、ネットワークの利用効率が悪く、ユーザに体感できない不便を実質的に与えることがあった。

【0015】

そこでこの発明は、ＩＰｖ６とＩＰｖ４とのどちらが使えないネットワークを経由する場合にも対応でき、かつ、ＴＣＰ以外のプロトコルにも対応した形式でデュアルスタック問題を解消でき、さらに、ＩＰｖ４とＩＰｖ６とが両立する場合であっても応答品質のよいバージョンでの通信を行えるようにして、利用者の利便性を向上させることを目的とする。

【課題を解決するための手段】

【0016】

この発明は、ＤＮＳ−ｐｒｏｘｙ機能部２１を有する中継装置１１がＤＮＳ要求を中継してＤＮＳサーバ１３からＩＰアドレスを受け取った際に、それを速やかにユーザ端末１２へ返送するのではなく、
ＩＰｖ４及びＩＰｖ６のいずれについても中継装置１１が当該ＩＰアドレスのウェブサーバ１４へ実際に接続して応答性を計測し、その応答性計測結果が、応答性を確認できたものであるバージョンのＩＰアドレスを優先してユーザ端末１２に返送することによって、上記の課題を解決したのである。

【0017】

すなわち、中継装置１１は、ＤＮＳ−ｐｒｏｘｙ機能部２１とともに、ウェブサーバ１４に対して応答性を計測、確認するための応答性計測部２２を有する。ＤＮＳ−ｐｒｏｘｙ機能部２１は、ＩＰｖ４とＩＰｖ６とのいずれについても、ＤＮＳサーバ１３からＩＰアドレスを受け取ったら、それをユーザ端末１２に返送せずに、一旦そのＩＰアドレスを応答性計測部２２へ渡す。応答性計測部２２は、それぞれのバージョンのＩＰで当該ウェブサーバ１４と実際に通信してその応答性を計測する。計測にあたっては、単純にｐｉｎｇを送る方法や、ＴＣＰの３ｗａｙｓ−ｈａｎｄｈａｋｅを実際に行う方法が挙げられる。実際に接続し、応答できたことを応答性計測部２２が確認したら、その応答性計測結果をＤＮＳ−ｐｒｏｘｙ機能部２１へ渡し、応答性計測結果が接続を確認できたものであるバージョンのＩＰアドレスをユーザ端末１２に送る。これにより、ウェブサーバ１４との間に、ＩＰｖ４とＩＰｖ６のいずれかにしか対応しないネットワークがあっても、ユーザ端末１２は実際に応答性が計測できたバージョンのＩＰアドレスで接続できるので、ＩＰアドレスを受け取った後に、実際に繋がらないセッション構築の試行を行わずに済み、ユーザが実際に感じる待ち時間をほぼ無くすことができる。

【0018】

ウェブサーバ１４との間に、ＩＰｖ４又はＩＰｖ６のいずれかのみに対応するネットワークが介在している場合は、その対応しているバージョンのＩＰアドレスでの応答のみが返ってくるため、必然的にその返ってきたバージョンのＩＰアドレスを、より優れた通信品質でセッション構築できるバージョンとして、ユーザ端末１２に送る。

【0019】

また、所要時間の比較だけでなく、エラー率が低かった方のバージョンのＩＰアドレスを、応答品質が優れたものとして、優先的にＤＮＳーｐｒｏｘｙ機能部へ渡してもよい。

【発明の効果】

【0020】

この発明により、ＩＰｖ４及びＩＰｖ６が混在する環境において、確実に接続できる経路でセッションの構築を実施するため、通信できないバージョンのＩＰで無駄にセッションの構築を試みてユーザを待機させることがなくなる。また、どちらのバージョンで接続可能な場合でも、その後の接続要求へのレスポンスについて、当該ウェブサーバとの間でより高速で応答できるバージョンを選ぶことができるので、ユーザがネットワークアクセスする際の体感的なレスポンスを、セッションの開始から終了までを通じて向上させることができる。

【図面の簡単な説明】

【0021】

【図1】この発明の実施形態の例を示す機能ブロック及び構成図

【図2】この発明の実施形態の第一の例を示すシーケンス図

【図3】ｐｉｎｇとＴＣＰで応答性を計測する際のフロー図

【図4】この発明の実施形態の第二の例を示すシーケンス図

【図5】ＩＰｖ４にしか対応しないネットワークが介在する環境例の概念図

【図6】図５の環境におけるセッション確立時の例を示すシーケンス図

【発明を実施するための形態】

【0022】

以下、この発明について具体的な実施形態の例を挙げて詳細に説明する。
図１は、この発明にかかる中継装置１１の機能ブロックと、ユーザ端末１２、ＤＮＳサーバ１３、及びウェブサーバ１４の通信との概念図である。

【0023】

中継装置１１は、ユーザ端末１２と、ウェブサーバ１４との間にある中継装置であり、例えば家庭用ルータなどのホームゲートウェイのようなゲートウェイとして機能する装置である。具体的には、ユーザ端末１２からのＨＴＴＰ通信と、ウェブサーバ１４からのＨＴＴＰ通信を中継するとともに、ＤＮＳ−ｐｒｏｘｙとしての機能も備える装置である。

【0024】

ユーザ端末１２は、パソコン、スマートフォン、タブレット端末など、ＩＰによる通信を行う端末であれば特に限定されない。

【0025】

ＤＮＳサーバ１３は、ユーザ端末１２で普段入力されるＦＱＤＮ（ドメイン名）に対応するＩＰアドレスを調べて、ユーザ端末１２からの問い合わせに対して名前の解決を行い、ＩＰアドレスを返すことができるＤＮＳキャッシュサーバである。サーバ自身が記録しているＦＱＤＮとＩＰアドレスとの組み合わせから検索して応答するだけでなく、他のＤＮＳキャッシュサーバへリクエストを中継して、名前を解決する場合もある。

【0026】

ウェブサーバ１４は、ユーザ端末１２からのリクエストに応じてコンテンツを送信するサーバ機能を有するサーバである。図１中では一つであるが、実際には多数のサーバがインターネット上に存在しており、それぞれがＦＱＤＮ及びそれに対応した、ＩＰｖ４又はＩＰｖ６又はそれらの両方のＩＰアドレスを有する。

【0027】

これらの間で行われる通信に対して、中継装置１１は一般的な中継装置としての機能の他に、ＤＮＳ−ｐｒｏｘｙ機能部２１と、応答性計測部２２とを有する。ＤＮＳ−ｐｒｏｘｙ機能部２１は、ユーザ端末１２から送られてきたＦＱＤＮからＩＰアドレスを求める、すなわちＤＮＳ要求を中継し、ＤＮＳサーバ１３との間でその名前（ＦＱＤＮ）の解決を行うものである。また、応答性計測部２２は、後述するように、受け取ったＩＰアドレスが示すウェブサーバ１４との間で、接続が可能であるか否かをＩＰｖ４とＩＰｖ６との両方で送信して確認するものである。

【0028】

このうち、中継装置１１の各部（２１，２２）は、独立したチップでもよいし、ソフトウェア上で実現するものでもよい。この各部間でのデータの授受は、実際の通信でもよいし、メモリ空間上での受け渡しでもよい。中継装置１１は、これらを実現するための処理部たるプロセッサと、記憶部たる揮発性メモリや不揮発性メモリを有する。

【0029】

この中継装置１１が行う処理を、図２に示すシーケンス図を用いて説明する。
まず、ユーザ端末１２のブラウザなどから、ＦＱＤＮを含んだアドレスへのアクセスが指示されると、ユーザ端末１２は当該ＦＱＤＮで指定されるＩＰアドレスを得るために、ＩＰｖ４とＩＰｖ６の両方で、当該ＦＱＤＮを含んだＤＮＳ要求を送信する（Ｓ１１１）。上記ＤＮＳ要求を受け取った中継装置１１のＤＮＳ−ｐｒｏｘｙ機能部２１は、ＩＰｖ４とＩＰｖ６とのそれぞれについて、ＤＮＳサーバ１３へＤＮＳ要求を転送する要求転送手段を実行する（Ｓ１１２）。ＤＮＳサーバ１３は、ＤＮＳ要求に含まれるＦＱＤＮに対応するＩＰアドレスを、ＩＰｖ４、ＩＰｖ６のそれぞれについて返答する（Ｓ１１３）。

【0030】

ここで、ＩＰアドレスを受け取ったＤＮＳ−ｐｒｏｘｙ機能部２１は、ユーザ端末１２に速やかに返答するのではなく、そのＩＰアドレスの情報をバッファ（図示せず。）に保持したまま、応答性計測部２２へ受け渡す（Ｓ１１４）。応答性計測部２２は、受け取ったＩＰアドレスで指定されるウェブサーバ１４へ向けてパケットを送信し、通信が実際にどの程度の品質で返ってくるか否かを確かめる応答性計測手段を実行する（Ｓ１１５）。

【0031】

図２では、ウェブサーバ１４までの間に、ＩＰｖ４／ｖ６の両方に対応したネットワーク１５ａ，１５ｂがあり、それに挟まれてＩＰｖ４にのみ対応したネットワーク１６が介在している状況を例に取る。ＩＰｖ４のアドレスを指定して行われる応答性計測のパケットは、ネットワーク１５ａ，１６，１５ｂを通過でき、ウェブサーバ１４まで到達し、ウェブサーバ１４は応答を返す（Ｓ１１６）。

【0032】

一方、ＩＰｖ６のＩＰアドレスを指定して行われる応答性計測のパケットは、ネットワーク１５ａを通過することができても、ネットワーク１６を通過することができず、その先のネットワーク１５ｂにあるウェブサーバ１４まで到達することができない。このため、送信したパケットに対する応答が返ってこないので、応答性計測部２２はＩＰｖ６での応答性計測パケットを、一定間隔を空けて、予め定めた回数送信して、応答が返ってくるかを試みる再計測手段を実行する（Ｓ１２１）。この間に、ＩＰｖ４による上記の確認が進行することとなる。

【0033】

ウェブサーバ１４からの応答をＩＰｖ４で受け取った応答性計測部２２は、ＩＰｖ６と比べて速やかに返ってきたＩＰｖ４で応答性を計測確認できた旨の応答性計測結果をＤＮＳ−ｐｒｏｘｙ機能部２１へ送信する応答確認通知手段を実行する（Ｓ１１７）。ここで、応答性計測部２２は、応答性を計測確認できた旨の通知を受け取って速やかにＤＮＳ−ｐｒｏｘｙ機能部２１へ返送してもよいし、一定時間に亘ってＩＰｖ６での応答が返ってくるか否かを待ってもよい。ただし、待ちすぎるとユーザの体感レスポンスが低下するので、応答が返ってこないバージョンのＩＰアドレスでの二度目の送信に対する応答が返ってくると想定される時間を経過したら、ＤＮＳ−ｐｒｏｘｙ機能部２１へＩＰｖ４の応答性計測結果の返答を行うことが望ましい。

【0034】

上記応答性計測結果の返答を受信したＤＮＳ−ｐｒｏｘｙ機能部２１は、保持しておいたそのＩＰｖ４のＩＰアドレスをユーザ端末１２へ返す確認アドレス返答手段を実行する（Ｓ１１８）。この時点でユーザ端末１２は、ウェブサーバ１４と接続できる環境がもう整っているので、ＩＰｖ６についての応答を待たずに、ＩＰｖ４のＩＰアドレスを用いて、中継装置１１が通常有するパケット転送機能などの中継機能を利用してＴＣＰセッションの構築を行う（Ｓ１１９）。

【0035】

一方、ＩＰｖ６で所定の回数の応答性計測パケットを送信したものの応答が返ってこなかったことを確認した応答性計測部２２は、応答性の計測がＮＧであった旨の応答性計測結果をＤＮＳ−ｐｒｏｘｙ機能部２１への応答として返す計測失敗通知手段を実行する（Ｓ１２２）。この返答を受けたＤＮＳ−ｐｒｏｘｙ機能部２１は、ユーザ端末１２にエラーか、又はＤＮＳサーバ１３から受け取ったＩＰｖ６のＩＰアドレスを通知する要求応答手段を実行する（Ｓ１２３）。ただしこの時点では既にＩＰｖ４でセッションが確立しているため、このエラーやＩＰｖ６アドレスの通知は、ユーザ端末１２にとって何らかの変更を行わせるものではない。すなわち、先に応答性計測結果を受け取ったバージョンのＩＰで通信を確立させたまま、通信が続行される。

【0036】

上記の応答性計測部２２が送信する応答性計測のパケットとしては、ウェブサーバ１４からＩＰベースでの返答を受けることができるコマンドやプロトコルであれば特に限定されるものではなく、ｐｉｎｇを送信してもよいし、ＴＣＰセッションの構築を試みてもよい。ｐｉｎｇを用いる方がＴＣＰ以外のプロトコルにも対応するため汎用性が高い。一方で、サーバによってはセキュリティ対策としてＰｉｎｇに応答しないサーバもあるため、ＴＣＰを用いないと反応しない場合もある。このため、応答性の計測にあたって、ｐｉｎｇとＴＣＰセッション構築との両方を並行して行うと、より確実に応答性を確認することが出来る。

【0037】

応答性計測部２２が行う、ｐｉｎｇとＴＣＰとのそれぞれについてのフローをまとめて図３に示す。これらは選択的に行っても良いし、図のように並行して行ってもよい。

【0038】

まず、応答性計測にｐｉｎｇを使用する場合（Ｓ２１１）、ＤＮＳ−ｐｒｏｘｙ機能部２１から受信したＩＰアドレスへ向けて、Ｅｃｈｏ−Ｒｅｑｕｅｓｔを送信する（Ｓ２１２）。当該ＩＰアドレスのウェブサーバ１４からＥｃｈｏ−Ｒｅｐｌｙが返ってきたら（Ｓ２１３）、ＤＮＳ−ｐｒｏｘｙ機能部２１へ当該バージョンのＩＰアドレスでの応答性計測がＯＫである旨を送信する（Ｓ２１４）。所定の時間を経過してもＥｃｈｏ−Ｒｅｐｌｙが返ってこなければ（Ｓ２１３→Ｓ２１５）、所定の再送回数となるまでＥｃｈｏ−Ｒｅｑｕｅｓｔを送信する（Ｓ２１５→Ｓ２１２）。一般的には３，４回程度繰り返して応答が無ければ、ＤＮＳ−ｐｒｏｘｙ機能部２１に応答性計測がＮＧであった旨を送信する（Ｓ２１６）。

【0039】

一方、応答性計測にＴＣＰを使用する場合（Ｓ２２１）、ＤＮＳ−ｐｒｏｘｙ機能部２１から受信したＩＰアドレスへ向けて、ＴＣＰセッションを開始する「ＳＹＮ」フラグの立ったパケットを送信する（Ｓ２２２）。これをウェブサーバ１４が受信できた場合には、「ＳＹＮ／ＡＣＫ」のフラグが立ったパケットを返すので、そのパケットを受信できれば（Ｓ２２３）、応答性計測部２２は「ＦＩＮ」又は「ＲＳＴ」のフラグが立ったパケットを送信して、当該セッションを削除させる（Ｓ２２４）。あくまで応答性計測のためのセッションであり、実際のＨＴＴＰ要求などはユーザ端末１２から送られるので、ここでは一旦セッションを終了してサーバリソースを開放することが望ましいためである。その上で、ＤＮＳ−ｐｒｏｘｙ機能部２１へ当該バージョンのＩＰアドレスでの応答性計測がＯＫである旨を送信する（Ｓ２２５）。所定の時間を経過しても「ＳＹＮ／ＡＣＫ」が返ってこなければ（Ｓ２２３→Ｓ２２６）、所定の再送回数となるまで「ＳＹＮ」パケットを送信する（Ｓ２２６→Ｓ２２２）。一般的には３，４回程度繰り返して応答が無ければ、ＤＮＳ−ｐｒｏｘｙ機能部２１に応答性計測がＮＧであった旨を送信する（Ｓ２２７）。

【0040】

上記応答性計測部２２、及び中継装置１１は、この応答性計測結果についてキャッシュを残さない方が望ましい。ネットワークの通信品質は刻々と変化するため、先の応答性計測結果が後で再利用できるとは限らないからである。

【0041】

上記の図２のシーケンス図では、途中にＩＰｖ４のみのネットワーク１６が介在した場合について説明したが、逆にＩＰｖ６のみのネットワークが介在した場合でも、ＩＰｖ４とＩＰｖ６が逆になった形で、同様に応答性が計測されたＩＰｖ６についての接続が行われることとなる。

【0042】

次に、ＩＰｖ４とＩＰｖ６とのいずれでも到達できるウェブサーバ１４に対して接続を行う際に、応答品質がよりよかったバージョンのＩＰアドレスを優先的にユーザ端末１２に返送する場合について、図４に示す例を用いて説明する。中継装置１１とウェブサーバ１４との間のネットワーク１５ａとネットワーク１５ｂは、ＩＰｖ４とＩＰｖ６とのいずれでも通信可能であるが、ネットワーク１５ａはＩＰｖ４での通過に時間がかかるものとする。

【0043】

まず、ユーザ端末１２からＤＮＳサーバ１３へのＦＱＤＮの解決を求めるＤＮＳ要求を、ＤＮＳ−ｐｒｏｘｙ機能部２１が転送し、得られたＩＰｖ４とＩＰｖ６とのＩＰアドレスを応答性計測部２２に渡すまで（Ｓ２１１〜Ｓ２１４）は上記の図２の形態におけるＳ１１１〜Ｓ１１４と同じである。

【0044】

それぞれのバージョンのＩＰアドレスを受けた応答性計測部２２は、それぞれのＩＰアドレスを用いてウェブサーバ１４に対して応答性の計測を行う（Ｓ２１５）。この計測は上記のようにｐｉｎｇやＴＣＰのセッションでよい。このうち、ＩＰｖ４の方が先に応答性計測を始めているが、ＩＰｖ４はネットワーク１５ａにおける遅延が起こるため、ウェブサーバ１４に応答性計測が到達し（Ｓ２１６）、その反応が返ってくる（Ｓ２１７）際には、ＩＰｖ６との到達時間は逆転している。

【0045】

ここで応答性計測部２２は、先にレスポンスが到着したＩＰｖ６の方が応答品質に優れていると判断し、ＩＰｖ６でのＩＰアドレスを優先してＤＮＳ−ｐｒｏｘｙ機能部２１へ渡す（Ｓ２１８）。ＤＮＳ−ｐｒｏｘｙ機能部２１はこのＩＰｖ６のＩＰアドレスをユーザ端末１２に返送する（Ｓ２１９）。ユーザ端末１２はＩＰｖ６のＩＰアドレスを取得したので、ＩＰｖ６でウェブサーバ１４へセッションを構築する（Ｓ２２０）。

【0046】

一方、ネットワーク１５ａ、１５ｂでの応答品質に劣ると判断されたＩＰｖ４については、応答性計測結果として、よくなかった（ＮＧ）旨をＤＮＳ−ｐｒｏｘｙ機能部２１へ返送する（Ｓ２２１）。ＤＮＳ−ｐｒｏｘｙ機能部２１は、ＩＰｖ４についてユーザ端末１２から受けたＤＮＳ要求への返答として、エラー又はＩＰｖ４のＩＰアドレスを返送する（Ｓ２２２）。ただしＩＰｖ４のＩＰアドレスを返送する場合は、より応答品質に優れているとの判断がされたＩＰｖ６のＩＰアドレスよりも後に送信して、ユーザ端末１２が応答品質の劣るＩＰｖ４でのセッション構築を行わないようにする。

【0047】

当然にして、上記とは逆に、ＩＰｖ６の方が応答品質の悪いネットワークでは、応答性計測部２２はＩＰｖ４の方をより優れた選択肢として判断し、ＤＮＳ−ｐｒｏｘｙ機能部２１に対して、ユーザ端末１２に優先的にＩＰｖ４のＩＰアドレスを送信するように、ＩＰｖ４についての応答性計測結果を優先的に渡す。

【符号の説明】

【0048】

１１ 中継装置
１２ ユーザ端末
１３ ＤＮＳサーバ
１４ ウェブサーバ
１５ａ，１５ｂ ネットワーク（両方対応）
１６ ネットワーク（ＩＰｖ４のみ対応）
２１ ＤＮＳ−ｐｒｏｘｙ機能部
２２ 応答性計測部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】