流媒体的协议

nmwhqjl

流媒体和服务模型
在Internet诞生以来相当长的一段时间内，网上的应用一直局限于下载（Download）使用的模式。流媒体（Stream Media）技术的出现使得在窄带互联网中传播多媒体信息成为可能。
1995年，当时的Progressive Network公司（现在叫RealNetwork公司）推出了第一个流产品。自那时以来，Internet上的各种流应用迅速涌现，逐渐成为网络界的研究热点。随着这项技术的不断发展，现在已经有越来越多的网站开始采用流式技术作为传播信息的方式，从而使网站的内容变得丰富多彩。
未来的网络将是多功能提供多种不同服务，以支持不同的应用需求，特别是适应实时多媒体的应用。如何实现这种有不同服务提供能力的集成服务一直是国内外研究的热点。IETF针对Internet服务模型层次开展研究，较早地提出了所谓综合业务／资源预留协议（Intserv／RSVP）模型。后来又提出区分服务模型(DiffServ，Differentiated Services)。
本章介绍流媒体和服务模型的有关技术和协议，以及典型的应用。
第 1 节   流媒体传输和服务协议
一 ．RTP和RTCP
RTP （ Real-time Transport Protocol ，实时传输协议) 是用于 Internet 上针对多媒体数据流的一种传输协议。 RTP 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。 RTP 通常使用 UDP 来传送数据，但 RTP 也可以在 TCP 或 ATM 等其他协议之上工作。当应用程序开始一个 RTP 会话时将使用两个端口：一个给 RTP ，一个给 RTCP(Real-time Transport Control Protocol，实时传输控制协议) 。 RTP 本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制。它依靠 RTCP 提供这些服务。通常 RTP 算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。 RTCP 和 RTP 一起提供流量控制和拥塞控制服务。在 RTP 会话期间，各参与者周期性地传送 RTCP 包。 RTCP 包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。 RIP 和 RTCP 配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
二．RTSP
RTSP(RealTime Streaming Protocol ， 实时流协议 ) 是由 RealNetworks 和 Netscape 共同提出的，该协议定义了一对多应用程序如何有效地通过 IP 网络传送多媒体数据。 RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP 或 RTP 完成数据传输。 HTTP 与 RTSP 相比， HTTP 传送 HTML ，而 RTSP 传送的是多媒体数据。 HTTP 请求由客户机发出，服务器作出响应；使用 RTSP 时，客户机和服务器都可以发出请求，即 RTSP 可以是双向的。
三．RSVP
由于音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求之外，还需其他更多的条件。 RSVP(Resource Reserve Protocol ，资源预订协议) 是为 Internet 开发的 ，使用它来 预留一部分网络资源 ( 即带宽 ) ，能在一定程度上为流媒体的传输提供 QoS 。在某些试验性的系统如网络视频会议工具 vic 中就集成了 RSVP 。
四．IntServ模型
IETF为了提高IP网络的性能，推出IntServ（综合服务）框架模型使IP网能够提供具有QoS保证的传输，应用于对QoS要求较为严格的实时多媒体通信和分布式多媒体应用(音频和视频)。IntServ定义了一个最小的对于全网的要求集合，使Internet转变为一个坚固的综合业务通信基础设施。它的实施需对全网络的路由器升级，加入软硬件（详细参考RFC l633）。
IntServ为应用提供其所要求的端到端行为(End To End Behavior)，使应用能够为其数据包的传送选择服务等级。为了支持这种能力，数据包所经过的每个网络元素(子网和IP路由器)都必须能够支持控制服务质量(QoS)的机制，并且必须提供一种手段把应用的要求通知给每个网络元素，并在应用与网络元素之间传送QoS管理信息。
IntServ所采用的主要技术包括：先进的碰撞管理，限制延迟、抖动，网络内带宽消耗的排队算法，以及能够为特定应用预留带宽的资源预留协议(RSVP)。
1．IntServ的服务类型
IntServ模型规定了三种不同等级的服务类型：
(1)可保证业务(Guaranteed Service)：对端到端数据包延迟有严格的界定，并且具有不丢失包的保证。该业务不能控制固定延迟，它能保证的是排队延迟的大小。网络使用加权公平排队(Weight Fair Queuing)算法。
(2)可控负载业务(Controlled Load)：在较轻负载网络中近似于尽力而为（Best-Effort）业务，提供最小包传送延迟，不要求特定排队算法。在可控负载的业务网络中，应用可以假设网络传输的包差错率近似下层传输媒质的基本包差错串；包平均传输延迟与网络绝对延迟差别不大。
(3)尽力而为业务(Best-Effort Service)：目前的业务不提供任何的QoS保证。
2．IntServ模型的基本概念和机制
(1)流：为了标识实时业务，IntServe模型中提出了流的概念。实时业务可由流来标识。为了提供实时业务要求的服务质量，必须改变交换机和路由器软件使之能够对流进行处理。扩展路由功能加入先进的排队策略和流建立协议，使路由器不仅辨别消息的发送目的，还能判断是否属于某个流，属于某个流就应提供相应的服务质量(QoS)。信令协议功能包括保证使网络能够为每一个流提供有效的资源并设置其所需要的排队策略。
(2)排队策略：定义排队策略是IntServ模型的重要内容之一。传统路由是用FIFO排队算法，处理网络阻塞事件能力差，加上优先级对实时业务的转发延迟保证，但使低优先级可能出现饿死，而采用公平排队算法能够较好地解决这个问题。但希望得到较好的QoS实时业务它还缺少一个优先级策略，如果采用加权公平排队算法(Weight-Fair Queuing)就能够有效地改进。
(3)阻塞控制机制：IntServe提供加权的随机早期探测(Weighted Random Early Detection，WRED)阻塞控制机制，可为不同业务类型提供不同的业务保证。
(4)资源预留协议(RSVP)：该协议为每个流预先申请其所要求的网络资源，在IP包从发送者到接收者之间经过的每一个路由上为每个业务流申请所需的带宽、缓冲区等资源，而路由器则必须为RSVP流保持所需的“软状态”。
3.存在的问题
(1)可扩展性是IntSer的重要问题。它要求网上从发送到接收之间所有路由都支持所实 施的信令协议，如果中间有不支持的节点，资源预留和服务质量保证就大打折扣。
(2)实现机制相当复杂，目前IETF还没有给出令人满意的结果。
五．DiffServ模型
DiffServ（区分服务）是IETF工作组为了克服IntServ的可扩展性差而提出的另一个服务模型，目的是制定一个可扩展性相对较强的方法来保证IP的服务质量(QoS)。传统的Internet网上ISP为所有用户提供同一等级的服务，即尽力而为的方式。DiffServ模型(见图14-01-1)的目的实际上是给业务分类，在用户和业务网的接口处分级，业务的分组也是基于每个数据包的不同标识。同一级别的业务会聚合统一传送，保证相应的延迟、传送速率、抖动等服务质量(QoS)参数。
ER
边界路由器
TR
转发路由器
GR
网关路由器
CC
客户端设备
  图14-01-1  DiffServ 模型示意图
DiffServ并不提供从发送者到接收者的端到端服务质量保证，而是在域(Domain)的范围内保证与业务分类相对应的服务质量，每个域之间对于不同类别业务的服务质量都应有一定的约定和包标识的翻译机制。
IETF对域专门定义，Differentiated Service Domain也叫DS域。它是指Internet的一部分，在其中有一致的业务分类策略和管理机制等。
在DiffServ当中，所有处理都基于Internet业务流的分级，包括流的聚合以及适用于不同业务类别的每一个跳行为(PHB，Per-Hop-Behavior)，因此它具有较大的可扩展性。由于它不同于上述的IntServ模型中在每个路由器上为每个业务流保留软状态，所以在网络不断扩展的过程中，不必过于担心网络负担增加是否给网络造成根本性的损害。DiffServ把对业务服务质量的控制缩小到了每个域的范围，更进一步降低了在目前网络中实现的复杂度。
第 2 节   RTP 与 RTCP 协议
一. 概述
实时传输协议（RTP，Real Time Transport Protocol）由RFC 1889定义，主要用于网络上各种实时应用（Real-time applications）。现在实时应用非常热（图14-02-1）。
图14-02-1  网络实时应用例
为什么不采用TCP？
众所周知，Web网页传输是建立在HTTP协议的基础上的，但是HTTP有着自己的局限性：
1.HTTP是无连接协议，限制了每次连接只处理一个请求，服务器处理完客户的请求，收到应答后，即断开连接，虽然这种方式可以节省时间，但却无法实现广播。
2.HTTP是无状态协议，所谓的无状态协议是指协议对于事件处理无记忆能力，这就意味着如果后续处理需要前面的信息，则必须重传，如果采用HTTP则必须重传，从而导致传输数据量增大，带宽浪费。
存在4个问题：
o      不需要100% 的可靠性
o      重发延迟
o      窗口后退
o      N 参与者 -> N*N 连接
实时传输协议提供了支持这些要求的功能：
·           丢失，顺序混乱：序列号
·           丢失，不稳定：时间戳
·           数据源/有效载荷认定
·           速率控制: 服务质量反馈（QoS feedback）
RTP用于一对多传输情况下，提供时间信息和实现媒体同步。此外，实时传输控制协议（RTCP，Real Time Transport Control Protocol）与RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此服务器可利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合网上的实时数据。
RTP和其他熟悉的协议如HTTP、 FTP等类似，但是根据实时流的特定要求作了剪裁。
和HTTP、FTP不同，RTP并不下载整个视频到客户计算机上，而是用固定的数据速率传输一个细的单向数据流，使其实时播放广播（在很短的初始化握手和数据缓冲之后）。一个流化了的一分钟电影就恰好播放一分钟。当连接具有足够的带宽来处理数据流的时候，电影就将播放。当数据播放完了就丢弃。观众只能通过再请求从流服务器来重放。
实时流是如何被处理的？
当你收听实时广播时，流客户软件 （比如，QuickTime Player， 或者QuickTime 插件) 发送一个请求到流服务器。服务器查找会话描述协议 (SDP，Session Description Protocol)文件, 如找到，就开始通过RTP发送流媒体到你的计算机。
一个SDP文件是一个文本文件，包含了将要发送什么和怎么收听的信息。SDP文件由计算机上的广播软件（比如Sorenson广播器）建立，它捕获实况媒体，但是SDP文件必须在媒体广播之前被拷贝到流服务器。QuickTime Player 和QuickTime 插件可以打开视频的SDP文件。
传送的问题
必须牢记实时流包含一些传送上的问题。
• 数据丢失。 RTP 使用低级的UDP进行传送。 UDP 比TCP/IP快，但是没有丢失报告机制，所以Internet上的流通常都会丢失。
• 网络地址转换。小型网络用路由器连接Internet接收流可能有问题。这些路由器通常使用网络地址转换(NAT， Network Address Translation), 但是RTP的流包含的端口地址会使一些老式NAT软件迷惑。你需要升级NAT软件。
• HTTP 管道。如其他失败，使用HTTP管道将RTP数据包打包进普通HTTP数据包。这常常使流能穿过防火墙或NAT路由器。要使用HTTP管道, 收看者必须配置自己的QuickTime 设置控制面板，通过检查使用HTTP并且设置端口为80（或者是流服务器用HTTP传输的端口），而且服务器必须支持HTTP管道。
RTP 与 RTSP的比较
分清楚RTP和实时流协议（RTSP）很重要, RTSP是另一个传送协议。RTSP 用在观众和Unicast 服务器通信的情况。RTSP 提供双向通信，即观众可以和流服务器通信并且进行如倒带、换章节观看等操作。
相反，RTP 是一个单向协议，只能从服务器发送实况或存储流到客户。
RTP一般和RTCP配合使用（图14-02-2）。两个密切链接的部分（相继的UDP端口）：
o  数据部分，传输RT数据
o 控制部分RTCP（Real Time Control Protocol) ，监视QoS和携带预期信息
  
（a）用途
（b）使用相邻的端口
图14-02-2  RTP和RTCP的使用
二．RTP数据传输协议
RTP提供端对端网络传输功能，适合通过多播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立于传输层和网络层。
1．RTP固定头
RTP头格式如图14-02-3所示。
图14-02-3  RTP头格式   
开始12个八位组（字节）出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各字段的含义如下：
① 版本(v)：2位，标识RTP版本。
② 填充标识(P)：1位，如设置填充位，在包尾将包含附加填充字，它不属有效载荷。填充的最后一个八位组包含应该忽略的八位组。某些加密算法需要固定大小的填充字，或为在低层协议数据单元中携带几个RTP包。
③ 扩展(x)：1位，如设置扩展位，固定头后跟一个头扩展。
④ CSRC计数(cc)：4位，CSRC计数包括紧接在固定头后CSRC标识符个数。
⑤ 标记(M)：1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标识位，或通过改变位数量来指定没有标记位。
⑥ 载荷类型(PT，Payload Type)：7位，标识RTP载荷格式并决定其解释。设置指定载荷类型代码对载荷格式的静态映射（audio, video, image, texte, html等）。其他载荷类型代码可通过非RTP途径动态定义。对音频和视频的缺省映射初集在相关设置中指出。将来可进一步扩展。
⑦ 序列号（Sequence Number）：16位，序列号随每个RTP数据包而增加1，由接收者用来探测包损失，而恢复包序列。序列号初值是随机的，使对加密的文本攻击更加困难。
⑧ 时间戳（timestamp）：32位，时间戳反映RTP数据包中第一个八位组的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时钟必须有足够分辨率，满足所需同步和测定包到达抖动精度。时钟频率依赖携带数据的格式，并在设置中静态指定。如RTP包周期产生，采用采样所用的时钟确定名义采样时刻，而不是从系统读出。如同序列号，时间戳的初始值是随机的。如几个连续RTP包在逻辑上一次产生它们就有着相同的时间戳，属于同一视频帧。如数据不是以采集顺序发送，像MPEG插入的视频帧，连续RTP包包含的时标可能不是单调的。
⑨ 同步源标识符（SSRC，Synchronization Source Identifier）：32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中设有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。
⑩ CSRC列表：0到15项，每项32位。CSRC列表表示包内包含的对载荷起作用的源。标识数量由CC段给出。如超过15个作用源，也仅标识15个。CSRC标识由混合器插入，用作源的SSRC标识。
2．复用RP连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址(网络地址与端口号)提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不再将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。
使用同一SSRC，而具有不同载荷类型的交叉包将带来几个问题：
(1) 如一种载荷类型在连接期间切换，没有办法识别新值将替换哪一个旧值。
(2) SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明哪种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
(3) RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
(4) RTP混合器不能将不兼容媒体流合并成一个流。
(5) 在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配，接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
3．对RTP头特定设置的修改
现用RTP数据包头对RTP支持的所有应用类共同需要的功能集可以认为是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位宇，故允许分配在固定头中。包含这些段的八位组可通过设置重新定义以适应不同的要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八位组中最重要的位。
其他特殊载荷格式(视频编码)所要求的信息应该携带在包的载荷部分。可出现在头部，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始的12个八位组处理RTP包。
三. RTP控制协议——RTCP
RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分发机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：
(1) 主要是提供数据发布的质量反馈。RTCP是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP多播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP多播等发布机制使网络服务提供商之类的团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
(2) RTCP带有称作规范名字(CNAME)的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME与相关RTP连接中给定的几个数据流联系。
(3)前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其他参加者发送控制包，就加大独立观察参加者数量。该数量用于计算包发送的速率。
(4)第四个可选功能是传送最小连接控制信息，如辨识参加者。最可能用在“松散控制”连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。
在IP多播场合应用RTP时，前三个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
（一）RTCP包格式
下面定义几个携带不同控制信息的RTCP包类型：
·           SR（Sender Report）：发送者报告，当前活动发送者发送、接收统计。
·           RR（Receiver Report）：接收者报告，非活动发送者接收统计。
·           SDES（Source Description）：源描述项，包括CNAME, NAME, EMAIL, PHONE等。
·           BYE：表示结束。
·           APP（application）：应用特定函数。
类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多个RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。
组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但为了执行协议功能，强加如下约束：
(1) 接收统计(在SR或RR中)应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP包应包含报告包。
(2) 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。
(3) 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。
因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：
①加密前辍(Encryption prefix)
仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。
② SR或RR
组合包中第一个RTCP包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，即避免组合包中RTCP包为BYE（终止标识）。
③ 附加RR
如报告统计源数目超过31，在初始报告包后应该有附加RR包。
④ SDES
包含CNAME项的SDES包必须包含在每个组合RTCP包中。如应用要求，其他源描述项可选，但受到带宽限制。
⑤ BYE或APP
其他RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。
建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径量最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在因特网分配号码机构（IANA，Internet Assighnedd Numbers Authority）处注册。
二）RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对多播，给定连接数据率仍是常数，独立于连接数。但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
对每个连接，假定数据流量受到“连接带宽”的总量限制。选择连接带宽是根据费用或网络带宽的先验知识，与媒体编码无关，但编码选择会受到连接带宽的限制。当调用一个媒体应用时，连接带宽参数由连接管理应用提供，但媒体应用也可根据单个发送者数据带宽设置缺省值。应用可根据多播范围规则或其他标准强制限制带宽。由于这是资源预订系统需要知道的，对控制与数据流量的带宽计算包括低层传输与网络协议。应用也需要知道在使用哪个协议。在传输途中，因为包将包含不同连接层的包头，所以连接层的包头不计算在内。控制流量应限制为连接带宽中已知的一小部分：小，传递数据的传输协议主要功能才不致受损；已知，控制流量才能包含在所给资源预订协议的带宽规范中，这样，每个参加者就可单独计算其共享量。建议分配给RTCP的连接带宽固定为5％，而这个数值与间隔计算中其他常量并不重要，连接中所有参加者必须使用相同数值，因此，使用相同间隔计算。
计算RTCP包间隔依赖连接中地址加入数量的估计。当新地址被监听到，就加到此计数，并在以SSRC或CSRC标识索引的表中为之建立一个条目，用来跟踪它们。直到收到带有多个新SSRC包，新条目才有效。当收到具有相应SSRC标识的RTCP的BYE包，条目可从表中删除。如果对少量RTCP报告间隔没有接收到RTP或RTCP包，参加者可能将另外一个地址标记成不活动，如还未生效就删除掉。这为防止包丢失提供强大支持。为了“超时”正常工作，所有地址必须对RTCP报告间隔记入大致相同的数值。
一旦确认地址有效，如后来标记成不活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME(人名)和E-mail(电子邮件地址)。它也是定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20％。而且并没有有意让所有SDES项包含在每个应用中。
（三）发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包则根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间惟一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR。SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR或RR包中，附加RR包可堆叠在初始SR或RR包之后。
发送者报告包由三部分组成，也可能还有第四个特定设置扩展部分（图14-02-4）。   
图14-02-4  发送者报告包
1) 第一部分为头，8个八位组长，内容如下。
① 版本（V）：2位，标识RTP版本。
② 填充(P)：1位，如设置于此位，RTCP包结尾包含一些附加填充八位组，它们不属于控制信息。最后一个八位组填充表示应忽略多少个填充。有些加密算法需要填充，块大小固定。在组合RTCP包内，填充仅在最后一个包中需要，因为组合包加密成一个整体。
③ 接收报告计数(RC)：5位，包含在包内的接收报告块数目，0值为有效。
④ 包类型(PT)：8位，包含常数200标识此包为RTCP的SR包。
⑤ 长度：16位，32位字RTCP包长度的一半。
⑥ SSRC：32位，同步源标识。
2) 第二部分为发送者信息，20个八位组，出现在每个发送者报告包中。含义如下。
① NTP时标：64位，表示报告发送时的时钟时间，这样它就可用于合并从其他发送者到那些接收者的接收报告返回的时标。
② RTP时标：32位，与上述NTP时标同一时间有关，但与RTP时标有着相同的时间单位和同样的随机偏移。
③ 发送者包计数：32位，自开始发送来，直到SR包产生时刻，发送者发送RTP数据包总数。如改变SSRC标识符，此计数重置。
④ 发送者八位组计数：32位，发送者在RTP数据包中发送的载荷八位组总数。从发送开始，直到产生SR包，如发送者改变SSRC标识，重置此计数。这部分可用于估计载荷数据平均速率。
3) 第三部分包含接收报告块，大小不固定。每个接收报告块传送单个同步源接收RTP包的统计。发生冲突，当源改变SSRC标识时，接收者并不继续统计。这些统计包括：
① SSRC_n(源标识)：32位，接收报告块中信息所属源的SSRC标识。
② 丢失部分：8位，前一个SR或RR包发送以来所丢失的源SSRC_n的RTP数据包中一部分，定义成所丢失包的数目。
③ 丢失包累积数：24位，自接收以来所丢失的源SSRC_n的RTP数据包总数，定义成小于实际所接收包的数量，该数量包括迟到或复制的包。因此，迟到的包不计为丢失，如有复制，此数量可能为负数。
④ 收到已扩展的最高系列号：32位，低16位包含从SSRC_n源RTP数据包中收到的最高系列号，最重要的16位以系列号循环相应计数扩展系列号。如开始时间明显不同，同一连接内不同接收者将对系列号产生不同扩展。
⑤ 间隔抖动：32位，RTP数据包间隔时间的统计估计，以时标为单位，是一个无符号整数。
⑥ 最后SR时标(LSR)：32位，NIP时标的中间32位，如还没有收到SR，此段设为零。
⑦ 自最后一个SR来的延迟(DLSR)：32位，延迟以1／65536秒为单位，表示源SSRC_n收到的最后一个SR包与发送此接收块之间的时间，如还没有收到SR，此段设为零。
接收报告包格式与SR包类似（图14-02-5），但包类型包含常数201，并删除发送者信息的五个字。当没有数据传输或接收报告时，则将一个空RR包(RC=O)放在组合RTCP包的前头。
图14-02-5  接收报告包
如接收者或发送者有附加信息要有规律地报告，应对接收报告与接收者定义设置或应用扩展。如需要附加发送者信息，应首先包含在发送者报告的扩展中，但不出现在接收者报告内。如要包括接收者信息，数据结构应设块数组，与接收报告块数组类似，即块数量由RC段表征。
人们总是希望接收质量反馈不仅对发送者有用，而且对其他接收者和第三方监控都有用。发送者可根据反馈改变发送，接收者决定问题是出现在本地、区域还是全局。网络管理员可仅使用接收RTCP包、而不是RTP数据包的设置无关监控器来估计网络多播的性能。
累计计数用在发送信息与接收者报告块中，可考虑长期和短期测量与提供报告丢失恢复能力之间的差别。后两个接收到报告之间的差别可用来估计近来发送的质量。将NTP时标包含在内，从两个报告间隔的差别考虑速率。由于时标独立于数据编码时钟速率，很可能实现编码与设置无关的质量监控器。
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别则给出间隔期间希望发送的包数量，两者之比等于间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失率可通过NTP时标差除以丢失部分得到。
根据发送者信息，第三方监控器可计算出载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
（四）源描述RTCP包
源描述RTCP包（SDES）为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源（图14-02-6）。
图14-02-6  SDES包
1) 项描述如下：
（1）版本(V)、填充(P)、长度：如SR包中所描述。
（2）包类型(PT)：8位，包含常数202，标识RTCP SDES包。
（3）源计数(X)：1位，包含在SDES包中的SSRC／CSRC块数量，零值有效，但没有意义。
2) 源描述项
源描述项内容如图14-02-7所示。
图14-02-7  源描述项
① CNAME
规范终端标识SDES项。CNAME标识属性如下：
·           如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
·           像SSRC标识，CNAME标识在RTP连接的所有参加者中应是惟一的。
·           为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
·           为方便第三方监控，CNAME应适合程序或人员定位源。
② NAME
用户名称SDES项，这是用于描述源的真正的名称，如"John Doe，Bit Recycler，Megacorp"，可以是用户想要的任意形式（图14-02-8）。对诸如会议应用，这种名称也许是参加者列表显示所最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中惟一依赖。
图14-02-8  NAME
③ E-mail
电子邮件地址SDES项。邮件地址格式由RFC822规定，如“John.Doe@megacorp.com"。连接期间，电子邮件仍希望保持为常数。
图14-02-9  EMAIL
④ PHONE
电话号码SDES项。电话号码应带有加号，代替国际接入代码，如“+86 28 8541 1212"即为中国电话号码。
图14-02-10  PHONE
⑤ LOC
用户地理位置SDES项。根据不同应用，此项具有不同的详细程度。对会议应用，字符串如"Murray Hill，New Jersey"就足够了。然而，对活动标记系统，字符串如“Room 2A244，AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。
图14-02-11  LOC
⑥ TOOL
应用或工具名称SDES项，是一个字符串，表示产生流的应用的名称与版本，如“video tool 1.2”。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。
图14-02-12  TOOL
⑦ NOTE
通知／状态SDES项。推荐的该项语法如下所述，但这些或其他语法可在设置中显式定义。NOTE项旨在描述源当前状态的过渡信息，如"on the phone，can't talk"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。
当其为活动时，由于NOTE项对显示很重要，其他非CNAME项(如NAME)传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20~30倍RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。
图14-02-13  NOTE
⑧ PRIV
专用扩展SDES项。该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前组长度段为8位。前缀字符中是定义PRIV项人员选择的名称，惟一对应应用接收到的其他PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其他人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
注意，前缀消耗了总长为255个八位组项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性，IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
（五）断开RTCP包（BYE）
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC／CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个八位组计数，后跟表示离开原因的很多八位组文本，如：“camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32位边界，字符中就不以空结尾；否则，BYE包以空八位组填充。
图14-02-14  BYE
（六）定义应用的RTCP包（APP）
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
图14-02-15  APP
图14-02-16给出了一个速率控制例。在理想情况下，使用RTP/RTCP可以使源速率与传输能力达到匹配（最小丢失）。
图14-02-16  速率控制例
四. 基于网络和传输协议的RTP
这部分讲述特殊网络和传输协议内与携带RTP包相关的内容。如果没有规范外特定协议定义替代，下列规则可适用。
RTP依赖低层协议提供RTP数据和RTCP控制流的多路分解。对UDP和类似协议，RTP使用一个偶数端口号，而相应RTCP流使用下一个(奇数，递增)端口号。如应用使用一个奇数RTP端口，就应该用下一个小偶数端口代替。RTP数据包不包含长度段或其他描述，因此RTP依赖低层协议提供长度指示，RTP包最大长度仅受低层协议限制。如RTP包包含在提供连续八位组流的低层协议而不是信息(包)中，必须定义RTP包的封装以提供帧机制。如低层协议包含填充，也需要帧机制，否则结果无法决定RIP负载程度。这里没有定义帧机制。
当RTP包含在提供帧的协议中时，为了允许在一个低层协议数据单元(UDP包)包括几个RTP包，设置可指定所使用的帧方法。在网络或传输包中携带几个RTP包可减少头部，并可能简化不同流之间的同步。
第3节 RTSP协议
RTSP（Real Time Stream Protocol，实时流协议）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现插数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、多播UDP与TCP等提供途径，并为选择基于RTP上发送机制提供方法。
一．简介
1．目的
实时流协议建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP 1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：
(1)从媒体服务器上检索媒体
用户可通过HTTP或其他方法提交一个演示描述。如演示是多播，演示时就包含用于连续媒体的多播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
(2)媒体服务器邀请进入会议
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
(3)将媒体加到现成讲座中
例如，服务器告诉用户可获得附加媒体内容。这对现场讲座显得尤其有用。如HTTP 1.1中类似，RTSP请求可由代理、通道与缓存处理。
2．协议特点
RTSP有如下特性。
(1) 可扩展性：新方法和参数很容易加入RTSP。
(2) 易解析：RTSP可由标准HTTP或MIME解析器解析。
(3) 安全：RTSP使用网页安全机制。
(4) 独立于传输：RTSP可使用不可靠数据报协议(EDP)、可靠数据报协议(RDP)；如要实现应用级可靠，可使用可靠流协议。
(5) 多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
(6) 记录设备控制：协议可控制记录和回放设备。
(7) 流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会。
(8) 适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
(9) 演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。
(10) 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
(11) HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台(PICS)。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
(12) 适当的服务器控制：如用户启动一个流，必须也可以停止一个流。
(13) 传输协调：实际处理连续媒体流前，用户可协调传输方法。
(14) 性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。
3．扩展RTSP
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP可以如下三种方式扩展：
(1) 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加人要求的段中。
(2) 加入新方法。如信息接收者不理解请求，返回501错误代码，发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
(3) 定义新版本协议，允许改变所有部分(协议版本号位置除外)。
4．操作模式
每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其他途径用户可获得这个文件，它没有必要保存在媒体服务器上。为了说明这个问题，假设演示描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。
下面区分几种操作模式。
(1)单播：用户选择的端口号将媒体发送到RTSP请求源。
(2)服务器选择地址多播：媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。
(3)用户选择地址多播：如服务器加入正在进行的多播会议，多播地址、端口和密钥由会议描述给出。
5．RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
(1) SETUP：让服务器给流分配资源，启动RTSP连接。
(2) PLAY与RECORD：启动SETUP分配流的数据传输。
(3) PAUSE：临时停止流，而不释放服务器资源。
(4) TEARDOWN：释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。
6．与其他协议的关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP。
但是，RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近时，在缓存、代理和授权上采用HTTP功能是有价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。
二. 协议参数
1．RTSP版本
H.321采用，用RTSP代替HTTP。
2．RTSPURL
“rksp"和“rtspu"方案用于指RTSP协议使用的网络资源，为RTSP URL定义方案特定的语法和语义。
3．会议标识
会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何八位组数值。会议标识必须全局惟一。
4．连接标识
连接标识是长度不确定的字符串，必须随机选择，至少要8个八位组长，使其很难被猜出。
5．SMPTE相关时标
SMPTE相关时标表示相对剪辑开始的时间，相关时标表示成SMPTE时间代码，精确到帧级。时间代码格式为小时：分钟：秒：帧。缺省smpte格式是"SMPTE 30"，帧速率为每秒29.97帧。其他SMPTE代码可选择使用smpte时间获得支持(如"SMPIE 25")。时间数值中帧段值可从0到29。每秒30与29.97帧的差别可将每分钟的头两帧丢掉来实现。如帧值为零，就可删除。
6．正常播放时间
正常播放时间(NPT)表示相对演示开始的流绝对位置。时标由十进制分数组成。左边部分用秒或小时、分钟、秒表示；小数点右边部分表示秒的部分。演示的开始对应0.0秒，负数没有定义。特殊常数定义成现场事件的当前时刻，这也许只用于现场事件。直观上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。
7．绝对时间
绝对时间表示成ISO 8601时标，采用UTC(GMT)。
8．可选标签
可选标签是用于指定RTSP新可选项的惟一标记。这些标记用在请求和代理-请求头段。当登记新RTSP选项时，需提供下列信息：
（1）名称和描述选项。名称长度不限，但不应该多于20个字符。名称不能包括空格、控制字符。
（2）表明谁改变选项的控制。如IETF，ISO，ITU-T，或其他国际标准团体、联盟或公司。
（3）深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。
（4）对专用选项，附上联系方式。
三. RTSP信息
RTSP是基于文本的协议，采用ISO 10646字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。文本协议很容易以脚本语言(如：Tcl，Visual Basic与Perl)实现研究原型。
ISO 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定：
(1)不管实体头段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。
(2)如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
(3)服务器关闭连接。
注意，RTSP目前并不支持HTTP 1.1“块”传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，但没有定义任何HTTP代码。
四. 实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体则由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
五. 连接
RTSP请求可以几种不同方式传送：
·           持久传输连接，用于多个请求／响应传输。
·           每个请求／响应传输一个连接。
·           无连接模式。
传输连接类型由RTSP URL来定义。对“rtsp'’方案，需要持续连接；而"rtspu"方案，调用RTSP请求发送，而不用建立连接。
不像HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的惟一途径。
六. 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。已定义方法如表14-03-1所示。
表14-03-1   RTSP方法
方法
方向
对象
要求
含义
DESCRIBE
C->S
P, S
推荐
检查演示或媒体对象的描述，也允许使用接收头指定用户理解的描述格式。DESCRIBE的答复-响应组成媒体RTSP初始阶段
ANNOUNCE
C->S
S->C
P, S
可选
当从用户发往服务器时，ANNOUNCE将请求URL识别的演示或媒体对象描述发送给服务器；反之，ANNOUNCE实时更新连接描述。如新媒体流加入演示，整个演示描述再次发送，而不仅仅是附加组件，使组件能被删除
GET_PARAMETER
C->S
S->C
P, S
可选
GET_PARAMETER请求检查RUL指定的演示与媒体的参数值。没有实体体时，GET_PARAMETER也许能用来测试用户与服务器的连通情况
OPTIONS
C->S
S->C
P, S
要求
可在任意时刻发出OPTIONS请求，如用户打算尝试非标准请求，并不影响服务器状态
PAUSE
C->S
P, S
推荐
PAUSE请求引起流发送临时中断。如请求URL命名一个流，仅回放和记录被停止；如请求URL命名一个演示或流组，演示或组中所有当前活动的流发送都停止。恢复回放或记录后，必须维持同步。在SETUP消息中连接头超时参数所指定时段期间被暂停后，尽管服务器可能关闭连接并释放资源，但服务器资源会被预订
PLAY
C->S
P, S
要求
PLAY告诉服务器以SEFUP指定的机制开始发送数据；直到一些SETUP请求被成功响应，客户端才可发布PLAY请求。PLAY请求将正常播放时间设置在所指定范围的起始处，发送流数据直到范围的结束处。PLAY请求可排成队列，服务器将PLAY请求排成队列，顺序执行
RECORD
C->S
P, S
可选
该方法根据演示描述初始化媒体数据记录范围，时标反映开始和结束时间；如没有给出时间范围，使用演示描述提供的开始和结束时间。如连接已经启动，立即开始记录，服务器数据请求URL或其他URL决定是否存储记录的数据；如服务器没有使用URL请求，响应应为201(创建)，并包含描述请求状态和参考新资源的实体与位置头。支持现场演示记录的媒体服务器必须支持时钟范围格式，smpte格式没有意义
REDIRECT
S->C
P, S
可选
重定向请求通知客户端连接到另一服务器地址。它包含强制头地址，指示客户端发布URL请求；也可能包括参数范围，以指明重定向何时生效。若客户端要继续发送或接收URL媒体，客户端必须对当前连接发送TEARDOWN请求，而对指定主执新连接发送SETUP请求
SETUP
C->S
S
要求
对URL的SETUP请求指定用于流媒体的传输机制。客户端对正播放的流发布一个SETUP请求，以改变服务器允许的传输参数。如不允许这样做，响应错误为"455 Method Not Valid In This State”。为了透过防火墙，客户端必须指明传输参数，即使对这些参数没有影响
SET_PARAMETER
C->S
S->C
P, S
可选
这个方法请求设置演示或URL指定流的参数值。请求仅应包含单个参数，允许客户端决定某个特殊请求为何失败。如请求包含多个参数，所有参数可成功设置，服务器必须只对该请求起作用。服务器必须允许参数可重复设置成同一值，但不让改变参数值。注意：媒体流传输参数必须用SETUP命令设置。将设置传输参数限制为SETUP有利于防火墙。将参数划分成规则排列形式，结果有更多有意义的错误指示
TEARDOWN
C->S
P, S
要求
TEARDOWN请求停止给定URL流发送，释放相关资源。如URL是此演示URL，任何RTSP连接标识不再有效。除非全部传输参数是连接描述定义的，SETUP请求必须在连接可再次播放前发布
注：P----演示，S----流，C----用户端，S----服务器端
  
某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并增加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据(如RTP包)用一个ASCII字符$封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。
当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP／RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
七. 流水线操作
支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给多播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间(RTT)后重发同一信息。
在TCP中RTT估计的初始值为500ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输(如TCP和RTSP)应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
实现RTSP的系统必须支持通过TCP传输RTSP，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不像HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。
第 4 节   RSVP 协议
资源预订协议(RSVP)是网络控制协议，它使Internet应用传输数据流时能够获得特殊服务质量。RSVP属OSI七层协议栈中传输层，它不是路由协议；它同路由协议协同工作，建立与路由协议计算出路由等价的动态访问列表。图14-04-1说明了RSVP运行环境。
图14-04-1  RSVP中主机信息通过数据流发送给接收者示意图   
一. RSVP数据流
在RSVP中，数据流是一系列信息，它们有着相同的源、目的(可有多个)和服务质量（QoS），而QoS要求通过网络以流说明形式通讯。流说明是互连网主机用来请求特殊服务的数据结构，保证互连网处理主机传输。RSVP支持三种传输类型：尽力(best-effort)递交，速率敏感(rate-sensitive)，延迟敏感(delay-sensitive)。用来支持这些传输类型的数据流服务依赖QoS实施，
尽力递交为传统IP传输。包括文件传输(如邮件传输)、磁盘映像、交互登录和事务传输等应用。支持尽力递交的服务称为尽力递交服务。
速率敏感传输放弃及时性，而确保速率。例如，速率敏感传输请求100kbps带宽，如在扩展期实际发送200kbps，路由器可能延迟传输。速率敏感传输目的不在通过电路交换网络传输，但它通常与电路交换网络(ISDN)应用有联系，现在正运行在数据报网络(IP)上。这类应用如H.323视频会议，设计运行在ISDN(H.320)或ATM(H.310)上，但发现在Internet上也有应用。H.323编码是常数速率或准常数速率，它需要常数传输速率。RSVP服务支持速率敏感传输，称为位速率保证服务。
延迟敏感传输要求传输及时，并因而改变其速率。例如，MPEG-2视频根据图像改变量大小平均流量为3~7Mbps，3Mbps可能对应一堵上色的墙，而7Mbps可能是海洋的波浪。MPEG-2视频源发送关键帧和增量帧。典型情况下，每秒一个或两个关键帧来描述整个图像，而每秒13或28帧描述关键帧之间的变化，增量帧通常比关键帧小。因此，帧与帧之间速率变化较大。但由于单个帧要求在一帧时间内发送出去，或解码器速度跟不上，必须对增量帧传输进行特定优先级别协调。RSVP服务支持延迟敏感传输，被看作控制延迟服务(非实时服务)与预报服务(实时服务)。
二. RSVP数据流处理
RSVP数据流基本特征是连接，数据包在其上流通。连接是具有相同单播或多播目的的数据流，RSVP分别处理每个连接。RSVP支持单播和多播连接(这里连接是一些发送者与另一些接收者的会话)，而流总是从发送者开始的。特定连接的数据包被导向同一个IP目的地址或公开的目的端口。IP目的地址可能是多播发送的组地址，也可能是单个接收者的单播地址。公开目的端口可用UDP／TCP目的端口段、另外传输协议等价段或某些应用特定信息定义。
RSVP数据发布是通过多播或单播实现的。多播传输将某个发送者的每个数据包拷贝转发给多个目的。单播传输特征是只有一个接收者。即使目的地址是单播，也可能有以公共端口区分的多个接收者。多个发送者也可能存在单播地址，在这种情况下，RSVP可建立多对一传输的资源预订。每个RSVP发送者和接收者对应惟一的Internet主机。然而，单个主机可包括以公共端口区分的多个发送者和接收者。
(1) RSVP服务质量
在RSVP中，服务质量(QoS)是流规范指定的属性，流规范用于决定参加通信的实体（路由器、接收者和发送者）进行数据交换的方式。主机和路由器使用RSVP指定QoS，其中主机代表应用数据流使用RSVP从网络申请QoS级别，而路由器使用RSVP发送QoS请求给数据流路经的其他路由器。这样做，RSVP就可维持路由器和主机状态来提供所请求的服务。
(2) RSVP连接启动
为了初始化RSVP多播连接，接收者首先使用Internet组成员协议(IGMP)加入IP目的地址指定的多播组。对单播连接，单播路由就像IGMP结合协议无关多播(PIM)在多播时的作用。接收者加入组后，潜在的发送者就开始发送RSVP路径信息给IP目的地址。接收者应用收到路径信息，开始发送相应资源预订请求信息，使用RSVP指定欲点播的流描述。发送者应用接收到资源预订请求信息后，发送者开始发送数据包。
三. RSVP资源预订类型
资源预订类型指一套指定所支持参数的控制选项。RSVP支持两种主要资源预订：独占资源预订和共享资源预订。独占资源预订为每个连接中每个相关发送者安装一个流；而共享资源预订由互不相关的发送者使用。表14-04-1说明这两种资源预订协议的应用范围及所支持的范围与类型的组合情况。   
    表14-04-1  RSVP支持的资源预订
范围
资源预订类型
独占
共享
显式
固定过滤（FF）
共享显式（SE）
通配
未定义
通配过滤（WF）
  (1) 通配过滤类型
通配过滤类型(WF)以通配符指定共享预订。这时资源预订可看作共享管道，其大小是所有接收者连接请求资源的最大值，与发送者数量无关。资源预订随发送者主机扩展，并随新发送者加入而自动扩展。
(2) 固定过滤类型
固定过滤类型(FF)指定显式范围的独占资源预订。对FF类型资源预订，独占资源预订请求是数据包从特殊发送者处创建的。资源预订范围由发送者显式列表决定，对给定连接的总资源预订是所有请求发送者的FF资源预订的总和。同一发送者的不同接收者请求的FF资源预订必须合并为共享所给节点的单个资源预订。
(3) 共享显式类型
共享显式类型(SE)以显式资源预订范围指定共享资源预订环境。如同FF一样，发送者设置由作出资源预订的接收者显式指定。
(4) RSVP资源预订类型含义
WF与SE都是共享资源预订，适用于多播应用，那些应用的特定约束使多个数据源不能同时发送。例如，语音会议中同时讲话的人数目有限。每个接收者可能对一个语音通道发送两次WF或SE资源预订请求。FF类型给不同发送者流建立独立的资源预订，它更适合于视频信号。不足的是不能把共享资源预订与独占资源预订结合起来。
四. RSVP软状态实现
对RSVP，软状态指可被某些RSVP信息更新的路由表和终端节点的状态。软状态特征允许RSVP网络支持动态组成员变化，并适应路由变化。一般说来，软状态由基于RSVP网络维护，使网络可在没有查询终端节点的情况下改变状态。对比电路交换结构，终端节点进行依次呼叫，如失败，进行依次新呼叫。
RSVP协议为创建和维护多播和单播混合发送路径的分布式资源预订状态提供了一个通用功能。为维护资源预订状态，RSVP跟踪路由器和主机节点的软状态。路径与资源预订请求信息创建并周期更新RSVP软状态。如果在清除时间间隔到期前没有收到相应更新信息，就删除该状态，显式teardown信息也可删除软状态。RSVP周期扫描欲建立的软状态，并转发路径与预订请求更新信息给下一跳。
当路由改变，下一个路径信息初始化新路由的路径状态，将来的资源预订请求信息建立资源预订状态。现在未使用的网段状态标记为超时（RSVP规范要求在拓扑改变后两秒通过网络初始化新资源预订）。当发生状态变化，RSVP无延迟地将变化从RSVP网络的一个终端传到另一个终端。如接收到的状态与存储状态不同，就更新存储状态。若结果改变了欲产生的更新信息，更新信息立即生成并转发出去。
五. RSVP操作模型
在RSVP下，资源为简单数据流(单向数据流)预订起来。每个发送者逻辑上与接收者不同，但任何应用都可充当发送者和接收者，接收者负责请求资源预订。图14-04-2说明了其基本操作环境，紧接部分将提供特定事件序列的框架。
   
  图14-04-2  RSVP操作环境：为单向数据流预订资源   
1．基本RSVP协议操作
RSVP资源预订处理初始化开始于RSVP后台服务查询本地路由协议以获得路由。主机发送IGMP消息加入多播组，而发送RSVP消息预订沿组路径的资源。每个能加入资源预订的路由器将收到的数据包传递给包分类器，然后将它们在包调度器中排队。RSVP包分类器决定每个包的路由和QoS类，RSVP调度器给每个接口所使用的特殊数据链路层媒介上的传输分配资源。如果数据链路层媒介有自身的QoS管理能力，包调度器负责协调数据链路层，获得RSVP所请求的QoS。调度器本身分配无源QoS媒介上包传输能力，如双铰线；也可分配其他系统资源，如cpu时间与缓存。QoS请求一般发源于接收者主机应用，而被传递到本地RSVP应用，如RSVP后台服务。RSVP协议接着将对所有节点(路由器与主机)的请求沿逆向数据路径传到数据源。在每个节点处，RSVP程序应用一个称为进入允许控制的本地决定程序决定是否能提供所请求的QoS。如进入允许控制成功，RSVP程序设置包分类和调度器的参数，以获得所申请的QoS。如果进入允许控制在某节点处失败，RSVP程序给产生此请求的应用返回一个错误指示。
2．RSVP隧道
在整个Internet上同时配置RSVP或任意其他协议都是不可能的。实际上，RSVP决不可能在每个地方都被配置。因此，即使只有两个支持RSVP的路由器与一群不支持RSVP的路由器相连，RSVP也必须提供正确协议操作。一个中等规模不支持RSVP的网络不能执行资源预订，因而服务保证也就不能实现。然而，如该网络有充足额外容量，也可以提供可接受的实时服务。
为了支持RSVP网络连接通过不支持RSVP的网络，RSVP支持隧道技术。隧道技术要求RSVP和非RSVP路由器用本地路由表转发到目的地址的路径信息。当路径信息通过非RSVP网络时，路径信息拷贝携带最后一个支持RSVP的路由器的IP地址。预订请求信息转发给下一个上游支持RSVP的路由器。
六. 加权平均排队方案
用技术来加强出现瓶颈处的有效资源预订(如Cisco的加权平均排队方案)有着正面影响。仅当瓶颈发生在非RSVP域、且不可避免时隧道技术才有风险。图14-04-3表示基于RSVP网络间采用隧道技术的RSVP环境。
  
图14-04-3   应用隧道技术的RSVP环境   
七. RSVP消息
RSVP支持资源预订请求消息、路径消息、错误与确认消息以及断开消息四种基本消息类型。每种消息描述如下。
1．资源预订请求消息
资源预订请求消息是每个接收者逐级发送给发送者的。此消息逆着数据包使用的路由到达发送者主机。资源预订请求信息必须发送到发送者主机，以便主机为首跳（hop）设置相应传输控制参数。RSVP不发送任何肯定确认消息。
2．路径消息
RSVP路径消息由每个发送者沿路由协议提供的单播或多播路由发送，用来存储每个节点的路径状态，路径状态用于逆向路由资源预订请求消息。
3．错误与确认消息
有三种错误与确认消息，即路径错误消息、资源预订请求错误消息和资源预订请求确认消息。路径错误消息来自于路径消息，向发送者传输，使用路径状态一跳一跳地进行路由。在每一跳，IP目的地址是前一跳的单播地址。资源预订请求错误消息来源于资源预订消息，向接收者传输，使用资源预订状态一跳一跳地进行路由。在每一跳，IP目的地址是下一跳节点的单播地址。
错误消息包括如下信息：
·           进入允许出错
·           带宽不可获得
·           服务不被支持
·           无效流说明
·           模糊路径
资源预订请求确认消息是资源预订消息中出现资源预订确认对象时发送的，消息包括一份资源预订确认拷贝。确认消息发到接收者主机的单播地址，地址可从资源预订确认对象得到。资源预订请求确认消息一跳一跳地转发到接收者。
4．断开消息
RSVP断开消息删除路径和资源预订状态，而不用等到清除超时。断开消息可被终端系统(发送者或接收者)或到达状态超时的路由器初始化。RSVP支持路径断开消息与资源预订请求断开消息两种类型断开消息，前者删除路径状态，从初始点开始向下游接收者传输，并像路径消息一样路由；后者删除资源预订状态，从断开起始点向上游所有匹配发送者传输，并向相应资源预订请求消息路由。
八. RSVP包格式
图14-04-4说明了RSVP包格式。  对象字段见图14-04-5。
   
图14-04-4   RSVP包格式
图14-04-5   RSVP对象字段
下面说明RSVP包格式的头和对象段。
1．RSVP消息头段
RSVP消息头段组成：
1）版本号：4位，表示协议版本号（当前版本为1） 。
2）标志：4位，当前没有定义标志段。
3）类型：8位，有几种可能值，如表14-04-4所示。
表14-04-4   RSVP消息类型值
值
消息类型
1
路径
2
资源预订请求
3
路径错误
4
资源预订请求错误
5
路径断开
6
资源预订断开
7
资源预订请求确认
4）校验和：16位，表示基于RSVP消息的内容上标准TCP／UDP校验和。
5）长度：16位，表示RSVP包的字节长度，包括公共头和随后的可变长度对象。如设置了更多片段（MF）标志，或片段偏移为非零值，这就是较大消息当前片段长度。
6）发送TTL（Time to live，存活时间）：8位，表示消息发送的IP生存期。
7）消息ID（标识）：32位，提供下一RSVP跳／前一RSVP跳消息中所有片段共享标签。
8）更多片段（MF）标志：一个字节的最低位，其他7位用于预订。除消息的最后一个片段外，都将设置MF。
9）片段偏移：24位，表示消息中片段的字节偏移量。
2．RSVP对象段
RSVP对象段组成如下：
1）长度：16位，包含总对象长度，以字节计(必须是4的倍数，至少是4)。
2）分类号：表示对象类型，每个对象类型都有一个名称。RSVP程序必须可识别分类，类型在表14-04-5列出。如没有识别出对象分类号，分类号高位决定节点采用什么行动。
3）C-类型：在分类号中惟一。最大内容长度是65528个字节。分类号和C-类型字段(与标志位一起)可用作定义每个对象惟一性的16位数。
4）对象内容：长度、类型号和C-类型段指定对象内容的形式。
表14-04-5  RSVP对象类型
对象类型
说明
Null
类型号为0，C-类型被忽略。长度必须是4的倍数，至少为4，空对象可出现在一系列对象中，其内容被接收者忽略
Session
包含IP目的地址，如可能，还包括公共目的端口，用来定义对其他对象的特定连接(在RSVP消息中是必须的)
RSVP Hop
携带发进此消息的支持RSVP节点的IP地址
Time Values
如存在，包含更新时期和TTL状态以覆盖缺省值
Style
定义资源预订类型，外加类型特定信息，这些特定信息不是流规范或过滤器规范对象(包含在资源预订请求消息中)
Flow Specification
定义所要求的QoS(包含在资源预订请求消息中)
Filter Specification
定义连接数据包的一个子集，它应该收到所要的QoS(由资源预订请求消息中流说明对象指定)
Sender Template
包含发送者IP地址，也许还有一些附加识别发进者的多路分解信息(包括在路径消息中)
Sender TSPEC
包含发送者数据流的传输特性(包括在路径消息中)
Adspec
在路径消息中携带通知数据
Error Specification
说明一个错误（包含在路径错误或资源预定请求错误消息中）
Policy Data
携带使本地策略模块决定是否允许相关资源预订的消息（包含在路径错误或资源预定请求错误消息中）
Integrity
包含授权初始节点的密文数据，有时还有确认资源预定请求消息内容的数据
Scope
为转发资源预订消息制定的一个显式范围规范
Reservation Confirmation
携带请求确认的接收者IP地址，可能出现在资源预订请求或资源预订确认中
九. 演示
RSVP演示
十. RSVP小结
RSVP运行在传输层，在IP上层。与ICMP和IGMP相比，它是一个控制协议。RSVP 的组成元素有发送者、接收者和主机或路由器。发送者负责让接收者知道数据将要发送，以及需要什么样的QoS；接收者负责发送一个通知到主机或路由器，这样他们就可以准备接收即将到来的数据；主机或路由器负责留出所有合适的资源。
RSVP协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征，通过IP包中“流标记”来鉴别。发送一个流前，发送者传输一个路径信息到目的接收方，这个信息包括源IP地址、目的IP地址和一个流规格。这个流规格是由流的速率和延迟组成的，这是流的OoS需要的。接收者实现预定后，基于接收者的模式能够实现一种分布式解决方案。
RSVP领域的发展是非常迅速的，但目前并没有在任何一种网络上得到证实，它的应用只是局限在测试的小Intranet网络上。因为RSVP的预定必须建立在完全流方式的基础上，其可扩展性问题倍受关注。RSVP还存在诸如当一个服务请求被申请控制否决时网络应该怎样通知用户以及用户怎样应答这样的通知等问题。
第5节 区分服务
区分服务（DiffServ）是IETF工作组为了克服IntServ的可扩展性差而提出的另一个服务模型，目的是制定一个可扩展性相对较强的方法来保证IP的服务质量(QoS)。
与DiffServ有关的因特网草案（Internet-Drafts）有：
An Informal Management Model for Diffserv Routers
Management Information Base for the Differentiated Services Architecture
New Terminology and Clarification for Diffserv
Differentiated Services Quality of Service Policy Information Base
An Assured Rate Per-Domain Behaviour for Differentiated Services
与DiffServ有关的RFC（Request For Comments）有：
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (RFC 2474)
An Architecture for Differentiated Services (RFC 2475)
Assured Forwarding PHB Group (RFC 2597)
Differentiated Services and Tunnels (RFC 2983)
Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification (RFC 3086)
Per Hop Behavior Identification Codes (RFC 3140)
An Expedited Forwarding PHB (RFC 3246)
Supplemental Information for the New Definition of the EF PHB (RFC 3247)
A Delay Bound alternative revision of RFC2598 (RFC 3248)
一．实现说明
当数据流由客户进入DiffServ域(如域A)时，边缘路由器通过标识该字段，将IP包首先分为不同的服务类别，而网络中的其他传送转发路由器在收到该IP包时，则根据该字段所标识的服务类别将其放入不同的队列，并且由作用于输出队列的流量管理机制控制每一个队列，即给予不同的每一跳行为(PHB)。
其中最主要的就是对每个队列给出带宽分配，以及发生阻塞时如何丢包，这些资源的分配规则都是预先设定好的。
在DiffServ域中，路由器大致可以分为两类：
·边缘路由器；
·传送路由器(核心路由播)。
其中传送路由器只负责将进入的数据包按级别排队，并按事先设定的带宽、缓冲处理输出队列。
边缘路由器除了完成上述功能以外，还在输入接口处设有检查机制以监视用户是否遵守业务等级协定(SLP)，分类机制以标识输人的每个业务包，并将其分别排入相应的队列。
二．DiffServ模型的优缺点
DiffServ的设计思想是希望使用一种与目前lP网络协议相结合的方式来实现对网络QoS的保证，因此其实现要比使用端到端控制的IntServ简单，网络额外负担也较小。现在IETFRSVP和DiffServ两个工作组都正在研究RSVP与DiffServ相结合的问题，以进一步扩大DiffServ与现有系统的可兼容性。
DiffServ模型本身也还不完善。首先它并不提供全网端到端的服务质量保证，尚需进一步明确和开展的研究包括：
(1)  业务分类的具体划分实现；
(2)每个业务性能的量化描述；
(3)IP的业务类型与ATM QoS的映射等。
以上所有文件还未形成真正的标准（ 即RFC文档）。要实现对IP网络的QoS保证尚处于研究和实验阶段。国内外都对它抱有很大的希望，美国100多所大学参加的Internet2工程已经把DiffServ模型推向QoS测试网，一般称为QBone，可望不久的将来能展示出一个全新的网络。
三．区分服务在Internet2中
Internet2是由美国170所大学和公司与美国政府合作，由UCAID(University Corporation for Advanced Internet Development)发起，为新一代网络技术开发和设计的下一代Internet的高速实验网。 Internet2基于美国高速骨干网之一的Abilene。Abilene和vBNS、ESNet等高速网络成为美国Internet2和下一代Internet（NCI，Next Generation Internet）的主要网络。初期，Internet2的主干网络Abilene由13000英里2.4Gbps的SONET(Synchronous Optical Network)连接50所大学和3家公司，核心路由器和交换机使用Cisco公司12000路由交换机，逐渐发展到10Gbps的高速网连接150所大学。
Internet2的主要目标是为大学和研究机构提供满足新一代高速网络应用要求的研究测试平台。提供支持的主要应用包括：
(1)双向交互式的语音／图像服务；
(2)虚拟合作环境；
(3)高保密性的音／视频流；
(4)远程设备控制(如显微镜，探测仪)；
(5)大数据量传输。
在此基础上，Interaet2的最终目标是高速网络应用普及化。作为下一代Internet的实验网和雏形，Internet2力求加速新一代网络技术的研究，同时，新技术也不断改进和促进Internet2的发展。
Internet2主要是针对当前Internet带宽不足，无法进行大量新型网络技术的研究与测试等问题而设计的。当前网络新技术的研究主要集中在网络边缘，而对于核心部分的研究则受到很大程度的限制。为此，Internet2推出了称为"QBone"的测试网。
QBone是由多播骨干网MBone(Multicast Bone)和6Bone(IPv6 Bone)发展起来的，也称为域间(InterDomain)网。MBone是IETF(Internet Engineering Task Force)提出的Multicast主干网(Multicast Bone，筒称MBone)，它是一个集成到Internet中的网络，能在与MBone直接相连的主机之间提供实时的多播，多播可应用到许多多媒体应用系统，如音／视频会议、分布式交互仿真、分布式数据库更新以及电子商务等。1998年，IETF为了提供IP QoS测试网推出QBone。主要目标是为了在QBone上实现如远程控制、分布式协作、虚拟教学等网络新技术的测试。QBone采用IETF提出的区分服务(DiffServ)模型来提供IP QoS保证，QBone则为DiffServ提供跨域(InterDomain)的测试环境。
四．区分服务框架模型
区分服务在实现上由每跳行为（PHB，Per Hop Behavior）、包的分类机制和流量控制功能(测量、标记、整形、策略控制)三个功能模块组成。区分服务实现可扩展性的重要策略是在网络中心节点只进行转发操作，将分类和大部分流控的复杂性操作转移到了网络边缘节点。同时，将同类的流聚集传输，避免了大量的流状态信息的保存，大大降低了网络实现的复杂性和网络负荷。区分服务的模型可由图14-05-1表示。
图14-05-1  DiffServ的结构模型示意图  
区分服务的基本思想是在网络边缘将进入的流分成各种不同的类型，将同种类型的流合并起来进行集束传输，并对每一种类型在网络中分别进行处理。分类的工作在网络的入口处进行，分类通过检查包的一个或多个字段的内容来完成。包被标识为一定的服务类型，并记录在包头字段里，随后将包按一定的流量控制策略送入网络。网络中转发包的核心路由器通过检查包头来确定对包进行何种处理。每种服务类型都要给予不同的处理方式，以获得相应的服务质量。核心路由器对包所做的处理包括将包置入哪一种队列，网络拥塞时以何种丢包策略对包进行丢弃等。
(1)区分服务中的标记分类机制
区分服务中传输的是流聚集而不是单个的流，每一组流聚集都具有相应的各自不同的流传输服务标准，在各个域内部根据不同的媒体传输要求提供不同的传输服务。这一过程是通过区分服务中IP包头的区分服务标记字段(DS Field)来实现的，DS的标记字段在IPv4中定义在包头的TOS字节，在扩展的IPv6中定义在包头的流类型字节（Traffic Class Octet）的前六位。DS标记字段对应相应传输媒体的PHB。
传输分类的过程是在边界节点上进行的，边界节点查询DS标记字段并将其归入某一特定的流聚集中。DS模型中边界调节分类的部分主要包括：
接纳控制(Admission Control)，判断是否有足够的资源来支持相应类型的控制。
包分类器(Packet Classifier)，确定源地址、目的地址、端口字段，判断包的类型。
包调度器(packet Scheduler)，用来调度包的发送。在调度器中，负责主要的包流量的整形与调度，提供标记器(Marker)、计量器(Meter)、丢包器(Dropper)三部分。由标记器对IP包头进行标记，计量器和丢包器主要进行排队发送等工作，如图 14-05-2 所示。
图14-05-2  边界分类机制示意图  
计量器和丢包器已经有了许多比较成熟的调度算法，对于IP实现QoS而提出的几个较重要的算法及其思想将在下面“区分服务中的调度算法”中进行介绍。
(2)区分服务中的PHB
PHB是一个DS节点调度转发处理包头标有DS标记的IP包流的外部行为描述。在DS字段内，转发节点是按照PHB来进行的，在每一传输段逐段保证PHB行为是区分服务的最大特点，也是区分服务分段保证端到端QoS的基础。PHB可以用一系列流的参数特性包括延迟、抖动、优先级等来描述。由于不同的PHB流同时传输，因而就存在流的竞争问题。当前边界节点与内部节点中流聚集的竞争与公平性问题一直是研究的热点问题。与多媒体传输中自适应思想相结合的调节方法将是发展的趋势。
IETF已经标准化了一部分PHB，包括BE（Best Effort）、加速型转发（EF，Expedited Forwarding）、确保型转发（AF，Assured Forward)及兼容IP优先级的类型选择型（CS，Class Selecter）四种。
五．区分服务中的调度算法
在基于IP的网络中实现QoS的重要途径是确定良好的包调度与流控制算法。区分服务中的流调度机制实现于边界节点的调度器和中间节点的丢包器，目前对提出的调度算法已经有了许多改进算法。下面针对区分服务的特点就较成熟的令牌桶过滤器(Token Bucket Filter)、基于权的公平队列算法(WFQ，Weighted Fair Queuing)、RED(Random Early Detection)算法、Two-Drop过程算法和Three-Drop过程算法等5种在IP QoS中的常用算法进行讨论。
(1)令牌桶过滤器
这一算法是由Clark，Shenker和Zhang在其关于包交换网支持实时网络流的论文中提出的，如图14-05-3所示。其基本思想是：指定一个大小为B的令牌桶，当包到达时，从桶中减去一定数量的令牌。除非桶中有足够数量的令牌，否则就不能被发送。因此，控制发送端包的发送数量≤B，若流量源以小于等于R的速率发送包，称其为遵守令牌过滤器的参数，因此容易理解由令牌过滤器规划的网络，因为遵守流量就应满足R(t)≤B(对于任何时间增量为t而言)。实现上主要考虑怎样处理不遵守流量的数据流。令牌桶已被用在许多路由器的实现中。
图14-05-3 令牌桶过滤器  
(2)基于权的公平队列算法
WFQ算法用来控制由路由器交换机向外发送数据包，每一个包是基于时间戳的，规定其到达、发送时间，以及它们的长度。WFQ调度器的发送队列记录每一个包的到达时间，使得时间戳最小的包先发送。根据权值变量，允许某些特定的流能够得到比其他流更多的带宽。另外，WFQ是工作存储（Work-Conserving）的，就是说路由器将会不间断地发送当前的包而使链路不处于空闲状态。以上两点保证了WFQ调度器成为支持实时流量的理想算法。但研究同时表明，WFQ调度算法也存在一些问题，如带宽利用不足、带宽／时延耦合、流量特性扭曲、流量粒度过细等；提出了一些新的改进算法，如W2FQ等。
(3)RED算法
RED算法是针对DiffServ模型展开的主要研究算法，如图14-05-4所示，也是使用最为广泛的一种。RED是针对FIFO分组调度算法进行分组缓冲管理和丢弃机制，其特点是通过丢弃规则丢弃分组，使得路由器的排队队列最短。其工作参数为两个阈值MINth，MAXth和一个最大丢弃概率Pmax。当缓冲排队长度小于MINth时，不对进入的分组进行丢弃；当缓冲排队长度大于MAXth时，丢弃所有进入分组；而当缓冲排队长度S在两阈值之间时，以概率((S-MINth)／(MAXth-MINth))Pmax对进入的分组进行丢弃。现在已经出现了一些RED的改进型算法，如DWRED、GRED等。
图14-05-4  RED  
(4)Two-Drop过程算法和Three-Drop过程算法
此算法源于RIO网络。在RIO网络中，网络边缘设备控制并标记进入的单个或聚集流包，若包到达时的发送速率在定义的范围以内，包被标志为IN，否则被标记为OUT。当前的发送速率用时间滑动窗口（TSW，Time Sliding Windows)或者用一个令牌桶控制器(Token Bucket Controller)来测量核心路由器为IN和OUT各保持一个物理队列。当发生拥塞时，首先丢弃OUT包，若仍然有拥塞则开始丢弃IN包。这种策略优先IN包可以为用户提供不同级别的相应服务。Three-Drop过程算法如图14-05-5所示，是在Two-Drop过程算法的基础上进行的扩展，将每一个包标记为红、绿、黄三种颜色。通常黄色代表的预留速率大于绿色代表的预留速率，绿色代表的预留速率大于红色代表的预留速率。用更细的分级获得更好的执行控制效果。同时，一些基于X-Drop的算法采用Two-Drop和Three-Drop的思想，通常被称为Multi-Drop过程，X-Drop过程的思想被广泛地采纳于DiffServ的实现当中。
图14-05-5  Three-Drop过程算法  
以上讨论的是针对IP QoS而设计的一些算法。流量整形是DiffServ当中重要的组成部分，因而良好的整形算法对于保证良好的服务质量至关重要。在实际应用当中，往往是使用以上算法的基本思想，而采取多种方法相结合的方式来进行流量管理，特别是在DiffServ公平性方面的研究更是促进了以上各种算法的发展和丰富。
第5节 流应用
网上广播是当前Internet上流行的一种应用（图14-06-1）。目前，在Internet上应用较广泛的流式媒体包括：RealNetworks公司的SureStream技术、Macromedia公司的Shockwave技术、MetaCreations公司的MetaStream技术以及Apple公司的QuickTime技术等。
图14-06-1  网上广播
RealPlayer支持的RealAudio和RealVideo是美国RealNetworks公司开发的网络广播技术中用于传输声音和图像的文件的格式，接下来将具体介绍一下以RealSystem G2为基础的网上广播系统。
RealNetworks公司的RealSystem由内容制作工具(RealProducer)、服务器端软件(RealServer)和客户端软件(RealPlayer)三部分组成。
RealProducer是一个编码、压缩转换工具。用来制作Real视频、音频文件。
主要功能：
·           将常见格式视音频文件转换成RealNetworks公司的rm流格式文件。
·           能够将视频捕捉卡捕获的影像实时地压缩转换成直播信息流（或者rm流格式文件），然后送到RealServer服务器，实现直播。
RealProducer 特性
·           高质量的声音：使用RealProducer可以压缩生成的高质量的声音文件，其效果接近CD的音质。其占用的带宽范围是12Kbps到352Kbps。
·           生成高品质的视频
·           可以模拟用户的观看效果
·           支持多平台：RealProducer现在可以运行在Windows, Macintosh, Linux 和 Solaris平台上.
RealServer软件
   RealServer软件包含以下的组成部分：
o  执行程序 - 这是RealServer软件的最主要部分，在windows平台叫做rmserver.exe，在UNIX平台叫做rmserver.
o  Plug-ins - 这些插件提供Realserver的功能特征。由于是采用开放式的体系结构，用户可以自己增加realserver的功能特征。
o  设置文件 - rmserver.cfg ,基于XML格式的文本文件，保存realserver的所有设置信息。
o  系统管理 - 基于WEB的管理控制台，用来管理和监视realserver。
o  工具文件 - Java监视器，G2SLTA
o  其他文件 - 根据用户安装情况，会有其他的一些文件用来增强RealServer的功能。
RealSystem所使用的通道和协议
o  使用两种通道与客户端软件realplayer通讯：一种是控制通道，用来传输诸如“暂停”、“前进”等命令，使用TCP协议；另一个是数据通道，用来传输实际的媒体数据，使用UDP协议。
o  主要使用两个协议来与客户端联系： RTSP (Real Time Streaming Protocol) 和 PNA (Progressive Networks Audio).
Encoder与RealServer之间的通讯
当Encoder需要向RealServer传输压缩好的数据时，通常使用one-way(UDP)与RealServer通讯。而一些防火墙通常禁止UDP数据包通过，因此，RealProducer可以设置成使用TCP协议的方式向服务器传输数据。
RealServer与RealPlayer之间的通讯
当用户在浏览器上点击一个指向媒体文件的链接时，Realplayer打开一个与RealServer的双路连接，通过这个连接与RealServer之间来回传输信息（图14-05-2）。
图14-05-2 双路连接
一旦RealServer接受了客户端的请求，它将通过UDP协议传输客户请求的数据（图14-05-3）。
图14-05-3 双路连接响应
RealServer支持的文件格式（表14-06-1）
表14-06-1 RealServer支持的文件格式
Audio File Types
RealAudio, WAV, AU, MPEG-1*, MPEG-2*, MP3*
Video File Types
RealVideo, AVI, QuickTime
Other File Types
RealPix, RealText, GIF, JPEG, SMIL, Real G2 with Flash
*MPEG-1, MPEG-2, and MP3 需要另外的插件
值得一提的是在RealSystem G2系统中为网上现场直播使用了一种新的称为SureStream的技术，能让RealServer和 RealPlayer动态地根据网络带宽进行沟通、调整。使用SureStream技术，在信号源方面，RealEncoder可以将声音或图像数据按好几种压缩比率进行编码，并对RealServer和 RealPlayer按合适的数据压缩比率进行传输。在一个RealSystem G2系统中，编码软件RealEncoder生成多种带宽的数据流，当一个接收进程RealPlayer G2连接一个能提供可调带宽内容的服务器RealServer时，RealServer会自动侦测该RealPlayer的连接速度，并按该速度提供相应匹配的最好的数据流。当该RealPlayer的网络连接出现数据包丢失现象时，RealServer就会转向传递更低带宽的数据流。这虽然会导致音质的下降，但消除了抖动、发嘶、重新连接等现象。当该RealPlayer的连接速度上升后，服务器会转向提供更高带宽的数据流。而且这中间发生的转换过程是瞬间完成的，节目的接收没有中断或间隔。
RealPlayer则负责将传输过来的Real格式的音频或视频数据流播放出来，所以只要在客户端安装了RealPlay G2播放器，就可以接收到精彩的广播电视节目。
Realplayer播放过程
1.       浏览器通过HTTP协议向RealServer服务器发出请求，URL请求中包含激活RAMGEN的参数。
2.       指向被请求SMIL文件的URL引发RAMGEN自动产生一个包含SMIL文件位置的RAM文件，这个RAM文件将被传送给浏览器。
3.       RAM文件的扩展名（.ram 或者.rpm）将使得浏览器激活RealPlayer程序。
4.       RealPlayer接受浏览器传递过来的RAM文件，然后用RTSP协议与RealServer进行通讯，请求该RAM文件中包含的SMIL文件。
5.       根据在SMIL文件中包含的信息，Realplayer向RealServer请求、接受并播放媒体元素。
图14-05-4  Realplayer播放过程
〖参考文献〗
P.K. Andleigh & K. Thakrar, "多媒体系统设计（Multimedia System Design）", 徐光佑、史元春译，电子工业出版社, 1998.
F. Kuo & W. Effelsberg, "Multimedia Communication: Protocols And Applications", Prentic Hall, 1997.
Ralf Steinmetx & Klara Nahrstedt，《多媒体技术：计算、通信和应用》，潘志庚、叶绿、耿卫东等译，清华大学出版社，2000。
林福宗,《多媒体技术基础》,清华大学出版社，第2版，2002年8月。
蔡安妮，孙景鳌编著，《多媒体通信技术基础》，电子工业出版社，2000年8月。
黄孝建编著，《多媒体技术》，北京邮电大学出版社，2000年9月。
胡晓峰，吴玲达，老杨松，司光亚编著，《多媒体技术教程》，人民邮电出版社，2002年1月。
张丽，《流媒体技术大全》，中国青年出版社，2001年。
〖相关网站〗
清华大学林福宗《多媒体技术基础》
http:www.tsinghua.edu.cn/

http://www.ietf.org/html.charters/diffserv-charter.html

http://www.internet2.edu/

http://www.internet2.edu/abilene/

http://kabru.eecs.umich.edu/qos_network/diffserv/DiffServ_Ref.html
〖练习和思考题〗
支持流媒体的协议有哪些?
试说明RTP与RTCP的关系。
试比较RTP和RTSP，说明有何不同。
叙述RVSP的操作模型，说明它是怎样进行资源预订的。
举例说明音频和/或视频数据流的播放过程。



本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/6384/showart_139952.html