一、RTP传输协议
二、RTCP数据传输控制协议
三、 RTSP实时流媒体协议
四、 RSVP资源预留协议
-------------------------------------------------------------------------------------------------------------------
流媒体实现的关键技术是流式传输，因此，流媒体传输协议无疑成为流媒体技术的重中之重，流媒体协议的设计和制定是为了实现流媒体服务器和客户端的通讯。在流媒体传输中，标准的协议是RTP（Real-time Transport Protocol,实时传输协议）、RTCP（Real-time Transport Control Protocal,实时传输控制协议）、RTSP（Real Time Streaming Protocal,实时流媒体协议）和RSVP（ReSource reserVe Protocol,资源预定协议）。
实时传输协议RTP是针对在互联网上进行媒体数据流传输而提出的，它的目的是提供时间信息和实现流同步。RTP是最典型、最广泛的服务于流媒体的传输层协议。RTP可以在一对一或一对多的传输情况下工作。RTP可以在UDP、TCP或ATM等其他协议之上工作。
实时传输控制协议RTCP和RTP一起提供流量控制和拥塞控制服务。
实时流协议RTSP是由Realnetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
RSVP是互联网上的资源预定协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS，它使Internet应用传输数据流时能够获得特殊服务质量。
一、RTP传输协议
RTP(Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当RTP工作于一对多的传输情况下时，依靠底层网络实现组播，利用RTP over UDP模式实现组播的传输就是其典型应用。RTP传输协议有如下一些特点：
1、协议灵活性
RTP协议不具备运输层协议的完整功能，其本身也不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述，而是依靠下层协议提供长度标识和长度限制。另外，RTP协议将部分运输层协议功能(比如流量控制)上移到应用层完成，简化了运输层处理，提高了该层效率。
2、数据流和控制流分离
RTP协议的数据报文和控制报文使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
3、协议的可扩展性和适用性
RTP协议通常为一个具体的应用来提供服务，通过一个具体的应用进程实现，而不作为OSI体系结构中单独的一层来实现，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。
虽然RTP协议是为多媒体数据流传输而设计的，但是其用途不仅限于此，RTP协议还可以用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。RTP报文格式中包括固定的RTP报文头，可选用的作用标识(CSRC)和负载数据。如果RTP所依赖的底层协议对RTP报文的格式有所要求，RTP报文的格式必须进行修改或重新定义。通常，单一的底层数据报文仅包含单一的RTP报文。下图1为一个典型的负载MPEG-4视频流的RTP报文格式。
RTP报文头部分各参数的意义如下：
(1)负载类型（PT）：对音频或视频等数据类型予以说明，并说明数据的编码格式。
(2)填充（P）：如果设置了填充位，表示在该RTP包的末尾含有并非有效负载数据31的填充位。
(3)扩展位（Extension-X）：由使用的RTP框架定义。
(4)序列号（Sequence Number）：为了安全，服务器从一个随机初始化值开始，每发送一个RTP数据包序列号增加1。客户端可以根据序列号重新排列数据包的顺序，并对丢失、损坏和重复的数据包进行检测。
(5)标志位（Marker-M）：标志位由具体的应用框架定义。例如，RTP的MPEG4负载格式中，标志位设为1标志就是VOP的最后一个（或仅有一个）RTP包。
(6)时间戳（Timestamp）：RTP时间戳为同步不同的媒体流提供采样时间，用于重新建立原始音频或视频的时序。另外，它还可以帮助接收方确定数据到达时间的一致性或变化（有时被称为抖动）。
(7)同步源标识（SSRC）：帮助接收方利用发送方生成的唯一的数值来区分多个同时的数据流。SSRC必须是一个严格的随机数。
(8)作用标识(CSRC):网络中使用混合器时，混合器会在RTP报文头部之后插入新的同步源标识，区分多个同时的数据流。在所有PTP报文中，开始12个字节的格式完全按照上图定义的格式，而CSRC标识列表仅出现在混合器插入时。
标准的RTP数据报文头部参数对RTP支持的所有应用类的共同需要是完整的。然而，为了维持ALF设计原则，报文头部还可以通过改变、增加参数实现优化，或适应特殊应用的需要。由于标志位和负载类型段携带特定设置信息，所以很多应用都需要它们，否则要容纳它们，就要增加另外32位字，因此，标志位和负载类型允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，例如采用更多或更少标志位。如果有标志位，既然设置无关监控器能观察报文丢失模式和标志位间关系，可定位八进制中最重要的位。
如果RTP协议需要负载其它特殊格式(如视频编码)的音视频数据，所要求的信息应该携带在报文的数据负载部分。所需信息也可以出现在报文头部，但必须总是在载荷部分开始处，或在数据模式的保留值中指出。如果特殊应用类需要独立负载格式的附加功能，应用运行设置应该在现存固定报文头部的SSRC参数之后，定义附加固定段。这些设置能使客户端迅速而直接访问附加段，同时，与监控器和记录器无关设置通过解释开始的12个八进制处理RTP报文。
二、RTCP数据传输控制协议
RTP协议本身包括两部分：RTP数据传输协议和RTCP传输控制协议。为了可靠、高效地传送实时数据，RTP和RTCP必须配合使用，通常RTCP包的数量占所有传输量的5%。RTP实时传输协议主要用于负载多媒体数据，并通过包头时间参数的配置使其具有实时的特征。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP(Real-time Contro1 Protocol)传输控制协议提供这些服务。RTCP传输控制协议主要用于周期的传送RTCP包，监视RTP传输的服务质量。在RTCP包中，含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，实现流量控制和拥塞控制服务。
RTP的控制协议RTCP通过在会话用户之间周期性地递交控制报文来完成监听服务质量和交换会话用户信息等功能。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。RTCP协议将控制包周期发送给所有连接者，应用与数据报文相同的分布机制。底层协议提供数据与控制包的复用，如使用单独的UDP端口号。
具体来说RTCP的主要功能包括以下四个部分：
1、提供数据发布的质量反馈，这是RTCP最主要的功能。作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用。反馈功能由RTCP发送者和接收者报告执行。
2、发送带有称作规范名字(CNAME)的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME与相关RTP连接中给定的几个数据流联系。
3、用于控制RTCP数量包的数量。前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。
4、传送最小连接控制信息，如参加者辨识。最可能用在“松散控制”连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通信要求。
RTCP报文格式与RTP报文类似，包括固定的报文头部分和可变长结构元素，结构元素的意义由RTCP报文的类型决定，因为通常RTCP包非常小，一般把多个RTCP包合并为一个RTCP包，然后利用一个底层协议所定义的报文格式进行发送。
RTCP报文格式如图2所示，RTCP报文头部参数首先要区别携带不同控制信息的RTCP报文的类型，RICP报文类型主要有以下几种：
SR：发送报告，当前活动发送者发送、接收统计；
RR：接收报告，非活动发送者接收统计；
SDES：源描述项，包括CNAME；
BYB：表示结束；
APP：应用特定函数。
在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及己经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。
其中最主要的RTCP报文是SR和RR。通常SR报文占总RTCP数据包的25%，RR报文占75%。类似于RTP数据包，每个RTCP报文以固定的包头部分开始，紧接着的是可变长结构元素，但是以32位长度为结束边界。在RTCP报文中，不需要插入任何分隔符就可以将多个RTCP报文连接起来形成一个RTCP组合报文。由于需要底层协议提供整体长度来决定组合报文的结尾，所以在组合报文中没有单个RTCP报文的显式计数。
RTCP控制报文的发送周期是变化的，与报文长度L、用户数N和控制报文带宽B相关：周期P=L*N/B。原因是RTP设计允许应用自动扩展的模式，连接数可从几个到上千个。在一般的音频会议中，因为同一时刻一般只有两个人说话，所以数据流和控制流都是内在限制的，控制流不会对传输造成影响。而在组播发送模式下，给定连接数据率独立于用户数，仍是常数，但控制流量不是内在限制的。如果每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
三、 RTSP实时流媒体协议
RTSP（Real-time Steaming Protocol）是由RealNetworks和Netcape共同提出的一个应用层协议。它可以在媒体服务器和客户端之间建立和控制连续的音/视频媒体流，协同更低层协议RTP、RSVP等一起来提供基于Internet的整套流式服务。RTSP提供了一种可扩展框架，使得可控的、点播的实时数据的传送成为可能。它提供用于音频和视频流的“VCR模式”远程控制功能，例如暂停、快进、快退和定位。支持单播和组播。RTSP还提供选择发送通道的方法(如UDP、组播UDP和TCP)和基于RTP的发送机制。RTSP像是媒体服务器和客户端之间的“网络远程控制”，它提供多种服务，如从媒体服务器上检索媒体、邀请媒体服务器进入会议、添加媒体到现成节目。RTSP在语法和操作上类似于HTTP，因此许多HTTP的扩展机制都可以移植于RTSP上。在RTSP中，每个节目和媒体流由RTSP URL确定，全部节目和媒体特性都在节目描述文件中给予了描述，包括编码、语言、RTSP URL、目的地址、端口号以及其它参数。但是，不同于HTTP的无状态和非对称，RTSP是有状态的、对称的协议。RTSP的服务器保持会话状态以连接RTSP流的请求，并且服务器和客户端都可以发出请求。
协议支持的操作如下：
媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示就包含用于连续媒体的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
四、 RSVP资源预留协议
由于音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求之外，还需其它更多的条件。RSVP(ReSource reserVe Protocol)是Internet上的资源预留协议，使用RSVP预留一部分网络资源(即带宽)，能在一定程度上为流媒体的传输提供QoS。资源预留协议使Internet应用传输数据流时能够获得特殊服务质量，它同路由协议协同工作，建立与路由协议计算出路由等价的动态访问列表，RSVP属OSI七层协议栈中传输层。RSVP的流程是单一的，并不区分发送方和接收方，且支持单播和组播，适应于可变成员个数和路由。