【Video】流媒体协议介绍（rtp/rtcp/rtsp/rtmp/mms/hls）

RTP

参考文档 RFC3550/RFC3551

该实时传输方案专为互联网中的多媒体数据流设计。
该标准数据包格式被广泛应用于音频和视频内容的实时在线传输。
该实时传输方案广泛应用于流媒体服务、语音通话以及一键通通信等场景。
通过与RTCP协同工作以及基于H.323或Session Initiation Protocol (SIP)的支持，在电信产业中占据重要地位。
该技术方案不仅支持实时通信功能，并且其底层架构基于UDP网络传输机制。

RTP并未提供按时发送机制及其它服务质量（如QoS）的支持，并需由底层服务来完成这一功能。其未承诺确保数据传输或阻断无序传输行为，并对底层网络的可靠性缺乏信心支持。其采用有序传输方式，在此过程中接收端可重组发送端的数据包序列，并根据需要确定合适的位置安排数据包的位置以确保有效传输，在视频解码场景中则无需按顺序进行解码处理以提高效率。

RTP 包含两个相互关联的部分： RTP —— 传输实时数据；RTP 控制协议（RTCP）—— 评估服务质量并提供当前会话的相关信息。

RTCP

实时传输控制协议（Real-Time Transport Control Protocol 或 RTP Control Protocol 或缩写 RTCP）是实时传输协议（RTP）的一个补充协议。该协议通过信道外机制实现对 RTP 流的管理与控制，并通过与 RTP 协作将多媒体数据打包并发送到目标地址。该协议定期向参与实时媒体会话的各方发送控制信息，并其主要作用是对 RTP 提供服务质量反馈机制。具体而言，在服务质量和性能优化方面 RTCP 收集了以下各项指标：例如记录了以下各项指标：传输字节数、分组数量、丢失分组数量、抖动度、单向和双向网络延迟等关键参数信息；基于这些收集到的数据信息网络层应用程序可采取相应的优化措施例如限制信息流量或采用压缩编码效率较低的编解码器以进一步提升服务质量和用户体验；值得注意的是 RTCP 本身不具备数据加密或身份认证功能；而 S-RTCP 则可应用于类似场景

SRTP & SRTCP

参考文档 RFC3711

基于实时传输协议的安全实时传输协议是被定义的一个协议。该种安全实传议定书旨在为单播及多播应用中的实时数据传输提供加密、认证、完整性和重放保护等特性。它是由David Oran（思科公司）与Rolf Blom（爱立信公司）共同开发的；而最初的版本则于2004年3月被IETF首次发布为RFC 3711文件。鉴于RTP与RTCP之间存在紧密联系关系，在这种背景下也发展出了一个相关的伴生议定书——即称为Secure RTCP或SRTCP的安全 realtime transmission control protocol；这个 Secure RTCP/ SRTCP议定书为原有的 RTP/ RTCP 提供了类似的安全特性保障；就像它的上层议定书——Secure RTP/ SRTP一样。在采用 RTP 或 RTCP 协议进行数据传递时；选择是否采用 Secure Real-time Transport Protocol/SRTP/ Secure Real-time Transmission Control Protocol/Safe RTCP则是可选的选项；然而即便采用了这些安全实传相关议定书；其中提供的各种安全性特征仍可独立选择性地启用或禁用；唯一例外的情况是在采用 Secure Real-time Transmission Control Protocol/Safe RTCP时必须要启用其认证特性保障

RTSP

参考文档 RFC2326

由Real Networks与Netscape共同提出的一种协议。该协议明确了如何通过IP网络高效传输多媒体数据给一对多的应用程序。RTSP构建了一个可扩展框架,使其能够实现对实时音频和视频数据的控制与分发。这些来源包括现场采集的数据以及来自剪辑存储的数据。该协议的目的在于控制多个数据发送连接,并提供选择合适的传输通道（如UDP、multicast UDP和TCP）的方法。

RTSP（实-time streaming protocol）主要用于控制声音或影像的多媒体流，并支持同时多个流的需求，在其定义域内并不限定传输使用的网络通信规范。服务器端可自主决定采用TCP或UDP传送流数据。其语法结构与HTTP 1.1相似，在时间同步问题上不特意关注因而能够容忍一定程度的网络延迟。由于与HTTP 1.1类似的运作模式，《Proxy》代理服务器具备快速获取功能《Cache》，而由于RTSP具备重定向能力，《根据实际负载状况转换提供服务的服务器》以避免过大的负载集中在单一服务器导致延迟发生

RTSP 和RTP的关系

RTP无法完整下载整个影视文件；相反地，在网络上它是以恒定的数据传输速率发送数据；而客户端也按此速度接收并显示视频内容；一旦视频内容展示完毕，则无法进行重复播放；除非重新向服务器端请求新的数据块。

在功能上，RTSP主要特点是支持双向实时数据传输。该协议使得客户端能够向服务器发送多种请求，并且包括但不限于回放、快进和倒退等多种操作。此外，在功能上还支持基于RTP的数据传输，并可以选择使用诸如TCP或UDP等其他通道来发送数据。该协议具备良好的扩展能力，并且属于网络应用层的一种协议类型。当前遇到的实际应用场景之一是服务器端实时采集并编码两个独立的视频流，则而客户端则能够接收并展示这两个独立的视频流。无需对所接收的数据进行回放或倒退处理，则通常采用的是UDP与RTP结合，并通过组播技术实现高效传输。

以下是基于您提供的文本内容进行的改写

SDP

多媒体交互式服务（MIS）系统中的媒体流管理机制主要包括媒体流发现、媒体流分发等关键技术。该系统通过构建多级分布式架构实现对媒体流的有效管理，并支持多种媒体流类型间的智能转换与灵活分配。
基于此设计的MIS系统框架主要包含三个核心组件：媒体流发现模块、媒体流分发模块以及媒体流调度模块。

SDP的设计核心理念是通用性，在其应用领域不仅限于组播会话目录这一特定场景下运行操作。然而该技术不支持参与方就会议内容及媒体格式进行协商议定，在此过程中仅能完成会议的基本连接建立工作。在因特网组播骨干网（Mbone）环境中，则由专门的会话目录工具负责发布多媒体会议通知并提供必要的参与者地址及所需工具信息传递服务功能。当SDP完成两个会话之间的连接建立后，则需向所有参与者传递足够的会议相关信息以确保会议顺利进行。这些信息采用UDP数据包传输，并由带有SAP协议头的信息包周期性地分发至已知的组播地址及指定端口位置上实现传送过程；其中包含有SAP协议头以及以文本形式存在的有效负载部分；这部分具体指的是包含有SDP相关会议详细描述的信息内容；此外还可以通过电子邮件或者WWW（World Wide Web）等其他方式实现数据传输途径的选择与配置设置

SDP 文本信息包括：

对话名称及其目的；【

SDP 是一种文本编码形式，在 ISO 10646 字符集下基于 UTF-8 格式进行处理。其 SDP 对话部分如下所示：
其协议版本字段值为 v；
参与者标识符 o 包含所有者或创建者的相关信息；
对话名称字段值为 s；
可选的对话相关信息字段包括 i；
参与者提供的 URI 地址字段值为 u；
联系人电子邮箱地址字段值为 e；
参与者提供的联系方式字段值为 p；
连接参数包括 c；
传输带宽数值字段值为 b。

一个或以上的时间区间设定（如上所述）：其中z值表示（如上所述），k值代表（如上所述），a值包含（如上所述）。

时间描述
t = （会话活动时间）
r = * （0或多次重复次数）

媒体描述
m=（媒体标识符及其传输位置）
i=（媒体名称参数）
c=（连接信息；若位于会话层则可省略此字段）
b=（带宽数据）
k=（加密密钥参数）

a = * （0 个或多个会话属性行）

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)，即实时消息传送协议是由Adobe Systems公司为了实现Flash播放器与服务器之间的音频、视频以及数据传输而开发的一种开放协议。该协议包含三种变体形式：

RTMP(Real Time Messaging Protocol)，即实时消息传送协议是由Adobe Systems公司为了实现Flash播放器与服务器之间的音频、视频以及数据传输而开发的一种开放协议。该协议包含三种变体形式：

1)工作在TCP之上的明文协议，使用端口1935；

2)RTMPT封装在HTTP请求之中，可穿越防火墙；

3)RTMPS类似RTMPT，但使用的是HTTPS连接；

Real Time Messaging Protocol（RTMP）协议由Adobe Flash采用以实现对象、视频及音频数据的实时传输。该协议建立于基于TCP/IP网络通信模型或者基于轮询HTTP机制的数据传输架构之上

RTMP协议如同一种专门设计的数据容器，在其中可以存储两种不同类型的媒体内容：一种是适用于Multimedia Format（AMF）的数据文件；另一种则是来自Flv视频文件中的音频和视频信息。单个端口连接能够通过多种传输路径来传递多路网络流；这些路径都遵循固定大小包裹的标准.

mms

Microsoft Media Server Protocol（缩写为MMS），即"微软媒体服务器协议"（Microsoft Media Server Protocol），是一种用于从WindowsMedia服务器中获取文件(.asf格式)的流式传输协议。该协议被用于从WindowsMedia发布点获取单播内容，并通常作为默认选择用于连接到WindowsMedia单播服务。当观众在WindowsMedia Player中输入URL直接连接内容时，则必须使用该协议来引用该流。根据指定配置参数表可得，默认情况下,MMS会通过预设埠1755进行通信。

当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。
如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。
若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。例如：mms://windows_media_server/LiveEvents。这里 windows_media_server 是 Windows Media 服务器名，而 LiveEvents 是发布点名

HLS

HLS是一种由苹果公司开发的基于HTTP的标准协议。它支持实时流媒体传输与分段回放，并广泛应用于iOS设备生态中以满足iPhone、iPad等设备的需求。其核心机制与传统分段式HTTP点播相似但其特点在于采用极细粒度的数据分块

相对于传统的流媒体直播协议（如RTMP、RTSP、MMS等），HLS直播在客户端获取到的数据并非完整的连续媒体流。在HLS协议下，服务器端将实时直播数据存储为多个短暂的小文件（采用MPEG-TS格式），而接收端则不断下载并播放这些小文件。由于服务器会持续生成新的小文件以提供最新内容，在接收端只需按顺序播放即可实现流畅观看。这表明HLS实际上采用了分段播放的技术来模拟直播效果。由于其基于HTTP传输机制的特点，在防火墙或代理设置上无需额外考虑延迟问题，并且短小的分段文件能够快速适应不同网络带宽下的播放需求。然而这种技术特性也导致了HLS在实时性方面通常会低于其他传统流媒体方案

综上所述

基于上述的理解需深入研究并系统地实现以下技术关键点

1. 获取视频源与音频源的相关数据。
2. 采用H264和AAC双格式压缩对原始信号实施编码处理。
3. 将视频流与音频流整合后打包成MPEG-TS多路分组数据。
4. 基于HLS分段策略构建相应的m3u8分片列表，并生成完整的索引表。
5. 建立基于HTTP传输层协议的服务可用性模型。