计算机网络 第八章：互联网上音视频服务

1.概述

多媒体信息最主要的两个特点：

  1. 多媒体信息的信息量往往很大。
  2. 在传输多媒体数据时，对时延和时延抖动均有较高的要求。

互联网提供的音频/视频服务大体上可分为三种类型：

  1. 流式（streaming）存储音频/视频
  2. 流式实况音频/视频
  3. 交互式音频/视频

2.流式存储音频/视频

“流式存储音频/视频”中的“存储”二字，表明这里所讨论的流式音频/视频文件不是实时产生的，而是已经录制好的，通常存储在光盘或硬盘中。

  1. 用户从客户机（client machine）的浏览器上用 HTTP 协议向服务器请求下载某个音频/视频文件，GET 表示请求下载的 HTTP 报文。请注意，HTTP 使用 TCP 连接。
  2. 服务器如有此文件就发送给浏览器，RESPONSE 表示服务器的 HTTP 响应报文。在响应报文中装有用户所要的音频/视频文件。整个下载过程可能会花费很长的时间。
  3. 当浏览器完全收下这个文件后（所需的时间取决于音频/视频文件的大小），就可以传送给自己机器上的媒体播放器进行解压缩，然后播放。

为什么不能直接在浏览器中播放音频/视频文件呢？这是因为播放器并没有集成在万维网浏览器中。因此，必须使用一个单独的应用程序来播放这种音频/视频节目。

2.1 具有元文件的万维网服务器

第一种改进的措施就是在万维网服务器中，除了真正的音频/视频文件外，还增加了一个元文件（metafile）。所谓元文件（请注意，不是源文件）就是一种非常小的文件，它描述或指明其他文件的一些重要信息。这里的元文件保存了有关这个音频/视频文件的信息使用元文件下载音频/视频文件的几个步骤：

  1. 浏览器用户点击所要看的音频/视频文件的超链，使用 HTTP 的 GET 报文接入到万维网服务器。实际上，这个超链并没有直接指向所请求的音频/视频文件，而是指向一个元文件。这个元文件有实际的音频/视频文件的统一资源定位符URL。
  2. 万维网服务器把该元文件装入 HTTP 响应报文的主体，发回给浏览器。在响应报文中还有指明该音频/视频文件类型的首部。
  3. 客户机浏览器收到万维网服务器的响应，分析其内容类型首部行，调用相关的媒体播放器（客户机中可能装有多个媒体播放器），把提取出的元文件传送给媒体播放器。
  4. 媒体播放器使用元文件中的 URL 直接和万维网服务器建立 TCP 连接，并向万维网服务器发送 HTTP 请求报文，要求下载浏览器想要的音频/视频文件。
  5. 万维网服务器发送 HTTP 响应报文，把该音频/视频文件发送给媒体播放器。媒体播放器在存储了若干秒的音频/视频文件后（这是为了消除抖动），就以音频/视频流的形式边下载、边解压缩、边播放。

2.2 媒体服务器

为了更好地提供播放流式音频/视频文件的服务，现在最为流行的做法就是使用两个分开的服务器，一个普通的万维网服务器，和另一个媒体播放器（media server）。

媒体服务器和万维网服务器可以运行在一个端系统内，也可以运行在两个不同的端系统中。媒体服务器与普通的万维网服务器的最大区别就是，媒体服务器是专门为播放流式音频/视频文件而设计的，因此能够更加有效地为用户提供播放流式多媒体文件的服务。因此媒体服务器也常被称为流式服务器（streaming server）。

采用媒体服务器后，下载音频/视频文件的前三个步骤仍然和上一节所述的一样，区别就是后面两个步骤：

  • 媒体播放器使用元文件中的 URL 接入到媒体服务器，请求下载浏览器所请求的音频/视频文件。下载文件可以使用 HTTP/TCP，也可以借助 UDP 等任何协议，例如使用实时运输协议 RTP。
  • 媒体服务器给出响应，把该音频/视频文件发送给媒体播放器。媒体播放器在迟延了若干秒后（例如，2~5秒），以流的形式边下载、边解压缩、边播放。

上面提到，传送音频/视频文件可以使用 TCP，也可以使用UDP。起初人们选用 UDP 来传送。不采用 TCP 的主要原因是担心当网络出现分组丢失时，TCP 的重传机制会使重传的分组不能按时到达接收端，使得媒体播放器的播放不流畅。但后来的实践经验发现，采用 UDP 会有以下几个缺点：

  1. 发送端按正常播放的速率发送流媒体数据帧，但由于网络的情况多变，在接收端的播放器很难做到始终按规定的速率播放。
  2. 很多单位的防火墙往往阻拦外部 UDP 分组的进入。
  3. 使用 UDP 传送流式多媒体文件时，如果在用户端希望能够控制媒体的播放，如进行暂停、快进等操作，那么还需要使用另外的协议 RTP 和 RTSP 。这样就增加了成本和复杂性。

于是，现在对流式存储音频/视频的播放，如Y ouTube 和 Netflix，都采用 TCP 来传送。使用 TCP 传送流式视频的几个主要步骤：

  1. 用户使用 HTTP 获取存储在万维网服务器中的视频文件，然后把视频数据传送到 TCP 发送缓存中。若发送缓存已填满，就暂时停止传送。
  2. 从 TCP 发送缓存通过互联网向客户机中的 TCP 接收缓存传送视频数据，直到接收缓存被填满。
  3. 从 TCP 接收缓存把视频数据再传送到应用程序缓存（即媒体播放器的缓存)。当这个缓存中的视频数据存储到一定程度时，就开始播放。
  4. 在播放时，媒体播放器等时地（即周期性地）把视频数据按帧读出，经解压缩后，把视频节目显示在用户的屏幕上。

这里要指出，如果是观看实况转播，那么最好应当首先考虑使用 UDP 来传送。如果使用 TCP 传送，则当出现网络严重拥塞而产生播放的暂停时，就会使人难于接受。使用UDP传送时，即使因网络拥塞丢失了一些分组，对观看的感觉也会比突然出现暂停要好些。

2.3 实时流式协议 RTSP

RTSP 是为了给流式过程增加更多的功能而设计的协议。RTSP 本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送（有点像文件传送协议 FTP 有一个控制信道），因此 RTSP 又称为带外协议。

  1. 浏览器使用 HTTP 的 GET 报文向万维网服务器请求音频/视频文件。
  2. 万维网服务器从浏览器发送携带有元文件的响应。
  3. 浏览器把收到的元文件传送给媒体播放器。
  4. 媒体播放器的 RTSP 客户发送 SETUP 报文与媒体服务器的 RTSP 服务器建立连接
  5. 媒体服务器的 RTSP 服务器发送响应 RESPONSE 报文。
  6. 媒体播放器的 RTSP 客户发送 PLAY 报文开始下载音频/视频文件（即开始播放）
  7. 媒体服务器的 RTSP 服务器发送响应 RESPONSE 报文。

此后，音频/视频文件被下载，所用的协议是运行在 UDP 上的。可以是后面要介绍的 RTP，也可以是其他专用的协议。在音频/视频流播放的过程中，媒体播放器可以随时暂停（利用PAUSE 报文）和继续播放（利用PLAY报文)，也可以快进或快退。

  1. 用户在不想继续观看时，可以由RTSP客户发送TEARDOWN报文断开连接。
  2. 媒体服务器的RTSP服务器发送响应RESPONSE报文。

请注意，以上编号的步骤 1~7 至都使用实时流协议 RTSP。步骤 8~9 “音频/视频流”则使用另外的传送音频/视频数据的协议，如 RTP。

3.交互式音频/视频

3.1 IP 电话概述

3.1.1 狭义的和广义的 IP 电话

狭义的 IP 电话就是指在 IP 网络上打电话。所谓“IP网络”就是“使用 IP 协议的分组交换网”的简称。这里的网络可以是互联网，也可以是包含有传统的电路交换网的互联网，不过在互联网中至少要有一个 IP 网络。

广义的 IP 电话则不仅仅是电话通信，而且还可以是在IP网络上进行交互式多媒体实时通信（包括话音、视像等），甚至还包括即时传信 IM（Instant Messaging）。

3.1.2 IP 电话网关

IP 电话网关（IP Telephony Gateway），它是公用电话网与 IP 网络的接口设备。IP 电话网关的作用就是：

  1. 在电话呼叫阶段和呼叫释放阶段进行电话信令的转换。
  2. 在通话期间进行话音编码的转换。

3.1.3 IP 电话的通话质量

IP 电话的通话质量的两个因素：

  1. 通话双方端到端的时延和时延抖动
    1. 话音信号进行模数转换要产生时延。
    2. 已经数字化的话音比特流要积累到一定的数量才能够装配成一个话音分组，这也会产生时延。
    3. 话音分组的发送需要时间，此时间等于话音分组长度与通信线路的数据率之比。
    4. 话音分组在互联网中经过许多路由器的存储转发时延。
    5. 话音分组到达接收端在缓存中暂存所引起的时延。
    6. 将话音分组还原成模拟话音信号的数模转换也要产生一定的时延。
    7. 话音信号在通信线路上的传播时延。
    8. 由终端设备的硬件和操作系统产生的接入时延。
  2. 话音分组的丢失率

3.2 IP 电话所需要的几种应用协议

在 IP 电话的通信中，我们至少需要两种应用协议。一种是信令协议，它使我们能够在互联网上找到被叫用户。另一种是话音分组的传送协议，它使我们用来进行电话通信的话音数据能够以时延敏感属性在互联网中传送。

3.3 实时运输协议 RTP

RTP 为实时应用提供端到端的运输，但不提供任何服务质量的保证。需要发送的多媒体数据块（音频/视频）经过压缩编码处理后，先送给 RTP 封装成为 RTP 分组（也可称为 RTP 报文)。RTP 分组装入运输层的 UDP 用户数据报后，再向下递交给 IP 层。

RTP 还有两点值得注意。首先，RTP 分组只包含 RTP 数据，而控制是由另一个配套使用的 RTCP 协议提供。其次，RTP 在端口号 1025 到 65535 之间选择一个未使用的偶数 UDP 端口号，而在同一次会话中的 RTCP 则使用下一个奇数 UDP 端口号。但端口号 5004 和 5005 则分别用作 RTP 和 RTCP 的默认端口号。

在 RTP 分组的首部中，前 12 个字节是必需的，而 12 字节以后的部分则是可选的。下面按照各字段重要性的顺序来进行介绍：

  1. 有效载荷类型（payload type）：占 7 位。这个字段指出后面的 RTP 数据属于何种格式的应用。收到 RTP 分组的应用层就根据此字段指出的类型进行处理。
  2. 序号：占 16 位，对每一个发送出的 RTP 分组，其序号加 1。在一次 RTP 会话开始时的初始序号是随机选择的。序号使接收端能够发现丢失的分组，同时也能将失序的 RTP 分组重新按序排列好。
  3. 时间戳：占 32 位，时间戳反映了 RTP 分组中数据的第一个字节的采样时刻。
  4. 同步源标识符：占32位，用来标志 RTP 流的来源。
  5. 参与源标识符：可选，最多 15 个。用来标志来源于不同地点的 RTP 流。
  6. 参与源数：占 4 位，这个字段给出后面的参与源标识符的数目。
  7. 版本：占 2 位。当前使用的是版本 2。
  8. 填充 P：占 1 位，在某些特殊情况下需要对应用数据块加密，这往往要求每一个数据块有确定的长度。如不满足这种长度要求，就需要进行填充。这时就把 Р 位置 1，表示这个 RTP 分组的数据有若干填充字节。在数据部分的最后一个字节用来表示所填充的字节数。
  9. 扩展 X：占1位，X 置 1 表示在此 RTP 首部后面还有扩展首部。
  10. 标记 M：占 1 位，M 置 1 表示这个 RTP 分组具有特殊意义。

3.4 实时运输控制协议 RTCP

实时运输控制协议 RTCP（RTP Control Protocol）是与 RTP 配合使用的协议，RTCP 协议也是 RTP 协议不可分割的部分。

RTCP 协议的主要功能是：

  1. 服务质量的监视与反馈
  2. 媒体间的同步（如某一个 RTP 发送的声音和图像的配合）
  3. 多播组中成员的标志

RTCP 使用的五种分组类型，它们都使用同样的格式：

  • 结束分组 BYE：表示关闭一个数据流。
  • 特定应用分组 APP：使应用程序能够定义新的分组类型。
  • 接收端报告分组 RR：用来使接收端周期性地向所有的点用多播方式进行报告。

3.5 H.323（IP电话的一套信令标准）

H.323 不是一个单独的协议而是一组协议。H.323 包括系统和构件的描述、呼叫模型的描述、呼叫信令过程、控制报文、复用、话音编解码器、视像编解码器，以及数据协议等。

H.323 标准指明了四种构件，使用这些构件连网就可以进行点对点或一点对多点的多媒体通信：

  1. H.323终端：这可以是一个PC，也可以是运行H.323程序的单个设备。
  2. 网关：网关连接到两种不同的网络，使得 H.323 网络可以和非 H.323 网络（如公用电话网）进行通信。仅在一个 H.323 网络上通信的两个终端不需使用网关。
  3. 网闸（gatekeeper）：网闸相当于整个H.323网络的大脑。
  4. 多点控制单元 MCU（Multipoint Control Unit）：MCU 支持三个或更多的 H.323 终端的音频或视频会议。

H.323 是一个协议族，它可以使用不同的运输协议，组成部分：

  1. 音频编解码器：H.323要求至少要支持 G.711，建议支持 G.722, G.723.1, G.728 和 G.729。
  2. 视频编解码器：H.323 要求必须支持H.261标准。
  3. H.255.0 登记信令：即登记/接纳/状态 RAS。
  4. H.225.0 呼叫信令：用来在两个 H.323 端点之间建立连接。
  5. H.245 控制信令：用来交换端到端的控制报文，以便管理 H.323 端点的运行。
  6. T.120 数据传送协议：这是与呼叫相关联的数据交换协议。
  7. 实时运输协议 RTP 和实时运输控制协议 RTCP

3.6 会话发起协议 SIP（IP电话的另一套信令标准）

SIP 协议的出发点是以互联网为基础，而把 IP 电话视为互联网上的新应用。因此 SIP 协议只涉及到 IP 电话所需的信令和有关服务质量的问题，而没有提供像 H.323 那样多的功能。SIP 没有强制使用特定的编解码器，也不强制使用 RTP 协议。然而，实际上大家还是选用 RTP 和 RTCP 作为配合使用的协议。

SIP 使用文本方式的客户服务器协议。SIP 系统只有两种构件：

  1. 用户代理（user agent）：包括两个程序：
    1. 用户代理客户 UAC (User AgentClient)：用来发起呼叫
    2. 用户代理服务器 UAS (User Agent Server)：用来接受呼叫。
  2. 网络服务器（network server）：包括两个程序：
    1. 代理服务器（proxy server）：接受来自主叫用户的呼叫请求
    2. 重定向服务器（redirect server）：通过响应告诉客户下一跳代理服务器的地址。

SIP 的地址十分灵活。它可以是电话号码，也可以是电子邮件地址、IP 地址或其他类型的地址。但一定要使用SIP的地址格式，例如：

和 HTTP相似，SIP 是基于报文的协议。SIP 使用了 HTTP 的许多首部、编码规则、差错码以及一些鉴别机制。它比 H.323 具有更好的可扩缩性。SIP 的会话共有三个阶段：建立会话、通信和终止会话。

SIP 有一种跟踪用户的机制，可以找出被叫方使用的 PC 的 IP 地址。为了实现跟踪，SIP 使用登记的概念。SIP 定义一些服务器作为 SIP 登记器。每一个 SIP 用户都有一个相关联的 SIP 登记器。

4.改进“尽最大努力交付”的服务

4.1 使互联网提供服务质量

服务质量 QoS 是服务性能的总效果，此效果决定了一个用户对服务的满意程度。

4.2 调度和管制机制

4.2.1 调度机制

“调度”就是指排队的规则。先进先出的最大缺点就是不能区分时间敏感分组和一般数据分组。在先进先出的基础上增加按优先级排队，就能使优先级高的分组优先得到服务。

但是，简单地按优先级排队会带来一个缺点，这就是在高优先级队列中总是有分组时，低优先级队列中的分组就长期得不到服务，这就不太公平。公平排队 FQ（Fair Queuing）可解决这问题。

为了使高优先级队列中的分组有更多的机会得到服务，可增加队列“权重”的概念，这就是加权公平排队WFQ（Weighted Fair Queuing），其工作原理如图：

加权公平排队 WFQ 是这样工作的。分组到达后就进行分类，然后送交与其类别对应的队列（图中假定分为三类）。三个队列按顺序依次把队首的分组发送到链路。遇到队列空就跳过去。但根据各类别的优先级不同，每种队列分配到的服务时间也不同。可以给队列 $i$ 指派一个权重 $w_i$。于是队列 $i$ 得到的平均服务时间为 $w_i/(\Sigma{w_j})$，这里 $\Sigma{w_j}$是对所有的非空队列的权重求和。这样，若路由器输出链路的数据率（即带宽）为 $R$，那么队列 $i$ 将得到的有保证的数据率 $R_i$ 应为：

$$
R_i=\frac{R×w_i}{\Sigma{w_j}}
$$

加权公平排队 WFQ 在服务质量体系结构中占有重要的地位。当前的许多路由器产品都加入了 WFQ 调度的功能

4.2.2 管制机制

前面提到了使用管制机制可以提供服务质量。对一个数据流，我们可根据以下三个方面进行管制：

  1. 平均速率
  2. 峰值速率
  3. 突发长度：在非常短的时间间隔内连续注入到网络中的分组数。

要在网络中对进入网络的分组流按以上三个指标进行管制，可使用非常著名的漏桶管制器（leaky bucket policer）（可简称为漏桶），其工作原理如图：

4.2.3 漏桶机制与加权公平排队相结合

把漏桶机制与加权公平排队结合起来，可以控制队列中的最大时延。

4.3 综合服务 IntServ 与资源预留协议 RSVp

IntServ 可对单个的应用会话提供服务质量的保证，其主要特点有二：

  1. 资源预留：一个路由器需要知道给不断出现的会话已经预留了多少资源（即链路带宽和缓存空间）。
  2. 呼叫建立：一个需要服务质量保证的会话，必须首先在源点到终点路径上的每一个路由器预留足够的资源，以保证其端到端的服务质量的要求。

IntServ 定义了两类服务：

  1. 有保证的服务（guaranteed service）：可保证一个分组在通过路由器时的排队时延有一个严格的上限。
  2. 受控负载的服务（controlled-load service）：可以使应用程序得到比通常的“尽最大努力”更加可靠的服务。

IntServ 共有以下四个组成部分：

  1. 资源预留协议 RSVP：它是IntServ的信令协议。
  2. 接纳控制（admission control）：用来决定是否同意对某一资源的请求。
  3. 分类器（classifier）：用来把进入路由器的分组进行分类，并根据分类的结果把不同类别的分组放入特定的队列。
  4. 调度器（scheduler）：根据服务质量要求决定分组发送的前后顺序。

综合服务 IntServ 体系结构存在的主要问题是：

  1. 状态信息的数量与流的数目成正比。
  2. IntServ 体系结构复杂。若要得到有保证的服务，所有的路由器都必须装有接纳控制、分类器和调度器。这种路由器称为RSVP路由器。

4.4 区分服务 DiffServ

4.4.1 区分服务的基本概念

由于综合服务 IntServ 和资源预留协议 RSVP 都较复杂，很难在大规模的网络中实现，因此 IETF 提出了一种新的策略，即区分服务 DiffServ（Differentiated Services） [RFC 2475][W-DiffServ]。区分服务有时也简写为 DS。因此，具有区分服务功能的结点就称为 DS 结点。

区分服务 DiffServ 的要点如下：

  1. DiffServ 力图不改变网络的基础结构，但在路由器中增加区分服务的功能。因此，DiffServ 将 IP 协议中原有 8 位的 IPv4 的服务类型字段和 IPv6 的通信量类字段重新定义为区分服务 DS。路由器根据 DS 字段的值来处理分组的转发。

  2. 网络被划分为许多个 DS 域（DS Domain）。一个 DS 域在一个管理实体的控制下实现同样的区分服务策略。DiffServ 将所有的复杂性放在 DS 域的边界结点（boundary node）中，而使 DS域内部路由器工作得尽可能简单。边界结点可以是主机、路由器或防火墙等。

  3. 边界路由器中的功能较多，可分为分类器（classifier）和通信量调节器（conditioner）两大部分。调节器又由标记器（marker）、整形器（shaper）和测定器（meter）三个部分组成。

  4. DiffServ 提供了一种聚合（aggregation）功能。DiffServ 不是为网络中的每一个流维持供转发时使用的状态信息，而是把若干个流根据其 DS 值聚合成少量的流。

4.4.2 每跳行为 PHB

DiffServ 定义了在转发分组时体现服务水平的每跳行为 PHB（Per-Hop Behavior）。所谓“行为”就是指在转发分组时路由器对分组是怎样处理的。

IETF 的 DiffServ 工作组已经定义了两种 PHB：

  1. 迅速转发 PHB：可记为 EF PHB，或 EF。EF PHB 用来构造通过 DS 域的一个低丢失率、低时延、低时延抖动、确保带宽的端到端服务（即不排队或很少排队）。
  2. 确保转发 PHB：可记为 AF PHB 或 AF。AF 用 DSCP 的第 02 位把通信量划分为四个等级（分别为001, 010, 011 和 100），并给每一种等级提供最低数量的带宽和缓存空间。对于其中的每一个等级再用 DSCP 的第 35 位划分出三个“丢弃优先级”（分别为 010, 100 和 110，从最低丢弃优先级到最高丢弃优先级）。当发生网络拥塞时，对于每一个等级的 AF，路由器就首先把“丢弃优先级”较高的分组丢弃。

可以看出，区分服务 DiffServ 比较灵活，因为它并没有定义特定的服务或服务类别。当新的服务类别出现而旧的服务类别不再使用时，DiffServ 仍然可以工作。

计算机网络
#课本
计算机网络 第八章：互联网上音视频服务
https://pudding.nousbuild.com/computer-network-8/
作者
Haoning Wu
发布于
2022年7月2日
更新于
2024年4月7日
许可协议