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

目次

基本概念について

重要な用語

WCCP の概要

WCCP サービスの概要

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

キャッシングとは

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

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

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

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

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

クライアントのメディア プレーヤーによる要求の発行方法

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

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

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

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

限定スコープ アドレス

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

GLOP アドレス

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

基本概念について

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

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

「重要な用語」

「WCCP の概要」

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

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

重要な用語

表 2-1 では、キャッシングとストリーミングで使用される重要な用語を説明します。

 

表 2-1 重要な用語

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

コンテンツ配信

ACNS ネットワーク内でコンテンツを配信するために使用される方式。スタンドアロン 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.2』を参照してください。

プル配信

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

Request

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

Web オブジェクト

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

キャッシング関連用語
 

キャッシング

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

キャッシュ ヒット

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

キャッシュ ミス

Content Engine のキャッシュ内にはない要求されたコンテンツ(Web オブジェクト)。

ライブ コンテンツ

オリジン サーバからブロードキャストされるコンテンツ ストリーム(一般的には、ストリーミング メディア)。定義内容の詳細は、 表 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(1 台でもあれば) に登録されていない 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.2』を参照してください。

配置関連用語

 

中央管理による配置

次に示す ACNS ネットワーク デバイスを 1 台またはそれ以上使用して構成される配置。Content Distribution Manager、Content Distribution Manager で登録されている Content Engine、および ACNS 5.x ソフトウェアを実行している Content Router。そのような配置を設定、保守、モニタする方法については、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.2』を参照してください。

ローカル管理による配置

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

PAC ファイル

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

ルーティング関連の用語

 

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

クライアント ブラウザまたはメディア プレーヤーを設定して、明示的に特定のフォワード プロキシ サーバ(そのContent Engine)を指すルーティングのタイプ。Web クライアントは彼らのコンテンツ要求が Content Engine(フォワード プロキシ サーバ)に宛先が指示されていることを認識しているので、非透過キャッシング サービス(たとえば、この 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 の RTSP メディア サービスの設定」を参照してください。

サニタイズド ロギング

クライアントの身元を含まない(すなわち、故意に隠す) 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 の RTSP メディア サービスの設定」を参照してください。

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 の RTSP メディア サービスの設定」を参照してください。

ストリーム 分割

クライアントが要求したストリームを提供するためにオリジン サーバからの単一のライブ ストリームをスプリッタで複数のストリームに分割、またはコピーするプロセス。このプロセスは、ストリームがマルチキャストと非マルチキャスト対応の混成ネットワークを通過するときに特に一般的です。スプリッタは、ユニキャストまたはマルチキャストにより着信ストリームを受信して、ユニキャストまたはマルチキャストによりストリームを配信できます。ストリーム分割は、ライブ ストリームまたはスケジュールされた再ブロードキャストに使用することができます。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 から見えなければなりません。

WCCP には、Version 1 と Version 2 の 2 つのバージョンがあります。

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

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

WCCP サービス(web-cache サービス[サービス 0])は 1 つだけサポートされます。

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

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

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

戻りに GRE(Generic Routing Encapsulation)のサポートはありません。

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

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

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

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

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

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 キャッシュ サービスの設定」を参照)。WCCP を使用した透過リダイレクトを設定する方法については、「スタンドアロン Content Engine の透過リダイレクションの設定」 を参照してください。

WCCP サービスの概要

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

よく知られていない他のサービスは、WCCP Version 2 を使用するダイナミック(ユーザ定義)WCCP サービス(サービス 90 ~ 97)によりサポート可能です。ダイナミック WCCP サービスの定義の一部として、基準のセット(たとえば、アプリケーション タイプ[HTTP キャッシング、HTTPS キャッシング、またはストリーミング]、ハッシュ パラメータ、パスワード、重み付け)を指定し、このサービスにサービス識別子(サービス 90 ~ 97)を Content Engine 上で割り当てます。ユーザ定義サービスに対するこの基準を 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 が複数のルータに加えて広範な機能とサービス( 表 5-2 を参照)のセットをサポートするためです。

サポートされる WCCP サービスのリストについては、 表B-3 を参照してください。スタンドアロン Content Engine の場合に Content Engine CLI を使用して、WCCP サービスを設定する方法については、 「スタンドアロン 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 ブラウザ側にローカル キャッシュを用意し、Web 閲覧プロセス中に迅速にアクセスできるように、ユーザが最近閲覧したページをブラウザのキャッシュ内に保存するようにセットアップします(図 2-3 を参照)。たとえば、ブラウザ上で Back ボタンをクリックしたときには、ローカル キャッシングが利用され、直前に表示されていたページが迅速に表示されます。

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

 

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

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

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

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

3. サーバが最近配信したコンテンツを再配信する必要がなくなるため、オリジン 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.2 またはそれ以降)を実行している Content Engine が、コンテンツを Web クライアントに配信するために使用するネットワーク プロトコルの記述リストについては、 表B-1 を参照してください。

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

ここでは、ストリーミング メディア サービスがローカル管理配置の Content Engine 上でどのようにサポートされているかを説明します。この項の構成は次のとおりです。

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

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

サポートされるストリーミング メディア プロトコルのリストについては、 表B-2 を参照してください。スタンドアロン Content Engine 上でメディア サービスを設定する方法については、『中央管理配置に関する Cisico ACNS ソフトウェア コンフィギュレーション ガイド』を参照してください。

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

「スタンドアロンContent Engine の RTSP メディア サービスの設定」

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

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

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

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

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

 

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

Cisco ACNS ソフトウェアは、いくつかのストリーミング メディア ソリューション(Microsoft、RealNeworks、および Apple Computer を含む)をサポートします。サポートされるストリーミング メディア ソリューションのリストについては、 表 1-3 を参照してください。

メディア ファイルに対するクライアント要求は、次のルーティング方式を使用して、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 ソフトウェアでは、RealProxy 用 SMIL ファイルのサポートが追加されました。


media-index ファイルには、メディア ファイルへの相対リンクまたはメディア ファイルへの絶対リンクが含まれています。.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 ファイルはプレーヤーに 3 つのビデオを取得するように指示しています。3 つのビデオは、それぞれ別の Web サイトにあります。ビデオの完全な 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 を指すように設定できます (「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 アドレスをもつ単一データ ストリームを受信できることが必要です。複数のホストが同じパケットを受信でき、しかも複数のマルチキャスト グループを区別できるように、何らかの手段を考慮する必要がありました。

これを実現する方法の 1 つに、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 セグメント上のホストのグループに送信する際にこの機能が使用されます。

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

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

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

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

 

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 アドレスのあいまいさ