ファイアウォールは、偶然にも故意にもメディアプレゼンテーションをブロックしますから、ストリーミング配信をうまく行なうためにはあなたのネットワークのファイアウォールをよく知っておくことが必要です。この章の説明は、ファイアウォールによる問題に出あっているユーザからの質問に答えるためにも役に立つでしょう。
ファイアウォールは、組織の内部ネットワークとインターネットとの間のすべての通信の監視や時には制御を行なうソフトウェアプログラムです。ネットワークは、会社のローカルエリアネットワーク、ワイドエリアネットワーク、インターネットなどで構成されることもあり、またカスタマのファイルへの不正なアクセスを防止しているインターネットサービスプロバイダである場合もあります。ファイアウォールの役割は、どちらの方向の通信にせよ、すべての通信がその組織のセキュリティポリシーに従うことを保証することです。
一般に、ファイアウォールはインターネットへの1方向アウトバウンドアクセスは許可します。メディアコンテンツのストリーミング配信と受信には、RealServerとクライアントとの間に双方向通信を確立する必要がありますから、ファイアウォールはクライアントがこの接続を確立しようとする試みを拒否し、その結果クリップに対するクライアントのリクエストがファイアウォールで拒否される可能性があります。
この章では、RealServerがファイアウォールの後ろにある場合にインターネット上のユーザにコンテンツを配信できない理由を説明し、保護されたマシンのネットワーク周辺に留まりつつコンテンツを配信するにはRealServerをどこに移動させればよいかを示します。
以下のいくつかのセクションでは、考えられるファイアウォール構成を説明し、RealServerがそれらとどのように連携して動くかを示します。この情報は、次のような事柄を知りたい方には興味があるでしょう：
ファイアウォールについて詳細は、RealNetworksのWebサイト、http://service.real.com/firewallから入手することができます。
特定のファイアウォール製品の設定についての詳細は、そのファイアウォールソフトウェアの説明書を参照してください。
サーバがファイアウォールの後ろにある場合は、ファイアウォールの後ろにいるユーザにしかコンテンツをストリーミング配信できません。ファイアウォールの反対側にいるユーザにインターネット上でストリーミング配信することはできません。
 |
追加情報 |
|---|
| 「ファイアウォールがユーザエクスペリエンスに影響を及ぼす理 由」を参照してください。 |
インターネット上でストリーミングやブロードキャストを行なうサーバを置くのに最良の場所は、非武装地帯（DMZ）とも呼ばれる周辺ネットワークの部分です。
|
|
追加情報 |
|---|
| 「RealServerのファイアウォールの近くへの配置」を参照してく ださい。 |
最良のユーザエクスペリエンスをもたらすファイアウォールは、RTSPおよびPNAのアプリケーション層トラフィックを許可し、またUDPトランスポートプロトコルを許可するものです。
|
|
追加情報 |
|---|
| 「ファイアウォール情報のまとめ」を参照してください。 |
オンデマンドストリーミングにせよ、その他のライブ配信方法にせよ、コンテンツをクライアントにストリーミング配信することは、このセクションで説明するように単純なことです。
オンデマンドストリームに関連してクライアントに発生する可能性のある問題については、「ファイアウォールの後ろのクライアントとの通信」で説明します。
クライアントは、オンデマンドストリームに接続するのと同じ方法でライブブロードキャストに接続します。しかしながら、RealServerにライブデータを供給するエンコーダは、エンコーダとRealServerとの間にファイアウォールがあるとRealServerに接続できない可能性があります。「ファイアウォールの後ろのエンコーダとの通信」を参照してください。
ファイアウォールの反対側にあるスプリッタと一緒に働くためには、第12章「ライブプレゼンテーションのスプリッティング」で説明するように特別な配慮が必要になります。
マルチキャストは、通常はブロードキャストがファイアウォールの外に出ない、イントラネットの内側で発生します。マルチキャストがファイアウォールを越えて起きる場合は、マルチキャストトラフィックを許可するようにファイアウォールに特別な設定を行なう必要があります。
RealProxyは、他のクライアントが接続するのと同じようにしてあなたのRealServerに接続します。さらに、メディアをキャッシュに保存するために2つのTCP接続を使います。
クライアントとRealServerとの間にファイアウォールがあるときは、アクセスログのclient_IP_addressフィールドに表示されるIPアドレスは本当のクライアントアドレスではない可能性があり、どのクライアントがあなたのRealServerからストリーミング配信されたマテリアルを見ているかを正確に知ることができないかもしれません。クライアントのアドレスを自分自身のアドレスに置き換えてしまうファイアウォールのリストについては、表「各種ファイアウォールタイプを通過するストリーミングメディア」を参照してください。
サーバーによる（ユーザまたはクライアントソフトウェアからの）認証情報のリクエストは、制御チャネル上で配信されます。ファイアウォールが制御チャネルの接続を妨げた場合は、RealServerはそのリクエストを認証することはできず、従ってそれを配信しません。
ユーザとユーザがホスティングのためにコンテンツを保存しようとする場所との間にファイアウォールがある場合は、ユーザはクリップをサーバに送信することができない場合があります。
RealServerは、クライアントと交信するために2つの「チャネル」と呼ばれる接続を使用します。1つはクライアントとの通信のため、1つは実際のデータのためのものです。通信用チャネルは、RealServerがパスワードの要求と受信、クライアントが早送り、一時停止、停止などの指示の送信をこのライン上で行なうことから、「制御チャネル」と呼ばれます。メディアは、実際は別の「データチャネル」上でストリーミング配信されます。
RealServerは、データの送信に2組のプロトコルを使います。
TCPプロトコルはパケットの配信を保証しますが、これは制御用情報とエラーチェックのために非常に重要です。このプロトコルには輻輳制御が組み込まれていますが、ネットワーク状態の変化への応答速度は速くありません。TCPは双方向接続用プロトコルであるため、クライアントとRealServerはパスワードを交信することができます。また、ユーザが一時停止や早送りを押すと、その情報はTCP接続を通じて送信されます。しかしながら、それぞれの指示情報が所期の送り先に到着したかどうかを確認するためには、いくらかのオーバーヘッドが費やされます。
UDPパケットは、一方向のみに送信されます。伝送はエラーチェックを行ないませんから、TCPよりも速くパケットを送ることができます。
制御情報に適しているというTCPの特徴は、連続したデータの伝送にはあまり適していないという性質をもたらしています。TCPで使われるオーバーヘッドは、ストリーミングメディアの配信には効果的ではありません。
クライアントが受け取るストリームの品質は、使われているトランスポートプロトコルに関係しています。
RealServerは、クライアントとの交信にRTSP（Real Time Streaming Protocol）およびPNA（Progressive Networks Audio）の2つの主要アプリケーション層プロトコルを使います。これらのプロトコルは双方向TCP接続と連携して、「開始」や「一時停止」などのコマンドをクライアントから送り、またRealServerからクライアントへクリップのタイトルなどの情報を送ります。3番目のプロトコルであるHTTPは、その他のタイプのデータを送るために使われます。
| 制御チャネルプロトコル | データチャネルプロトコル |
|---|---|
| RTSP | TCPおよびUDP、またはTCPのみ |
| PNA | TCPおよびUDP、またはTCPのみ |
| HTTP | TCPのみ |
この章の後で説明するように、ファイアウォールがファイアウォールの外側を発信元とするUDP接続を許可しない場合は、TCPプロトコルを単独で使うことがあります。
ファイアウォールのセキュリティポリシーでは、すべてのトラフィックを停めて、ファイアウォール管理者が特に指定したサービスだけを許可します。通常は、組織内部で発生したHTTPトラフィックおよびTCPベースのトラフィックが、ファイアウォールの通過を許可されます。
このようなファイアウォールを通してストリーミングメディアをリクエストしようとするクライアント（例えばRealPlayer）は、この種のファイアウォールでは許可されていないUDPを使おうとしているために、最初はファイアウォールから拒否されます。
クライアントは、UDPをデフォルトのトランスポートプロトコルとして使っては、サーバとの接続が確立できないことに気づきます。この時点で、クライアントはTCPやHTTPのような代替プロトコルをデータ伝送に使うことを試みます。
大部分のファイアウォールはHTTPトラフィックを許可するように設定されているため、HTTPを使ってファイアウォールを通過できる可能性はかなりあります。
RealServerは、2つの固有な方法を使ってHTTP上でストリーミングメディアを配信することができます。その方法とは、RTSPまたはPNAプロトコルのストリームをHTTPプロトコルでラッピングする方法、およびHTTPによってプレゼンテーションをダウンロードする方法です。しかしながら、これらの方法はいずれも、可能な限り最善のユーザエクスペリエンスをもたらすものではありません。
互いに交信し合うエンコーダ、サーバ、クライアントなどのRealSystem G2を構成するソフトウェアパッケージの間をファイアウォールが隔離している場合は、データの配信が最善のレートで行なわれない可能性があります。
このセクションの情報は、RealServerと次に示すRealSystemソフトウェアとの間の接続の性質に関心のあるサーバ管理者を対象としています：
RealServerとクライアントとの間にファイアウォールがない場合（例えば、両方とも同じ内部ネットワークにいる場合）は、構成要素のソフトウェアはまずRealServerへの双方向TCP制御接続を確立しようと試みます。RealServerは、最初はこの接続を、クリップの名前、長さ、著作権などのリクエストされたメディアに関する情報をクライアントに送信する手段として使います。クライアントは、再生や停止などのボタン機能を操作したときにコマンドをRealServerに送信するためにこの接続を使います。
初期の接続が確立されると、次にRealServerはクライアントへのデータチャネルを確立します。実際のメディアは、UDPプロトコルを使ったこのデータチャネルで送信されます。
このセクションでは、クライアントソフトウェアがRealServerと交信しようとする際に、その内部で使われるロジックを説明します。
再生の品質を最適化するために、クライアントは一般的なファイアウォールコンフィグレーションを通過してRealServerと接続するためのいくつかの異なる方法を自動的に試すように設計されています。
下のリストは、クライアントソフトウェアがデータチャネルによるストリーミングメディア送信に使うようにRealServer対して要求するプロトコルを。どのようにして決定するかを示しています。
デフォルトでは、クライアントがストリーミングされたバージョンではなくクリップ全体を取得することになるために、HTTPダウンローディングは許可されません。HTTPダウンロードを有効にするには、そのクリップのパスをHTTP Deliveryリストに追加します。
リクエストがオンデマンドコンテンツの場合は、クライアントは次の3つの方法を試みます：
ユーザは、ファイアウォール管理者の指示に従って、RealPlayeが常に特定のプロトコルとポートを使うように設定することができます。
|
|
追加情報 |
|---|
| クライアントのプレファレンスを設定する手順については、 RealPlayer Plus G2 Manualを参照してください。 http://service.real.com/help/library/index.html参照。 |
クライアントがファイアウォールの後ろにいて、コンテンツへのアクセスに問題がある場合は、サービス改善のために採れるステップがあります。
あなたのRealServerがファイアウォール（「最良のファイアウォール構成」参照）に対して適正な位置に置かれていることが確かな場合は、次のようなステップが役に立ちます：
80を使っていることを確認します（「HTTPトラフィックがあなたのRealServerに確実に届くようにするには：」の手順を参照してください）。
RealPlayerには、すべてのストリームをHTTP形式で送信するようにリクエストするためのオプションがあります。WebサーバがRealServerと同じコンピュータまたはIPアドレスにインストールされていない場合は、これらのクライアントリクエストはHTTPポート番号を80に設定すれば受け取ることができます。RealServerがWebサーバと同じコンピュータにインストールされている場合は、次のようなオプションがあります：
80を使わないでください。別の値を使う必要があり、その別の値はHTTPで始まるいずれかのRealServerリンクに含まれていなければなりません。
RealServerは、RealServerがネットワークの周辺ネットワークに位置しているならば、ファイアウォールの後ろにあるエンコーダを交信することができます。
RealServerとエンコーディングソフトウェアがファイアウォールの同じ側にある場合は、両者の間に通信上の問題はありません。
異なるバージョンのエンコーダは、異なるプロトコルを使ってRealServerに接続します：
|
|
追加情報 |
|---|
| 異なるバージョンのエンコーダが使うポート番号については、「エ ンコーダが使うポート番号」を参照してください。 |
クライアントとの通信の場合と同様に、RealServerとの通信に好ましいオプションはUDPです。
UDPはリアルタイム通信に対しては、より頑健なプロトコルであり、従ってエンコーダとRealServer間の接続にはより好ましい方法です。TCPプロトコルでは、ネットワークの輻輳によって影響を受け、ライブセッションがばらばらになる可能性があります。UDPは、短時間のネットワーク輻輳の期間に対してはより弾力的です。
エンコーディング接続は、プロキシすることができません。従って、エンコーダがファイアウォールの後ろにある場合は、次のいずれかを行なう必要があります（好ましい順にリスト）：
デフォルトでは、スプリッタとRealServerはUDPを使って交信します。代わりにTCPを使うオプションがあります。
スプリッティング接続は、プロキシすることができません。従って、スプリッタがファイアウォールの後ろにある場合は、次のいずれかを行なう必要があります（好ましい順にリスト）：
この設定は、ソース上ではプッシュスプリッティングに設定されますが、スプリッタ上ではプルスプリッティングに設定されることに注意してください。
RealProxyがファイアウォールの後ろに置かれているのは、よくあるケースです。これに関連しては、RealServerからRealProxyへの接続はRealServerからクライアントへの接続と同じように動作しますが、次の2つの接続タイプだけしか利用できません：
他の構成要素ソフトウェアでは使っているHTTP配信のオプションは利用できません。
ファイアウォールがTCPを禁止する場合は、RealProxyはクライアントに代わってストリームをプロキシすることができません。
|
|
追加情報 |
|---|
| RealProxyの設定について詳細は、RealProxy Administration Guideを参照してください。 http://service.real.com/help/library/index.html参照。 |
ファイアウォールは、大きく分けて6つのタイプに分類されます。ファイアウォール製品のベンダは、その製品に1つ以上のタイプを組み合わせる場合もあります。あなたの組織でお使いのファイアウォールのタイプによって、RealServerがクライアントにコンテンツをストリーミング配信する方法は影響を受けます。
ソースRealServerのアクセスログに表示されるアドレスは、クライアントのファイアウォールタイプによって異なります。
ファイアウォールはクライアントソフトウェアとインターネット間のすべてのタイプの通信を監視しますが、ここではストリーミングメディアに対するファイアウォールの影響についてのみ説明します。
アプリケーションレベルのファイアウォールは、まず内部ネットワーク上のコンピュータと外のコンピュータとの間にリクエストされた接続を許可するかどうかを決定します。接続が許可された場合は、ファイアウォールはリクエストしているソフトウェアを模倣して2台のコンピュータ間に必要な通信リンクをセットアップします。仲介者として、ファイアウォールは2つのネットワーク間の通信を監視して、許可されないアクティビティを抑えることができます。
アプリケーションレベルのファイアウォールはRealPlayerとRealServerとの間の仲介者として働くために、ファイアウォール自身がRealPlayerプロトコル（RTSPおよびPNA）を処理する方法を知っている必要があります。
ユーザは、クライアントソフトウェアがプロキシまたはファイアウォールマシンとコンタクトするように設定する必要があります。（RealPlayerでは、この設定はOptions > Preferences > Proxyの下にあります。）
ソースRealServerのアクセスログには、クライアントのアドレスの代わりにファイアウォールマシンのIPアドレスが表示されます。
ネットワーク管理者は、ストリーミングメディアへのリクエストをインターセプトするように、ファイアウォールを設定します。
ソースRealServerのアクセスログには、クライアントのアドレスの代わりにファイアウォールマシンのIPアドレスが表示されます。
アプリケーションを装うのではなく、ネットワークレベルのファイアウォールはトランスポートレベルで送信された情報パケットを検査して、パケットを阻止すべきかどうかを決定します。それぞれのパケットは、ファイアウォール管理者が定めた規則に基づいて、転送または阻止されます。
ネットワークレベルフィルタリングファイアウォールの一般的なコンフィグレーションでは、ファイアウォールの内側で起こされたすべての接続は許可し、ファイアウォールの外側にあるマシンで行なわれたすべての接続は制限するかまたは禁止します。大部分のプログラムについては、これらのプログラムが通常は1つのアウトバウンドTCP接続のみを確立するため、この方式はうまく働きます。
しかしながらRealPlayerとRealServerとは、コマンドを送るためのTCP接続とTCPにより受け取った指示に従って実際のメディアをストリーミング配信するためのUDP接続という、2本同時の接続を保持します。接続を制御するためにRealPlayerが起こしたTCP接続は、パケットフィルタファイアウォールを通過します。もちろんネットワークレベルフィルタはUDPを阻止しますから、RealServerが送ったUDPストリームはファイアウォールではね返されて、リクエストを行なったRealPlayerには届きません。
RealServerのアクセスログは、クライアントのアドレスを表示します。
ステートフルパケットフィルタリングファイアウォールは、クライアントとインターネットとの間の通信を監視して、インバウンドパケットがファイアウォールの内側のクライアントのリクエストで送られたことを確認します。パケットフィルタと同様に、個々のパケットに対してより複雑なアクションを行なうオプションを含む場合があります。
これらのファイアウォールは、RTSPおよびPNAトラフィックを許可するように設定する必要があります。
RealServerのアクセスログは、クライアントのアドレスを表示します。
ユーザによる追加の設定を必要とするSOCKSサポートが組み込まれたソフトウェアだけが、SOCKSファイアウォールを通してデータを送信することができます。RealPlayerはSOCKSをサポートしていません。.
場合によっては、ユーザがSOCKSをサポートしているWinsock.dllをインストールして、それをSOCKSファイアウォールを指すように設定できます。
ネットワークアドレス変換ファイアウォールは、クライアントのリクエストをRealServerに転送する前に、クライアントの内部アドレスを外部アドレスに変換します。リクエストを受け取ると、RealServerはUDPパケットをクライアントにではなく直接ファイアウォールに送信するので、ファイアウォールはそのパケットがどのクライアントがリクエストしたものかわからない場合があります。
下のテーブルは、6つの最も一般的なファイアウォールタイプと特別なコンフィグレーション情報をまとめたものです。
いくつかのファイアウォールでは、上のセクションで説明したファイアウォールタイプを実際はミックスして使っています。例えば、多くのパケットフィルタリングファイアウォールはネットワークアドレス変換も許しており、従ってRealServerアクセスログに表示されるIPはクライアントのアドレスではなくファイアウォールのアドレスになります。
RealSystemソフトウェアのユーザに最善の体験をもたらすファイアウォールは、ポート554上のTCP制御チャネルと一定のポート範囲上のUDPデータチャネルを許可してストリーミングメディアを許容するものです。
次に最善のオプションは、TCP制御チャネルとTCPデータチャネルを共にポート554上で許可するファイアウォールです。ファイアウォール管理者は、ファイアウォールに対してこのような変更を簡単に行なうことができます。しかしながら、このコンフィグレーションでは接続の品質はそれほどよいものではありません。
最後に、ほとんどすべてのファイアウォールはHTTPトラフィックを許可しており、HTTPはRealServerとクライアント間の接続として動作します。しかしながら、エンコーダとスプリッタはHTTP上ではサーバと交信することはできません。
RealServerがファイアウォールの後ろにあって、ファイアウォールの反対側のクライアントにコンテンツをストリーミング配信している場合は、その置き場所を再検討してください。RealServerをファイアウォールの後ろに置くことは、次のような理由からあまり意味がありません。RealServerはクライアントのリクエストによってTCP接続を開く必要があり、ほとんどのファイアウォールはファイアウォールの内側で起こされた場合にのみTCP接続を許可するからです。また、RealServerはUDPチャネルをさまざまなポートで開く必要があります。ここでもまた、ほとんどのファイアウォールはUDP接続をまず許可しません。
RealServerがファイアウォールの後ろにある場合は、インターネット上のクライアントがあなたのコンテンツにアクセスすることはほぼ完全に不可能です。
この解決策は、ファイアウォールを非武装地帯（DMZ）とも呼ばれている周辺ネットワークに移動することです。周辺ネットワークは主要内部ネットワークの外側にありますが、ファイアウォールによってまだ保護されている場所です。ここではクライアントによるTCPやUDP接続のリクエストは、RealServerがファイアウォールの後ろにある場合に起きるようなセキュリティリスクを伴いません。周辺ネットワークにあるマシンには、内部ネットワークにあるマシンに適したものとは異なる、より自由なセキュリティ機能をセットアップすることができます。
以下のテーブルに示す情報は、ファイアウォールにどのポートを開けばよいかを決めるために役立ちます。詳細については、特にリストにあるポートのすべては明示的に開きたくない場合は、RealNetworksのWebサイト、http://service.real.com/firewallにある文書を参照してください。
これらのテーブルは、マルチキャスティングにおけるポート番号の使用についてはカバーしていません。
通常は、クライアントソフトウェアはデータチャネルにUDPを選択し、データを受け取るポート番号に6970から6999の間の値を指定します。RealServerは、ポート554（RTSPでリクエストした場合）またはポート7070（PNAでリクエストした場合）上でリクエストを受け取り、データをクライアントが指定したポート番号にダイレクトします。
クライアントソフトウェアがデータチャネルにTCPを選択した場合は、RealServerは制御チャネルとデータチャネルの両方に対して同じポート番号を使います。クリップがRTSPを使ってリクエストされた場合は、両方のチャネルともポート554を使います。クリップがPNAを使ってリクエストされた場合は、両方のチャネルともポート7070を使います。
このテーブルは、RealServerが使う代表的な値を示します。
このテーブルに示した値に加えて、スプリッタが自分自身のコンテンツ（スプリッティングとは別に）を配信している場合は、表「RealServerが使うポート」の中のすべての値を使います。
| リッスンか、送信先か | ポート番号 | プロトコル | 目的 |
|---|---|---|---|
| RealServerとの通信 | |||
| リッスン | 554 | TCP | RealPlayerからのRTSPリクエスト |
| 送信先 | 3030 | TCPまたはUDP | プルスプリッティングリクエスト |
| リッスン | 11001 | TCPまたはUDP | プッシュスプリッティングリクエスト |
RealProducer PlusG2バージョン6.1では、データ接続にTCPを使うようにRealProducer Plusに指示することができます。よりよいユーザエクスペリエンスがえられるため、UDPのほうが好ましい方法ですが、エンコーダとサーバとの間にファイアウォールがある場合はTCPが必要になります。TCPを使うように選択した場合は、ポート4040は制御チャネルとデータチャネルの両方に使われます。
下に示した設定に加えて、RealPlayerはデフォルトのブラウザからプロキシ設定（設定されている場合）を継承します。ブラウザでそれが変更された場合は、その変更はRealPlayerに反映されます。ユーザは、RealPlayerのPreferencesメニューからこの機能をオフにすることができます。