JP2017536606A - コンテンツ配信ネットワークにおけるロングテールコンテンツ処理 - 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