第8章 互联网上的音频/视频服务

8.1概述

📝 多媒体信息： 包括声音和图像信息

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

• 第一，多媒体信息的信息量往往很大。
• 第二，在传输多媒体数据【边传输边播放】时，对时延和时延抖动均有较高的要求。

📌 抖动的核心概念

1. 等时 vs. 非等时
   对模拟信号要经过采样和模数转换变为数字信号，然后将一定数量的比特组装成分组进行传送。

   • 等时（Isochronous）：发送端按严格固定间隔发送分组（如数字音频、视频流）。
   • 非等时（Anisochronous）：分组在网络中因拥塞、路由变化、排队延迟等因素，到达时间不可预测（传统IP网络的特性）。

   

   分组：

   • 由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的。因此在发送多媒体分组时应当给每一个分组加上序号。
   • 在每一个分组增加一个时间戳(timestamp)，让接收端知道所收到的每一个分组是在什么时间产生的。

2. 抖动（Jitter）

   是指在数据传输过程中，分组到达接收端的时间间隔不稳定，导致数据流不均匀或不规则的现象。

3. 抖动的表现

   • 延迟变化（Delay Variation）：比如，第一个数据包耗时 20ms，第二个 50ms，第三个 10ms → 抖动发生。

   • 数据堆积或断续：导致音频卡顿、视频跳帧、实时通话不连贯。

   • 例如：

     理想情况：|--A--|--B--|--C--|（等时到达）
     实际情况：|---A---|C|--B----|（抖动导致乱序+延迟不均）
     

📊 抖动的影响

场景	抖动的影响
实时音视频（VoIP/直播）	声音断续、画面卡顿
网络游戏	操作延迟、卡顿
金融交易系统	数据不同步，影响决策

📚 抖动问题的解决

在接收端设置适当大小的缓存【先进先出的队列】"，当缓存中的分组数达到一定的数量后再以恒定速率按顺序将这些分组读出进行还原播放。【消除了时延的抖动，但付出的代价是增加了时延。】

非等时 => 等时：

缓存使所有到达的分组都经受了迟延。由于分组以非恒定速率到达，因此早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停留的时间就较短。从缓存中取出分组是按照固定的时钟节拍进行的，因此，到达的非等时的分组，经过缓存后再以恒定速率读出，就变成了等时的分组

💻 传输实时数据特点：

丢失容忍(loss tolerant)：宁可丢失少量分组(不能丢失太多)，也不要太晚到达的分组。【在连续的音频或视频数据流中，很少量分组的丢失对播放效果的影响并不大(因为这是由人来进行主观评价的)，因而是可以容忍的。】

✏️ 目前互联网提供的音频/视频服务大体上可分为三种类型:

流媒体(streaming media)：流式音频/视频

• 流式(streaming)存储音频/视频
  • 先把已压缩的录制好的音频/视频文件(如音乐、电影等)存储在服务器上。用户通过互联网下载这样的文件。但用户并不是把文件全部下载完毕后再播放，而是能够边下载边播放，即在文件下载后不久(例如，一般在缓存中存放最多几十秒)就开始连续播放。
  • 特点：
    ✅ 内容预先录制并存储在服务器（如MP4文件）。
    ✅ 采用渐进式下载或自适应流媒体（如HLS/DASH）。
    ✅ 允许暂停、快进、缓冲，容忍较高延迟。
  • 例子：爱奇艺/腾讯视频/Netflix 等
• 流式实况音频/视频
  • 是一对多(而不是一对一)的通信。它的特点是:音频/视频节目不是事先录制好和存储在服务器中的，而是在发送方边录制边发送(不是录制完毕后再发送)。在接收时也要求能够连续播放。接收方收到节目的时间和节目中事件的发生时间可以认为是同时的(相差仅仅是电磁波的传播时间和很短的信号处理时间)。流式实况音频/视频按理说应当采用多播技术才能提高网络资源的利用率，但目前实际上还是使用多个独立的单播。
  • 特点：
    ✅ 内容实时采集并广播，无存储回放（或短暂延迟）。
    ✅ 需要低延迟。
    ✅ 可能使用UDP + 协议优化（如RTMP、WebRTC）。
  • 例子：抖音直播/快手直播 等
• 交互式音频/视频
  • 用户使用互联网和其他人进行实时交互式通信。例如：互联网电话或互联网电视会议。
  • 特点：
    ✅ 端到端实时双向通信，延迟极低。
    ✅ 严格抗抖动和丢包（如FEC、抖动缓冲）。
    ✅ 通常基于UDP + RTP/RTCP或WebRTC。
  • 例子：微信语音/视频通话、腾讯会议 等

特性	流式存储	流式实况	交互式
内容来源	预存文件	实时采集	实时双向传输
延迟要求	高容忍（秒级）	中低（秒级）	极低（毫秒级）
协议典型用例	HTTP/HLS/DASH	RTMP/WebRTC	WebRTC/RTP
用户控制	可暂停/跳转	仅观看（无回放）	实时交互
抗抖动技术	大缓冲区	CDN + 小缓冲	动态抖动缓冲

8.2 流式存储音频/视频

媒体播放器(media player)：一个用来【播放音频/视频节目】的【单独】的【应用程序】。

媒体播放器具有的主要功能：管理用户界面、解压缩、消除时延抖动和处理传输带来的差错。

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

元文件(meta file)：是一种非常小的文件，描述或指明其他文件的一些重要信息。这里的元文件保存了有关这个音频/视频文件的信息。

8.2.2 媒体服务器

媒体服务器：是专门为播放流式音频/视频文件而设计的，常被称为流式服务器(streaming server)。

传送音频/视频文件可以使用TCP，也可以使用UDP。观看实况转播，最好首先考虑使用UDP来传送。

采用UDP 会有以下几个缺点：

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

YouTube 和Netflix，都 采用 TCP 来传送，主要步骤：

• 如果用户暂停播放，那么图中的三个缓存将很快被填满，这时TCP发送缓存就暂停读取所要传送的视频文件，否则就会引起视频数据的丢失。
• 当用户继续播放时，媒体播放器每读出n bit，TCP发送缓存就可以从存储的视频文件再读取n bit。如果客户机中的两个缓存经常处于填满状态，就能够较好地应付网络中偶然出现的拥塞。
• 如果步骤②的传送速率小于步骤④的读出速率，那么客户机中的两个缓存中的存量就会逐渐减少。当媒体播放器缓存的数据被取空后，播放就不得不暂停，直到后续的视频数据重新注入进来后才能再继续播放。

8.2.3 实时流式协议 RTSP

实时流式协议 RTSP(Real-Time Streaming Protocol）

• RTSP是 IETF 的 MMUSIC 工作组(Multiparty Multimedia Session Control WG，多方多媒体会话控制工作组)开发的协议

• RTSP现在是2.0版本

• 又称带外协议(out-of-band protocol)：RTSP本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送

• 又称互联网录像机遥控协议：用来使用户在播放从互联网下载的实时数据时能够进行控制，如:暂停/继续、快退、快进等。

• RTSP以客户-服务器方式工作

• RTSP是一个应用层的多媒体播放控制协议

• RTSP的语法和操作与HTTP协议的相似——所有的请求和响应报文都是ASCII 文本。但与HTTP不同的地方是RTSP是有状态的协议(HTTP是无状态的)。

• RTSP记录客户机所处于的状态——初始化状态、播放状态或暂停状态

• RTSP控制分组既可在TCP上传送，也可在UDP上传送

• RTSP没有定义音频/视频的压缩方案

• RTSP没有规定音频/视频在网络中传送时应如何封装在分组中

• RTSP没有规定音频/视频流在媒体播放器中应如何缓存

• 在使用 RTSP 的播放器中比较著名的是苹果公司的QuickTime和Real Networks 公司的 RealPlayer。

工作过程：

8.3 交互式音频/视频

8.3.1 IP 电话概述

狭义和广义IP电话：

共同点: 在 IP 网络上进行操作。【所谓“IP 网络”就是“使用IP协议的分组交换网”的简称。这里的网络可以是互联网，也可以是包含有传统的电路交换网的互联网，不过在互联网中至少要有一个IP网络。】

不同点：

• 狭义 - 仅能电话通信
• 广义 - 不仅仅是电话通信，还可以是进行交互式多媒体实时通信(包括话音、视像等)，还可以即时传信IM(Instant Messaging)。

🌐 交互式多媒体实时通信：指通过IP网络实现的 语音、视频、数据协同传输，并支持用户之间的 实时互动。平台：Zoom、微信视频等

🌐 即时传信是一种基于IP网络的 实时文本/多媒体消息交换 服务，支持用户或群组间的 低延迟通信，通常集成了状态管理（在线/离线）、消息回执、文件传输等功能。平台：微信，Slack，钉钉等

💡关键差异的直观对比

维度	狭义IP电话	广义IP电话
业务形态	单纯语音通话	语音+视频+IM+协作（如共享白板）
典型设备	IP话机、SIP软电话	智能手机App、浏览器、智能音箱

IP电话网关

IP电话网关(IP Telephony Gateway): 它是公用电话网与IP网络的接口设备。

IP电话网关的作用就是:

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

IP电话通话质量

电路交换电话网的通话质量：

• 当电路交换电话网的通信量太大时，无法拨通电话(听到的是忙音)，即电话网拒绝对正在拨号的用户提供接通服务。
• 只要拨通了电话，保证满意的通话质量。

IP电话的通话质量，主要由两个因素决定：

• 通话双方端到端的时延和时延抖动，

• 话音分组的丢失率。【“丢失掩蔽算法” 对丢失的话音分组进行处理】

​ 但这两个因素都是不确定的，而是取决于当时网络上的通信量。若网络上的通信量非常大以致发生了网络拥塞，
​ 那么端到端时延和时延抖动以及分组丢失率都会很高，这就导致IP电话的通话质量下降。

端到端的时延

端到端的时延不应超过250ms，否则交谈者就会感到不自然。陆地公用电话网的时延一般只有 50~70ms。但经过同步卫星的电话端到端时延就超过250ms。

IP电话端到端时延是由以下几个因素造成的:

1. 话音信号进行模数转换要产生时延。【取决于 话音编码 的方法。】
2. 已经数字化的话音比特流要积累到一定的数量才能够装配成一个话音分组，这也会产生时延。【取决于**话音编码**的方法。】
3. 话音分组的发送需要时间，此时间等于话音分组长度与通信线路的数据率之比。【当采用高速光纤主干网时，该时延也不大。】
4. 话音分组在互联网中经过许多路由器的存储转发时延。
5. 话音分组到达接收端在缓存中暂存所引起的时延。
6. 将话音分组还原成模拟话音信号的数模转换也要产生一定的时延。【取决于**话音编码**的方法。】
7. 话音信号在通信线路上的传播时延。【一般都很小(卫星通信除外)，通常可不予考虑】
8. 由终端设备的硬件和操作系统产生的接入时延。

• IP电话网关引起的接入时延约为 20~40ms
• 用户PC声卡引起的接入时延为20~180ms
• 有的调制解调器(如 V.34)还会再增加 20~40ms的时延(由于进行数字信号处理、均衡等)。

话音编码

目前适合IP电话使用的ITU-T标准——话音编码统一的国际标准：

• G.729话音速率为8 kbits 的共轭结构代数码激励线性预测 CS-ACELP(Conjugate-Structure Algebraic-Code-Excited Linear Prediction)声码器。
• G.723.1话音速率为 5.3/6.3 kbit/s 的线性预测编码 LPC(Linear Prediction Coding)声码器。

标准	比特率(kbit/s)	帧大小(ms)	处理时延(ms)	帧长(字节)	数字信号处理 MIPS
G.729	8	10	10	10	20
G.723.1	5.3/6.3	30	30	20/24	16

• 比特率是输入为64 kbits 标准 PCM 信号时在编码器输出的数据率。
• 帧大小是压缩到每一个分组中的话音信号时间长度。
• 处理时间是对一个运行编码算法所需的时间。
• 帧长是一个已编码的帧的字节数(不包括首部)。
• 数字信号处理MIPS(每秒百万指令)是用数字信号处理芯片实现编码所需的最小处理机速率(以每秒百万指令为单位)。

接收端缓存空间和播放时延的大小对通话质量的影响

Skype IP 电话

• 使用互联网低比特率编解码器iLBC (internet Low Bit rate Codec)，进行话音的编解码和压缩。

• Skype支持两种帧长:

  • 20ms(速率为15.2kbits，一个话音分组块为304bit)
  • 30ms(速率为13.33 kbits，一个话音分组块为400bit)。

• Skype对话音分组的丢失进行了特殊的处理，因而能够容忍高达 30%的话音分组丢失率，通话的用户一般感觉不到话音的断续或迟延，杂音也很小。

• Skype采用了P2P和全球索引(Global Index)技术提供快速路由选择机制。

• Skype 还采用了端对端的加密方式，保证信息的安全性。Skype 在信息发送之前进行加密，在接收时进行解密，在数据传输过程中保证了中途不被窃听。

• 户数据主要存储在P2P网络中，Skype对公共目录中存储的和用户相关的数据都采用了数字签名，保证了数据无法被篡改。

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

8.3.3 实时运输协议 RTP

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

可以视为应用层的一部分

• 在应用程序的发送端，开发者必须编写用RTP封装分组的程序代码，然后把RTP 分组交给 UDP套接字接口。
• 在应用程序的接收端，RTP分组通过 UDP 套接字接口进入应用层后还要利用开发者编写的程序代码将RTP分组中把应用数据块提取出。

可以视为运输层的一部分

• 封装了多媒体应用的数据块，并且由于RTP向多媒体应用程序提供了服务(如时间和序号)

RTP分组

RTP分组只包含RTP数据，而控制是由另一个配套使用的 RTCP 协议提供的。

RTP端口号

• RTP 在端口号1025 到 65535 之间选择一个未使用的偶数 UDP端口号
• 在同一次会话中的 RTCP 则使用下一个奇数 UDP端口号
• 端口号 5004 和 5005 则分别用作RTP和 RTCP 的默认端口号。

RTP首部格式

在RTP分组的首部中，前12个字节是必需的，而12字节以后的部分则是可选的。

• 有效载荷类型(payload type)，占7位。这个字段指出后面的 RTP 数据属于何种格式的应用。
  • 对于音频有效载荷：μ律PCM(0)，GSM(3), LPC(7)；A律PCM (8),G.722(9),G.728(15)等。
  • 对于视频有效载荷：活动 JPEG (26)H.261 (31),MPEGI (32),MPEG2 (33)等。
• 序号，占16位。对每一个发送出的RTP分组，其序号加1。在一次RTP会话开始时的初始序号是随机选择的。序号使接收端能够发现丢失的分组，同时也能将失序的RTP分组重新按序排列好。
• 时间戳 - 媒体时间戳，占32位。时间戳反映了RTP 分组中数据的第一个字节的采样时刻。
  • 在一次会话开始时时间戳的初始值也是随机的。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加。
  • 接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块,从而消除时延的抖动。
  • 时间戳还可以用来使视频应用中声音和图像同步。
• 同步源标识符，占 32位。同步源标识符SSRC(Synchronous SouRCe identifier)是一个数，用来标志 RTP 流(stream)的来源。
  • SSRC与IP地址无关，在新的 RTP 流开始时随机地产生。
  • RTP使用UDP传送，因此可以有多个RTP流复用到一个UDP用户数据报中。
• 参与源标识符，占 32位。
  • 参与源标识符CSRC(Contributing SouRCe identifier)，最多可有15个。用来标志来源于不同地点的 RTP 流。
  • 在多播环境中，可以用中间的一个站(叫作混合站mixer)把发往同一个地点的多个 RTP 流混合成一个流，在目的站再根据CSRC的数值把不同的RTP流分开
• 参与源数，占4位。参与源标识符的数目。
• 版本，占2位。当前使用的是版本2。
• 填充P，占1位。P置1，表示这个RTP分组的数据有若干填充字节。在数据部分的最后一个字节用来表示所填充的字节数。
• 扩展X，占1位。X置1，表示在此RTP首部后面还有扩展首部。
• 标记M，占1位。M置1，表示这个RTP分组具有特殊意义。

8.3.4 实时运输控制协议RTCP

实时运输控制协议 RTCP(RTP Control Protocol) 主要功能是:

• 服务质量的监视与反馈、
• 媒体间的同步(如某一个RTP发送的声音和图像的配合)，
• 以及多播组中成员的标志。

RTCP分组

• RTCP分组(也可称为RTCP报文)也使用 UDP来传送，但 RTCP 并不对音频/视频分组进行封装。
• 由于RTCP 分组很短，因此可把多个 RTCP分组封装在一个UDP用户数据报中。
• RTCP分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告(例如，已发送的分组数和字节数、分组丢失率、分组到达时间间隔的抖动等)。

RTCP分组类型

类型	缩写表示	意义
200	SR	发送端报告
201	RR	接收端报告
202	SDES	源点描述
203	BYE	结束
204	APP	特定应用

结束分组 BYE 表示关闭一个数据流。

特定应用分组 APP 使应用程序能够定义新的分组类型。

接收端报告分组 RR 用来使接收端周期性地向所有的点用多播方式进行报告。

• 发送RR分组有两个目的:

  • 第一，可以使所有的接收端和发送端了解当前网络的状态;
  • 第二，可以使所有发送 RTCP 分组的站点自适应地调整自己发送 RTCP分组的速率，使得起控制作用的RTCP分组不要过多地影响传送应用数据的RTP分组在网络中的传输。

• 接收端每收到一个 RTP流(一次会话包含有许多的RTP流)就产生一个接收端报告分组RR。

• RR分组的内容有:

  • 所收到的RTP流的SSRC；
  • 该RTP流的分组丢失率(若分组丢失率太高，发送端就应当适当降低发送分组的速率);
  • 在该RTP流中的最后一个RTP分组的序号；
  • 分组到达时间间隔的抖动等。

发送端报告分组SR 用来使发送端周期性地向所有接收端用多播方式进行报告。

• 发送端每发送一个RTP流，就要发送一个发送端报告分组SR。
• SR分组的主要内容有:
  • 该RTP流的同步源标识符 SSRC;
  • 该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间(或墙上时钟时间 wall clock time);
    【要传送视频图像和相应的声音就需要传送两个流。绝对时钟时间就可进行图像和声音的同步。】
  • 该 RTP 流包含的分组数；
  • 该 RTP 流包含的字节数。

源点描述分组SDES 给出会话中参加者的描述，它包含参加者的规范名NAME(Canonical NAME)。规范名是参加者的电子邮件地址的字符串。

8.3.5 H.323

H.323 概述

H.323 是互联网的端系统之间进行实时声音和视频会议的标准。

H.323不是一个单独的协议而是一组协议。

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

H.323 核心构件

组件	功能	类比
H.323 终端（Terminal）	发起/接收音视频的设备（IP 电话、视频会议终端） 【可以是一个PC，也可以是运行H.323程序的单个设备】	参会者
网关（Gateway）	连接 H.323 网络与传统电话网（PSTN） 【连接到两种不同的网络，使得H.323 网络可以和非H.323 网络(如公用电话网)进行通信。仅在一个H.323网络上通信的两个终端就不需要使用网关。】	翻译官
网闸（Gatekeeper）	负责地址解析（地址转换）、带宽管理、访问控制（授权）和计费功能 还可以帮助 H.323 终端找到距离公用电话网上的被叫用户最近的一个网关。	调度员
多点控制单元MCU（Multipoint Control Unit）	多方会议控制（混音、视频切换） 【管理会议资源、确定使用的音频或视频编解码器】	会议主持人

H.323 体系结构

• 音频编解码器 H.323要求至少要支持G.711(64kbits的PCM)。建议支持如G.722(16 kbit的ADPCM),G.723.1(5.3/6.3的LPC),G.728(16 kbits 的低时延 CELP)和 G.729(8 kbit/s的CS-ACELP)等。
• 视频编解码器 H.323 要求必须支持 H.261标准(176x144 像素)。
• H.255.0登记信令，即登记/接纳/状态 RAS(Registration/Admission/Status)。H.323终端和网闸使用RAS来完成登记、接纳控制和带宽转换等功能。
  • 终端注册/注销：终端向网闸注册自身的联系信息（如 IP 地址、别名），加入 H.323 网络管理域。
  • 地址解析：网闸将终端的别名（如电话号码 “1001”）映射为网络地址（IP:Port）。
  • 权限认证：验证终端身份（如密码、证书），防止非法接入。
  • 状态维护：定期发送心跳消息（Keepalive），监控终端在线状态。
• H.225.0呼叫信令，用来在两个 H.323 端点之间建立连接。
• H.245 控制信令，用来交换端到端的控制报文，以便管理 H.323端点的运行。
• T.120 数据传送协议 这是与呼叫相关联的数据交换协议。用户在参加音频/视频会议时，可以和其他与会用户共享屏幕上的白板。由于使用TCP协议，因此能够保证数据传送的正确(在传送音频/视频文件时使用的是 UDP，因此不能保证服务质量)。
• 实时运输协议 RTP 和实时运输控制协议 RTCP。

H.323是在以已有的电路交换电话网为基础，增加了IP电话的功能(即远距离传输采用IP网络)。H.323的信令也沿用原有电话网的信令模式，因此与原有电话网的连接比较容易。

8.3.6 会话发起协议 SIP

会话发起协议SIP(Session Initiation Protocol)

• SIP 以互联网为基础，而把IP 电话视为互联网上的新应用。
• SIP 使用文本方式的客户-服务器协议。
• SIP 是基于报文的协议。SIP使用了HTTP的许多首部、编码规则、差错码以及一些鉴别机制。
• SIP 还有一个配套协议是会话描述协议SDP(Session Description Protocol)——使电话会议的参加者应当能够动态地加入和退出。
• SIP 系统只有两种构件：
  • 用户代理(user agent)两个程序
    • 用户代理客户 UAC(User Agent Client)，用来发起呼叫，
    • 用户代理服务器 UAS(User Agent Server)，用来接受呼叫。
  • 网络服务器(network server)两个程序
    • 代理服务器(proxy server)。接受来自主叫用户的呼叫请求(实际上是来自用户代理客户的呼叫请求)，并将其转发给被叫用户或下一跳代理服务器，然后下一跳代理服务器再把呼叫请求转发给被叫用户(实际上是转发给用户代理服务器)。
    • 重定向服务器(redirect server)。不接受呼叫，它通过响应告诉客户下一跳代理服务器的地址，由客户按此地址向下一跳代理服务器重新发送呼叫请求。
• SIP地址可以是电话号码，也可以是电子邮件地址、IP地址或其他类型的地址。SIP的地址格式，例如:
  • 电话号码 sip:zhangsan@8625-87654321
  • IPv4 地址 sip:zhangsan@201.12.34.56
  • 电子邮件地址 sip:zhangsan@163.com
• SIP 会话

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

8.4.1 使互联网提供服务质量

服务质量 QoS 是服务性能的总效果，此效果决定了一个用户对服务的满意程度。服务质量可用若干基本的性能指标来描述，包括可用性、差错率、响应时间、吞吐量、分组丢失率、连接建立时间、故障检测和改正时间等。

路由器分类：

分类(classification)，即路由器根据某些准则对输入分组进行分类，然后对不同类别的通信量给予不同的优先级。

路由器管制：

路由器能够对某个数据流进行通信量的管制(policing)，使得这个数据流不要影响其他正常的数据流在网络中通过。

路由器调度：

调度，能够决定数据的发送顺序。

呼叫接纳(call admission)：

数据流预先声明它所需的服务质量，然后或者被准许进入网络(能得到所需的服务质量)，或者被拒绝进入网络(当所需的服务质量不能得到满足)

8.4.2 调度和管制机制

1、调度机制

“调度”就是指排队的规则

默认排队规则就是先进先出FIFO(First In First Out)

• 当队列已满时，后到达的分组就被丢弃。
• 最大缺点就是不能区分时间敏感分组和一般数据分组。
• 不公平，排在长分组后面的短分组要等待很长的时间。

按优先级排队。假定优先级分为两种，因此有两个队列:高优先级队列和低优先级队列。

• 在到达路由器后就由分类器(又称为分类程序)对其进行优先级分类，然后按照类别进入相应的队列。

• 只要高优先级队列中有分组在内，就从高优先级队列中按照链路速率取出排在队首的分组。

• 只有当高优先级队列已空时，才能轮到低优先级队列中的分组输出到链路上。

• 缺点：在高优先级队列中总是有分组时，低优先级队列中的分组就长期得不到服务。

  

公平排队FQ(Fair Queuing)。

• 公平排队是对每种类别的分组流设置一个队列，然后轮流使每一个队列一次只能发送一个分组。
• 对于空的队列就跳过去。
• 缺点：长分组得到的服务时间长，而短分组就比较吃亏，并且公平排队并没有区分分组的优先级。

加权公平排队 WFQ(Weighted Fair Queuing)。

• 分组到达后就进行分类，然后送交与其类别对应的队列(假定分为三类)。

• 三个队列按顺序依次把队首的分组发送到链路。遇到队列空就跳过去。

• 根据各类别的优先级不同，每种队列分配到的服务时间也不同。

  可以给队列 i 指派一个权重 w_i 。队列 i 得到的平均服务时间为 w_i / (Σw_j) ，这里 ∑w_j 是对所有的非空队列的权重求和。

  若路由器输出链路的数据率(即带宽)为R，那么队列 i 将得到的有保证的数据率 R_i 应为 R_i = (R × w_i) / (Σw_j)

  

2、管制机制

对一个数据流，我们可根据以下三个方面进行管制:

• 平均速率：是指在一定的时间间隔内通过的分组数。但这个时间间隔的选择也说明了这个指标的严格程度。

  限定数据流的平均速率为每秒50个分组和平均速率为每分钟3000个分组，虽然这两个指标的平均值都一样，但其严格程度却不同。假定有一个数据流，有一秒钟通过了1000个分组，但一分钟平均下来仍不超过 3000个，那么这个数据流的平均速率符合后面一个指标，但却远远不满足前面的指标。

• 峰值速率：限制了数据流在非常短的时间间隔内的流量。“非常短的时间间隔”需要指明时间间隔是多少。峰值速率也同时受到链路带宽的限制。

  例如，限定数据流的平均速率为每分钟3000个分组，但同时限定其峰值速率不超过每秒1000个分组。

• 突发长度：网络也限制在非常短的时间间隔内连续注入到网络中的分组数。

漏桶管制器(leaky bucket policer)(可简称为漏桶) 可对进入网络的分组流按以上三个指标进行管制：

• 漏桶是一种抽象的机制。

• 漏桶中 最多可装入b个权标(token)。只要漏桶中的权标数小于b个，新的权标就 以每秒r个权标的恒定速率加入到漏桶 中。但若 漏桶已装满了b个权标，则新的权标就不再装入 ，而漏桶的权标数达到最大值b。

• 漏桶管制分组流进入网络的过程如下:

  • 分组进入网络前，先要进入一个队列中等候漏桶中的权标。

    • 若漏桶中有权标，就可从漏桶取走一个权标，然后就准许一个分组从队列进入到网络。

    • 若漏桶已无权标，就要等新的权标注入到漏桶，再把这个权标拿走后才能准许下一个分组进入网络。

      【“准许进入网络”不等于“已经进入了网络”，分组进入网络还需要时间，取决于输出链路的带宽和分组在输出端的排队情况。】

  • 假定在时间间隔t 中把漏桶中的全部b个权标都取走，但在这个时间间隔内漏桶又装入了rt个新的权标，因此在任何时间间隔t内准许进入网络的分组数的最大值为rt+b。控制权标进入漏桶的速率r就可对分组进入网络的速率进行管制。

3、漏桶机制与加权公平排队相结合: 管制 + 调度

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

假定有n个分组流输入到一个路由器，复用后从一条链路输出。每一个分组流使用漏桶机制进行管制，漏桶参数为 b_i 和 r_i，i=1,2,…,n

当分组流通过漏桶后等待 WFQ服务时，一个分组所经受的最大时延?

分组流i。

• 假定漏桶i已经装满了b_i个权标。表示分组流i不需要等待就可从漏桶中拿走b_i个权标，因此6个分组可以马上从路由器输出。
• 分组流i 得到的数据率R_i = (R × w_i) / (Σw_j)。
• b_i个分组中最后一个分组所经受时延最大，等于传输这b_i个分组所需的时间 d_max，即 b_i 除以传输速率: d_max = [b_i · (Σw_j)] / (R × w_i)

8.4.3 综合服务IntServ与资源预留协议RSVP

综合服务IntSery和资源预留协议RSVP都较复杂，很难在大规模的网络中实现

综合服务IntServ(Integrated Services)： 可对单个的应用会话提供服务质量的保证

IntServ 特点

• 资源预留。一个路由器需要知道给不断出现的会话已经预留了多少资源(即链路带宽和缓存空间)。

• 呼叫建立。在一个会话开始之前必须先有一个呼叫建立(又称为呼叫接纳)过程，它需要在其分组传输路径上的每一个路由器都参加。每一个路由器都要确定该会话所需的本地资源是否够用，同时还不要影响到已经建立的会话的服务质量。

  一个需要服务质量保证的会话: 在源点到终点路径上的每一个路由器预留足够的资源，以保证其端到端的服务质量的要求。

IntServ 定义了两类服务:

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

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

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

资源预留协议 RSVP(ReSource reserVationProtocol)

会话声明它所需的服务质量，以便使路由器能够确定是否有足够的资源来满足该会话的需求。

RSVP协议是面向终点的

RSVP 协议不是运输层协议而是网络层的控制协议，RSVP不携带应用数据。

资源预留协议RSVP工作原理：

• 资源预留协议RSVP在进行资源预留时采用了多播树的方式。

• PATH 报文

  • 发送端发送PATH 报文(即存储路径状态报文)，给所有的接收端指明通信量的特性。

  • 每个中间的路由器都要转发 PATH报文。

• RESV报文

  • 接收端用RESV报文(即资源预留请求报文)进行响应。

  • 路径上的每个路由器对RESV报文的请求都可以拒绝或接受。

    • 当请求被某个路由器拒绝时，路由器就发送一个差错报文给接收端，从而终止了这一信令过程。
    • 当请求被接受时，链路带宽和缓存空间就被分配给这个分组流，而相关的流(ow)状态信息就保留在路由器中。

​

IntServ 体系结构分为前台和后台两个部分。

• 组成部分：

  • 前台部分，包括两个功能块，即分类器与分组转发，分组的调度器。每一个进入路由器的分组都要通过这两个功能块。

  • 后台部分，包括四个功能块和两个数据库。这四个功能块是:

    • 路由选择协议，负责维持路由选择数据库。由此可查找出对应于每一个目的地址和每一个流的下一跳地址。

    • RSVP协议，为每一个流预留必要的资源，并不断地更新通信量控制数据库

    • 接纳控制，当一个新的流产生时，RSVP就调用接纳控制功能块，以便确定是否有足够的资源可供这个流使用。

    • 管理代理，用来修改通信量控制数据库和管理接纳控制功能块，包括设置接纳控制策略。

• 存在的主要问题:

  • 状态信息的数量与流的数目成正比。在大型网络中，按每个流进行资源预留会产生很大的开销。
  • IntServ 体系结构复杂。
    若要得到有保证的服务，所有的路由器都必须装有 RSVP、接纳控制、分类器和调度器。这种路由器称为RSVP路由器。在应用数据传送的路径中只要有一个路由器不是RSVP路由器，整个的服务就又变为“尽最大努力交付”了。
  • 综合服务 IntServ 所定义的服务质量等级数量太少，不够灵活。

8.4.4 区分服务DiffServ

1、区分服务的基本概念

区分服务 DiffServ (Differentiated Services), 有时简写为DS。 是 网络流量分类管理 的一种方式，通过 给分组打标签（标记优先级），让路由器根据标签提供不同的服务质量（QoS）。

有区分服务功能的节点就称为DS节点。

区分服务 DiffServ的要点:

• DiffServ 不改变网络的基础结构，在路由器中增加区分服务的功能。

  DiffServ将IP协议中原有8位的IPv4的服务类型字段和IPv6 的通信量类字段重新定义为区分服务DS。路由器根据DS字段的值来处理分组的转发。利用DS 字段的不同数值就可提供不同等级的服务质量。

  • DS字段现在只使用其中的前6位，即区分服务码点DSCP(Differentiated Services Code Point),
  • 后面的两位目前不使用，记为CU(Currently Unused)。

​ 由 DS 字段的值所确定的服务质量实际上就是由 DS 字段中 DSCP 的值来确定的。

• 网络被划分为许多个DS域(DS Domain), 一个DS域在一个管理实体的控制下实现同样的区分服务策略。DiffServ将所有的复杂性放在DS 域的边界节点(boundary node)中而使 DS 域内部路由器工作得尽可能简单。
• 边界路由器 的功能较多，可分为分类器(classifier)和通信量调节器(conditioner)两大部分。
  • 调节器又由标记器(marker)、整形器(shaper)和测定器(meter)三个部分组成。
• 提供了一种聚合(aggregation)功能。DiffServ是把若干个流根据其DS值聚合成少量的流。路由器对相同DS 值的流都按相同的优先级进行转发。不需要使用 RSVP 信令。

2、每跳行为 PHB

“行为”就是指在转发分组时路由器对分组是怎样处理的。例子:“首先转发这个分组”或“最后丢弃这个分组”。

“每跳”是强调这里所说的行为只涉及本路由器转发的这一跳的行为，而与下一个路由器怎样处理无关。

定义了两种 PHB：

• 迅速转发PHB(Expedited Forwarding PHB) 可记为EF PHB，或 EF。对应于EF的区分服务码点DSCP的值是101110。

  • EF指明离开一个路由器的通信量的数据率必须等于或大于某一数值。
  • 用来构造通过 DS 域的一个低丢失率、低时延、低时延抖动、确保带宽的端到端服务(即不排队或很少排队)——又称为Premium(优质)服务。

• 确保转发 PHB(Assured Forwarding PHB) 可记为 AF PHB 或 AF。

  • DSCP的第0~2位把通信量划分为四个等级(分别为001，010，011和100)，并给每一种等级提供最低数量的带宽和缓存空间。

  • 对于其中的每一个等级再用DSCP的第3~5位划分出三个“丢弃优先级”(分别为010，100和110，从最低丢弃优先级到最高丢弃优先级)

    当发生网络拥塞时，对于每一个等级的AF，路由器就首先把“丢弃优先级”较高的分组丢弃。

对比维度	区分服务（DiffServ）	综合服务（IntServ/RSVP）
核心思想	基于类（Class-Based）：分组按 DSCP 标记分类处理	基于流（Flow-Based）：为每个连接预留资源（端到端保障）
资源管理	无严格预留，仅优先级调度	严格预留带宽/延迟（通过 RSVP 信令协议）
复杂度	✅ 低（路由器只需处理少数 PHB 行为）	❌ 高（需维护每一条流的状态）
扩展性	✅ 强（适合大规模网络，如互联网）	❌ 弱（仅适用于小规模网络，如企业内网）
服务质量保证	❌ 相对保障（依赖优先级标记）	✅ 绝对保障（硬性预留资源）
标记方式	使用 IP 头部 DSCP 字段（6 位编码）	依赖 RSVP 信令协议（PATH/RESV 报文）
典型应用	互联网 ISP、多业务企业网	视频会议专线、高要求实时业务
拥塞处理	通过优先级调度缓解拥塞	直接拒绝无法满足 QoS 的新流

---

参考教材：

计算机网络（第8版） (谢希仁) (Z-Library).pdf