ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3
基本概念について
基本概念について
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

基本概念について

重要な用語

WCCP の概要

WCCP サービスの概要

ACNS ソフトウェアのキャッシングの基本概念

キャッシングとは

キャッシング可能なコンテンツ

ネットワーク プロトコルとキャッシング

ACNS ストリーミング メディアの基本概念

ストリーミング メディア ソリューションの概要

クライアント ブラウザのメディア プレーヤーの起動方法

クライアントのメディア プレーヤーが要求を出す方法

ストリーミング メディア キャッシングにおけるキャッシング ポリシーの概要

IP マルチキャスティングの基本概念

安全に問題のあるサービス

サーバとクライアント間のファイルのコピー

限定スコープ アドレス

ソース固有マルチキャスト アドレス

GLOP アドレス

レイヤ 2 マルチキャスト アドレス

基本概念について

この章では、スタンドアロン Content Engine を設定する前に理解しておくべき重要な基本概念の概要を説明します。

この章の構成は、次のとおりです。

「重要な用語」

「WCCP の概要」

「ACNS ソフトウェアのキャッシングの基本概念」

「ACNS ストリーミング メディアの基本概念」

重要な用語

表2-1 では、キャッシングとストリーミングで一般的に使用されるいくつかの重要な用語について説明します。

 

表2-1 重要な用語

用語
定義
コンテンツ関連の用語用語
 

コンテンツ配信

ACNS 5.x のネットワークでコンテンツを配信するために使用される方式。スタンドアロン Content Engine を使用して、2 つの配信方式がサポートされています(プル配信と事前ローディング)。この表にある事前ローディングとプル配信に関する説明を参照してください。

コンテンツの新鮮度

キャッシュされたコンテンツの新鮮度。つまり、コンテンツが Content Engine にキャッシュされてから、オリジン サーバ上でコンテンツが更新されたかどうかを示します。ユーザがオンデマンド コンテンツを要求すると、Content Engine はキャッシュされたオブジェクトが「最新のもの」であるかどうかをチェックしてから(つまりコンテンツがローカルにキャッシュされた後で、オリジン サーバ上のコンテンツが更新されているかどうかをチェックしてから)、コンテンツをクライアントに配信します。Content Engine がコンテンツをキャッシュして以来、コンテンツが変更されていない場合、Content Engine はクライアントにキャッシュされたコンテンツを送信します。コンテンツがキャッシュされた後に変更されている場合、Content Engine はコピーをオリジン サーバから取得し、最新のコンテンツをキャッシュし、最新のキャッシュされたコンテンツをクライアントに送信します。

キャッシュを更新する設定方法については、「HTTP キャッシュ新鮮度の設定」を参照してください。

事前ローディング

スタンドアロン Content Engine が特定のコンテンツを取得し、それ以後の要求を予測して、保管するコンテンツ配信方式。「スタンドアロン Content Engine のコンテンツ事前ローディングの設定」を参照してください。Content Distribution Manager に登録されている Content Engine は、コンテンツ配信方式として、事前配信をサポートします。スタンドアロン Content Engine は事前配信をサポートしません。

コンテンツの事前配置については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。

プル配信

ユーザの要求(クライアントがトリガーした要求)によりコンテンツが取得され、Content Engine 上でキャッシュされるコンテンツ配信方式。同一コンテンツに対するそれ以後の要求は、ローカルのキャッシュから配信されます。このタイプのキャッシングをデマンドプル キャッシングと言います呼ばれます。

要求

コンテンツを取得するためのデバイス(クライアント)からの通信。

Web オブジェクト

Web 上で転送可能なオブジェクト(たとえば、Web ページ)。テキスト オブジェクトおよびバイナリ オブジェクト全般を意味する用語。テキスト オブジェクトは HTML ページです。バイナリ オブジェクトは、テキスト オブジェクト以外の Web オブジェクトです(たとえば、GIF および JPEG)。

キャッシング関連用語
 

キャッシング

以後の検索に備えて Web オブジェクトを保管する機能。

キャッシュ ヒット

要求されたコンテンツ(Web オブジェクト)が、Content Engine のキャッシュにある場合のこと。

キャッシュ ミス

要求されたコンテンツ(Web オブジェクト)が、Content Engine のキャッシュにない場合のこと。

ライブ コンテンツ

オリジン サーバからブロードキャストされるコンテンツ ストリーム(一般的には、ストリーミング メディア)。詳細な定義については、 表1-2 を参照してください。

オンデマンド コンテンツ

ユーザの要求(クライアントがトリガした要求)により獲得され、キャッシュされ、そして配信されるコンテンツ。オンデマンド コンテンツは、プル配信を介して獲得され、Content Engine のローカルにキャッシュされます。プル配信方式は、各種キャッシング サービス(たとえば、リバース プロキシ キャッシング、HTTP プロキシ キャッシング、HTTP 透過プロキシ キャッシング、RealMedia プロキシ キャッシングおよび RealMedia 透過キャッシング)で使用されます。一方、コンテンツは Content Engine 上に、事前ロード オペレーションの結果として、キャッシュされます。オンデマンド コンテンツ定義の詳細については、 表1-2 を参照してください。

事前ロード コンテンツ

特定のコンテンツに対するユーザ要求を予測してそのコンテンツ(事前ロード オペレーション)の取得をスケジュールすることにより、スタンドアロン Content Engine 上に取得、保管されるコンテンツ。

詳細については、「スタンドアロン Content Engine のコンテンツ事前ローディングの設定」を参照してください。

デバイス関連用語

 

クライアント

Web コンテンツを要求するために、ブラウザまたはメディア プレーヤーを使用しているエンド ユーザ。Web クライアントとも呼ばれます。「スタンドアロン Content Engine がサポートしている Web クライアント」を参照してください。

オリジン サーバ

クライアントが要求したコンテンツを収容するサーバ。このサーバはマスター コンテンツ リポジトリとして働きます。ストリーミング メディアの場合、オリジン サーバはエンコーダからライブ ストリーミングを受信します。これらのストリームは、オリジン ストリーミング サーバからコンテンツを受信するエッジ デバイスとして動作する Content Engine に転送されるか、または「分割」されます。ストリーミング コンテンツ以外の場合、コンテンツが未だローカル キャッシュに保管されていない場合、Content Engine は要求されたコンテンツをオリジン サーバから取得します。

スタンドアロン
Content Engine

ACNS 5.x ソフトウェアを実行していて、スタンドアロン デバイスとして管理するために、意図的に Content Distribution Manager(ある場合)に登録されていない Content Engine。次の方法を使用して、スタンドアロン Content Engine を設定すること、あるいは管理することができます。

Setup ユーティリティ

Content Engine CLI

Content Engine GUI

複数のスタンドアロン Content Engine を配置できます(たとえば、スタンドアロン Content Engine クラスタを配置することもできます)。

このマニュアルでは、スタンドアロン Content Engine をキャッシングおよびストリーミング エンジンとして使用する場合の設定、管理、監視方法について説明します。

Content Distribution Manager に登録されている Content Engine については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。

配置関連用語

 

中央管理による配置

次に示す ACNS ネットワーク デバイスを 1 台またはそれ以上使用して構成される配置。Content Distribution Manager、Content Distribution Manager に登録されている Content Engine、および ACNS 5.x ソフトウェアを実行している Content Router。

そのような配置の設定、保守、および監視に関する情報について、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。

ローカル管理による配置

ACNS 5.x ソフトウェアを実行していて、キャッシングおよびストリーミング エンジンとして設定される Content Engine を 1 台またはそれ以上使用して構成される配置。このマニュアルはこれらのタイプの配置に焦点を合わせています。

PAC ファイル

プロキシ サーバとして特定の Content Engine にクライアント ブラウザを指すために使用されるファイル(プロキシ自動設定)。このファイルは、ご使用のイントラネット内のサーバに置かれていて、クライアント デスクトップ上のブラウザにより、起動時にロードされます。PAC ファイルは、JavaScript で記述されています。直接プロキシ ルーティングを使用して、あるクライアントからの要求を特定の Content Engine に宛先を指示するために直接プロキシ ルーティングを使用する場合に PAC ファイルを使用します。

詳細については、「PAC ファイルを使用したクライアント ブラウザへの直接スタンドアロン Content Engine の指定」を参照してください。

ルーティング関連の用語

 

直接プロキシ ルーティング

クライアント ブラウザまたはメディア プレーヤーを設定して、明示的に特定のフォワード プロキシ サーバ(その Content Engine )を指すルーティングのタイプ。Web クライアントからのコンテンツ要求の宛先は、Content Engine(フォワード プロキシ)に指定されているので、Web クライアントは非透過キャッシング サービスを行うこの Content Engine を指し示すことができます。ちなみに、クライアントの高速化は、このContent Engine 上にキャッシュされているコンテンツにアクセスすることによるものです。

直接プロキシ ルーティングを使用しているときに有効で、サポートされているキャッシング サービス、およびストリーミング サービスのリストについては、 表1-5 を参照してください。

このルーティング方式を使用するクライアントの設定方法については、「直接プロキシ ルーティングを使用可能にするクライアント ブラウザとメディア プレーヤーの設定」を参照してください。

透過
リダイレクト

Web Cache Communication Protocol(WCCP)ルータまたは レイヤ 4 スイッチが透過的にクライアント要求を代行受信し、その要求を Content Engine にリダイレクトするルーティング タイプ。Web クライアントは、WCCP ルータまたはレイヤ 4 スイッチがその要求を Content Engine(透過プロキシ サーバ)にリダイレクトしていることを知りません。

透過リダイレクトが使用されている場合に、サポートされるキャッシングとストリーミング サービスのリストについては、 表1-6 を参照してください。

このルーティング方式の設定方法については、「スタンドアロン Content Engine の透過リダイレクションの設定」を参照してください。

プロキシ サーバ関連用語

 

フォワード プロキシ サーバ

クライアント要求を Content Engine に宛先を指示するために直接プロキシ ルーティングが使用されるため、Web クライアントから直接クライアント要求を受信する Content Engine。「非透過フォワード プロキシ キャッシングの概要」を参照してください。

リバース プロキシ サーバ

Web サーバの高速化のために、リバース プロキシ サービスを実行している Content Engine。特定の Web サーバ(Web サーバ ファーム)から要求されたコンテンツをローカルにキャッシュすることにより、それら少数の Web サーバのためのプロキシとして動作します。「透過リバース プロキシ キャッシングの概要」を参照してください。

透過 プロキシ サーバ

クライアントを高速化するために使用される Content Engine。ローカル キャッシュに保存できるときは常に、要求されたコンテンツをキャッシュすることにより、Web クライアントのプロキシとして動作します。透過リダイレクト(WCCP ルーティングまたはレイヤ 4 スイッチ)が、クライアント要求を Content Engine に宛先を指示するために使用されるルーティング方式になっている場合に使用されます。Web クライアントは、要求が WCCP ルータまたはレイヤ 4 スイッチで代行受信され、Content Engine(透過プロキシ サーバ)にリダイレクトされていることを知りません。「透過フォワード プロキシ キャッシングの概要」を参照してください。

サービス関連用語

 

プロキシ キャッシュサービス

高速化タイプのプロキシ サーバとして、Content Engine を使用する キャッシング サービス。

HTTP、HTTPS、FTP、WMT、および RTSP 要求(フォワード プロキシ サーバまたは透過プロキシ サーバとして機能している Content Engine を使用して)に応答するクライアントの高速化

HTTP または FTP-over-HTTP 要求(リバース プロキシ サーバとして機能している Content Engine を使用して)に応答する Web サーバの高速化

RTSP ストリーミングおよびキャッシングサービス

サポートされる RTSP ストリーミングとキャッシング サービス(たとえば、RealMedia プロキシ キャッシング、RealMedia 透過キャッシング、および RealProxy ライブ分割)。詳細については、「スタンドアロン Content Engine の RealMedia サービスの設定」を参照してください。

サニタイズド ロギング

クライアントの身元を含めない(または故意に不明にした)Web リソース要求のロギング。詳細については、「トランザクション ログのサニタイジング」を参照してください。

トランザクション

クライアントが完了した Web リソースの要求(成功した、または失敗した)。トランザクションの情報は、ACNS ソフトウェアのトランザクション ログに記録されます。詳細については、「スタンドアロン Content Engine 上でのトランザクションのモニタリング」を参照してください。

WCCP

Cisco Web Cache Communication Protocol(WCCP)。透過プロキシ サーバとして機能している Content Engine に対して、コンテンツのためのクライアント要求の透過リダイレクトをサポートするルータと Content Engine により使用されるプロトコル。詳細については、「WCCP の概要」を参照してください。

WMT ストリーミングおよびキャッシングサービス

サポートされる WMT ストリーミングとキャッシング サービス(たとえば、WMT プロキシ キャッシング、WMT 透過キャッシング、および WMT ライブ分割)。詳細については、「スタンドアロン Content Engine 上の WMT ストリーミング メディア サービスの設定」を参照してください。

ストリーミング関連用語

 

RealMedia(RM)形式

RealNetworks ストリーミング メディア ファイルの形式 RealProxy が Content Engine 上で有効になっている場合、スタンドアロン Content Engine は RealMedia コンテンツ(.rm ファイル)を RealMedia Player に配信できます。詳細については、「スタンドアロン Content Engine の RealMedia サービスの設定」を参照してください。

SMIL

Synchronized Multimedia Integration Language。HTML と同じような オープン スタンダードの マークアップ言語。このわかりやすく強力なマークアップ言語を使用すると、複数のクリップを調整することが可能です。また、SMIL を使用すると、複数のクリップを再生する方法、時間、および場所を定義できます。SMIL ファイルはプレゼンテーションの全体のスケジュールを確定します。

RealMedia Player

RealPlayer および RealOne Player などの RealNetworks メディア プレーヤー。スタンドアロン Content Engine は RealMedia Player(直接プロキシ ルーティングまたは透過代行受信のいずれかを使用して)からの要求を受信すると、Content Engine は RealNetworks RTSP プロトコルを使用して、要求された RealMedia コンテンツを RealMedia Player に配信します。要求された RealMedia コンテンツが、ローカル キャッシュ内に保存されていない場合、Content Engine は、要求されたコンテンツをオリジン ストリーミング サーバ(RealNetworks サーバ)から取得します。詳細については、「スタンドアロン Content Engine の RealMedia サービスの設定」を参照してください。

ストリーム分割

クライアントが要求したストリームを提供するためにオリジン サーバからの単一のライブ ストリームをスプリッタで複数のストリームに分割、またはコピーするプロセス。このプロセスは、ストリームがマルチキャストと非マルチキャスト対応の混成ネットワークを通過するときに特に一般的です。スプリッタは、ユニキャストまたはマルチキャストにより着信ストリームを受信して、ユニキャストまたはマルチキャストによりストリームを配信できます。ストリーム分割は、ライブ ストリームまたはスケジュールされた再ブロードキャストに使用することができます。WMT を使用するストリーム分割については、「WMT ライブ ストリームを配信するためのスタンドアロン Content Engine の設定」を参照してください。

WCCP の概要

シスコはルータまたはスイッチがパケットを透過的にネットワーク キャッシュにリダイレクトすることを可能にするために、Cisco IOS ソフトウェアに組み込みの Web Cache Communication Protocol(WCCP)を開発しました。スタンドアロン Content Engine を使用する環境では、WCCP はルータとスタンドアロン Content Engine 間の通信メカニズムとして動作します。


) WCCP は リダイレクト ルータではなく、Content Engine(キャッシング デバイス)だけにライセンスされます。WCCP は、ルータまたはスイッチの通常の動作に干渉することはありません。ルータ は、WCCP Version 1 または Version 2 をサポートする Cisco IOS ソフトウェアのバージョンを実行している必要があります。


ルータ上でキャッシング サポートが有効で、Content Engine 上で WCCP サポートが有効になっている場合、デバイスは、それらに設定済みの WCCP 機能およびサービスと通信し、それらを配信することができます。WCCP 対応ルータを使用するには、インターネットに接続されているインターフェイス上で IP アドレスが設定されている必要があります。またインターフェイスが、ネットワーク上の Content Engine から見えなければなりません。

2 つのバージョン(Version 1 および Version 2)WCCP を使用できます。

WCCP Version 1 の機能と制限事項の概要は、次のとおりです。

WCCP 対応ルータ(ホーム ルータ)は 1 台だけ、サポートされます。

単一の WCCP サービス(web-cache サービス[サービス 0])だけがサポートされます。

トラフィック リダイレクトは、ポート 80 でのみサポートされます。

各ホーム ルータは、標準 web-cache サービス(サービス 0 )を最大 32 台の Content Engine に対してサポートできます。

バイパス サポートはありません(たとえば、スタティック バイパス、エラー バイパス、および認証バイパスはサポートされていません)。

戻りに汎用ルーティング カプセル化(GRE)のサポートはありません。

WCCP Version 2 は、広範なサービスと機能のセット(バイパス サポートを含む)と複数の WCCP 対応ルータをサポートしています(WCCP Version 2 の機能とサービスのリストについては、 表6-3 を参照してください)。そのため、WCCP Version 2 の使用をお勧めします。

次のイベント シーケンスでは、WCCP Version 2 を実行するように設定されている Content Engine とルータとの対話について詳細に説明しています。

1. 各 Content Engine がルータのリストを使用して設定されます(「スタンドアロン Content Engine の ルータ リスト の定義」を参照)。

2. 各 Content Engine がその存在と、通信を確立したすべてのルータのリストを告知します。ルータは、グループ内の Content Engine のビュー(リスト)で応答します。

ルータと Content Engine は互いの存在を認識し、管理プロトコルを使用して WCCP サービス グループを形成します。また、Content Engine は、ルータが Content Engine を再認識できるように、定期的に「Here I am」メッセージをルータに送ります。プロトコルは、サービス グループ内のルータのリストをそのメッセージの一部として組み込んで、ビューを正しく表現する必要があります。

3. Content Engine クラスタ内のすべての Content Engine 間で、このビューが一致すると、1 台の Content Engine がリード エンジンとして指定されます。Content Engine のクラスタがある場合、その存在がすべてのルータから認識され、最も小さい IP アドレス番号をもつ Content Engine がリード Content Engine になります。

このリード Content Engine の役割は、Content Engine クラスタ内の Content Engine 間でどのようにトラフィックを割り当てるかを決定します。このリード Content Engine は、WCCP 対応ルータがこのクラスタ内の Content Engine にパケットをリダイレクトするときに固く守らなくてはならないポリシーを設定します。この割り当て情報は、指定された Content Engine からサービス グループ全体に送られます。これにより、そのサービス グループ内のルータはパケットを正しくリダイレクトでき、そのサービス グループ内の Content Engine が負荷をより効率的に管理できます。

HTTP、WMT、または RealMedia 透過キャッシングを WCCP リダイレクトを使用して設定するために Setup ユーティリティを使用する場合、WCCP Version 2 が使用されます。HTTP 透過キャッシング(web-cache サービス)に対して、WCCP Version 1 を使用するためには、Content Engine CLI を使用して、この WCCP サービスを設定する必要があります(「例 1:WCCP Version 1 を使用する web-cache サービスの設定」を参照)。WCCP を使用する透過リダイレクトの設定については、「スタンドアロン Content Engine の透過リダイレクションの設定」を参照してください。

WCCP サービスの概要

ルータが提供する WCCP サービスの一部には、よく知られている基準のセット、および事前に定義されたサービス識別子(たとえば、web-cache サービスはその識別子としてゼロ"0" を使用します。[サービス 0 の場合])があります。このようなサービスの例は、他にも、リバース プロキシ サービス(サービス 99)、http-cache サービス(サービス 70)、および RTSP サービス(サービス 80)などがあります。

その他の一般的でないサービスについては、WCCP Version 2 を使用する動的な(ユーザ定義による)WCCP サービス(サービス 90 ~ 97)によりサポート可能です。動的な WCCP サービスを定義する一部として、基準のセット(たとえば、アプリケーション タイプ[HTTP キャッシング、HTTPS キャッシング、またはストリーミング]、ハッシュ パラメータ、パスワード、および重み付けなど)を指定し、Content Engine 上でこのサービスにサービス識別子(サービス 90 ~ 97)を割り当てます。ユーザ定義サービスに対するこの基準を Content Engine に指定できますが、WCCP Version 2 対応のルータでは、特定のサービス識別子(サービス 90 ~ 97)をサポートする必要があります。ユーザ定義による WCCP Version 2 サービスの設定に関する詳細は、「ユーザ定義 WCCP サービスをサポートするためのスタンドアロン Content Engine の設定」を参照してください。

WCCP Version 1 は 1 つの WCCP サービス(web-cache サービス)と単一のルータ(ホーム ルータ)のみをサポートします。WCCP Version 2 だけが ユーザ定義 WCCP サービス(サービス 90 ~ 97)をサポートします。そのため、WCCP Version 2 の使用をお勧めします。これは、WCCP Version 2 が複数のルータに加えて広範な機能とサービス( 表6-3 を参照)のセットをサポートしているためです。

サポートされる WCCP サービスのリストについては、 表B-3 を参照してください。スタンドアロン Content Engine に WCCP サービスを設定するための、Content Engine CLI の使用に関する情報については、「スタンドアロン Content Engine の透過リダイレクションの設定」を参照してください。

ACNS ソフトウェアのキャッシングの基本概念

ここでは、ACNS ソフトウェア キャッシングに関する次の基本概念を説明します。

「キャッシングとは」

「キャッシング可能なコンテンツ」

「ネットワーク プロトコルとキャッシング」

キャッシングとは

キャッシングとは、Web ページなどの Web オブジェクトを以後の検索に備えて保存しておく機能を指します。一般に Web クライアントは、Web ブラウザを使用して Web サーバにオブジェクトを要求します(図2-1 を参照)。

図2-1 基本的な Web 要求

 

それぞれの Web オブジェクトには、固有に定義されたアドレス(URL)があり、このアドレスによって Web ブラウザは、Web オブジェクトを検索できます。この検索の際には、サーバ アドレスは、DNS 空間に存在するものと想定されます。URL アドレスの基本コンポーネントを図2-2 に示します。

図2-2 URL アドレスの基本コンポーネント

 

Web ブラウザを使用するキャッシングを実行するために、ブラウザは Web を見聞きするプロセスの間のより簡便なアクセスのために、ユーザが最近見聞きしたページを保持するようにセットアップ可能なローカル キャッシュを持っています(図2-3 を参照)。たとえば、ブラウザ上で Back ボタンをクリックしたときには、ローカル キャッシングが利用され、直前に表示されていたページが迅速に表示されます。

図2-3 ローカルでのブラウザ キャッシュの設定

 

ローカルでキャッシュを使用しても、キャッシュ本来の利点が得られますが、Content Engine を使用すると、特別のキャッシング機能を多くのユーザが利用できます。

Content Engine が以後の検索に備えて大量の情報を保存しておく機能には、ユーザおよびインターネット トラフィックの両方に対して、全体として次のような重要な利点があります。

Web オブジェクトをユーザに近い場所に保存しておくため、同じコンテンツをネットワーク経由でアクセスする必要がなくなり、ネットワークの輻輳が減少する。

Web ページはローカルに、またはユーザに近い場所に保存されるので、Web ページの表示に必要な時間が短くなる。

サーバが最近配信したコンテンツを再配信する必要がなくなるため、オリジン Web サーバの負荷が減少する。

このシナリオでは、あるユーザが Web オブジェクトを Web サーバから取得しようとします。ローカル ブラウザは、キャッシュ内にページを保存していないので、Web 要求の際のプロキシとしての Content Engine を使用して、オリジン Web サーバに要求を送ります。この配置では、Content Engine は Web クライアントに対するプロキシの役割をし、最初は、Content Engine のキャッシュ内に保存しているオブジェクト中から、このWeb 要求を満たそうとします。

キャッシング可能なコンテンツ

キャッシング可能なコンテンツは、一般的にスタティック アプリケーション データであり、 表2-2 で説明されているようなファイル タイプ、およびファイル拡張子に関連付けることができます。

 

表2-2 キャッシング可能なコンテンツのファイル タイプとファイル拡張子

ファイル タイプ
ファイル拡張子

グラフィック ファイル

gif、jpeg、bmp

圧縮ファイル

zip、gz、tar

文書ファイル

text、txt、pdf

マルチメディア ファイル

avi、mov、mpeg、wav

ネットワーク プロトコルとキャッシング

Web ブラウザと Web サーバ間の対話は、既存の標準アプリケーション層インターネット プロトコルを使用し、そのプロトコルには HTTP、Microsoft Media Server(MMS)プロトコル、および RTSP などがあります。Content Engine は、これらのすべての Web アクセス プロトコルを使用して、Web オブジェクトを Web クライアントに配信できる必要があります。ACNS 5.3.1 ソフトウェアまたはそれ以降を実行している Content Engine が、Web クライアントにコンテンツを供給するために使用するネットワーク プロトコルの記述リストについては、 表B-1 参照してください。

ACNS ストリーミング メディアの基本概念

ここでは、ストリーミング メディア サービスがローカル管理配置の Content Engine 上でどのようにサポートされているかを説明します。また、下記のトピックについて議論します。

「ACNS ストリーミング メディアの基本概念」

「IP マルチキャスティングの基本概念」

サポートされるストリーミング メディア プロトコルのリストについては、 表B-2 を参照してください。スタンドアロン Content Engine 上でメディア サービスを設定する方法については、次の章を参照してください。

「スタンドアロン Content Engine 上の WMT ストリーミング メディア サービスの設定」

「スタンドアロン Content Engine の RealMedia サービスの設定」

Content Distribution Manager に登録されている Content Engine 上で メディア サービスを設定する方法については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。

ストリーミング メディア ソリューションの概要

ストリーミングとは、すべてのメディア パケットを受信し終わる前に、コンテンツにアクセスまたはコンテンツを見ることを可能にする技術です。それに対して、キャッシングは、コンテンツに アクセスする前に、そのコンテンツが完全に受信されていなければなりません。ストリーミング メディアは、ビデオ オンデマンド(VOD)などに代表される、ライブ コンテンツやオンデマンド コンテンツとして配信することができます。

Cisco ACNS ソフトウェアは、数種類のストリーミング メディア ソリューションの形式をサポートしています。その中には WMT(Microsoft Windows Media Technologies)ソリューション、RealNetworks 社の RealMedia ソリューションなどがあります。ACNS 5.3.1 ソフトウェア リリースでは、Windows Media 9 RTSP サーバのサポートが追加されました。サポートされるストリーミング メディア ソリューションのリストについては、 表1-3 を参照してください。

配置できるストリーミング メディア ソリューションのタイプは、Content Engine が、Content Distribution Manager に登録されているか、スタンドアロンContent Engine であるかによって異なります。たとえば、RTSP ベースの Cisco Streaming Engine および Apple QuickTime ソリューションは、スタンドアロン Content Engine でサポートされていません。

RTP および RTSP は両方とも、インターネットにおけるストリーミング メディアのために設計されたインターネット標準プロトコルです。

RTP(RFC-1889)は、ユニキャスト(TCP および UDP)およびマルチキャストの両方を介したマルチメディア データ用のデータ転送プロトコルです。

RTSP は、標準のインターネット ストリーミング制御プロトコル(RFC-2326)です。

RTSP は、アプリケーション レベルのプロトコルで、ビデオやオーディオなど、リアルタイム性をもつストリーミング メディア データの配信を制御します。RTSP は、テキスト ベースのプロトコルで、通常 TCP ポート 554 で動作します。RTSP は、マルチメディアサーバのネットワーク リモート制御として機能し、ストリーミングメディア プロトコルとして広く普及しています。Apple QuickTime、RealProxy、および Cisco Streaming Engine はすべて、RTSP をストリーミング メディア プロトコルとして使用し、RTP をデータ転送プロトコルとして使用するコンテンツ配信方式です。RealNetworks は、この標準 RTSP プロトコルに独自の拡張機能を追加しました(たとえば、RealMedia クライアントと RealNetwork ストリーミングサーバ間の要求および応答)。

IETF 標準の RTP および RTSP プロトコルのサポートは、ACNS 5.1 ソフトウエアまたはそれ以降の一部として含まれています。ただし、ACNS 5.x ソフトウェアを実行する Content Engine で有効にすることができる、次の 2 つのストリーミング メディア 機能には別途ライセンスが必要です。

RealProxy ストリーミング メディア機能は、RealProxy ライセンスが必要です。このトピックに関する詳細は、「RealMedia サービスの設定」を参照してください。

WMT ストリーミング メディア機能は、WMT ライセンスが必要です。スタンドアロン Content Engine の WMT ストリーミング ソリューションの詳細は、「スタンドアロン Content Engine 上の WMT ストリーミング メディア サービスの設定」 を参照してください。


) Content Distribution Manager に登録されている Content Engine のための メディア サービスを設定する方法については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。


図2-4 で示すように、ストリーミング メディア ファイルはネットワークからユーザに送信されるファイルで、そのファイルを受信している間に、ユーザのメディア プレーヤー上で再生されます。ストリーミング メディア ファイルは、データ パケットの連続ストリームとしてリアルタイムに表示されるので、ファイルを表示するための待ち時間を必要としません。このストリーミング方式により、再生前に大量の表示用メディア ファイルを保存したり、そのメディア ファイルにストレージ スペースを割り当てたりする必要がありません。

図2-4 Content Engine を直接プロキシ モードで使用するストリーミング メディア モデル

 

図2-4 では、あるイベント会場の模様が音声と映像の両方で記録されています。この記録は、後で VOD として、またはライブとしてユーザのネットワークに配信される予定です。信号はエンコーダ ソフトウェアとハードウェアでストリーミング可能なファイルに圧縮され、ファイルは、メディア ファイル サーバに送信されます。次にストリーミング メディア サーバはメディア ファイルをライブまたはオンデマンドに基づいて Content Engine に配信します。その後、Content Engine は、要求されたコンテンツを PC または他の電子デバイス上で特定のメディア ソフトウェア(たとえば、Windows Media player など)を実行しているユーザに中継します。

メディア ファイルに対するクライアント要求は、次のルーティング方式を使用して、Content Engine に送信されます。

直接プロキシ ルーティングを使用して、クライアントのメディア プレーヤーは、直接 Content Engine を指すように設定されます。

透過リダイレクトを使用して、WCCP ルータまたはレイヤ 4 スイッチは透過的にメディア ファイルに対するクライアント要求を代行受信し、透過的にその要求を Content Engine にリダイレクトします。

両方のタイプのルーティングでは、Content Engine は常にライブ コンテンツを外部ストリーミング メディア サーバ(Encoder >ストリーミング メディア サーバ> Content Engine)またはエンコーダ(Encoder > Content Engine)から取得します。Content Engine はライブ コンテンツの発信元ではありません。

ブラウザは主に HTTP を使用してコンテンツを取得し、ストリーミング メディア プレーヤーは各種ストリーミング プロトコルを使用して、コンテンツを取得、表示します。たとえば、RealMedia Player は RealNetworks RTSP プロトコルを使用して、音声と映像コンテンツを流し、Windows Media Player は Microsoft MMS プロトコルを使用して、音声と映像コンテンツを流し、QuickTime Player は IETF 標準 RTSP プロトコルを使用して、マルチメディア コンテンツを流します。クライアントのデスクトップ上のメディア プレーヤーは、エンド ユーザが直接起動できます。またクライアント ブラウザが自動的にメディア プレーヤーを起動することもできます。サポートされる Web クライアントのリストについては、 表1-4 を参照してください。

クライアント ブラウザのメディア プレーヤーの起動方法

メディア プレーヤーの起動方法を理解することは重要なことです。これは media-index ファイルと相対リンクがコンテンツ配信ソフトウェアに制限を加えているためで、一般に、ディレクトリ構造が Content Engine 上で保守されている必要があります。

次の 2 つは、クライアント ブラウザがクライアント デスクトップ上で、ストリーミング メディア プレーヤーを起動するための主要な方法です。

Web ページに埋め込まれている JavaScript を使用する場合。

ストリーミング メディア プレーヤーを MIME タイプ関連付けを使用して起動するブラウザの場合。MIME タイプ関連付けは、ブラウザの機能です。特定の MIME タイプ サフィックスをもつオブジェクトが使用されている場合に、ブラウザが特定のアプリケーションを起動できるようにします。デフォルトの関連付けルール セットは、インターネット上の一般的なオブジェクト タイプをカバーしています。ユーザはブラウザの MIME タイプ関連付けルールの編集、追加、削除を行うことができます。たとえば、MIME タイプ関連付けを使用して、クライアント ブラウザは *.pdf ファイルが使用されている場合には、Adobe Acrobat Reader を起動し、*.asf または *.asx ファイルが使用されている場合には、Windows Media Player を起動します。

クライアント ブラウザは、さまざまな状況でクライアント デスクトップ上のメディア プレーヤーを起動できます。たとえば、HTML ページに、ASF 形式でエンコードされたビデオへのリンクが含まれている場合(例を参照)、クライアント ブラウザはこの HTML ページを処理している間に、クライアント デスクトップ上の Windows Media Player を起動し、ファイル wmt_vod/welcome1.asf をサーバ stream-ce50.abc.com から取得します。MMS プロトコルは、Windows Media Player で再生する .asf ファイルを取得するために使用されます。

HTML>
HEAD>
<TITLE>Example Page with a Video/TITLE>
</HEAD>
<BODY>
<A HREF="mms://stream-ce50.abc.com/wmt_vod/welcome1.asf">TEST CLIP</A>
</BODY>
</HTML>
 

クライアント ブラウザがクライアント デスクトップ上のメディア プレーヤーを起動する方法としてより一般的な例は、ビデオとプレゼンテーション素材が、.asx ファイルまたは SMIL(Synchronized Multimedia Integration Language)ファイルのように一つの media-index ファイルにパッケージになっている場合です。WMT ストリーミングが使用する .asx ファイルと RealNetworks RealMedia ストリーミングが使用する SMIL ファイル。一般に、ブラウザは .asx ファイルを取得すると、Windows Media Player を起動し、.asx ファイルをプレーヤーに渡します。同様に、クライアント ブラウザは SMIL ファイルを取得すると、クライアント デスクトップ上で RealMedia Player を起動し、SMIL ファイルをデスクトップ上の RealMedia player に渡します。


) ACNS 5.2.1 ソフトウェア リリースでは、RealProxy のための SMIL ファイルのサポートが追加されました。


メディアインデックス ファイルは、メディア ファイルへの相対リンクまたは絶対リンクを含むことができます。.asf ファイルへの絶対リンクを含む .asx ファイルの例を次に示します。

<!--A simple playlist with entries to be played in sequence.-->
<ASX version = "3.0">
<Title>The Show Title</Title>
<Entry>
<Ref href = "mms://adventure-works.com/Path1/title1.wma" />
</Entry>
<Entry>
<Ref href = "mms://abc-studio.com/Path2/title2.wma" />
</Entry>
<Entry>
<Ref href = "mms://fox-networks.com/Path3/title3.wma" />
</Entry>
</ASX>
 

指定されたシーケンスでは、.asx ファイルは異なる Web サイトにある 3 つのビデオを取得するようにプレーヤーに指示しています。ビデオの完全な URL は、.asx ファイルにリストされています。

SMIL ファイルが相対リンクを含んでいる場合の例を次に示します。SMIL ファイルは、http://www.w3.org/2001/SMIL20/Language/example.xml です。この場合、RealMedia Player は、ビデオ http://www.w3.org/2001/SMIL20/Language/demo.rm を再生するように指示されます。

<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
<body>
<video src="demo.rm"/>
</body>
</smil>

) RealMedia ファイルは、.rm 拡張子(上記の例に示されているように)です。これは、ファイルが RealMedia 形式であることを示しています。


相対リンクの場合、完全な URL は SMIL ファイルの URL パスにある最後のパス コンポーネントを相対リンクに置き換えることにより作成されています。

大部分のメディア プレーヤーは同期化メディアをサポートしています。すなわち、それらはスライド プレゼンテーションを使用して同期を取る音声と映像です。一般に、メディアは同一ディレクトリに置かれ、相対リンクを使用して参照されます。

クライアントのメディア プレーヤーが要求を出す方法

メディア プレーヤーが起動された後、再生するメディア ファイルが渡され、プレーヤーはブラウザの再生手順と同じような手順でメディア ファイルを再生します。

1. メディア プレーヤーはクライアント デスクトップで設定されている DNS 解決サーバを使用して、ストリーミング サーバの IP アドレスを調べます。メディア プレーヤーにプロキシが設定されている場合、メディア プレーヤーは DNS の参照を実行しません。メディア プレーヤーはプロキシに IP アドレスの検索を実行するように要求します。クライアントのブラウザを直接 Content Engine を指すように設定できるのと同じように、クライアントのメディア プレーヤーも直接 Content Engine を指すように設定できます。詳細については、次の項を参照してください。

「WMT MMS 要求に対して Windows Media Player が 直接スタンドアロン Content Engine を指し示すようにするための設定」

「RealMedia Player が直接スタンドアロン Content Engine を指し示すようにするための設定」

2. メディア プレーヤーはメディア サーバとの接続をデフォルト ポート(WMT の場合、ポート 1755、RTSP の場合 ポート 554)、または指定されたポートで確立しようとします。プロキシの場合、メディア プレーヤーはプロキシとの接続を指定されたポートで確立します。

3. メディア プレーヤーとメディア サーバまたはプロキシとの接続が確立されると、メディア プレーヤーは、メディア サーバまたはプロキシとセッションを確立するために情報を交換します。

一般に、メディア プレーヤーがサーバまたはプロキシに送信する最初のパケットには、目的のメディア サーバの IP アドレスまたはサーバのドメインが含まれています。これは HTTP とは異なり、最初のパケットにはドメイン情報だけでなく、オブジェクトの情報も含まれています。WMT および RTSP ストリーミング プロトコルの場合は両方とも、最初のパケットはサーバの情報のみを伝送します。オブジェクトの情報(パス名)は、クライアントのメディア プレーヤーとサーバ間で 2 番目のパケット、または 3 番目のパケットが交換されるまで使用できません。WMT プロトコルを使用する場合、オブジェクト情報は 4 番目のパケット交換後に使用できます。RTSP-over-RTP プロトコルを使用する場合、オブジェクト情報は 3 番目のパケット交換後に使用できます。

RTSP リダイレクト方式

HTTP と同様に、RTSP プロトコルにも「リダイレクト」メッセージがあります。サーバはリダイレクト メッセージを新しい URL を使用するメディア プレーヤーに送信できます。またメディア プレーヤーは新しい URL を再生します。

WMT リダイレクト方式

WMT ストリーミング プロトコルの現行バージョンは、リダイレクトの方法を備えていません。代わりに、より一般的にサーバで使用されている方法は、.asx ファイルを使用してビデオを公開すること、またリダイレクトが必要な場合、.asx ファイルを書き直すことです(ファイル内の参照部分を変更して)。すでに説明してきたように(「クライアント ブラウザのメディア プレーヤーの起動方法」を参照)、.asx ファイルは、メディア プレーヤーに指示を与えて、各種コンテンツ オブジェクトを取得し、ファイル内の参照を書き直すことにより、効果的にメディア プレーヤーを別の URL にリダイレクトします。

ストリーミング メディア キャッシングにおけるキャッシング ポリシーの概要

HTTP キャッシングとは対照的に、ストリーミング メディア キャッシングのキャッシング ポリシーははるかに単純です。これは、ストリーミング メディアはたいてい巨大なスタティック コンテンツであるからです。

WMT キャッシングを使用して、Content Engine GUI または CLI(たとえば、 wmt cache max-obj-size グローバル設定コマンド)を使用して、スタンドアロン Content Engine のキャッシング ポリシーを指定します。すべての応答がキャッシュ可能で、部分的応答も含みます。すべての WMT 要求は、要求がキャッシュにヒットしたとしても、Content Engine はクライアントのためにサーバを使用して、ストリーミング コントロール セッションを確立するしないに関係なく、Content Engine とオリジン サーバ間の通信になります。ストリーミング制御セッションを設定することによって、Content Engine は、キャッシュされたコンテンツが最新のものであり、クライアントがそのコンテンツにアクセスできることを確認できます。ストリーミング オブジェクトは一般にかなり大きいので、サーバとのコントロール セッションの確立に要するオーバーヘッドは無視できます。またキャッシュにヒットさせても帯域幅の使用量を削減しません。

RealProxy キャッシング(RealMedia プロキシ キャッシングと RealMedia 透過キャッシング)を設定するには、RealNetworks RealSystem Administrator GUI を使用して RealProxy キャッシング ポリシーを指定します。このトピックの詳細は、「RealSystem Administrator GUI による RealProxy の設定」を参照してください。

IP マルチキャスティングの基本概念

マルチキャスト配信は、IP マルチキャスト上の異なる受信デバイスが、Content Engine から単一のメディア コンテンツ ストリームを同時に受信できるようにすることにより、ストリーミング メディアの配信を可能にします。これにより、ストリームが要求されるたびに単一のストリームが単一のデバイスに送信されるのでなく、単一のストリームが多数のデバイスに送信されるため、ネットワーク帯域幅の消費量を大幅に節約できます。

このマルチキャスト配信機能を使用するには、同一チャネルからコンテンツを受信するように各デバイスを設定し、これらのデバイスがサブスクライブできる Content Engine 上でマルチキャスト アドレスを設定します。配信側のデバイスは、Content Engine にセットアップされているマルチキャスト アドレスにコンテンツを送信します。このアドレスから、サブスクライブされている受信側のデバイスのすべてにコンテンツが配信されます。

マルチキャストを利用するには、すべてのデバイス(Content Engine、ルータ、およびクライアントを含む)がマルチキャスト対応でなければなりません。このため、マルチキャストは、ルータをマルチキャスト用に設定できるローカル ネットワーク内で最もよく使用されます。インターネット経由でのマルチキャスト配信は、マルチキャストが行われる経路上のすべてのデバイスがマルチキャスト対応になってはじめて可能になります。

IP マルチキャスト アドレスの割り当ては、Internet Assigned Numbers Authority(IANA)によって管理されています。IANA は、IP マルチキャスト用に IPv4 クラス D アドレス スペースを割り当てています。このため、すべての IP マルチキャスト グループ アドレスは、 224.0.0.0 ~ 239.255.255.255 の範囲内にあります。ただし、 ソースとグループ アドレスのいくつかの組み合わせは、マルチキャストには使用できません。使用できないマルチキャスト アドレスの範囲、および使用できない理由のリストについては、「使用できないマルチキャスト アドレスの割り当て」を参照してください。

安全に問題のあるサービス

マルチキャスト アドレスの 224.0.1.2/32、224.0.1.22/32、および 224.0.2.2/32 の範囲を使用するアプリケーションは、悪意の攻撃に弱いことは周知であり、安全性の点で重大な問題があります。

サーバとクライアント間のファイルのコピー

一部のアプリケーションは、サーバとクライアント間のファイルのコピーに使用され、そのほかにもパーソナル コンピュータ間のグループを保守するために使用されます。これらのアプリケーションは、ローカル サブネット上または管理ドメイン内で使用されることを想定していますが、ソフトウェアが使用するデフォルトのアドレスは、表B-8 に示されている管理スコープのアドレスの範囲内に含まれていません。

限定スコープ アドレス

限定スコープ アドレスも管理用スコープのアドレスと呼ばれます。これらの限定アドレスは、RFC 2365 にある「 Administratively Scoped IP Multicast 」にローカルまたは組織に限定するとの記載があります。企業や大学などの組織は、ドメインの外部に転送されないローカル マルチキャスト アプリケーションにこの限定スコープ アドレスを使用できます。通常は、このアドレス範囲内のマルチキャスト トラフィックが自律システム(AS; Autonomous System)、またはユーザ定義のドメインの外部に流出しないように予防するために、フィルタを使用してルータを設定します。自律システムやドメインの内部で、限定スコープ アドレスの範囲をさらに細分化することによって、ローカル マルチキャスト境界を定義できます。この再分割はアドレス スコーピングと呼ばれ、こうした小規模なドメイン間でアドレスの再使用が可能になります。

ソース固有マルチキャスト アドレス

アドレスの 232.0.0.0/8 範囲は、ソース固有マルチキャスト(SSM; source-specific multicast)に予約済みです。SSM は、Protocol-Independent Multicast(PIM)プロトコルを拡張したもので、一対多(one-to-many)通信における効果的なデータ配信メカニズムです。

GLOP アドレス

RFC 2770(GLOP Addressing in 233/8)では、すでに予約済みの AS 番号をもつ組織ごとに静的に定義されるアドレス用に、233.0.0.0/8 のアドレス範囲を予約済みにするように提案されています。この手法は GLOP アドレス指定と呼ばれます。ドメインの AS 番号は、233.0.0.0/8 アドレス範囲の 2 番目と 3 番目のオクテットに埋め込まれます。たとえば、AS 番号 62010 は F23A のように 16 進形式で書き込まれます。これを 2 つのオクテット F2 と 3A に分割すると、10 進形式の 242 と 58 が得られます。これらの値により、サブネット 233.242.58.0/24 が AS 62010 用にグローバルに予約されます。

レイヤ 2 マルチキャスト アドレス

従来、LAN セグメント上のネットワーク インターフェイス カード(NIC; Network Interface Card)は、バーンイン(burned-in)MAC アドレス、またはブロードキャスト MAC アドレスを宛先とするパケットのみを受信できました。IP マルチキャストでは、複数のホストが共通の宛先 MAC アドレスをもつ単一データ ストリームを受信できることが必要です。複数のホストが同じパケットを受信でき、しかも複数のマルチキャスト グループを区別できるような、何らかの方法を考案する必要がありました。

ひとつの方法として、IP マルチキャスト クラス D アドレスを MAC アドレスに直接マップすることがあげられます。現在では、NIC はこの方法を使用してさまざまな MAC アドレス(NIC 固有のユニキャスト アドレス、ブロードキャスト アドレス、およびマルチキャスト アドレスの範囲)を宛先とするパケットを受信できます。

IEEE LAN 仕様では、ブロードキャスト パケットとマルチキャスト パケットの伝送を規定しています。802.3 規格では、最初のオクテットのビット 0 は、ブロードキャストまたはマルチキャストのどちらのフレームであるかを示すために使用されます。図2-5 では、イーサネット フレーム内にあるブロードキャスト、またはマルチキャストのビットの位置を示しています。

図2-5 IEEE 802.3 MAC アドレス形式

 

このビットは、フレームの宛先がネットワーク上のホストのグループ、またはすべてのホスト(ブロードキャスト アドレス 0xFFFF.FFFF.FFFF の場合)であることを示します。

IP マルチキャストでは、IP パケットを LAN セグメント上のホストのグループに送信する際にこの機能が使用されます。


ACNS 5.x Content Engine の MAC アドレス テーブルは 50,000 エントリまでサポートします。


イーサネット MAC アドレスのマッピング

IANA は、16 進形式の 01:00:5E から始まるイーサネット MAC アドレスのブロックを所有しています。このブロックの半分は、マルチキャスト アドレス用に割り当てられています。0100.5e00.0000 ~ 0100.5e7f.ffff の範囲が、IP マルチキャスト用に使用できるイーサネット MAC アドレスの範囲です。

この割り当てにより、イーサネット アドレス内の 23 ビットが IP マルチキャスト グループ アドレスに対応します。IP マルチキャスト グループ アドレスの下位 23 ビットが、イーサネット アドレスに使用されるこれらの 23 ビットにマップされます(図2-6 を参照)。

図2-6 イーサネットまたは FDDI の MAC アドレス マッピングに対する IP マルチキャスト

 

IP マルチキャスト アドレスの上位 5 ビットはこのマッピングで除外されるため、得られるアドレスは固有になりません。実際には、32 の異なるマルチキャスト グループ ID が同じイーサネット アドレスにマップされます(図2-7 を参照)。ネットワーク管理者は、IP マルチキャスト アドレスを割り当てる際にこの点を考慮する必要があります。たとえば、224.1.1.1 と 225.1.1.1 は、レイヤ 2 スイッチ上で同じマルチキャスト MAC アドレスにマップされます。あるユーザがグループ A(224.1.1.1 によって指定)に加入し、他のユーザがグループ B(225.1.1.1 によって指定)に加入した場合、両ユーザとも A と B の両方のストリームを受信します。このような状況では、このマルチキャスト配置の有効性は限られたものになります。

図2-7 MAC アドレスのあいまいさ