流媒体协议介绍（RTP / RTCP / RTSP / RTMP/ MMS / HLS）
流媒体协议介绍（RTP / RTCP / RTSP / RTMP/ MMS / HLS）
- 一、RTP (参考文档为RFC 3550和RFC 3551)
- 二、RTCP
- 三、SRTP和SRTCP(其参考文档为RFC 3711)
- 四、RTSP(其参考文档为RFC 2326)
- 五、RTSP与RTP之间的关系
- 六、SDP
- 七、RTMP和RTMPS
- 八、MMs技术
- 九、HLS流式传输技术
一、RTP (参考文档RFC3550 / RFC3551)
The Real-Time Transport Protocol (RTCP) functions to deliver multimedia data streams across the Internet in the transport layer.
该协议明确了互联网中音频与视频的标准数据包格式。该协议通常应用于流媒体系统（结合RTCP）以及视频会议和一键通系统（如Push to Talk, 配合H.323或SIP），从而确立了其在IP电话产业中的技术核心地位。该协议与RTCP协同工作，并基于UDP构建。
RTP本身并未提供精确的时间发送机制或其它服务质量（如QoS）保障,其功能需由底层服务来完成。 RTP无法确保数据传输或阻止无序传输,其可靠性的保障也未得到充分确认。 RTP采用按顺序的方式传输数据块,每个数据包都带有唯一的标识符——序列号,在接收端这些标识符有助于重新排列顺序。此外,在某些应用中（如视频解码）,这种标识符还可以用来确定数据块的最佳位置以避免影响解码过程。
RTP主要由两个紧密相关的组成部分构成：一是用于传送具有实时属性的数据；二是作为控制协议（RTCP），它负责确保服务质量和传输实时性，并传递正在处理会话的相关信息。
二、RTCP
实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）属于实时传输协议（RTP）系列中的一个补充系统。该协议专门针对实时媒体流进行优化设计，并与主RTP协同工作以实现高效的数据打包与分发功能。在实际应用中，RTCP主要通过定期向参与实时多媒体会话的各方发送控制信息来维持会话状态并确保数据完整性。
RTCP的核心作用是对RTP提供的服务质量进行相应的反馈。
该媒体连接统计系统由... RTCP负责收集与媒体连接相关的统计数据。
这些统计信息包括传输字节数、传输分组数、丢失分组数、抖动度（jitter）以及单向和双向时延等参数。
网络应用可以根据这些关键性能指标来优化服务质量措施，
如限制数据流量或采用更高效的编码解码方案。
值得注意的是，
... RTCP仅专注于提供基础的性能反馈而不涉及数据加密或身份验证功能。
而... S Reno-TT（SRTCP）则同样适用于这类场景。
三、SRTP & SRTCP（参考文档 RFC3711）
该协议（SRTP）是基于RTP标准开发的一种安全传输技术，在单播与多播应用中对实时数据进行加密、验证消息完整性并防止数据重放。该协议由思科公司的David Oran与爱立信公司的Rolf Blom共同开发，并于2004年3月被IETF正式指定为RFC3711标准。
鉴于实时传输协议与能够用于控制该会话的实时传输控制协议（即RTP或RTCP）之间存在密切的关系。其对应的安全实时传输控制协议则通常附带有一个相关的protocol,并被称为 safe realtime transmission control protocol (SRTCP 或 Secure RTCP)。该 safe realtime transmission control protocol旨在提供与原始 realtime transmission control protocol相似的安全特性,类似于 secure realtime transmission protocols旨在保护 realtime protocols所拥有的那些功能。
当采用实时传输协议或实时传输控制协议时，并非必须排斥使用安全版本的相应协议；然而，在选择了安全版本的安全实时传输协议或安全实时传输控制协议后，则并非所有的其特性（如加密与认证功能）均需启用。值得注意的是，在采用安全版本的安全实时传输控制协议时，默认情况下会启用其消息认证特性。
四、RTSP（参考文档 RFC2326）
由Real Networks和Netscape共同提出一项创新协议。该协议规定了一对多应用程序如何通过IP网络高效地传送多媒体内容。RTSP提供了实现实时传输所需的一个扩展性框架，在其中可以实现控制和分发音频以及视频流。这些来源包括现场采集的数据以及那些存储于剪辑文件中的素材。其目的就是管理多个数据传输连接，并为此类应用提供了灵活的选择途径——无论是采用UDP还是广域网 UDP 作为基础传输介质——同时还能根据需要决定采用基于RTP的方式进行内容分发。
RTSP（Real Time Streaming Protocol）主要用于控制声音或影像的多媒体流，并允许同时处理多个流需求；其传输使用的网络通信协议不在其定义范围。服务器端可自主选择采用TCP或UDP协议发送多媒体数据；其语法结构和运行机制与HTTP 1.1相似但不特别注重时间同步因而能够容忍较大的网络延迟；此外在前面提到的部分中"Multicast"功能也具有重要意义：除了能够减少服务器端所需的网络带宽外还能从而支持多路视讯会议。
由于其工作原理与HTTP/1.1一致，在RTSP中代理服务器Proxy同样具备快速访问（Cache）的能力。此外，在具备重定向能力的情况下，在实际负载分布下自动切换提供服务的服务器位置，从而有效防止资源过度集中导致延迟问题的发生。
五、RTSP 和RTP的关系
RTP不像HTTP/FTP能够完整下载整个影视文件。它以恒定速率在网络上传输数据，并确保客户端也能同步接收这些信息。一旦电视画面播放完毕，则无法再次播放该内容；除非重新请求服务器提供新数据。
在功能设计上，RTSP与RTP的主要差异体现在：RTSP作为一种基于实时数据传输技术的网络协议，在功能定位上与其类似的是HTTP协议家族中的成员。该协议赋予客户端对远程服务器发起多种实时操作请求的能力（例如回放、快进和倒退等），同时允许通过多种底层传输介质实现可靠的数据传输：包括传统的TCP/IP协议以及现代的UDP协议和组播UDP技术。作为典型的网络应用层协议，在功能定位上与其类似的是HTTP协议家族中的成员。在实际应用场景中存在如下情况：服务器端实时采集并进行编码处理后输出两路独立视频流；而客户端则能够通过相应的解码模块接收这两路视频流并完成显示操作；值得注意的是，在这种架构下客户端无需对视频数据进行额外的操作（如回放或倒退），从而能够直接采用UDP+RTP+组播的技术方案实现高效的数据传送
实现实时通信的技术称为 RTP（Real-time Transport Protocol）。该协议专为高效的信息传递设计。
采用编码技术的 RTP 和 RTCP 协议被广泛应用于信息传递领域。
实现实时通信的技术称为 RTP（Real-time Transport Protocol）。该协议专为高效的信息传递设计。
采用编码技术的 RTP 和 RTCP 协议被广泛应用于信息传递领域。
实现实时通信的技术称为 RTP（Real-time Transport Protocol）。该协议专为高效的信息传递设计。
采用编码技术的 RTP 和 RTCP 协议被广泛应用于信息传递领域。
RTSP：实时流协议（Real Time Streaming Protocol，RTSP）
在实时传输协议中主要包含了 six 核心请求：DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN 和 OPTIONS 等等。
在对话过程中 SETUP 指令用于确定将使用的 RTP/RTCP 端口。
通过 PLAY 指令启动数据流的发送，在需要时使用 PAUSE 指令停止数据流的发送。
TEARDOWN 指令则用于处理会话结束的情况。
其他相关选项如 NOTIFY 和 REPLACE 也在其功能范围内提供支持。
RTP/RTCP协议负责传输实时多媒体数据。该协议包含两个主要部分：发送方报告（Sender Report）和接收方报告（Receiver Report），它们用于实现实时音视频同步以及其他相关功能。
六、SDP
多媒体会话描述是由SDP协议通过提供会话通知、会话邀请和其他形式的多媒体会话初始化等目的来实现的。
会议日志辅助多媒体会议的通告，并传递相关设置信息；SDP 即被用来将这种信息发送至接收端；SDP 是一种纯粹的会话描述格式；它在实现时仅使用不同的适当选择的运输层通信机制；这些机制包括以下几种典型的运输层通信机制：SAP、SIP、RTSP、MIME扩展邮件和HTTP/HTTPS。
SDP的设计初衷在于普遍适用性，在广泛类型的网络环境及各种应用场景中均有应用潜力，并不仅局限于组播会议目录这一特定领域。然而，在协商会议内容或媒体编码方面它也缺乏支持
在因特网组播骨干网（Mbone）架构中，采用Session Directory Service（SDD）来发布多媒体会议通知，并向加入者传输必要的会议地址及相关的专用工具信息；该过程由Multipoint Session Protocol（MSP）负责实现。 MSP建立并维护好一个会话后，在随后的时间里持续向所有参与方发送足够的相关信息；这些数据通过Group Announcement Protocol（SAP）进行分组广播传输，在已知的组播地址与端口位置发送；这些数据是以UDP数据包的形式传递的，在每个UDP包中包含了SAP协议头部以及文本有效载荷部分；这里所说的文本有效载荷即指SDP中的 session 描述信息；除此之外的信息还可以通过电子邮件或Web （World Wide Web）的方式来传输
SDP 文本信息涉及的内容包括：
- 对话名称及其目的；
- 对话时长；
- 参与对话的各种媒介；
- 涉及接收方相关信息（如地址等）。
协议架构
SDP 信息是文本信息，采用 UTF-8 编 码中的 ISO 10646 字符集。
SDP 会话描述如下（标注 * 符号的表示可选字段）
涉及一个或多个时间点的时间描述（如下所述）。其中z代表（进行时间区域调整）。k表示用于加密操作的密钥信息。a对应于可能包含零个到多个属性的数据行。涉及零个及以上的媒体数据描述部分。（如后续内容所示）。
时间描述
t = （会话活动时间）
r = * （0或多次重复次数）
媒体信息描述
其值为：
（媒体名称和传输地址）
i=
（媒体标题）
c=
（连接信息 — 若涉及会话层则此字段可选）
b=
（带宽参数值）
k=
（加密密钥值）
a=
（零个或多个会话属性项）
七、RTMP/RTMPS
Real-Time Message Protocol (简称RTMP)是一种针对Flash播放器与服务器之间实现音频、视频及数据传输的开放标准
它有三种变种：
- 1)运行在TCP之上的一类明文协议采用端口1935。
- 2)RTMPT被嵌入到HTTP请求中具备穿越防火墙的能力。
- 3)与之相比RTMPS采用HTTPS连接而非像RTMPT那样的方式。
该RTMP协议（Real Time Messaging Protocol）被Flash应用于对象、视频和音频的传输，并基于TCP协议或轮询HTTP协议运行。
RTMP协议类似于一种能够装载数据包的容器结构。这些数据包括AMF格式的数据以及FLV格式中包含的画面和音频信息。通过多个专用通道，一个单一的网络连接能够同时传输多路网络流。每个通道中的数据包均采用固定的大小进行传输。
八、ＭＭＳ
MMS（Microsoft Media Server Protocol）又称为微软媒体服务器协议，在Windows Media 服务器上用于以流的方式获取.asf文件的一种通信协议。
Windows Media单播流通常通过预设端口1755由MMS协议传输至发布服务器。Windows Media单播服务默认采用MMS协议进行数据传输。当用户在Windows MediaPlayer中输入URL连接内容而非点击超级链接时，则必须使用MMS协议引用该媒体流。指定传输参数的默认端口为1755
在将数据通过MMS协议发送至发布点时，在必要情况下会进行协议切换以确保最佳连接状态。这种切换过程始于尝试通过MMSU与客户端建立连接的过程。
其中，
MMSU是一种基于UDP的MMS协议实现方式。
具体而言，
如果发现该特定的MMSU连接无法建立，
则服务器将尝试采用MMST作为替代方案。
MMST也是一种基于TCP的数据传输机制，
旨在提供更加稳定的通信路径。
当您接入包含在内联索引中的 .asf 文件时，则应采用 MMS 方式来实现快进、后退、暂停以及启动/停止流等操作。请注意，在这种情况下不应通过 UNC 路径进行快进或后退操作。当通过独立安装的 Windows Media Player 接收内容时，请确保指定正确的单播 URLs。若内容通过主发布点进行点播发布，则该 URL 由服务器名称与 .asf 文件名构成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您希望转化为流的文件名。
若您有实时内容需要进行广播单播分发，则该URL由服务器名称与发布点标识符共同构成。例如，在Windows Media Server平台中使用LiveEvents作为分发标识符时，URL格式为mms://windows_media_server/LiveEvents。其中 windows media server 是 Windows Media 服务器名称，LiveEvents 则表示直播分发点标识。
九、HLS
HTTP Live Streaming（HLS）是由苹果公司(Apple Inc.)开发的一种建立在HTTP协议基础之上的流媒体传输协议，在iOS生态系统中得到了广泛应用。该技术不仅支持流媒体的直播功能，还实现了点播服务，并为此设计了专门的解决方案以满足对实时性要求较高的场景需求。与传统分段点播相比,HLS采用极小的分片尺寸进行传输
相较于传统的流媒体直播协议——包括但不限于RTMP（Real-Time Multicast Protocol）、RTSP（Real-Time Streaming Protocol）以及MMS（Multimedia Stream System）等标准——HLS（High-Latency Scalable Transport, High-Latency Scalable Transport）具有显著的不同特性。实际上，HLS的显著特点在于其客户端无法获取完整且连续的数据流。相反，在服务器端，原始直播数据被分割成一系列较短的时间段文件，并采用MPEG-TS格式进行编码存储。而客户端持续下载并解码这些分段文件以供播放——由于服务器持续不断地生成最新的直播片段，并将这些片段发送至客户端进行解码与播放。这种机制使得在实际应用中——由于采用HTTP/HTTPS传输机制——完全不用考虑网络防火墙或代理 server的影响。同时需要注意的是，在这种架构下——每个分段时间长度非常短暂——从而使得客户端能够根据当前网络带宽自动调节码率并切换播放源以适应不同的网络状况。值得注意的是这一技术特性带来的问题是——HLS的整体延迟水平通常会高于其他类型的流媒体方案
基于上述了解，在实现HTTP Live Streaming直播过程中需着重研究并落实以下关键技术要点
- 获取视频源及音频源的原始数据
- 采用H264和AAC双格式压缩技术对方波形数据进行编码处理
- 将视频流与音频流组合后打包成MPEG-TS流容器
- 基于HLS分段机制生成适配的m3u8分片列表，并构建完整的m3u8索引文件
- 采用HTTP协议作为数据传输的基本通信方式