ip网络服务质量序言.docVIP

ip网络服务质量序言 引 言 Internet的发展过程中有许多标志—从令人振奋的“信息高速公路”到令人悲观的“世界范围的等待（World Wide Wait）”。作为一个给人以深刻印象的、世界范围内网络互连的集成，Internet以各种速度将大量的信息传送到各种不同的地点，因此可以说Internet可能真的就像高速公路一样。但是，大多数人经历过这个所谓高速公路给我们带来的不可预料的服务，我们几乎不能否认Internet发展中出现的“世界范围的等待”的存在。这条信息高速公路有时候就好像是一条到处是水没有修好的街道，为减轻交通流量，通常会根据其重要性选择一些分组，对其进行延迟发送或彻底丢弃。服务质量（Quality of Service, QoS）就是要最大限度减少这类问题的发生。 我们为什么需要服务质量 大多数人在玩文字游戏的时候如果看见“尽力而为（Best Effort）”这个词，他们头脑里首先反应的可能就是Internet。网际协议（Internet Protocol, IP）族的发展历史清晰集中地反映出了这种能在各种情况下寻找与建立连接的网络技术的发展过程。一旦分组给定了其最终的目的地址，网络就将（尽最大可能）试图通过任何可用的内部链路确定一条通路，来完成分组向目的地的传送。网络完成传送的实际时间（传输延时）是我们应该考虑的第二个问题。如果由于网络中出现长期或短期的问题而造成网络中没有能到达目的地址的通路，分组就可能会被丢弃（延迟的一种相当极端的形式）。在这两种情况下，网络不会向分组的源端返回任何信息来指示分组发送成功还是失败。这就像邮递普通的信件，邮递员会说“把信交给我吧”，然后只是尽最大努力去传送它。如果需要提供有保证的传递，源端与目的端之间一定要采用额外的端到端机制（例如传输控制协议或称为TCP）来确定分组是否被成功传送，如果失败还要重新传送丢失的分组。 当然，在现实世界中事件的及时性是很重要的。一个穿过IP网络产生分组流的应用程序常常需要满足其自身的某些要求，仅仅在某一些时刻将分组发送出去是远远不够的。一个自动的、每天运行一次的文件备份程序，可能要花数分钟甚至数小时来完成备份任务，因此它可能根本不关心那些经过很长环形径路才到达的分组。如果你在Web上浏览或查询一个远程数据库，那么你会忍受以秒计的延迟；如果延迟超过几分钟，你就根本不可能接受。一些要求更严格的应用程序，例如会话聊天、实时的声音与图像等，必须满足用户的交互的要求—这时可以忍受的延迟是以几分之一秒来衡量的。由网络引入的延迟通常被称为端到端的延迟时间（latency）。 在现实世界中的另一个常见需求是保持分组在时间上的序列特性（来自同一个源的分组到达的时间间隔）。如果一个应用程序按照规律间隔地发送分组流，而这些分组在到达远端目的地时发生分组聚集的突发，那么就说明网络已经破坏了分组源的时间序列特性—通常这种现象称为抖动（Jitter）。这也给那些用于实时音频与视频传送的应用程序带来一些十分棘手的要求（尽管在非实时应用程序中很少考虑这一点，如文件传送与邮件的传输）。一般来说，人们还是希望视频与音频的传输在接收端能够还原出连续平滑、正常的媒体内容。 为了防止抖动的出现，许多现有的网络视频/音频应用程序配置了播放（play-out）缓冲区，以便在对视频与音频内容进行解码时恢复最初的时间序列。然而，播放缓冲区会增加分组从源端发送到接收端的平均时间。交互式应用程序（如Internet电话）需要在大缓冲与小缓冲之间仔细平衡。大缓冲区用来应付网络的不可测行为，小缓冲区用来确保某种可以接受的通话效果。为保证时间序列特性，有时丢弃那些在网络中延迟了很长时间的分组也是值得的。对于非交互式应用程序（如Internet电视广播），播放缓冲区可能会相对大一些，因为这并不会影响用户那端的使用效果。 目前的Internet既不能保证分组传输的及时性，也不能保证分组时间的序列特性—这是因为Internet更关注向哪里发送分组，而较少注意发送分组的时间。在发展的早期这种做法是可以接受的，因为那时的应用程序通常是不要求实时性的。而对简单的实时服务如远端登录等，当时的网络一般情况下也已经能提供足够好的服务了。网络的设计与配置通常都遵循这样一句格言，“网络出现拥塞时就增加带宽”。共享可用带宽的工作完全交给了统计复用的随机原理。只要任何一条链路的可用带宽远远大于平均的通信负载，大概每个人都会感满意。 然而，时代已经发生了变化。企业的IP intranet与商业IP骨干网同样都要面临许多新的需求，要求他们的网络在端到端的行为上具有更高的可预测性。这些需求是由一系列因素所引出的，这些因素包括运行网络多媒体应用程序的PC数量的