多媒体网络

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

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

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│   ├── 掩盖└── 会话控制    ├── 建立    ├── 维护    └── 终止

关联内容（自动生成）