第8章：多媒体网络（Multimedia Networking）

一、导读

8.1 本章学习目标

多媒体应用（音频、视频）对网络提出了特殊要求：低延迟、低抖动、高带宽。本章讲解多媒体网络的关键技术：RTP 协议、流媒体服务、QoS 机制、以及 CDN 内容分发网络。

本章的核心学习目标包括：

理解多媒体网络的挑战：延迟、抖动、丢包
掌握 RTP 协议：实时传输协议
理解流媒体：DASH、HLS
掌握 QoS 机制：IntServ、DiffServ
理解 CDN：内容分发网络
了解音视频编码基础：采样率、量化、压缩

8.2 为什么多媒体网络如此重要

视频和音频已经成为互联网流量的主体。据预测，视频流量将占互联网总流量的 80% 以上。理解多媒体网络的工作原理，对于开发音视频应用、优化用户体验至关重要。

多媒体网络的核心挑战在于：网络本身是为数据传输设计的（TCP 保证可靠传输），而多媒体应用对延迟和抖动的敏感度远高于对丢包的敏感度。这种矛盾是多媒体网络设计的核心问题。

8.3 核心问题引导

在阅读本章时，请带着以下问题思考：

为什么实时视频通话不能使用 TCP？

抖动是什么？如何消除抖动的影响？

自适应码率流媒体是如何工作的？

CDN 如何减少用户访问内容的延迟？

QoS 机制为什么在互联网上部署困难？

二、核心概念详解

2.1 多媒体网络的挑战

2.1.1 延迟（Latency）

从发送方到接收方的总时间。对于实时应用（如语音通话），延迟应小于 150ms。延迟超过 250ms 时，通话体验会明显下降。延迟的来源包括：编码延迟、网络传输延迟、抖动缓冲延迟、解码延迟。

2.1.2 抖动（Jitter）

分组到达时间的变化。抖动会导致音频卡顿、视频花屏。

发送端：分组1 @ t=0, 分组2 @ t=20ms, 分组3 @ t=40ms
接收端：分组1 @ t=50ms, 分组2 @ t=75ms, 分组3 @ t=85ms
抖动 = 到达间隔的变化 = (25ms, 10ms) → 不均匀

抖动的消除通常使用抖动缓冲（jitter buffer）：接收方将分组缓存一段时间，然后以均匀的速率播放。缓冲越大，抗抖动能力越强，但延迟也越大。

2.1.3 丢包（Packet Loss）

分组在网络中丢失。丢包会导致音频中断、视频马赛克。对于实时应用，重传通常不可行（因为延迟太大），因此需要使用前向纠错（FEC）或丢包隐藏（packet loss concealment）技术。

2.2 RTP（实时传输协议）

RTP 为实时应用提供端到端的传输服务：

时间戳：用于恢复时钟
序列号：用于检测丢包和重排序
负载类型：标识编码格式

RTP 报文段格式：
+--------+--------+--------+--------+
| V=2 | P | X | CC |  M  |  PT   |
+--------+--------+--------+--------+
|         序列号                    |
+--------+--------+--------+--------+
|         时间戳                    |
+--------+--------+--------+--------+
|         SSRC 标识符               |
+--------+--------+--------+--------+
|           载荷                    |
+-----------------------------------+

RTP 本身不提供可靠传输、顺序保证或 QoS 保证。它只是一个"传输格式"，需要与 RTCP（RTP 控制协议）配合使用。RTCP periodically 发送统计信息（如丢包率、抖动），帮助发送方调整传输参数。

2.3 流媒体

2.3.1 DASH（动态自适应流）

DASH 将视频分成多个片段，每个片段有多个码率版本。客户端根据网络状况动态选择码率。

视频：
片段1：低码率、中码率、高码率
片段2：低码率、中码率、高码率
...

DASH 的核心思想是：将视频编码为多个不同码率的版本，客户端根据当前的网络带宽和缓冲区状态，动态选择最合适的码率。当网络状况好时选择高码率，网络状况差时降低码率以避免卡顿。

2.3.2 HLS（HTTP Live Streaming）

Apple 推出的流媒体协议，原理与 DASH 类似。HLS 将视频分成 10 秒左右的 TS 片段，通过 M3U8 播放列表索引。HLS 的优势是兼容性好（所有浏览器和设备都支持），但延迟较高（通常 10-30 秒）。

2.4 VoIP（Voice over IP）

VoIP 将语音数字化并通过 IP 网络传输。

2.4.1 语音编码

PCM：脉冲编码调制，64 kbps，电话质量
G.711：64 kbps，无压缩
G.729：8 kbps，压缩语音
Opus：可变码率（6-510 kbps），高质量，低延迟

语音编码的核心是在质量和码率之间取得平衡。窄带语音（300-3400Hz）只需要 8kHz 采样率，而宽带音频（20-20000Hz）需要 44.1kHz 采样率。

2.4.2 抖动缓冲

接收方使用抖动缓冲来平滑分组到达时间的变化。抖动缓冲的大小需要根据网络抖动动态调整：太小会导致丢包，太大会增加延迟。

2.5 QoS（服务质量）

QoS 机制保证网络应用的服务质量。

2.5.1 IntServ（集成服务）

端到端预留资源，保证服务质量。使用 RSVP 协议。IntServ 的优点是能提供确定的 QoS 保证；缺点是需要在每个路由器上维护每个流的状态，可扩展性差。

2.5.2 DiffServ（区分服务）

在分组头部标记 DSCP（区分服务码点），路由器根据标记进行优先级调度。DiffServ 的优点是可扩展性好（只需要在边缘标记，核心路由器只需分类和转发）；缺点是不能提供确定的 QoS 保证。

2.6 CDN（内容分发网络）

CDN 将内容缓存到边缘服务器，用户从最近的服务器获取内容。

2.6.1 CDN 架构

源服务器：存储原始内容
边缘服务器：缓存内容，服务用户
重定向服务器：将用户重定向到最近的边缘服务器

CDN 的服务器放置策略有两种：深入接入（进入 ISP 网络）和靠近接入（放在 IXP 附近）。前者覆盖更多用户，后者成本更低。

2.6.2 CDN 的优势

减少延迟（用户从最近的服务器获取内容）
降低源服务器负载
提高可用性（分布式部署，单点故障不影响全局）

三、深入分析

3.1 网络性能对多媒体的影响

应用	延迟要求	丢包容忍	带宽需求
语音通话	<150ms	<5%	64-128 kbps
视频会议	<200ms	<5%	1-5 Mbps
直播	<2s	<1%	2-10 Mbps
点播	无要求	<0.1%	5-50 Mbps

不同应用对网络的要求差异很大。实时应用对延迟和抖动敏感，但可以容忍一定丢包；非实时应用对延迟不敏感，但需要可靠传输。

3.2 视频编码与压缩

视频压缩的核心思想是去除空间冗余（帧内压缩）和时间冗余（帧间压缩）。

I 帧：关键帧，独立编码，不依赖其他帧
P 帧：预测帧，参考前面的帧
B 帧：双向预测帧，参考前后两个方向的帧

视频码率 = 分辨率 x 帧率 x 压缩比。4K 视频（3840x2160）在 30fps 下，原始数据量约 12Gbps，经过压缩后通常为 15-25Mbps。

3.3 音频质量指标

指标	含义	要求
采样率	每秒采样次数	8kHz（电话）、44.1kHz（CD）
量化位数	每个采样的精度	8bit、16bit
比特率	每秒数据量	64kbps、128kbps、320kbps

四、实践案例

4.1 案例一：使用 ffmpeg 处理和分析音视频

bash

# 转换格式
ffmpeg -i input.mp4 output.avi

# 调整码率
ffmpeg -i input.mp4 -b:v 2M output.mp4

# 提取音频
ffmpeg -i input.mp4 -vn output.mp3

# 查看媒体信息
ffprobe -v quiet -print_format json -show_format -show_streams input.mp4

ffmpeg 是音视频处理的瑞士军刀，支持几乎所有音视频格式。通过 ffprobe 可以查看媒体文件的详细信息，包括编码格式、码率、分辨率等。

4.2 案例二：使用 Wireshark 和 iperf 分析多媒体网络性能

启动 Wireshark，过滤 rtp

观察 RTP 报文段的格式

分析时间戳和序列号

使用 iperf 测试网络带宽和抖动

bash

# 测试带宽
iperf3 -s
iperf3 -c server_ip

# 测试 UDP 性能（模拟实时应用）
iperf3 -c server_ip -u -b 1M

五、常见误区

5.1 误区一："带宽越大，视频越清晰"

带宽只是因素之一，编码质量、分辨率、帧率、编码器效率等都影响视频质量。同样的带宽，使用更先进的编码器（如 H.265 vs H.264）可以获得更好的画质。

5.2 误区二："丢包率 1% 不影响体验"

对于实时应用，1% 的丢包率可能导致明显的音频中断和视频花屏。1% 的丢包率意味着每 100 个分组丢失 1 个，对于 50fps 的视频，每 2 秒丢失一帧，肉眼可见。

5.3 误区三："TCP 可以用于实时视频"

TCP 的拥塞控制和重传机制会引入不可预测的延迟。当发生丢包时，TCP 会等待重传，导致后续数据被阻塞（队头阻塞）。这就是为什么实时应用通常使用 UDP 或基于 UDP 的协议（如 WebRTC）。

5.4 难点：理解自适应码率算法

自适应码率算法需要根据带宽、缓冲区、丢包率等多个因素动态调整码率，算法设计复杂。常见的策略包括：基于带宽估计（如 BBA）、基于缓冲区（如 BBA）、基于混合指标（如 Pensieve）。

六、本章小结

第8章讲解了多媒体网络：

多媒体网络 面临延迟、抖动、丢包的挑战

RTP 为实时应用提供传输服务

流媒体 使用 DASH/HLS 实现自适应码率

QoS 机制保证服务质量

CDN 将内容缓存到边缘，减少延迟

后续章节将讲解网络安全。

七、思考题

假设一个 VoIP 通话使用 G.711 编码（64kbps），每 20ms 发送一个分组。如果网络延迟为 100ms，抖动为 30ms，丢包率为 2%。请问需要多大的抖动缓冲？如何处理丢包？

比较 DASH 和 HLS 的异同。为什么 Netflix 选择 DASH 而 Apple 选择 HLS？

为什么实时视频通话通常使用 UDP 而不是 TCP？WebRTC 是如何在 UDP 上实现部分可靠传输的？

CDN 的两种服务器放置策略（深入接入 vs 靠近接入）各有什么优缺点？如果你是 CDN 运营商，你会如何选择？

QoS 的两种模型（IntServ 和 DiffServ）各有什么优缺点？为什么 DiffServ 在互联网上更成功？