1.4 语音、视频和数据的流量特征
Cisco QoS认证考试指南（第2版）
你为什么需要QoS呢？QoS能够影响网络的带宽、延迟、抖动和丢包等属性。不同的应用对于带宽、延迟、抖动和丢包的要求也不相同。通过使用QoS，网络可以更好地为每种应用分配合理的QoS资源。
接下来的三个小节涵盖了语音流、视频流和数据流。早期的QoS考试中覆盖了更多有关语音、视频和数据的QoS特征；但当前QoS考试所涉及的这部分知识并不深入。很多阅读过本书前一版的读者认为下面的小节介绍了很多很好的背景知识，值得通篇阅读本章接下来的内容，但有关考试的更多重点内容将来自于本书的其他章节。如果你决定跳过本小节，请不要错过名为“规划和实施QoS策略”的小节，它在本章“基础小结”部分之前。
1.4.1 语音流量特征
在未使用QoS工具的网路中，语音流量的质量会衰减得很快。本章足够详细地介绍了语音流量，使大家能够理解每种QoS工具可以对语音产生的影响。
注释：本书不会深入介绍语音，因为那些细节并不直接与QoS相关。如需额外信息，请参考以下资源：
Deploying Cisco Voice over IP Solutions，Cisco Press出版，Davidson和Fox著
IP Telephony，惠普专业书籍，Douskalis著
Voice over IP Fundamentals，Cisco Press出版，Davidson和Peters著1
IP Telephony，McGraw Hill出版，Goralski和Kolon著
www.cisco.com/warp/public/788/voip/delay-details.html
若不使用QoS，呼叫者会体验到很差的语音质量，语音会变得断断续续或不知所云。延迟会导致可交互性降低，比如通话的双方可能总是会同时说话，因为延迟会使人感觉对方已经说完了他/她想说的话。再比如声音丢失，会使呼叫者听到空白音。甚至呼叫还能能被中断。
大多数QoS问题都可以分为4个QoS特性来进行讨论：带宽、延迟、抖动和丢包。首先我们先介绍数据网络中的语音基础，接下来就这4种QoS特性，来讨论针对语音流量实施的具体QoS策略。
1．语音基础
数据网络中的语音包括：IP语音（VoIP）、帧中继语音（VoFR）和ATM语音（VoATM）。这3种数据语音技术都用来传输语音，但它们之间又有些微差别。在考试中，你见到的大多数问题都是与VoIP相关的，而不是VoFR或VoATM，因为在这3项技术中，VoIP是最普及的。Cisco IP电话建立的所有呼叫都使用VoIP，而不是VoFR或VoATM。
请想象在图1-17中，两台模拟电话201和301之间建立了一通呼叫。
在对端电话能够听到声音之前，会发生一系列事件。任一方用户需要摘机并拨号，连接该电话的路由器会对号码进行翻译，然后使用信令的方式建立VoIP呼叫（本例中两台电话分别连接在R1和R3的FXS模拟端口上，因此路由器使用H.323信令）。在信令的处理过程中，主叫方会听到回铃音，被叫方会听到电话振铃。当被叫方摘机后，呼叫建立完成。
实际的语音呼叫（相对于信令来说）使用的是实时传输协议（RTP）。图1-18给出了使用RTP的IP数据包格式。
在两台模拟电话之间建立呼叫的过程中，路由器首先会收集模拟语音，然后将语音数字化，再用一种语音编码方式将语音进行编码，最后将编码后的语音放入图1-18所示的负载字段中。举例来说，R1会创建如图1-18所示的IP数据包，将编码后的语音比特放入语音负载字段，然后发送数据包。源IP地址是R1上的IP地址，而目的IP地址是R3上的IP地址。当R3接收到数据包后，它会执行反向操作，最终通过模拟电话播放出模拟声波。
IP电话所经历的的呼叫过程在概念上与之相似，但具体细节有些不同。IP电话所使用信令包括SCCP（Skinny客户端控制协议，Skinny Client Control Protocol），该协议工作在IP电话与CUCM2（Cisco Unified Communications Manager）服务器之间。信令完成后，两台IP电话之间建立RTP流。CUCM并不直接参与实际的通话，它只在呼叫建立和拆除阶段介入（CUCM为了实现控制，会与每台IP电话维护一个TCP连接）。R1和R3并不会代替IP电话来创建RTP数据包，因为IP电话自己负责创建RTP数据包。在R1和R3看来，IP电话发送的数据包只是IP数据包。
最后，网络管理员可以选择VoIP呼叫所使用的编/解码器（编码）。编码器负责处理入站的模拟信令，将其转换为数字（二进制）信令。用来表示语音的二进制数值，根据管理员所设定的编码，而有所不同。每种编码都有多种特性，其中最重要的特性是所需带宽，即设备发送这种编码创建的语音负载需要多少带宽。表1-10给出了常用的编码及其所需带宽。
*负载包含数字化语音，但不包含传输语音流量所需的包头和包尾
语音基础（是的，非常基础！）部分可以总结为以下内容。
多种语音信令协议可以通过响应用户在电话上的拨出的号码，在两台电话之间建立RTP流。
RTP流用于在两台电话之间（或在其VoIP网关之间）传输语音。
为什么对语音的描述如此简单？这是因为所有语音负载流都需要相同的QoS特征，而所有语音信令流都需要相同的其他QoS特征。通过每种类型的QoS工具，本书会给出如何为“语音”实施QoS工具，其中分两类讨论，即语音负载（RTP数据包）和语音信令。表1-11对比了语音负载和语音信令所需的QoS需求。
通过使用QoS工具，管理员可以用不同的方式，分别对待语音负载和语音信令。因此每类QoS工具都需要首先把语音数据包归类到这两种类型之中。为了分类，QoS工具需要能够定位数据包中的一个字段，这个字段表明这个数据包是语音负载、语音信令或者表明这是其他类型的数据包。表1-12列出了用于语音信令和语音负载的各种协议、定义该协议的文档，并说明如何对其进行识别。
接下来的内容将针对4项QoS特征，更详细地介绍与语音相关的内容：带宽、延迟、抖动和丢包。
2．语音带宽考量
语音呼叫会建立一个拥有固定数据速率的流，即每个数据包之间具有相等的间隔。我们可以把语音数据流描述为等时的（isochronous），引用Dictionary.com的解释，意思是“具有相同时间间隔的特征，或在相同时间间隔发生。”请考虑图1-19所示案例，模拟电话201和301之间建立了一通呼叫。
R1创建出IP/UDP/RTP语音负载数据包并将其发送出去，默认发送间隔为20毫秒。由于Cisco IOS软件在每个数据包中放入20毫秒的编码语音，因此设备需要每20毫秒发送一个数据包。这时，语音负载实际需要多少带宽？真实带宽需求量依赖于以下几个方面：
编码；
数据包开销（IP/UDP/RTP）；
数据链路成帧类型（取决于使用的数据链路）；
压缩。
很多人将G.711呼叫按64 kbit/s计算，将G.729呼叫按8 kbit/s计算，这个带宽值仅考虑了负载，忽略了数据链路、IP、UDP和RTP头部。
不同的编码选择以及是否使用RTP头部压缩，会导致带宽需求截然不同。压缩RTP（cRTP）会压缩IP/UDP/RTP头部，并且当使用较低比特率的编码时，带宽需求会显著降低。在使用G.711时，由于大多数带宽需要承载的是语音负载，因此虽然cRTP有助于减少带宽需求，但从百分比来看，带宽需求降低得并不明显。不管编码类型是什么，只要使用了cRTP，就会增加延迟，因为处理器需要对包头进行压缩和解压缩。
注释：尽管实际中有很多编码选择，但本书在多数案例中仅对比G.711和G.729，需要注意的是，在使用其他编码时，可能需要不同的QoS策略。
ATM会在语音数据包上添加可观的数据链路开销。每个ATM呼叫都有5字节的开销；除此之外，只有一部分承载了语音数据包的最后一个信元（Cell）中，可能会有很多浪费的空间。举例来说，G.729呼叫的数据包大小为60字节，ATM为其添加8字节的帧开销，之后将这68字节的帧放到两个信元中——其中一个占满ATM信元负载的48字节，而另一个占用20字节的信元负载，并“浪费”掉28字节。因此为了发送一个大小为60字节的语音“数据包”，将会有总大小为106字节的两个信元被发送到ATM网络中。有一个方法可以减少开销，即在负载中包含30毫秒的G.729编码语音，有趣的是这也只需要两个ATM信元。
语音活动检测（VAD，Voice Activity Detection）也会对语音负载实际使用的带宽产生影响。当通话中没有声音时，VAD可以让语音数据包的发送方不发送任何数据包。由于人们在聆听的时候通常不说话，因此对话是交互式的（我知道例外也总是存在的，就像我现在就能想到例外场景！），从而VAD可以将实际带宽减少60%左右。为每通呼叫节省的带宽量是无法预测的，比如在吵杂的环境中通话，VAD就无法生效了。同时VAD也会使通话者感到不愉快。比如通话者有一段时间没说话，当他再次开始说话时，根据VAD的逻辑，前端语音有可能被剪切，也就是不发送最开始几毫秒的语音。
表1-13全面对比了在不同的数据链路协议上，两种编码类型实际所使用的比特率。该表还分行显示出这两种常见编码在每个数据包中承载默认20毫秒语音负载（每秒50个数据包）以及30毫秒语音负载（每秒33.3个数据包）的情况。
*第3层带宽消耗是指数据包第3层包头到数据（有效负载）部分所消耗的带宽
表1-13呈现出一个有趣的事实：将G.729从50 pps（每数据包20毫秒负载）改为33 pps（每数据包30毫秒负载），在ATM链路上会极大地节省带宽。这是因为转发60字节的VoIP数据包（G.729的20毫秒负载）需要两个ATM信元，转发80字节的VoIP数据包（G.729的30毫秒负载）也需要两个ATM信元。
3．延迟考量
延迟过多会降低语音呼叫的质量，现象表现为语音断断续续，甚至导致呼叫断开。这种情况下，沟通也会变得困难，不知你是否曾经使用无线电话通话，感觉像在使用无线电？“嘿，弗雷德，我们去打保龄球吧。完毕。”“好的，巴尼，我们去打保龄球，贝蒂和威尔玛去逛街。完毕。”如果延迟很大的话，可能无法知道何时该你讲话了。
语音流量与其他数据包一样，也会遭遇延迟，这些延迟来自于不同的源。表1-14有助于回顾前文讲述的延迟组成。
图1-20所示案例解释了延迟的相关概念，并给出了延迟值（举例）。如果延迟是可以忽略的，案例中将其列为0。图中的数字表示延迟值，这些值是根据真实情况编造的。转发延迟通常以微秒为单位，因此是可以忽略的。R1到R2之间的传播延迟是以100千米链路为标准计算的。串行化延迟是以未经压缩的G.729语音数据包为标准，且假设PPP为其数据链路协议。队列延迟的可能范围很大；本例在R1的56 kbit/s链路上给出了15毫秒——假设语音数据包前面排了一个105字节的数据帧——这并不是一个很大的队列延迟。50毫秒的网络延迟是编造的，但这是一个非常合理的数字。本例中的总延迟是94毫秒，对于数据网络工程师来说，这个延迟相当理想。
这样就足够了吗？语音呼叫可以容忍多小的延迟？ITU对合理的单向延迟预算进行了定义，但Cisco有不同的想法。你可能会遇到这种用户：为了省钱而忍受大延迟。举例来说，有质量保证的国际呼叫需要每分钟3美元，那么你可能更倾向使用质量差的免费呼叫。表1-15列出了延迟预算的建议。
图1-20中的呼叫满足了G.114推荐的延迟预算。但对于语音流量来说，除了数据流量会遭遇的所有延迟类型之外，还有一些额外的延迟类型：
编解码延迟（Codec Delay）；
封包化延迟（Packetization Delay）；
去抖动缓冲延迟（De-jitter Buffer Delay）（初始播放延迟，Initial Playout Delay）。
警告：
很多图书和网站使用不同的术语来表示这3种与语音相关的延迟类型。本书使用的术语与Cisco课程一致，因此也与考试一致。
编解码延迟和封包化延迟彼此相同。要理解它们的中心概念请看图1-21，本例中问了一个问题，“从讲话者说出的话，到设备发送IP数据包，这之间经历了多少延迟？”
考虑一下，在IP电话发送数据包之前，都会发生什么。呼叫者拨号，之后呼叫建立。当呼叫建立后，IP电话开始发送RTP数据包。一旦IP电话开始发送数据包，它每20毫秒（默认）发送一个，也就是说每个数据包的语音负载中有20毫秒的语音。那么从说话者发出声音，到携带这部分声音的数据包被发送出去，这之间需要多长时间？
请想象声音波动了一瞬间。若你和我坐在同一间屋子里交谈，从你说话到我听到，这段延迟是非常小的，因为你的声音是以声速传播的，也就是大约1000千米每小时。在包交换电话通讯中，设备需要把声音转换成模拟电子信号，后再转换成数字电子信号，最后将这个数字信号（负载）放入数据包中，也就是说设备需要时间来做上述操作。因此在讲话者说话后，到设备发送IP/UDP/RTP负载数据包之前，将会有一些延迟，并且在这期间经历的延迟如下所示：
封包化延迟；
编解码延迟。
4．封包化延迟
IP电话或语音网关必须收集20毫秒的语音，才会将20毫秒语音负载放入一个数据包中（使用G.711和G.729的IP电话和Cisco IOS软件网关默认会将20毫秒的语音放入一个RTP数据包中；管理员可以修改这个值）。因此，在本书的讨论中，我们总是在案例中使用20毫秒的标准。这也就是说，说话者必须说了20毫秒之后，设备才会创建承载20毫秒语音的数据包。
5．编解码延迟
编解码延迟包含以下两部分：
处理入站模拟信号并将其转换成相应数字信号所花费的时间；
称作先行控制（Look-Ahead）的特性。
先说说编解码延迟中的第一个部分，这部分对于所有编解码类型来说都是一样的，IP电话或网关必须对入站的模拟信号进行处理，根据所使用的编解码类型，将其编码为相应的数字信号。举例来说，G.729一次性处理10毫秒的模拟语音。这个处理过程确实需要花费时间，将模拟信号转换成G.729 CS-ACELP（共轭结构-代码激励线性预测）实际所花费的时间大约为5毫秒。根据编码负载，Cisco站点中的一些文章将这个数值取值在2.5～10毫秒。
编解码算法可能会引入额外的延迟，这是由其名为先行控制（Look-Ahead）的特性所致。在预知编码类型的条件下，会用到先行控制。换句话说，就是通过利用人类声带的特性（无法从一种声音瞬间转换成另一种完全不同的声音），使用更少的比特数来编码语音。通过研究语音讲话，并且知道在接下来的几毫秒后，声音不会发生显著的变化，这时算法就可以用更少的比特数来编码语音——这是将64 kbit/s的G.711呼叫发展成8 kbit/s的G.729呼叫的一种方法。然而，预知算法通常要求编解码器在处理将被编码的语音信号时，要连同接下来的几毫秒语音一起处理。比如G.719编码要处理10毫秒语音样本，编解码器需要收到全部的10毫秒语音，还要加上接下来的5毫秒，这是为了执行编码算法中的预知部分。
因此G.729a编码为语音带来的延迟如下，以10毫秒样本为例，从要被编码的这10毫秒语音到达时开始算起：
5毫秒先行控制+5毫秒处理（平均）=10毫秒
要记住，编码延迟会根据编码负载而变化。Cisco.com中的白皮书“Understanding Delay in Packet Voice Networks（理解包交换语音网络中的延迟）”提供了更多的相关内容（http://www.cisco.com/en/US/tech/tk652/tk698/technologies_white_
paper09186a00800a8993.shtml）。
6．考虑封包化延迟和编解码延迟带来的影响
我们需要综合考虑封包化延迟和编解码延迟，因为它们也确实混杂在一起。举例来说，封包化延迟会消耗20毫秒，用来等待20毫秒的语音传来。但在这前20毫秒之间还发生了什么？请看表1-16，这里列出了各个事件发生的时间表，这个表是从讲话者开始说话计算的。
需要注意的是，封包化延迟和编解码延迟重叠在一起。尽管它们各自耗费20毫秒，但由于它们重叠在一起，因此数据包实际经历的总延迟是30毫秒，而不是40毫秒。
7．去抖动缓冲延迟
去抖动缓冲延迟是语音延迟的第三个组成部分。抖动切实发生在数据网络中，你可以控制它，为抖动敏感的流量最小化抖动，但你不能消除它。但为什么要在介绍延迟的部分介绍抖动？因为缓解抖动带来影响的重要工具——去抖动缓冲区（有时也称为抖动缓冲区）会增加延迟。
去抖动缓冲区会收集语音数据包并稍后将其播放给收听者，也就是延迟几毫秒后在播放语音。通过这种做法，若下一个数据包遭遇了抖动，到达的时间延后了，这时去抖动缓冲区中的数据包就可以与这个遭遇了抖动的数据包同步播放，这可以使声音听起来质量更好。在汽车的CD播放器中也使用了相同的工具——CD播放器会预读几秒钟，因为知道汽车可能会颠簸，而CD可能会遇到暂时不可读的情况——但CD播放器可以持续播放储存在固态内存中的音乐。同样地，去抖动缓冲区也会在语音播放前，通过收集语音来进行“预读”，这样被延迟的数据包就不容易引起语音的中断。
去抖动缓冲区必须在开始播放语音前填满，这个延迟称为初始播放延迟，详见图1-22所示。
本图展示了去抖动缓冲区中的初始播放延迟。第一个数据包到达时间，与第三个数据包到达时间，之间的时间差是可变的，在本图所示案例中，间隔40毫秒（Cisco IOS网关默认将初始播放延迟设置为40毫秒）。事实上，若把初始播放延迟设置为40毫秒，那么无论接下来的几个数据包是否抵达，延迟都是40毫秒。考虑图1-23所示案例，本例更深入阐述了去抖动缓冲区的工作原理。
在图1-23中，无视其他数据包的到达时间，开始播放语音的时间以静态设置的播放延迟间隔为准，本例中为40毫秒。40毫秒的去抖动播放延迟允许语音遭遇抖动——毕竟我们知道抖动总会发生——它能够维持一定的速率播放语音。
图1-24汇总了语音呼叫中的所有延迟组成部分。本图沿用了图1-20中的一些延迟值，同时给出了语音相关的延迟：编解码延迟、封包化延迟和去抖动缓冲延迟。
根据G.114建议，这个延迟有些超出了可接受的单向延迟范围，但还在Cisco建议的200毫秒范围内。不考虑额外增加的语音延迟，150毫秒延迟预算看来还是可以达到的。然而编解码延迟和封包化延迟共30毫秒，（合理的）默认去抖动延迟（实际为去抖动初始播放延迟）有40毫秒，这几项就占去了150/200毫秒延迟中的70毫秒。如此一来，如何能将总延迟维持在可接受的延迟预算中？你可以针对可变延迟来实施策略。表 1-17 列出了不同的延迟组成部分，并标明了哪项是可变的。
8．语音抖动考量
前文介绍延迟的部分详细介绍了语音流与抖动的技术细节。若抖动不会降低语音呼叫的质量，那么它就不会成为一个问题。但无论抖动快速增加还是快速降低，都会影响接收语音的模式并且丢失声音。以图1-25为例，数据包3和4遭遇了抖动。
在图1-25中，第二个数据包与第一个数据包遭遇的延迟相同。如何得出这个结论的？IP电话或Cisco IOS网关以20毫秒的间隔发送数据包；如果数据包每隔20毫秒到达一个，那么它们的延迟也是相同的，也就是说没有抖动。但本例中，数据包3在数据包2到达后40毫秒才到达，这意味着数据包3遭遇了20毫秒的抖动。数据包3到达后45毫秒，数据包4才到达，由于数据包4是在数据包3发送后第20毫秒发出的，因此数据包4遭遇了25毫秒的抖动。这种情况带来的后果是去抖动缓冲区空了，并且会产生一段静音。事实上，数据包4出现后，接收方会丢弃这个数据包，因为相对于短暂的静音，播放迟到的语音会带来更大的问题。
将去抖动缓冲区的大小可视化，可以参考图1-26所示的方法。数据包到达的时间与图1-25相吻合，去抖动缓冲区的大小由y轴表示。
是什么导致了抖动？是各种延迟类型。其中两个最臭名昭著的可变延迟是队列延迟和网络延迟。队列技术可以做到尽快服务语音数据包，从而能够降低并稳定语音数据包的队列延迟。管理员还可以使用LFI技术将大数据包分片为多个小数据包，并且允许语音数据包穿插在这些小数据包之前获得服务。最终，管理员需要对这些超额订阅的帧中继和ATM网络进行重新设计，来减少延迟。与语音和QoS相关的抖动概念可以总结如下：
抖动总是发生在分组网络中；
接收侧的去抖动缓冲区可以弥补一些抖动；
QoS工具，尤其是队列工具和分片工具，可以将抖动值降到足够低，以便使去抖动缓冲区能够有效地提供服务；
管理员可以通过设计帧中继和ATM网络，来减少网络延迟和抖动。
注释：在IP电话上按下信息（“i”）按钮，可以查看抖动的状态信息。
9．语音丢失考量
路由器会由于多种原因丢包，其中两个最大的原因如下：
比特错误；
队列排满。
QoS对于比特错误无能为力，但可以对队列空间排满造成的丢包产生极大的积极影响。图1-27中对比了FIFO队列（单一队列）和一种简单的双队列机制，即一条队列用于语音负载，另一条队列传输其他所有流量。
假设有4个数据包几乎同时到达，编号1～4，其中数据包1首先到达。在FIFO机制中，路由器将这些数据包以其到达的顺序放入FIFO输出队列中。若输出队列如图所示，仅能排列3个数据包，会发生什么？第四个数据包会被尾部丢弃。
现在再假设第四个数据包是语音数据包，并且使用双队列机制，每条队列都能够排3个数据包。那么在此案例中，路由器就不会丢弃语音数据包（数据包4）。事实上，假设路由器中配置有语音队列，该队中的数据包会被优先转发，从而减少了语音数据包的延迟。
注释：最大队列长度为3也太短了；但在图中表示40个数据包的队列也未免有些繁复。
图1-27底部的案例中，路由器没有丢弃语音数据包。但稍微深入了解双队列机制，才会发现它真正的强势之处。假设呼叫准入控制（CAC）只允许这台路由器并发两路G.729呼叫，并且假设这台路由器不使用cRTP。那么每路呼叫所需带宽为26.4 kbit/s，共计52.8 kbit/s。现在想像一下，队列机制总是为语音数据包分配最高优先级，也就是当语音数据包到达后，将“当前正在发送的”数据包发送完成后，马上发送语音数据包。然后假设队列机制在这个128 kbit/s链路上，为语音队列确保60 kbit/s带宽。综合上述所有特性，语音队列永远不会等待很长时间（假设使用以下参数）：
队列机制总是将语音数据包置于最高优先级；
呼叫准入控制（CAC）防止并发过多的语音呼叫；
LFI允许语音数据包穿插到大数据数据包的分片前；
这个接口上的语音队列永远不会排满，语音数据包永远不会被尾部丢弃。
另一种QoS工具——呼叫准入控制（CAC）——是避免丢包策略中一个非常重要的组成部分，继而可以提高语音质量。基于路由器且作用于语音的最佳队列工具包括一系列将一部分带宽用于语音队列的机制。当接口还排有其他数据包时，若队列超过最大值，则超出部分的语音数据包会被丢弃。从字面上理解，超额建立一个呼叫，就会导致所有语音呼叫的质量降低。因此仍需考虑CAC的其他形式，以避免丢失所有呼叫。
最后，当一个单独的语音负载数据包丢失时，有另一个特性可以提供帮助。G.729编码会通过预测未来几毫秒的语音，来压缩语音的有效负载部分。G.729会使用相同的逻辑来执行一个名为自动填充（Autofill）_的功能，这个功能是在呼叫接收侧将数字信号转换成模拟信号时应用的。G.729自动填充特性能够在后续数据包丢失时，对后续几毫秒的语音做一个学术猜测。自动填充特性做出学术猜测后，可以填充30毫秒“丢失的”语音。由于在使用G.729编码时，IP电话和IOS网关默认在每个数据包中发送20毫秒的语音，因此丢失一个数据包时，G.729自动填充算法会对丢失的语音数据包进行最佳猜测，并播放猜测的语音。
与语音丢失相关的内容可以总结如下：
路由器会由于多种原因丢弃数据包；最可控的原因是由于队列排满而导致的尾部丢弃；
通过队列技术，（等时地）将语音放入其他队列，而不是放入排满数据流量的队列，可以降低语音数据包遭遇尾部丢弃的几率；
QoS工具有助于保障语音质量，尤其是队列和LFI，它们会降低语音队列排满的几率，从而避免尾部丢弃；
其他QoS工具能够针对其他类型的数据包进行控制，从而保障语音质量，CAC通过语音数据包来保护语音流；
使用G.729时，单一的数据包丢失可以通过自动填充算法进行补偿。
1.4.2 视频流量特征
在未使用QoS的环境中，视频流通常质量不高：画面可能会不清晰，动作可能会忽动忽停或看起来像慢动作，并且通常音频会变得和视频不同步。可能视频已经完全看不了了，但音频还在继续播放。简而言之，除非网络为所有流量提供足够的带宽，否则视频质量总是会降低的。
与本章前文介绍语音相同，本节也把视频流量与4个QoS特征关联起来进行分析：带宽、延迟、抖动和丢包。首先先介绍分组视频的基本内容，然后根据这4个QoS特征，分别介绍与视频相关的细节内容。
1．视频基础
IP数据包视频可以分为以下两大类。
交互式视频——包括H.323会议系统，比如Cisco IP/VC 3500系列产品和微软NetMeeting桌面视频会议产品。H.323视频会议工具使用RTP协议来传输音频和视频负载，通常使用单独的RTP流来发送音频和视频。
非交互式视频——包括网络教学视频服务和流媒体，产品包括Cisco IP/TV、微软Windows媒体技术产品和RealNetworks产品。有些非交互式视频使用H.323标准来完成视频呼叫的建立和拆除，而有些则不是这样；举例来说，RealNetworks最新的服务器使用RTSP（实时流传输协议，Real-Time Streaming Protocol）来完成呼叫建立和拆除，并且根据所使用的视频播放器，通过私有的RealNetworks数据传输（RDT）协议或RTP协议来传输视频负载。
与语音编码相同，视频编码负责将模拟的音频和视频转换为数据包的形式。与语音延迟一样，视频延迟中也包含编解码延迟、封包化延迟和去抖动初始播放延迟。视频会使用常见的语音编码来转换音频信号，其中包括G.711和G.729，并将音频信号与视频信号分开发送。视频会使用多种编码类型来转换视频信号，其中包括ITU H.261和流行的MPEG编码（动态图像专家组，Moving Pictures Experts Group）。图1-28描述了一个建立在两台H.323视频会议系统之间的视频会议。
在视频会议开始前，会发生下列事件。
用户必须设置/点击正确的应用程序设置选项，来申请参加一个会议，通常这个步骤非常简单，比如告诉H.323应用程序一个特定的主机名，来表明你想要参加一个会议。
VC单元必须处理H.323/H.225呼叫建立消息。
必须建立两个RTP流——一个用于音频，一个用于视频。
到目前为止，语音和视频之间的相似性超过了差异性。它们之间最大的不同在于视频对于带宽的要求（下面的小节“视频带宽考量”中介绍了视频对于带宽的需求）。表 1-18中总结了视频和音频所需的QoS特征类型。
正如语音一样，很多QoS工具的功能也是尽可能为视频负载满足它所需的QoS特征。与此同时，你可能仍希望将视频信令流与其他数据流区别开来，也希望将视频负载流区分对待。为了进行流量分类，QoS工具需要利用数据包中的一个字段来确定这个数据包是视频负载、视频信令，还是其他类型的数据包。表1-19列出了用于视频信令和负载的各种协议、定义该协议的文档，并说明如何对其进行识别。
接下来的内容将针对4项QoS特征，更详细地介绍与视频相关的内容：
带宽；
延迟；
抖动；
丢包。
2．视频带宽考量
与语音不同，同一个视频流中的数据包大小和数据包速率不尽相同。大多视频编码利用一种普遍称之为“预测”的机制，即发送编码过的视频帧（大数据包）后，跟着发送一系列矢量（小数据包），用来描述前面数据帧的变化。尽管这种算法及大地降低了视频对于带宽的需求，但它直接导致视频流中的数据包速率不统一，数据包大小不统一。然而一段视频实际所需的带宽取决于编码复杂性，以及视频中的物体移动次数。表1-20列出了4种流行的视频编码及其所需带宽。
不同的编码只是通过衡量视频质量和带宽需求，为管理员提供了不同的选择，并且各种编码都需要对所有类型的应用提供支持。举例来说，MPEG中包含了多个标准，每个标准都是针对不同的应用类型提出的。ITU H.261为视频会议提供了一个视频标准，这个标准适用于参会者不太移动的情况！举一个例子，若视频会议中讲话的人肢体语言很丰富，那么与会者可能会从屏幕上看到断断续续的手部运动。所有这些编码类型都使用动态带宽和不同的数据包大小。图1-29显示出H.261视频会议呼叫中，不同大小数据包所占的百分比。
如前所述，视频流中的数据包大小和数据包速率并不统一。比如一个高质量的视频会议可能平均需要768 kbit/s带宽，而真实的数据包速率可能低到35pps，也可能高达120pps。此外，管理员还需要为持续发送的视频信令流考虑一些额外的开销。一些QoS工具配置选项可能不仅受到带宽需求（kbit/s）的影响，还受到数据包速率（pps）的影响。要记住，队列大小是以数据包数量来计算的；因此为了避免尾部丢弃，视频流队列比语音流队列需要大得多的队列空间。此外，Cisco建议在为视频配置队列工具时，管理员应该分配多于20%的平均带宽，来处理这一小部分易变的视频流。Cisco还建议要为视频流保留不超过33%的链路带宽。表1-21总结了语音和视频流量在带宽需求上的主要不同点。
3．视频延迟考量
双向或交互式分组视频会与语音呼叫遭遇相同的延迟类型。但单向或流媒体分组视频能够忍受相当大的延迟。请考虑图1-30中的情况，一台分组视频设备正在接收一个单向流媒体视频流。
在图1-30所示案例中，最初的播放延迟花费了30秒——不是30毫秒，而是30秒。本例中不涉及交互，也没有视频流返回视频服务器；因此这种环境中最重要的特性是：一旦视频开始播放了，它就拥有很高的质量。通过配置30秒的去抖动缓冲区，可以积累30秒（不是毫秒）的抖动，这样在播放期间就不会受到延迟或抖动的影响了。
对于双向交互式分组视频来说，延迟肯定会影响质量。前文介绍语音和语音延迟的部分已经为你提供了与视频延迟相关的大部分内容。视频会遭遇编解码延迟、封包化延迟和去抖动（初始播放）延迟。要特别注意的是，视频延迟预算通常要求高质量的视频会议延迟在0～200毫秒，去抖动初始播放延迟在20～70毫秒。
4．视频抖动考量
与延迟承受能力一样，单向视频比双向交互式视频能承受更多的抖动。在规划QoS时，对于双向视频的处理方法应该与语音相同，也就是最小化它的延迟。此外，建议正确且精确地分配/部署带宽。管理员应该给予单向流媒体视频足够的带宽，它能承受更多的延迟和抖动。
与视频网络相关的抖动考量可以总结如下：
抖动总是发生在分组网络中；
接收侧的去抖动缓冲区可以弥补一些抖动；
为交互式视频设置的去抖动缓冲区为几十毫秒，允许发生影响视频质量的小抖动；
为流媒体视频设置的去抖动缓冲区为几十秒，允许遭遇极大的抖动，但不会影响视频质量；
QoS 工具，尤其是队列工具和分片工具，可以将抖动值降到足够低，以便使去抖动缓冲区能够有效地提供服务。
5．视频丢包考量
丢包会降低视频流的质量。由于丢失了数据帧，画面会变得忽动忽停或停滞，音频也可能便变得断断续续。总之，视频无法忍受丢包。
路由器会由于多种原因丢包，由于队列排满导致的丢包可以通过多种QoS工具来解决。记住，尾部丢弃描述的是当队列已排满，路由器收到了一个要放入这个队列的数据包，这时路由器就会丢弃这个数据包。你可以通过4种基本的QoS策略来降低丢失视频数据包的风险。
启用队列机制，将视频数据包放入单独的队列，与拥塞的数据流分开；
将视频队列配置得长一些；
启用CAC，来防止视频队列中并发过多的视频流。换句话说，CAC能够在视频流中保护视频质量；
在能够容忍丢包的数据流（通常是数据，不是视频！）中使用RED（随机早期检测，Random Early Detect）工具，它会降低这些数据流的发送速度，从而降低接口总体的拥塞情况。
6．语音和视频对比：总结
表1-22对比了视频和语音对于QoS的不同需求。
1.4.3 数据流量特征
本书以及与本书相关的考试，都假设你在使用本书前，已经具有相当高水平的数据流知识。实际上，Cisco的QoS课程假设你已经至少学习过ICND和BSCI课程，并且希望你还学习过BGP课程。在Cisco QoS课程设立之初，是希望学生在学习本课程前已经通过了CCNP认证。
QoS一直以来都是很重要的，尤其随着数据、语音和视频融合到单一的网络中，QoS就变得更为重要。与技术融合一样，工作在网络通信领域的专业人士也各自有着不同的背景。本节内容是为那些不具备数据背景的工程师准备的。
注意：
若你想了解更多有关TCP/IP协议的内容，可以阅读Douglas Comer最新出版的Internetworking with TCP/IP一书，本书第1卷非常适合网络工程师阅读。还可以选择Richard Stevens的TCP/IP Illustrated第1卷。
与本章语音和视频的内容类似，本节也将数据流量与4项QoS特征关联起来介绍：带宽、延迟、抖动和丢包。接下来先介绍数据应用流的基础知识，然后介绍与4项QoS特征相关的QoS细节内容。
1．IP数据基础
在语音和视频应用中，首先进行的是信令交互，用来创建语音或视频呼叫。尽管在数据流中不将其称为信令，但也确实会发生类似的步骤——举例来说，当你打开Web浏览器输入www.cisco.com后，在网页的第一部分显示出来之前，会先发生几件事。由于我们的重点在QoS，因此本书专注于实际的负载流——真正的数据——而不是关注与此相关的信令。
大多应用会使用两种TCP/IP传输层协议之中的一种：UDP（用户数据报协议）或TCP（传输控制协议）。编写程序的人会为应用选择其中一个传输层协议来使用。大多数情况下，程序员会选择使用标准协议，也就是使用TCP或UDP。比如Web服务器使用TCP，因此在编写Web应用时，程序员会使用TCP。
TCP可以进行错误恢复，UDP不行。要进行错误恢复，TCP会发送一些初始化消息来创建一个TCP连接，与此同时，也会初始化一些计数器，并以此用来进行错误恢复。图1-31所示案例为连接建立阶段。
TCP会在TCP包头中，以控制字段中的2比特来表示连接建立完成。这2比特的控制字段称为SYN和ACK控制符，这2比特有特殊有趣的含义。SYN表示“同步序列号”，它是初始化TCP连接的必要组成部分。ACK控制符表示“这个包头中的确认字段是有效的”。
当TCP三次握手完成后，TCP连接就建立了，也就可以执行错误恢复了。图1-32描述了在连接建立后，序列号和确认号是如何工作的。
如图所示，服务器发送数据并为其标明序列号。Web客户端向服务器发回的TCP包头中的确认号（4000）表明了下一个将要接收的字节；这被称为转发确认（Forward Acknowledgment）。实质上，浏览器会用序列号1000、2000和3000来确认收到的所有3个包（在本例中，每个数据包都包含1000字节的数据）。序列号表示分段中第一个字节的号码。要记住，若数据包的序列号是3000，字节数是1000，那么字节3000～3999是包含在这个数据包中的——因此浏览器应该期待接下来收到字节4000。
TCP还会使用窗口来控制数据的发送速率。窗口字段指定了连接中所允许的未确认字节的最大数量。图1-32所示案例中当前窗口大小为3000，后来窗口大小增加为4000（请注意在本例中，每个TCP分段携带1000字节的数据）。窗口大小会随着网络性能进行“滑动”，变大或变小，因此有时称之为“滑动窗口（Sliding Window）”。当发送方发送了当前窗口规定的最大字节数之后，它必须等待对方的确认，这个机制对数据流实施了一定的控制。这个机制的效率很高，因为当前可用窗口的大小会随时随着发送的字节数量增加而减小，并且随着收到的确认字节数量增加而增加。
TCP和UDP之间最大的不同之处在于TCP可以执行错误恢复。因此有些人认为TCP是可靠的，UDP是不可靠的。要知道，语音流和视频流使用RTP，同时也使用UDP——为什么语音和视频要使用一个如此不可靠的协议呢？答案很简单：若使用TCP来传输语音或视频数据包，TCP能够意识到数据包的丢失情况，并且在丢包时会进行重传，这种机制会带来过多的延迟，从而重新发送语音或视频数据包是没有任何意义的。然而对于数据应用来说，即使确保所有数据都到达可能会花费更多的时间，也要保证所有的数据都确实到达了连接的另一端，这种情况下，TCP就更为适用了。图1-33给出了TCP错误恢复逻辑的基本概念。
图1-33描述的传输案例中，第二个TCP分段丢失了，或存在错误。Web客户端的回应消息中的ACK字段为2000，表示Web客户端接下来希望收到字节数为2000的数据包。这时Web服务器中的TCP功能就可以恢复丢失的数据，也就是重新发送第二个TCP分段。TCP协议允许Web服务器只发送这第二个分段然后等待，期望从Web客户端收到回应消息，并且确认值为4000。
最后，在去参加QoS考试之前，你还应该理解TCP和UDP的一个特性。这个特性与TCP和UDP头部中的字段相关，这部分字段称为“源和目的端口号（Source and Destination Port Numbers）”。我们可以通过一个简单的案例来理解端口号的作用；对于QoS来说，端口号可以用来区分数据包，也就是说允许路由器或交换机针对不同的数据包应用不同的QoS行为。在接下来的案例中，汉娜正在使用3项应用，服务器杰西为这3项应用提供服务。这个公司编写了一个广告应用程序和一个电汇应用程序，当前都在使用中。此外，汉娜还正在使用一个基于Web的应用程序，如图1-34所示。
接收到数据包后，杰西需要知道将数据包中的数据交给哪项应用，但3个数据包来自同一个以太网和IP地址。你可能认为杰西会查看数据包携带的是UDP还是TCP，以此来进行区分，但从图中可以看出，有两项应用（电汇和Web）都使用TCP。当然了，UDP和TCP的设计者故意在TCP和UDP头部添加端口号字段，就是为了进行复用。“复用”这个术语通常用来表示一种能力：即能够确定应用该从哪个数据包中获取数据。每项应用使用不同的端口号，从而杰西知道如何为不同的应用提供数据，如图1-35所示。
很多众所周知的应用使用众所周知的端口号，比如Web、FTP、TFTP、Telnet、SMTP、POP3等。如果在使用一项应用前，你需要询问其他人，来获得该应用使用的端口号，那也太麻烦了。正因为有了这些众所周知的端口号，我们就可以假设（比如）这个Web服务器使用80端口。对于QoS工具来说，若你想将Web流量分类出来，只需查看使用端口80的数据包即可。
当然了，可能在你的职业生涯中，会不断学习并使用TCP/IP架构中的所有协议。前述的简短介绍仅为你提供了一点背景知识，有助于你继续阅读后续章节。表1-23列出了TCP和UDP的重点内容。
接下来的内容将针对4项QoS特征，更详细地介绍与数据相关的内容：带宽、延迟、抖动和丢包。
2．数据带宽考量
语音需要消耗一定量的带宽，视频需要消耗一个小范围内的带宽，与上述两者均不同，数据对于带宽的需求范围非常大。有些应用可能只需要不到1 kbit/s的带宽，而有些应用可能会消耗掉你能提供的所有带宽。
对于数据带宽来说，最大的问题是围绕OSI第8层——业务层提出来的。比如说应该为Web流量分配多少带宽？要知道，在很多办公场所，Web流量消耗了可用网络带宽的80%。那么更好的问法可能是“应该为重要的业务Web流量分配多少带宽？”对于与财政计划相关的Web应用来说，访问ESPN.com（查看最新比分）这类应用不应该具有很强的竞争力。比如股票经纪商在查看股票报价时会希望获得最低延迟，而我可能只需等待得稍微久一点，才能看到最新的体育比赛比分。
应该为数据应用流考虑的其他合理问题是：这个应用是否为交互式。交互式应用通常（不总是这样！）比非交互式应用需要更少的带宽。最常见的对比来自于Telnet（使用非常少的带宽）和FTP（消耗你提供的所有带宽），这表明了交互式应用消耗较少的带宽。当然了，现在很多交互式应用都是基于Web的，如果Web页面中包含有大量图片，那么它对于带宽的需求也是相当可观的。
数据流的带宽、延迟、抖动和丢包考量会根据这些或那些因素而变化。实际上，同一个数据应用的QoS特征可能会在两个公司之间显示出明显差别！这是因为有太多的因素需要考虑并且这些因素会因网络而异，因此没有一组需求总是适用于所有环境。
但是不要绝望！你应该至少从一个方面来考量带宽需求：商业角度。简单地说，有些应用是关键业务，而有些则不是。因此QoS策略至少应该包括：识别关键应用，并为其赋予所需要的QoS特性。而其他数据流量则不在考虑之列，或者用QoS术语来说，它们就是“尽力转发（Best-Effort）”流量。表1-24总结了3种流量类型在带宽需求上的主要不同。
3．数据延迟考量
与语音和视频不同，数据应用的质量并不会由于突然增加了区区几百毫秒的延迟而降低。事实上，相比于语音和交互式视频，数据应用对于延迟的承受能力是非常强的。还有一点与语音和视频不同，数据应用往往会对往返延迟有要求。
表1-25总结了会对数据应用的延迟产生影响的两个因素。
由于数据对于QoS的需求变化性很大，因此在决定如何为各种应用实施相应的 QoS时，员工之间会进行更多的沟通。沟通增加了，传达错误消息的几率也增加了。比如在询问一个并不关注网络的员工的意见时，他可能会说“对于这个关键任务应用，我们需要稳定的1～3秒响应时间！”他的意思是说为了使用户看到从应用发来的完整响应，双方向上需要发送的所有数据包延迟在1～3秒。当用户要求1～3秒的应用响应时间时，千万别天真地认为他指的是一个数据包的单向延迟是1～3秒。
数据应用与语音和视频流遭遇的延迟类型不同。前文介绍过了一些核心的延迟组成部分——队列延迟、串行化延迟、传播延迟、网络延迟、处理延迟和整形延迟。数据流不会受到编解码延迟、封包化延迟和去抖动缓冲延迟的影响。
4．数据抖动考量
与延迟相似，数据应用忍受抖动的能力也比语音和视频强很多。交互式应用对于抖动的容忍能力很差。我是在IBM一个大型的SNA网络中学习的网络互连技术，当调试路由和QoS（早前内置在SNA中，但这就另当别论了！）时，有一句谚语是这么说的“只要响应时间是同步的，就可以接受很长的响应时间”。出于某种原因，人类本性决定了在人们的交互中，连贯性远远比响应时间更为重要。
交互式数据应用无法像非交互式应用那样忍受那么多的抖动或延迟。而语音和视频应用可以忍受的抖动或延迟甚至比交互式数据应用还要少。正因为语音和视频无法忍受哪怕很小的延迟和抖动，工程师需要使用QoS工具来为语音和视频降低延迟——这样做会反过来增加数据应用的延迟和抖动！举例来说，如果路由器接下来要发送语音包而不是数据包，那么语音包能够获得合理延迟预算的可能性就比数据包大——同时数据包会遭遇更多的延迟。由于知道了数据比语音能够承受更多的延迟和抖动，工程师就可以在这方面做些折中。
数据网络的抖动考量可以总结如下：
抖动总是发生在分组网络中；
数据应用没有去抖动缓冲区，用户总是会经历一定的抖动，他们仅仅会意识到响应时间不一致；
交互式应用对于抖动的容忍度较低，但即使如此，几百毫秒的抖动仍不会影响交互式应用；
在融合网络中，管理员总是通过QoS工具来增强（降低）语音和视频流的抖动，这样做带来的负面影响是增加了数据应用的延迟和抖动。
5．数据丢包考量
与语音和视频不同，数据应用并不总会受到丢包的影响。对于多数应用来说，它需要获得所有数据；若丢失的数据包被重新发了过来，就并不会造成什么实际损失。而另一些应用甚至根本不关心数据包是否丢失。为了透彻地分析，我们将数据应用分为以下 3 类：使用UDP且执行错误恢复的应用、使用UDP且不执行错误恢复的应用和使用TCP的应用。
使用UDP且执行错误恢复的应用
有些应用需要错误恢复特性，但选择通过应用代码来实现错误恢复。比如NFS（网络文件系统）和TFTP（简单文件传输协议）都是用UDP，并且都在应用内部执行错误恢复。NFS允许从远端文件服务器读取并写入数据，保证数据不丢失对于NFS来说极为关键！同样地，TFTP用来传输文件，确保文件的任何部分都不丢失也是极为重要的。因此这些UDP应用会提供应用层错误恢复，来提高对丢包的耐受度。
使用UDP且不执行错误恢复的应用
有些应用就是不需要错误恢复。最常见的这类协议有SNMP（简单网络管理协议），它允许网路管理软件查询被管理设备的信息。网络管理工作站检索的数据量非常庞大，很多时候，偶尔错过一些统计数据也并不会影响管理员使用管理软件。SNMP的设计者特意避免使用TCP和应用层错误恢复机制，就是为了确保SNMP的简单结构，从而使其更具备可扩展性，要知道SNMP会应用在各种场合中。由于这种应用并不关心是否有丢包，因此它对丢包的耐受度很高。
使用TCP的应用
由于基于TCP的应用可以依赖TCP来恢复丢失的数据包，因此能够接受较高的丢包率。尽管对于用户来说丢包并重传的过程是透明的，但由于重传数据包而为网络添加的负载也确实会加重网络拥塞的情况。
6．语音、视频和数据对比：总结
表1-26总结了数据对于QoS的需求，并对比了语音和视频的相关需求。
1该书第2版已由人民邮电出版社引进并出版，中文书名为《VoIP技术构架（第2版·修订版）》。——译者注
2 Cisco Unified Communications Manager曾称为CallManager，本书使用缩写CUCM。——译者注