标准Internet协议(IP)的网络提供尽力而为的数据传输。这种IP网络允许客户端主机的结构复杂一些，而网络端的结构可以保持相对的简单，因为Internet要支持自身的快速发展，所以这样的结构划分是有好处的。当越来越多的主机联在一起的时候，网络服务的需求最终会超过网络的能力，而服务却不会停止，由此产生网络性能的逐渐恶化，进而造成传输迟延的变化(抖动)，甚至引起分组丢失，但不会影响常用的Internet应用(如，电子邮件，文件传输和Web应用)，而其它应用就不能适应有迟延的服务。传输迟延对有实时要求的应用(例如传送多媒体信息)及大多数双向通信(如电话)带来了问题。
增加带宽是满足这些实时应用必要的第一步。但是当业务量猛增的时候，仍难以避免传输迟延。甚至在一个负载相对较轻的IP网络上，传输迟延也能累积到影响实时应用的程度。为了提供能够满足要求的服务，必须补充制订有关服务数量、或服务质量水平的规定。规定中需要在网络方面增加一些协议，来区分具有严格定时要求的业务和能够容忍迟延、抖动和分组丢失的业务。这就是服务质量(QoS)协议要做的事情。QoS不是创造带宽，而是管理带宽，因此它能应用得更为广泛，能满足更多的应用需求。QoS的目标是要提供一些可预测性的质量级别，以及控制超过目前IP网络最大服务能力的的服务。
QoS协议要满足各种应用的需要。这篇文章将对这些协议做详尽的描述，然后说明它们在遵循端到端原则的不同的网络结构里是如何相互配合工作的。IPQoS技术所面临的挑战是要能把传输的服务从不同的数据流中区分开，或者在不中断网络工作的情况下将数据聚合起来。尽力而为服务的改进表明让Internet发挥其最大作用的设计思路发生了根本变化。
为了避免QoS协议用于网络时出现问题，端到端原则仍然是QoS设计者首要遵循的原则。所以，保持网络边缘复杂、核心简单这一基本原则是QoS结构设计的中心问题。这不是指单个QoS协议，而是指这些协议如何相互配合来实现端到端的QoS。
QoS协议
描述QoS的方法不只一种。通常情况下，QoS是一个网络部件(如一个应用、一台主机或一个路由器)提供的一些保证稳定传输网络数据的质量级别。某些应用对QoS的要求比其它应用更高，因此有下面两种基本的QoS：
资源预留(适于综合服务)：根据某个应用对QoS的要求来分配网络资源，并且服从带宽管理策略
按优先级排列(适于差分服务)：对网络的业务进行分类，并根据带宽管理策略的规范来分配网络资源。当所标识的业务类别有更强烈服务要求的需求时，网络部件会给予优先处理。
有两种其它方法描述QoS类型：
''流''型QoS：把一个''流''定义为一个信源和信宿之间、单个、单向、由传输协议唯一标识的数据流，其中包括数据流的源地址、源端口号、目的地址以及目的端口号
''聚合''型QoS：一个聚合是简单的两个或更多的''流''。最为突出的是，这些''流''会有相同的标记或者优先级号码，也许还有一些相同的认证信息。
应用、网络拓扑结构和策略决定了哪一种QoS最适合个别''流''，或者''流聚合''。
为满足对QoS不同的需要，有以下几种QoS协议和算法：
资源预留协议(RSVP)：提供网络资源预留的信令。尽管RSVP经常用于单个流，但也用于聚合流的资源预留
差分服务(DiffServ)：提供一个简单的分类和网络聚合流的优先级
多协议标记交换(MPLS)：根据分组头的标记，通过网络路径控制来提供聚合流的带宽管理
子网带宽管理(SBM)：负责OSI第二层(数据链路层)的分类和优先级排列，同IEEE802网络进行共享和交换。
RSVP－资源预留
RSVP是一个信令协议，它提供建立连接的资源预留，控制综合业务，往往在IP网络上提供仿真电路。RSVP是所有QoS技术中最复杂的一种，与尽力而为的IP服务标准差别最大，它能提供最高的QoS等级，使得服务得到保障、资源分配量化，服务质量的细微变化能反馈给支持QoS的应用和用户。
协议的工作情况如下：
发送端依据高、低带宽的范围、传输迟延，以及抖动来表征发送业务。RSVP从含有''业务类别(TSpec)''信息的发送端发送一个路径信息给目的地址(单点广播或多点广播的接收端)。每一个支持RSVP的路由器沿着下行路由建立一个''路径状态表''，其中包括路径信息里先前的源地址(例如，朝着发送端的上行的下一跳)
为了获得资源预留，接收端发送一个上行的RESV(预留请求)消息。除了TSpec，RESV消息里有''请求类别(RSpec)''，表明所要求的综合服务类型，还有一个''过滤器类别''，表征正在为分组预留资源(如传输协议和端口号)。RSpec和过滤器类别合起来代表一个''流的描述符''，路由器就是靠它来识别每一个预留资源的
当每个支持RSVP的路由器沿着上行路径接收RESV的消息时，它采用输入控制过程证实请求，并且配置所需的资源。如果这个请求得不到满足(可能由于资源短缺或未通过认证)，路由器向接收端返回一个错误消息。如果这个消息被接受，路由器就发送上行RESV到下一个路由器
当最后一个路由器接收RESV，同时接受请求的时候，它再发送一个证实消息给接收端
当发送端或接收端结束了一个RSVP会话时，有一个明显的断开连接的过程。
RSVP支持的综合业务有以下两种基本类型：
有保证业务：这种业务是，尽可能地仿真成一条专用虚电路。除了要根据TSpec参数的要求确保带宽的有效性外，它还可以用把一条路径里的不同网络部件的参数合并起来的方法来提供一个端到端的固定的队列延迟
受控负载：这相当于''无负载条件下尽力而为服务''。因此，它比''尽力而为''服务更好，但是不能提供''有保证业务''所承诺的，具有严格固定队列延迟的服务。
对于‘有保证业务’和受控负载，处理不同的(与类别无关)数据业务就象处理没有QoS的尽力而为数据业务那样。综合业务采用令牌筐模式来表征输入／输出排序算法。设计令牌筐是为了平滑输出的业务流，但不象泄露筐模式(也可以平滑输出的业务流)，令牌筐模式允许数据突发、在短时间内维持更高的发送速率。
RSVP协议机制要点：
每个路由器的预留资源是''软''的，即这些资源需要由接收端定期地刷新
RSVP不是传输协议，而是网络(控制)协议。作为这样的协议，它不传送数据，但是和TCP或者UDP的数据''流''是并行工作的
应用要求API详细说明数据流的需求，初始化预留资源请求，并且在发出初始化请求后，接收预留成功或失败的通知并贯穿于整个会话过程。为了更好地利用API，API也要包含那些描述在整个预留时间内的预留建立期间或之后，当条件发生变化时出现问题的RSVP错误信息
根据接收端的情况来预留资源，是为了有效的接纳相当复杂的(组播)接收端组
在上行方向的业务复制点处组播预留资源混合在一起(仍然有不易理解的复杂算法在里面)
尽管RSVP业务可以通过不支持RSVP的路由器，但是这会在QoS''链''上产生一条''弱链路''，于是，QoS''链''的服务质量降回到''尽力而为''的水平(即在这些链路上没有预留资源)
两种RSVP协议：一是纯RSVP，包含IP的46号协议(用于IP分组头的协议区)，RSVP的分组头和有效负载封装在IP分组头里。封装在UDP里的RSVP把它的分组头放在UDP数据报里。下文将描述只支持纯RSVP的802协议，即''子网带宽管理''。
上面提到RSVP提供最高的IPQoS等级。应用可以请求高量化程度的QoS，以及具有非常好的传输质量保证的QoS。这听上去似乎万无一失，可让我们感觉疑惑的是，为什么我们还要考虑其它问题。这是由于RSVP协议存在着复杂性和开销的价格问题，因而许多应用和网络的一些组成部分并不采用它。简单地说，RSVP缺少微调的方法，而DiffServ却可以提供这种方法。
