Web サーバー ストリーミングでは HTTP (Hyper Text Transfer Protocol) を使用します。これは、サーバーとクライアントとの間の通信のために、すべての Web サーバー (たとえば、Microsoft® Internet Information Server) および Web ブラウザ (たとえば、Microsoft Internet Explorer) で使用されている、標準の Web プロトコルです。HTTP は、すべてのデータ伝送を処理する伝送制御プロトコル (TCP) の上で作動します。TCP はファイル転送やリモート ログインのような非リアルタイム アプリケーション用に最適化されています。その目標は、ネットワーク全体の安定性と高いスループットを保証しながら、データ転送レートを最大化することです。この目標を達成するために、スロー スタートというアルゴリズムを使用して、TCP は最初に遅い転送レートでデータを送信し、宛先からパケットが失われたと報告がくるまで徐々にレートを上げていき、報告を受けると TCP は帯域幅の限界に達するかまたはネットワークの混雑に遭遇したものと解釈して、元に戻って低いデータレートでデータを送信するようにします。それからまた徐々にレートを上げるというプロセスを繰り返します。TCP は失われたパケットを再送信して、データ転送の信頼性を維持するよう努めます。しかし、再送信したすべてのパケットがメディア ストリーム中で再生するのに間に合うようにクライアントに到達することを保証することはできません。
ポスティングとホスティング
ストリーミング メディア サーバー方式では、最初のステップは Web サーバー方式と似ています。ただ、メディア ファイルを圧縮したファイルを Web サーバーの代わりに専用のストリーミング メディア サーバー (たとえば、Microsoft Windows Media サービス) にコピーする点が異なります。それから、そのメディア ファイルを参照する Web ページが Web サーバー上に置かれます。Windows Media サービスと Web サーバーを同じコンピュータ上で稼働させることができます。
データの配信
ストリーミング メディア サーバーによるデータ送付の残りのプロセスは Web サーバー方式とは相当に異なります。Web サーバー方式のストリーミングで採用されている、一方的にデータを送りつける方法とは対照的に、データは双方向的かつ知能的にクライアントに送信されます。この方式では、圧縮されたオーディオおよびビデオのストリームにぴったり合うデータレートで、コンテンツが転送されます。データ受け渡しプロセスの間、サーバーとクライアントは密接に連絡を取り合い、クライアントからのいかなるフィードバックにもストリーミング メディア サーバーは応答することができます。
比較分析
Web サーバー方式のソリューションとストリーミング メディア サーバー方式のソリューションとの違いは、導入のしやすさ、管理のしやすさ、およびユーザーによる使い勝手に明確に現れてきます。このホワイト ペーパーでは以降、汎用の Web サーバーとマイクロソフトのストリーミング メディア サーバーである Windows NT Server Windows Media サービス (以降 Windows Media サーバーと呼びます) との間で比較を行います。
Web サーバーを用いたストリーミング : 利点
ストリーミング メディア サーバーではなく Web サーバーを用いてストリーミングを行う主な利点は、実際には 1 つしかありません。それは既存のインフラストラクチャを利用することです。Web サーバー方式では標準の Web サーバーしか使用しません。それは既にどこの組織にも存在すると思われるので、新しいソフトウェア インフラストラクチャをインストールすることも管理することも必要ありません。他方、Windows Media サーバー方式は、追加のサーバー ソフトウェアをインストールして管理するために、コンテンツ プロデューサとシステム管理スタッフの両方またはどちらか一方を必要とします。そのために、複雑度が高いがいっそう強力でもある Windows Media サーバー環境を学習して管理するために、より一層のトレーニングおよびスタッフに対するコストがかかります。
ここで注意すべきことがあります。それは、Web サーバーを用いてストリーミングを行うと、既存の Web サーバー インフラストラクチャにかかる負荷が増大し、クライアントの要求にサービスを提供するためには追加の Web サーバー ハードウェアが必要となることが多々あることです。ハードウェアのコストだけに基づいて、専用のストリーミング メディア サーバーを抑えて Web サーバーによるストリーミングを選択することは、財務的な節減につながりません。
Windows Media サーバー を用いたストリーミング : 利点
Windows Media サーバーは、多数の小さな HTML ファイルやイメージ ファイルではなく、ライブまたはオンデマンドのストリーミング メディアを処理するように特別に設計されています。したがって、Windows Media サーバーには、下記のように、標準の Web サーバーよりも多くの利点があります。
UDP プロトコルを使用すると、広い帯域幅を利用してクライアントにデータを送ることができます (その結果ビデオの品質が向上します)。サーバーとクライアントとの間の接続性が同じであり、インターネットの混雑ぐあいが同じであると想定しても、そういう結果になります。特殊化したストリーミング メディア サーバーを利用しているため、圧縮されたメディア ファイルのヘッダに基づいて、データが消費される速度を知ることができます。Windows Media サーバーはこの要求されたビット レートでのみクライアント (Windows® Media Player) にデータを送信します。ネットワーク リンクのボトルネックによりデータが失われることはありません。したがって、ネットワークのスループットが高くなり、クライアントにとってオーディオおよびビデオの品質が高まるという結果が得られます。
オーディオおよびビデオの品質が向上 : ネットワーク スループットが高いことは、Windows Media サーバーによるオーディオおよびビデオの品質が優れていることの理由の 1 つにすぎません。他にもいくつか理由がありますがそのうちの 2 つを下に例示します。
再生中も Windows Media サーバー と Windows Media Player は連絡を保っています。したがって、クライアントからのフィードバックにサーバーは動的に応答することができます。ネットワークが混雑しているために、(28.8 Kbps ではなく) 22 Kbps でしかデータがクライアントに到達しない場合、サーバーは対応措置を講ずることができます。具体的には、オーディオの品質は維持しながら、ビデオ ストリームのフレーム レートを少し下げて、利用可能な 22 Kbps を超えないようにします。Web サーバー方式ではこのような措置を取ることはできません。Web サーバー方式では、クライアントからのフィードバックがなく、オーディオの優先度をビデオよりも動的に高めることもできません。したがって、Web サーバーから送られてくるオーディオ / ビデオをクライアントは受け取り終わってから前に進むことになります。その結果、次のバッファリングが終わるまで再生が待たされるという不愉快な現象が発生します。初期のストリーミング メディア製品にはよくあったことです。それとは対照的に、Windows Media サーバーからは連続的に円滑なストリームが得られます。ネットワークが混雑しているときでも、ビデオのフレーム レートが変わったことをほとんど感じることはありません。
Windows Media サーバーを用いたストリーミングでは、UDP のトラフィックの方が HTTP のトラフィックよりも優先度が高いという特性を利用しています。その結果、オーディオおよびビデオのストリーミング データの方がファイルおよび Web ページの転送よりも優先されます。それにより、表示が円滑に進む可能性が高まります。
高度な機能のサポート : Windows Media サーバー方式では高度な機能をサポートしています。その例として、再生されたストリームの詳細なレポーティング、VCR の制御 (シーク、早送り、巻き戻し)、ライブのビデオの配信、クライアントへの複数のストリームの配信が挙げられます。Web サーバー ストリーミングの場合は、そのような機能はたとえ可能であったとしても、実装するのは困難であり、サポートする効率もよくありません。
多数のユーザーへのコスト効果の高いスケーラビリティ : ストリーミング メディアの初期の段階では、多くの場合、同時には少数のユーザーにしかサービスを提供できませんでした。そのため、Web サーバー ストリーミングが適切なソリューションでした。しかし、オーディオおよびビデオの利用が増大するにつれて、何百人または何千人の同時ユーザーにサービスを提供するサイトも多くなってきました。そのような状況において、Windows Media サーバーの 2 つの主要な機能が Web サーバーよりも大きな利点となります。
特殊化 : Web サーバー方式では、クライアントにメディア ファイルを送るのに Web サーバーを使用します。しかし、Web サーバーは多数の小さな HTML ファイルを送るために最適化されており、大きなメディア ファイルを送るのには適していません。Windows Media サーバーでは、大量のファイルを送る要求に対応するために、ディスクからメディア ファイルを読み出し、メイン メモリにバッファリングし、ネットワークにストリームとして送出する方法を最適化しています。Windows Media サーバーではスケーラビリティを Web サーバーの 2 倍から 3 倍に容易に向上させることができます。
コンテンツ著作権の保護 : Web サーバー ストリーミングでは再生した各メディア ファイルのローカル キャッシュ コピーを作成します。したがって、エンド ユーザーがそれらのファイルを個人のディレクトリにコピーして後で参照することを防止する方法はありません。そうすると、従量制の有料ビジネス モデルを採用しているコンテンツ プロバイダは損害をこうむります。また、広告から収入を得ているコンテンツ プロバイダも損害をこうむります。エンド ユーザーが繰り返しプロバイダのサイトにアクセスすることがなくなるからです。Windows Media サーバーの場合は、ユーザーはデータ ストリームを再生できるだけで、ファイルを直接自分のハード ディスクにダウンロードすることはできないようになっています。ネットワークを介して受信されたデータ パケットは直接クライアント アプリケーションに引き渡されます。エンド ユーザーが介入してコピーを作成する簡単な方法はありません。
複数の配信オプション : Windows Media サーバーの場合、可能な場合には最適な UDP プロトコルまたはマルチキャスト プロトコルを用いてメディアをストリーミングし、必要な場合には TCP プロトコルを用いてメディアをストリーミングします。それにより、企業のユーザーはファイアウォールのセキュリティを脅かすことなくインターネット コンテンツを参照することができるとともに、すべてのネットワーク上のすべてのユーザーがすべてのストリーミング メディア コンテンツにアクセスできることが保証されます。Windows Media サーバーは独自のバージョンの HTTP プロトコルを実装して、ファイアウォールまたはプロキシ サーバーを通じてストリーミングを行えるようにしながら、Windows Media サーバーの大部分の利点を依然として保持しています。
Windows Media サービスでは 4 種類のプロトコル構成をサポートしています。各プロトコル構成に固有の利点があります。
HTTP + TCP : Windows Media サーバーでは、TCP ベースのデータ配信に加えて、HTTP ベースの制御コマンドをサポートすることもできます。この組み合わせには、Web トラフィックを通す (ポート 80) すべてのファイアウォールと連携しながら、標準の Web サーバーよりもはるかに多くの制御 (早送りや巻き戻しなど) を行えるという利点があります。しかし、生の TCP ストリームにある程度のオーバーヘッドがかかり、スケーラビリティが低下します。
マルチキャスト : Windows Media サーバーでは、IP マルチキャスト プロトコルをサポートすることもできます。それにより、多数のユーザーにストリーミング コンテンツを非常に効率よく配信することができます。マルチキャスト機能を利用すると、何百人ないし何千人のユーザーが単一のストリームを再生することができます。ただし、マルチキャストを処理できるルーターを備えたネットワーク上でのみ機能します。マルチキャストは企業のネットワーク上では徐々に普及していますが、インターネット上では依然として非常に希です。
Windows Media サーバーは適切なプロトコルに自動的に切り替えます。したがって、クライアント側で構成する必要ありません。Windows Media サーバーは最初は最適な UDP プロトコルまたはマルチキャスト プロトコルを使用してファイルの転送を試みます。それが不成功であった場合、Windows Media サーバーは最初に生の TCP プロトコルを通じて送信を試み、次いで HTTP ベースの制御を加味した TCP プロトコルを通じて送信を試みます。
トップに戻る