第 11 章 ファイヤーウォール

ファイヤーウォールは Helix Universal Server の通信に問題を発生させることがあります。この章は、このような問題の解決に役立ちます。ここでは、まずファイヤーウォールとネットワーク プロトコルの背景情報を紹介します。次に、できるだけ最良のストリーミング メディア体験を視聴者に提供できるように、ファイヤーウォールの推奨取り扱い方法について説明します。最後に、RealNetworks コンポーネントで使用される通信ポートの一覧を示します。

ファイヤーウォールについて

ファイヤーウォールは、社内ネットワークとインターネットの間のすべての通信をモニタし、時には制御するソフトウェア プログラムまたは装置です。ネットワークの規模にかかわらず、通常、ファイヤーウォールはネットワーク エッジに配備され、ファイヤーウォールの内側にあるデータに対する不正なアクセスを防止します。ファイヤーウォールは、どちらの方向の通信でも、すべての通信がその組織のセキュリティ ポリシーに従っていることを保証します。

ファイヤーウォール テクノロジは設定変更が可能です。通信方向、IP アドレス、プロトコル、ポートなど、多くの条件を組み合わせて通信を制限できます。ファイヤーウォールは Helix Universal Server とほかのコンピュータの間に配置されるため、Helix Universal Server に必要な通信タイプを許可していないと、通信障害の原因となることがあります。ほかのコンピュータとは、エンコーダまたはレシーバとしてセットアップされたサーバーやメディア クライアントです。

ファイヤーウォールへのアクセス権を持っているユーザーは、ファイヤーウォールを設定して、Helix Universal Server の通信を最適化するようなポート、プロトコル、およびアドレスを有効にすることができます。ただし、組織のセキュリティ ポリシーのため、最適なストリーミング配信ができないこともあります。たとえば、クライアントがファイヤーウォールの内側にあり、そのファイヤーウォールがインターネットへの単一方向アウトバウンド アクセスだけを許可している場合、このクライアントは、インターネットを通して Helix Universal Server からストリーミング配信されるクリップを効率よく受信できません。クライアントで最適なストリーミング結果を得るには、双方向通信を確立する必要があります。

プロトコル レイヤ

プロトコルとは、コンピュータがネットワークを通して通信するときに使用する言語です。Transmission Control Protocol/Internet Protocol (一般に TCP/IP と呼ばれます) には、インターネットの基礎となっているプロトコル一式が含まれています。TCP/IP はレイヤ構造に基づいて動作し、各レイヤには特定のネットワーク タスクが割り当てられています。

通信が行われるとき、送信元のコンピュータでは、その最も高いネットワーク レイヤから最も低いレイヤにメッセージが送られます。送信元コンピュータの最も低いネットワーク レイヤは、ネットワークを通してそのメッセージを送信します。送信先コンピュータにメッセージが届くと、ここでも同じレイヤを逆方向に通過させます。

各ネットワーク レイヤでは、タスクを実行するためにそれぞれ特定のプロトコルが使用されます。より上位のレイヤから降りてきたパケットは、下位レイヤのパケット内に詰め込まれます。これはカプセル化と呼ばれています。パケットをカプセル化することで、下位のレイヤでは上位のレイヤについて理解しなくても、割り当てられたタスクを処理できます。このレイヤ機構を通すと、あるコンピュータ上の送信先レイヤで受け取るオブジェクトは、別のコンピュータ上の対応するレイヤから送り出されたものと正確に一致します。

たとえば、Web ブラウザなどのアプリケーションは、HTTP を通して行われる Web ページ要求などのデータを、アプリケーション レイヤでパッケージ化してから下位のトランスポート レイヤに渡します。HTTP 要求のパケットはここで TCP パケット内にまとめられ、送信先である Web サーバーに届けられます。Web サーバーでは、この元の TCP パケットを受け取ると、その外側の TCP 部分を除去し、送信先コンピュータの上位のアプリケーション レイヤまで HTTP メッセージを送ります。すると、次にこのレイヤは、HTTP ベースの要求を Web サーバーに届けます。

注意 : ネットワークのレイヤ化は複雑な題材です。ここでは、ネットワークを通してパケットを配信するために必要なその他のレイヤについては省略します。代わりに、トランスポート レイヤとアプリケーション レイヤ、およびストリーミング メディアに関連するプロトコルに重点を置いて説明します。

トランスポート レイヤ プロトコル

すべてのトランスポート レイヤ プロトコルは、ホスト間のデータ転送を行います。使用するトランスポート レイヤ プロトコルによっては、受信されるストリームの品質に大きな影響があります。IP ネットワークで使用される主な転送プロトコルは、TCP と UDP の 2 つです。Helix Universal Server では両方のプロトコルを使用できます。通常、使用するプロトコルは、関係するサーバーとクライアントのネゴシエーションによって自動的に選択されます。

Transmission Control Protocol (TCP)

Helix Universal Server では、さまざまな方法で TCP を使用できます。TCP は双方向通信用の単一チャネルを提供するため、Helix Universal Server ではこのチャネルを制御チャネルとして使用できます。制御チャネルでは、一時停止や早送りなどのユーザー コマンド、パスワードなどをクライアントとやり取りします。TCP プロトコルではパケットの配信が保証されるほか、通信の信頼性向上に役立つ輻輳制御も組み込まれています。

その反面、TCP はネットワーク状態の変化に対する応答が遅く、エラー チェック機能のためにネットワーク オーバーヘッドも発生させます。このような理由から、TCP は、パスワードやユーザー コマンドのように帯域幅消費の少ないコンテンツを配信するのに適しています。場合によっては、TCP を使うとファイヤーウォールを通しての通信が容易になることもあります。たとえば、Helix Universal Server とクライアントの間の UDP トラフィックをブロックするファイヤーウォールで、TCP 接続は許可されていることがあります。

User Datagram Protocol (UDP)

Helix Universal Server は、データ チャネル上で UDP パケットを使ってクライアント ソフトウェアにデータを配信します。クライアント ソフトウェアは、データ チャネルでパケットを受信できなかったとき、UDP ベースの要求を Helix Universal Server に送信します。この転送では TCP ほど多くのネットワーク オーバーヘッドを消費しないため、TCP よりも速くパケットを送信できます。

通常、ビデオやオーディオのデータは帯域幅を大量に消費するため、ストリーミング メディアの配信には UDP を使用すると有利です。このような理由から、Helix Universal Server では、トランスミッタからレシーバへの通信にデフォルトで UDP を使用します。Helix Producer エンコーダは、トランスミッタとして動作するようにセットアップできます。したがって、エンコーダからのライブ ストリームの配信には UDP 接続を使用するようにしてください。

アプリケーション レイヤ プロトコル

Helix Universal Server は、RTSP、PNA、MMS、および HTTP という 4 つのアプリケーション レイヤ プロトコルを使って、クライアントにストリーミング メディアを配信します。次の表は、これらのプロトコルの使用法をまとめたものです。

Real-Time Streaming Protocol (RTSP)

RTSP は、マルチメディア プレゼンテーションを配信するために設計された標準規格のプロトコルであり、大規模なブロードキャストには大変便利なプロトコルです。多重ビット レート エンコーディングを使用する SureStream ファイルを配信できるのは RTSP だけです。SMIL、RealText、および RealPix にも RTSP が必要です。RTSP では、プレイヤーの制御メッセージに TCP を使用し、ビデオやオーディオのデータに UDP を使用します。RTSP では、TCP を使ってデータを配信することも可能ですが、これはお勧めできません。RTSP は、RealOne Player、RealPlayer、QuickTime Player など、RTSP 対応のプレイヤーで使用してください。

Progressive Networks Audio (PNA)

PNA は、以前のバージョンの RealNetworks クライアント ソフトウェアで使用されていた独自のプロトコルです。現在の Helix Universal Server では、古いバージョンの RealNetworks クライアント (RealPlayer 5 およびそれ以下のバージョン) との互換性のために PNA がサポートされています。PNA では、プレイヤーの制御メッセージに TCP を使用し、オーディオ データに UDP を使用します。PNA では、TCP を使ってデータを配信することも可能ですが、これはお勧めできません。

注意 : PNA プロトコルの要求 URL には、pna:// ではなく pnm:// を使用します。

Microsoft Media Services (MMS)

MMS は、マルチメディア プレゼンテーションを配信するために特別に設計されたプロトコルです。標準規格のプロトコルではありませんが、このプロトコルを使うと、ライブまたはオンデマンドの Windows Media クリップを Windows Media Player にブロードキャストできます。MMS では、プレイヤーの制御メッセージに TCP を使用し、ビデオやオーディオのデータに UDP を使用します。MMS では、TCP を使ってデータを配信することも可能ですが、これはお勧めできません。

HyperText Transfer Protocol (HTTP)

HTTP は主に Web ページに使用されます。Helix Universal Server では、HTTP を使って Helix Administrator のページや HTML ベースのドキュメントを表示します。また、ストリーミング メディア コンテンツを指すメタファイルをクライアント ソフトウェアが要求するときにも使用されます。HTTP は HTTP クローキングにも使用されます。HTTP クローキングは、ストリーミング メディア プロトコルがファイヤーウォールで制限されている場合に、その後ろにいるクライアントにストリーミング メディアを配信するための手法です。

注意 : Helix Universal Server では、ライブ Windows Media ストリームを Windows Media エンコーダから Helix Universal Server へ転送するときにも HTTP を使用します。

パケット形式

インターネットのデータはすべて IP パケットで配信されます。ただし、TCP や UDP でストリーミング メディアの制御プロトコルをラップできるのと同様に、IP パケットでも、ストリーミング メディア データの配信用に設計された形式にデータ パケットをラップできます。Helix Universal Server では、次の両方のパケット形式を使用できます。

RealNetworks Data Transport (RDT)

Helix Universal Server は、RealOne Player などの RealNetworks クライアントと RTSP で通信するとき、パケット形式として RDT を使用します。独自形式である RDT では、SureStream などの RealMedia 機能が使用できます。

Real-Time Transport Protocol (RTP)

RTP は、RTSP プロトコルで使用するために設計された標準規格のパケット形式です。たとえば、QuickTime Player では、パケット形式として RTP が使用されています。Helix Universal Server は RTP を完全にサポートしており、QuickTime Player などの RTP ベースのクライアントにストリーミング配信するときは、自動的に RTP に切り替えます。RealOne Player などの RealNetworks クライアントも RTP をサポートしており、RTSP/RTP サーバーからデータを受信するときにこのパケット形式を使用します。

ファイヤーウォールと Helix Universal Server 機能

ファイヤーウォールが Helix Universal Server の機能にどのような影響を与えるかについて、次の表に示します。

ネットワークへの Helix Universal Server の配置

Helix Universal Server の配備にあたっては、ネットワーク上のどこに配置するかをまず決定する必要があります。組織内のクライアントだけにコンテンツをストリーミング配信する場合、通常は Helix Universal Server をファイヤーウォールの内側に配置するのが最適です。この配置では、Helix Universal Server にもファイヤーウォールにも特別な設定は必要ありません。ただし、ファイヤーウォールで隔てられたインターネット側にいるクライアントは、おそらく Helix Universal Server にアクセスできなくなります。

インターネット上のクライアントにコンテンツをストリーミング配信する必要がある場合は、Helix Universal Server をファイヤーウォールの外側に配置する方が適しています。最適なストリーミング配信を行うために、Helix Universal Server ではストリーミング プロトコルを使用する必要があります。また、着信および発信の各 UDP 接続を、負荷に応じてさまざまなポートで処理する必要があります。組織のセキュリティ ポリシーを変更して最適な接続を可能にすることもできますが、それによってファイヤーウォールの有効性が損なわれることもあります。

この問題を解決するには、非武装地帯 (DMZ: De-Militarized Zone) と呼ばれる周辺ネットワークを作成し、そこに Helix Universal Server を移動する方法が最適です。このシナリオでは、メイン ネットワークと周辺ネットワークの間の接続は強力に保護する一方で、周辺ネットワーク内では緩やかなセキュリティ ポリシーを適用します。これにより、メイン ネットワークは安全に保たれ、インターネットから Helix Universal Server への接続は最適に維持されます。

ファイヤーウォール テクノロジの取り扱い

組織によっては、Helix Universal Server をファイヤーウォールの背後に配置し、ファイヤーウォールを通してメディアをストリーミング配信する以外に方法がない場合もあります。この場合は、Helix Universal Server とほかのコンピュータの間で最適な通信ができるようにファイヤーウォールを設定する必要があります。この設定を行わないと、通信品質が標準以下になるか、まったく通信できなくなります。

ここでは、さまざまな状況で最適な通信を得るための要件について説明します。これを参考に、ファイヤーウォールでどの種類のトラフィックを通過させるかを決定できます。「デフォルト ポート」では、Helix Universal Server がほかのコンピュータとの通信に使用する特定のポートを一覧に示します。この一覧に示された値はデフォルト値であり、その多くは必要に応じて変更できます。

着信 UDP トラフィックの制限

Helix Universal Server では、RealOne Player などのクライアントから着信する UDP パケット用のポート数を制限できます。クライアントは、データの受信確認として、また、消失パケットの再送要求を行うために、これらのパケットを送信します。ファイヤーウォールですべての着信 UDP 通信を受け入れることは可能ですが、多数の UDP ポートを開いておくことに躊躇するネットワーク管理者も多いでしょう。しかし、Helix Universal Server でこれらのパケットを受信できないとサービス品質が低下します。この問題を解決するために、Helix Universal Server では、すべてのクライアントからの応答を少数の UDP ポートにリダイレクトすることで、開いておく UDP ポートの数を制限できます。

詳細情報 : この機能のセットアップ手順については、「ポートの割り当て変更」を参照してください。

仮想 IP アドレスの取り扱い

Helix Universal Server の配置に影響を与えるテクノロジは、ファイヤーウォールだけではありません。Helix Universal Server のクラスタを 1 つの仮想 IP アドレスの下に置く必要がある場合もあります。このようなネットワーク トポロジは可能ですが、RTSP トラフィックを制限するファイヤーウォールを通すと、RTSP トラフィックに意図せぬ影響が発生することがあります。

仮想 IP アドレスの動作

通常の IP アドレスは、単一のサーバーとしてリゾルブされます。一方、仮想 IP アドレスは、通常はハードウェア スイッチによって一団のサーバーとしてリゾルブされます。ハードウェア スイッチの後ろにサーバーのクラスタが置かれ、すべてのサーバーで同じコンテンツを共有しているものの、それぞれに一意のプライベート IP アドレスが設定されているとします。この場合、パブリック IP アドレスはハードウェア スイッチだけに割り当てられます。パブリック通信はすべてハードウェア スイッチが受け取り、各要求を負荷に応じてクラスタ内のホストに渡します。

仮想アドレスでの問題点

問題はパブリック IP アドレスとプライベート IP アドレスの組み合わせから発生します。ファイヤーウォールがストリーミング メディア プロトコルをブロックする場合、クライアントは HTTP クローキングを使って通信します。通常、ファイヤーウォールのセキュリティは HTTP トラフィックの通過を許可するため、ほとんどの場合はこの方法で効果的に迂回できます。この手法については、「HTTP クローキング」で詳細に説明します。ここでは、クローキングが機能するためには、クライアントは同じ Helix Universal Server に対して 2 つの HTTP 接続を確立する必要があるということだけを理解しておいてください。

クライアントが HTTP クローキングを使用するとき、Helix Universal Server は最初の HTTP 接続に対して、クラスタの仮想 IP ではなく実際の IP アドレスを使って応答します。これによってクライアントでは、ハードウェア スイッチを迂回して、要求を処理する Helix Universal Server と直接 2 番目の HTTP 接続を確立できます。ただし、サーバーがプライベート IP アドレスを使用すると、クライアントは必要な 2 番目の接続を確立できず、HTTP クローキングは失敗します。

仮想アドレスの問題点の解決

仮想アドレスの問題点を解決するには、次の 2 とおりの方法があります。

• ストリーミング メディア プロトコルによる接続を許可するようにファイヤーウォールを設定します。サーバーとクライアントの間で最も効率よく通信できるため、この方法が理想的です。
• 1 つの仮想 IP アドレス下にあるすべてのホストで、グローバルにルーティング可能な IP アドレスを使用します。これによってクライアントでは、ストリーミング メディア プロトコルを制限するファイヤーウォールを越えて、HTTP クローキングによる要求を行うことができます。ただし、組織で多数のパブリック IP アドレスを登録申請しておく必要があります。

どちらの解決方法も使用できない場合、特に制限の厳しいファイヤーウォールの外側にいる RTSP クライアントの一部で、コンテンツにアクセスできなくなることがあります。

エンコーダ、レシーバ、プロキシの取り扱い

ファイヤーウォールに対して Helix Universal Server を設置したら、次にほかのサーバーの配置を検討する必要があります。このようなサーバーとしては、レシーバやリレーとしてセットアップされた Helix Universal Server のほか、エンコーディング ソフトウェアやメディア プロキシ ソフトウェアを実行するコンピュータなどがあります。一般に、これまでに説明した規則や制限事項は、これらのサーバーにも当てはまります。可能な場合は、ほかのエンコーダやレシーバも Helix Universal Server と共に周辺ネットワークに配置します。これが不可能な場合、解決策はサーバーの種類によって大きく異なります。

エンコーダとの通信

ここでは、Helix Universal Server をファイヤーウォールの内側に配置し、ファイヤーウォールの外側のエンコーダと最適な通信を確保するように設定したと仮定します。このファイヤーウォールが最適に設定されていても、別の組織のファイヤーウォールによって問題が発生することもあります。

別の組織が独自のファイヤーウォールを通してこの Helix Universal Server にライブ ブロードキャストを配信するとします。最善の解決策は、その組織に連絡してエンコーダをファイヤーウォールの外側に移動してもらうことです。または、その組織と相談して、必要なネットワーク パスを開くようにします。どちらの解決策も使用できない場合は、エンコーダとの通信に TCP を使用してみる方法もあります。

Windows Media エンコーダからの HTTP ブロードキャスト

Windows Media エンコーダがライブ Windows Media ブロードキャストを送信するときに使用できるプロトコルは HTTP だけです。HTTP は TCP を使用しています。この構成では、Helix Universal Server がエンコーダからライブ ブロードキャストをプルします。プルする HTTP ポートの番号は Windows Media エンコーダの管理者に問い合わせてください。Helix Universal Server では、デフォルトの HTTP ポートでライブ ブロードキャストを受信します。

レシーバとの通信

デフォルトでは、レシーバと Helix Universal Server は UDP を使って交信します。代わりに TCP を使用することもできます。レシーバがファイヤーウォールで隔てられている場合は、レシーバを周辺ネットワークに移動する必要があります。これが不可能な場合は、トランスミッタからレシーバへの転送プロトコルを TCP に変更します。詳細については、第 9 章「トランスミッタとレシーバ」を参照してください。

Helix Universal Proxy との通信

通常、Helix Universal Proxy サーバーはファイヤーウォールで隔てられて配置されます。この点で、Helix Universal Server と Helix Universal Proxy との接続は、Helix Universal Server とクライアントとの接続に似ていますが、HTTP 通信は使用できません。Helix Universal Proxy は、まずデータ転送に UDP を使用して RTSP で接続を試みます。ファイヤーウォールで UDP 接続が禁止されている場合、Helix Universal Proxy は、データ転送に TCP を使用して RTSP で接続を試みます。Helix Universal Proxy では、HTTP 配信は利用できません。したがって、ファイヤーウォールで RTSP が禁止されていると、Helix Universal Proxy はクライアントに代わってストリームをプロキシすることができません。

ファイヤーウォールで隔てられたクライアント ソフトウェア
へのストリーミング配信

ここでは、ファイヤーウォールで隔てられているクライアントがストリーミング メディアを視聴するときに、どのようなテクノロジを使って Helix Universal Server と通信するかについて説明します。クライアントの接続機能に対応するように Helix Universal Server をセットアップするための参考になります。

チャネル ネゴシエーション

Helix Universal Server は、クライアントと交信するためにチャネルと呼ばれる 2 つの接続を使用します。

• 制御チャネル

Helix Universal Server はこのチャネルを使ってクライアントと通信します。このチャネルで、Helix Universal Server はパスワードの要求と受信を行い、クライアントは早送り、一時停止、停止などの指示を送信します。

• データ チャネル

メディア クリップ自体は、別のデータ チャネル上でストリーミング配信されます。

Helix Universal Server と RealOne Player との通信

トランスポート レイヤでは、優先使用されるプロトコルがファイヤーウォールでブロックされているために最初の通信が失敗した場合でも、RealOne Player を含むほとんどのメディア プレイヤーが対処できます。対処方法としては、ブロックされていないプロトコルと配信方法に自動的に切り替える手法が主に使用されます。典型的な例として、クライアントは制御チャネルを TCP に切り替えます。TCP は UDP よりも低効率ですが、ブロックされていることが少ないからです。

制御接続が確立されると、次にクライアントはデータ チャネルのネゴシエーションを行います。可能な場合、データ チャネルでは、より効率の良い UDP 転送が使用されます。ライブ ストリームの場合、RealOne Player など一部のクライアント ソフトウェアは、まず UDP マルチキャストをセットアップしようとします。これが失敗すると、次にクライアントは UDP ユニキャストでの受信を試みます。これも失敗すると、クライアントは確立されている制御チャネルをデータ用に使用します。つまり、クライアントは最適なデータ配信方法からセットアップを試し、最終手段として制御チャネルを使用します。

詳細情報 : ユニキャストとマルチキャストについては、それぞれ第 7 章と第 8 章を参照してください。

HTTP クローキング

一部のファイヤーウォールでは RTSP や MMS などのストリーミング メディア プロトコルが制限されていることがあり、そのためクライアントが制御接続を確立できないことがあります。このような場合、クライアントとサーバーでは、ストリーミング メディア トラフィックを HTTP として偽装させます。これが HTTP クローキングと呼ばれる手法です。HTTP トラフィックはほとんどのファイヤーウォールで許可されているため、この手法で通信の問題を回避できます。ただし、HTTP はストリーミング メディア用に設計されていないため、ユーザーが受信するストリームの品質は劣ります。

HTTP クローキング手法では、HTTP プロトコルの制限事項にも対処する必要があります。たとえば、RTSP クライアントは、2つの HTTP ストリームを使って単一の Helix Universal Server に接続します。どちらのストリームもクライアントが開始するため、クライアントのファイヤーウォールでは通常、これらの接続を発信 HTTP トラフィックとして許可します。最初の接続は、HTTP の GET 方法を使用します。これは、ブラウザが Web ページを要求するときに使用する標準の方法です。受信側末端の Helix Universal Server では、HTTP 偽装を除去し、カプセル化されている RTSP 情報に従って、クライアントにどの情報を送信するかを決定します。

次に Helix Universal Server では、メディアのストリーミング配信を開始するために、同じクライアントから 2 番目の HTTP 接続を待つ必要があります。2 番目の接続は、HTTP の POST 方法を使用します。これは、Web サーバーがブラウザにデータを送信するときに使用する標準の方法です。クライアントによって開始されたこれらのストリームが両方とも確立されると、RTSP をブロックするファイヤーウォールで隔てられていても、クライアントと Helix Universal Server は RTSP パケットを双方向にやり取りできます。

HTTP トラフィック用のポート 80

HTTP クローキングが機能するためには、クライアントが Helix Universal Server のHTTP ポートに接続する必要があります。Helix Universal Server が、HTTP 用としてよく知られたポート 80 を使用する場合には問題ありません。しかしそれ以外のポートを HTTP 用に使用する場合、問題となる可能性があります。使用するポートがクライアントでわかっていても、ポート 80 への発信 HTTP トラフィックがファイヤーウォールで制限されていると、クライアントは接続できません。

このような理由から、Helix Universal Server の HTTP ポートとしてはポート 80 を設定することをお勧めします。このように設定することで、最大限の種類のプレイヤー ソフトウェアをサポートできます。この設定が不可能な場合でも、RealOne Player と RealPlayer 8 は、Helix Universal Server の HTTP ポートを検出できることが多く、発信方向の通信がファイヤーウォールでブロックされていない限り、その HTTP ポートに接続できます。ただし、すべてのプレイヤーで可能とは限りません。

詳細情報 : Helix Universal Server と Web サーバーを同じマシンにインストールした場合は、Helix Universal Server にポート 80 を割り当てる前にいくつかの対策が必要です。詳細については、「Web サーバーと Helix Universal Server」を参照してください。

ポート ヒンティング

デフォルトのポート値を使用できない Helix Universal Server では、ポート ヒンティングが役立ちます。ポート ヒンティングを使用すると、Ramgen ユーティリティを使ってクリップを起動するときに、Helix Universal Server は使用中のポート番号を RealOne Player や RealPlayer 8 に送信できます。この機能はデフォルトで有効になっています。コンテンツ制作者は、Ram ファイルを定義するときに、Helix Universal Server マシンへの接続を試行するポートを定義することもできます。

詳細情報 : これらの機能の詳細については、「標準以外のポートによる通信の処理」を参照してください。

デフォルト ポート

ここでの説明は、ファイヤーウォールでどのポートを開くかを決定するために役立ちます。このリストにあるポートの一部を開かないようにするには、詳細について http://service.jp.real.com/firewall を参照してください。

Helix Universal Server のデフォルト ポート

次の表に、Helix Universal Server がメディア クライアントやほかのサーバーとの通信に使用するデフォルト ポートを示します。

レシーバのデフォルト ポート

レシーバが独自のコンテンツを （スプリットとは別に） 配信している場合は、次の表に示す値のほかに、「Helix Universal Server のデフォルト ポート」で説明したすべての値が使用されます。

Helix Universal Proxy のデフォルト ポート

次の表に、Helix Universal Proxy で使用されるデフォルト ポートを示します。

エンコーダのデフォルト ポート

Helix Producer では、エンコーダにさまざまな動作をセットアップできます。次の表では、Helix Producer の通信モードである旧式 モードとアカウント ベース トランスミッタ モードについて説明します。新しいエンコーディング方式を使用するとき、Helix Producer はトランスミッタのように動作します。トランスミッタとして動作するように Helix Producer をセットアップした場合は、「Helix Universal Server のデフォルト ポート」に示されているポートとプロトコルを使用してください。

RealProducer G2 (バージョン 6) 以降では、データ接続に TCP を使用するように RealProducer に指示できます。より良い配信品質が得られる UDP を推奨しますが、エンコーダと Helix Universal Server の間にファイヤーウォールがある場合は TCP が必要になることもあります。TCP を使用する場合は、制御チャネルとデータ チャネルの両方でポート 4040 が使用されます。

注意 : RealEncoder/Publisher 5 以前では、ポート 5050 で TCP データおよび制御チャネルを使用します。

メディア プレイヤーのデフォルト ポート

RealOne Player、RealPlayer 6 〜 8、Windows Media Player、および QuickTime Playerで使用される通信ポートを次の表に示します。RealOne Player では、この表の設定に加えて、デフォルトのブラウザからプロキシ設定 (設定されている場合) を継承します。ただし、RealOne Player の [Preferences (環境設定)] メニューでこの機能を無効にすることもできます。

Helix Universal Server は制御チャネル要求を受信すると、クライアント指定のポート番号にデータを送ります。RealOne Player と RealPlayer は、データ チャネルに UDP を選択し、データ チャネルのポート番号として 6970 から 32000 までの値を指定します。 Windows Media Player も UDP を選択し、データ チャネルのポート番号として 1024 から 5000 までの値を指定します。 クライアントがデータ チャネルに TCP を選択した場合、Helix Universal Server は制御チャネルとデータ チャネルの両方に対して同じポート番号を使用します。

RealPlayer G2 (バージョン6) より前のバージョンの RealPlayer では、次のポートが使用されます。

© 2002 RealNetworks, Inc. All rights reserved. 詳細については、RealNetworks を参照してください。 画面左側に目次フレームが表示されない場合は、ここをクリックしてください。