JP6747721B2 - ネットワークアドレス解決 - Google Patents

Description

［関連出願］
本特許協力条約（ＰＣＴ）特許出願は、"ＮＥＴＷＯＲＫ ＡＤＤＲＥＳＳ ＲＥＳＯＬＵＴＩＯＮ"という発明の名称で２０１５年２月２７に出願された米国特許仮出願６２／１２６，２７７号に基づく優先権を主張し、その開示内容全体が、全ての目的のために、参照によって本明細書に完全に組み込まれる。

本開示の態様は、ネットワークアドレス解決に関し、具体的には、コンテンツ配信ネットワークによる配信に向けた改良されたホストネームを複数のリソースに割り当てること、および、ＤＮＳを通じてコンテンツの人気度をトラッキングし、コンテンツの人気度に基づいてＣＤＮノードに対する要求を解決するために、これらの改良されたホストネームを使用することを含む。

インターネットおよびワールドワイドウェブ（「ウェブ」）は、どこからでもアクセスできるものとなってきた。コンテンツプロバイダ（パブリッシャー）は、今や、世界中の多数のクライアントに対してあらゆる種類のコンテンツを提供すべく、インターネット（そして、具体的にはウェブ）を使用する。そうしたプロバイダのコンテンツのいくらか、または全てを供給するジョブを軽減すべく、今や、多くのコンテンツプロバイダがコンテンツ配信ネットワーク（ＣＤＮ）に加入する。ＣＤＮを使用すると、コンテンツプロバイダのサーバから供給する代わりに、ＣＤＮから（例えば、ＣＤＮ内の１または複数のサーバから）複数のクライアントへコンテンツが提供され得る。キャッシングＣＤＮにおいて、コンテンツはまた、提供される前、もしくは、そのコンテンツに対する特定の要求に応答してのいずれかで、複数のＣＤＮサーバのうちのいくつかまたは全てにキャッシュされてもよい。ＣＤＮのエッジサーバ内にコンテンツをキャッシュさせることは、ＣＤＮの性能を向上させる。何故ならば、そうしたコンテンツは、コンテンツを提供することにおいてエッジサーバよりも効率の低いミッドティアオリジンサーバまたはその他の位置から取り出される必要が無いからである。

多数の形態のコンテンツがＣＤＮから提供され得る。例えば、今や、テレビ番組および映画がいくつものウェブサイトからアクセスされ得る。それらの番組や映画は、実際に、ＣＤＮから提供され得る。紙媒体の新聞がウェブに移行しており、ポータルを提供する。ブラウザ、アプリ等によって何らかの形態のコンピューティングデバイス（例えば、ＰＣ、スマートフォン、またはタブレット）を操作しているクライアントは、それらのポータルを通じて、ショートビデオクリップ、記事、画像、およびオーディオトラックのような、多数の形態のコンテンツにアクセスし得る。ソフトウェアアップデートおよびパッチは、かつてはディスクで提供されるだけ、および受信者にメールされるだけであったが、今では、ネットワーク接続だけを使用してデバイスに定期的に配信されており、それらのアップデートおよびパッチはＣＤＮから配信されている。

本開示の様々な態様が着想および開発されたことは、特に、これらの所見を念頭に置いてのものである。

本開示の実施形態は、ドメインに対する権威ネームサーバにおいてユニフォームリソースロケータ解決要求を受信する処理を含むコンテンツ配信方法を含む。このユニフォームリソースロケータ解決要求は、ユニフォームリソースロケータ解決要求のホストネームに少なくとも部分的に基づいて受信される。ホストネームは、このユニフォームリソース解決要求に関連付けられたリソースに関連する。この方法は、リソースに関連するホストネームに基づいて、このリソースの人気度をトラッキングすること、および、このリソースを配信可能なネットワーク内のノードを提供することをさらに含んでよい。この提供されるノードは、リソースの人気度に基づいている。これらの処理は、処理ユニットを含むコンピューティングデバイス（または複数のコンピューティングデバイス）によって実行されてよく、非一時的コンピュータ可読媒体に格納されたコンピュータ可読命令として符号化されてよい。

本開示の実施形態は、コンピュータ実行可能な命令を含んだ非一時的コンピュータ可読媒体と通信する少なくとも１つの処理デバイスを含む装置をさらに含んでよい。コンピュータ実行可能な命令は、ドメインに対する権威ネームサーバにおいてユニフォームリソースロケータ解決要求を受信するためのものである。このユニフォームリソースロケータ解決要求は、このユニフォームリソースロケータ解決要求のホストネームに少なくとも部分的に基づいて受信される。ホストネームは、このユニフォームリソースロケータ解決要求に関連付けられたリソースに関連する。これらの命令は、さらに、このリソースに一意的に関連したホストネームに基づいて、このリソースの人気度をトラッキングするためのものであってよい。

これらの実施形態およびその他の実施形態が、以下において、より詳細に説明される。

本明細書に説明される本開示の上記のおよびその他の目的、特徴、並びに利点が、添付の図面に示されるような、これらの発明概念の特定の実施形態に関する以下の記載から明らかになるはずである。また、図面中において、同様の参照符号は、様々な図にわたって同じ部分を指す。これらの図面は、本開示の代表的な実施形態を図示するだけであり、従って、範囲の限定とみなされるべきではない。

あるリソースに対して割り当てられた固有ホストネームに基づいてリソースの人気度をトラッキングし、そのリソースの人気度に少なくとも部分的に基づいて、コンテンツ配信ネットワーク内のノードに対する要求を解決することのできるコンテンツ配信ネットワークおよびその他のネットワークを図示するネットワーク図である。

あるリソースに対して割り当てられた固有ホストネームに基づいた人気度トラッキングおよびコンテンツ配信の方法を示すフロー図である。

本明細書にて説明される様々なシステムおよび方法を実施し得るコンピューティングシステムの例である。

本開示の態様は、クライアントへコンテンツを提供するためのコンテンツ配信ネットワーク（ＣＤＮ）内に存在し得るエッジサーバ、ラック、クラスタ、またはその他のデバイスを選択するためのシステムおよび方法を含む。本開示の態様はまた、コンテンツに割り当てられた固有の改良されたホストネームを使用することに基づいてコンテンツ（リソース）の人気度をトラッキングすることも含む。一例において、人気度指定は、あるリソースに対して改良されたホストネームをグローバルに割り当てる形を取り得る。これは、そのリソース（または、固有の改良されたホストネームを伴う埋め込みリソースを含んだリソース）に対するオリジンサーバにおいて成されてよい。もしくは、オリジンサーバに関連して成されてよい。改良されたホストネームは、そのリソースに対して特有のものである。すなわち、そして一例においては、あるリソースに対する固有ホストネームが、オリジンサーバにて割り当てられてよく、または定義されてよい。本明細書にて説明されるように、オリジンサーバは、複数のサーバの集合であっても分散していてもよく、任意の定められたコンテンツプロバイダからのコンテンツに対するソースである。オリジンサーバは、ＣＤＮ内に維持されてよい。または、ＣＤＮ外に維持されてよい。

多くの従来のシステムにおいて、ＤＮＳ時間（ホストネームがＩＰアドレスに対して解決されているとき）における要求である実際のリソースは認識しない。むしろ、ホストネームだけが知られている。そのリソースに対して固有ホストネームを提供することにより、ＤＮＳ解決機能内の何らかのデバイスが、この固有ホストネームが何回解決されているのかを理解することによって、そのリソースの人気度をトラッキングすることができる。従って、人気度サービスが、人気度をトラッキングし、ＤＮＳ要求を解決するときの人気度を考慮するＤＮＳインフラストラクチャと連結される。

２つのリソース（リソース１およびリソース２）に対する改良されたホストネームの例は次の通りである。

ｗｗｗ．ｒｅｓｏｕｒｃｅ１．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅ１

ｗｗｗ．ｒｅｓｏｕｒｃｅ２．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅ２

そのような状況において、ｅｘａｍｐｌｅ．ｃｏｍに対する権威ネームサーバには、サブドメイン（この例においては、ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ）をＣＤＮのネームサーバに委任するためのＤＮＳレコードが提供される。従って、要求クライアントのＩＳＰリゾルバが、そのような改良された固有ホストネームを解決すべくｅｘａｍｐｌｅ．ｃｏｍに対する権威ネームサーバにコンタクトするとき、このリゾルバは、これに代わって、ＣＤＮのネームズサーバに向けられる。ＣＤＮネームサーバは、任意の特定の改良されたホストネームに対する解決要求の数を数えることによってリソースの人気度をトラッキングしてよく、複数のＣＤＮノードのどのティアにクライアントを向けるかを判断する場合に、これを使用してよい。このＣＤＮ内において、１または複数のコンテンツサーバティアが、人気コンテンツおよび不人気コンテンツの両方を提供するように構成されてよい。例えば、可能性のある様々なクライアント位置に地理的に近接して位置する比較的多くのコンテンツサーバが、人気コンテンツに対して指定されてよい。クライアントからの人気コンテンツ要求が、ＣＤＮによって、人気ティア内のサーバに対して解決され、ここからそれは提供されるだろう。そのコンテンツが何回か要求され、ＤＮＳおよび改良されたホストネームを通じてトラッキングされるので、このコンテンツは、最初は人気ティア内のマシンからアクセスされ、その後、ＣＤＮのアーキテクチャに応じてアクセスされるだろう。次に、そのマシンにてキャッシュされてよい。

本明細書にて使用されるように、「コンテンツ」という用語は、その表現に関わらず、また、それが何を表すかに関わらず、あらゆる形態のあらゆる種類のデータを意味する。「コンテンツ」という用語は、限定するものではないが、静止画および／または動画、テキスト、ストリーミングオーディオを含むオーディオコンテンツ、ストリーミングビデオを含むビデオコンテンツ、ウェブページ、コンピュータプログラム、ドキュメント、ファイル等を含んでよい。例えば、ＨＴＭＬおよびＸＭＬのようなマークアップ言語を使用して、何らかのコンテンツが他のコンテンツに埋め込まれてよい。コンテンツは、特定の要求に具体的に応答して生成された、または形成された、または構成されたコンテンツを含む。「リソース」という用語は、場合によっては、本明細書ではコンテンツを指すものとして使用されることがある。

リソースはまた、リソースを生成すべく、何らかの様式で組み合わされた複数のオブジェクトの集合を指すこともある。例えば、ビデオまたはオーディオストリームが、一連の、特定の符号化レートの（例えば、ある短期間の）小さなチャンクとして配信されてよい。そのような全ての符号化レートからのそのような全てのチャンクは、共通の改良されたホストネームをそれらが共有するように、集合的に単一のリソースとみなされてよい。同様に、複数の埋め込みリソースを一意的に含む複数のページが、コンテナ（例えば、ＨＴＭＬまたはＸＭＬドキュメント）およびそれらの埋め込みリソースに対して、同一の改良されたホストネームを利用してよい。

図１は、本開示の実施態様に対するネットワーク構成の一例を示し、図２は、関連した方法を記載する。示されているネットワークは、要求に対応することおよびコンテンツを提供することに関与するその他多くの構成要素を含むだろう。しかしながら、ここの図は、このシステムに関与するいくつかの構成要素だけに焦点を当てており、当業者であれば、このネットワーク内のその他の従来の構成要素を容易に理解するだろう。コンテンツ配信に関し、この例においては、ブラウザ１２を動作させているコンピューティングデバイス１０から要求が生じる。コンピューティングデバイスは、パーソナルコンピュータ、シンクライアント、タブレット、スマートフォン、セットトップボックス、ケーブルボックス等のような、ブラウザを動作させ、ネットワーク接続を介してコンテンツを要求する能力をユーザに提供することの可能な、何らかの形態の従来のデバイス、もしくは、ネットワークとやり取りし、そこからコンテンツを要求するのに適切な他の何らかのアプリまたはアプリケーションであってよい。ユーザデバイスは、パブリックネットワークで展開されているコンシューマデバイスであってよく、プライベートネットワークで展開されている企業用デバイス、または、その他のタイプのデバイスであってよい。多くの場合、ネットワーク接続は、１または複数のリゾルバ１４を動作させているインターネットサービスプロバイダ（ＩＳＰ）によって提供されるだろう。リゾルバ（ＤＮＳリゾルバともまた呼ばれる）が、要求されたリソースに対するネットワークアドレスを解決する（例えば、ドメインネームをＩＰアドレスに変換する）ために使用されるクライアント側デバイスである。一般的に言えば、リゾルバは、あるリソースに対するネットワークアドレスを解決すべく、様々な多くの構成要素を含み得るＤＮＳインフラストラクチャ１６とコンタクトする（例えば、クエリを行う）。

本開示の態様を示すために、ユーザがブラウザでウェブページアドレスｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍに入る場合を考慮する。ブラウザ１２はリゾルバ１４にコンタクトするか、またはリゾルバ１４とやり取りし、次にリゾルバ１４が、ＤＮＳ１６から、ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍウェブページに対するＩＰアドレスを要求する（処理２００）。ＤＮＳは、ブラウザ内でこのウェブページをレンダリングするであろうハイパーテキストマークアップ言語（ＨＴＭＬ）ドキュメント２０を配信することの可能なオリジンサーバ１８のＩＰアドレスを返す。このフローは、ウェブページに対するオリジンサーバにコンタクトすることを説明する。しかしながら、これは説明を目的として行われるものであり、ＤＮＳが、ウェブページを取得するために、何らかの他のデバイスへの要求を解決し得ることも可能である。ＨＴＭＬドキュメントを取得すべく、クライアントデバイスは、オリジンサーバとの間に、ＨＴＴＰプロトコル通信をカプセル化し得るＴＣＰ接続を確立する（処理２１０）。オリジンサーバは、クライアントのノードへの配信のため、および／または他のノードへのコピーの配信のために、コンテンツのオリジナルコピーを維持するデバイス（または、複数のデバイスの集合）である。本開示はオリジンサーバへの接続に関連して示されているものの、これに代わって、この接続は、要求されたリソースを提供するためにＤＮＳ内で指定された、何らかの他のデバイスによって成されてよい。この例において、オリジンサーバはデータベース２２と接続される。データベース２２は、埋め込みリソース２４を伴うＨＴＭＬドキュメント２０を含んだストレージ機器のような何らかの形態のストレージデバイス（または複数のストレージデバイス）に格納されたリソースを、構造化および管理する。このＨＴＭＬドキュメントが、ウェブページｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍを表示すべく、ブラウザが使用するものである。この例において、埋め込みリソースは、何らかの形態のコンテンツへのリンク（例えば、ＵＲＬ）である。そのウェブページが表示されているときにこのリンクを選択することによって、ユーザがそれらのコンテンツを取得できる。オンラインニュースサイトの場合、例えば、ホームページまたは任意の数のサブページ（ＨＴＭＬドキュメント）が、記事、ショートビデオクリップ等のようなコンテンツ（埋め込みリソース）への任意の数のリンクを含んでよい。テレビまたは映画ポータルの場合、ホームページまたは任意の数のサブページが、テレビの連続番組の特定のエピソードまたは特定の映画公開への任意の数のリンクを含んでよい。

このＨＴＭＬドキュメントには、特定のリソースに対する固有の改良されたホストネームを有する埋め込みリソース２４のＵＲＬ２６が提供される。ここで、ＣＤＮの顧客は、コンテンツの人気度を理解する必要または人気度を予め指定する必要が無い。例えば、ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍがオンラインビデオプロバイダのホームページであり、埋め込みリソースが、劇場で人気を博し、最近公開された映画へのリンクである場合を考慮する。そのような例において、この映画がビデオプロバイダによって公開された場合、おそらくこれは人気となる（何度も要求される）だろう。従って、この映画に対する改良されたホストネームが、ＣＤＮネームサーバ２８によって何度も解決され、それにより、ＣＤＮによって「人気」と指定されることになるだろう。

本明細書で説明される例において、コンテンツは人気または不人気のいずれかであり、人気度は、特定の改良されたホストネームがＤＮＳによって解決された回数に基づいて指定されてよい。ＤＮＳは、具体的に、改良されたホストネームに対するＣＤＮネームサーバ２８であり得る。しかしながら、人気度は、その他のスケールで指定されてもよい。例えば、そのスケールに関係するしきい値（解決された回数）による、１＝低、２＝中、３＝高や、１が不人気で１０が最も人気があるというような１−１０のスケール等である。さらに、このスケールは、そのコンテンツに対する要求の数に基づいて、初期の指定から調整されてよい。これは、別々の時間（例えば、１日あたり、１分あたり、１秒あたり、等の要求の数）に基づいたものであってよい。最後に、人気度はまた、地域特化されてもよい。例えば、ニュース記事の場合におけるリソースは、最初、それが生じた地域においては人気であるものの、その他の地域では不人気とみなされるだろう。例えば、仮に、アトランタでのニュース速報記事の場合を考えると、オンラインニュース記事（埋め込みリソース）は、ジョージアまたは米国南東部では人気と指定されるだろうが、その他の全ての地理的地域では不人気と指定されるだろう。従って、人気度サービスは地域特化されてよく、任意の定められた地理的地域におけるＤＮＳ解決の数に基づいて人気度がトラッキングされてよい。

ＤＮＳ時間における人気度指定を提供すべく、埋め込みリソースに対して固有の改良されたホストネームが提供される。固有の改良されたホストネームに関し、一例において、リソース１（例えば、最近公開された大ヒット映画）には、ある固有ホストネームが与えられ、リソース２（例えば、非常に古く、深遠なドキュメンタリー映画）には、異なる固有ホストネームが与えられるとする。上記にて導入されたような２つの改良されたホストネーム２６は、次のようであろう。埋め込みリソース１（ＥＲ１）＝（ｈｔｔｐ：／／ｒｅｓｏｕｒｃｅ１．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅ１）人気コンテンツに対して）、および、埋め込みリソース２（ＥＲ２）＝ｈｔｔｐ：／／ｒｅｓｏｕｒｃｅ２．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅ２（不人気コンテンツに対して）。これらの固有ＵＲＬホストネームは、ＨＴＭＬページ２２内に埋め込まれる。ユーザは、ここから、これらのリソースのうちのいずれかを要求してよい。本明細書にて、改良されたホストネームの２つの例が提供されている。しかしながら、任意の数の代替的なホストネームが使用されてよく、１または２を超えた、リソースおよび対応する改良されたホストネームの数（Ｎ）もまた使用されてよい。

代替的に、ホストネームは、パス中のリソースに対する明示的な参照を含む必要が無く、むしろ、以下においてより詳細に説明される、インデックス、パスのチェックサム（例えば、ＭＤ５）等のような何らかのリソースごとの識別子を含んでよい。このホストネームは、人気度をカウントするために、クライアントＩＰアドレス（または、その表現）もまた含み得る。代替的に、相対的な人気度がネーム解決時に記されてよい。何故ならば、同じネームが、おそらく、いくつかに対してリゾルバにキャッシュされ、ＣＤＮ ＤＮＳシステムにコンタクトすることなく、多数のクライアントによって使用され得るからである。

クライアント要求に戻ると、上記のように、ＨＴＭＬドキュメント２２が、埋め込みリソースとともにクライアントデバイス１０へと返される（処理２２０）。その後、クライアントがいずれかのリソースを選択した場合、そのリソースに関連付けられた改良されたホストネームを（ＤＮＳを通じて）検索すべく、ブラウザ１２が再びＩＳＰリゾルバ１４と通信する。人気のある場合の例を使用すると、ＩＳＰリゾルバは、ｒｅｓｏｕｒｃｅ１．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍを解決すべく、ＤＮＳにコンタクトするだろう。特定の一実装例において、ｅｘａｍｐｌｅ．ｃｏｍに対する権威ネームサーバが、ＣＤＮ２８に対する権威ネームサーバにｐａｔｈ．ｅｘａｍｐｌｅ．ｃｏｍサブドメインを委任するだろう。複数の埋め込みリソースのうちの１つからのホストネームを解決するとき、クライアントデバイスに関連付けられたＩＳＰリゾルバがＣＤＮの権威ネームサーバに向けられ、その後、これが、要求をどの人気度ティアに割り当てるかを判断する前に、そのように要求された各ネームの人気度をトラッキングすることができるだろう（処理２３０）。その後、ＣＤＮ ＤＮＳサーバ２８は、このクライアントにとって最も適切な配信ノードを、その人気度ティア内から選択し、そのＩＰアドレスをＩＳＰリゾルバへ返すだろう。ＣＤＮネームサーバは、人気ドメイン３０内または不人気ドメイン３２内のコンテンツサーバのいずれかからクライアントがコンテンツを取得するように向けるための、何らかの形態のインテリジェントトラフィックマネジメント３６（最適配信アルゴリズム）を使用してよい。固有の改良されたホストネームのために、ＣＤＮネームサーバは、固有の改良されたホストネームそれぞれの人気度をトラッキングする。これは、ＣＤＮ ＤＮＳに関連付けられた人気度サービス３４によって実現され得る。ＣＤＮネームサーバは、また、コンテンツを配信するのにＣＤＮ内で最良のサーバノードに対するＩＰアドレスも返す（処理２４０）。人気コンテンツに対しては、このノードは人気ティア内に存在するだろう。不人気コンテンツに対しては、このノードは不人気ティア内に存在するだろう。

インテリジェントトラフィックマネジメント（ＩＴＭ）機能は、要求クライアントに対してコンテンツを提供するのに最も好ましいアドレスを返してよい。そうすると、簡単な例においては、カリフォルニアとニューヨークの両方からコンテンツを供給することの可能なノードを有するＣＤＮから人気コンテンツを要求しているニューヨークのユーザにとって、コスト、レイテンシ、品質、最適なＣＤＮの使用等を含むいくつもの理由により、カリフォルニアからコンテンツを提供することは最適ではないだろう。本システムにおいて、その代わりにＩＴＭは、ニューヨークにいるクライアントに対してニューヨークのノードを返してよい。１つの例において、ＣＤＮネームサーバが、クライアントデバイス１０の位置に対するプロキシとして、リゾルバ１４の位置を使用してよいことに留意されたい。

ＩＴＭは、コンテンツを提供するためのノードを判断する場合に、クライアントデバイスのＩＰアドレス、リゾルバのＩＰアドレス、顧客、その他の様々な形態の情報を考慮および使用してよい。例えば、ＩＴＭは、コンテンツを提供すべく、クライアントデバイスまたはリゾルバに最も近いノードを選ぶように地理的情報を使用してよい。コンピューティングエンジンは、ネットワークトラフィックをさらに考慮してよく、最も近いノードがあまりにもビジーである場合には、近いけれどもそれよりはビジーでない別のノードを選択してよい。いくつかの事例において、そのような改良されたノード選択は、人気コンテンツに対してだけ実行されてよく、不人気コンテンツは、オリジンまたはエッジにあるものを除いたティアから提供されてよい。

例えば、いくつかの事例においてこのノードは、まだそのコンテンツをローカルに格納していなくてもよく、要求を受信すると、オリジンサーバ、別のノード、またはその他の場所からコンテンツを要求する必要がある。そのような事例において、この命令は、そのノードにコンテンツをキャッシュおよび維持させ、例えば、キャッシングＣＤＮにおいて動作している場合、次の要求に直接対応することができるだろう。

ＣＤＮネームサーバは、判断されたネットワークアドレス（例えば、ＵＲＬ、ＵＲＩ等）を要求クライアントデバイスへと返し、その後、ブラウザ１２（または、その他のデバイス）が、埋め込みリソースを提供するように指定されたＣＤＮノードとの接続を確立してよい。指定されたノードは、埋め込みリソースを有しているか、またはコンテンツを取得して要求クライアントにそれを提供するかのいずれかであろう。ＣＤＮ内にて、クライアントの要求コンテンツとして、人気ティアノードがコンテンツの全てをすぐにキャッシュし、クライアントから要求を受信すると、このコンテンツを直接配信することができるだろう。

可能な一実装例において、固有ホストネームは、基本ドメイン内のパスから発生されてよい。例えば、パスエレメントの順序を逆にし、"／"を"．"で置き換える機能を使用すると、／ｓｏｍｅ／ｄｉｒ／ｒｅｓｏｕｒｃｅ．ｅｘｔというパスは、ｒｅｓｏｕｒｃｅｅｘｔ．ｄｉｒ．ｓｏｍｅ．ｐａｔｈ．ｅｘａｍｐｌｅ．ｃｏｍを生じるだろう。

代替的な実装例において、固有ホストネームは、リソースごとに使用されてよい（これは、ＤＮＳシステムが人気度をトラッキングすることを可能とするだろう）。そこで、ｈｔｔｐ：／／ｏｒｉｇｉｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅのようなリソースに対し、システムは、ｈｔｔｐ：／／ｒｅｓｏｕｒｃｅ．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅのようなＵＲＬを使用するだろう。この例において、ＤＮＳサーバは、リソースの表現とそのパスを含む全体の"ｐａｔｈ（パス）"を参照する。ｈｔｔｐ：／／ｏｒｉｇｉｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅの例において、ＤＮＳサーバは、／ｐａｔｈ／ｒｅｓｏｕｒｃｅを取得しないだろう。故に、要求を受けるパスおよびリソースを認識しないだろう。しかしながら、人気度トラッキングＵＲＬにおいて、ＤＮＳは、このリソースの表現およびパスを参照する。故に、このコンテンツに対して存在する要求の回数をトラッキングすることができる。従って、ＤＮＳはリソース人気度をトラッキングし得る。

代替形態において、実際のパスおよびリソースネームをＵＲＬに提供することなしに、またＤＮＳにとって利用可能とすることなしに人気度トラッキングを提供すべく、このシステムは、オリジンにおける各／ｐａｔｈ／ｒｅｓｏｕｒｃｅを一意的に表すホストネームを使用してよい。そのような代替形態において、このシステムは、ｈｔｔｐ：／／ａ１２４２．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅのようなｐａｔｈ／ｒｅｓｏｕｒｃｅの固有ホストネーム表現を提供すべく、／ｐａｔｈ／ｒｅｓｏｕｒｃｅのインデックスまたはチェックサム（例えば、ＭＤ５）を使用してよい。この例において、ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍドメイン内のネームは、／ｐａｔｈ／ｒｅｓｏｕｒｃｅの異なる値ごとに異なるものである。上記にて参照された改良された固有ホストネームと同様に、ＤＮＳは、あるリソースに対する要求の数をトラッキングしてよい。故に、人気度をトラッキングすることができる。

ここで、チェックサムが使用される場合、これは、パスが有効であること、および／または、そのリソースに対してホストネームが正しいことを確認するためにもまた使用され得る。いくつかの事例において、第２の無関係なＵＲＬ上のある１つのＵＲＬからのホストネームを誰かが使用しているときに、システムは「リンクのハイジャック」という形の課題を有する場合がある。パスに対して相対的なホストネームの正当性を確認すべく、このホストネームがチェックサムである場合、またはこのホストネームがチェックサムを含む場合に、クライアントにより要求されている／ｐａｔｈ／ｒｅｓｏｕｒｃｅとこれが整合しなければ、受信ＣＤＮノードが直ちにこの要求を拒否することができる。このチェックは、部分的または完全であり得る。すなわち、このチェックサムは、／ｐａｔｈ／ｒｅｓｏｕｒｃｅのある部分にわたるものであってよい。または、／ｐａｔｈ／ｒｅｓｏｕｒｃｅ全体のものであり得る。／ｐａｔｈ／ｒｅｓｏｕｒｃｅの一部分を使用することは、リソースごとよりも、むしろ、複数のリソースの組に対して人気度がトラッキングされていることを意味するだろうが、トラッキングされるのに必要なネームの数がある程度低減されるという恩恵を伴う。これは、密接に関連した複数のオブジェクト（例えば、ストリーミングビデオアセットの個々のチャンク）の複数のグループを扱う場合に有益となり得る。

図３は、本明細書にて説明される様々な手法を実施し得るコンピューティングシステム６００の例示的概略図である。アプリケーション６０８のためのコンピューティングシステムは、バス６０１（すなわち、インターコネクト）、少なくとも１つのプロセッサ６０２またはその他のコンピューティングエレメント、少なくとも１つの通信ポート６０３、メインメモリ６０４、リムーバブルストレージ媒体６０５、リードオンリメモリ６０６、および大容量ストレージデバイス６０７を含む。プロセッサ６０２は、これらに限定されるものではないが、Ｉｎｔｅｌ（登録商標）Ｉｔａｎｉｕｍ（登録商標）またはＩｔａｎｉｕｍ２（登録商標）プロセッサ、ＡＭＤ（登録商標）Ｏｐｔｅｒｏｎ（登録商標）またはＡｔｈｌｏｎ ＭＰ（登録商標）プロセッサ、もしくは、Ｍｏｔｏｒｏｌａ（登録商標）のプロセッサ商品群のような、あらゆる既知のプロセッサであり得る。通信ポート６０３は、モデムベースのダイアルアップ接続に使用するためのＲＳ−２３２ポート、１０／１００イーサネット（登録商標）ポート、銅線またはファイバを使用したギガビットポート、もしくはＵＳＢポートのいずれでもあり得る。通信ポート６０３は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはコンピュータシステム６００が接続する任意のネットワークのようなネットワークに応じて選択されてよい。ランデブーアプリケーションは、入出力（Ｉ／Ｏ）ポート６０９を介して周辺デバイス（例えば、ディスプレイスクリーン６３０、入力デバイス６１６）と通信し得る。

メインメモリ６０４は、ランダムアクセスメモリ（ＲＡＭ）、または、本技術分野において一般に知られている任意の他の動的ストレージデバイスであり得る。リードオンリメモリ６０６は、プロセッサ６０２に対する命令のような静的情報を格納するためのプログラマブルリードオンリメモリ（ＰＲＯＭ）チップのような、任意の静的ストレージデバイスであり得る。大容量ストレージデバイス６０７は、情報および命令を格納するために使用され得る。例えば、Ａｄａｐｔｅｃ（登録商標）のスモールコンピュータシリアルインタフェース（ＳＣＳＩ）ドライブのファミリのようなハードディスク、光学ディスク、Ａｄａｐｔｅｃ（登録商標）のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）ドライブのファミリ等のＲＡＩＤのようなディスクのアレイ、または、任意の他の大容量ストレージデバイスが使用されてよい。

バス６０１は、プロセッサ６０２を、その他のメモリブロック、ストレージブロック、および通信ブロックと通信可能に連結する。バス６０１は、使用されるストレージデバイスに応じて、ＰＣＩ／ＰＣＩ−Ｘ、ＳＣＳＩ、またはユニバーサルシリアルバス（ＵＳＢ）ベースのシステムバス（またはその他）であり得る。リムーバブルストレージ媒体６０５は、あらゆる種類の外部ハードドライブ、サムドライブ、コンパクトディスク−リードオンリメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リライタブル（ＣＤ−ＲＷ）、デジタルビデオディスク−リードオンリメモリ（ＤＶＤ−ＲＯＭ）等を含み得る。

本明細書における実施形態は、コンピュータプログラム製品として提供されてよい。これは、プロセスを実行するようにコンピュータ（または、他の電子デバイス）をプログラムするために使用され得る命令がそこに格納された、機械可読媒体を含み得る。機械可読媒体は、これらに限定されるものではないが、光学ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、磁気カードまたは光カード、フラッシュメモリ、もしくは、電子的命令を格納するのに適切な他のタイプの媒体／機械可読媒体を含んでよい。

示されるように、メインメモリ６０４は、上記にて説明され、また下記にてさらに説明される機能性をサポートする、改良されたホストネーム人気度ランデブーエンジンアプリケーション６０８−１により符号化される。例えば、一実施形態において、アプリケーション６０８−１は、本明細書に記載された様々なプロセスおよび／または命令を含んでよく、または実施してよい。アプリケーション６０８−１（および／または、本明細書に記載されたその他のリソース）は、本明細書に記載された様々な実施形態による処理機能性をサポートする、データおよび／またはロジック命令のようなソフトウェアコード（例えば、メモリまたはディスク等の別のコンピュータ可読媒体に格納されたコード）として具現化され得る。一実施形態の処理の間、プロセッサ６０２は、例えばロジック命令を通じて、メインメモリに格納された、または実体的に格納されたアプリケーション６０８−１に基づいて、および、プロセッサ６０２上で実行して、ＥＨＮＰＲプロセス６０８−２を、起動、動作、実行、解釈または実施すべく、バス６０１の使用を介してメインメモリ６０４にアクセスする。

上記の説明は、本開示の技法を具現化する例示的なシステム、方法、技法、命令シーケンス、および／またはコンピュータプログラム製品を含む。しかしながら、記載された開示は、これらの具体的な詳細無しでも実施され得ることが理解される。本開示において、開示される方法は、デバイスによって可読な命令セットまたはソフトウェアとして実施されてよい。さらに、開示される方法におけるステップの特定の順序または階層は、例示的アプローチの事例であることが理解される。設計上の優先事項に基づいて、この方法におけるステップの特定の順序または階層は、開示されている主題内に留まりながら再配列され得ることが理解される。方法に係る添付の請求項は、例としての順序で様々なステップの要素を提示するものであり、必ずしも、提示された特定の順序または階層に限定されるべきことを意味するものではない。

記載された開示は、本開示によるプロセスを実行するようにコンピュータシステム（または、他の電子デバイス）をプログラムするために使用され得る命令がそこに格納された機械可読媒体を含み得る、コンピュータプログラム製品またはソフトウェアとして提供されてよい。機械可読媒体は、機械（例えば、コンピュータ）によって可読な形態（例えば、ソフトウェア、処理アプリケーション）で情報を格納するための任意のメカニズムを含む。機械可読媒体は、これらに限定されるものではないが、磁気ストレージ媒体、光学ストレージ媒体（例えば、ＣＤ−ＲＯＭ）、光磁気ストレージ媒体、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラマブルメモリ（例えば、ＥＰＲＯＭおよびＥＥＰＲＯＭ）、フラッシュメモリ、または、電子的命令を格納するのに適切な他のタイプの媒体を含んでよい。

本開示および付随するその利点の多くが、上記の説明によって理解されるはずであり、開示されている主題から逸脱することなく、または、その全ての実体的な利点を犠牲にすることなく、複数の構成要素の形態、構成、および配置において様々な変化が成され得ることが明らかなはずであると考えられる。記載されている形態は単なる説明であり、そのような変化を包含および含むことを、以下の請求項は意図している。

様々な実施形態を参照して本開示が記載されてきたものの、これらの実施形態は例示的であって、本開示の範囲をそれらに限定するものではないことが理解されるべきである。多くの変形、変更、付加、および改善が可能である。より一般的に、本開示による実施形態が、特定の実装例のコンテキストにおいて記載されてきた。機能性は、本開示の様々な実施形態において、異なるように複数のブロックに分けられてよく、または組み合わされてよく、もしくは、様々な用語で記載されてよい。これらおよび他の変形、変更、付加、および改善は、以下の特許請求の範囲にて定義される、本開示の範囲に含まれ得る。
［項目１］
ドメインに対する権威ネームサーバにおいてユニフォームリソースロケータ解決要求を受信する段階であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求のホストネームに少なくとも部分的に基づいて受信され、前記ホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに関連する、受信する段階と、
前記リソースに関連する前記ホストネームに基づいて、前記リソースの人気度を追跡する段階と、
前記リソースを配信可能なネットワーク内のノードを提供する段階であって、前記提供されるノードは、前記リソースの前記人気度に基づいている、提供する段階と
を備える、コンテンツ配信方法。
［項目２］
前記リソースの前記人気度の前記追跡をする段階は、
前記リソースに関連する前記ホストネームが要求される回数を判断することにより、前記権威ネームサーバにおいて、前記リソースの前記人気度を追跡する段階を含む、請求項１に記載のコンテンツ配信方法。
［項目３］
前記ノードは、コンテンツ配信ネットワーク内のエッジサーバである、請求項１または請求項２に記載のコンテンツ配信方法。
［項目４］
前記ホストネームは、基本ドメインネームおよび前記リソースへのパスの関数から構成される、請求項１から請求項３のいずれか一項に記載のコンテンツ配信方法。
［項目５］
前記ホストネームは、前記パスに一意的に関連したチェックサムを含む、請求項４に記載のコンテンツ配信方法。
［項目６］
前記チェックサムに基づいて、前記ホストネームが前記パスおよび前記リソースと一致することを確認する段階をさらに備える、請求項５に記載のコンテンツ配信方法。
［項目７］
前記ホストネームは、前記リソースに一意的に関連したインデックスを含む、請求項１から請求項６のいずれか１項に記載のコンテンツ配信方法。
［項目８］
前記リソースを示すパスを前記ホストネームに変換する段階をさらに備える、請求項１から請求項７のいずれか１項に記載のコンテンツ配信方法。
［項目９］
前記ホストネームは、固有ホストネームであり、ｒｅｓｏｕｒｃｅ．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅの形式を含むリンクに含まれる、請求項１から請求項８のいずれか１項に記載のコンテンツ配信方法。
［項目１０］
コンピュータ実行可能な命令を含む非一時的コンピュータ可読媒体と通信する少なくとも１つの処理デバイスを備える装置であって、
前記コンピュータ実行可能な命令は、
ドメインに対する権威ネームサーバにおいてユニフォームリソースロケータ解決要求を受信する命令であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求のホストネームに少なくとも部分的に基づいて受信され、前記ホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに関連する、受信する命令、および、
前記リソースに一意的に関連する前記ホストネームに基づいて、前記リソースの人気度を追跡する命令
である、装置。
［項目１１］
前記リソースの前記人気度の前記追跡は、
前記リソースに一意的に関連した前記ホストネームが、特定の地理的地域内で要求される回数を判断することにより、前記権威ネームサーバにおいて、前記特定の地理的地域内での前記リソースの前記人気度の追跡を含む、請求項１０に記載の装置。
［項目１２］
前記コンピュータ実行可能な命令は、前記リソースを配信可能なネットワーク内のノードをさらに提供する命令であって、前記提供されるノードは、前記リソースの前記人気度に基づいている、請求項１０または請求項１１に記載の装置。
［項目１３］
前記ノードは、コンテンツ配信ネットワーク内のエッジサーバである、請求項１２に記載の装置。
［項目１４］
前記ホストネームは、基本ドメインネームおよび前記リソースへのパスの関数から構成される、請求項１０から請求項１３のいずれか１項に記載の装置。
［項目１５］
前記ホストネームは、前記パスに一意的に関連したチェックサムを含む、請求項１４に記載の装置。
［項目１６］
前記コンピュータ実行可能な命令は、前記チェックサムに基づいて、前記ホストネームが前記パスおよび前記リソースと一致することをさらに確認する命令である、請求項１５に記載の装置。
［項目１７］
前記ホストネームは、前記リソースに一意的に関連したインデックスを含む、請求項１０から請求項１６のいずれか１項に記載の装置。
［項目１８］
前記コンピュータ実行可能な命令は、前記リソースを示すパスを前記ホストネームにさらに変換する命令である、請求項１０から請求項１７のいずれか１項に記載の装置。
［項目１９］
前記ホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられた前記リソースに一意的に関連する、請求項１０から請求項１８のいずれか１項に記載の装置。
［項目２０］
前記リソースに一意的に関連した前記ホストネームは、ｒｅｓｏｕｒｃｅ．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅの形式を含むリンクに含まれる、請求項１９に記載の装置。
［項目２１］
ドメインに対する権威ネームサーバにおいてユニフォームリソースロケータ解決要求を受信する命令であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求のホストネームに少なくとも部分的に基づいて受信され、前記ホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに関連する、受信する命令、および、
前記リソースに一意的に関連する前記ホストネームに基づいて、前記リソースの人気度をする命令
を少なくとも１つの処理デバイスに実行させるプログラム。

Claims (15)

1. ドメインに対するネームサーバにおいてユニフォームリソースロケータ解決要求を受信する段階であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求の固有の改良されたホストネームに少なくとも部分的に基づいて受信され、前記固有の改良されたホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに一意的に関連する、受信する段階と、
   前記ネームサーバにおいて、前記リソースの人気度をトラッキングする段階であって、前記トラッキングすることは、前記リソースに関連する前記固有の改良されたホストネームが要求される回数を判断することを含み、前記固有の改良されたホストネームは、基本ドメインネームおよび前記リソースへのパスの関数から構成される、トラッキングする段階と、
   前記リソースを配信可能なネットワーク内のノードを提供する段階であって、前記提供されるノードは、前記リソースのトラッキングされた前記人気度に基づいている、提供する段階と
   を備える、コンテンツ配信方法。
2. 前記ノードは、コンテンツ配信ネットワーク内のエッジサーバである、請求項１に記載のコンテンツ配信方法。
3. 前記固有の改良されたホストネームは、前記パスに一意的に関連したチェックサムを含む、請求項１または請求項２に記載のコンテンツ配信方法。
4. 前記チェックサムに基づいて、前記固有の改良されたホストネームが前記パスおよび前記リソースと一致することを確認する段階をさらに備える、請求項３に記載のコンテンツ配信方法。
5. 前記固有の改良されたホストネームは、前記リソースに一意的に関連したインデックスを含む、請求項１から請求項４のいずれか１項に記載のコンテンツ配信方法。
6. 前記リソースを示すパスを前記固有の改良されたホストネームに変換する段階をさらに備える、請求項１から請求項５のいずれか１項に記載のコンテンツ配信方法。
7. 前記固有の改良されたホストネームは、ｒｅｓｏｕｒｃｅ．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅの形式を含むリンクに含まれる、請求項１から請求項６のいずれか１項に記載のコンテンツ配信方法。
8. コンピュータ実行可能な命令を含む非一時的コンピュータ可読媒体と通信する少なくとも１つの処理デバイスを備える装置であって、
   前記コンピュータ実行可能な命令は、
   ドメインに対するネームサーバにおいてユニフォームリソースロケータ解決要求を受信する命令であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求の固有の改良されたホストネームに少なくとも部分的に基づいて受信され、前記固有の改良されたホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに一意的に関連する、受信する命令、
   前記ネームサーバにおいて、前記リソースの人気度をトラッキングする命令であって、前記トラッキングすることは、前記リソースに関連する前記固有の改良されたホストネームが要求される回数を判断することを含み、前記固有の改良されたホストネームは、基本ドメインネームおよび前記リソースへのパスの関数から構成される、トラッキングする命令、および、
   前記リソースを配信可能なネットワーク内のノードを提供する命令であって、前記提供されるノードは、前記リソースのトラッキングされた前記人気度に基づいている、提供する命令、
   である、装置。
9. 前記ノードは、コンテンツ配信ネットワーク内のエッジサーバである、請求項８に記載の装置。
10. 前記固有の改良されたホストネームは、前記パスに一意的に関連したチェックサムを含む、請求項８または請求項９に記載の装置。
11. 前記コンピュータ実行可能な命令は、前記チェックサムに基づいて、前記固有の改良されたホストネームが前記パスおよび前記リソースと一致することをさらに確認する命令である、請求項１０に記載の装置。
12. 前記固有の改良されたホストネームは、前記リソースに一意的に関連したインデックスを含む、請求項８から請求項１１のいずれか１項に記載の装置。
13. 前記コンピュータ実行可能な命令は、前記リソースを示すパスを前記固有の改良されたホストネームにさらに変換する命令である、請求項８から請求項１２のいずれか１項に記載の装置。
14. 前記リソースに一意的に関連した前記固有の改良されたホストネームは、ｒｅｓｏｕｒｃｅ．ｐａｔｈ．ｃｄｎ．ｅｘａｍｐｌｅ．ｃｏｍ／ｐａｔｈ／ｒｅｓｏｕｒｃｅの形式を含むリンクに含まれる、請求項８から請求項１３のいずれか一項に記載の装置。
15. ドメインに対するネームサーバにおいてユニフォームリソースロケータ解決要求を受信する命令であって、前記ユニフォームリソースロケータ解決要求は、前記ユニフォームリソースロケータ解決要求の固有の改良されたホストネームに少なくとも部分的に基づいて受信され、前記固有の改良されたホストネームは、前記ユニフォームリソースロケータ解決要求に関連付けられたリソースに一意的に関連する、受信する命令、および、
    前記ネームサーバにおいて、前記リソースの人気度をトラッキングする命令であって、前記トラッキングすることは、前記リソースに関連する前記固有の改良されたホストネームが要求される回数を判断することを含み、前記固有の改良されたホストネームは、基本ドメインネームおよび前記リソースへのパスの関数から構成される、トラッキングする命令、および、
    前記リソースを配信可能なネットワーク内のノードを提供する命令であって、前記提供されるノードは、前記リソースのトラッキングされた前記人気度に基づいている、提供する命令、
    を少なくとも１つの処理デバイスに実行させるプログラム。