Network - 05.Multimedia Networking

Motivation

冲突的本质： 互联网最初是为数据传输（如文件、邮件）设计的，提供的是“尽力而为 (Best-Effort)”的服务——不保证时间，但保证完整。然而，多媒体应用（音频/视频）的需求恰恰相反：它们对延迟和抖动极度敏感，但对少量丢包可以容忍。
核心挑战： 如何在不提供服务质量保证（无 QoS）的现有互联网架构上，让对 QoS 要求极高的多媒体应用流畅运行？

Content Summary

应用分类： 区分了存储流式、直播流式和实时交互式应用的不同需求。
应用层解决方案： 在网络层无法改变的情况下，利用客户端缓冲、CDN、FEC (前向纠错) 和交织等技术在端系统解决抖动和丢包问题。
专用协议： 介绍了 RTP (传输媒体数据) 和 SIP (信令控制)。
网络层演进 (QoS)： 探讨了如何通过调度算法 (如 WFQ)、监管机制 (令牌桶) 以及 DiffServ/IntServ 架构，让网络从“尽力而为”向“提供服务保证”演进。

第 7 章：多媒体网络 (Chapter 7: Multimedia Networking)

7.1 引言与原则 (Principles)

多媒体应用的分类 (Classify multimedia applications):
1. 存储流式 (Stored streaming):
  - 媒体存储在源端，传输给客户端。
  - 客户端在所有数据到达前就开始播放 (streaming)。
  - 关键是播放时机 (playout timing)。
  - 具有 VCR 功能（暂停、倒带、快进），允许初始延迟。
2. 直播流式 (Live streaming):
  - 例如：互联网广播、体育赛事直播。
  - 也有播放缓冲区，播放可能会滞后传输数十秒。
  - 无法快进，但可能可以暂停或倒带。
3. 实时交互式 (Interactive, real-time):
  - 例如：IP 电话 (VoIP)、视频会议、分布式互动游戏。
  - 对延迟非常敏感 (Delay sensitive): 端到端延迟应小于 150ms (好) 或 400ms (可接受)。
  - 对丢包具有一定的容忍度 (Loss tolerant)。
网络服务需求 (Network services):
- 不同的应用需要不同的服务级别 (QoS)。
- 现有的互联网提供的是 尽力而为 (Best-effort) 服务，不保证延迟和丢包。
挑战:
- 尽力而为的服务模型难以满足多媒体应用对 QoS 的要求。
- 解决方案：应用层技术 (Application-level techniques) + 网络层机制 (Network-level mechanisms)。

7.2 流式存储音频和视频 (Streaming Stored Audio and Video)

流式传输 (Streaming): 客户端在下载的同时播放。
客户端缓冲 (Client Buffering):
- 目的： 吸收网络延迟的抖动 (Jitter)，使播放更加平滑。
- 机制：
  - 填充速率 (fill rate) $x(t)$ 是可变的（受网络带宽影响）。
  - 排空速率 (drain rate) $d$ 是恒定的（受播放速率决定）。
  - 缓冲区在开始播放前会预存一部分数据。
UDP vs TCP:
- UDP: 发送速率由服务器控制，不进行拥塞控制，适合对延迟敏感的应用。需要应用层处理丢包和重排序。
- TCP: 发送速率受拥塞控制影响，波动大。提供可靠传输，但重传会增加延迟。HTTP/TCP 更容易穿透防火墙。
适应不同客户端速率:
- 服务器存储多个不同编码速率（比特率）的视频版本（如 1.5 Mbps, 28.8 Kbps）。
- 根据客户端的可用带宽选择合适的版本。

7.3 尽力而为服务的优化 (Making the Best of Best Effort Service)

互联网提供的“尽力而为”服务不保证带宽、延迟和丢包，为了满足多媒体应用的需求，需要在应用层采取多种机制来应对网络的不确定性。

1. 客户端缓冲 (Client-Side Buffering)

这是流式播放中最核心的机制，用于解决网络抖动 (Jitter) 问题。

原理：
- 输入速率 (Fill Rate, $x(t)$ )： 从网络接收数据的速率，由于网络拥塞等原因，是可变的。
- 输出速率 (Drain Rate, $d$ )： 播放器消耗数据的速率，通常是恒定的（取决于编码比特率）。
- 缓冲池： 在客户端内存中开辟一块区域，先将数据积累到一定程度再开始播放。
作用：
- 平滑抖动： 缓冲区的存在吸收了数据包到达时间的不规律变化，保证播放器能以恒定速率读取数据。
- 补偿延迟： 初始的播放延迟（Play-out delay）为暂时滞后的数据包提供了到达的时间窗口。

2. 传输协议的选择 (UDP vs TCP)

多媒体应用需要在 UDP 和 TCP 之间根据需求做权衡。

UDP (用户数据报协议)

特性：
- 发送速率由服务器控制（通常等于编码速率），不进行拥塞控制，对网络拥塞“无感知”。
- 低延迟： 没有重传机制，播放延迟短（通常 2-5 秒）。
容错： 需要应用层自己处理丢包（如通过 FEC）和乱序。
适用场景： 对实时性要求高、能容忍少量丢包的应用（如 VoIP、实时会议）。

TCP (传输控制协议)

特性：
- 发送速率波动： 受 TCP 拥塞控制机制（如慢启动、AIMD）影响，发送速率会剧烈波动（“锯齿状”）。
- 可靠传输： 保证数据不丢失，但重传机制会引入显著的延迟。
- 穿透性好： HTTP/TCP 更容易通过防火墙和 NAT（许多防火墙默认拦截 UDP）。
适用场景： 存储流媒体（如 YouTube, Netflix），依靠较大的客户端缓冲区来平滑 TCP 的传输波动。

3. 适应不同客户端速率 (Rate Adaptation)

由于不同客户端的接入带宽差异巨大（如 5G vs 拨号），服务器不能以单一码率发送。

多重编码 (Multiple Encodings)：
- 服务器将同一个视频预先编码为不同比特率的多个版本（例如：1.5 Mbps, 500 Kbps, 28.8 Kbps）。
动态选择：
- 客户端根据当前检测到的可用带宽，请求合适版本的视频片段。
- DASH (Dynamic Adaptive Streaming over HTTP) 是目前主流的实现方式。

4. 自适应播放延迟 (Adaptive Playout Delay)

针对实时交互应用（如 IP 电话），不能使用过大的缓冲区。需要在“低延迟”和“低丢包”之间寻找动态平衡。

核心思想

动态调整： 不是使用固定的播放延迟，而是根据网络状况动态估算延迟。
调整时机： 仅在每个语音突发 (Talk Spurt) 的开始时刻调整播放时间，在突发内部保持固定的播放间隔，通过压缩或拉长静音期来实现调整。

算法步骤

估算平均网络延迟 ( $d_i$ )：
使用指数加权移动平均 (EWMA) 公式：

$d_i = (1-u) \cdot d_{i-1} + u \cdot (r_i - t_i)$
- $r_i$ : 接收时间, $t_i$ : 发送时间
- $u$ : 权重系数 (如 0.01)
估算延迟偏差/抖动 ( $v_i$ )：
$v_i = (1-u) \cdot v_{i-1} + u \cdot | r_i - t_i - d_i |$
计算播放时间 ( $p_i$ )：
对于语音突发的第一个包：

$p_i = t_i + d_i + K \cdot v_i$
- $K$ : 安全系数 (如 4)。这表示播放时间设置为“发送时间 + 平均延迟 + K倍抖动”，以覆盖绝大多数数据包的到达时间。
突发检测：
通过比较连续包的时间戳和序列号来判断是否开始了新的语音突发（例如：时间戳跳变 $> 20ms$ 且序列号连续）。

5. 丢包恢复机制 (Recovery from Packet Loss)

在不使用 TCP 重传（因为太慢）的情况下，应用层可以通过增加冗余来对抗丢包。

A. 前向纠错 (FEC - Forward Error Correction)

方案 1：异或冗余
- 每 $n$ 个原始数据块，计算生成 1 个冗余块（异或结果）。
- 发送 $n+1$ 个块。
- 能力： 可以恢复这组中任意 1 个 丢失的包。
- 代价： 增加了带宽消耗 ( $1/n$ ) 和播放延迟 (需要等一组包到齐)。
方案 2：低质量流冗余
- 在发送第 $n$ 个高质量包时，附带第 $n-1$ 个包的低质量版本（如低码率音频）。
- 如果第 $n-1$ 个包丢失，可以使用第 $n$ 个包中携带的低质量版本进行填补。
- 优点： 延迟较低。

B. 交织 (Interleaving)

原理： 发送时不按顺序发送相邻的音频单元，而是将其打散重排。
- 例如：发送顺序为 1, 5, 9… 而不是 1, 2, 3…
作用： 如果网络发生突发性丢包（连续丢一组包），在接收端还原后，这些丢包会变成分散的单个丢失单元。
优势： 分散的小错误比连续的大段静音更容易被通过算法掩盖（Error Concealment）。
代价： 增加了播放延迟。

6. 内容分发网络 (CDN)

解决单点服务器瓶颈和长距离传输延迟的问题。

核心策略： 内容复制 (Content Replication)。
部署： 将内容（如视频文件）预先推送到分布在全球边缘网络（靠近用户）的数百/数千台服务器上。
请求路由：
- 当用户请求视频时，利用 DNS 重定向 技术。
- 权威 DNS 服务器根据用户的 IP 地址，判断其地理位置。
- 将请求重定向到距离用户最近（或负载最轻）的 CDN 节点。
优势： 显著降低了网络延迟，减少了骨干网流量，提高了系统的可靠性。

7.4 实时交互应用协议 (Protocols for Real-Time Interactive Applications)

RTP (Real-Time Protocol):
- 运行在 UDP 之上。
- 提供：载荷类型标识 (Payload Type), 序列号 (Sequence Number), 时间戳 (Timestamp)。
- 不提供 QoS 保证（不保证及时交付或不丢包）。
RTCP (RTP Control Protocol): 用于监控服务质量和传递会话信息。
SIP (Session Initiation Protocol): 用于建立、修改和终止多媒体会话（如 VoIP 呼叫）。

7.5 提供多种服务等级 (Providing Multiple Classes of Service)

传统的互联网提供的是“尽力而为 (Best-Effort)”的服务，即“一刀切”的模型。为了满足多媒体应用的需求，网络需要演进为提供多种服务等级。

1. 核心设计原则 (Design Principles)

为了实现区分服务，网络架构需要遵循以下四个原则：

原则 1：标记 (Marking / Classification)
- 路由器需要能够区分不同类别的流量。
- 方法： 在网络边缘（Edge）对数据包进行标记（例如使用 IP 头部的 ToS 字段），核心路由器根据标记处理数据包。
原则 2：隔离 (Isolation / Protection)
- 需要保护一个类别的流量不受其他类别（特别是行为不当的流）的影响。
- 例如：通过调度机制，确保音频流不会被突发的 FTP 文件传输阻塞。
原则 3：高效利用资源 (Efficiency)
- 虽然需要隔离，但也希望资源能被共享。
- 例如：如果高优先级的流量没有使用其分配的带宽，应该允许低优先级的流量使用这些空闲带宽，而不是让带宽闲置。
原则 4：呼叫接纳 (Call Admission)
- 物理链路的容量是有限的。如果流量需求超过了链路容量，必须拒绝新的连接请求（类似于电话忙音），以保证现有连接的服务质量。

2. 调度机制 (Scheduling Mechanisms)

调度策略决定了链路上的下一个数据包该发送队列中的哪一个。

A. 先入先出 (FIFO)

机制： 按照数据包到达队列的顺序进行发送。
丢弃策略 (Discard Policy)： 当队列满时，如何丢弃数据包？
- 尾部丢弃 (Tail Drop)： 丢弃新到达的数据包（最常用）。
- 优先级丢弃 (Priority)： 根据优先级丢弃/移除数据包。
- 随机丢弃 (Random)： 随机选择数据包丢弃（如 RED 算法）。

B. 优先级排队 (Priority Queuing)

机制： 维护多个优先级的队列（如高优先级、低优先级）。
规则： 只要高优先级队列中有数据包，就先发送高优先级的；只有高优先级队列为空时，才发送低优先级的数据包。
缺点： 可能导致低优先级流量“饥饿” (Starvation)，即永远得不到服务。

C. 轮询 (Round Robin - RR)

机制： 循环扫描各个类别的队列，如果队列非空，就发送一个数据包。
特点： 提供了类之间的公平性，避免了饥饿问题。

D. 加权公平队列 (Weighted Fair Queuing - WFQ)

机制： 广义的轮询。每个类被分配一个权重 ( $w_i$ )。
规则： 在每个服务循环中，第 $i$ 类获得的服务量与其权重 $w_i$ 成正比。
优势： 既保证了每个类别的最小带宽保证，又允许在某类空闲时共享带宽。

3. 监管机制 (Policing Mechanisms)

监管的目的是强制流量源遵守其声明的流量参数（SLA），防止恶意或错误的流量占用过多资源。

三个常见的监管指标：

平均速率 (Average Rate)： 长期来看，每单位时间发送多少数据包。
峰值速率 (Peak Rate)： 短期内的最高发送速率。
突发大小 (Burst Size)： 允许连续发送的最大数据包数量（无需中间等待）。

核心实现：令牌桶 (Token Bucket)

这是一种限制输入流量以满足特定突发大小和平均速率的机制。

参数：
- $r$ ：令牌生成速率 (tokens/sec)。
- $b$ ：桶的容量 (bucket depth)，即最大令牌数。
工作原理：
- 令牌以速率 $r$ 填入桶中。
- 桶满时，新令牌被丢弃（令牌数不超过 $b$ ）。
- 数据包要发送，必须从桶中消耗令牌。
- 如果桶中令牌不足，数据包必须等待或被丢弃/标记。
QoS 保证：
- 结合 令牌桶 (限制流量) 和 WFQ (加权调度)，网络可以提供确定性的最大延迟上界 ( $D_{max} = b/R$ )。

4. 区分服务架构 (DiffServ Architecture)

DiffServ 是一种通过在网络边缘进行复杂处理，而在网络核心保持简单的架构，旨在解决扩展性问题。

架构组件：

边缘路由器 (Edge Router)： 复杂性所在
- 分类 (Classification)： 根据源/目 IP、端口号等识别流量。
- 标记 (Marking)： 将数据包标记为“配置内 (In-Profile)”或“配置外 (Out-Profile)”，通常修改 IP 头部的 ToS (Type of Service) 字段。
- 监管 (Policing)： 使用令牌桶等机制限制流量速率。
核心路由器 (Core Router)： 简单高效
- 不维护每条流的状态（Per-flow state）。
- 仅根据数据包的标记（类别），通过 PHB (Per-Hop Behavior) 进行相应的缓冲和调度处理。
- 例如：优先转发标记为“高优先级”的数据包。

优势：

可扩展性强 (Scalability)： 核心网络不需要知道具体的业务流，只处理有限的几个服务等级，因此可以支持庞大的流量。

7.6 提供 QoS 保证 (Providing QoS Guarantees)

集成服务 (Integrated Services / IntServ):
- 理念： 为每个应用会话预留端到端资源（带宽、缓冲）。
- 呼叫接纳 (Call Admission): 网络根据资源情况决定是否接受新连接。
- 缺点： 需要在路由器中维护每个流的状态，可扩展性差。
服务模型:
- 保证服务 (Guaranteed Service): 提供确定的延迟上界。
- 受控负载服务 (Controlled Load Service): 提供类似网络未加载时的服务质量。

案例研究：无线 Mesh 网络传输视频 (Wireless Mesh for Video)

特点： 多跳、自组织、自愈合。
优势： 高带宽（支持多路视频）、部署简单、覆盖范围广。
技术：
- 跨层设计 (Cross-layer design): 物理层、MAC 层、网络层、传输层协同工作。
- 多优先级传输: 将视频帧分为不同优先级（I帧 > P帧 > B帧），映射到不同的传输队列（AC_VO, AC_VI 等）。
- 动态数据映射: 根据网络状况动态调整数据包的映射策略。

Network

#Network

Network - 05.Multimedia Networking

https://yima-gu.github.io/2026/01/14/Network/Network-05-Multimedia/

作者

Yima Gu

发布于

2026年1月15日

许可协议

Network - 06.Security-01 上一篇

Network - 04.Data Link Layer-02 下一篇