多媒体网络

多媒体网络不是一组协议的集合，而是在不可靠、无保证的网络之上，构造"人类可感知连续体验"的系统工程。

一、多媒体网络的第一性原理

1. 本质矛盾

多媒体网络面对的是一组不可消除、只能权衡的根本矛盾：

  1. **人类感知是连续的，而网络是离散的**
  2. **网络是尽力而为的，而体验必须是可控的**
  3. **实时性要求与可靠性机制天然冲突**
  4. **网络不可预测，而应用必须“看起来稳定”**

这些矛盾决定了： 👉 多媒体网络无法依赖网络本身的确定性，只能通过端系统与应用层机制进行补偿。

2. 多媒体系统的核心目标

多媒体网络并不追求“网络指标最优”，而是追求：

感知质量最优（QoE, Quality of Experience）

因此，系统设计遵循的不是“零丢包、零错误”，而是：

二、端到端多媒体网络的抽象架构

1. 分层不是 OSI，而是“能力分工”

┌──────────────────────┐
│ 用户感知层（QoE）     │ ← 连续体验、音画同步
├──────────────────────┤
│ 应用适配层            │ ← 编码、缓存、自适应
├──────────────────────┤
│ 媒体承载层            │ ← RTP / UDP / TCP
├──────────────────────┤
│ 会话与控制平面        │ ← SIP / RTSP
├──────────────────────┤
│ 网络服务模型          │ ← Best Effort / DiffServ / QoS
└──────────────────────┘

关键思想：

三、多媒体应用的基本特性

1. 视频

👉 核心思想： 空间冗余换时间连续性（压缩 + 缓冲）

2. 音频

👉 核心思想： 允许不完整，但不能不及时

四、时间连续性的核心机制：缓存

1. 缓存的系统本质

缓存不是性能优化，而是时间不确定性的吸收器：

2. TCP + 应用缓存的协同

服务器
  └─ TCP发送缓存
        ↓
网络
        ↓
客户端
  └─ TCP接收缓存
        ↓
  └─ 应用播放缓存
        ↓
    解码与显示

关键点

五、流媒体传输模型的本质区分

1. UDP 实时流：以时间为中心

典型协议：RTP / RTSP 设计哲学：

👉 时间优先于完整性

2. HTTP 流：以吞吐为中心

关键机制

适应性 HTTP 流（DASH）

👉 用时间换确定性

3. 本质对比

维度 UDP 实时流 HTTP 流
核心目标 低时延 稳定播放
丢包处理 忽略 / 掩盖 重传
网络适应 弱 强
工程可部署性 低 高

六、实时语音（VoIP）的系统约束

1. 不可接受的条件

👉 宁可丢，也不能等

2. 抖动的本质与对策

抖动来源

解决机制

  1. 时间戳
  2. 延迟播放（抖动缓冲）

策略选择

3. 丢包处理的三种哲学

方法 本质 代价
前向纠错 空间换可靠性 带宽增加
交织 时间分摊风险 时延增加
掩盖 感知容忍 信号失真

七、实时会话的控制平面

1. 平面分离思想

2. RTP：媒体承载最小集合

提供但不保证

👉 RTP 不解决问题，只暴露问题给应用

3. SIP：会话的社会化基础设施

解决的问题

👉 SIP 本质上是：

实时通信世界的“HTTP + DNS”

八、支持多媒体的网络服务模型

1. 三种服务哲学

模型 思想 现实地位
尽力而为 简单、可扩展 主流
区分服务 有限优先级 局部使用
QoS 保证 确定性 理论理想

2. 工程现实的选择逻辑

尽力而为网络

区分服务

QoS 网络

👉 互联网选择了“应用层复杂，网络层简单”

九、为什么今天的主流是 HTTP + 自适应？

这是一个工程与现实博弈的结果：

👉 胜出的不是最"优雅"的方案，而是最能活下来的方案。

十、能力视角总结（稳定认知）

多媒体网络核心能力
├── 时间连续性
│   ├── 缓存
│   ├── 延迟播放
├── 带宽适应性
│   ├── 预取
│   ├── 自适应码率
├── 丢包容忍
│   ├── FEC
│   ├── 掩盖
└── 会话控制
    ├── 建立
    ├── 维护
    └── 终止

关联内容（自动生成）