计算机网络第五版之QoS-中文翻译.docVIP

5.4 QoS 前一节所看到的技术是减少拥堵和提高网络性能。然而，应用程序想要从网络得到更强的性能保证，而不是“尽最大努力”。特别是多媒体程序，经常有最小吞吐量和最大延迟的要求。这一节，我们将继续研究网络性能，但是现在要重点关注提供满足应用程序需求的服务质量的方法。 为了提供好的服务质量，一个简单的解决方案是建造一个足以容纳任何流量的具有足够容量的网络。这个解决方案叫做overprovisioning。根据这个方案建造的网络将不会有明显的丢包，而且低延迟（假设有一个恰当的路由选择方案）。这样的网络的性能是最好的。某种程度上，电话系统是overprovisioning的，因为一般情况下，拿起听筒立刻就能听到拨号音。这是因为，电话系统有足够多的可用容量，总是能满足需求。 这个方案的问题在于，太过昂贵。基本上就是砸钱来解决问题。QoS机制使用较少的容量同时较低的成本来让网络满足应用程序的需求。此外，overprovisioning基于预期的流量。如果流量模式有较大的改变，所有投资就白费了。使用QoS机制，网络能坚持做出的性能保证，即使流量模式有较大的变化，代价是拒绝一些请求。 为了确保服务质量，有四个问题必须解决： 1、应用程序对网络有什么需求。 2、如何调整进入网络的流量。 3、为了保证性能，如何在路由器上预留资源。 4、网络能否稳妥地接受更多的流量。 没有单项技术能有效应对所有这些问题。相反，发展了多种技术用在网络（传输）层。实际使用的服务质量解决方案捆绑了多种技术。为此，我们将描述用于互联网的两个版本的服务质量， 称作Intergrated Services和Differentiated Services。 5.4.1 应用程序需求 从源到目的的一连串数据分组，称作流（flow）。一条流，在面向连接的网络中是一个连接上的所有数据分组，在无连接网络中是从一个进程发往另一个进程的所有数据分组。每条流的需求能用下面四个主要参数来描述：带宽、延迟、抖动和丢失率。这些一起决定了流的服务质量需求。 几个常用的应用和他们的网络需求的强度。对网络的要求比对应用程序的要求低，应用程序能改善网络提供的服务。特别是，对于可靠的文件传输，网络不需要做到没有丢失，对于银视频的播放，网络不需要统一分组的延迟，一定量的抖动能够通过在接收端缓存来平滑。然而，如果网络带宽太小或者延迟太大，没有应用程序能够补救这种状况。 Application Bandwidth Delay Jitter Loss Email Low Low Low Medium File sharing High Low Low Medium Web access Medium Medium Low Medium Remote login Low Medium Medium Medium Audio on demand Low Low High Low Video on demand High Low High Low Telephony Low High High Low Videoconferencing High High High Low 图5-27 应用程序的服务质量需求强度 应用程序对带宽的需求有所不同，email、各种形式的Audio和Remote login不需要很多带宽，但是File Sharing和各种形式的Video需要大量带宽。 更有意思的是对延迟的需求。文件传输应用程序，包括email和video对延迟不敏感。如果所有分组都统一延迟了几秒，没有害处。交互式应用程序，例如网上冲浪和Remote login对延迟更敏感。实时应用程序，例如Telephony和Video Conferencing对延迟有严格的要求。如果打电话时说的话延迟太长，这是令人无法接受的。另一方面，从一台服务器播放音频和视频不要求很低的延迟。 延迟或分组到达时间的变动（例如，标准偏差）称作抖动（jitter）。图5-27中前三个应用程序对分组到达的时间间隔的规律性不敏感。Remote login对抖动稍微有些敏感，如果连接存在抖动，屏幕上的更新会以突发的方式显示。Video和Audio对抖动非常敏感。如果某人正在通过网络观看视频，视频的帧全部恰好延迟2秒，一切平安无事。但是如果传输时间 在1秒到2秒内随机变动，结果将是很糟糕的，除非应用程序隐藏了抖动。对于音频，甚至是一个几微秒的抖动能够被清楚地听出来。 前四个应用程序对丢包比音视频有更强的要求，因为所有的位必须正确传递。传输层重传网络层丢失的数据分组来实现正确传递的目标。这是很费带宽的做法。如果网络层在第一时间拒绝看起来会丢失的分组，这样做也许会更好，音视频应用程序能够容许一些丢失分组而不进行重传，因为人们不会注意短的暂停或