JP2018506936A - ネットワークにおいてコンテンツを配信するエンドツーエンドソリューションのための方法及びシステム - 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