close

Enter

Log in using OpenID

コンピュータネットワークB 問題提起: ビデオが見たい 転送しながら再生

embedDownload
問題提起: ビデオが見たい
コンピュータネットワークB
• ダウンロードが長い
• ディスクを占領する
– 6Mbps×3600秒=21600Mビット=2.7Gバイト
– 10Mbpsでの転送時間=21600Mビット/10Mビット
=2160秒=36分 待ちたくない
第12回
リアルタイム通信 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
• ほとんどIPのまま
• 再送・順序整列・重複除去
流量制御・輻輳制御
はしない
• パケットへの分割もしない
TCP
アプリ
• 片方向通信では、遅延より遅延変動が問題
アプリ
• トランスポート層だが
アプリ
(脱線)遅延と遅延変動の違い
アプリ
UDPを使う ~ UDPとは
UDP
IP
データリンク
物理層
• ポートだけ追加
Page 7
2005秋 ネットワークB
2006/1/10
脱線: 実はTCPも使われる
– ストリーミングで見た話 ~ 遅延が変わると困る
– 遅延の絶対値は(そこそこ)長くてもいい
クリックから再生開始までが延びるだけ
• 対話型通信では、遅延自体が問題
– 「もしもし」と「はいはい」の間が伸びて話しづらい
0.3秒を越えると会話が不自然になる
Page 8
2005秋 ネットワークB
RTP Real Time Protocol
• MS Media PlayerにせよRealVideoにせよ
• リアルタイム通信を制御するプロト
TCP転送モードはサポートしている
• なぜ?
コル
• 大したことはしていない
– 理由① ファイヤウォールを乗り越えやすい
組織入口で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(制御情報交換用パケット)
アプリ
RTP
UDP
IP
データリンク
物理層
• パケット損失率、遅延、遅延変動などを
測定、報告
Page 10
2005秋 ネットワークB
2006/1/10
ライブデータのストリーミング
• コンサート、講演会...(スポーツとか?)
• 遅延を気にするか? 数秒ならよいか?
– ゴールシーンが数秒遅れると?
• 大勢に効率よく配る必要
– 大勢が同時にアクセス ⇒ サーバ負荷集中
– 「マルチキャスト」で解決できるが...
現実にはほとんど使われない ~ 理由?
Page 12
2005秋 ネットワークB
2006/1/10
2
IP電話
IP電話
• 普通の電話 vs IP電話
– 普通電話 = 電話線上を音声転送
アナログ 又は ディジタル
回線を占有(回線交換)、0/1列を送る
占有するから高い+交換機が専用で高
い
– IP電話 = IPネットワーク上を音声転送
ディジタル
パケット交換、パケットの形にまとめて送る
声のときだけパケットなので大勢で共有、
IPルータは汎用製品で安い
Page 13
2005秋 ネットワークB
2006/1/10
IP電話
• 声をIPで運ぶこと自体は難しくないが...
• 遅延が非常に問題
– 0.3秒を越えると、対話が不自然
– 符号化、復号化の遅延があるので、ネットワークに
許されるのは0.1秒以下、0.05秒(50mS)程度
• パケット損失の問題 ~ 回復する時間がない
• 「呼制御」の必要性
– 接続制御、会議通話など 既存電話での追加機能
• 既存電話との接続・親和性
Page 14
電話番号、119
2005秋 ネットワークB
2006/1/10
UDP いつ使うか? (教科書)
• 遠距離電話部分だけをIP電話 ⇒ 実用
– 専用のIPネットワークを使う
• 総パケット数が少ない通信
• 同一プロバイダ内のみでIP電話 ⇒ 実用
– ある程度余裕を持ったNW設計。品質保証はできない
携帯電話の品質に慣れたので多少悪くてもよい?
– TCPではコネクション設定などのやり取りの方
が多くなってしまうとき
• 動画や音声などのマルチメディア通信
• 一般インターネット間でのIP電話 ⇒ 最近スカイプ
– 再送による遅延変動がいやだ
• 既存電話との通話
– 電話番号問題 ⇒ 050の割当開始
– パケット損失の被害が少ない
• 既存電話の置き換え ⇒ たとえば119サービス?
– 「ライフライン」に耐えるか? (非常時)
Page 15
2005秋 ネットワークB
2006/1/10
– 注: とは言うけれど、TCPを使う場合もある
品質保証
2005秋 ネットワークB
2006/1/10
品質保証のためのプロトコル
• ビデオや電話を品質よく転送したい
– リアルタイム転送だと、
大きい帯域を長い時間取る~ネット負荷大
遅延変動を小さく押さえなければならない
• 2つの考え方
– 確実にうまくいくとは限らないが優先的に転送
ベストエフォートの中で優先度制御
– 確実にうまくいくように、同時利用者数を制限
一定数を超える場合は、接続時に断る
(アドミッションコントロール) 品質保証
Page 17
Page 16
2005秋 ネットワークB
2006/1/10
• RSVP 帯域予約プロトコル
– ReSource Reservation Protocol
• 送信端から受信端までの間の
全てのリンクで必要帯域を予約する
• 実際にはほとんど使われていない
– 予約すると帯域の利用効率が下がる
– そこそこの性能が出るぐらい広帯域になった
(余裕が出来た)
Page 18
2005秋 ネットワークB
2006/1/10
3
まとめ
(12-1) リアルタイム通信(ストリーミング)の原理
を説明せよ
(12-2) リアルタイム通信(ストリーミング)のメ
リットを整理せよ
(12-3) (調査問題)「通信」と「放送」の違いを
調べてみよ。ネット上での「放送」に対する
法規制や、マルチキャストの法的扱いに
ついて調べてみよ。
Page 19
2005秋 ネットワークB
2006/1/10
4
Author
Document
Category
Uncategorized
Views
0
File Size
154 KB
Tags
1/--pages
Report inappropriate content