计算机网络第五版之QoS中文翻译Word文档下载推荐.docx
《计算机网络第五版之QoS中文翻译Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《计算机网络第五版之QoS中文翻译Word文档下载推荐.docx（17页珍藏版）》请在冰豆网上搜索。
这些一起决定了流的服务质量需求。
几个常用的应用和他们的网络需求的强度。
对网络的要求比对应用程序的要求低，应用程序能改善网络提供的服务。
特别是，对于可靠的文件传输，网络不需要做到没有丢失，对于银视频的播放，网络不需要统一分组的延迟，一定量的抖动能够通过在接收端缓存来平滑。
然而，如果网络带宽太小或者延迟太大，没有应用程序能够补救这种状况。
Application
Bandwidth
Delay
Jitter
Loss
Email
Low
Medium
Filesharing
High
Webaccess
Remotelogin
Audioondemand
Videoondemand
Telephony
Videoconferencing
图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-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全速发送一小段时间，直到耗尽桶里的令牌。
然后削减到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字节/秒，一个输出突发最多能容纳B+RS字节。
同时，一个长度为S秒的高速突发的字节数为MS。
因此，
，
。
令牌桶算法把大的突发拉低到长期速率R。
经常有这样的需求：
把峰值速率拉下来，但是不要低至长期速率（也不需要提升长期速率以让更多的流量进入网络）。
平滑流量的办法之一是在第一个令牌桶后面再插入第二个令牌桶。
第二个桶的速率要比第一个大。
第一个桶塑造流量，固化它的平均速率，但是允许一些突发。
第二个桶拉低突发的峰值速率。
例如，如果第二个桶的速率被设置成500Mbps，容量为0，初始突发将以峰值速率500Mbps进入网络，比前面的1000Mbps要低。
使用所有这些桶，需要点小技巧。
当令牌桶被用于在主机处进行流量整形，分组会被迫排队和等待，直到桶允许他们被发送。
当令牌桶被用于网络中的路由器上进行流量监管，算法被用于确保发送的数据包数量不会比允许的更多。
这些工具提供方法来网络流量整形成更可管理的形态，以便于满足服务质量需求。
5.4.3分组调度
能够调整被交付的流量的形状是一个好的开端。
然而要提供性能保证，还必须沿着分组穿越网络的线路预留足够的资源。
为了做点这一点，假设一个流中的分组都是沿着同样的线路。
把一个流中的分组随机喷洒到路由器上会使任何保证都变得困难。
因此，从源到目的地必须建立起类似虚电路的东西，属于一条流的所有分组必须都沿着这条路径。
为一个流中的分组之间或者参与竞争的流之间分配路由器资源的算法被称作分组调度算法（packetschedulingalgorithms）。
有三种资源能被预留：
1、带宽
2、缓存空间
3、CPU周期
第一个，带宽，使最显而易见的。
如果一条流要求1Mbps，输出线路的容量为2Mbps，那么试图把三条流导到那条输出线路将不会正常运作。
因此，预留带宽意味着不要把任何输出线路塞满。
Thus,reservingbandwidthmeansnotoversubscribinganyoutputline.
第二个资源是缓存空间，这是经常供不应求的。
当一个分组到达，它被缓存在路由器里面，直到它能被在选种的输出线路上传输。
缓存的目的是当流相互之间竞争的时候吸收小的流量突发。
如果没有缓存可用，分组不得不取消，因为没有地方存放它。
对于好的服务质量，会为某条特殊的流预留一些缓存，这样，这条流就不必为了缓存而与其它流竞争。
在某个最大值范围内，总有可用的缓存为这条流准备着。
最后，CPU周期也可能是一种稀缺的资源。
处理分组会占用CPU时间，因此一台路由器每秒只能处理一定数量的分组。
现代路由器能够快速处理大多数分组，某些种类的分组需要占用大量的cpu处理周期，例如ICMP分组。
为了确保及时对这些分组的处理，需要设法确保CPU没有过载。
分组调度算法分配带宽和其他路由器资源，通过决定缓存了的分组中哪个是下一个即将发送的。
每个路由器以队列的形式为每条输出线路缓存分组，直到它们能被发送，发送的顺序与到达的顺序一样。
这个算法叫做FIFO（First-InFirst-Out）。
当队列满了的时候，FIFO路由器通常会丢掉新到的分组。
新到的分组会被放在队列的末尾，因此这种丢掉分组的行为被称作taildrop。
下面将介绍的其他调度算法创建了新的机会来决定当缓存满了之后哪个分组会被丢掉。
FIFO调度实现起来很简单，但是它不适合用来提供好的服务质量，因为当有多条流的时候，其中一条能够很容易的影响其他流的性能。
如果前面的一条流是强势的，发送大的分组突发，这些分组将停留在队列里。
按顺序处理分组，意味着强势的发送者能够占据它路径上路由器的大多数容量，使其他流严重缺乏资源，降低了它们的服务质量。
雪上加霜的是，那些特别想要通过路由器的流的分组很可能要被延迟，因为它们不得不在队列里面坐在强势发送者发送的许多分组后面。
许多分组调度算法被设计出来，提供了更强的流间隔离，阻止相互干涉的企图。
最早被设计出来的算法之一是公平队列（fairqueueing）算法。
这个算法的实质是：
路有器为每个流准备一个队列，每条流有一条指定的输出线路。
当线路空闲的时候，路有其循环稍描队列，如图5-30所示。
然后取下一个队列的第一个分组。
这样，如果n台主机竞争这条输出线路，每台主机每n个输出分组中占一个。
感觉上这是公
平的，所有的流用同样的速率发送分组。
发送更多的分组也不会提升这个速率。
这个算法有一个缺点：
它给使用大分组的主机的带宽，比使用小分组的主机多。
改进的建议是：
把按分组的循环改成按字节的循环。
使用的技巧是：
计算循环的次数，把这个当作虚拟时间，这个时间是每个分组完成发送的时间。
分组按照他们完成时间排序，并按这个顺序发送。
图5-31展示了这个算法和一个例子，在这个例子中有三个流中达到的分组的结束时间。
如果一个分组的长度为L，从启动时间（starttime）到结束排队发送需要L轮。
启动时间要么是前一个分组（同一队列）的结束时间，要么是分组的到达时间（如果当它到达时队列是空的）。
仅看前两个队列中各自的前两个分组，它们到达的顺序为A，B，D和F。
分组A在第0轮到达，8字节长度，因此结束时间为8轮。
同样B的结束时间为11。
分组D在B被发送之后达到。
D的长度为9字节因此，D的结束时间为11+9=20。
F的到达时间比A结束的时间晚，所以F的结束时间为它的到达时间10+长度6=16。
不考虑新来的分组，这四个分组的相对发送顺序为A，B，F，D，即使F比D晚到。
很可能在最上面的流中到达一个小分组，然后比D更早发送。
只有D的传送还没开始，才能比D早一步发送。
公平队列不抢占正在传送的分组。
因为分组是按整体发送的，公平队列仅是对理想的逐字节（byte-by-byte）方案的一种近似。
这个算法的缺点是：
它给与所有主机同样的优先级。
例如，在很多情况下，可望给予视频服务器比文件服务器更多的带宽。
每一轮循环给视频服务器两个或多个字节，这是很方便的。
这个改进的算法被称作加权公平队列WFQ（WeightedFairQueueing）。
把每轮的字节数作为流的权重，W。
给出计算结束时间的公式：
是到达时间，
是结束时间，
是分组i（同一个队列中的分组）的长度。
图5-31（a）中最低下的队列的权重是2，因此它的分组发送的更快，可以从图5-31（b）中给出的结束时间中看出。
另一个现实的考虑是实现的复杂度。
加权公平队列需要在结束时间把分组插入到一个排序队列sortedqueue。
如果有N个队列，那么每个分组至少需要
复杂度的操作，这在有许多流的路由器上很难实现。
加权公平队列的一个近似亏空轮询（deficitroundrobin），实现起来非常高效，没分组仅
复杂度操作。
有了这个近似，加权公平队列被广泛的使用。
也存在着其他的调度算法。
一个简单的例子是优先级调度，每个分组被标上优先级。
高优先级的分组总是先于低优先级的分组发送，低优先级的被缓存起来。
同一优先级的分组按照FIFO的顺序发送。
然而，优先级算法有缺点，那就是：
高优先级分组突发会阻塞低优先级分组，低优先级分组不得不无限等待。
加权公平队列是更好的选择。
给高优先级队列一个大的权重，比如3，高优先级分组通常走短线（因为高优先级的分组相对较少），低优先级的分组仍能少量通过，即使有高优先级的流量的时候。
分组可以携带时间戳，按时间戳顺序发送。
时间戳纪录分组沿着路径在路由器上发送的时候，落后或提前的程度。
在一个路由器上排在别的分组后面的分组往往是落后，被优先服务的分组往往是提前。
按分组时间戳的顺序发送分组有利于把慢的分组加速，同时把快的分组减速。
这样做的结果是，网络上传递的分组的延迟更趋向一致。
5.4.4准入控制AdmissionControl
QoS保证通过准入控制处理建立（Qosguaranteesareestablishedthroughtheprocessofadmissioncontrol）。
用户提供流，同时随行的还有对网络的QoS需求。
然后网络决定是否接受或者拒绝该流，这个决定是基于网络的容量和对其它流做出的承诺。
如果网络接受了这个流，网络会提前在网络中的路由器上预留容量，这样做是为在这个新的流上有流量的时候保证服务质量。
上面说的预留，必须要在路径上所有的路由器上做，这个路径是指该流上的分组经过网络的路径。
如果在该路径上的任意一个路由器没有预留资源，该路由器可能会发生拥塞，一个拥塞得路由器会毁了QoS保证。
许多路由算法在各个源和各个目的之间寻找单一的一条最佳路径，然后在最佳路径上发送所有的流量。
如果在最佳路径上没有足够的备用容量，这可能会导致一些流被拒绝。
通过为新的流选择另外一条不同的路径，并且该路径上有多余的容量，那么对于该流仍然可以做出QoS保证。
这被称作QoS路由（QoSrouting）。
还可以把前往每个目的地的流量拆分到多条路径上，这样可以更容易的找到多余的容量。
实现这个想法的一个简单方法是：
路有器选择相等cost的路径，把流量等分或者按照输出线路的容量比例划分。
给出一条路径，决定接受还是拒绝一个流并不是简单的比较流请求的资源（带宽、缓存、cpu周期）和路由器在这三个纬度上的过剩容量。
比这要更复杂一点。
虽然一些应用可能知道它们的带宽需求，但是很少知道缓存或CPU周期需求。
需要另一种方法来描述流，并把这种描述翻译成路由器资源。
Next,someapplicationsarefarmoretolerantofanoccasionalmisseddeadlinethanothers.应用程序必须从网络能做出的保证中进行选择，是硬性保证，还是大多数情况下保证。
如果其它条件都一样，每个人都会选择硬性保证，但是难点在于，这样做很昂贵，因为硬性保证限制了最坏情况下的性能。
对大多数分组的保证对应用程序来说通常是足够了，在性能一定的情况下，这样的保证可以支持更多的流。
一些应用程序可能愿意对流参数进行讨价还价，一些可能不愿意这么做。
例如，一个电影软件，通常运行在30帧/秒，如果没有足够的带宽支持30帧/秒，它可能会愿意降低到25帧/秒。
同样的，每帧的像素数量、音频带宽和其它性能指标可能也是可调节的。
流的协商可能会涉及多方（发送者，接收者，他们之间路径上所有的路由器），所以必须使用能协商的规范的参数来精确描述流。
这样的参数的集合被称作流规范（flowspecification）。
通常，发送者（例如：
视频服务器）产生一个流规范，提出它想使用的参数。
当这个规范在路径上传播时，每个路由器对它进行检查，按需要修改参数。
这种修改只能是降低，而不能提高（例如，更低的数据速率，而不是提高速率）。
当流规范到达对端，参数就能被建立。
图5-32是流规范的一个例子。
基于RFC2210和2211，用于IntegratedServices，这是一种QoS设计。
有5个参数。
前两个参数是令牌桶速率和令牌桶尺寸，令牌桶速率指的是：
使用一个令牌桶来给予发送者能传输的最大的持续速率，这是一个长期的平均速率，令牌桶尺寸给出了发送者能在短期内发送的最大突发。
第三个参数是峰值速率，这是网络在短暂的时间间隔内能忍受的最大传输速率。
发送者绝不能超过这个速率，即使是很短的突发。
最后两个参数指定最小和最大分组尺寸，包含传输和网络层头部。
最小尺寸是有用的，因为处理每个分组占用一些固定的时间，不管分组有多小。
一台路由器也许愿意处理10000分组/
升级会员 