コンピュータネットワーク 第１２回 リアルタイム通信、UDP/RTP ２００３年７月８日 山内長承 1 ＵＤＰ • ＴＣＰと同じレベル • 機能は、ほとんど何 もしない – コネクションなし – 順序、再送をしない • ポートはサポート ア プ リ ア プ リ ＴＣＰ ア プ リ ＵＤＰ ＩＰ データリンク 物理層 2 ＵＤＰヘッダ ３２ビット ヘ ッ ダ 宛先ポート番号 送信元ポート番号 パケット長 チェックサム データ 3 ＵＤＰ いつ使うか？ • 総パケット数が少ない通信 – ＴＣＰではコネクション設定などのやり取りの方 が多くなってしまうとき • 動画や音声などのマルチメディア通信 – 再送による遅延変動がいやだ – パケット損失の被害が少ない – 注： とは言うけれど、ＴＣＰを使う場合もある • あとでもう少し突っ込んで見ましょう 4 リアルタイム通信 • リアルタイム通信とは – 教科書： 「送信したデータがなるべく早く宛先に届く通信」 • 山内流解釈： – 送られてきたデータをすぐに使う場合 – ビデオダウンロード問題 ～ 見るまで待たされる ⇒ 到着した部分はすぐに再生を始める ～ 待たない 5 リアルタイム通信 ダウン ロード 方式 ストリー ミング 方式 download play download play これをリアルタイム通信と称することが多い 6 ＴＣＰの再送が起こると遅延 • パケット損失 ⇒ 再送 ⇒ 遅れる sender time Retrans NACK mission receiver delay • 再生に間に合わなくなる • だからＵＤＰを使いたくなる 7 キーワード： 遅延とジッタ（遅延の変動） • 片方向通信： 遅延より遅延変動が問題 • インタラクティブ通信： 遅延そのものが問題 sender time 遅 延 receiver 遅延 遅延 遅延が 伸びた 8 脱線： 実はＴＣＰも使われる • MS Media PlayerにせよRealVideoにせよ ＴＣＰ転送モードはサポートしている • なぜ？ – 理由① ファイヤウォールを乗り越えやすい – 理由② 片方向転送ならバッファリングで逃 げられる 9 ＲＴＰ Real Time Protocol • リアルタイム通信を制御する 大したことはしない • ＲＴＰ： 流すデータにつけるヘッダ ＋ ＲＴＣＰ： 制御用の情報を別に流す • ＲＴＰヘッダ： タイムスタンプ、シーケンス番号 • ＲＴＣＰパケット： 「補助」というが結構大変 – パケット損失率、遅延、遅延変動などを測定、報告 10 例： ストリーミング～ 蓄積コンテンツ • 音楽やビデオをインターネット配信 ⇒ 実用 • 難しさ： 遅延の変動（ジッター） ⇒ 数秒のバッファリングが必要（？） • その上に（セッション）制御用のプロトコル必要 – どんな内容か？ どんな符号化、どんなレート？ – Session Description Protocol, Real-Time Streaming Protocol, ... 11 例： ストリーミング ～ ライブ中継 • コンサート、講演会、ニュース放送．．． • 遅延を気にするか？ 数秒ならＯＫ？ • 大勢に効率よく配る マルチキャスト • 途中から見るための工夫 12 例： ＩＰ電話 • 声をＩＰで運ぶこと自体は難しくないが．．． • 遅延が非常に問題 – 0.3秒を越えると、対話が不自然 – 符号化、復号化の遅延があるので、ネットワークに許 されるのは0.1秒以下、0.05秒（50mS）程度 • パケット損失の問題 ～ 回復する時間がない • 「呼制御」の必要性 – 接続制御、会議通話など 既存電話での追加機能 • 既存電話との接続・親和性 電話番号、11913 ＩＰ電話 • 遠距離電話部分だけをＩＰ電話 ⇒ 実用 – 専用のＩＰネットワークを使う • 同一プロバイダ内のみでＩＰ電話 ⇒ 実用 – ＢＢフォンなど、品質保証はつらいがある程度使える （注）携帯電話の品質に慣れたので多少悪くてもよ い？ – プロバイダ間での接続の検討 • 既存電話との通話 – 電話番号問題 ⇒ 050の割当開始。 課金は？ • 既存電話の置き換え ⇒ たとえば119サービス？ – 「ライフライン」に耐えるか？ 14 品質保証 • リアルタイム ⇒ 帯域・遅延制約 • ルータで特別扱いし、優先的に転送 • 設定 ＲＳＶＰ 帯域予約プロトコル ＲｅＳｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ 15
© Copyright 2024 ExpyDoc
