JP2006166056A - クライアント‐ｉｓｐリンクの帯域幅の評価 - Google Patents

Abstract

【課題】 クライアントの獲得可能な帯域幅の信頼できる評価が得られる方法ならびにシステムを具体化する。
【解決手段】 クライアントとサーバの間のネットワーク接続の帯域幅を評価するための方法、プログラム、およびサーバは、第１および第２のオブジェクトをサーバからクライアントへ連続して供給することをサーバに対して求める要求を含む。第１および第２のオブジェクトがクライアントへ送信される。クライアントは、第１および第２のオブジェクトの配信の間の時間的な間隔を決定する。この時間間隔は、第２のオブジェクトのサイズに関する情報とともに帯域幅を評価するために使用される。第１および第２のオブジェクトは、クライアントのＩＳＰとアーキテクチャ的に近接しているコンテンツ配信ネットワーク・サーバから送信されるようにして、帯域幅評価の信頼性を向上させることができる。
【選択図】 図２

Description

本発明は、データ処理ネットワークの分野に関し、より詳細には、クライアントがインターネット・サービス・プロバイダを通じてネットワークへ接続するデータ処理ネットワークに関する。

クライアントとそのインターネット・サービス・プロバイダ（ＩＳＰ）の間における技術的に可能な最大の帯域幅は、それが獲得可能なパフォーマンスに制限を課することから重要な測度である。ウェブ・サイトを提供し、維持する者は、少なくとも２つの理由からこの測度に関心を有する。第１に、クライアントが獲得可能な最大帯域幅の知識があれば、ウェブ・サイトは、貧弱なパフォーマンスのための信頼性を配分することができる。適切な帯域幅を有するＩＳＰ接続を使用していると見られるクライアントが長い遅延を経験している場合に、ウェブ・サイトは、その遅延の原因の処理を試みるべきであり、クライアントのインターネット・リンクが限られた帯域幅を有している場合には、そのユーザが経験している遅延が、ウェブ・サイトの矯正能力を超えていることもあり得る。第２に、ウェブ・サイトは、クライアントの帯域幅キャパシティに対するその動作を、ウェブ・サイトがそのキャパシティを知っていればカスタム化することができる。高帯域幅ユーザに対してより高いレベルの特徴を提供する一方、低帯域幅ユーザが限りのない遅延時間に耐えることを防止できる能力は、魅力的な特徴である。

インターネット等のオープン・ネットワークの関連においては、多くの変数がドキュメントの配信に必要となる時間的な量に影響を与えることから帯域幅の測定が困難である。特に介在するルータおよびプロキシの存在は、任意の特定のディスティネーションまでドキュメントが移動するために要する時間的な量の追跡を疑わしいものとする。あるドキュメントが各種のルータ・ポイントにおいて遅延され、別のドキュメントが遅延されないといったことがあり得る。この種の遅延が非決定論であることから、既知のソースからドキュメントが到達するまでに要する長さを決定することによって帯域幅を測定することは困難を伴う。

クライアントの獲得可能な帯域幅の信頼できる評価が得られる方法ならびにシステムを具体化することは望ましいことであると言える。さらに、具体化された解決策がクライアントの現存する環境内において機能できることも望ましいことであると言えよう。

上記の目的は、連続して第１および第２のオブジェクトをクライアントへ供給することをサーバに対して求める要求を含む、クライアントとサーバの間におけるネットワーク接続の帯域幅を評価するための方法、プログラム、およびサーバによって取り組まれている。第１および第２のオブジェクトがクライアントへ送信される。クライアントは、第１および第２のオブジェクトの配信の時間的な間隔を決定する。この時間的な間隔が、第２のオブジェクトのサイズに関する情報とともに使用されて、帯域幅が評価される。第１および第２のオブジェクトを求める要求は、好ましくは、その要求がプロキシ・キャッシュによって供給されることを防止するためにネットワーク上において一意的なＵＲＬを用いて第１および第２のオブジェクトを識別する。第１および第２のオブジェクトが、クライアントのＩＳＰとアーキテクチャ的に近いコンテンツ配信ネットワーク・サーバからクライアントへ送信されるようにして帯域幅の評価の信頼性を向上することができる。一実施態様においては、ネットワーク内における第２のオブジェクトのフラグメント化を防止するために、第２のオブジェクトが、ネットワークに関連付けされる最小送信単位より小さいか、それと等しいサイズを有する。クライアントが帯域幅評価プロセスを（パケットのペアを要求することによって）起動することを可能にするソフトウエアは、好ましくはクライアントのブラウザの中から実行可能なスニペットとしてサーバから（または、サード・パーティのサービス・プロバイダから）提供することができる。１つの具体化においては、このスニペットがイメージ・オブジェクトのペアを作成し、一意的な識別子を作成し、さらにその一意的な識別子を組み込んだＵＲＬを使用してイメージ・オブジェクトとサーバ上のデータ・オブジェクト（パケット）のペアを関連付けする。一意的な識別子は、ネットワーク全体にわたって一意的であり、かつ特定の要求に対して一意的である。サーバは、ＵＲＬの固有部分を無視するか、除去することができる。この具体化においては、第１および第２のオブジェクトを求めるすべての要求が、サーバ上またはＣＤＮサーバ上にあるオブジェクトの単一ペアによって満される。帯域幅評価プロセスがサービス・プロバイダに委任される実施態様においては、サービス・プロバイダがサーバの応答時間の監視も行い、特定のクライアントのための応答時間が、そのクライアントの帯域幅が保証する時間より長い場合に警告を発する。

このほかの本発明の目的ならびに利点については、添付図面を参照した以下の詳細な説明を読むことによって明らかなものとなるであろう。

本発明には、各種の修正および代替形式が可能であるが、その特定の実施態様を、例として図面に示し、以下において詳細に説明する。しかしながら、ここに示している図面および詳細な説明は、開示されている特定の実施態様へ本発明を限定することを意図してなく、むしろその逆に、付随する特許請求の範囲によって定義される本発明の精神ならびに範囲内に含まれるあらゆる修正、等価、および変形を保護することにその意図がある。

概して言えば、本発明は、クライアントおよびそのＩＳＰの間におけるリンクにわたって獲得可能な帯域幅を評価するための方法およびシステムを企図している。クライアントがウェブ・サーバへアクセスするとき、サーバまたはサード・パーティのプロバイダ（サーバによって割り当てられる）が、比較的単純な、クライアントのブラウザ内において実行可能なコードをクライアントへ送信する。このコードが実行されると、クライアントがサーバへパケットのペアを求める要求を生成する。サーバは、『連続して』、もしくはわずかに時間を隔ててそれらの要求されたパケットを提供するか、あるいは別のサイトに提供させる。クライアントは、完全な第１のパケットを受信すると、その時刻を記録する。またクライアントは、完全な第２のパケットを受信すると、再びその時刻を記録する。これら２つの記録済みの時刻における差および第２のパケットのサイズの知識から、クライアント側のコードは、観察に基づく帯域幅番号を計算することができる。このプロセスを３回ないしはそれを超える回数にわたって繰り返し、決定されたもっとも高い帯域幅を採用することによって、精度の向上が得られる。

図１を参照すると、本発明の一実施態様に従ったデータ処理ネットワーク１００の選択されたエレメントが図示されている。ここに図示されている実施態様において、ネットワーク１００は、クライアント・システム（クライアント）１０２を含み、それが、そのクライアントのＩＳＰ １１０を伴うリンク１０３を介してインターネット等のワイド・エリア・ネットワークへ接続されていることが示されている。本発明は、クライアント対ＩＳＰリンク１０３の最大獲得可能帯域幅の信頼性のある評価を得ることに注目している。クライアント１０２からの送信、およびそこへの送信が行われるすべてのパケットがリンク１０３を横断しなければならず、また大多数のクライアントに関する帯域幅のボトルネックがクライアント対ＩＳＰリンク１０３であることから、リンク１０３の最大獲得可能帯域幅は、クライアントがデータを送受できる能力を実質的に決定する。クライアントがデータを送受するための帯域幅は、具体化に応じて同一でないことがある（たとえばＡＤＳＬ）。多くのアプリケーションについて、ウェブ・サイトのプロバイダおよびその他にとってもっとも関心のあるパラメータは、クライアントが情報を受信するための最大獲得可能帯域幅であり、それこそが本発明が主な焦点とするパラメータである。ＩＳＰ １１０は、クライアント１０２へ配信されるトラフィックおよびそこから受信されるトラフィックのすべてが通過しなければならないゲートウェイである。通常、ＩＳＰ １１０は、月極もしくは年間加入料と引き替えにインターネットへのクライアント１０２のアクセスを許可する。概して言えば、所定期間当たりの料金は、リンクの品質もしくは速度によって変化する。高速インターネット・アクセスを希望もしくは要求する加入者は、ダイアルアップ・アクセスが適切な加入者より一般に多くを支払う。それに代えて、リンクがプロバイダによって無償で提供されることもあり（たとえば、カスタマの小売店における場合）、その場合にはローカル・サーバのプロバイダが何を提供できるかによって帯域幅が制限される。それに加えて、地理的およびそのほかの考慮事項によって、エンド‐ユーザがダイアルアップ接続のみを有することが余儀なくされることもある。

クライアント１０２は、デスクトップもしくはノートブック・コンピュータ等のデータ処理デバイスまたはシステム、ウェブ対応携帯電話もしくはＰＤＡ等のワイヤレス・デバイス、あるいはそのほかの『ネットワーク・アウェア』デバイスである。ワールド・ワイド・ウェブ上のコンテンツへのアクセスは、クライアントのハードウエア上において実行するブラウザを用いて達成される。一般に使用されるほとんどすべてのブラウザは、かなりの程度までいくつかの共通の属性を共有する。その種の属性の１つが、ＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）コードを実行するブラウザの能力である。ＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）は、Ｎｅｔｓｃａｐｅ Ｃｏｒｐｏｒａｔｉｏｎ（ネットスケープ・コーポレーション）によって開発されたオープン、プラットフォーム非依存、オブジェクト指向プログラミング言語である。図示された実施態様においては、クライアント１０２が、システムもしくはデバイスがＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）コードを実行することを可能にする完全に機能的なランタイム環境を含んでいる。

クライアント１０２は、組織のホーム・ページ等の情報の検索を希望するとき、そのブラウザを使用してそのホーム・ページのためのユニバーサル・リソース・ロケータ（ＵＲＬ）を入力する（たとえば、ｗｗｗ．ＯｒｇａｎｉｚａｔｉｏｎＮａｍｅ．ｃｏｍ）。クライアントのブラウザは、このＵＲＬによって表されるオブジェクトを、そのオブジェクトがストアされているサーバから（またはプロキシ・サーバから）検索する要求を生成する。図１に示されているように、サーバ１５０は、組織のウェブ・サイトまたはウェブの存在を表す。組織のホーム・ページは、たとえばサーバ１５０上にストアされているか、あるいはサーバ１５０がアクセス可能なストレージ上にストアされている。

サーバ１５０によって代表される組織は、そのウェブ・サイトへ誰が訪問しているかといったことはもとより、そのビジターの有するインターネット・ケイパビリティがどの程度のレベルであるかといったことにおそらくは関心を有する。この情報は、ビジターへ提供されるサービスのタイプの差別化に使用することができる。またこれは、サーバへ、そのウェブの具体化が不適切であるときにそれを通知することもできる。特に、サーバ１５０が、高帯域幅接続を有している特定のクライアントがページの閲覧等において無視できない遅延を経験していることに気付いた場合には、そのウェブ・サイトの設計ならびに具体化の修正が必要なこともある。

クライアントの実際の帯域幅の正確な測度を得るときの困難は、部分的にはインターネットのアーキテクチャに帰する。理論的に言えば、クライアントの帯域幅の決定は、サーバからクライアントへ、なんらかのデータが配信されようとしているときにタイマを起動し、パケットの配信が完了したときにそのタイマを停止することによって達成することができる。データの量が既知であれば、この送信時間を使用して観察に基づく帯域幅の測度を計算することができる。ローカル・エリア・ネットワークにおいては、サーバからクライアントへ連続して（つまり、時間的に隣接するシーケンスで）パケットのペアを送信させることによって、このアプローチを実現することができる。その場合は、クライアントが第１のパケットを受信したときにタイマが開始される。このタイマは、第２のパケットの受信時に停止され、この経過時間によって第２のパケットのサイズを除することによって帯域幅が評価される。しかしながらインターネットの関連においては、介在するハードウエア・デバイスおよびファイル・キャッシュの存在がこのタスクを著しく困難なものとする。

図１に示されているように、たとえば、クライアント１０２からサーバ１５０へ至る任意のパスは、複数のルータ１１２を横切る。サーバ１５０が、単純にパケットのペアをクライアントへ送信することによってそのクライアントの帯域幅の決定を試みた場合に、ルータ１１２のうちのいずれかにおいて、ルータがなんらかの別のパケットの処理を行っている間に第２のパケットが遅延される可能性がある。それに加えて、インターネット上の多くのデバイスは、ファイル・キャッシュを含んでいる。ファイル・キャッシュは、最近アクセスされたデータのストアに使用されるストレージ・ファシリティである。たとえば、クライアントが特定のオブジェクトを要求した場合に、そのオブジェクトのコピーが、クライアント１０２とサーバ１５０の間にある１ないしは複数のルータおよび／またはプロキシ・サーバ上のストレージ・デバイス内にキャッシュされることがよくある。図１には、コンテンツ配信ネットワーク（ＣＤＮ）サーバ１２０によってファイル・キャッシュの一例が表されている。ＣＤＮは、多数の異なるサーバ上に大きなキャッシュ・ファイルを維持することによって単一ウェブ・サーバへのアクセス時間を短縮するとともに、その過負荷を防止する。理想的には、これらのＣＤＮサーバ１２０が、各種のＩＳＰ １１０の近傍に配置される。この出願の関連においては、２つのデバイスの近接が、それら２つのデバイスの間におけるネットワークの『ホップ』の数を指す。ＣＤＮサーバ１２０が主要なＩＳＰ １１０の近傍にあり、かつＣＤＮサーバのキャッシュが非常に多くの頻繁にアクセスされるオブジェクトをキャッシュしていると仮定すると、ウェブ・オブジェクトを求める多くの要求が、要求者のＩＳＰの近傍にある、オブジェクトのキャッシュ済みコピーによって供給される可能性があることは明らかであろう。より詳細については後述するが、本発明の一実施態様は、ＣＤＮサーバ１２０の存在を有益にてこ入れし、観察に基づいて導出される帯域幅番号の信頼性を向上する。しかしながら、クライアント‐ＩＳＰリンクの帯域幅を測定するという点から見ると、概して特定のオブジェクトがどこから供給されているかについて確信が得られないことから問題が悪化する。パケットのペアの例においては、第１のパケットが遠くのサーバから供給され、第２のパケットが近くのサーバから供給されたとすると、結果として得られる帯域幅の決定は、不正確であり、信頼できないものとなりがちである。

本発明は、ブラウザ内からインターネット上においてパケットのペアのコンセプトを具体化することに内在する困難と取り組んでいる。具体化される解決策のいくつかは、コンピュータ可読メディア上にストアされるコンピュータ実行可能インストラクションのセットもしくはシーケンスの形式とすることができる。これらのインストラクションは、磁気ディスクもしくはテープ、フラッシュ・メモリ・デバイス等の電気的に消去可能なデバイスを含む読み出し専用メモリ（ＲＯＭ）デバイス、およびこれらの類似物等々の持続性ストレージ・メディア上にストアすることができる。インストラクションが実行される時点においては、ソフトウエアが、データ処理システムのシステム・メモリあるいはシステムのプロセッサの１つに関連付けされたキャッシュ・メモリ等の揮発性ストレージ・メディア内に常駐することができる。

図２は、インターネット環境内において特定のクライアントのリンクの帯域幅を決定する方法２００を示したフローチャートである。一実施態様においては、本発明を実行するために必要なコードもしくはソフトウエアのほとんどが、大抵の従来的なブラウザ内において実行可能なＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）コードである。図示の実施態様においては、方法２００が、図１のサーバ１５０等のサーバによるクライアント要求の検出を含む。クライアントから受信される代表的な要求は、周知のＨＴＴＰフォーマットされた、特定のＵＲＬのためのＧＥＴ要求である。その種の要求の受信時に、サーバは、要求元のクライアントの帯域幅の評価を希望するか否かを決定する（ブロック２０４）。サーバは、選択されたクライアントについてだけ選択された回数だけ帯域幅の評価を行う選択をしてもよい。サーバは、たとえば、そのサーバを頻繁に訪問する（つまり、そのサーバからＵＲＬを要求する）クライアントについてだけ帯域幅が評価される選択を行うことができる。またサーバは、活動度が低いとき（帯域幅の決定のために必要なパケットの供給に関連するプロセッシング・オーバーヘッドがほとんど影響を持たないとき）、あるいは活動度が高いとき（サーバの利用可能な帯域幅の割り付けが重要なとき）に限って帯域幅が評価される選択を行うこともできる。サーバが、要求の受信に続いて帯域幅の評価が行われないことを選択した場合には、サーバは、単に従来の方法に従ってその要求を処理することになる。

サーバが帯域幅の評価を開始する場合には、図示した方法２００の実施態様は、まず、実行された帯域幅評価の繰り返しの数を追跡またはカウントするための変数を初期化する（ブロック２０６）。本発明の好ましい実施態様においては、複数回の帯域幅評価が繰り返されて、最終的な結果の精度が改善される。繰り返しの回数は、サーバによって決定される傾向にあるとはいえ、繰り返しの回数の追跡は、クライアント側が責任を負うことがおそらくは適当であるが、変形の具体化においては、これらの責任を代替方法に従って配分することができる。繰り返し変数の初期化に続いて、サーバ（もしくは、図４に関連して説明を後述するように、サード・パーティのプロバイダ）は、要求元のクライアントへ、ＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）スニペットを送信する（ブロック２０８）。ＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）スニペットは、特定のタスクを遂行するために設計されたＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）ソース・コードの１つである。本発明においては、クライアントへ引き渡されるスニペット（クライアント側スニペット）が、概して、サーバへのパケットのペアの要求、およびそのほかの、たとえばタイマの起動、時間の計算、帯域幅の計算等を含む帯域幅評価アクティビティを行うべく設計されている。クライアント側スニペットの具体化については、図３に関連して詳細を後述する。

サーバからクライアントへスニペットが送信されると、クライアントのブラウザが、すなわちより詳細に述べればクライアントのブラウザのＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）ランタイム環境が、そのスニペットを実行する。一実施態様においては、サーバがスニペット内に、クライアント‐ＩＳＰ間の帯域幅の決定がなされるべきか否かを決定するケイパビリティを埋め込むことができる。クライアント‐ＩＳＰ間の帯域幅が決定されることになっていれば、このスニペットがクライアントに、第１および第２のパケットをサーバに求める要求を生成させる。ここで述べている実施態様においては、これらのパケットがともに、予め定義済みの一意的なＵＲＬ（すなわち、以前にそのＵＲＬが要求されたことがないとする確度が極めて高い）によって識別される。一意的なＵＲＬは、本発明の関連において、要求されたオブジェクトが中間のルータまたはプロキシ・サーバのキャッシュ内に見つからないことを保証する上で望ましい。一実施態様における一意的なＵＲＬは、一意的な文字列を所定のオブジェクト名に付加することにより生成することができる。サーバがクライアントからパケット要求を受信したとき、要求されたＵＲＬのフォーマットが、そのＵＲＬが帯域幅を評価する目的で要求されたことをサーバに通知する。

ネットワークにわたって一意的であるＵＲＬを送信することが望ましいが、それぞれの要求元クライアントのために一意的なパケットを有する必要はない。それぞれのクライアントのための一意的なオブジェクトは、大量のストレージを必要とすることになる。図２に示されている本発明は、要求を送信する目的のためにネットワークにわたって一意的なＵＲＬを使用するが、すべてのクライアントに対して共通のＵＲＬの後ろに置かれているそのＵＲＬ文字列の一意的な部分を取り去ることによって（ブロック２１０）サーバ側のストレージを節約している。このようにサーバにおいては、一意的なＵＲＬの厖大な（可能性としては無限の）セットが２片のコンテンツをマップしている。

第１の帯域幅評価パケットを求める要求を認識すると、サーバは、第２のパケットを求める要求の受信を待機する選択を行い、２つのパケットが連続して配信されることをサーバが保証できるようにする。本発明の関連においては、連続した送信が、パケット・ペアのパケットの送信間隔が、クライアントのブラウザによって検出可能な最小時間間隔より短いことを示す。この最小値は、現在のところ約１０ｍｓ台であり、これは、ほとんどのサーバ・アプリケーションにおいてパケットが連続して送信されることが保証されるに充分な時間である。

第２のパケットを求める要求を受信した後、第１および第２のパケットが要求元クライアントへ連続して供給される（ブロック２１２）。これらのパケットは、サーバ１５０自体によって供給されるようにしてもよい。別の実施態様においては、サーバが、要求されたパケットの供給をコンテンツ配信ネットワークに代理させるが、供給デバイスとクライアントの間におけるホップの数を低減するためにはこれが望ましい。図１において述べたように、ＣＤＮは、図１のＩＳＰ １１０等のＩＳＰの（ネットワーク・ホップという意味において）近くに意図的に配置されるファイル・キャッシュ・サーバのネットワーク（サーバ１２０等）である。

本発明の関連においてＣＤＮを使用することは、パケットが要求元クライアントへ送信されるときに横切るネットワーク・ホップの数を低減することによって評価される帯域幅の信頼性を有利に改善する。これは、特定のＩＳＰと特定のサーバの間の地理的な距離が大きい場合（たとえば外国のウェブ・サーバとの間の場合）に特に当てはまる。多くの大規模ウェブ・サーバは、すでに、要求されたデータへのアクセス時間を短縮する手段として、またおそらくはより重要なことであるが、短時間に大量の要求が発生したときに生じることのある過負荷状態を防止するためにＣＤＮを使用している。

一実施態様においては、供給される第２のパケットが、帯域幅の決定がゆがめられるおそれのある、ネットワークによる複数のパケットへの分割を防止できるサイズで組み立てられる。第２のパケットのサイズは、たとえば一実施態様において、厳密に、最小送信単位（ＭＴＵ）から各種のヘッダのサイズを減じたサイズに拘束されている。たとえば、ＩＰヘッダおよびＴＣＰヘッダは、併せて４０バイトを必要とする。サーバは、第２のパケット用のコンテンツ・サイズを、コンテンツのサイズ＋ＨＴＴＰヘッダのサイズ＋ＴＣＰヘッダのサイズ＋ＩＰヘッダのサイズが１ＭＴＵを超えることのないように選択する。その名前から暗示されるように、ＭＴＵは、単一パケットとして送信されることが保証されているデータの最大量である。ＭＴＵより大きいパケットは、中間ルータによってフラグメント化される可能性を有する。言い換えると、ＭＴＵは、インターネットのルータによるフラグメント化を伴わない送信が保証される最小パケットである。インターネット上のＭＴＵは、５７６バイトである。すべてのネットワーク・ハードウエアは、ＭＴＵコンセプトを遵守しなければならず、これは、ネットワーク上のいずれのデバイスにもＭＴＵを複数のより小さいパケットに分割することが許されていないことを意味する。好ましい実施態様においては、第１および第２のＨＴＴＰオブジェクト（すなわち、第１および第２のパケット）が、中間キャッシュに対してそれらのオブジェクトのキャッシュを行わないディレクティブとともに送信される。しかしながら、いくつかの中間キャッシュがこれらのディレクティブに従わずに、オブジェクトをキャッシュすることがある。以下に図３を参照して説明するが、そのように従わないことがあっても、それが本発明の帯域幅評価プロセスに影響することはない。

ブロック２１２におけるパケットの引き渡しに続いて、サーバは、クライアント側スニペットが第２のパケットの受信に要した経過時間を基礎として帯域幅を計算する間を待機する。計算された帯域幅は、その後サーバへ引き渡されてストアされる（ブロック２１４）。

各繰り返しの後にクライアントによってインクリメントされる繰り返し変数Ｎが、予め決定済みのスレッショルド値と比較される（ブロック２１８）。Ｎ＝ＭＡＸとなるまで、このプロシージャの追加の繰り返しが行われる。繰り返しの回数には、信頼できる値を保証する一方、過剰な時間ならびにリソースを消費しないことが意図されている。逸話的な証拠は、ほとんどのアプリケーションにおいて４回のプロセスの繰り返しを行えば、良好な精度を伴うクライアントの最大獲得可能帯域幅を評価する上で充分であることを示唆している。どのような回数が指定されている場合でも、それぞれの繰り返しが対応する計算済みの帯域幅の値をもたらし、それが終了した後にサーバは、計算済みのスレッショルド数の最大値を値として選択する（ブロック２２０）。それに代えて、クライアントが評価済みの帯域幅の値のそれぞれをストアし、最大値を選択し、その単一の値をサーバへ送信することも可能である。クライアント上におけるパケット処理が適時的な態様で生じることを前提とすれば（すなわち、クライアント側が、第２のパケットの評価済み通過時間が不自然に低くなり、それによって不自然に高い帯域幅の評価がもたらされるほど長い時間期間にわたって第１のパケットの処理を遅延しないことを前提とすれば）、測定された帯域幅が実際の物理的な帯域幅を超えることが理論上不可能であるため最大値が使用されている。この仮定の下において、評価された帯域幅がリンクの物理的な限界を超えることは不可能であり、その結果、評価された帯域幅は、最大獲得可能帯域幅より小さいか、それと等しくなるはずである。

ここで図３を参照すると、先の図２の議論において言及したクライアント側スニペット３００の実施態様を例示したフローチャートが示されている。ここに図示されている実施態様においては、スニペット３００が一意的なＩＤを作成する（ブロック３０２）。この一意的なＩＤは、ほかのいずれのクライアントも同一の一意的なＩＤ（したがって、そのＩＤを一意的でなくする）を作成しないこと保証が高い確度なされる任意の方法において生成することができる。一実施態様においては、たとえば、時刻インジケータから導出した数字列および乱数を連結することによって一意性が達成される。すでに述べたように、この一意的なＩＤは、ＩＳＰに接続されている任意のプロキシ・サーバもしくはルータ上に存在するキャッシュが、パケット・ペア内のいずれのパケットも供給できないことを保証するメカニズムとして使用されている。

クライアント側スニペットは、一意的なＩＤを作成した後、第１および第２のオブジェクトを作成する（ブロック３０４）。好ましい実施態様においては、このとき作成されるオブジェクトがイメージ・オブジェクトになる。イメージ・オブジェクトは、概してグラフィカル・イメージのアクセスに使用されるが、本発明の関連においては、イメージ・オブジェクトのサポートする方法が帯域幅の決定に有用であることから選択されている。特に、すべてのＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）（登録商標）イメージ・オブジェクトは、イメージ・オブジェクトがロードされるときに起動されるＯｎＬｏａｄイベント・ハンドラをサポートしている。２つの異なるパケットが完全にロードされる時刻をマークすることによって動作する本発明においては、このイベント・ハンドラが極めて有用になる。またイメージ・オブジェクトは、ＯｎＥｒｒｏｒイベント・ハンドラもサポートしており、イメージのロードを試行する間にエラーに遭遇するとそれが通知を行う。ここで注意される必要があるが、ＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）イメージ・オブジェクトがブラウザ・スクリーン上に表示される必要はなく、したがって具体化によってはエンド‐ユーザにとって不可視にすることもできる。

作成された第１および第２のイメージ・オブジェクトのいずれにも、対応するイメージ・オブジェクト用の『理解容易な』名前（たとえば、ＩｍａｇｅＯｂｊｅｃｔＯｎｅおよびＩｍａｇｅＯｂｊｅｃｔＴｗｏ）を含む名前が与えられ、その名前に一意的なＩＤが追加される。パケット・ペア内の両方のパケット用に同一の一意的なＩＤを使用することによって、サーバは、２つの要求が同一クライアントから到来したとの決定を有利に行うことができる。この具体化においては、サーバが、同一ＩＤを伴う両方の要求が受信されるまで待機し、その後、パケットを連続して送信することができる。

イメージ・オブジェクトが、その後、作成済みオブジェクトのソース（ＳＲＣ）属性をセットすることによってサーバまたはＣＤＮへ向けて『ポイント』される（ブロック３０６）。ＳＲＣ属性が定義されると、これらのオブジェクトは、サーバ側から名称設定済みオブジェクトの検索を開始する。第１および第２のオブジェクトの検索の前に、クライアントのスニペットは、オブジェクトのｏｎｌｏａｄおよびｏｎｅｒｒｏｒイベントをアクティブにする（ブロック３０８）。パケットの受信に続いてイベント・ローダが最終的にトリガされると（ブロック３１０）、時刻が記録される（ブロック３１２）。記録された時刻は、帯域幅評価時間計測が開始する時点を表す。つまり、イメージ・オブジェクトとして第１のパケットを受信する方法によってクライアントは、クライアントのところで第２のパケットの受信が開始される時点を決定することが可能になる。

ブロック３１２において第１の時刻が記録された後、スニペットは、完全な第２のイメージ・オブジェクトの受信を監視する（ブロック３１４）。第２のイメージが完全にロードされた後（ブロック３１６）、スニペットは経過時間を計算し、第２のパケットのサイズの知識を用いて、計算による帯域幅の値を決定する（ブロック３１８）。一実施態様においては、第２のオブジェクトのサイズがスニペット内に埋め込まれている。その後、繰り返し変数Ｎがインクリメントされ（ブロック３１９）、計算済みの帯域幅の値がサーバへ返される（ブロック３２０）。一実施態様においては、これがサーバ上のＵＲＬに対してオブジェクトをポイントすることによって達成され、それが帯域幅の値をパラメータとして検索する。別の実施態様においては、クライアントが、単にサーバへ、決定に使用された一意的なＩＤとともに２つのパケットの間の時間遅延を通知する。サーバは、この時間遅延および第２のパケット（一意的なＩＤを用いてそれを追跡する）のサイズを用いて帯域幅を決定する。ＨＴＴＰエラー（ｏｎｅｒｒｏｒハンドラをトリガする）に起因していずれかのオブジェクトがロードされなかった場合にＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）スニペットは、試験を繰り返すか、あるいは中止することをクライアントに指示する。スニペットは、クライアントによって繰り返される回数を制限することができる。これらの全体の帯域幅評価は、セッションごとに１度、あるいは時間的な期間の経過ごとに１度（たとえば、４時間ごと）行うことができる。代表的な実施態様においては、関連するオーバーヘッドから、この決定をページごとには行わない。サーバによって提供されるコード・スニペットは、サーバ指定の条件に基づいてクライアントに試験を反復させる。またサーバは、その全体のクライアント‐ベースのランダムなセットだけが帯域幅評価を実行することを指示できる。ここで図４を参照すると、サーバへ帯域幅評価機能を提供する方法のフローチャートが示されている。図示された実施態様においては、参照番号１６０によって表されているサード・パーティのプロバイダが、サーバによって起動されたときに、適切なクライアントに対するスニペット・コードの配信を担当する。図示の実施態様においては、サーバ１５０が、プロバイダ１６０へ要求を送信することによってクライアント要求に対して応答する。プロバイダ１６０は、要求を受信し（ブロック４０２）、スニペットをクライアントへ送信する（ブロック４０４）。この場合にプロバイダ１６０（またはＣＤＮ １２０）は、パケットをクライアントへ供給し（ブロック４０６）、（適切な回数の繰り返しの後に）クライアントから決定済みの帯域幅を受信する（ブロック４０８）。その後プロバイダ１６０は、その帯域幅を要求元サーバへ引き渡す。サード・パーティのプロバイダを採用することによってサーバは、帯域幅決定の具体化にサーバ側スクリプトが必要としていたクライアント側スニペットを維持する必要性から開放され、それに代えて、決定された帯域幅を基礎とする決定に集中することができる。サード・パーティのサーバは、帯域幅情報をサーバ１６０のオペレータへ、継続ベースで配信するか、あるいは集計レポートの形式で配信することを選択できる。それに加えて、評価された帯域幅が１ないしは複数の別のサーバの統計と矛盾するとき、サーバに対して修正アクション通知を発行するようにプロバイダ１６０の具体化を行うこともできる。一例としてプロバイダ１６０は、クライアント側の帯域幅限界の追跡に加えて、サーバ側の応答時間も追跡することができる。

この開示の恩典を受ける当業者であれば、本発明が、クライアント‐ＩＳＰリンクに関する帯域幅の決定を観察に基づいて引き出すためのメカニズムを企図していることは明らかであろう。詳細な説明および図面の中に示し、説明してきた本発明の形式が現在のところ好ましい例として採用されているに過ぎないことが理解される。付随する特許請求の範囲は、開示された好ましい実施態様のすべての変形を包含するべく広く解釈されることが意図されている。

データ処理ネットワークのブロック図である。 本発明の一実施態様に従ってクライアントの獲得可能な帯域幅を決定する方法のフローチャートである。 本発明の一実施態様に従ってネットワーク接続のクライアント側において実行される処理を強調した図２の方法の詳細を例示したフローチャートである。 サーバによるクライアントの獲得可能な帯域幅の決定を可能にするためのサード・パーティのサービスを例示したフローチャートである。

符号の説明

１００ データ処理ネットワーク
１０２ クライアント
１０３ クライアント対ＩＳＰリンク
１１０ ＩＳＰ
１１２ ルータ
１２０ コンテンツ配信ネットワーク（ＣＤＮ）サーバ
１５０ サーバ
１６０ プロバイダ
２００ 方法
３００ クライアント側スニペット

Claims (20)

1. クライアントとサーバの間の接続の帯域幅を評価させるためのプログラムであって、前記プログラムが、コンピュータに、
   サーバに、第１および第２のオブジェクトを連続してクライアントへ送信することを要求する機能、
   前記クライアントの前記サーバへのアクセスに応答して、前記要求する機能を実現するスクリプトを前記クライアントへ配信する機能、
   前記クライアント上における前記スクリプトの実行を起動する機能、
   前記スクリプトからの要求に応答して、前記第１および第２のオブジェクトを前記クライアントへ送信する機能、
   および、
   前記第１および第２のオブジェクトの配信の間の時間間隔を決定するため、およびそれらから帯域幅を評価する機能を、
   実現させるプログラム。
2. 前記第１および第２のオブジェクトを要求する機能は、前記クライアントと前記サーバを接続するネットワーク上において一意的なＵＲＬを用いて前記第１および第２のオブジェクトを識別する機能を含む、請求項１に記載のプログラム。
3. 前記第１および第２のオブジェクトを前記クライアントへ送信する機能は、前記クライアントのＩＳＰとアーキテクチャ的に近接しているコンテンツ配信ネットワーク・サーバから前記第１および第２のオブジェクトを前記クライアントへ送信する機能を含む、請求項２に記載のプログラム。
4. 前記第２のオブジェクトは、前記ネットワークに関連付けされる最小送信単位より小さいかそれに等しいサイズを有し、その点で前記第２のオブジェクトのフラグメント化が防止される、請求項３に記載のプログラム。
5. 前記要求する機能は、
   第１および第２のイメージ・オブジェクトを作成する機能、
   一意的な識別子（ｕｎｉｑｕｅＩＤ）を生成する機能、
   および、
   前記第１および第２のイメージ・オブジェクトと前記サーバ上の第１および第２のオブジェクトを、前記ｕｎｉｑｕｅＩＤを含むＵＲＬを使用して関連付けする機能、
   を含む、請求項１に記載のプログラム。
6. さらに、前記第１および第２のＵＲＬ内の前記ｕｎｉｑｕｅＩＤを前記サーバが無視する機能を包含し、それにおいて任意のクライアントからの前記第１および第２のオブジェクトを求める要求が、前記サーバによって受信された前記ＵＲＬ内の前記ｕｎｉｑｕｅＩＤとは無関係に前記サーバ上のオブジェクトの単一ペアから供給される、請求項５に記載のプログラム。
7. 前記ｕｎｉｑｕｅＩＤを生成する機能は、時刻の値ならびに乱数を基礎として前記識別子を導出する機能を含む、請求項５に記載のプログラム。
8. さらに、前記第１のオブジェクトを求める要求に関連付けされた前記ｕｎｉｑｕｅＩＤと同一のｕｎｉｑｕｅＩＤを有する前記第２のオブジェクトを求める要求が受信された後に限り、前記第１のオブジェクトを求める要求に対して応答する機能を包含する、請求項５に記載のプログラム。
9. さらに、前記帯域幅の複数の評価を獲得するために前記要求する機能を複数回にわたって起動する機能、および獲得されたもっとも高い帯域幅を評価済み帯域幅として選択する機能を包含する、請求項１に記載のプログラム。
10. クライアントのネットワーク接続の獲得可能な帯域幅を評価するためのサービスであって、
    サーバが、サービス・プロバイダに、前記サーバと前記クライアントの間の接続の前記帯域幅の評価を要求することを可能にすること、
    前記クライアントへ、第１および第２のオブジェクトを時間的に連続した態様で前記クライアントへ供給することを前記サーバに要求するためのスニペットを提供することによって帯域幅の評価を求める前記要求に応答すること、
    前記スニペットを起動し、前記クライアントに、前記サーバへ前記第１および第２のオブジェクトを要求させ、それにおいて前記スニペットは、前記サービス・プロバイダへ、前記第１および第２のオブジェクトの配信の間に経過した時間的な量を示す情報を返すこと、
    前記経過した時間を部分的に基礎として前記獲得可能な帯域幅を評価すること、
    を包含するサービス。
11. さらに、前記サーバに関する応答時間データを維持し、選択したクライアントに関する前記サーバの応答時間および前記選択したクライアントに関連付けされる前記評価した帯域幅を基礎として前記サーバに警告を発することを包含する、請求項１０に記載のサービス。
12. 前記スニペットは、前記クライアントと前記サーバを接続するネットワーク上において一意的なＵＲＬを用いて前記第１および第２のオブジェクトを識別する、請求項１０に記載のサービス。
13. 前記サーバは、前記クライアントが接続されているＩＳＰサーバとアーキテクチャ的に近接しているコンテンツ配信ネットワーク・サーバから前記クライアントへ前記第１および第２のオブジェクトを送信することによって前記第１および第２のオブジェクトを求める前記要求に応答する、請求項１２に記載のサービス。
14. 前記第２のオブジェクトは、前記ネットワークに関連付けされる最小送信単位より小さいかそれに等しいサイズを有し、その点で前記第２のオブジェクトのフラグメント化が防止される、請求項１３に記載のサービス。
15. さらに、前記スニペットを複数回にわたって起動して前記帯域幅の複数の評価を獲得し、もっとも高い帯域幅の評価を選択することを包含する、請求項１４に記載のサービス。
16. 前記スニペットが、
    第１および第２のイメージ・オブジェクトを作成するためのコード手段、
    一意的な識別子（ｕｎｉｑｕｅＩＤ）を生成するためのコード手段、
    および、
    前記第１および第２のイメージ・オブジェクトと前記サーバ上の第１および第２のオブジェクトを、前記ｕｎｉｑｕｅＩＤを含むＵＲＬを使用して関連付けするためのコード手段、
    を含む、請求項１０に記載のサービス。
17. サーバとクライアントを前記クライアントのＩＳＰを介して接続するデータ処理ネットワークにおけるサーバであって、
    帯域幅評価スニペットであって、時間的に隣接するトランザクションにおいて第１および第２のオブジェクトを前記クライアントへ送信することを前記サーバに対して要求するべく構成されている帯域幅評価スニペットを前記クライアントへ提供し、
    前記スニペットによって生成された要求を、帯域幅評価を求める要求として識別し、かつ前記要求に対して、前記第１および第２のデータ・オブジェクトを提供することによって応答し、
    かつ、
    前記クライアントから、前記第１および第２のオブジェクトの配信の間に経過した時間を示す情報を受信するべく構成されているサーバ。
18. 前記帯域幅評価スニペットは、前記ネットワーク全体にわたり、かつ特定の要求に対して一意的である第１および第２のＵＲＬを使用して、前記サーバに対して第１および第２のオブジェクトを要求する、請求項１７に記載のサーバ。
19. 前記第１および第２のＵＲＬは、前記要求に関連付けされた時刻から導出された一意的な部分および乱数を含む、請求項１７に記載のサーバ。
20. 前記サーバは、前記クライアントのＩＳＰとアーキテクチャ的に近接しているコンテンツ配信ネットワーク・サーバへ前記第１および第２のオブジェクトを提供することによって前記第１および第２のデータ・オブジェクトを前記クライアントへ供給し、それにおいて前記クライアントは、前記ＣＤＮサーバから前記第１および第２のオブジェクトを受信する、請求項１７に記載のサーバ。

Images