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

目次

基本概念について

重要な用語

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 Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

プル配信

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

要求

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

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 に意図的に登録されていない Content Engine。スタンドアロン Content Engine の設定または管理を行うには、以下を使用します。

Setup ユーティリティ

Content Engine CLI

Content Engine GUI

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

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

Content Distribution Manager に登録する Content Engine の詳細については、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

配置関連の用語

中央管理による配置

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

この配置の設定、保守、モニタの詳細は、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

ローカル管理による配置

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 を参照してください。

このルーティング方式の設定方法については、 第 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 をプロキシ サーバとして使用する キャッシング サービス。

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

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

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

サポートされる RTSP ストリーミングとキャッシング サービス(RealMedia プロキシ キャッシング、RealMedia 透過キャッシング、RealProxy ライブ分割など)。詳細は、 第 8 章「スタンドアロン 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 ライブ分割など)。詳細は、 第 9 章「スタンドアロン Content Engine の WMT ストリーミング メディア サービスの設定」 を参照してください。

ストリーミング関連の用語

RealMedia(RM)形式

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

SMIL

Synchronized Multimedia Integration Language。HTML に類似する オープン スタンダードの マークアップ言語。単純かつ高性能なマークアップ言語で、複数のクリップを調整できます。また、SMIL では、複数のクリップを、いつ、どこで、どのように再生するかを定義できます。SMIL ファイルはプレゼンテーションの全体のスケジュールを確定します。

RealMedia Player

RealPlayer および RealOne Player などの RealNetworks メディア プレーヤー。スタンドアロン Content Engine は、(直接プロキシ ルーティングまたは透過代行受信のいずれかにより)RealMedia Player から要求を受信すると、RealNetworks RTSP プロトコルを使用して、要求された RealMedia コンテンツを RealMedia Player に配信します。要求された RealMedia コンテンツが、ローカル キャッシュ内に保存されていない場合、Content Engine は、要求されたコンテンツをオリジン ストリーミング サーバ(RealNetworks サーバ)から取得します。詳細は、 第 8 章「スタンドアロン 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 が、このインターフェイスを識別できる必要があります。

WWCP には、Version 1 および Version 2 の 2 つのバージョンがあります。

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

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

単一のWCCP サービス(web キャッシュ サービス[サービス 0])だけがサポートされます。

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

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

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

応答の場合、Generic Routing Encapsulation(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 は定期的にルータに対して「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 で、より効率的に負荷を管理できます。

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

WCCP サービスの概要

ルータが提供できる WCCP サービスの一部には、既知の基準セットおよび事前定義されたサービス識別子があります(たとえば、web キャッシュ サービスは、[サービス 0] の場合、識別子 [0] を使用します)。他にも、リバースプロキシ サービス(サービス 99)、HTTPS キャッシュ サービス(サービス 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 キャッシュ サービス)と、単一のルータ(ホーム ルータ)だけをサポートします。ユーザ定義 WCCP サービス(サービス 90 ~ 97)をサポートできるのは、WCCP Version 2 だけです。さらに、複数のルータをはじめ、より広範囲の機能セットおよびサービスをサポートできるので( 表6-3 を参照)、WCCP Version 2 の使用を推奨します。

サポート対象の WCCP サービスについては、 表B-3 を参照してください。Content Engine CLI を使用して、スタンドアロン Content Engine に WCCP サービスを設定する方法については、 第 6 章「スタンドアロン Content Engine の透過リダイレクションの設定」 を参照してください。

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

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

「キャッシングの概要」

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

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

キャッシングの概要

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

図2-1 基本的な Web 要求

 

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

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

 

Web ブラウザを使用してキャッシングを実装するには、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.4.1 以降を実行している Content Engine が、Web クライアントへのコンテンツ配信に使用できるネットワーク プロトコルの詳細については、 表B-1 を参照してください。

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

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

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

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

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

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

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

Content Distribution Manager に登録されている Content Engine 上でのメディア サービスの設定方法については、『 Cisco ACNS Software Configuration Guide for Centrally Managed Deployments 』Release 5.4を参照してください。

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

ストリーミングとは、すべてのメディア パケットの受信が完了する前に、コンテンツにアクセスしたり、コンテンツを表示できる技術です。これに対し、キャッシングの場合、コンテンツにアクセスする前にコンテンツ全体を受信する必要があります。ストリーミング メディアは、ビデオ オンデマンド(VOD)などに代表される、ライブ コンテンツやオンデマンド コンテンツとして配信することができます。

Cisco ACNS ソフトウェアは、Microsoft の Windows Media Technologies(WMT)ソリューション、RealNetworks, Inc. の Real Media ソリューションなど、複数のタイプのストリーミング メディア ソリューションをサポートしています。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 クライアントと RealNetworks ストリーミング サーバ間のチャレンジと応答など)を追加しています。

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 Software Configuration Guide for Centrally Managed Deployments』Release 5.4を参照してください。


図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 は常にライブ コンテンツを外部ストリーミング メディア サーバ(エンコーダ >ストリーミング メディア サーバ> Content Engine)またはエンコーダ(エンコーダ > Content Engine)から取得します。Content Engine はライブ コンテンツの発信元ではありません。

ブラウザは主に HTTP を使用してコンテンツを取得し、ストリーミング メディア プレーヤーは各種ストリーミング プロトコルを使用して、コンテンツを取得し、表示します。たとえば、RealMedia Player は RealNetworks RTSP プロトコルを使用してオーディオとビデオ コンテンツを流し、Windows Media Player は Microsoft MMS プロトコルを使用してオーディオとビデオ コンテンツを流し、QuickTime プレーヤーは 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 サーバから取得します。Windows Media Playerで再生する .asf ファイルの取得には、MMS プロトコルが使用されます。

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 ファイルまたは Synchronized Multimedia Integration Language(SMIL)ファイルのように単一の 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 ファイルにリストされています。


) RealMedia ファイルには、RealMedia 形式のファイルであることを示す .rm 拡張子が付いています。


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

ほとんどのメディア プレーヤーは、スライド プレゼンテーションによってオーディオとビデオが同期化される、同期化メディアをサポートしています。メディアは通常、同じディレクトリに置かれ、相対リンクを使用して参照されます。

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

メディア プレーヤーが起動すると、再生するメディア ファイルが渡され、プレーヤーはブラウザと同様の手順を実行します。

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

「Windows Media Player に WMT MMS 要求の直接の宛先としてスタンドアロン Content Engine を指定」

「スタンドアロン Content Engine を RealMedia Player の直接の宛先として指定」

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

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

アドレスの 232.0.0.0/8 範囲は、ソース固有マルチキャスト(SSM; source-specific multicast)に予約済みです。SSM は、1 対多通信で、効率的にデータ配信を行うメカニズムを実現する、拡張型 Protocol-Independent Multicast(PIM)プロトコルです。

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 セグメント上の Network Interface Card(NIC; ネットワーク インターフェイス カード)で受信できるのは、バーンイン(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 セグメント上のホストのグループに送信する際にこの機能が使用されます。


) 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 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 アドレスの曖昧さ