多媒体网络：流式存储音视频服务

目录

• 多媒体应用
  • 音视频的性质
  • 多媒体数据传输
• 流式存储音频/视频
  • 使用元文件的 Web 服务器
  • 引入专用的媒体服务器
• 传输协议
  • UDP 流
  • TCP 流
  • 适应性流和 DASH
• 实时流式协议 RTSP
• 内容分发网
  • 单源分发的缺点
  • CND 的部署方式
  • CND 的工作流程
  • 集群选择策略
• 参考资料

互联网最初为数据设计，IP 协议尽力而为和分组独立交付的特性适合传统数据，但对于实时音频/视频这类多媒体信息的传输提出了挑战。

多媒体应用

音视频的性质

从低质量视频会议的 100 kbps 到高清电影流媒体的 3+ Mbps，可见视频的核心特性是极高的比特率。视频的比特率通常比图片浏览、音乐流媒体等高一个数量级（10 倍或以上），例如一个 2Mbps 的视频流，其速率是 128kbps MP3 音乐的 16 倍。由于视频是当今互联网流量的绝对主体（预测占 90% 以上），设计网络视频应用时，高带宽需求是首要考虑因素。
视频包含大量冗余，允许在质量与比特率之间进行灵活权衡。对视频进行压缩有如下两种依据。应用压缩可以为同一内容生成不同比特率（如 300kbps, 1Mbps, 3Mbps）的多个副本，供用户根据自身网络条件选择。在视频会议等实时应用中，编码器可根据当前可用带宽动态调整压缩率，以提供该条件下最佳的视频质量。

视频压缩依据	说明
空间冗余	单帧图像内部相邻像素的相似性
时域冗余	连续帧之间图像内容的相似性

对音频进行数字化与压缩的基础是 PCM 编码，时模拟信号转化为数字的标准过程，包括采样、量化、编码三步，例如电话语音（8kHz 采样，8 位量化）-> 64 kbps；CD 音质（44.1kHz 采样，16 位量化，立体声）-> 1.411 Mbps。但是 PCM 编码的音频在互联网上很少使用，在网上传输的音频几乎都经过压缩，以大幅降低带宽需求。
音频的比特率相对较低，但对损伤敏感：未压缩语音（PCM）为 64 kbps；压缩语音（如 VoIP）可低于 10 kbps 仍保持可懂度；压缩高质量音乐（如MP3 在 128 kbps 左右。虽然音频的绝对比特率远低于视频，但其质量要求更为苛刻，用户对音频中断、卡顿、失真的容忍度远低于视频。因此尽管其数据量较小，网络协议和应用设计需要为音频数据提供更强的时间保障，和更优的丢包处理机制。

多媒体数据传输

本来电路交换的公用电话网传送话音和多媒体信息早已是成熟的技术，只要拨通了电话，各种信号在电话线路上的传输质量就有保证。但使用公用电话网的缺点是价格太高，所以需要想办法改用互联网。多媒体信息的两个核心特点为：

多媒体信息特点	说明
信息量极大	例如电话语音 PCM 的数据率为 64 kbit/s；CD 立体声 > 1.4 Mbit/s；不压缩彩色电视 > 250 Mbit/s，因此必须进行压缩。
对时延和时延抖动敏感	区别于先完整下载后播放，边传输边播放是网络多媒体应用的基本模式。发送端产生的等时分组，经过互联网非等时的传输后，到达接收端变得杂乱无章，直接播放会导致严重失真。

解决时延抖动的关键技术是使用接收端缓存，在接收端设置一个先进先出缓存区，其工作过程如下：

1. 非等时到达的分组先进入缓存排队。
2. 经过一个预设的播放时延 T 后，接收端以恒定速率从缓存中读取分组，进行还原播放。

缓存将非等时到达的离散分组流，转换为等时播放的连续流，平滑了时延抖动。但代价是引入了固定的播放时延 T，T 越大时抗抖动能力越强，但整体时延也越大，需在实时性和流畅性间权衡。

在实时数据传输的协议选择方面，应使用 UDP 而非 TCP。这是因为对于实时数据，低时延比绝对可靠更重要。宁可容忍少量分组丢失，也要避免因重传（TCP 机制）引入的过大、不确定的延迟。由于分组不一定能按序到达，所以需要序号来按序重组分组。同时接收端需要在正确的时刻开始播放，因此还需要时间戳用于标识分组产生的准确时间，并区分正常静默和网络导致的异常停顿。

互联网音频/视频服务主要有三种类型：

类型	特点	举例	说明
流式存储音频/视频	内容已预先录制并压缩存储在服务器上，用户边下载边播放，播放开始前仅有短暂缓存延迟（几秒到几十秒）。	在线音乐（网易云）、在线电影（优酷）、教学视频	实现了即点即看，无需完整下载。流媒体主要指此类，播放后本地通常不保存文件。
流式实况音频/视频	内容实时产生并发送，接收端近乎实时地播放，通常为一对多广播。	网络直播、赛事转播、网络电台	时效性最强，理想应用多播，但目前多为多个单播。
交互式音频/视频	用户之间实时的、双向的多媒体通信，对时延要求最高。	互联网电话、视频会议	属于实时交互式应用，需要端到端的低延迟保障。

流式存储音频/视频

此处的音视频已经录制好并保存于存储介质中，具有以下三个特点，其中最关键的是边下载边播放：

流式存储音视频特点	说明
流	流避免了在开始播放之前必须下载整个视频，客户开始从服务器接收文件几秒之后，通常就开始播放视频。
相互作用	因为媒体是预先录制的，用户可以对多媒体内容进行暂停、重新配置前进、重新配置倒退、快进等操作。
连续播放	一旦视频开始播放，它应该根据初始记录的时序进行。

使用元文件的 Web 服务器

传统下载方式中，浏览器通过 HTTP/TCP 从 Web 服务器完整下载整个文件到本地，再由独立的媒体播放器应用程序打开播放。其缺点在于用户必须等待整个文件下载完毕才能开始观看，对于大文件体验极差。

使用元文件的 Web 服务器引入元文件作为中介，它元文件是一个很小的文件，包含了实际音视频文件的 URL 和元信息。其工作流程如下：

1. 用户点击的链接指向元文件，而非实际媒体文件。
2. Web 服务器将元文件返回给浏览器。
3. 浏览器根据元文件类型，启动关联的媒体播放器，并将元文件交给它。
4. 媒体播放器读取元文件中的 URL，直接与 Web 服务器建立新的 TCP 连接，请求并开始下载媒体文件。
5. 媒体播放器在缓存少量数据后，开始边下边播。

该方法实现了播放与浏览器的解耦，媒体播放器可以直接、持续地从服务器获取数据流，实现了流式播放。但它仍使用通用的 Web 服务器和 HTTP/TCP，并非为流媒体优化。

引入专用的媒体服务器

引入专用的媒体服务器：将流媒体服务从通用 Web 服务器中分离出来，由专门的媒体服务器（或称流式服务器）负责。万维网服务器负责提供元文件，媒体服务器负责传输媒体数据流，其工作流程如下：

1. 前 3 步同元文件方案，浏览器获取元文件并启动播放器。
2. 媒体播放器根据元文件中的 URL，连接至媒体服务器而非 Web 服务器）。
3. 媒体服务器使用更适合流媒体的协议（最初尝试 UDP，后主流转为 TCP）向播放器传输数据。

传输协议

UDP 流

传输协议一开始选择了 UDP，目的是为了避免 TCP 重传机制引入的不确定延迟，追求更低延迟。服务器通过 UDP 以一种稳定的速率记录下视频块，用与客户的视频消耗速率相匹配的速率传输视频。UDP 流通常使用很小的客户端缓存，在将视频块传递给 UDP 之前，服务器将视频块封装在运输分组中。该运输分组是专门为传输音频和视频而设计的，使用了实时传输协议 RTP 或某种类似的方案。
但是 UDP 存在以下问题，因此 UDP 主要用于实时性要求极高的实况转播：

媒体服务器使用 UDP 的问题	说明
无法适应带宽变化	UDP 以固定速率发送，若网络带宽下降会导致播放卡顿
防火墙阻拦	许多防火墙会阻止 UDP 分组
控制复杂	实现播放控制（暂停、快进）需要额外协议（RTP/RTSP），增加复杂度

TCP 流

虽然 TCP 被认为重传会破坏实时性，但是以下良好的性质使得使用 TCP 成为主流方案：

媒体服务器使用 TCP 的优势	说明
带宽自适应	TCP 的拥塞控制能自动适应网络带宽变化
防火墙友好	TCP 80/443 端口通常畅通
实现简单	HTTP 基础设施成熟，缓存可以平滑抖动

视频通常作为一个 URL 的普通文件存储在 HTTP 服务器上，当用户要看视频时：

1. 客户和服务器之间建立一个 TCP 连接，并且发送一个对该 URL 的 HTTP GET 请求；
2. 服务器则尽可能快地在 HTTP 响应报文中发送该视频文件。

对于流式存储视频，客户能够尝试以高于消耗速率的速率下载视频。因此需要预取将来会被消耗的视频帧，预取的视频存储在客户应用缓存中。当 TCP 发送缓存显示为满时，服务器瞬间防止从视频文件发送更多的字节到套接字。客户应用程序从 TCP 接收缓存(通过其客户套接字)读出字节，并将字节放入客户应用缓存中。与此同时，客户应用程序周期性地从客户应用缓存中抓取视频帧，解压缩并显示在用户屏幕上。

如果用户暂停播放，那么缓存将很快被填满，这时 TCP 发送缓存就暂停读取所存储的视频文件。以后，媒体播放器每读出 n bit，TCP 发送缓存就可以从存储的视频文件再读取 n bit。如果客户机中的两个缓存经常处于填满状态，就能够较好地应付网上偶然出现的拥塞。如果传送速率小于读出速率，那么客户的两个缓存中的存量就会逐渐减少，当媒体播放器缓存的数据被取空后，播放就不得不暂停。实践证明，只要 TCP 平均传送速率达到视频节目规定的播放速率的两倍，媒体播放器一般就能流畅地播放网上的视频节目。
系统经常利用 HTTP GET 请求报文中的 HTTP 字节范围首部，当用户要在视频中重定位到一个新位置时，客户发送一个新 HTTP 请求。该请求用字节范围首部指出服务器应当从文件的哪个字节起发送数据，服务器从指示的字节开始发送。当某用户重定位到某个未来点或提前终止视频时，某些由服务器发送的已预取但尚未观看的数据将导致带宽和服务器资源的浪费。因此，许多流系统仅使用了长度适当的客户应用缓存，或者将限制在 HTTP 请求中使用字节范围首部预取的视频数量。

适应性流和 DASH

传统的 HTTP 流媒体为所有用户提供相同编码质量的视频，无法适应不同用户或同一用户在不同时间剧烈变化的网络带宽。经 HTTP 的动态适应性流 DASH 应运而生，它已成为现代自适应流媒体的事实标准。DASH 的核心思想是视频分块，多版本编码，客户端智能选择，服务器端将按照如下流程进行准备：

1. 将同一个原始视频编码成多个不同比特率（即不同清晰度）的版本。
2. 将每个版本的视频切割成一系列长度固定的小数据块。
3. 创建一个告示文件，列出了所有可用版本、每个版本的比特率，以及每个数据块的存储位置。

当需要获取视频时，客户端按照以下流程进行工作：

1. 获取清单：客户端首先下载告示文件，获知所有可用的视频版本和块信息。
2. 测量与决策：客户端持续测量当前可用的网络带宽，并监控本地播放缓存区的充盈程度。
3. 动态请求：基于测量结果，客户端运行一个速率自适应算法，决定接下来应该请求哪个版本的哪个数据块，并通过标准的 HTTP GET 请求获取它。
4. 边下边播：客户端下载并缓存这些块，然后按序解码播放。

为了避免因版本切换（尤其是大幅降码率）导致的画面质量突变，DASH 通常会提供多个中间质量版本进行平滑播放，使画质变化不易察觉。客户端算法根据网络状况在多个版本间动态切换：

网络与缓存状况	客户端的自适应决策	目标
带宽充足，缓存充足	上调：请求更高质量（更高比特率）的版本	在带宽允许的条件下提供最佳画质
带宽下降，缓存不足	下调：请求较低质量（较低比特率）的版本	避免播放卡顿，保证播放连续性
带宽恢复	逐步回调到更高质量的版本	在稳定后重新追求最佳画质

DASH 能为使用不同接入方式（如光纤、4G/5G、低速 Wi-Fi）的用户提供最适合其带宽的画质，应对移动用户因信号波动、网络拥塞导致的带宽实时变化。它利用现有的 HTTP Web 服务器、CDN 和缓存基础设施，无需部署特殊的流媒体服务器。服务器只是简单地响应 HTTP 请求，所有复杂的自适应逻辑都在客户端。在实际实现中，音频和视频通常被分别编码、存储和传输。客户端可以独立为音频和视频选择最适合的版本，并在本地进行同步播放。

实时流式协议 RTSP

RTSP 是一个应用层控制协议，用于媒体播放器远程控制媒体服务器的播放行为，其关键特性如下：

RTSP 特性	说明
带外协议	RTSP 信道只传输控制命令（如播放、暂停、定位），不传输实际的音视频数据。数据通过单独的 RTP 或 HTTP 连接传输
有状态协议	与无状态的 HTTP 不同，服务器需要维护客户端会话的当前状态（播放中、暂停等）
类似 HTTP 的语法	使用文本报文，易于理解和调试

RTSP 的工作流程如下：

1. 浏览器获取元文件，启动播放器。
2. 播放器向媒体服务器的 RTSP 服务端口发送 SETUP 命令，建立控制连接。
3. 播放器发送 PLAY 命令，开始接收数据流。
4. 播放过程中，可发送 PAUSE, TEARDOWN 等命令进行控制。
5. 音视频数据通过独立的连接传输。

内容分发网

单源分发的缺点

面对向全球数以亿计用户分发高带宽视频的挑战，从单一数据中心直接分发的模式存在三大缺陷：

单源分发的缺点	说明
长距离传输问题	跨洲、跨ISP传输，端到端路径长，瓶颈链路易导致卡顿
带宽浪费	热门内容被重复传输，浪费网络资源，内容商需支付高昂的流量费用
*单点故障	数据中心或出口链路故障将导致服务全局中断

CND 的部署方式

内容分发网 CDN 是解决这些问题的核心设施，它是一个地理分布式的服务器网络，用于存储和分发内容（视频、网页、图片等）的副本，并将用户请求智能地导向能提供最佳体验的服务器节点。

CDN 有两种部署原则：

原则	核心思想	优点	缺点	代表厂商
深入	将服务器集群深度嵌入到众多接入 ISP 的网络边缘，极度靠近最终用户	时延最低，吞吐量最高，优化用户体验	运维管理极其复杂，成本高
邀请做客	在少数关键枢纽位置（如靠近多个一级 ISP 的交换点）建设大型集群，并用高速网络互联。	运维管理相对简单，成本可控	用户体验（时延、吞吐）略逊于深入模式

CND 的工作流程

CDN 通常采用按需拉取的缓存策略，集群初始不存所有内容。当用户请求未缓存的内容时，集群从源站或其他集群拉取，同时本地留存副本供后续请求使用，并根据热度淘汰旧内容。CDN 的核心在于如何透明地将用户请求重定向到最优的 CDN 服务器，这主要依靠 DNS 劫持与重定向技术来实现，流程如下：

1. 内容标识：内容提供商将其内容的 URL 主机名的 DNS 解析授权给其合作的 CDN 厂商。
2. DNS 重定向：当用户 DNS 查询到达内容提供商的权威 DNS 时，后者不返回自身 IP，而是返回一个指向 CDN 域名的 CNAME 记录，将解析任务甩锅给 CDN 的 DNS 系统。
3. 智能调度：CDN 的权威 DNS 系统收到查询后，根据查询源的 IP 地址（即用户的本地 DNS 服务器 IP）和内置的集群选择策略，动态计算并返回一个最优的 CDN 服务器 IP 地址。
4. 直接交付：用户浏览器获得该 IP 后，便直接与最优的 CDN 服务器建立连接并获取内容，如通过 DASH 获取视频分片。

以第三方 CDN 为例，下图展示了从用户点击到获得内容的重定向流程：

sequenceDiagram participant U as 用户/浏览器 participant L as 本地DNS服务器 participant A as 内容提供商权威DNS participant K as CDN权威DNS系统 participant S as 最佳CDN服务器 Note over U, S: 1. 用户访问内容提供商页面 U->>U: 点击视频链接<br>http://video.netcinema.com/6Y7B23V Note over U, S: 2. DNS解析开始：寻找video.netcinema.com U->>L: DNS查询 L->>A: DNS查询 Note over A, K: 3. DNS重定向：将解析权交给CDN A-->>L: 返回CNAME: a1105.kingcdn.com L->>K: 查询 a1105.kingcdn.com Note over K, S: 4. CDN智能调度：返回最佳服务器IP K->>K: 执行集群选择策略<br>（基于LDNS IP、地理位置、负载等） K-->>L: 返回最佳CDN服务器IP L-->>U: 返回最佳CDN服务器IP Note over U, S: 5. 用户直连CDN服务器获取内容 U->>S: HTTP GET 请求视频 S-->>U: 传输视频数据（如DASH片段）

集群选择策略

CDN 的 DNS 系统决定最优服务器的常用策略如下，大型 CDN 在实际中通常混合使用多种策略，并综合考虑集群负载、与 ISP 的结算成本等因素来实现。

策略	工作原理	优点	缺点
地理最近	将用户的 LDNS IP 地址映射到地理位置，选择物理距离最近的集群。	实现简单，对多数情况有效。	LDNS 可能远离真实用户，而且地理最近 ≠ 网络最近（路由可能绕远），无法感知实时网络状况（拥堵、时延波动）。
实时测量	CDN 主动向全球 LDNS 或客户端发送探测包（如 Ping），测量时延、丢包率，选择性能最佳的集群。	能反映当前网络状态，选择更准确。	许多 LDNS 不响应探测，主动探测将增加开销，且可能干扰正常服务。
IP任播	为所有 CDN 集群分配相同的 IP 地址，并利用 BGP 路由协议，让互联网路由器自动将用户流量引导到 BGP 意义上的最近集群。	调度决策完全分布式，由网络路由决定，速度快。	由 BGP 路由决定，可能不是应用层性能最优，难以根据负载等更复杂的策略进行调度。

参考资料

《计算机网络(第七版)》 谢希仁 著，电子工业出版社
《计算机网络 自顶向下方法》 [美] James F.Kurose,Keith W.Ross 著，陈鸣 译，机械工业出版社