1.3 QoS：调整带宽、延迟、抖动和丢包
Cisco QoS认证考试指南（第2版）
不同的终端用户流量对网络性能的要求有所不同。比如文件传输应用只关注吞吐量，而对个别数据包的延迟并不关注；交互式应用需要一致的响应时间；语音呼叫需要一致的低延迟；视频会议需要一致的低延迟和高吞吐量。
用户可能会对应用性能和网络性能提出一些合理的抱怨。当然，终端用户总是认为网络要对所有的性能问题负责，无论这是否属实！用户合理的抱怨可能包括如下这些。
我的应用很慢。
我的文件需要传输很长时间。
视频卡住了。
电话延迟太大，我和对方总是同时说话，无法知道对方是否已经停下了。
我总是接不到电话。
在某些情况下，我们可以通过实施QoS特性，从根本上消除这些问题，或者至少降低其带来的影响。
那么，在未实施QoS的网络中，语音、视频和数据流量是如
QoS会尝试解决网络流量的性能问题，尽管它无法解决所有问题。QoS特性可以通过修改以下网络特性来提高网络性能：
带宽；
延迟；
抖动（延迟变化）；
丢包。
不幸的是，提高一个QoS特征，就会相应地降低另一个。比如，带宽定义了传输介质的容量，压缩工具可以减少发送所有数据包所需的带宽，但压缩过程增加了每个数据包的延迟，并且会消耗一定的CPU资源。再比如，抖动是指连续的数据包之间延迟的变化，因此有时也称之为“延迟变化”。路由器能够减少某些流量的抖动，但同时会增加其他流量的延迟和抖动。QoS特性可以解决抖动问题，也就是通过使用队列特性，将需要低抖动的数据包放入优先级队列。丢包有时是由于传输错误导致的，QoS机制无法对此提供任何帮助。但若不是因为传输错误，而是队列排满而导致的丢包，就可以使用QoS特性来决定丢弃哪些数据包。
你可以将QoS看作“管理下的公平”，或者“管理下的不公平”。成功规划QoS最关键的一点在于：你应该为有需要的流量增强某个特性，同时为不需要该特性的流量降低该特性。比如QoS设计应该为延迟敏感的流量降低延迟，同时为延迟不敏感的流量增加延迟。
接下来详细介绍这4种流量特征。
1.3.1 带宽
术语“带宽”（Bandwidth）是指通过某种媒介，正常情况下每秒钟传输的字节数。某些情况下，带宽等于接口的物理链路速率或时钟速率。其他情况下，带宽小于链路的实际速率。考虑图1-2所示案例，这里给出了两个常见网络，一个使用点到点串行链路，另一个使用帧中继链路。
在点到点网络中，WAN带宽等于物理媒介的物理链路速率或时钟速率。举例来说：假设有一条64 kbit/s的链路，那么你就可以发送64 kbit/s流量，并预期它能到达链路另一端。你不能期望它发送更多的流量，因为实际每秒发送的字节数不能超过接口的时钟速率。在这个案例中，带宽是显而易见的，双方向都是64 kbit/s。
帧中继网络根据合约提供了承诺带宽。但事实上很多合约的期望远不止这些！承诺信息速率（CIR，Committed Information Rate）定义了运营商确保通过其网络提供的带宽，也就是数据终端设备（DTE，Data Terminal Equipment）与每个虚电路（VC，Virtual Circuit）之间的带宽。这个保障是商业行为——OSI参考模型的第8层。在某些情况下，你可能无法实际获得CIR带宽。然而帧中继运营商既然承诺运营这样一个网络，它们至少能够在它们总的VC上提供CIR。事实上，每个VC的带宽等于每个VC的CIR。
不幸的是，多路访问网络上的带宽并不是这么简单的。假设R3的访问速率是256 kbit/s，R4的访问速率是T1。那么R3必须以它的访问速率发送流量，否则第1层功能无法正常工作。同样地，R4必须以T1速率发送流量。在帧中继快速发展的几年间，它最大卖点在于你可以“不劳而获”——你为了获得CIR花费了x，但你获得了远高于x价值的带宽。事实上，很多数据网络工程师在设计网络时，都假设每条VC会获得平均1.5～2倍的CIR。若R3和R4以过快的速度发送数据帧，当运营商的交换机队列排满时，交换机就会丢弃帧，R3和R4就得重传这些被丢弃的数据。若你在R3和R4之间购买了128 kbit/s的CIR，但实际发送速率为192 kbit/s或256 kbit/s，而且使用这种速率传输毫无问题，那么你实际拥有了多少带宽？因此在多访问网络中（比如帧中继或ATM），实际带宽一直是有争议的。
在实际环境中，帧中继带宽甚至可能低于CIR。例如：假设R4是主站点，同时还有15个与R3相同（包括R3）的远端站点。那么当R4的访问速率为1.544 Mbit/s时，你是否能够要求R4以128 kbit/s（CIR）的速率向所有15个站点同时发送数据？不能！以128 kbit/s的速率向所有15个站点发送数据，需要1.920 Mbit/s带宽，而R4只能发送和接收1.544 Mbit/s。那么工程师可以把网络设计成这样吗？可以！因为刚才那种情况是假设所有VC同时发送数据，或者帧中继交换机将数据进行排队（从左到右发送数据包）。而当15个远端站点不同时发送数据时，当一个站点需要带宽时，你可以（至少）获得128 kbit/s。这样做带来的负面影响是当队列排满时，大多数数据包会被丢弃；对于数据网络来说，这种做法通常是合理的折衷方案；对于无法忍受丢包的流量（比如语音和视频）来说，这种做法就不是合理的设计。
在本书中，多路访问网络的带宽是讨论重点，其中涉及一些使用更保守估算CIR带宽方法的应用，并对比了更灵活的估算方式，这通常涉及CIR的复用。
1．clock rate命令对比bandwidth命令
当你使用Cisco路由器时，有两条接口命令与带宽相关。命令clock rate定义了第1层实际支持的比特率。在路由器提供时钟的情况下使用这条命令，也就是该路由器通过串口连接了其他设备（比如另一台路由器）。命令bandwidth用于向很多Cisco IOS软件功能告知该接口上的可用带宽。举例来说，EIGRP（增强型内部网关路由协议，Enhanced Interior Gateway Routing Protocol）根据bandwidth命令来确定接口的度量值（Metric），而不是根据clock rate命令来确定。总之，bandwidth命令只会影响接口上其他工具的行为，并影响一些统计结果，但它不会改变接口发送比特的实际速率。
有些QoS工具与接口带宽有关，这个带宽是由bandwidth命令定义的。工程师在启用QoS特性时，要考虑默认带宽。无论实际带宽是多少，Cisco路由器串口的默认带宽设置为T1速率。在使用子接口时，子接口会继承相应物理接口的带宽设置。以图1-2为例，R3的默认带宽设置为1544（单位为kbit/s），而不是更为精确的128、192或256 kbit/s，这取决于工程师能够在该网络中使用的保守或灵活测量结果。
2．优化带宽的QoS工具
很多QoS特性都可以帮助解决带宽问题，本书中多个章节都详细介绍了这些特性。但现在我们要了解一下QoS工具的分类，这会帮助你理解细节内容。
解决带宽问题最好的QoS工具是提供更多的带宽！但是更多的带宽并不能解决所有问题。事实上，在融合网络（承载语音、视频和数据的网络）中，提供更多的带宽可能会掩盖延迟问题，而延迟问题可以通过其他QoS工具或更好的QoS设计得以解决。引用Arno Penzias的话，他曾是贝尔实验室的副总裁和诺贝尔奖获得者：“钱和性，存储和带宽：仅仅‘太多’是永远不够的。”若你能够承担的话，更多的带宽肯定会有助于提高流量质量。
一些关注链路效能的QoS工具，会通过减少传输数据所需的字节数，来提高带宽。图1-3给出了一个相当简单的案例来说明压缩的效果，假设压缩率是2:1。当没有使用压缩时，用64 kbit/s的点到点链路传输80 kbit/s的流量，就会形成队列。队列最终将会排满，这时队列尾部的数据包将会被丢弃——这称为尾丢弃行为。当使用了压缩时，假设达到了2:1的压缩率，那么只需要40 kbit/s就可以传输80 kbit/s的流量，从而有效地将链路的带宽容量提高了一倍。
本书介绍了几种压缩选择，有些压缩发生在队列前（如图1-3所示），而有些发生在队列后。
另一种可以直接对带宽产生影响的QoS工具称为CAC（呼叫准入控制，Call Admission Control）。CAC工具会决定当前网络状况是否能够接受一个新的语音和视频呼叫。这个许可是基于很多因素作出的，这些因素中包括带宽的测量。举例来说，设计中只允许通过一条路径，并发3路G.729 VoIP呼叫；这时可以用CAC来控制新呼叫，即已经建立了3通呼叫时，拒绝新呼叫（若不使用CAC阻止第4通呼叫，将导致链路超负载，那么结果就是所有4通呼叫的质量都会降低！）。使用CAC拒绝呼叫后，系统可根据VoIP拨号计划（Dial Plan）对呼叫进行重路由，比如通过PSTN（公共交换电话网，Public Switched Telephone Network）路径发起呼叫（事实上，CAC工具的相关内容不包含在当前版本的QoS考试内容中：642-642）。
队列工具可以在一定程度上影响特定类型的流量获得的带宽量。队列工具会创建很多条队列，系统会根据队列调度算法将数据包放入不同的队列。队列调度算法中的一个特性会确保一条队列所获得的最小带宽量。以图1-4为例，图中所示为双队列系统。第一条队列获得链路带宽的25%，第二条队列获得带宽的75%。
Cisco IOS软件队列工具预留带宽的行为是这样的：若两个队列中都排列着数据包，算法会根据配置，确保每个队列获得应有的链路带宽量。若只有一个队列中排列着数据包，那么这个队列会暂时获得比配置更高的带宽量。
1.3.2 延迟
网络中的所有数据包——从数据包第一次被发出，到它到达目的地——都会经历或多或少的延迟。QoS机制背后的很多概念都与延迟有某种联系。因此我们需要深入理解延迟的概念。以图1-5为例，本书中常使用这个示例网络。
举例来说，假设图1-5中的汉娜向服务器1发送125字节的数据包。汉娜通过交换机的快速以太网接口（Fast Ethernet）发送数据包。125字节等于1000比特，以快速以太网的速率计算，交换机将数据包串行化到快速以太网链路上需要花费1000 bit/100 000 000 bit/s的时间，即0.1 ms。交换机将数据包发送给R1时，又会产生0.1 ms的串行化延迟（为了方便计算，我忽略了数据链路层头部的长度）。
接着，当这个数据包通过56 kbit/s链路从R1发往R2，串行化延迟为1000比特/56 000 bit/s，即17.85 ms。快速以太网链路上的串行化延迟是微不足道的，但在低速串行链路上，串行化延迟就变得有些可观了。图1-6给出了数据包从汉娜发到服务器1路径上，各处不同的串行化延迟。
2．传播延迟
想象一下你又在看着一列火车，这次你坐在直升机中，从空中俯瞰轨道。你看着火车离开一个车站，接着到达第二个车站。你用码表测量第一节车厢离开第一个车站，到第一节车厢到达第二个车站的时间。当然其他车厢也花费同样的时间到达第二个车站。这个时间延迟与网络中的传播延迟类似。
传播延迟定义了每一个比特从一端到达另一端所花费的时间。当电信号或光信号放到电缆上后，并不是即刻便传播到电缆另一端的，这之间会有一些延迟。尽管电接口和光接口的传播速度接近光速，网络工程师也不能无视物理规则！唯一会影响传播延迟的因素是链路长度。
管理员可以使用下列公式来计算数传播延迟：
正如图1-7所示，链路长度会影响传播延迟，数据包大小和链路速度会影响串行化延迟。较大的数据包会遭受较大的串行化延迟；但在同一链路上，不同大小的数据包会遭受相同的传播延迟。一个常见的误解是，链路速度和时钟速率会影响传播延迟，这是不对的！表1-5列出了图1-6中的部分传播延迟和串行化延迟。
假如从汉娜到SW1的链路为100米，传播延迟就是100/(2.1 × 108)或0.48微秒。如果两个帧中继交换机之间的T3为1000千米，传播延迟就是1,000,000/(2.1 × 108)或4.8毫秒。请注意，链路上的时钟速率不会影响传播延迟，即使对于速率为56 kbit/s，链路长度为1000千米的帧中继接入链路（好长的帧中继接入链路！）也是如此，传播延迟仍为4.8毫秒。
3．队列延迟
数据包遭遇的队列延迟是指数据包等待设备先发送其他数据包的时间。大多数人在想到QoS时，会想到队列延迟；同时大多数人在想到QoS工具时，会想到队列策略和工具；但是队列工具只是QoS工具中的一个类别。队列延迟是指数据包在设备内部，花在排队上的时间——通常只是路由器的输出队列，因为路由器中的输入排队通常是忽略不计的。然而，排队的时间也可以大到上百毫秒，甚至更多。考虑图1-8的情况，其中R1里排列了4个1500字节的数据包，这些数据包是从汉娜发送到服务器1的。
一个数据包所经历的总延迟是（从端到端）所有这些延迟的总和。当R1接收到这4个数据包后，第4个数据包在被R2完整接收之前，会经历约860毫秒的延迟。这个例子只给出了单一路由器（R1）上的队列延迟，以及单一链路上的串行化延迟和传播延迟，端到端延迟包括网络中每台路由器的（队列）延迟和链路（串行化和传播）延迟。
4．转发延迟
转发延迟（Forwarding Delay）是指从路由器完全接收到一个数据包，到将它放入输出队列之间的处理时间。因此转发延迟并不包含数据包在队列中等待离开路由器的时间，它所包含的时间是路由器路由或转发数据包所必需的时间。
不同型号路由器的内部处理能力各不相同，Cisco通常不会给出转发延迟的统计数据。但一台路由器能够转发的数据包越多，以及使用特殊处理方式能够转发的数据包越多，转发延迟就会相应越低。
LAN交换机中的大多数延迟都小到可以忽略不计。但是很多时候，就像路由器一样，交换机也会带来延迟。有些LAN交换机使用一种称为“储存并转发”的转发逻辑，即必须在收到完整的数据帧之后，才转发该数据帧。而有些交换机则使用直通转发（Cut-Trough）或无碎片转发（Fragment-Free），即在转发数据帧的第一个字节时，交换机并未收到完整的所有字节。从技术上来看，如果你将转发延迟定义为：收到完整数据帧的时间与数据帧被放入输出队列的时间之间的时间差，那么有些局域网交换机的转发延迟实际上可能是负数！这只是取决于你想定义整体延迟中的哪一部分。在整体延迟预算的计算中，转发延迟通常是小到可以忽略不计的部分，因此本书不再强迫你继续讨论相关细节了！
如需了解更多的内部转发方式，比如Cisco快速转发（CEF，Cisco Express Forwarding），你可以回顾Cisco Press出版的书籍Inside Cisco IOS Software Architecture。
5．整形延迟
流量整形会带来额外的延迟，因为比起未使用流量整形的情况，使用流量整形会使服务队列的速度下降。如非必需，路由器何苦降低发送数据包的速率？因此，流量整形用来帮助调整流量的整体转发速率，因为当实际速率超出承诺速率时，设备可能会丢弃数据包。因此下列哪种情况看起来好一些？
飞快地发送数据包，同时丢弃数据包；
相对较慢地发送数据包，也不丢弃数据包。
正确的回答是——看情况！当然了，若你想发送得慢一些，并且希望设备不要丢弃数据包，那么流量整形是适合你的解决方案。
运营商会因为各种理由丢弃自己网络内部的数据帧和数据包。其中一个最常见的理由是大多数中心站点路由器使用快速访问链路，而远端站点使用的链路相对慢很多。如果中心站点使用T1链路，而远端站点使用56 kbit/s链路，那么数据帧就会塞满服务提供商网络中的队列，等待着穿越56 kbit/s的访问连路。还有很多其他情况会导致运营商丢弃数据包；第6章将更完整地介绍这些情况。
为了理解单一路由器中，与整形相关的基本概念，请看图1-10，R2拥有128 kbit/s访问速率，它连接R3的VC（虚电路）上的CIR（承诺信息速率）是64 kbit/s。
我们能够极其接近地猜测出传播延迟和串行化延迟。无论R2和R3之间有多少台交换机，在其间所有链路上积累的传播延迟与点到点链路上的传播延迟相同。对大多数大型运营商来说，由于它们拥有很多接入点（PoP），帧中继VC很有可能使用与点到点链路相同的物理路径来路由数据包。至于串行化延迟，用两条最慢的链路计算，到目前为止，这将是两条访问连路（在大多数案例中）。因此，下列两部分包含了云中的大部分串行化延迟：
在云中发送数据包的串行化延迟；
出站帧中继交换机（将数据包发往R3）上的串行化延迟。
举例来说，假设R2与R3之间距离1000千米，被发送的数据包大小为1500字节。网络延迟将至少为：传播延迟加上两条访问链路上的串行化延迟：
传播延迟 = 1000千米/2.1 × 108 = 4.8毫秒
串行化延迟（入站R2）= 1500字节 × 8 / 128,000 比特/秒 = 94毫秒
串行化延迟（出站R3） = 1500字节 × 8 / 1,544,000 = 7.8毫秒
延迟共计106.6毫秒
当然了，实际中的延迟是可变的，它与运营商、网络链路的状态和整体网络拥塞息息相关。在一些案例中，运营商会在SLA（服务等级协议）中添加对延迟的限制。
云内部的队列延迟为网络延迟带来了最大的不确定性，就像它在云外部做的一样。这类延迟的大小取决于流量，无法预测。
7．延迟总结
本章前文介绍的所有延迟类型，除整形延迟之外，存在于所有网络中。整形延迟只有当管理员启用了整形后才会发生。
在常见网络中，可能有也可能没有以下两种延迟。第一种：语音和视频流量会遭受编解码延迟。本章后续小节“语音延迟考量”中将详细介绍编解码延迟。此外，压缩需要设备进行处理，花在压缩数据包或解压缩数据包上的时间也是一种延迟。第8章将详细介绍压缩延迟。
表1-6总结了本部分介绍的延迟类型。
8．优化延迟的QoS工具
有很多QoS特性都可以帮助解决延迟问题。你可以在本书不同章节中获得这些工具的详细介绍。现在我们先来了解一下每类QoS工具负责完成什么工作，这有助于你有的放矢地阅读详细介绍。
再说一次，解决延迟问题最好的QoS工具是……更多的带宽！更多的带宽有助于解决与带宽相关的问题，同时也有助于解决与延迟相关的问题。首先，更快的带宽速率能够降低串行化延迟。其次，由于数据包出站速度变快了，因此队列延迟降低了。最后，VC上更高的CIR会降低整形延迟。总而言之，更快的带宽速率会降低延迟！
但很不幸，即使你能够负担更多的带宽，它也并不能解决所有延迟问题。事实上，在融合网络（同时承载语音、视频和数据的网络）中增加更多带宽可能会掩盖延迟问题，而其他QoS工具或更好的QoS设计可以很好地解决这些延迟问题。下面介绍的QoS工具能够影响某个特定类型数据包的延迟。
队列（队列调度）
队列是最流行的QoS工具，它会根据到达时间及其他因素，来选择性地发送数据包。换言之，不像FIFO队列机制那样使用一条队列，其他队列机制会创建多个队列，将数据包放入不同的队列中，再从这些不同队列中挑选数据包进行发送。这样做带来的结果是，一些数据包能够更快速地离开路由器，而另一些数据包则需要等待更长的时间。尽管队列机制无法降低所有数据包的延迟，但它可以为那些对延迟敏感的数据包降低延迟，并将那些对延迟不敏感的数据包的延迟相应提高。而且，在路由器上启用队列机制无需花费任何金钱，但增加带宽需要花钱。
每种队列机制都定义了不同的队列数量，并通过不同的方法来调度队列。换句话说，就是使用不同的规则，来确定接下来将发送哪个队列中的数据包。图1-12中所示的队列机制定义了两个队列。假设汉娜发送了4个数据包，第4个数据包来自于她运行的一个视频会议程序，而其他3个包则来自于一个Web应用程序，以便她调剂无聊的视频会议。
注意数据包1被分为3片。由于数据包2到达时，路由器已经开始发送数据包1了，因此数据包2需要等待。通过使用LFI，数据包2无需等待路由器发送完整的数据包1，而只需等待路由器发送分片1。
压缩
压缩作用于数据包或包头，通过压缩数据包或包头中的数据，减少比特数。因而可以将1500字节的数据包压缩为750字节，这样相对于1500字节的数据包来说，压缩后的串行化时间也缩短了一半。
压缩减少了串行化延迟，因为数据包的比特数变少了。但压缩和解压缩数据包所花费的处理时间，也可能增加数据包的延迟。第8章详细对比了每种压缩类型的优缺点。
流量整形
流量整形实际上是用来增加延迟的，以便减少数据包的丢包率。之所以在这里提到整形，是因为它对延迟会带来不良影响。
尽管添加更多的带宽总能减少延迟，但表1-7中总结的工具也能够影响网络中的延迟。
1.3.3 抖动
连续的几个数据包经历不同的延迟，这就是抖动。在数据包网络中，延迟的组成多种多样，因此抖动总是存在的，但问题是抖动是否会严重到降低该应用的服务质量。通常来说，数据应用都会预计遇到一些抖动，同时并不会降低服务质量。但某些流量（比如数字化语音）需要以一种连贯统一的方式传输数据包，比如每20毫秒发送一个。并且数据包也应该以相同的频率抵达目的地（这类流量被称为等时流量[isochronous traffic]）。
抖动是指当设备以一种统一的方式传输数据包时，数据包抵达目的地的时间间隔出现变化，即网络中存在不同的延迟。举例来说，如图1-14所示，这3个数据包来自于电话分机301和201之间的语音呼叫。
电话每20毫秒发送一个数据包。本例中第一个数据包抵达目的地20毫秒后，第二个数据包抵达，因此这里没有抖动。但第三个数据包是在第二个数据包抵达后30毫秒抵达的，因此这里有10毫秒的抖动。
发生抖动时，语音和视频的质量会大大降低。尽管严重的抖动会影响交互式应用，但数据应用往往能忍受更多的抖动。
优化抖动的QoS工具
有很多QoS特性都可以帮助解决抖动问题。你可以在本书不同章节获得这些工具的详细介绍。现在我们先来了解一下每类QoS工具负责完成什么工作，这有助于你有的放矢地阅读详细介绍。
再说一次，解决抖动问题最好的QoS工具是……更多的带宽！更多的带宽有助于解决与带宽相关的问题，同时也有助于解决与延迟相关的问题。若更多带宽可以降低延迟，那么由于抖动是变化的延迟，因此抖动也会减少。更快的带宽会降低串行化延迟，也就降低了抖动。举例来说，若延迟平均为100～200毫秒，那么抖动通常大于100毫秒。若通过添加更多带宽，使延迟降低到50～100毫秒，那么抖动也会降低到50毫秒。由于数据包可以更快速地被发送出去，因此队列延迟降低了。若之前的队列延迟平均为50～100毫秒，而现在是10～20毫秒，那么抖动也会降低。总而言之，快速发送有益于解决带宽、延迟和抖动问题！
但很不幸，即使你能够负担更多的带宽，它也并不能解决所有抖动问题。很多QoS工具有助于解决抖动问题，即相对于其他数据包，降低某个特定类型数据包的抖动。
能够影响延迟的工具同样可以影响抖动，表1-8简述了这些QoS工具。
1.3.4 丢包
我们要介绍的最后一个QoS流量特征是数据包丢失，或简称为丢包。路由器会由于很多原因丢失（Loss）/丢下（Drop）/丢弃（Discard）数据包，大多数QoS工具对此无能为力。举例来说，入站帧校验序列（FCS）失败的数据帧会被丢弃——周期性。但QoS工具可以最小化因队列排满导致的丢包。
在当今大多数网络中，由于比特错误而导致的丢包非常少，通常少于十亿分之一（10-9或更少的比特错误率[BER]）。因此丢包最关心的是由于缓存和队列排满而导致的丢包。请参考图1-15，汉娜发送50个连续的1500字节数据包，R1的队列长度为40。
术语“尾部丢弃（Tail Drop）”是指在路由器想要把数据包放到队列尾部的时候，丢弃数据包。如图1-15所示，当队列中的40个位置都排满后，这50个数据包中其余的数据包将被丢弃。在现实网络中，在路由器接收到完整的50个数据包之前，可能会发送出少数几个数据包，因此可能并不是10个数据包全都被丢弃，但也肯定会丢弃大量数据包。
有些流量会比其他流量更能忍受丢包。举例来说，人耳可以检测到只有10毫秒的语音丢失，但这么小的丢失不影响听者大致理解说话内容。Cisco数字信号处理器（DSP）可以预测语音数据包中丢失的内容，在使用G.729编码时，可预测30毫秒。默认情况下，每个语音数据包中包含20毫秒的语音；因此若两个连续的语音数据包丢失了，DSP是无法重新创建语音的，这时听者才会意识到空白中断。相反地，Web流量可以很好地忍受丢包，因为可以使用TCP重传数据。
优化丢包的QoS工具
只有几个QoS特性有助于解决丢包问题。你可以在本书不同章节获得这些工具的详细介绍。现在我们先来了解一下每类QoS工具负责完成什么工作，这有助于你有的放矢地阅读详细介绍。
现在，你应该会猜测带宽有助于预防丢包。更多的带宽有助于——它并不能解决所有问题。而且坦白说，如果你为融合网络（语音/视频/数据）增加了带宽，你还是会遇到质量问题。
更多的带宽如何能够减少丢包？更多的带宽会加快数据包的传输速度，这也就减少了队列长度，这样就不太可能会填满队列。只要队列不填满，就不会发生尾部丢弃。
你可以使用一类工具来减少丢包带来的影响，这类工具称为随机早期检测（RED，Random Early Detection）。
随机早期检测（RED）
TCP使用一种窗口机制，来限定TCP在未收到确认前，能够发送的数据量。不同TCP连接的TCP窗口会根据多种因素滑动，或开放或紧缩。RED假设若TCP连接可以在其输出队列被填满之前缩小TCP窗口，使发送到网络中的数据包变少，这样队列就不会被填满了。在队列不会被填满的情况下，RED不会打扰TCP，不会令其降低发送速度，因为没有必要这样做。
RED只是在队列填满并开始尾部丢弃之前，丢弃数据包。你几乎可以把RED当做是管理队列尾部的工具，而队列工具则是管理队列前部的工具！由于很多流量是基于TCP的，TCP会在发现前一个数据包丢失后，降低数据包的发送速度，RED则会在队列被填满之前，降低进入网络的数据包负载。需要进行相当详细的解释，才能使你理解RED的作用是什么，以及它是如何工作的。但想要有一个大致的了解还是很简单的，只要你理解TCP会在数据包丢失后，通过缩小窗口大小，来降低数据包的发送速度即可。
TCP使用窗口机制，窗口大小限定了在未收到确认前，TCP能够发送的数据量。窗口的大小基于多种因素而动态变化，其中包括丢失数据包。当数据包丢失后，根据其他的条件，TCP窗口会缩小到之前大小的50%。在一般网络中，大多数数据都是通过TCP发送的，当某条链路上发生了大量尾部丢弃行为时，几乎所有通过该链路发送数据的TCP连接，其TCP窗口都会缩小50%，这种缩小行为至少会发生一次。
考虑图1-15所示案例。如图所示，前一跳设备发送了50个数据包，导致路由器的队列排满，其中10个数据包被丢弃。假设这50个数据包分别来自于10个不同的TCP连接，在这次大型尾部丢弃行为中，所有10条连接都发生了丢包，那么前一跳设备再发送时，只能发送25个数据包（窗口缩小了一半）。
在使用了RED的情况下，在尾部丢弃发生前，RED就会丢弃一些数据包，这就使只有少部分TCP连接降速。通过缩小少数TCP窗口大小，可以避免发生尾部丢弃，从而让大多数用户获得更好的响应时间。若很少发生尾部丢弃的话，TCP的发送速率是稳定的。对于那些由于RED而丢弃数据包的TCP连接来说，相应缓慢只是暂时的，而这比所有用户都遭遇慢响应时间要好多了！
队列可以完成一系列任务，其中包括降低丢包率。丢包发生在队列排满的情况下，而队列机制通常能够由管理员来配置最大队列长度，因此只需把队列配置的足够长就可以了。使用更长的队列最大值，可能出现的丢包率就会降低。但相对的，队列延迟就会增加。来看图1-16所示的案例。
顶部案例中使用了单一的FIFO队列。排在49个数据包之后等待发送，这对于延迟敏感的流量来说，很可能无法正常工作。而对于丢包敏感而延迟不敏感的应用来说，更长的队列可能更为合适。这时管理员的目标可以是将延迟敏感的流量与丢包敏感的流量分别放入不同的队列，并为丢包敏感的流量配置一个超长的队列长度，正如底部案例所示。在这个案例中，与往常一样，管理员也在低丢包和低延迟之间做了折衷。
1.3.5 小结：QoS特征：带宽、延迟、抖动和丢包
本书涵盖了各种各样的QoS工具，每种工具都会直接或间接地对带宽、延迟、抖动或丢包产生影响。有些工具会增强某种数据包的某种QoS特征，但却降低其他数据包的这种QoS特征。比如队列工具可以优先发送某种数据包，降低其延迟，但这会相应地增加其他数据包的延迟。有些QoS工具会直接影响某种QoS特性，同时间接影响另一种QoS特性。比如RED负责直接管理丢包，同时间接降低了某些流量的延迟，因为RED通常会导致队列长度缩小。
正如本书详细介绍了每种特性一样，你也可以了解到这些特性是如何管理带宽、延迟、抖动和丢包的。