搜索
5.4QoS前一节所看到的技术是减少拥堵和提高网络性能。然而，应用程序想要从网络得到更强的性能保证，而不是“尽最大努力”。特别是多媒体程序，经常有最小吞吐量和最大延迟的要求。这一节，我们将继续研究网络性能，但是现在要重点关注提供满足应用程序需求的服务质量的方法。为了提供好的服务质量，一个简单的解决方案是建造一个足以容纳任何流量的具有足够容量的网络。这个解决方案叫做overprovisioning。根据这个方案建造的网络将不会有明显的丢包，而且低延迟（假设有一个恰当的路由选择方案）。这样的网络的性能是最好的。某种程度上，电话系统是overprovisioning的，因为一般情况下，拿起听筒立刻就能听到拨号音。这是因为，电话系统有足够多的可用容量，总是能满足需求。这个方案的问题在于，太过昂贵。基本上就是砸钱来解决问题。QoS机制使用较少的容量同时较低的成本来让网络满足应用程序的需求。此外，overprovisioning基于预期的流量。如果流量模式有较大的改变，所有投资就白费了。使用QoS机制，网络能坚持做出的性能保证，即使流量模式有较大的变化，代价是拒绝一些请求。为了确保服务质量，有四个问题必须解决：1、应用程序对网络有什么需求。2、如何调整进入网络的流量。3、为了保证性能，如何在路由器上预留资源。4、网络能否稳妥地接受更多的流量。没有单项技术能有效应对所有这些问题。相反，发展了多种技术用在网络（传输）层。实际使用的服务质量解决方案捆绑了多种技术。为此，我们将描述用于互联网的两个版本的服务质量，称作IntergratedServices和DifferentiatedServices。5.4.1应用程序需求从源到目的的一连串数据分组，称作流（flow）。一条流，在面向连接的网络中是一个连接上的所有数据分组，在无连接网络中是从一个进程发往另一个进程的所有数据分组。每条流的需求能用下面四个主要参数来描述：带宽、延迟、抖动和丢失率。这些一起决定了流的服务质量需求。几个常用的应用和他们的网络需求的强度。对网络的要求比对应用程序的要求低，应用程序能改善网络提供的服务。特别是，对于可靠的文件传输，网络不需要做到没有丢失，对于银视频的播放，网络不需要统一分组的延迟，一定量的抖动能够通过在接收端缓存来平滑。然而，如果网络带宽太小或者延迟太大，没有应用程序能够补救这种状况。ApplicationBandwidthDelayJitterLossEmailLowLowLowMediumFilesharingHighLowLowMediumWebaccessMediumMediumLowMediumRemoteloginLowMediumMediumMediumAudioondemandLowLowHighLowVideoondemandHighLowHighLowTelephonyLowHighHighLowVideoconferencingHighHighHighLow图5-27应用程序的服务质量需求强度应用程序对带宽的需求有所不同，email、各种形式的Audio和Remotelogin不需要很多带宽，但是FileSharing和各种形式的Video需要大量带宽。更有意思的是对延迟的需求。文件传输应用程序，包括email和video对延迟不敏感。如果所有分组都统一延迟了几秒，没有害处。交互式应用程序，例如网上冲浪和Remotelogin对延迟更敏感。实时应用程序，例如Telephony和VideoConferencing对延迟有严格的要求。如果打电话时说的话延迟太长，这是令人无法接受的。另一方面，从一台服务器播放音频和视频不要求很低的延迟。延迟或分组到达时间的变动（例如，标准偏差）称作抖动（jitter）。图5-27中前三个应用程序对分组到达的时间间隔的规律性不敏感。Remotelogin对抖动稍微有些敏感，如果连接存在抖动，屏幕上的更新会以突发的方式显示。Video和Audio对抖动非常敏感。如果某人正在通过网络观看视频，视频的帧全部恰好延迟2秒，一切平安无事。但是如果传输时间在1秒到2秒内随机变动，结果将是很糟糕的，除非应用程序隐藏了抖动。对于音频，甚至是一个几微秒的抖动能够被清楚地听出来。前四个应用程序对丢包比音视频有更强的要求，因为所有的位必须正确传递。传输层重传网络层丢失的数据分组来实现正确传递的目标。这是很费带宽的做法。如果网络层在第一时间拒绝看起来会丢失的分组，这样做也许会更好，音视频应用程序能够容许一些丢失分组而不进行重传，因为人们不会注意短的暂停或者偶尔的跳帧。为了容纳多种应用程序，网络可以支持不同的QoS类别。ATM网络是一个颇具影响的例子。它们支持：1、恒定比特率（例如：电话）2、实时可变比特率（例如：压缩的视频会议）3、非实时可变比特率（例如：看一部点播的视频）4、可用比特率（例如：文件传输）这些类别也能用于其它的目的和其他的网络。恒定比特率试图模仿一根提供统一带宽和统一延迟的电线。可变比特率发生在视频被压缩时，一些帧压缩的比其它帧利害。如果一个帧有很多细节可能要求发送很多比特，而如果是一堵白墙，可以很好的进行压缩。点播的视频实际上不是实时的，接收端在播放开始前能很容易的缓存几秒钟的视频。可用比特率用于像email那样对延时和抖动不敏感的应用，只要能得到带宽无论什么样的它们都能使用。5.4.2流量整形（Trafficshaping）在网络做出QoS保证之前，必须要知道保证的是什么样的流量。在电话网络，流量描述是简单的。例如，一个语音电话呼叫（非压缩格式）需要64kbps，每125微秒一个样本。然而数据网络流量是突发（bursty）的。流量速率变化（例如，压缩的视频会议）、用户与应用程序交互（例如：新开一个web页面）和计算机在任务间切换，这些时候通常分组都会以不一致的速率到达。突发的流量比恒定速率的流量更难处理，因为它们能填满缓存，导致分组丢失。流量整形是一种技术，它能调整进入网络的数据流的平均速率和突发。它的目标是允许应用程序传输适合它们需求的变化范围宽泛的流量，包含一些突发，然而有一个简单又用的方法来向网络描述可能会发生的流量模式。当一个流被建立，用户和网络（例如，客户和网络提供商）为这个流商定一个流量模式。实际上，客户对网络提供商说：“我的传输模式看起来会像这样；你能处理吗？”有时这种协定被称作SLA（ServiceLevelAgreement），特别是基于很长一段时间的聚合流，例如某个给定客户的所有流量。只要客户履行他那部分协定并且只要基于商定的合同发送分组，网络提供商保证及时传递所有这些分组。流量整形减少了拥堵，帮助网络履行它的承诺。然而，要实现这些，还存在着如下问题：网络提供商如何知道客户是否遵守协定，如果客户不遵守协定该怎么办。超出商定模式的分组可以被网络丢掉，或者标上低优先级标记。对通信流量的监控被称作流量监管（trafficpolicing）整形和监管对点对点和其他会消耗所有可用带宽的传输来说不那么重要，但是对实时数据，例如音视频等有严格的服务质量要求的连接来说非常重要。漏桶和令牌桶LeakyandTokenBuckets使用漏桶和令牌桶来特征化流量。图5-28（b）是一个底下有个小洞的桶。不管水进入该桶的速度是多少，只要桶里有水，从小洞里流出的水是恒定速率R，当桶空了，速度就变为了零。同样，当桶里的水达到的桶的容量B，任何再加入的水都从边上溢出了，被丢失。这个桶能被用来整形和监管进入网络的分组，如图5-28（a）所示。从理论上说，每台主机通过一个含有漏桶的接口连接到网络。要发送分组进入网络，必须把尽可能多的水放进桶里。当桶满的时候，如果一个分组到达了，这个分组必须排队，直到流出足够的水，使得桶能容纳它，或者被取消。前者可能发生在主机，调整它发往网络的流量，这个功能作为操作系统的一部分。后者可能发生在网络提供商网络接口的硬件上，监管进入网络的流量。这项技术被称作漏桶算法（leakybucketalgorithm）。一个不同但是等价的构想是：把网络接口想像成一个将被填满的桶，如图图5-285-28（c）所示。水龙头的流速是R，桶的容量是B。发送一个分组必须能够取水（或令牌）出桶（而不是把水放进桶）。桶内最多能放的令牌数量是B，如果桶空了，要发送分组，必须等待，直到更多的令牌到达。这个算法被称作令牌桶算法（tokenbucketalgorithm）。漏桶和令牌桶限制了流的长期的速率，但是允许短期的调节至最大长度的突发通过，不会被改动，不会有任何的人为延迟。较大的突发将被一个漏桶流量整形器平滑，以减少网络上的拥塞。例如，假设一台计算机能够产生高达1000Mbps的数据（每秒125兆字节），而网络的第一条链路也能以这样的速度运行。这台主机产生的流量模式如图5-29（a）所示。这个模式是突发的。即使主机以最高速率1000Mbps发送一个16000KB的突发（持续1/8秒），一秒钟之后的平均速率是200Mbps。现在假设路由器仅能在一小段时间内用最高速接收数据，直到缓存被填满。缓存尺寸为9600KB，比流量突发小。长时间的话，该路由器最佳速率不超过200Mbps（比方说，这是给与该客户的所有带宽）。言下之意，如果流量以这个模式发送，部分流量会在网络里被丢弃，因为无法全部放入路由器的缓存内。为了避免分组丢失，可以在主机处使用令牌桶调整流量。如果使用速率R为200Mbps，容量B为9600KB，这个流量就处于网络能处理的范围之内。令牌桶的输出如图5-29（b）所示。主机能够以1000Mbps全速发送一小段时间，直到图5-29耗尽桶里的令牌。然后削减到200Mbps，直到突发被发送完毕。这个效果就是延长突发的时间，因为这个突发太大不能一下子处理完。令牌桶的水位如图5-29（e）所示。开始的时候桶是满的，突发开始之后就被耗尽。当桶空了，新到的分组只能按照缓存填充的速度发送；桶的水位恢复了，才能有突发。当没有流量的时候，桶的水位升高，当流量按照桶填充的速度发送的时候，桶的水位不变。我们还能把流量整形成更少的突发。图5-29（c）中令牌桶的输出速率R=200Mbps，容量为0。这是一个极端的例子，流量被完全抹平了。突发不被允许，进入网络的流量速率稳定。图5-29（f）显示的对应的桶的水平一直为空。要进入网络，流量需要在主机排队，总是有一个分组等着被发送。最后，图5-29（d）显示了一个令牌桶的水位，该令牌桶的流速R=200Mbps，容量B=16000KB。前面假设的主机所发送的突发流量不经修改恰好能通过这个令牌桶。这个桶可能用于网络中的一台路由器，该路由器用来监控主机发送的流量。如果主机发送的流量符合与网络协商好的令牌桶，那么这个流量就能通过网络边界路由器上的令牌桶。如果主机发送的流量速度太快或者突发太强，令牌桶就会耗尽令牌。如果发生这种情况，流量监管器就会知道这个流量违反了协定。然后就会丢掉过量的分组或者降低优先级，至于采用何种方法根据网络的设计。例子中，在第一个突发之后，桶立刻空了，然后恢复到足够满，等待下一个突发。漏桶和令牌桶很容易实现。现在描述令牌桶的操作。例子中所描述的是水流持续的流进流出桶，而真正的实现必须使用离散量。使用一个计数器来描述桶的水位。每ΔT秒计数器增加R/ΔT单位。在上面这个例子中每1毫秒200K比特。每次一单位的流量被发送到网络，计数器就递减，流量不停的发送，直到计数器为0。当分组都是同样尺寸的时候，桶的水位只要用分子来计算（例如，200K比特是20个1250字节的分组）。然后，经常使用的是可变尺寸分组。这种情况下，桶的水位用字节来计数。如果桶里剩下的字节计数太少，不够发送一个大的分组，该分组必须等到桶里的令牌攒的足够多（如果令牌填充率比较慢，需要等的久一点）。计算最大突发长度（直到桶空）需要点小技巧。最大突发长度比9600KB除以125MBps要长一点，因为当突发在输出的时候，令牌也在不停到达。假设突发长度为S秒，最大输出速率为M字节/秒，令牌桶的容量为B字节，令牌到达的速率为R字节