WebRTC生态之流媒体传输协议简介（一）：RTMP、HLS、MPEG-DASH、HTTP-FLV、SRT、WHIP、WHEP、RTSP、RTP、RTCP、SDP

WebRTC，Web Real-Time Communication，作为Web浏览器提供实时通信能力的开放标准，经过十余年发展已从单纯的技术规范演化为涵盖协议栈、媒体服务器、客户端工具、SDK框架、完整平台在内的庞大技术生态体系。

为方便理解，可将WebRTC生态划分为六大板块：

• 流媒体传输协议
• 媒体服务器
• 推流与转码网关
• 客户端工具
• SDK与框架
• 完整平台与解决方案

流媒体传输协议

不同的流媒体传输协议各有特点，适用于不同的应用场景。从延迟角度进行排序，WebRTC和SRT处于第一梯队，延迟在200毫秒到500毫秒之间，能够满足实时互动需求；RTMP和HTTP-FLV处于第二梯队，延迟在1到5秒之间，适合弹幕互动直播；HLS和DASH处于第三梯队，延迟在10秒以上，适合大规模分发和录播场景。

从生态兼容性角度分析，RTMP和HLS的设备支持最为广泛，几乎所有推流软件和播放器都能兼容；WebRTC得到所有主流浏览器支持，但在专业设备领域的支持相对较少；SRT主要在专业广播设备中得到应用。协议的选择需要综合考虑延迟要求、规模需求、设备兼容性和运维复杂度等因素。

RTMP

Real-Time Messaging Protocol，Adobe公司开发的实时消息传输协议，长期以来是直播领域的事实标准。基于TCP传输，支持将音视频数据封装为FLV容器进行流式传输，低延迟、稳定性好。最初设计用于Flash播放器与Adobe Media Server之间的通信，Flash被淘汰后，其应用场景已转向推流端到媒体服务器的传输。

核心优势在于其成熟度和广泛的设备支持。几乎所有主流的推流软件和硬件编码器都支持RTMP输出，这使得RTMP成为连接不同系统的桥梁。RTMP推流延迟通常在1到3秒之间，不如WebRTC低，但对于大多数直播场景而言是可接受的。还支持时间戳和元数据，能够实现音视频同步和内容识别。

局限性：基于TCP传输，在网络波动时可能产生较大的延迟累积，不支持UDP多播。RTMP服务器需要维护长连接，扩展性受到限制。RTMP缺乏现代的NAT穿透机制，在复杂网络环境下的部署较为困难。促使业界寻找更先进的替代方案。

当前，RTMP主要用于推流端到媒体服务器的接入层，而分发层正逐步向WebRTC和HLS迁移。许多直播平台采用RTMP作为采集协议，然后通过SRS、ZLMediaKit等媒体服务器转换为其他协议进行分发。阿里云等云服务商也继续提供RTMP推流作为标准输入方式。

有三种变种：

• 工作在TCP之上的明文协议，使用端口1935；
• RTMPT封装在HTTP请求之中，可穿越防火墙；
• RTMPS类似RTMPT，但使用的是HTTPS连接；

HLS

HTTP Live Streaming，Apple公司推出的自适应流媒体传输协议，基于HTTP协议实现，具有良好的穿透性和兼容性。HLS将媒体内容切分为小文件片段（通常为2到10秒），通过M3U8播放列表文件进行组织，客户端通过不断请求最新片段来实现播放。这种基于HTTP的设计使得HLS可充分利用CDN进行分发，天然支持大规模并发。

HLS的延迟通常在10到30秒之间，这主要源于其设计理念——优先保证稳定性和兼容性，而非实时性。HLS采用TCP传输，能够在不可靠的网络环境下保持较好的播放体验。为降低延迟，Apple后来引入LL-HLS（Low-Latency HLS）扩展，通过预请求和_PART标签将延迟降低到3秒左右。但LL-HLS的支持尚不广泛，实际部署存在兼容性考虑。

HLS最初只支持TS容器格式，后来Apple添加对fMP4（Fragmented MP4）的支持，这使得HLS可与WebRTC共享相同的容器格式。LL-HLS进一步引入CMAF（Common Media Application Format）支持，推动不同传输协议之间的互操作性。在实际部署中，许多平台同时提供HLS和DASH两种协议，以最大化客户端兼容性。

MPEG-DASH

ISO/IEC发布的国际标准，与HLS类似，也采用基于HTTP的自适应比特率流媒体技术。DASH（Dynamic Adaptive Streaming over HTTP）采用更灵活的MPD（Media Presentation Description）描述媒体结构，支持更丰富的场景。两者在技术上有很多相似之处，都通过HTTP协议进行内容分发，都支持多码率自适应。DASH的优势在于其国际标准地位和更广泛的行业支持。

HTTP-FLV

一种将FLV封装通过HTTP协议传输的技术，结合FLV容器和HTTP协议的优点。与RTMP类似，HTTP-FLV也是一种低延迟的直播协议，延迟通常在2到5秒之间。利用HTTP/1.1的Chunked Transfer Encoding实现流式传输，避免完整的文件下载。

主要优势在于其简单性和兼容性。基于标准的HTTP协议，可直接使用现有的Web服务器和CDN基础设施，无需特殊的服务器端支持。FLV容器对H.264/AAC的封装也已经标准化，大多数播放器都能识别和处理。相较于RTMP，HTTP-FLV更容易穿透防火墙，在复杂网络环境下具有更好的连通性。

局限性：不具备自适应码率能力，无法根据网络状况动态调整视频质量。与WebRTC相比，HTTP-FLV的延迟较高，不适合实时互动场景。HTTP-FLV的播放需要Flash播放器或支持FLV的HTML5播放器，在移动端的兼容性相对较差。在Web环境中，通过flv.js库可将FLV流转换为MSE（Media Source Extensions）进行播放。

SRT

官网，Secure Reliable Transport的缩写，由Haivision开发的一种开源（GitHub，3.6K Star，934 Fork）传输协议，旨在解决传统RTMP/RTSP协议的局限性。基于UDP传输，提供可靠性和有序性保证，具备强大的NAT穿透能力。支持AES加密，确保传输安全，这与WebRTC的安全设计理念相吻合。

核心优势在于其卓越的网络适应性，采用ARQ（Automatic Repeat reQuest）机制进行丢包恢复，通过握手过程协商传输参数，能够在丢包率较高的网络环境下保持稳定的传输。延迟通常在500毫秒以下，优于HLS和HTTP-FLV，与WebRTC处于同一量级。还支持多路径传输，可同时利用多条网络链路提升带宽和可靠性。

SRT协议在专业广播领域获得广泛应用，许多专业编码器和解码器都支持SRT输入输出。SRT的URL格式为srt://host:port，支持参数化配置如延迟、加密密钥、带宽等。在公网传输场景下表现优异，特别适合远程制作、直播推流等对延迟和可靠性有较高要求的场景。

WHIP

WebRTC-HTTP Ingestion Protocol，为解决WebRTC推流标准不统一而诞生的协议。

IETF标准化的新兴协议，为WebRTC的接入和拉流提供HTTP-based的标准化方式。WHIP于2024年正式发布为RFC 9725，标志着WebRTC与传统广播体系的融合进入新阶段。

WHIP协议定义WebRTC推流的HTTP接口，推流端通过HTTP POST请求向媒体服务器发送SDP Offer，服务器返回SDP Answer，完成WebRTC会话建立。这种基于HTTP的设计使得推流过程可穿越大多数防火墙，无需维护持久的WebSocket连接。WHIP简化WebRTC的接入流程，开发者无需实现复杂的信令服务器，只需支持HTTP请求即可实现WebRTC推流。

WHEP

WebRTC-HTTP Egress Protocol，WHIP的互补协议，用于WebRTC拉流的标准化。定义客户端通过HTTP API从媒体服务器获取WebRTC流的机制，客户端发送HTTP请求获取SDP Answer，建立接收端连接。WHEP支持单播和组播模式，为大规模分发场景提供解决方案。

OBS Studio从28.0版本开始支持WHIP协议，用户可直接配置WHIP服务器地址进行WebRTC推流，无需中转服务器。这种端到端的WebRTC推流路径可将延迟降低到200毫秒左右，相较于传统的RTMP推流加WebRTC分发模式（通常500毫秒以上）有显著改善。

RTCP

RTP Control Protocol，实时传输控制协议，与RTP配合使用，传输统计信息如带宽、丢包率、抖动等，用于监控传输质量和进行拥塞控制。

RTP

Real-time Transport Protocol，实时传输协议，实际承载音视频数据的传输协议，负责将媒体数据打包并通过UDP进行传输。RTP包包含时间戳、序列号、负载类型等信息，支持媒体流的同步和丢包检测。支持多路复用，可在同一连接上传输多路媒体流。

SRTP

Secure Real-time Transport Protocol，安全实时传输协议，在RTP基础上增加安全能力。旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC3711发布。

SRTCP

Secure RTP Control Protocol，安全实时传输控制协议，也叫Secure RTCP，为RTCP提供安全特性。

在使用RTP或RTCP时，使不使用SRTP或SRTCP是可选的；但即使使用SRTP或SRTCP，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可被独立地使用或禁用。唯一的例外是在使用SRTCP时，必须要用到其消息认证特性。

RTSP

Real Time Streaming Protocol，实时流协议，由Real Networks和Netscape共同提出，用于控制多媒体流传输的应用层协议，通常与RTP配合使用。RTSP本身不传输媒体数据，而是负责建立和管理会话，支持播放、暂停、录制等控制操作。RTSP协议类似于多媒体的"远程控制"协议，常用于IP摄像头、监控系统、媒体播放器等场景。

RTSP在专业音视频领域有着广泛应用，特别是在安防监控、广播制作、视频会议等场景。RTSP支持认证机制，可实现推流和拉流的权限控制。RTSP基于UDP传输，延迟较低，但需要处理NAT穿透和防火墙问题。

SDP

Session Description Protocol，会话描述协议，为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供多媒体会话描述。

会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息，SDP即用于将这种信息传输到接收端。SDP完全是一种会话描述格式，不属于传输协议，只使用不同的适当的传输协议，包括会话通知协议（Session Announcement Protocol，SAP）、SIP、实时流协议（RTSP）、MIME扩展协议的电子邮件以及超文本传输协议（HTTP）。

SDP的设计宗旨是通用性，可应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但SDP不支持会话内容或媒体编码的协商。

在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，由SDP完成。SDP连接好会话后，传送足够的信息给会话参与者。SDP信息发送利用SAP周期性地组播通知数据包到已知组播地址和端口处。这些信息是UDP数据包，其中包含SAP协议头和文本有效载荷（text payload）。这里文本有效载荷指的是SDP会话描述。此外信息也可通过电子邮件或WWW进行发送。

SDP文本信息包括：

• 会话名称和意图；
• 会话持续时间；
• 构成会话的媒体；
• 有关接收媒体的信息（地址等）。

协议结构

SDP信息是文本信息，采用UTF-8编码中的ISO 10646字符集，SDP会话描述如下，标注*符号的表示可选字段：

• v=：协议版本
• o=：所有者/创建者和会话标识符
• s=：会话名称
• i=*：会话信息
• u=*：URI描述
• e=*：Email地址
• p=*：电话号码
• c=*：连接信息，如果包含在所有媒体中，则不需要该字段
• b=*：带宽信息

更多时间描述：

• z=*：时间区域调整
• k=*：加密密钥
• a=*：0个或多个会话属性行
• t=：会话活动时间
• r=*：0或多次重复次数

0个或多个媒体描述

• m=：媒体名称和传输地址
• i=*：媒体标题
• c=*：连接信息，如果包含在会话层则该字段可选
• b=*：带宽信息
• k=*：加密密钥
• a=*：0个或多个会话属性行

SIP

Session Initiation Protocol，会话发起协议，亦会话初始协议，是由IETF制定的一种多媒体通信协议。一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。这些会话可是Internet多媒体会议、IP电话或多媒体分发。

主要功能，包括用户定位、会话建立、会话参与方管理和特点的有限确定。通过以下逻辑功能来完成通信：

• 用户定位功能：确定参与通信的终端用户位置
• 用户通信能力协商功能：确定参与通信的媒体终端类型和具体参数
• 用户是否参与交互功能：确定某个终端是否加入某个特定会话中
• 建立呼叫和控制呼叫功能：包括向被叫“振铃”、确定主叫和被叫的呼叫参数、呼叫重定向、呼叫转移、终止呼叫等

SIP会话使用多达四个主要组件：SIP用户代理、SIP注册服务器、SIP代理服务器和SIP重定向服务器。这些系统通过传输包括SDP协议（用于定义消息的内容和特点）的消息来完成SIP会话。

• 用户代理：终端用户设备，如用于创建和管理SIP会话的移动电话、多媒体手持设备、PC、PDA等
• 注册服务器：包含域中所有用户代理的位置的数据库
• 代理服务器：接受SIP UA的会话请求并查询SIP注册服务器，获取收件方UA的地址信息
• 重定向服务器：允许SIP代理服务器将SIP会话邀请信息定向到外部域。

SIP协议是一个Client/Server协议，因此SIP消息分为请求消息和响应消息。常用的SIP请求消息包括：

• INVITE：表示主叫用户发起会话请求，邀请其他用户加入一个会话
• ACK：客户端向服务器端证实它已经收到对INVITE请求的最终响应
• BYE：表示终止一个已经建立的呼叫
• CANCEL：表示在收到对请求的最终响应之前取消该请求
• REGISTER：表示客户端向SIP服务器端注册列在To字段中的地址信息

常用的响应消息包括：

• 100试呼叫（Trying）
• 180振铃（Ringing）
• 200成功响应（OK）
• 404用户不存在（Not Found）
• 408请求超时（Request Timeout）
• 486线路忙（Busy Here）

SIP能够连接使用任何IP网络（有线LAN和WAN、公共Internet骨干网、移动2.5G、3G和Wi-Fi）和任何IP设备（电话、PC、PDA、移动手持设备）的用户，从而出现众多利润丰厚的新商机，改进企业和用户的通信方式。基于SIP的应用（如VOIP、多媒体会议、push-to-talk、定位服务、在线信息和IM）即使单独使用，也会为服务提供商、ISV、网络设备供应商和开发商提供许多新的商机。

MMS

Microsoft Media Server Protocol，微软媒体服务器协议，用来访问并流式接收Windows Media服务器中.asf文件的一种协议。MMS协议用于访问Windows Media发布点上的单播内容。MMS是连接Windows Media单播服务的默认方法。若在Windows Media Player中键入一个URL以连接内容，而不是通过超级链接访问内容，则必须使用MMS协议引用该流。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是发布点名。