JP6278531B2 - ハイブリッドｈｔｔｐ及びｕｄｐコンテンツ配信 - Google Patents

Description

本願は一般に、ネットワークを介したデータ通信に関する。

分散型コンピュータ・システムは従来技術で良く知られている。こうした分散型コンピュータ・システムの１つが「コンテンツ配信ネットワーク」又は「ＣＤＮ」であり、典型的にはサービス・プロバイダによって運営及び管理される。サービス・プロバイダは、典型的には、サービス・プロバイダの共有インフラストラクチャを使用する第三者（カスタマ）のためにコンテンツ配信サービスを提供する。この種の分散型システムは、時には「オーバーレイ・ネットワーク」と呼ばれ、典型的には、コンテンツ配信、適用促進、又は外部委託されたオリジン・サイト・インフラストラクチャの他のサポート等の、様々なサービスを容易にするように設計された、ソフトウェア、システム、プロトコル、及び技法と共に、ネットワークによって結び付けられた自律型コンピュータの集合を言い表す。ＣＤＮサービス・プロバイダは、典型的には、カスタマのポータルに提供された後、ネットワークに展開される、デジタル・プロパティ（ウェブサイト等）を介してサービスを配信する。

上述したタイプのオーバーレイ・ネットワークは、ネットワーク内のサーバから、ビデオ・ストリームを受信してこれをスクリーン上で再生するクライアントへと、ＨＴＴＰベースのストリーミングを提供する。クライアントは、デスクトップ・コンピュータ、モバイル・デバイス（スマートフォン、タブレット）、セットトップ・ボックス、スマート・テレビジョン又は電化製品、或いは任意の他のネットワーク接続デバイス上で動作し得るものである。典型的なＨＴＴＰベースのストリーミングを使用するケースでは、クライアントはＤＮＳを介してＩＰアドレスへと名前（例えばＣＤＮホスト名）を解決し、そのアドレスに関連付けられたサーバへのＴＣＰ接続を実行する。確立されると、クライアントは、望ましいコンテンツ、例えばメディア・フラグメントについてのＨＴＴＰ ＧＥＴ要求を送信する。サーバは、標準ＨＴＴＰ応答本体内のコンテンツ・データで以て応答する。更なる要求及び応答のために、接続はオープンのまま維持される。

ハーパーテキスト転送プロトコル（ＨＴＴＰ）を使用する標準手法は、（伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）接続上で）ＨＴＴＰプロトコルで要求を行い、ＨＴＴＰ応答内に要求されたデータを含む応答を（同じＴＣＰ／ＩＰ接続を介して）受信する。代替のストリーミング手法は、要求及び応答（制御メッセージを含む）の両方について、ユーザ・データグラム・プロトコル（ＵＤＰ）又はＴＣＰ上でのプロトコルを使用する。更に他の手法は、ＨＴＴＰセッションを介して何らかのプロトコルをトンネリングする。

現在、多くのエンド・ユーザが、遅い起動時間、再バッファリング、及び低いビットレート等の、ＨＴＴＰベース・ストリーミングに付随する問題を体験する。これらユーザの接続はしばしば高品質ビデオにとって十分に大きい帯域幅を示すが、サーバとクライアントとの間の往復時間及びパケット損失特性は、主に標準ＴＣＰベースのインプリメンテーションがこうしたネットワーク上で非効率的に動作することから、ストリーミング性能にマイナスの影響を与える。

米国特許出願公開第２０１１０１７３３４５号 米国特許第７，１１１，０５７号 米国特許第７，４７２，１７８号 米国特許第７，３７６，７１６号 米国特許出願公開第２００４００９３４１９号

したがって、ビデオ・ストリーミング品質を向上させるために新規の技法を提供することが求められている。本明細書における開示は、関係する従来技術に付随するこれら及び他の問題に対処するものである。

ハイブリッドＨＴＴＰ／ＵＤＰ配信プロトコルは、オーバーレイ等のネットワークを介したビデオ等のコンテンツの配信を大幅に向上させる。この手法は、ＨＴＴＰベース・ストリーミングに関する問題（例えば、遅い起動時間、再バッファリング、及び低いビットレート）に対処するのに特に有用である。

一般に当該プロトコルは、２つのフェーズ、すなわちＨＴＴＰフェーズとＵＤＰフェーズとを有する。ＨＴＴＰフェーズにおいて、クライアントはＨＴＴＰ ＧＥＴ要求をサーバに送信する。当該ＧＥＴ要求は、クライアントが当該プロトコルでのＵＤＰベースの転送を使用したい旨をサーバに伝える、トランスポート・ヘッダを含む。サーバは、このモードを拒否して通常のＨＴＴＰモードを継続してもよいし、あるいは、ＵＤＰフェーズに入るためにはどのように接続を行えばよいかをクライアントに伝えるヘッダ情報を伴う空の応答を送信することによって、応答してもよい。ＵＤＰフェーズにおいて、クライアントは接続を開始し、ＵＤＰによって最初に要求したコンテンツを受信する。

ハイブリッド手法は、ＵＤＰプロトコルでコンテンツを伝送するための別のチャネルを追加するという点が従来のＨＴＴＰベース・ストリーミングとは異なる。クライアントがサーバに接続すると、クライアントは所望のコンテンツ、例えばメディア・フラグメントに関するＨＴＴＰ ＧＥＴ要求を送信し、応答本体の転送のためにＵＤＰ接続を使用することを望む旨を示すＨＴＴＰヘッダを含める。クライアントは、ＵＤＰ配信に関する任意のプリファレンス（例えば、順方向誤り訂正（ＦＥＣ）、又は他のパラメータ）を含めることもできる。サーバは、プロトコルを使用するように設定されている場合、空の本体（コンテンツ長：０）回答で以て応答する。応答は、好ましくは、途中のプロキシが応答をキャッシュに入れるのを防ぐための様々なヘッダも含む。応答ヘッダにおいて、クライアントは、ＵＤＰプロトコルによってどのように同じサーバに接続するかに関する情報を（又は、例えばマルチソース・コンテンツ獲得のための、他の追加の代替サーバ参照をも）見つける。この情報は、典型的にはＩＰアドレス、ＵＤＰポート番号、オプションで（同じサーバのＵＤＰポート上に多くのこうした接続が存在する場合があるため、通信がいずれのフローに属するかを識別するための）何らかの他の特別ポート番号、バージョン、及びトークンＴを含む。この情報がサーバから受信されると、ＨＴＴＰ応答ヘッダ内に提供された情報（ＩＰアドレス、ＵＤＰポート番号、他のポート番号等）に基づいてＳＹＮ ＵＤＰパケットをサーバに送信することによって、クライアントはＵＤＰ接続を開始する。この要求は、好ましくはＨＴＴＰ応答からのトークンＴも含む。したがってサーバは、トークンを使用して、ＵＤＰパケットを送信しているクライアントが以前のＨＴＴＰ応答を見たこと、及び、かかるＳＹＮパケットが処理されるべきであることを、確認することができる。ＳＹＮは、好ましくはクライアントの初期シーケンス番号（ＩＳＮ）をも含む。サーバは、クライアントのＳＹＮパケットからの肯定応答ＩＳＮ値を含む、ＳＹＮ＿ＡＣＫパケットで以て応答する。ＳＹＮ＿ＡＣＫは、サーバのＩＳＮ値をも含む。その後クライアントは、サーバのＳＹＮ＿ＡＣＫパケットからの肯定応答ＩＳＮを含み、再びトークンＴをも含むＳＹＮ＿ＡＣＫ＿ＡＣＫパケットによって、ＳＹＮ＿ＡＣＫの受信を確認する。ＩＳＮ及びトークンＴの確認は、両者が通信に参加していること、及び以前のすべてのパケットを見ていることを保証するための手段として働く。トークン（ＨＴＴＰ応答では、ＳＹＮ及びＳＹＮ＿ＡＣＫ＿ＡＣＫパケット）は、この特定のクライアントとサーバとの間で、他のＨＴＴＰ要求についての接続の再使用も容易にする。このようにハンドシェイクが完了すると、ＵＤＰベース接続が確立されたものとみなされ、その後サーバは、（場合によってはＦＥＣ符号化された）コンテンツを伴うデータ・パケットの送信を開始する。コンテンツは、ＵＤＰが使用されないならば、オリジナルのＨＴＴＰ応答本体内にあったであろうものと同じである。

上記では、主題のより適切な特徴のうちのいくつかを概説した。これらの特徴は、単なる例示であるものと解釈すべきである。開示された主題を異なる態様で適用すること、又は、この主題を後述するように修正することによって、他の多くの有益な結果を得ることができる。

次に、主題及びその利点をより完全に理解するために、添付の図面に関連して以下で説明する。

コンテンツ配信ネットワーク（ＣＤＮ）として構成される、既知の分散型コンピュータ・システムを示すブロック図である。 代表的なＣＤＮエッジ・マシーン構成を示す図である。 本開示の基本的なハイブリッドＨＴＴＰ／ＵＤＰデータ配信手法を示す図である。 追加の細部において、本開示のハイブリッドＨＴＴＰ／ＵＤＰ配信技法に関する動作シナリオを示す図である。

図１は、本明細書の技法によって（以下で説明するように）拡張される、既知の分散型コンピュータ・システムを示す。

図１に示されるような既知のシステムでは、分散型コンピュータ・システム１００がＣＤＮとして構成され、インターネットの周囲に分散されたマシーン１０２ａ〜ｎのセットを有するものと想定される。典型的には、ほとんどのマシーンはインターネットのエッジ近くに、すなわちエンド・ユーザ・アクセス・ネットワークに、又はその近傍に配置されたサーバである。ネットワーク・オペレーション・コマンド・センタ（ＮＯＣＣ）１０４が、システム内の様々なマシーンの動作を管理する。ウェブ・サイト１０６等の第三者サイトは、分散型コンピュータ・システム１００、及び特に「エッジ」サーバに対する、コンテンツ（例えばＨＴＭＬ、埋め込みページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロード等）の配信を肩代わりさせる。典型的には、コンテンツ・プロバイダは、サービス・プロバイダの権威あるドメイン名サービスによって管理されているドメインに対して、所与のコンテンツ・プロバイダのドメイン又はサブ・ドメインを（例えばＤＮＳ ＣＮＡＭＥによって）エイリアス化することによって、自身のコンテンツ配信を肩代わりさせる。コンテンツを所望するエンド・ユーザは、そのコンテンツをより確実かつ効率的に取得するために、分散型コンピュータ・システムに向けて送られる。詳細には示されていないが、分散型コンピュータ・システムは、利用データ及び他のデータをエッジ・サーバから収集し、そのデータを領域又は領域のセット全体にわたって集約し、そのデータを、モニタリング、ログ記録、警告、課金、管理、又は他の運営及び管理機能を容易にするために、他のバックエンド・システム１１０、１１２、１１４、及び１１６に渡す、分散型データ収集システム１０８等の、他のインフラストラクチャも含み得る。分散型ネットワーク・エージェント１１８は、ネットワーク並びにサーバのロードをモニタリングし、ネットワーク、トラフィック、及びロードのデータを、ＣＤＮによって管理されているコンテンツ・ドメインに関して権限のあるＤＮＳ照会処理機構１１５に提供する。分散型データ移送機構１２０を使用して、エッジ・サーバに制御情報（例えばコンテンツを管理し、ロード・バランシングを容易にするためのメタデータ等）を配信することができる。

図２に示すように、所与のマシーン２００は、１つ又は複数のアプリケーション２０６ａ〜２０６ｎをサポートするオペレーティング・システム・カーネル（Ｌｉｎｕｘ又は変形等）２０４を動作させるコモディティ・ハードウェア（例えばＩｎｔｅｌ Ｐｅｎｔｉｕｍプロセッサ）２０２を含む。コンテンツ配信サービスを容易にするため、例えば所与のマシーンは典型的に、ＨＴＴＰ（ウェブ）プロキシ２０７、ネーム・サーバ２０８、ローカル・モニタリング・プロセス２１０、及び分散型データ収集プロセス２１２等の一連のアプリケーションを実行する。より一般的には、プロキシ２０７は、プログラム命令を含み、その命令がメモリ内に保持され、必要に応じてプロセッサ（又は複数のプロセッサ）によって実行される、ソフトウェアである。

ストリーミング・メディアでは、ＣＤＮマシーンは通常、サポートするメディア・フォーマットの要件に応じて、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｓｅｒｖｅｒ（ＷＭＳ）又はフラッシュ・サーバ等の、１つ又は複数のメディア・サーバを含む。専用メディア・サーバを使用する代わりに、トランスポート・プロトコルとしてＨＴＴＰを使用する。ＨＴＴＰベースのライブ・ストリーム及びＶＯＤベースの配信のためのアーキテクチャが、米国特許出願公開第２０１１０１７３３４５号に記載されている。その手法はＣＤＮ内でインプリメントされ、レコーディング・ティアを使用して配信されることになるコンテンツ・ストリームをレコーディングし、プレーヤ・ティアを使用してストリームを再生するという高水準機能を含む。ストリームをレコーディングするステップは、ストリームがソース・フォーマットにてＣＤＮエントリ・ポイントで受信されたときに開始する、サブステップのセットを含む。次いでストリームは、ＣＤＮ内でストリームを配信するための内部フォーマットであり、ストリーム・マニフェスト、１つ又は複数のフラグメント・インデックス（ＦＩ）のセット、及びＩＦフラグメントのセットを含む、中間フォーマット（ＩＦ）に変換される。プレーヤ・プロセスは、要求元クライアントがｇｈｏｓｔベースのプロキシ等のＣＤＮ ＨＴＴＰプロキシに関連付けられたときに開始される。ストリーム又はその一部に対する要求がＨＴＴＰプロキシで受信されたことに応答して、ＨＴＴＰプロキシは（アーカイブ又はデータ・ストアのいずれかから）ストリーム・マニフェスト及び少なくとも１つのフラグメント・インデックスを取り出す。フラグメント・インデックスを使用して、ＩＦフラグメントがＨＴＴＰプロキシに取り出され、ターゲット・フォーマットに変換され、次いでクライアント要求に応答してサービスされる。ソース・フォーマットはターゲット・フォーマットと同じであるか又は異なる。好ましくは、すべてのフラグメントは、ＨＴＴＰを用いてＨＴＴＰプロキシによってアクセス、キャッシュ、及びサービスされる。別の実施形態において、ストリームをオンデマンドで配信する方法（ＶＯＤ）は、（レコーディング・ティアの代わりに）トランスレーション・ティアを使用して、ＩＦコンポーネントの作成及び／又は取扱いを管理する。

ＣＤＮエッジ・サーバは、好ましくは構成システムを利用するエッジ・サーバに配分されている構成ファイルを利用して、好ましくはドメイン特化型、カスタマ特化型の１つ又は複数の広範なコンテンツ配信特性を提供するように構成されている。所与の構成ファイルは、ＸＭＬをベースとし、１つ又は複数の高度のコンテンツ処理特性を容易にする一連のコンテンツ処理規則及び命令を含むことが好ましい。構成ファイルは、データ伝送機構を介してＣＤＮエッジ・サーバに配信することができる。米国特許第７，１１１，０５７号は、エッジ・サーバ・コンテンツ制御情報を配信及び管理するための有用なインフラストラクチャを説明しており、これ等のエッジ・サーバ制御情報は、ＣＤＮサービス・プロバイダ自体、又は（エクストラネット等を介して）オリジン・サーバを運用するコンテンツ・プロバイダ・カスタマによってプロビジョニングすることができる。

ＣＤＮインフラストラクチャは複数の第三者によって共有されるため、本明細書ではマルチテナント共有インフラストラクチャと呼ぶことがある。ＣＤＮプロセスはインターネット上の公開でルーティング可能なノードに、モバイル・ネットワーク内に配置されたノード内又はその近傍に、企業ベースのプライベート・ネットワーク内又はその近傍に、或いはそれらの任意の組み合わせで、配置可能である。

メタデータ構成可能なオーバーレイ・ネットワーク・ウェブ・プロキシ（図２のプロキシ２０７等）は、本明細書ではグローバル・ホスト又はＧＨｏｓｔプロセスと呼ぶことがある。

ＣＤＮは、米国特許第７，４７２，１７８号に記載されたもののような記憶サブシステムを含むことができる。この開示内容は引用により本願に含まれるものとする。

ＣＤＮは、カスタマ・コンテンツの中間キャッシングを提供するためにサーバ・キャッシュ階層を運用することができる。このようなキャッシュ階層サブシステムの一例が米国特許第７，３７６，７１６号に記載されている。この開示内容は引用により本願に含まれるものとする。

ＣＤＮは、米国特許出願公開第２００４００９３４１９号に記載されたように、クライアント・ブラウザ、エッジ・サーバ、及びカスタマ・オリジン・サーバ間でセキュアなコンテンツ配信を提供することができる。これに記載されたセキュアなコンテンツ配信は、一方ではクライアントとエッジ・サーバ・プロセスとの間で、他方ではエッジ・サーバ・プロセスとオリジン・サーバ・プロセスとの間でＳＳＬベースのリンクを実施する。これによって、ＳＳＬによって保護されたウェブ・ページ及び／又はそのコンポーネントを、エッジ・サーバを介して配信することができる。

オーバーレイとしてＣＤＮリソースを用いることにより、（プライベートに管理可能な）エンタープライズ・データ・センタと第三者へのサービスとしてのソフトウェア（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）高速化サービスを容易にしてもよい。

ＣＤＮは、ＨＤストリーミング等の様々なコンテンツ配信機能を容易にするために、クライアント側ソフトウェアを提供することもできる。一手法において、クライアントは２つのコンポーネントを備える。第１は、非永続型のブラウザ内メディア・プレーヤであり、第三者（例えばＡｄｏｂｅ Ｆｌａｓｈ又はＭｉｃｒｏｓｏｆｔ Ｓｉｌｖｅｒｌｉｇｈｔ）コンポーネントに基づいてＨＤコンテンツの適応型又は動的なビットレート配信を容易にすることができる。第２は永続型デーモンの形のインターフェースであり、「クライアント側」コンテンツ配信を実行することができる。クライアント側配信とは、コンテンツを、ＣＤＮエッジ・サーバ及びインターフェースを実行中であり以前に同じコンテンツをダウンロードした他のエンド・ユーザの両方から、ダウンロードすることを意味する。

上述したタイプのオーバーレイ・ネットワークは、ネットワーク内のサーバから、ビデオ・ストリームを受信してこれをスクリーン上で再生するクライアントへと、ＨＴＴＰベースのストリーミングを提供する。クライアントは、デスクトップ・コンピュータ、モバイル・デバイス（スマートフォン、タブレット）、セットトップ・ボックス、スマート・テレビジョン又は電化製品、或いは任意の他のネットワーク接続デバイス上で動作し得るものである。典型的なＨＴＴＰベースのストリーミングを使用するケースでは、クライアントはＤＮＳを介してＩＰアドレスへと名前（例えばＣＤＮホスト名）を解決し、そのアドレスに関連付けられたサーバへのＴＣＰ接続を実行する。確立されると、クライアントは、望ましいコンテンツ、例えばメディア・フラグメントについてのＨＴＴＰ ＧＥＴ要求を送信する。サーバは、標準ＨＴＴＰ応答本体内のコンテンツ・データで以て応答する。更なる要求及び応答のために、接続はオープンのまま維持される。

上記をバックグラウンドとして、次に本開示の主題について説明する。

ストリーミング及びダウンロードのためのハイブリットＨＴＴＰ＋ＵＤＰ手法
本開示は、インターネットを介してメディア及び他のコンテンツを配信し、標準ＨＴＴＰベースの配信を置き換えるか又は補足するための新規な手法である。既存の標準ストリーミング及びダウンロード手法との主な相違点は、ＨＴＴＰベース要求及びＵＤＰベース応答の組み合わせである。

図３は、本開示の基本的手法を示す図である。この図で使用される場合、サーバ３００は通信のサーバ側を示し、クライアント３０２はクライアント側を示す。サーバ及びクライアントのコンポーネントは、本開示のＨＴＴＰ要求ＵＤＰ応答機能を実行するように構成されている。この例示のシナリオでは、クライアント３０２は、例えばビデオのフラグメント、ソフトウェア・ダウンロード、又は他のコンテンツ等の注目するコンテンツの所与のバイト範囲について、ＨＴＴＰ ＧＥＴ要求（そのうちの１つが３０４に示されている）を行う。各ＨＴＴＰ要求は、クライアントがＵＤＰ応答を受信できることをサーバ・コードに通知する、ＨＴＴＰヘッダ（又は等価の帯域外データ構造）を含む。図に示されるように、サーバ３００はステップ３０６で、ＨＴＴＰヘッダ及び本体を含むＨＴＴＰ応答で、ＨＴＴＰ ＧＥＴ要求に応答する。しかしながらこの応答は、いくつかの点で従来のＨＴＴＰ応答とは異なる。特に、ＨＴＴＰ応答ヘッダは、サーバがＵＤＰ接続と、オプションで秘密トークンＴ１等のデータ・ストリングとをリスニングする、ＵＤＰ ＩＰ：ポートの識別を含む。しかしながら、ＨＴＴＰ応答本体は空である（すなわち、ＨＴＴＰ ＧＥＴ要求によって要求されたコンテンツを欠いている（含まない））。最初の２つの通信はＴＣＰで行われる。本開示によれば、ＨＴＴＰ本体に含められたであろうコンテンツは、その後、ＵＤＰで、図示された後続のＵＤＰベース接続によって配信される。特にステップ３０８で、ＨＴＴＰ応答を受信したクライアントは、ＨＴＴＰ応答内で識別されるサーバのＵＤＰ ＩＰ：ポートへのＳＹＮを発行する。ＳＹＮは、（セキュリティの目的で）秘密トークンＴ１を含むことができる。ステップ３１０で、サーバは、秘密トークンＴ２を含むＳＹＮＡＣＫをクライアントに戻す。ステップ３１２でクライアントは、秘密トークンＴ２を含むＡＣＫで以て応答する。トークンは、オリジナルのＨＴＴＰ応答を受信しているクライアントのみが、要求されたオリジナル・コンテンツを受信できることを保証する。その後ステップ３１４でサーバは要求されたデータ・パケットで以て応答するが、それはＵＤＰで配信される。

好ましくは、ＨＴＴＰ接続は、（典型的には、同じか又は異なるコンテンツの追加バイト範囲についての）１つ又は複数の追加のＨＴＴＰ要求を受信するためにアライブ状態に保たれ、要求されたコンテンツがこの態様でＵＤＰで配信される。

付随的な改良点は、順方向誤り訂正（ＦＥＣ）又は（ＵＤＰ配信用に）他のパケット符号化を使用することである。

以下で、ハイブリッドＨＴＴＰ／ＵＤＰプロトコルの好ましい実施形態の詳細をさらに説明する。図４は、このハイブリッドＨＴＴＰ／ＵＤＰ接続の初期化及び使用のシナリオを示す。前述のように、ハイブリッド手法は、ＵＤＰプロトコルでコンテンツを伝送するための別のチャネルを追加する点が異なる。本明細書における手法では、クライアント４００は、ＤＮＳ（例えばオーバーレイ・ネットワーク権威ＤＮＳ）を介してＩＰアドレスへと名前を解決し、そのネットワーク内のエッジ・サーバ４０２へのＴＣＰ接続を実行する。確立されると、クライアントはステップ４０４で、所望のコンテンツ、例えばメディア・フラグメントに関するＨＴＴＰ ＧＥＴ要求を送信し、応答本体の転送のためにＵＤＰ接続を使用することを望む旨を示すＨＴＴＰヘッダ（等）を含める。クライアントは、ＵＤＰ配信に関する任意のプリファレンス（例えば、順方向誤り訂正（ＦＥＣ）、又は他のパラメータ）を含めることもできるが、典型的にはそれらに従うか否かの決定はサーバに委ねられている。サーバは、オブジェクトのメタデータ処理のためにＵＤＰプロトコルの使用がイネーブルされたと想定し、ステップ４０６で、空の本体（コンテンツ長：０）回答で以て応答する。応答は、好ましくは、途中のプロキシが応答をキャッシュに入れるのを防ぐための様々なヘッダも含む。応答ヘッダにおいて、クライアントは、ＵＤＰプロトコルによってどのように同じサーバに接続するかに関する情報を（又は、例えばマルチソース・コンテンツ獲得のための、他の追加の代替サーバ参照をも）見つける。この情報は、典型的にはＩＰアドレスを含む（例えば、これまでの接続が明示的プロキシ接続を介するものであった可能性があり、クライアントは通信しているサーバのＩＰアドレスへの可視性を有していない可能性があるため）。戻された情報は、前述のように、ＵＤＰポート番号、オプションで（同じサーバのＵＤＰポート上に多くのこうした接続が存在する場合があるため、通信がいずれのフローに属するかを識別するための）何らかの他の特別ポート番号、バージョン、及びトークンＴをも含む。

この情報がサーバ４０２から受信されると、ＨＴＴＰ応答ヘッダ内に提供された情報（ＩＰアドレス、ＵＤＰポート番号、他のポート番号等）に基づいてＳＹＮ ＵＤＰパケットをサーバに送信することによって、クライアント４００はステップ４０８でＵＤＰ接続を開始する。この要求は、好ましくはＨＴＴＰ応答からのトークンＴも含む。したがってサーバは、トークンを使用して、ＵＤＰパケットを送信しているクライアントが以前のＨＴＴＰ応答を見たこと、及び、かかるＳＹＮパケットが処理されるべきであること（そうでなければ、サーバによって受信されたすべての予期せぬパケットは、送信者に対するいかなる応答もなく静かにドロップされる）を、確認することができる。図に示されるように、ＳＹＮは、好ましくはクライアントの初期シーケンス番号（ＩＳＮ１）をも含む。ステップ４１０でサーバ４０２は、クライアントのＳＹＮパケットからの肯定応答ＩＳＮ１値を含む、ＳＹＮ＿ＡＣＫパケットで以て応答する。ＳＹＮ＿ＡＣＫは、サーバのＩＳＮ値であるＩＳＮ２をも含む。その後クライアントは、ステップ４１２で、サーバのＳＹＮ＿ＡＣＫパケットからの肯定応答ＩＳＮ（すなわちＩＳＮ２）を含み、再びトークンＴをも含むＳＹＮ＿ＡＣＫ＿ＡＣＫパケットによって、ＳＹＮ＿ＡＣＫの受信を確認する。ＩＳＮ及びトークンＴの確認は、両者が通信に参加していること、及び以前のすべてのパケットを見ていることを保証するための手段として働く。トークン（ＨＴＴＰ応答では、ＳＹＮ及びＳＹＮ＿ＡＣＫ＿ＡＣＫパケット）は、この特定のクライアントとサーバとの間で、他のＨＴＴＰ要求のために接続の再使用を容易にする。このようにハンドシェイクが完了すると、ＵＤＰベース接続が確立されたものとみなされ、その後ステップ４１４でサーバは、（場合によってはＦＥＣ符号化された）コンテンツを伴うデータ・パケットの送信を開始する。コンテンツは、ＵＤＰが使用されないならば、オリジナルのＨＴＴＰ応答本体内にあったであろうものと同じである。好ましくは、サーバはデータ・パケットを送り続け、クライアントは肯定応答（ＡＣＫ）で以て応答する。ＡＣＫを使用して輻輳制御を容易にすることが可能である。ハンドシェイク及びデータ配信の間に、クライアントは、（例えばステップ４１６で）ＲＳＴパケット等の何らかの制御メッセージをＴＣＰに同様に送信することも可能である。クライアントは、ＦＥＣが使用される場合には、例えば現行のＦＥＣブロックが適切に復号されたこと、そして次のブロックがサーバによって送信されるべきであることを示す、サーバによって送信される符号化データのフローを制御するための特別なパケットも送信する。

更に図４に示されるように、初期接続の確立及び交換の後、クライアント４００は次のコンテンツを要求することができる。そのため、ステップ４１８でクライアント４００は、次のフラグメントに対するＧＥＴ要求を（例えば同じドメイン名で）発行する。要求は、ＨＴＴＰ要求のための既存のＴＣＰ接続を使用して送信することが可能であり、既存のＵＤＰ接続は応答用に使用される。応答は、ステップ４２０でサーバ４０２から配信される。これで例示のシナリオの説明は完了する。

典型的には、ＵＤＰでのプロトコル接続は、（ＴＣＰでのＨＴＴＰと同様に）一時に１つのセッションのみをサポートする。この手法は接続ごとの明示的多重化を提供しない一方で、多くの接続は同じＵＤＰポートで動作可能であるため、オペレーティング・システムの見地からすると、多重接続のシナリオは多重化の様相を呈する。したがって一実施形態では、複数のＵＤＰポート（スタックごとに１つ）を単一のサーバ上で使用することにより、使用可能ＣＰＵ処理リソースをより良く活用することができる。

好ましくは、要求を満たした後、ＴＣＰ接続（ＨＴＴＰの場合）及びＵＤＰ接続の両方がアライブ状態に保たれる。その後、別のＵＲＬオブジェクトをダウンロードしなければならない場合（例えばストリーム中の次のメディア・フラグメント）、両方の接続が（タイムアウトを介して）依然としてアライブとみなされる場合には再使用される（又は再使用可能である）。好ましくはＴＣＰ及びＵＤＰ接続は、各単一のＨＴＴＰ ＧＥＴ要求に対するものを除いては結合又はバインドされておらず、それぞれが他方に影響を与えることなく閉じることが可能であり、また、それぞれが更なる要求に関して独立に再使用可能である。既存のＵＤＰ接続が再使用されるべきである旨をＨＴＴＰヘッダを介して示す新規のＨＴＴＰ ＧＥＴ要求がＴＣＰ接続を介して送信されると、サーバは、ＴＣＰでＨＴＴＰ（空）応答を送信すること、及び、既存のＵＤＰ接続で要求されたオブジェクトの本体を送信することの両方によって、即時に応答する。

新規フラグメントに対する新規ＵＤＰパケットを処理する前に、（ＦＥＣ符号化データが使用される場合）当該プロトコルで入ってくるＦＥＣ符号化データを復号するために必要なすべての詳細を完全なＨＴＴＰ応答が含むため、クライアントは典型的には、第１にこの完全なＨＴＴＰ応答を取得しなければならない。現行のデータ転送が完了する前に、新規のＨＴＴＰ ＧＥＴ要求を送信すること（及び、データ転送のために既存の接続の再使用を要求すること）も可能である。これによって既存の転送を中止し、新規要求が即時に満たされることになる。このプロトコルに準拠するあらゆるデータ・パケットが、「属している」ＨＴＴＰ応答のＩＤを含むため、各サイドからの特別な確認は必要なく、したがって新規ＨＴＴＰ要求に属するデータ・パケットはクライアントによって容易に識別される。

好ましくは、ＨＴＴＰ／１．１の要件に適合するトランスポートＨＴＴＰヘッダ値を介して、プロトコル特有の情報がサーバとクライアントとの間で交換される。（プロトコルのインプリメントが実行可能なクライアントからの）クライアントＨＴＴＰ要求に、特別なユーザ・エージェント（ＵＡ）ストリングを含めることもできる。前述のように、プロトコルが使用されることになる場合、サーバからのＨＴＴＰ応答は空の本体を含み、接続をどのように行う（又は再使用する）かについての詳細を備えた追加のトランスポート・ヘッダを有する。より具体的に言えば、サーバはトランスポート・ヘッダを解析し、以下の１つを送信することによって、要求に応答する。すなわち、ハイブリッド・プロトコルが使用される（そして、ヘッダが接続エンドポイント及びトークン詳細を含む）場合の、ＨＴＴＰステータス・コード２０２を伴うＨＴＴＰ応答、プロトコルが使用される（そして、上記ヘッダがエンドポイント及びトークン・キーを含まない、つまり、要求ヘッダでクライアントが要求する通り、既存のプロトコル接続が再使用されることになる）場合の、ステータス・コード２０２を伴うＨＴＴＰ応答、又は、当該プロトコルが使用されない場合、すなわち、サーバはＨＴＴＰ規格に従って挙動することになり、当該プロトコルを識別するトランスポート・ヘッダが存在しないかのように応答がリソース・データを本体内に含む場合に使用することになる、任意のステータス・コードを伴うＨＴＴＰ応答、のうちの何れかである２０２の応答コードのどちらの場合も、応答はプロキシ・サーバによるキャッシングが不可能であり、３番目は（通常のサーバ・メタデータ設定によって制御される通りに）キャッシュ可能である。（ＨＴＴＰ２０２応答において）サーバによって課せられるアンチキャッシング・ヘッダは、例えば、Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ、Ｃａｃｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ、ｍｕｓｔ−ｒｅｖａｌｉｄａｔｅ、Ｄａｔｅ、Ｅｘｐｉｒｅｓ、Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｓｔｏｒｅ、ｎｏ−ｃａｃｈｅ、ｍａｘ−ａｇｅ＝０、及びＶａｒｙ：“^＊”を含む。

トークンはオプションである。３２桁の１６進数として表される１２８ビットの符号なし整数とすることができる。エンドポイントは、その存在が、コンテンツを受信するために（当該プロトコルでの）新規接続を確立すべきである旨をクライアントに示すキーである。エンドポイントのフォーマットは、［ＩＰ＿ａｄｄｒｅｓｓ］−［ＵＤＰ＿ｐｏｒｔ＿ｎｕｍｂｅｒ］−［ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ＿ｎｕｍｂｅｒ］とすることができる。

変形実施形態において、ＵＤＰ配信はマルチキャストＵＤＰとすることができる。この変形では、クライアントはサーバに対してＨＴＴＰ要求を実行し、ＨＴＴＰサーバは、以前に説明したように空の本体を含む応答で以て応答する。ＨＴＴＰ応答はハイブリッド・プロトコル用のトランスポート・ヘッダをも含み、この場合ヘッダは、マルチキャスト・グループ・アドレスを含む。その後、クライアントはマルチキャスト・グループに加入し、要求されたコンテンツを受信する。マルチキャスト・グループに加入すること及びマルチキャストＵＤＰパケットを受信することは、（オプションとして）ネイティブＩＰマルチキャストがサポートされていないネットワーク内でのクライアントのための自動マルチキャスト・トンネリング（ＡＭＴ）によって、容易に可能である。コンテンツが受信されると、クライアントはマルチキャスト・グループを離れることができる。多くのクライアントによる同じファイル（ストリームのセグメントである可能性がある）に関する任意数の要求を、同じマルチキャスト・グループを介して満たすことが可能である。これを可能にするために、サーバはファイルのデータをマルチキャスト・グループに送信する。好ましくは、データはＦＥＣ符号化されて送信される。したがって、例えばファイルのサイズが１ＭＢの場合、サーバは、何らかの事前に構成された時間に、事前に構成された速度で、（クライアントによるファイルの復号に有用な）ファイルのデータに関する情報を含むＦＥＣパケットを送り続ける。例えばサーバは、何らかの定義済み期間に、１ＭＢファイルを８Ｍｂｐｓ（すなわち毎秒１ＭＢ）で送信することができる。この期間に、同じファイルを要求するすべてのクライアントが同じマルチキャスト・グループを使用する。この手法によりリソースが節約され、マルチキャストで単一のコピーを送信することで、多くの受信者への人気コンテンツの配信（ライブ・ストリーム又はソフトウェア更新）をサポートすることができる。ファイルがマルチキャスト・グループに送信されている時間は、クライアントによるファイルに対する需要に基づいて動的に拡張可能である。すなわちファイルに対する要求が存在する限り、サーバはマルチキャスト・チャネルへの送信を継続する。クライアントはいつでもマルチキャスト・グループに加入可能であり、ＦＥＣ符号化によってオリジナル・ファイルを復号するための十分なデータを受信するのに必要な限りで加入すればよい。最適化として、サーバは複数のマルチキャスト・グループで同じファイルのコンテンツを並行して送信してよく、クライアントがそれらのうちの複数（すべて、オリジナルのＨＴＴＰ応答のヘッダで戻されることになる）に加入することにより、（ＦＥＣは複数ソースからのデータを容易に組み合わせることが可能であるため）それらのダウンロード容量をより多く利用すること、及びファイルをより速く受信することができる。

理解されるように、この手法は、（ハイブリッドＨＴＴＰ−ＵＤＰプロトコルを使用するように構成された）クライアントが（プロトコルを使用するように構成された）サーバに対してＨＴＴＰ要求を行うことによって動作し、次いでサーバは、ＵＤＰでメディア又はファイル・コンテンツをＨＴＴＰ要求の応答として戻す。この手法によってプロバイダは、アクセス制御、認証、ＱｏＳ報告、ＧＥＯロケーション、及びＨＴＴＰベースのウェブ・サーバに組み込まれた他の特性を含む、ＨＴＴＰが利用可能な標準ＣＤＮインフラストラクチャを使用又は活用可能にする一方で、ＵＤＰ上でのメディア又はファイル・データ伝送の完全な制御を提供することができる。後者は、制限なしに、たとえ（パケット損失及び待ち時間等の）ネットワーキング特性が最適でない場合であっても、より良い体験及び制御を提供するための、カスタム輻輳制御手法及び／又は（前述のような）順方向誤り訂正等のパケットの符号化を含む。したがってこうしたケースでは、この手法は、従来のダウンロード及びストリーミング・ソリューションからのＨＴＴＰの既存の特徴を使用する利点と、ＵＤＰベースのデータ伝送の利点とを組み合わせる。ハイブリッド手法は、何が伝送されることになるかを制御するために既存のＨＴＴＰベース・ソリューションを使用すると同時に、メディア又は他のコンテンツのためにＵＤＰベースのデータ伝送を使用することから恩恵を受けるため、非常に有利である。ＵＤＰ通信が不可能な場合、あらゆるクライアントがデータを受信できることを保証するために、要求及び応答の両方について標準ＨＴＴＰが使用される。ＵＤＰに対するサポートはＨＴＴＰによって送られる。

アプリケーション及びサーバがこの手法を直接使用することができるが、あるいはプロキシを使用してこの機能に対するサポートを追加することができる。例えば、ストリーミング・アプリケーション又は（ダウンロード用の）ブラウザは、ＨＴＴＰのみによってプロキシへ、又はプロキシを通じて要求を行うことが可能であり、次いでプロキシは、サーバと通信する際にこの手法を使用する。好ましくは、クライアント対プロキシ通信はＨＴＴＰのみであるが、プロキシは、ハイブリッドであるＨＴＴＰ及びＵＤＰベース・プロトコルによってサーバと通信する。同様に、ウェブ・サーバはプロキシを（トランスペアレントに又は明示的に）使用して、この手法に対するサポートを追加することができる。

ストリーミングでは、この手法が任意の既存のＨＴＴＰベース・ストリーミング技術を用いて良好に動作するという点で、追加の恩恵が存在する。

より一般的には、本明細書で説明した手法は、サーバからクライアントへのＨＴＴＰストリーミングが必要な場合は必ずインプリメント可能である。クライアントとは、ビデオ・ストリームを受信してこれを画面で再生する側を指す。クライアントは、デスクトップ・コンピュータ、モバイル・デバイス（スマートフォン、タブレット等）、セットトップ・ボックス、スマート・テレビジョン、又は任意の他の接続されたデバイス上で、動作可能である。サーバは、ストリーム・データをクライアントに向けて送信する側である。本明細書で言及される場合、ＨＴＴＰベース・ストリーミングは、ストリームを構築して再生するためにオブジェクトを要求及びダウンロードする際にＨＴＴＰプロトコルのみを使用する、任意のビデオ・ストリーミングを指す。非限定的な例には、Ａｐｐｌｅ ＨＬＳ、Ａｄｏｂｅ ＨＤＳ、Ｍｉｃｒｏｓｏｆｔ ＳｍｏｏｔｈＳｔｒｅａｍｉｎｇ、及びＭＰＥＧ−ＤＡＳＨが含まれる。本明細書の手法を使用して、例えばＨ．２６４ビデオ・エレメンタリ・ストリームやＡＡＣオーディオ・エレメンタリ・ストリームで構成されるプログラム・ストリームを含む、ＭＰＥＧ−２トランスポート・ストリーム等の、ライブ及びオンデマンド・ストリーミングをサポートすることができる。無論この例は、限定的であるものとは意図されていない。

本明細書に記載されたＨＴＴＰ／ＵＤＰハイブリッド配信手法は、ビデオ・ストリーミングの品質を向上させる。この手法は、既存のＨＴＴＰベース・ストリーミング・ソリューションにトランスペアレントに適合可能である。ハイブリッド手法は、メディア・データ転送についてパケット損失及び待ち時間の悪影響を大幅に削減するため、ストリーミング品質を大幅に向上させる。

本明細書に記載された技術のクライアント部分は、１つ又は複数のプラットフォーム（例えばｉＯＳ、Ａｎｄｒｏｉｄ等）のためのソフトウェア開発キット（ＳＤＫ）としてインプリメント可能であり、ＳＤＫをプラットフォーム上のアプリケーションで使用することにより、互換性のあるモバイル・アプリがハイブリッドＨＴＴＰ／ＵＤＰ手法を使用してコンテンツをダウンロード／ストリーミングできるようにすることが可能である。したがって、アプリケーションは、例えばＳＤＫを使用してそのＡＰＩを介してＵＲＬオブジェクトをダウンロードするか、又は、ＳＤＫによって作成されたローカルＨＴＴＰサーバを使用してストリーミング／ダウンロードするかの、いずれかが可能である。

ハイブリッド・プロトコルは、特にＦＥＣベースＵＤＰ配信や高度な輻輳制御技術等の他の技術と結合された場合に、著しい利点を提供する。ＦＥＣは、冗長性を利用することによってパケット損失を克服する周知の技法である。ＦＥＣでは、オリジナルのパケット・フロー（各パケットがデータ片を表す）を送信する代わりに、送信者がデータを新規のパケット・セット（各パケットは、オリジナル・データの様々な部分に関する情報を追加のパリティ・データと共に保持する）に符号化する。新規セットのサイズは、一般にオリジナル・データよりも大きい。符号化されたデータの受信者は復号を実行し、十分な符号化パケットを受信すると、オリジナル・データを再構成する。データを再構成するためには、通常、オリジナル・データ・サイズと同じか又はわずかに多い量の符号化データのみを受信すればよい。このため、転送が多くの損失を伴うものであっても、データを再伝送する必要なしに、オリジナル・データを復号することが可能である。様々な損失レート及びアプリケーションに適した、様々なＦＥＣコードが存在する。ＩＥＴＦ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐでは、コンテンツの信頼性のある配信に使用するための３つのＦＥＣスキーム、すなわち、ＲａｐｔｏｒＱ（ＲＦＣ６３３０に記載）、低密度パリティ・チェック（ＬＤＰＣ）（ＲＦＣ５１７０に記載）、及び、リードソロモン（ＲＦＣ５５１０に記載）を指定している。他の既知のＦＥＣ技法としては、ＲａｐｔｏｒＱの旧バージョンであるＲａｐｔｏｒ Ｒ１０（ＲＦＣ５０５３に記載）がある。Ａｋａｍｉ（登録商標） ＦａｓｔＴＣＰ（商標）等の輻輳制御スキームを適合させて、サーバからクライアントに送信されるデータ・パケットについてのカスタム輻輳制御を容易にするのに用いてよい。一般に、この既知のスキームはキューイング遅延を使用してネットワーク輻輳を測定する。送信者側では、輻輳ウィンドウ（ＣＷＮＤ）を使用して、送信するバイト数を制御する。最初にこのスキームに従い、ＣＷＮＤは伝送遅延に合わせて迅速に増大し、次いで（パスに沿ってパケットがキューイングされる際の）キューイング遅延の変動に合わせてやや消極的に調整される。送信者は、ネットワーク変化に適合するようにそのＣＷＮＤを調整する。

本明細書に記載された技法は、標準ＴＣＰ又は複数の並行ＴＣＰ接続に比べて、ランダム環境（非輻輳）損失及び高待ち時間の下でのトータル・スループットを向上させる。この技法は、より正確な帯域幅推定及び高度な輻輳検出を介して、スループットの安定性を向上させる。更にこの技法は、起動時間の削減、量及び持続時間の再バッファリング・イベントの削減、並びに、ビットレート切り替え頻度の削減も提供する。上記はすべて、閲覧時間をより長くし、ユーザ体験をより良くすることにつながる。記載された技法は、ストリーミングに標準ＨＴＴＰ手法を使用する、円滑なフェイルバック・モードも提供する。

変形として、配信のＵＤＰベース部分は、マルチパスを介して実施可能である。一般に、マルチパスは、複数のソース（例えば、複数のエッジ・サーバ、エンド・ユーザ・ピア等）からの並行したダウンロードを示す。マルチパスは、同じサーバ（又はピア）が、ネットワーク内の異なるパスを介し並行して複数回ダウンロードするために使用されるシナリオをも指す。こうしたスキームは、ＦＥＣがいかなる調停も無しに多くのソースからのデータを組み合わせることができるため、ＦＥＣ符号化がインプリメントされる際に有用である可能性がある。ある環境では、複数のソースからの並行したダウンロード（及び、性能に応じてそれらのソースを動的に変更すること）は、ＵＤＰフェーズについてインプリメント可能である。

代表的なインプリメントにおいて、本機能は、プロセッサによって実行されるコンピュータ・プログラム命令としてソフトウェア内にインプリメントされる。

より一般的には、本明細書で記載された技術は、一緒になって上述の機能を容易にし又は提供する、一連の１つ以上のコンピュータ関連のエンティティ（システム、マシーン、プロセス、プログラム、ライブラリ、機能等）を用いて提供される。典型的な実施形態においては、ソフトウェアが実行される代表的なマシーンは、コモディティ・ハードウェア、オペレーティング・システム、アプリケーション・ランタイム環境、及び一連のアプリケーション又はプロセス、並びに関連データであって、所与のシステム又はサブシステムを提供するものから成る。既述の通り、機能はスタンドアロン・マシーンの形態でインプリメントされてもよいし、或いは一連の分散されたマシーンにわたってインプリメントされてもよい。機能はサービス、例えばＳａａＳソリューションとして提供されてもよい。

上記は本発明のいくつかの実施形態によって実行される動作の特定の順序を記載したが、代替的な実施形態では、異なる順序での動作の実行、いくつかの動作の組み合わせ、いくつかの動作の重複等があり得るから、このような順序は例示的なものであることは理解されよう。本明細書における所与の実施形態の参照は、記載する実施形態が特定の特性、構造、又は特徴を含む場合があるが、全ての実施形態がその特定の特性、構造、又は特徴を必ずしも含むものではないことを示している。

開示した主題は、方法又はプロセスに照らして記載したが、主題の開示は本明細書における動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築してもよく、又はコンピュータに記憶したコンピュータ・プログラムによって選択的に活性化又は再構成される汎用コンピュータを含んでもよい。そのようなコンピュータ・プログラムは、限定ではないが、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクを含むいずれかのタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気もしくは光カード、又は電子命令の記憶に適したいずれかのタイプの媒体等のコンピュータ読み取り可能記憶媒体に記憶することができ、その各々はコンピュータ・システム・バスに結合される。

システムの所与のコンポーネントを別個に記載したが、それらの機能のいくつかは、所与の命令、プログラム・シーケンス、コード部分等において組み合わせるか共有することが可能であることは当業者には認められよう。

これは限定ではないが、特定の機能の一部はオペレーティング・システム等に内蔵できるから、機能はアプリケーション層ソリューションの形態でインプリメントされるのが好ましい。

機能はまた、ＨＴＴＰＳ等の、ＨＴＴＰ以外の他のアプリケーション層プロトコル、又は類似の動作特性を有する他のプロトコルによってインプリメントされてもよい。

一般化すると、接続のクライアント側又はサーバ側をインプリメントし得るコンピューティング・エンティティのタイプに限定はない。いかなるコンピューティング・エンティティ（システム、マシーン、デバイス、プログラム、プロセス、ユーティリティ等）であっても、クライアント又はサーバとしての機能を果たすことができる。

Claims (13)

1. データ配信の方法であって、
   ハードウェア・プラットフォーム上で動作するサーバで、
   クライアントから、コンテンツ・オブジェクトを識別するＨＴＴＰ要求であって、当該ＨＴＴＰ要求への応答本体の転送のためにはＵＤＰ接続を使用することを当該クライアントが望む旨を示すＨＴＴＰ要求ヘッダを含むＨＴＴＰ要求を受信すること、
   前記サーバに関連付けられたＩＰアドレス及びポート番号を識別するヘッダと前記要求されたコンテンツ・オブジェクトを欠いた応答本体とを含む前記ＨＴＴＰ要求に対する応答を戻すこと、
   前記ＩＰアドレス及びポート番号に差し向けられたＵＤＰ要求を前記クライアントから受信すること、及び、
   前記ＨＴＴＰ要求で識別されたが、前記ＨＴＴＰ要求に対する前記応答本体では戻されなかった前記コンテンツ・オブジェクトを含む、前記ＵＤＰ要求に対する応答を戻すこと、
   を含む、方法。
2. 前記クライアントと前記サーバとの間の永続型ＨＴＴＰ接続を維持すること、
   を更に含む、請求項１に記載の方法。
3. 少なくとも１つの追加のＨＴＴＰ要求を前記クライアントから受信すること、及び、
   前記少なくとも１つの追加のＨＴＴＰ要求に対するＵＤＰベースの応答を戻すこと、
   を更に含む、請求項２に記載の方法。
4. 前記ヘッダはセキュリティ・トークンをも含む、請求項１に記載の方法。
5. 前記ＵＤＰ要求に対する前記応答を戻すことに先立ち、前記サーバは、前記ＵＤＰ要求が前記セキュリティ・トークンをも含むことを確認する、請求項４に記載の方法。
6. 前記ヘッダは、前記サーバと前記クライアントとの間の１つまたは複数のプロキシが前記ＨＴＴＰ要求に対する前記応答をキャッシングするのを防ぐための情報も含む、請求項１に記載の方法。
7. プロセッサと、
   コンピュータ・プログラム命令を保持するコンピュータ・メモリとを備え、
   前記コンピュータ・プログラム命令は、
   クライアントから、コンテンツ・オブジェクトを識別する、第１のトランスポート・プロトコルで配信される要求であって、当該要求への応答本体の転送のためには第２のトランスポート・プロトコルでの接続を使用することを当該クライアントが望む旨を示す第１のトランスポート・プロトコルの要求ヘッダを含む要求を受信するためのプログラム・コードと、
   前記要求に対する応答を戻すためのプログラム・コードであって、前記応答は前記第１のトランスポート・プロトコルで配信される、プログラム・コードとを含み、
   前記応答は、前記要求されたコンテンツ・オブジェクトの代わりに空の応答本体と、少なくとも第１及び第２の情報を含むトランスポート・ヘッダとを含むものであり、前記第１の情報は、前記コンテンツ・オブジェクトが前記第１のトランスポート・プロトコルとは異なる第２のトランスポート・プロトコルで取得可能なアドレスを識別するためのものであり、前記第２の情報は、前記要求を発行した前記クライアントによって前記要求が受信されたことを後で確認する際に使用するためのものであり、
   更に、前記第２のトランスポート・プロトコルで配信された前記第２の情報を含む要求を前記アドレスで受信したことに応答するプログラム・コードであって、前記第２のトランスポート・プロトコルで配信された要求に応答して、前記第１のトランスポート・プロトコルで配信された前記応答では戻されなかった前記コンテンツ・オブジェクトを戻すプログラム・コードを含む、装置。
8. 前記第１のトランスポート・プロトコルはＨＴＴＰであり、前記第２のトランスポート・プロトコルはユニキャスト及びマルチキャストのうちのどちらかのＵＤＰである、請求項７に記載の装置。
9. 前記コンテンツ・オブジェクトは、順方向誤り訂正（ＦＥＣ）符号化スキームに従って戻される、請求項７に記載の装置。
   
10. 前記アドレスは、マルチキャスト・グループ・アドレス及びマルチキャスト・グループ・アドレスのセットのどちらかある、請求項７に記載の装置。
11. サービス・プロバイダがＨＴＴＰベース・ストリーミングを使用してエッジ・サーバからビデオ配信を提供する、マルチテナント・オーバーレイ・ネットワーク環境で動作可能なシステムであって、
    ハードウェア・プロセッサで実行されるサーバ側プログラム・コードを含む第１の機械と、
    ハードウェア・プロセッサで実行されるクライアント側プログラム・コードを含む第２の機械と、
    を備え、
    前記第１の機械は、
    前記第２の機械から、コンテンツ・オブジェクトを識別するＨＴＴＰ要求であって、当該ＨＴＴＰ要求への応答本体の転送のためにはＵＤＰ接続を使用することを前記第２の機械が望む旨を示すＨＴＴＰ要求ヘッダを含むＨＴＴＰ要求を受信すること、
    前記第１の機械に関連付けられたＩＰアドレス及びポート番号を識別するヘッダと、前記要求されたコンテンツ・オブジェクトを欠いた応答本体とを含む前記ＨＴＴＰ要求に対する応答を戻すこと、
    前記ＩＰアドレス及びポート番号に差し向けられたＵＤＰ要求を受信すること、及び、
    前記ＨＴＴＰ要求で識別された前記コンテンツ・オブジェクトを含む前記ＵＤＰ要求に対する応答を戻すこと、
    を実行するように動作可能であり、
    前記第２の機械は、
    前記第１の機械へ、前記コンテンツ・オブジェクトを識別する前記ＨＴＴＰ要求を送信すること、
    前記第１の機械に関連付けられたＩＰアドレス及びポート番号を識別する前記ヘッダと、前記要求されたコンテンツ・オブジェクトを欠いた前記応答本体とを含む前記ＨＴＴＰ要求に対する前記応答を受信すること、
    前記ＩＰアドレス及びポート番号に差し向けられた前記ＵＤＰ要求を送信すること、及び、
    前記ＨＴＴＰ要求で識別されたが、前記ＨＴＴＰ要求に対する前記応答本体では戻されなかった前記コンテンツ・オブジェクトを含む前記ＵＤＰ要求に対する前記応答を、受信すること、
    を実行するように動作可能である、
    システム。
12. 前記ヘッダはセキュリティ・トークンをも含む、請求項１１に記載のシステム。
13. 前記ＵＤＰ要求が前記セキュリティ・トークンを含み、前記サーバ側プログラム・コードが前記ＵＤＰ要求は前記セキュリティ・トークンをも含むことを確認すると、前記サーバ側プログラム・コードは前記ＵＤＰ要求に対する前記応答を戻すようにさらに動作可能である、請求項１２に記載のシステム。