JP5514315B2 - コンテンツ配信ネットワーク上のチャンク形式ダウンロード - Google Patents

Description

本願の技術はコンテンツ配信ネットワークからのファイルのダウンロードに関し、より具体的には完全ファイルを集合的に構成する複数のバイト範囲をコンテンツ配信ネットワークから同時ダウンロードすることを対象とする。

関連出願との相互参照
本出願は「コンテンツ配信ネットワーク上のチャンク形式ダウンロード」という名称で２００９年８月２８日に出願された米国特許出願第１２／５５０，１９０号に優先権を主張する。この出願は参照によりその全体が本明細書に組み込まれる。

メディア、ソフトウェア、アプリケーション、並びに他のファイル及びコンテンツを配信するためにインターネットが頻繁に用いられる。企業及び他のコンテンツプロバイダはダウンロード用の様々なファイルを提供する。エンターテイメント産業における例では、顧客は音楽又は映画を購入して自身のコンピュータにダウンロードできる。ソフトウェア産業では、顧客及びユーザはソフトウェア及び／又はアップグレードを購入して自身のコンピュータにダウンロードできる。しかしながら、顧客及びユーザがこのようなファイルをダウンロードするために、ファイルはオンラインでホスト処理（host）されなければならない。プロバイダが自身の提供するコンテンツをホスト処理することが一般的である。しかしながら、数多くのユーザがダウンロードしたがる人気ファイルをプロバイダがホスト処理するならば、（要求されたデータのユーザへの実際の送信を実行する）プロバイダのウェブサーバは、数多くの要求及び送信のすべてのせいで低速になりうる。従って、アカマイのようなコンテンツ配信ネットワーク（ＣＤＮ：Content Delivery Network）を用いてプロバイダが自身のファイルを配信することがより一般的になってきている。

コンテンツプロバイダは、ファイルをＣＤＮサーバ（群）にアップロードすることによって、又は必要に応じてコンテンツプロバイダからファイルをフェッチするようにＣＤＮを設定することによって、ＣＤＮを介してファイルをダウンロードできるようにする。ＣＤＮは通常、様々な位置に複数のウェブサーバを有し、各ウェルサーバはプロバイダによってアップロードされたファイル（群）をキャッシュし、格納し、又は何らかの方法でこれにアクセスする。関与する特定のプロトコルが時間の経過につれて変化しうる間に、現在のプラクティスでは、コンテンツプロバイダからファイルをダウンロードするユーザの要求は以下のステップに従ってＣＤＮによって処理される。第１に、ユーザのコンピュータは、ファイルのホストのインターネットプロトコル（ＩＰ）アドレスをルックアップするために標準のドメインネームサービス（ＤＮＳ）クエリを生成する。ＣＤＮによって運営されるＤＮＳサーバはこのＤＮＳクエリを扱う。次いで、ＣＤＮは、コンテンツプロバイダのウェブサーバからファイルをダウンロードする代わりに、ユーザがＣＤＮのウェブサーバのうちのどの１つからファイルをダウンロードすべきかを判定する。第２に、ＣＤＮは選択されたホストのＩＰアドレスでＤＮＳクエリに応答する。第３に、ユーザのコンピュータのソフトウェアは次いで単一のＣＤＮウェブサーバから完全ファイルをダウンロードする。しかしながら、ＣＤＮ内の単一のウェブサーバから完全ファイルをダウンロードすることは不都合を有する。

ＣＤＮとは異なり、ピア・ツー・ピア（Ｐ２Ｐ）ファイル共有ネットワークでは、ユーザはチャンク形式で互いにファイルをダウンロードしようとする。Ｐ２Ｐネットワークでは、各ユーザは典型的に、要求されたファイルの相異なるチャンクをダウンロードする複数のソース（ピア）を見つけうる。従って、ダウンロードの残存時間（lifetime）の間にＰ２Ｐソースの１つが低速になったとしても、ユーザへの送信全体は大きな影響を受けない。しかしながら、ＣＤＮでは、ユーザは典型的に単一のウェブサーバから完全ファイルをダウンロードするので、このウェブサーバが（高負荷、ネットワーク混雑などのせいで）低速になったならば、ダウンロードは著しく影響を受ける（低速になるか、失われさえする）だろう。さらに、Ｐ２Ｐネットワークではダウンロードを促進するために他の利用可能なソース（ピア）が使用されるが、ＣＤＮでは他の適切なウェブサーバは典型的には使用されない。このように、Ｐ２Ｐネットワークでは負荷が分散され均等になるが、ＣＤＮはこれを実施しない。それにもかかわらず、Ｐ２Ｐネットワークも不都合を有する。企業及び他のコンテンツプロバイダは、Ｐ２Ｐネットワークに関する負の烙印のせいで自身のコンテンツを配信するのにＰ２Ｐネットワークを使用することをためらう。Ｐ２Ｐネットワークでは、コンテンツの配信に関する制御が少なく（例えば、任意のピアが別のピアとコンテンツを共有できる。）、これによりコンテンツの不正使用（海賊行為、違法コピーなど）につながりうる。さらに、それぞれの個別のＰ２Ｐネットワークへ接続するための追加の個別のクライアントソフトウェアをダウンロードしない限り、ユーザはＰ２Ｐネットワークを使用できない。それによって、Ｐ２Ｐネットワークの使用はユーザ側に透過的でなくなる。

全体的なダウンロード速度を改善できるようにＣＤＮがファイルの分割ダウンロードを提供できるようにするソリューションの必要性が存在する。

本明細書で開示される概念の追加の特徴及び利点は以下の記載で説明され、一部は当該記載から自明であり、記載される技術の実施により習得されうる。本概念の特徴及び利点は添付の特許請求の範囲で特に指摘される手段及び組み合わせによって実現され取得されてもよい。記載される技術のこれらの特徴及びその他の特徴は以下の記載及び添付の特許請求の範囲からより十分に明らかになるか、本明細書で説明されるような開示の概念の実施によって習得されうる。

本開示はコンテンツ配信ネットワーク（ＣＤＮ）からチャンク形式でファイルを配信するためのコンピュータで実施される方法及び装置を記載する。本明細書で開示されるのは、ファイルを構成するバイト範囲を同時にダウンロードすることによってＣＤＮからファイルをダウンロードするための既存のＣＤＮシステム又はクライアント装置上の既存のソフトウェアを変更する実施形態である。

一部の実施形態では、ＣＤＮの既存のドメインネームサービス（ＤＮＳ）を利用して、従来のＡレコードで指定されたサーバのＩＰアドレスを要求し、その後に戻されたＩＰアドレスへファイルを構成するバイト範囲を要求する。このような実施形態でクライアント装置は、所望のファイルのバイト範囲についてＩＰアドレスによって識別されたＣＤＮエンドサーバに反復要求を行うように構成され、クライアントコンピュータによって再構築されるファイルのチャンクとしてダウンロードを受信するようにさらに構成される。

一部の実施形態では、ＤＮＳは、要求されたダウンロードにサービスを提供するＣＤＮエンドサーバ候補に対応付けられたＩＰアドレスのリストを含む新しいタイプのＤＮＳエントリを受信して返すように構成されている。これらの実施形態では、クライアントはＤＮＳへマルチＩＰアドレスルックアップを要求でき、ＤＮＳは指定されたサーバに対応付けられたサーバのすべてのＩＰアドレスのリストを有する「チャンクレコード」を返せる。その後、クライアントは、チャンクレコード内の情報を使用して、チャンクレコードで識別されたサーバへバイト範囲を要求できる。ここでも、クライアントはファイルを含むバイト範囲を求める複数の要求を行うように構成され、クライアントコンピュータによって再構築されるファイルのチャンクとしてダウンロードを受信できる。

一部の実施形態では、ＤＮＳは従来のＡレコードを返せるが、Ａレコードに様々なコントロールが添付される。例えば、これらの実施形態では、ＤＮＳは短いタイム・ツー・リブ（ＴＴＬ）を有するＡレコード又はＡレコードの使用を制限するための他の命令を返してもよい。クライアントは指定されたサーバのＩＰアドレスを要求でき、ＤＮＳは、識別されたサーバに１回の要求を行うことが有用であるように十分に短いＴＴＬを有するこの情報を含むＡレコードを返せる。この方法を用いて、チャンク形式でファイルをダウンロードしようとするクライアントはＡレコードで識別されたエンドサーバへ最初のチャンクを要求するが、後続のチャンクについて、クライアントはファイルを構成する次のバイト範囲にサービスを提供するサーバのＩＰアドレスを再要求する必要があるだろう。このようにして、システムはＤＮＳサーバ内で共通のインテリジェントルーティング能力を反復的に利用でき、所与のファイルの複数のチャンク形式リクエストの負荷をＣＤＮエンドサーバ間で均等にできる。

一部の実施形態では、ＣＤＮウェブサーバは複数のサーバ間でダウンロード要求をルーティングするために用いられうる。これらの実施形態では、ＤＮＳサーバは他の記載された実施形態の何れかについて記載された特性を取りうる。クライアントはバイト範囲の所望のファイルを求める要求を行い続けるだろうが、ＣＤＮウェブサーバはダウンロード要求を受信でき、場合によっては要求に対してサービスを提供するか、又はＣＤＮ内の別のサーバに要求をリダイレクトする。このようにして、ＣＤＮウェブサーバはＤＮＳに類似するルーティングロジックが提供され、よって複数のサーバ間で一連の要求を負荷分散できる。

本明細書に記載される実施形態を通じて、ＤＮＳサーバは制御ロジックの程度を変えることができる。例えば、短時間ＴＴＬの実施形態とは別に、又はこの実施形態に追加して、ＤＮＳはまた、任意の所与のサーバについての要求の回数の制限、最適なサーバのランキング、収容されうるバイト範囲の制限、及び記載される実施形態の実施において有用となりうる他の制御ロジックのような情報を返しうる。

さらに、様々な実施形態で記載されるクライアントコンピュータは、どのサーバへバイト範囲を要求するか、同時要求、サイズ又は要求の大きさを選択するための最適化ロジック、及び様々な最適化パラメータを選択するための他のこのようなロジックを使用するよう構成されうる。クライアントコンピュータはまた、ファイルを構成するバイト範囲を要求する前にファイルサイズを要求するように構成されうる。

記載される実施形態を実行するために有用又は必要なクライアント装置、ＣＤＮネットワークのコンポーネントのような様々な装置も開示される。さらに、装置及びコンポーネントのシステムも開示される。同様に、記載される実施形態はすべて、格納されたコンピュータ読み取り可能命令を有し、本明細書に記載される方法を実行するために様々なプロセッサベース装置に命令するために有用なコンピュータプログラマブル製品に記録されうる。

上述の実施形態が実施される方法を最良に記載するために、そして本開示の他の利点及び特徴を規定するために、より特定の記載が以下に提供され、添付の図面で説明される。これらの図面が単に本発明の例示の実施形態を図示し、従って特許請求の範囲を限定するとみなされるべきでないという理解の下で、添付の図面の使用を通じる追加の特異性及び詳細によって例が記載され説明される。

例示のコンピューティング装置を説明する図である。 例示のシステムの実施形態を説明する図である。 所与のアドレスからのファイルダウンロードを求める要求を処理する方法の実施形態を説明する図である。 所与のアドレスからのファイルダウンロードを求める要求を処理する方法の実施形態を説明する図である。 所与のアドレスからのファイルダウンロードを求める要求を処理する方法の実施形態を説明する図である。 例示のシステムの実施形態を説明する図である。 エンドサーバリダイレクトの実施形態の方法の実施形態を説明する図である。 エンドサーバリダイレクトの実施形態の方法の実施形態を説明する図である。 サーバのインテリジェントルーティングの実施形態を説明する図である。

開示される方法及び装置の様々な実施形態が以下に詳細に検討される。特定の実施が検討されるが、これは例示の目的のためだけに行われることが理解されるべきである。当業者は本開示の精神及び範囲を逸脱することなく他のコンポーネント、構成及びステップが用いられてもよいことを理解するだろう。

図１を参照して、携帯型又は据え置き型でありうる汎用コンピューティング装置１００が示され、処理部（ＣＰＵ）１２０と、リードオンリメモリ（ＲＯＭ）１４０及びランダムアクセスメモリ（ＲＡＭ）１５０のようなシステムメモリを含む様々なシステムコンポーネントを処理部１２０に結合するシステムバス１１０とを含む。他のシステムメモリ１３０も同様に利用可能であってもよい。システムは２つ以上のＣＰＵ１２０を有するコンピューティング装置上で動作してもよいし、処理能力を一緒になって提供するようにネットワーク接続されたコンピューティング装置のグループ又はクラスタ上で動作してもよい。システムバス１１０は、メモリバス又はメモリコントローラ、周辺機器バス、及び様々なバスアーキテクチャの何れかを用いるローカルバスを含むいくつかのタイプのバス構造の何れであってもよい。ＲＯＭ１４０等に格納された基本入出力（ＢＩＯＳ）は例えば起動中にコンピューティング装置１００内の要素間で情報を転送するのを支援する基本ルーチンを提供してもよい。コンピューティング装置１００はさらに、ハードディスクドライブ１６０、磁気ディスクドライブ、光ディスクドライブ、テープドライブ等のようなストレージ装置を含む。ストレージ装置１６０はドライブインタフェースによってシステムバス１１０に接続される。ドライブ及びこれに関連するコンピュータ読み取り可能記憶媒体は、コンピューティング装置１００のためのコンピュータ読み取り可能命令、データ構造、プログラムモジュール及び他のデータの不揮発性ストレージを提供する。１つの側面では、特定の機能を実行するハードウェアモジュールは、当該機能を実行するためにＣＰＵ，バス、ディスプレイ等のような必須のハードウェアコンポーネントに接続された有体のコンピュータ読み取り可能記憶媒体に格納されたソフトウェアコンポーネントを含む。基本コンポーネントは当業者に既知であり、装置のタイプに依存して、例えば装置が小さなハンドヘルドコンピューティング装置であるか、デスクトップコンピュータであるか、大型コンピュータサーバであるかに依存して、適切な変形が予期される。

本明細書に記載される例示の環境はハードディスクを採用するが、磁気カセット、フラッシュメモリカード、ＤＶＤ、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）のような、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ読み取り可能記憶媒体が当該例示の動作環境で用いられてもよいことが当業者に理解されるはずである。

コンピューティング装置１００とのユーザ対話を可能にするように、入力装置１９０は、音声のためのマイク、ジェスチャ又はグラフィカル入力のためのタッチセンサスクリーン、キーボード、マウス、モーション入力、音声等のような任意の個数の入力機構を表す。入力は、音声検索クエリの開始を示すために提示者によって用いられてもよい。装置出力１７０はまた、当業者に既知の複数の出力機構のうちの１つ以上でありうる。例えば、ディスプレイ又はスピーカに接続されるかディスプレイ又はスピーカを含みうるビデオ出力／オーディオ出力装置が一般的である。さらに、ビデオ出力／オーディオ出力装置はまた、これらの専用機能の性能を向上するための専用プロセッサを含みうる。一部の例では、マルチモーダルシステムは、コンピューティング装置１００と通信するための複数のタイプの入力をユーザが提供できるようにする。通信インタフェース１８０は総括的にユーザ入力及びシステム出力を統治し管理する。任意の特定のハードウェア構成で動作する開示の方法及び装置に関して限定は存在せず、従って基本的な特徴はハードウェア又はソフトウェア構成が発展すると、改善されたものに容易に置換されうる。

説明を明確にするために、例示のシステムの実施形態は（「プロセッサ」というラベルが付された機能ブロックを含む）個別の機能ブロックを備えるように示される。これらブロックが表す機能は、ソフトウェアを実行可能なハードウェアを含むがこれに限定されない共有ハードウェア又は専用ハードウェアの何れかを使用することによって提供されてもよい。例えば、図１に表される１つ以上のプロセッサの機能は単一の共有プロセッサによって提供されてもよいし、複数のプロセッサによって提供されてもよい。（「プロセッサ」という用語の使用は、ソフトウェアを実行可能なハードウェアを排他的に言及すると解釈されるべきではない。）例示の実施形態は、マイクロプロセッサ及び／又はデジタル信号プロセッサ（ＤＳＰ）ハードウェア、上述の動作を実行するソフトウェアを格納するためのリードオンリメモリ（ＲＯＭ）、結果を格納するためのランダムアクセスメモリ（ＲＡＭ）を備えてもよい。超大規模集積回路（ＶＬＳＩ）ハードウェアの実施形態だけでなく、汎用ＤＳＰ回路と組み合わされるカスタムＶＬＳＩ回路も提供されてもよい。

様々な実施形態の論理動作は、（１）汎用コンピュータ内のプログラマブル回路上で動作する、コンピュータで実施されるステップ、動作又は手続のシーケンスとして、（２）特定用途プログラマブル回路上で動作する、コンピュータで実施されるステップ、動作又は手続のシーケンスとして、及び／又は（３）プログラマブル回路内の相互接続された機械モジュール又はプログラムエンジンとして実装されてもよい。

本システム及び本方法は特にコンテンツ配信ネットワーク（ＣＤＮ）を介してチャンク形式でユーザにファイルを配信するために有用である。ハイレベルでは、クライアントコンピュータは、範囲において、すなわちチャンク形式でファイルがダウンロードされることを要求するように構成されうる。例えば、１０メガバイトのファイルは３つの相異なるチャンクでダウンロードを提供するように、１バイト目〜３，０００，０００バイト目の範囲と、３，０００，００１バイト目〜６，０００，０００バイト目の範囲と、６，０００，００１バイト目〜１０，０００，０００バイト目の範囲とにおいてダウンロードされうる。ダウンロードの効率及び速度を最大化するために、ファイルは任意のバイト範囲の任意の個数のチャンクに分割されうる。

チャンク形式ダウンロード要求に対してサービスを提供するためのＣＤＮ２００が図２に説明される。図２では、ＣＤＮの少なくとも１つのエンドサーバ２１８、２２０、２２２がクライアント装置２３０、２３２へのダウンロードのために要求されたファイル２０４のチャンク２２４、２２６、２２８を提供できる。一部の実施形態では、本システム及び本方法はインターネット接続を介して実行されるが、本発明の原理は電子装置の相互通信を促進する多種多様なネットワークに適用可能である。

コンテンツプロバイダ２０２は、ダウンロードを求めるユーザ又はクライアントへホスト処理するＣＤＮ２００へファイル２０４を提供できる。コンテンツプロバイダ２０２はＣＤＮへダウンロードされるべきファイルを送信するためにＣＤＮ２００と通信する。この通信はインターネット上で行われてもよいし、インターネット上で行われなくてもよい。ＣＤＮの上位レベル／ルート／親サーバ２０６はＣＤＮを通じてファイル２０８、２１２、２１６を配信する。ＣＤＮ内に中間ネットワーク２１０及び／又は中間レベルサーバ２１４が存在してもよいし、しなくてもよい。ＣＤＮ内の複数のレベルのいずれのサーバ２０６、２１０、２１４、２１８、２２０、２２２のいずれもがコンピューティング装置で実装されうる。ネットワークを通じてファイル２０４を配信することによって、所与のファイルを求める要求に対してサービスを提供するためのサーバがより多く存在する。さらに、要求に対してサービスを提供するサーバが数多く存在するので、ダウンロードのためのファイルを要求する様々なクライアントの地理的に比較的近くにサーバが位置しうるように、これらのサーバは地理的に分散しうる。

エンドサーバ２１８、２２０、２２２は、ファイルを要求するクライアントへファイルを配信することによって、ダウンロード要求に対してサービスを提供する。図２に示される実施形態では、複数のエンドサーバ２１８、２２０、２２２がチャンク２２４、２２６、２２８でダウンロードファイル２０４を求める要求に対してサービスを提供する。エンドサーバ２１８はチャンク２２４をクライアント２３０へ送信し、サーバ２２０はチャンク２２６を送信し、サーバ２２２はチャンク２２８を送信する。ユーザ装置２３２はまた、複数のエンドサーバからチャンク形式でファイルを受信するように示される。

ＣＤＮ２００の一部であるドメインネームサービス（ＤＮＳ）２３８も図２に示される。ＤＮＳはクライアントによって提供されたＵＲＬに基づいてＩＰアドレスを求める要求を受信し、ダウンロード要求に対してサービスを提供するエンドサーバのＩＰアドレスを識別するＤＮＳアドレスレコード（Ａレコード）を返す。クライアントは返されたＩＰアドレスを使用して、エンドサーバと直接にコンタクトする。この分野で知られているように、ＤＮＳは、要求元への地理的近さ、帯域幅、ネットワークの混雑度、及び要求に対して最も効率的にサービスを提供できるエンドサーバを識別するために用いられうる他のパラメータのようなネットワーク効率性パラメータに基づいてどのエンドサーバが要求に対してサービスを提供すべきかを判定できる。言い換えると、ＤＮＳは、クライアントに対してダウンロード要求のサービスを最も効率的に提供できるエンドサーバのＩＰアドレスを返すことによって、ダウンロード要求をインテリジェントルーティングできる。

一部の実施形態では、ＤＮＳは、ネットワーク効率性パラメータ以外のパラメータに基づいてエンドサーバのＩＰアドレスを返す。例えば、一部の実施形態では、ＤＮＳは、同一のクライアントコンピュータへ最近返されたアドレスとは異なるエンドサーバのＩＰアドレスを返しうる。

一部の実施形態では、ＤＮＳはさらに、新たなタイプのＤＮＳレコードであるチャンクレコードを求める要求を受け入れるように変更され、このチャンクレコードは、ダウンロード要求に対してサービスを潜在的に提供できるいくつかのエンドサーバに対応するＩＰアドレスのリストを含む。

図３〜図５は、ダウンロード要求に対してサービスを提供するだろうエンドサーバのＩＰアドレスをクライアントに提供するためにＤＮＳに依存する記載されたシステムの実施形態を説明する。図３の例では、従来のＤＮＳは、供給されたＵＲＬに対応するＩＰアドレスを求める要求を受信し３０２、当該要求に対してサービスを提供できるＣＤＮエンドサーバに対応付けされているＩＰアドレスを有するＡレコードを返す３０４。上述のように、ＤＮＳは、ネットワーク効率性に関する情報とコンテンツ配信ネットワークに関する情報とに基づいて適切なエンドサーバを選択できる。返されたＩＰアドレスを使用して、クライアントは所望のファイルの一部を構成する第１バイト範囲を要求し、ＣＤＮエンドサーバは要求を受信してサービスを提供する３０６。同時に、又はほぼ同時に、クライアントは同じサーバからの第２バイト範囲を要求し３０８、すべてのバイト範囲が要求されるか完全ファイルがダウンロードされるまで、更なるバイト範囲を要求し続ける３１０。一部の実施形態では、クライアントはまた、任意の新たなバイト範囲について、３０２から始まる処理を繰り返しうる。

図４は、ダウンロード要求に対してサービスを提供できるいくつかのＣＤＮエンドサーバのＩＰアドレスを有する新たなタイプのレコード、以下ではチャンクレコードを返すようにＤＮＳが変更されうる実施形態を説明する。クライアントは所与のＵＲＬに対応するマルチアドレスルックアップを求める要求を送信し、ＤＮＳはこれを受信する３１５。要求３１５に応答して、ＤＮＳは要求に対してサービスを提供可能なサーバのリストを有するチャンクレコードを返しうる３１６。このサーバのリストを用いて、クライアントはＣＤＮによって受信される複数の要求を行いうる３１７、３１８、３１９。要求のそれぞれは別々のバイト範囲であってもよいし、完全ファイルを含む重複するバイト範囲であってもよい。各要求は同一のＣＤＮエンドサーバへ送信されうるが、好適には要求はチャンクレコードに含まれるＩＰアドレスのリストに対応するサーバ間で分散されるだろう。

これらの実施形態では、チャンクレコードで表されるエンドサーバのどれへバイト範囲を要求するかを最終的に決定するのはクライアント装置である。クライアントは、チャンクレコードで識別されたサーバへ順番に要求を行いうるラウンドロビン型選択処理を用いてこの選択を行いうる。これに代えて、クライアントはバイト範囲を求める任意の所与の要求について、リストからランダムにＩＰアドレスを選択できる。しかしながら、一部の実施形態でクライアントは、チャンクレコード内で識別されるサーバを最適化ロジックに基づいてクライアントが選択できる何らかのインテリジェントシステムを有しうる。例えば、クライアントは様々なＩＰアドレスへの要求のダウロード速度を監視でき、最良の性能を有するサーバをより頻繁に再利用できる。クライアントはまた、すでに要求されたダウンロードを監視して、同じサーバへ複数の要求を行うことで何らかの利益を得られているかどうかを判定し、それに従って当該サーバに新たな要求を行いうる。他の最適化ロジックはまた、ダウンロードされるべきファイルのチャンクをどのＩＰアドレスへ要求するかを選択するために用いられうる。さらに、上述の特徴は例示の実施形態以外にも用いることができ、これらの特徴はこの実施形態に固有であると見なされるべきでないことが理解されるべきである。

一部の実施形態では、３１６で返されるチャンクレコードはまた、レコードに列挙されたサーバに関する追加の情報を含みうる。例えば、特別のＡレコードはまた、要求に対してサービスを提供するためにどのサーバが最も適するかを示すサーバのランキングを含みうる。チャンクレコードはまた、特定のサーバへどれくらいの大きさのバイト範囲が最適に要求されるべきかに関する情報を含みうる。ユーザ装置の位置を表す情報、ＣＤＮエンドサーバに関するネットワークの混雑度を表す情報、ＣＤＮエンドサーバによってサービスが提供されるべき要求の量を表す情報などのような他の情報も有用でありえ、チャンクレコードに含まれうる。

図５は非常に短いタイム・ツー・リブ（ＴＴＬ）を有する従来のＡレコードをＤＮＳサーバが返す実施形態を説明する。ＤＮＳはクライアントからＩＰアドレスを求める要求を受信し３２０、ＤＮＳは短いＴＴＬを有するＡレコードをクライアントへ返す３２３。ＴＴＬは、クライアントへ返される任意のレコードが、返されたＩＰアドレスに１度だけ接続されるために十分な長さだけ生き延びる（利用可能である）ように、十分に短くすべきである。従って、ＴＴＬは１分よりも短く、より好適には１秒よりも短くすべきである。一部の実施形態では、ＴＴＬは１００ミリ秒よりも短い。クライアントが短いＴＴＬを有するＡレコードを受信した場合に、クライアントは３２６で、Ａレコードで識別されたＩＰアドレスへファイルの第１範囲を要求する。ＣＤＮ内のエンドサーバはその後、当該要求に対してサービスを提供し始めることができる。しばらくして、場合によっては３２０、３２３、３２６が実行されている間に、クライアントはＤＮＳへファイルの第２チャンクを要求でき３２１、ＤＮＳはで要求を満たす最良のサーバを再計算し、短いＴＴＬを有する別のＡレコードで当該サーバのＩＰアドレスを返す３２４。次に、クライアントは、３２７で要求に対してサービスを提供するＡレコードで識別されたサーバへ第２チャンクを要求できる。本方法は、すべてのチャンクが要求されるかダウンロードされるまで続きうる。例えば、第１チャンク及び第２チャンクをダウンロードしている間に、本方法は反復して継続し、更なるバイト範囲を要求し３２２、短いＴＴＬを有するＡレコードを受信し３２５、Ａレコードで識別されたサーバへ次のチャンクを要求する３２８。

図６はシステムの実施形態を説明する。クライアント装置３３０はＤＮＳサーバ３３２へ、ダウンロードのためのファイルを提供する指定されたサーバに対応するＩＰアドレスを要求する。ＤＮＳサーバ３３２は、別の要求を処理するための能力、範囲方式要求を扱うための能力、ネットワークの混雑度、及び要求に対して最も効率的にサービスを提供できるエンドサーバ３４４へ要求をインテリジェントルーティングする際に有用な他の要因を監視するために、ＣＤＮ３４０の他のコンピュータと通信３４２している。ＤＮＳ３３２は１つ以上のエンドサーバのＩＰアドレスをクライアントへ通信３３６する。クライアントはＣＤＮ３４０へチャンク形式のファイルを要求３３９し、一連の２つ以上の通信３３８でファイルのチャンクを受信する。

図７はエンドサーバによるダウンロード要求のリダイレクトを可能にすることによって、チャンク形式のファイルのダウンロードを促進するためにＣＤＮのエンドサーバを利用する実施形態を実行する方法を説明する。これらの実施形態では、各ＣＤＮエンドサーバは、ユーザ装置の位置を表す情報、他のＣＤＮエンドサーバの負荷、利用可能性、ネットワークの混雑度などを表す情報にアクセス可能である。言い換えると、ＣＤＮエンドサーバはＤＮＳサーバと同様のインテリジェントルーティング能力を有するように構成される。

図７に説明されるように、ＤＮＳサーバは、指定されたサーバのＩＰアドレスを求める要求をクライアントから受信する４００。ＤＮＳサーバは場合によっては、ＣＤＮがチャンク形式ダウンロードのサービスを提供可能であることをクライアントに通知し４０２、ファイルダウンロード要求のサービスを提供するためのエンドサーバの第１ＩＰアドレスを返す４０４。第１エンドサーバがファイルをダウンロードする要求を受信した場合に４０６、当該エンドサーバは要求を処理して当該要求が範囲方式要求であるかを判定する４０８。要求が完全ファイルをダウンロードする要求であるならば、第１エンドサーバは、要求に対してサービスを提供する第２エンドサーバに要求をリダイレクトできる４１２。第２エンドサーバは、第１エンドサーバの（上述のＤＮＳの能力と同様の）インテリジェントルーティング能力に基づいて第１エンドサーバによって選択される。このインテリジェントルーティング能力は要求をよりよく扱える第２エンドサーバを識別できる。しかしながら、一部の実施形態では、第１エンドサーバはまた、自身が要求に対して最も適してサービスを提供することを判定し、その後自ら要求に対してサービスを提供できる。

４０８に戻り、要求が範囲方式要求であるならば、第１エンドサーバは追加の要求が行われることを予想でき、自身のインテリジェントルーティング能力を使用して、範囲方式要求の現在の部分にサービスを提供するサーバを選択し、当該サーバ４１４にクライアントをリダイレクトできる。その後、クライアントのリダイレクトを受けたエンドサーバは要求に対してサービスを提供できる４１６。同時に、第１エンドサーバはまた、要求されたファイルの第２バイト範囲すなわち次のバイト範囲を受信でき４１８、当該要求を、以前の範囲の何れかと同じサーバ又は異なるサーバにリダイレクトでき４２０、当該サーバによりサービスが提供される４２２。バイト範囲を求める要求を受信し、当該要求を新たなサーバにリダイレクトし、当該要求に対してサービスを提供する処理は、すべてのバイトにサービスが提供されるか、又はすべてのバイトがダウンロードされるまで続きうる４２４。

一部の実施形態では、要求を受信する第１エンドサーバは自ら当該要求に対してサービスを提供できる。これは、要求に対してサービスを提供するのに最も適しているのは第１エンドサーバであると第１エンドサーバが判定した場合に望ましい。一部の実施形態では、リダイレクトの無限ループを避けるために、一部のエンドサーバは常に要求に対してサービスを提供し、決してリダイレクトしないようにプログラムされる。さらに別の実施形態では、要求がリダイレクトされた回数が記録され、許容されるリダイレクトの回数に制限が課される。このような実施形態では、許容されたリダイレクトの回数の制限をすでに超過しているリダイレクトされた要求を受信した任意のサーバは当該要求に対してサービスを提供しなければならない。

リダイレクトする処理は当該分野で既知の任意の処理によって行われてもよく、例えば要求を渡すことによって行われてもよいし、バイトを求める要求を再度行うようにクライアントに命令することによって行われてもよい。

図８はエンドサーバリダイレクトの実施形態のシステム実施形態を説明する。この図はＣＤＮの２つのブランチが相異なる都市に配置されたＣＤＮの一部分を説明する。中間サーバ４３４、４３６はネットワークのその他の部分からファイルを受信し、それを同じ都市のエンドサーバへ配信する。説明されたように、サーバ４３４は、すべてが都市１に配置されたエンドサーバ４３８、４４０、４４２へファイルを配信できる。同様に、サーバ４３６は、すべてが都市２に配置されたエンドサーバ４４４、４４６、４４８へファイルを配信できる。

ダウンロードされるべきファイルを含むバイトの第１範囲の最初の要求として、クライアントコンピュータ４３０はＤＮＳ４３２へＩＰアドレスを要求し、ＤＮＳは要求を処理するためにＡレコードの形式で近くのエンドサーバのＩＰアドレスを返す。クライアント４３０とＤＮＳ４３２との間の通信が４５２として示される。

その後、クライアント４３０は、エンドサーバ４３８を位置決めするためにＤＮＳ４３２によってクライアント４３０へ与えられたＩＰアドレスを用いてエンドサーバ４３８の範囲方式要求を行う４５０。自ら要求に対してサービスを提供する代わりに、エンドサーバ４３８は、エンドサーバ４４０が当該要求に対してよりよくサービスを提供できることを判定し、クライアントコンピュータ４３０をエンドサーバ４４０へリダイレクトし４５４、その後エンドサーバ４４０が要求に対してサービスを提供する４５６。

クライアントコンピュータ４３０が任意の後続の要求を行う場合に、クライアントコンピュータは以前に受信したＡレコードをキャッシュできるので、再度ＤＮＳ４３２に問い合わせる必要はない。しかしながら、一部の実施形態では、クライアント４３０とＤＮＳ４３２との間で更なる通信が行われうる。例えば、Ａレコードが短いＴＴＬを有する場合や後続の要求が元の要求から長い時間を経て来た場合に、ＤＮＳとの更なる通信が望ましいだろう。

しかしながら、ＤＮＳとの通信が望まれない又は必要ないことを仮定すると、クライアント４３０は後続の範囲方式要求をＡレコードで識別されたエンドサーバ、この場合はエンドサーバ４３８へ送信する４５８。エンドサーバ４３８は要求に対してサービスを提供するための最良のエンドサーバを再び計算し、サーバ４４６が最良のサーバであることを判定する。サーバ４４６は異なる都市にあったとしても選択されうることに留意されたい。エンドサーバ４３８はサーバ４４６へ要求をリダイレクトし４６０、サーバ４４６は要求に対してサービスを提供する４６２。

図９はチャンク形式要求に対してサービスを提供する最良のエンドサーバを判定する方法を説明する。上述のように、この判定はＤＮＳサーバ及び／又はＣＤＮエンドサーバによって実行されうる。受信されたダウンロード要求をインテリジェントルーティングするために、ＤＮＳ又はエンドサーバは、エンドサーバがチャンク形式要求を扱うかどうか８０７、ユーザ装置の位置８００、ユーザ装置にトポロジ的に隣接する（すなわち近くにある）各エンドサーバの位置８０２、クライアントへのエンドサーバの地理的近さ８０３、ユーザ装置に近い各エンドサーバの負荷８０４、ユーザ装置の近くの各エンドサーバの利用可能性８０６、ネットワークの混雑度８０８などを含むがこれらに限定されない複数の入力を受信して処理する。これらの入力に基づいて、利用可能なエンドサーバ８１０のそれぞれについて、特定のファイルを求める個別の要求に対するエンドサーバがサービスを提供する能力を表す品質スコアが計算される。ユーザ装置に最も近いエンドサーバが要求に対してサービスを提供する最も望ましいサーバでないこともありうる。例えば、より近いサーバが高い負荷を有する場合や利用不可能であるならば、より地理的に近いエンドサーバは、ダウンロードを要求するクライアント装置から更に除かれたエンドサーバよりも、要求に対してサービスを提供することが望ましくないだろう。品質スコアに基づいてランク付けリストが生成されうる８１２。ＤＮＳサーバ又はエンドサーバは、サーバランキングモジュール８１４によって判定された比較的高い品質スコアを有する少なくとも１つのエンドサーバのＩＰアドレスをリターンサーバモジュール８１６を介してクライアントへ返す８２０。

一部の実施形態では、エンドサーバはまた、同じ技術を用いて要求に対してサービスを提供する最も望ましいサーバが自身であるか他のエンドサーバであるかを判定するように構成されうる。この場合に、エンドサーバは他のエンドサーバについての品質スコアを返すことができ、これらのスコアに基づいてエンドサーバは自ら要求に対してサービスを提供するか、より望ましいエンドサーバにクライアントをリダイレクトするかの何れかを行える。

本明細書に記載される実施形態に関して、適切にチャンク処理を扱うためにユーザ側も特別の機能を所有しうる。チャンク形式ダウンロードを扱うための機能をユーザ側が有さないならば、ユーザ側は単に非チャンク方式でファイルをダウンロードするだろう（例えば、ユーザ装置はＣＤＮ内の１つのエンドサーバから完全ファイルをダウンロードする。）。特別な機能はダウンロード管理ソフトウェアを介して実行されえ、ユーザはこのソフトウェアを取得する必要があるか、チャンク形式ダウンロードを扱うための組み込み能力を有するウェブブラウザを介する必要がある。１つの特別な機能はＣＤＮのＤＮＳサーバによって送信されるチャンクレコードを要求してこれを用いる能力を有しうることである。さらに、ユーザ側の主要な機能はダウンロードされたファイルのチャンクを処理し、これらを再構築して元のファイルを形成する能力である。

上記で説明され記載された方法は別個の実施形態として記載されてきたかもしれないが、各実施形態の要素は他の実施形態でも適用できることが理解されるべきであり、よって互いに排他的であるとみなされるべきではない。

本発明の範囲内の実施形態はまた、コンピュータ実行可能命令又はデータ構造を搬送又は格納するためのコンピュータ読み取り可能記憶媒体を含みうる。このようなコンピュータ読み取り可能記憶媒体は汎用コンピュータ又は特定用途コンピュータによってアクセス可能な任意の利用可能な記憶媒体でありうる。例として、このような有体のコンピュータ読み取り可能記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光学ディスクストレージ、磁気ディスクストレージ又は他の磁気ストレージ装置、若しくはコンピュータ実行可能命令又はデータ構造の形式で所望のプログラムコード手段を搬送又は格納するために用いられうる任意の他の記憶媒体を含みうるが、これらに限定されない。コンピュータ実行可能命令は例えば、汎用コンピュータ、特定用途コンピュータ又は特定用途処理装置に所定の機能又は機能のグループを実行させる命令及びデータを含む。コンピュータ実行可能命令はまた、スタンドアロン又はネットワーク環境内のコンピュータによって実行されるプログラムモジュールを含む。一般的に、プログラムモジュールは、特定のタスクを実行するか特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、及びデータ構造を含む。コンピュータ実行可能命令、関連するデータ構造、及びプログラムモジュールは、本明細書に開示される方法のステップを実行するためのプログラムコード手段の例を表す。このような実行可能命令又は関連するデータ構造の特定のシーケンスはこのようなステップで説明された機能を実装するための対応する動作の例を表す。

本発明の他の実施形態は、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースコンシューマ電子装置又はプログラマブルコンシューマ電子装置、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含む多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で実施されてもよい。実施形態はまた、通信ネットワークを通じて（有線リンク、無線リンク、又はこれらの組合せによって）接続されたローカル処理装置及びリモート処理装置によってタスクが実行される分散コンピューティング環境で実施されてもよい。分散コンピューティング環境において、プログラムモジュールはローカルメモリストレージ装置及びリモートメモリストレージ装置の両方に配置されてもよい。

記載されたシステムの様々な段階における通信は、ローカルエリアネットワーク、トークンリングネットワーク、インターネット、企業イントラネット、８０２．１１シリーズ無線信号、光ファイバネットワーク、無線又はマイクロ波伝送などを通じて実行されうる。基盤となる通信技術が代わったとしても、本明細書に記載された基本原理はなおも適用可能である。

上述の様々な実施形態は例示のためだけに提供され、本発明を限定するとみなされるべきではない。本明細書に説明され記載された例示の実施形態及び用途には従わないが、本開示の真の精神及び範囲から逸脱しない、本発明になされうる様々な変形及び変更を当業者は容易に認識するだろう。

Claims (16)

1. コンテンツ配信ネットワークからファイルをチャンク形式で配信する方法であって、
   ファイルをチャンク形式でクライアントがダウンロードできる複数のサーバの複数のＩＰアドレスを求める要求を含むドメインネームサービス（ＤＮＳ）要求を前記クライアントからＤＮＳで受信する工程と、
   前記要求に対してサービスを提供可能な２つ以上のサーバのＩＰアドレスを判定するように前記ＤＮＳ要求を処理する工程と、
   前記２つ以上のサーバのうちの第１サーバの第１ＩＰアドレスを前記クライアントへ返す工程と、
   前記２つ以上のサーバのうちの第２サーバの第２ＩＰアドレスを前記クライアントへ返す工程であって、前記第２ＩＰアドレスは前記第１ＩＰアドレスとは異なる、工程と、
   前記ファイルを求める範囲方式ダウンロード要求を前記第１サーバ及び前記第２サーバで受信する工程であって、前記範囲方式ダウンロード要求は前記ファイルの複数の部分を示す、工程と、
   前記範囲方式ダウンロード要求を受信したサーバにおいて、前記ファイルの各部分に対して前記２つ以上のサーバのうちのどれがサービスを提供すべきかを判定する工程と、
   前記範囲方式ダウンロード要求に対してサービスを提供する工程と、
   を有することを特徴とする方法。
2. 前記範囲方式要求を受信する前に、指定されたファイルのサイズを返すためのバイト要求を前記クライアントから受信し、前記クライアントへ前記ファイルのサイズを返す工程をさらに有することを特徴とする請求項１に記載の方法。
3. 前記要求は、前記ファイルの相異なる指定されたバイト範囲を求める一連のダウンロード要求を含むことを特徴とする請求項１又は２に記載の方法。
4. 一連のシーケンシャルな要求のそれぞれが再び処理される長さを有するタイム・ツー・リブ（ＴＴＬ）で前記ＤＮＳが前記サーバのＩＰアドレスを返すことを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. 前記ＤＮＳはダウンロード要求に対してサービスを提供するための複数のサーバを含むチャンクレコードを返すことを特徴とする請求項１乃至４の何れか１項に記載の方法。
6. 前記受信された範囲方式ダウンロード要求は前記チャンクレコードで返されたサーバのうちの２つ以上で受信されることを特徴とする請求項５に記載の方法。
7. 前記複数のＩＰアドレスは、前記ファイルをダウンロードする後続のダウンロード要求のために前記クライアントにキャッシュされることを特徴とする請求項１乃至６の何れか１項に記載の方法。
8. 前記ドメインネームサービスは、前記範囲方式ダウンロード要求を扱う前記コンテンツ配信ネットワークのサーバの能力を定期的に監視することを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 前記複数のサーバは、前記ダウンロード要求を負荷分散するように構成されたルーティングロジックを含むことを特徴とする請求項１乃至８の何れか１項に記載の方法。
10. 請求項１乃至９の何れか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラム。
11. ファイルのネットワークベース配信のためのシステムであって、
    コンテンツ配信ネットワーク（ＣＤＮ）内にファイルをセグメント形式でダウンロードするための要求を受信するように構成された少なくとも１つのＣＤＮサーバであって、前記少なくとも１つのＣＤＮサーバは完全ファイルを構成する複数のファイルセグメントを求める複数の要求を受信し、各ファイルセグメントに対してどのＣＤＮサーバがサービスを提供するかを判定し、少なくとも２つの範囲の少なくとも一部を前記判定されたＣＤＮサーバへ同時に送信することによって前記要求に対してサービスを提供するように構成される、ＣＮＤサーバと、
    クライアントからＩＰアドレス要求をまず受信し、前記要求の受信に応答して、ダウンロードの前記要求に対してサービスを提供する少なくとも２つの好適なＣＤＮサーバを判定し、前記少なくとも２つのＣＤＮサーバのそれぞれについての複数のＩＰアドレスを前記クライアントへ返すためのドメインネームサービス（ＤＮＳ）サーバであって、前記複数のＩＰアドレスのそれぞれは互いに異なる、ＤＮＳサーバと
    を備えることを特徴とするシステム。
12. 前記好適なＣＤＮサーバのうちの前記少なくとも１つのＣＤＮサーバは、前記ファイルをセグメント形式でダウンロードする要求を受信した場合に、受信したそれぞれの要求について、当該要求に対してサービスを提供するのは第２ＣＤＮサーバの方が望ましいかを判定するように構成された第１ＣＤＮサーバであり、前記第２ＣＤＮサーバの方が望ましいと前記第１ＣＤＮサーバが判定したならば、前記第１ＣＤＮサーバは当該要求に対してサービスを提供するための前記第２ＣＤＮサーバに当該要求をリダイレクトするように構成されることを特徴とする請求項１１に記載のシステム。
13. ファイルのバイト範囲をダウンロードする一連の要求を行うように構成されたプロセッサであって、前記一連の要求は完全ファイルを構成するバイト範囲全体を求める要求を集合的に含む、プロセッサと、
    ダウンロードの前記一連の要求を前記プロセッサから受信し、この要求に対してサービスを提供するためのコンテンツ配信ネットワーク（ＣＤＮ）へ当該一連の要求を送信するように構成されるとともに、少なくとも２つの相異なるバイト範囲の少なくとも一部を前記コンテンツ配信ネットワークから同時に受信するように構成された通信インタフェースと、
    を備え、
    前記少なくとも２つの相異なるバイト範囲のそれぞれは、前記ＣＤＮネットワークにおいて当該バイト範囲に対してサービスを提供すると判定された前記ＣＤＮネットワーク内のサーバから受信されることを特徴とする装置。
14. 前記プロセッサは、一連のバイト範囲でファイルをダウンロードするようにプログラムされたウェブブラウザを動作させるように更に構成されることを特徴とする請求項１３に記載の装置。
15. 前記プロセッサは、前記ＣＤＮからリダイレクト命令を受け入れ、前記リダイレクト命令に従って前記ＣＤＮネットワーク内の第２サーバから前記バイト範囲を受信するようにさらに構成されることを特徴とする請求項１３に記載の装置。
16. 前記プロセッサは、同時に行われるダウンロード要求の個数と、バイト範囲を要求すべきサーバとの少なくとも一方を決定する最適化ロジックを実行するように構成されることを特徴とする請求項１３に記載の装置。

Images