問題提起： ビデオが見たい
コンピュータネットワークＢ
• ダウンロードが長い
• ディスクを占領する
– 6Mbps×3600秒＝21600Mビット＝2.7Gバイト
– 10Mbpsでの転送時間＝21600Mビット/10Mビット
＝2160秒＝36分 待ちたくない
第１２回
リアルタイム通信 UDP・RTP、品質保証
リアルタイム通信/ストリーミングの原理・
TCPの問題とUDP/RTPの利用・通信品質保証
• 昔： 回線遅い・ディスク小さい （マジつらかった）
⇒ 今： 回線早い・ディスク大きい（問題ない？）
でも長いコンテンツが見たいし．．．
Page 2
転送しながら再生
ダウンロード
2006/1/10
リアルタイム通信
• 全部貯まるのを待たない～ストリーミング通信
ダウン
ロード
方式
2005秋 ネットワークB
再生
• リアルタイム通信とは
– 教科書：
「送信したデータがなるべく早く宛先に届く通信」
この間待たされる
• 私の解釈：
– 送られてきたデータをすぐに使う場合
ダウンロード
ストリー
ミング
方式
待時間
再生している
間に次を転送
Page 3
• ダウンロード完了を待ちたくない場合
再生
2005秋 ネットワークB
2006/1/10
Page 4
2005秋 ネットワークB
2006/1/10
リアルタイム通信での転送
ストリーミングではTCPは問題あり
• リアルタイム通信では
• パケット損失 ⇒ 再送 ⇒ 遅れる
＝ 遅れずにデータが次々と着く必要
サーバ
サーバ 送出 ① ② ③
ACKが来ない
再送
端末
到着が遅れた
遅れ
到着 ① ② ③
端末
本来再生開始
するべき時刻
Page 5
2005秋 ネットワークB
途切れる
再生
① ② ③
データが実際
到着した時刻
2006/1/10
• 再生タイミングに間に合わなくなる
• TCPの再送が問題 ⇒ 再送をやめたい
Page 6
2005秋 ネットワークB
2006/1/10
1
• ほとんどＩＰのまま
• 再送・順序整列・重複除去
流量制御・輻輳制御
はしない
• パケットへの分割もしない
ＴＣＰ
アプリ
• 片方向通信では、遅延より遅延変動が問題
アプリ
• トランスポート層だが
アプリ
（脱線）遅延と遅延変動の違い
アプリ
ＵＤＰを使う ～ ＵＤＰとは
ＵＤＰ
ＩＰ
データリンク
物理層
• ポートだけ追加
Page 7
2005秋 ネットワークB
2006/1/10
脱線： 実はＴＣＰも使われる
– ストリーミングで見た話 ～ 遅延が変わると困る
– 遅延の絶対値は（そこそこ）長くてもいい
クリックから再生開始までが延びるだけ
• 対話型通信では、遅延自体が問題
– 「もしもし」と「はいはい」の間が伸びて話しづらい
0.3秒を越えると会話が不自然になる
Page 8
2005秋 ネットワークB
ＲＴＰ Real Time Protocol
• MS Media PlayerにせよRealVideoにせよ
• リアルタイム通信を制御するプロト
ＴＣＰ転送モードはサポートしている
• なぜ？
コル
• 大したことはしていない
– 理由① ファイヤウォールを乗り越えやすい
組織入口でTCPのポート80しか通さないなど
– 理由② 片方向転送ならバッファリングで逃げる
• 到着したデータをバッファに貯める
• 到着が途切れてもバッファに貯めたデータでしのげる
• バッファに貯めている時間だけ、再生開始が遅れる
Page 9
2005秋 ネットワークB
2006/1/10
蓄積コンテンツのストリーミング
• 音楽やビデオをインターネット配信 ⇒ 実用
• 難しさ： 遅延の変動（ジッター）
⇒ 数秒のバッファリングが必要（？）
• その上に（セッション）制御用のプロトコル必要
– どんな内容か？ どんな符号化、どんなレート？
– Session Description Protocol,
Real-Time Streaming Protocol, ...
Page 11
2005秋 ネットワークB
2006/1/10
2006/1/10
– パケットの順序番号
– パケットのタイムスタンプ（再生時刻）
– 複数ストリームの区別
– RTCP（制御情報交換用パケット）
アプリ
ＲＴＰ
ＵＤＰ
ＩＰ
データリンク
物理層
• パケット損失率、遅延、遅延変動などを
測定、報告
Page 10
2005秋 ネットワークB
2006/1/10
ライブデータのストリーミング
• コンサート、講演会．．．（スポーツとか？）
• 遅延を気にするか？ 数秒ならよいか？
– ゴールシーンが数秒遅れると？
• 大勢に効率よく配る必要
– 大勢が同時にアクセス ⇒ サーバ負荷集中
– 「マルチキャスト」で解決できるが．．．
現実にはほとんど使われない ～ 理由？
Page 12
2005秋 ネットワークB
2006/1/10
2
ＩＰ電話
ＩＰ電話
• 普通の電話 vs ＩＰ電話
– 普通電話 ＝ 電話線上を音声転送
アナログ 又は ディジタル
回線を占有（回線交換）、0/1列を送る
占有するから高い＋交換機が専用で高
い
– ＩＰ電話 ＝ ＩＰネットワーク上を音声転送
ディジタル
パケット交換、パケットの形にまとめて送る
声のときだけパケットなので大勢で共有、
ＩＰルータは汎用製品で安い
Page 13
2005秋 ネットワークB
2006/1/10
ＩＰ電話
• 声をＩＰで運ぶこと自体は難しくないが．．．
• 遅延が非常に問題
– 0.3秒を越えると、対話が不自然
– 符号化、復号化の遅延があるので、ネットワークに
許されるのは0.1秒以下、0.05秒（50mS）程度
• パケット損失の問題 ～ 回復する時間がない
• 「呼制御」の必要性
– 接続制御、会議通話など 既存電話での追加機能
• 既存電話との接続・親和性
Page 14
電話番号、119
2005秋 ネットワークB
2006/1/10
ＵＤＰ いつ使うか？ （教科書）
• 遠距離電話部分だけをＩＰ電話 ⇒ 実用
– 専用のＩＰネットワークを使う
• 総パケット数が少ない通信
• 同一プロバイダ内のみでＩＰ電話 ⇒ 実用
– ある程度余裕を持ったＮＷ設計。品質保証はできない
携帯電話の品質に慣れたので多少悪くてもよい？
– ＴＣＰではコネクション設定などのやり取りの方
が多くなってしまうとき
• 動画や音声などのマルチメディア通信
• 一般インターネット間でのＩＰ電話 ⇒ 最近スカイプ
– 再送による遅延変動がいやだ
• 既存電話との通話
– 電話番号問題 ⇒ 050の割当開始
– パケット損失の被害が少ない
• 既存電話の置き換え ⇒ たとえば119サービス？
– 「ライフライン」に耐えるか？ （非常時）
Page 15
2005秋 ネットワークB
2006/1/10
– 注： とは言うけれど、ＴＣＰを使う場合もある
品質保証
2005秋 ネットワークB
2006/1/10
品質保証のためのプロトコル
• ビデオや電話を品質よく転送したい
– リアルタイム転送だと、
大きい帯域を長い時間取る～ネット負荷大
遅延変動を小さく押さえなければならない
• ２つの考え方
– 確実にうまくいくとは限らないが優先的に転送
ベストエフォートの中で優先度制御
– 確実にうまくいくように、同時利用者数を制限
一定数を超える場合は、接続時に断る
（アドミッションコントロール） 品質保証
Page 17
Page 16
2005秋 ネットワークB
2006/1/10
• ＲＳＶＰ 帯域予約プロトコル
– ＲｅＳｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ
• 送信端から受信端までの間の
全てのリンクで必要帯域を予約する
• 実際にはほとんど使われていない
– 予約すると帯域の利用効率が下がる
– そこそこの性能が出るぐらい広帯域になった
（余裕が出来た）
Page 18
2005秋 ネットワークB
2006/1/10
3
まとめ
(12-1) リアルタイム通信（ストリーミング）の原理
を説明せよ
(12-2) リアルタイム通信（ストリーミング）のメ
リットを整理せよ
(12-3) （調査問題）「通信」と「放送」の違いを
調べてみよ。ネット上での「放送」に対する
法規制や、マルチキャストの法的扱いに
ついて調べてみよ。
Page 19
2005秋 ネットワークB
2006/1/10
4