[コンピュータネットワーク] 18. マルチメディアネットワーキングとストリーミング

マルチメディアアプリケーションの種類
======================================

1. 蓄積型メディアストリーミング（Streaming Stored Media）
   - Netflix、YouTube、Hulu
   - 事前録画されたコンテンツを再生
   - 若干の遅延は許容（バッファリング）

2. リアルタイムストリーミング（Live Streaming）
   - Twitch、スポーツ中継
   - リアルタイムコンテンツを若干の遅延で配信
   - 10秒以内の遅延が目標

3. 対話型リアルタイム（Interactive Real-Time）
   - VoIP（Skype、Zoom、Discord）
   - ビデオ会議、オンラインゲーム
   - 150ms以内の遅延が必要（厳格）

ビデオ圧縮の原理
==================

非圧縮ビデオ：
  - 解像度：1920 x 1080（Full HD）
  - 色：24ビット/ピクセル
  - フレーム：30fps
  - ビットレート：1920 x 1080 x 24 x 30 = 約1.5 Gbps

圧縮後：
  - H.264/AVC：1~10 Mbps（Full HD）
  - H.265/HEVC：0.5~5 Mbps（Full HD）

圧縮技法：
  1. 空間的冗長性（Spatial Redundancy）
     - フレーム内の隣接ピクセルの類似性を活用
     - Iフレーム：独立圧縮

  2. 時間的冗長性（Temporal Redundancy）
     - 連続フレーム間の差分のみをエンコード
     - Pフレーム：前のフレームとの差分
     - Bフレーム：前後のフレームとの差分

ビットレート方式
=================

CBR（Constant Bit Rate）：
  ビットレートが一定
  |_______________________________________
  |========================================
  |========================================
  +----------------------------------------> 時間

VBR（Variable Bit Rate）：
  シーンの複雑さに応じてビットレートが変動
  |         ___
  |   __   |   |  _    ___
  |__|  |__|   |_| |__|   |___
  +----------------------------------------> 時間
    静的  動的  静的 動的  静的

VBRが一般的：同じ平均ビットレートでより良い画質

HTTPストリーミングの動作
==========================

サーバ                              クライアント
  |                                    |
  |<-- HTTP GET（ビデオファイル要求）----|
  |                                    |
  |--- HTTP応答（ビデオデータ）-------->|
  |     TCPを通じて順次転送            |
  |                                    | [受信バッファ]
  |                                    |     |
  |                                    | [クライアントバッファ]
  |                                    |     |
  |                                    | [ビデオ再生]

クライアントバッファの動作：
  - 十分なデータが溜まったら再生開始
  - TCPが輻輳制御で送信レートを調整
  - バッファが空になるとリバッファリング（再生中断）

DASHの動作原理
================

サーバ側準備：
  元のビデオを複数のビットレートでエンコードしチャンクに分割

  ビットレート1（240p）：[C1][C2][C3][C4][C5]...  0.5 Mbps
  ビットレート2（480p）：[C1][C2][C3][C4][C5]...  1.5 Mbps
  ビットレート3（720p）：[C1][C2][C3][C4][C5]...  3.0 Mbps
  ビットレート4（1080p）：[C1][C2][C3][C4][C5]... 6.0 Mbps
  ビットレート5（4K）：  [C1][C2][C3][C4][C5]...  15.0 Mbps

  マニフェストファイル（MPD）：各チャンクのURLとビットレート情報

クライアント動作：
  1. マニフェストファイルをダウンロード
  2. 現在の利用可能帯域幅を測定
  3. 帯域幅に合ったビットレートの次のチャンクを要求
  4. 帯域幅の変化に応じてビットレートを動的に調整

時間に伴うビットレートの変化：
  [720p][720p][1080p][1080p][480p][480p][720p][1080p]
                      ^帯域幅増加  ^帯域幅減少  ^回復

CDNなし vs CDN使用
====================

CDNなし：
  米国サーバ <=============> 韓国ユーザー（遅延200ms+）
  米国サーバ <=============> ブラジルユーザー（遅延300ms+）
  米国サーバ <=============> オーストラリアユーザー（遅延250ms+）
  --> 1つのサーバに負荷集中、長い遅延

CDN使用：
  [オリジンサーバ]
       |
  [CDNサーバ：ソウル] <--> 韓国ユーザー（遅延10ms）
  [CDNサーバ：サンパウロ] <--> ブラジルユーザー（遅延15ms）
  [CDNサーバ：シドニー] <--> オーストラリアユーザー（遅延12ms）
  --> ユーザーの近くからコンテンツを配信

CDN配置戦略
=============

1. Enter Deep（進入戦略）
   - ISPのアクセスネットワーク内部にサーバを配置
   - ユーザーに非常に近い
   - 管理が困難（サーバ数が非常に多い）
   - Akamai方式：世界中に24万台以上のサーバ

2. Bring Home（集結戦略）
   - IXP（Internet Exchange Point）近くに大規模サーバクラスタを配置
   - 管理が容易
   - ユーザーとやや遠い距離
   - Limelight、Google CDN方式

CDNコンテンツ配信過程
========================

ユーザーがvideo.example.com/movie.mp4を要求：

1. ユーザーブラウザがDNS検索：video.example.com
2. オリジンDNSがCDNのDNSにCNAMEリダイレクト
3. CDN DNSがユーザーに最も近いCDNサーバIPを返却
4. ユーザーがCDNサーバに直接HTTP要求
5. CDNサーバがコンテンツを配信（キャッシュヒット時即座に、ミス時オリジンから取得）

DNSベースのCDNサーバ選択：
  ユーザー位置 --> ローカルDNS IP --> CDN DNS
  CDN DNSが地理的に最も近いサーバIPを返却

Netflixストリーミングアーキテクチャ
=====================================

[Netflixクライアントアプリ]
        |
        | 1. ログイン、検索、おすすめ
        v
[AWSクラウド]（Netflixバックエンド）
  - ユーザー認証
  - コンテンツ推薦
  - DRMライセンス
  - マニフェストファイル生成
        |
        | 2. ストリーミングURL（CDNサーバアドレス）
        v
[Netflixクライアントアプリ]
        |
        | 3. DASHベースのビデオストリーミング
        v
[Netflix Open Connect CDN]
  - 自社CDNインフラ
  - ISP内部にOCA（Open Connect Appliance）を設置
  - 人気コンテンツを事前配布（オフピーク時間帯）

VoIPの要件
============

- 許容可能な遅延：150ms以下（良好）、400ms以下（許容）
- パケット損失：1~5%の損失はFECで回復可能
- ジッタ：パケット到着間隔の変動 --> プレイアウト遅延で補償

音声エンコーディング：
  PCM：8000サンプル/秒 x 8ビット = 64 Kbps
  パケット化：20msごとに160バイト + ヘッダ = 約200バイトのパケット

ジッタ（Jitter）の問題
========================

送信側：パケットを一定間隔（20ms）で送信
  |P1|  |P2|  |P3|  |P4|  |P5|（20ms間隔）

ネットワークを経ると到着間隔が不規則に：
  |P1|    |P2||P3|      |P4|  |P5|（可変間隔）

解決：プレイアウトバッファ（Playout Buffer）
  - 受信パケットをバッファに格納
  - 一定の遅延後にバッファから均等間隔で再生

プレイアウト遅延の設定：
  固定プレイアウト遅延：
    すべてのパケットに同一の遅延を適用
    遅延が大きい：パケット損失は少ないが会話遅延が増加
    遅延が小さい：自然な会話だが遅れたパケットは破棄

  適応型プレイアウト遅延：
    発話区間（talkspurt）の間に遅延を調整
    ネットワーク遅延の平均と分散を推定して動的に調整

VoIP損失回復技法
==================

1. FEC（Forward Error Correction）
   方法A：冗長パケット送信
     元：    [P1][P2][P3][P4]
     XOR：   [P1^P2][P2^P3][P3^P4]
     P2損失時：P1^P2 XOR P1 = P2を回復

   方法B：低品質コピーの挿入
     [P1高品質][P1低品質コピー | P2高品質][P2低品質コピー | P3]
     P2損失時にP2低品質コピーで代替

2. インターリービング（Interleaving）
   元：         [1,5,9,13] [2,6,10,14] [3,7,11,15] [4,8,12,16]
   インターリーブ：[1,2,3,4] [5,6,7,8] [9,10,11,12] [13,14,15,16]

   1パケット損失時に連続的でなく分散した損失
   --> 補間（interpolation）で回復可能

トラフィック別QoS要件
========================

トラフィック種類 | 帯域幅  | 遅延    | ジッタ  | 損失
-----------------+---------+---------+--------+--------
メール           | 低      | 無関係  | 無関係  | 0%必要
Webブラウジング  | 中      | 低      | 無関係  | 0%必要
ファイル転送     | 高      | 無関係  | 無関係  | 0%必要
VoIP             | 低      | 非常に低| 低      | 一部許容
ビデオストリーミング| 高   | 低      | 低      | 一部許容
オンラインゲーム | 低      | 非常に低| 非常に低| 一部許容

QoSメカニズム
===============

1. マーキング（Marking）
   - パケットに優先度を表示
   - IPヘッダのToS/DSCPフィールドを使用
   - 高い優先度：VoIP、ビデオ会議
   - 低い優先度：ファイルダウンロード、メール

2. ポリシング（Policing）
   - トラフィックが合意された速度を超えないように制限
   - トークンバケット：トークンが一定速度で生成、パケット送信時に消費

3. スケジューリング（Scheduling）
   - 優先度キューイング、WFQなど
   - 高い優先度のトラフィックを先に処理

4. アドミッション制御（Admission Control）
   - ネットワークが新しいフローを受け入れられるか判断
   - 受け入れ不可の場合は拒否

トークンバケットアルゴリズム
==============================

パラメータ：
  r = トークン生成速度（tokens/sec）
  b = バケットサイズ（最大トークン数）

動作：
  - トークンがrの速度でバケットに蓄積
  - パケット送信時にトークンを消費
  - トークンがなければパケットは待機または破棄
  - バケットが満杯なら新しいトークンを破棄

効果：
  - 平均送信レート：rに制限
  - 瞬間的なバースト：bまで許容

  トークン数
  b |____
    |    \___
    |        \___
    |    バースト  \___平均r
    +-------------------> 時間

Diffservアーキテクチャ
========================

インターネットでQoSを提供するためのスケーラブルなフレームワーク

動作：
  1. エッジルータ：パケットの分類とマーキング（DSCP設定）
  2. コアルータ：DSCP値に基づく差別化された処理

DSCP（Differentiated Services Code Point）：
  IPヘッダのToSフィールドの6ビットを使用

PHB（Per-Hop Behavior）：
  - EF（Expedited Forwarding）：最優先処理（VoIPなど）
  - AF（Assured Forwarding）：保証された転送（4クラス）
  - BE（Best Effort）：デフォルト処理（一般トラフィック）

利点：スケーラブル、フローごとの状態が不要
短所：厳密なQoS保証が困難