WebRTCWeb Real-Time Communication作为Web浏览器提供实时通信能力的开放标准经过十余年发展已从单纯的技术规范演化为涵盖协议栈、媒体服务器、客户端工具、SDK框架、完整平台在内的庞大技术生态体系。为方便理解可将WebRTC生态划分为六大板块流媒体传输协议媒体服务器推流与转码网关客户端工具SDK与框架完整平台与解决方案流媒体传输协议不同的流媒体传输协议各有特点适用于不同的应用场景。从延迟角度进行排序WebRTC和SRT处于第一梯队延迟在200毫秒到500毫秒之间能够满足实时互动需求RTMP和HTTP-FLV处于第二梯队延迟在1到5秒之间适合弹幕互动直播HLS和DASH处于第三梯队延迟在10秒以上适合大规模分发和录播场景。从生态兼容性角度分析RTMP和HLS的设备支持最为广泛几乎所有推流软件和播放器都能兼容WebRTC得到所有主流浏览器支持但在专业设备领域的支持相对较少SRT主要在专业广播设备中得到应用。协议的选择需要综合考虑延迟要求、规模需求、设备兼容性和运维复杂度等因素。RTMPReal-Time Messaging ProtocolAdobe公司开发的实时消息传输协议长期以来是直播领域的事实标准。基于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之上的明文协议使用端口1935RTMPT封装在HTTP请求之中可穿越防火墙RTMPS类似RTMPT但使用的是HTTPS连接HLSHTTP Live StreamingApple公司推出的自适应流媒体传输协议基于HTTP协议实现具有良好的穿透性和兼容性。HLS将媒体内容切分为小文件片段通常为2到10秒通过M3U8播放列表文件进行组织客户端通过不断请求最新片段来实现播放。这种基于HTTP的设计使得HLS可充分利用CDN进行分发天然支持大规模并发。HLS的延迟通常在10到30秒之间这主要源于其设计理念——优先保证稳定性和兼容性而非实时性。HLS采用TCP传输能够在不可靠的网络环境下保持较好的播放体验。为降低延迟Apple后来引入LL-HLSLow-Latency HLS扩展通过预请求和_PART标签将延迟降低到3秒左右。但LL-HLS的支持尚不广泛实际部署存在兼容性考虑。HLS最初只支持TS容器格式后来Apple添加对fMP4Fragmented MP4的支持这使得HLS可与WebRTC共享相同的容器格式。LL-HLS进一步引入CMAFCommon Media Application Format支持推动不同传输协议之间的互操作性。在实际部署中许多平台同时提供HLS和DASH两种协议以最大化客户端兼容性。MPEG-DASHISO/IEC发布的国际标准与HLS类似也采用基于HTTP的自适应比特率流媒体技术。DASHDynamic Adaptive Streaming over HTTP采用更灵活的MPDMedia 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的封装也已经标准化大多数播放器都能识别和处理。相较于RTMPHTTP-FLV更容易穿透防火墙在复杂网络环境下具有更好的连通性。局限性不具备自适应码率能力无法根据网络状况动态调整视频质量。与WebRTC相比HTTP-FLV的延迟较高不适合实时互动场景。HTTP-FLV的播放需要Flash播放器或支持FLV的HTML5播放器在移动端的兼容性相对较差。在Web环境中通过flv.js库可将FLV流转换为MSEMedia Source Extensions进行播放。SRT官网Secure Reliable Transport的缩写由Haivision开发的一种开源GitHub3.6K Star934 Fork传输协议旨在解决传统RTMP/RTSP协议的局限性。基于UDP传输提供可靠性和有序性保证具备强大的NAT穿透能力。支持AES加密确保传输安全这与WebRTC的安全设计理念相吻合。核心优势在于其卓越的网络适应性采用ARQAutomatic Repeat reQuest机制进行丢包恢复通过握手过程协商传输参数能够在丢包率较高的网络环境下保持稳定的传输。延迟通常在500毫秒以下优于HLS和HTTP-FLV与WebRTC处于同一量级。还支持多路径传输可同时利用多条网络链路提升带宽和可靠性。SRT协议在专业广播领域获得广泛应用许多专业编码器和解码器都支持SRT输入输出。SRT的URL格式为srt://host:port支持参数化配置如延迟、加密密钥、带宽等。在公网传输场景下表现优异特别适合远程制作、直播推流等对延迟和可靠性有较高要求的场景。WHIPWebRTC-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推流。WHEPWebRTC-HTTP Egress ProtocolWHIP的互补协议用于WebRTC拉流的标准化。定义客户端通过HTTP API从媒体服务器获取WebRTC流的机制客户端发送HTTP请求获取SDP Answer建立接收端连接。WHEP支持单播和组播模式为大规模分发场景提供解决方案。OBS Studio从28.0版本开始支持WHIP协议用户可直接配置WHIP服务器地址进行WebRTC推流无需中转服务器。这种端到端的WebRTC推流路径可将延迟降低到200毫秒左右相较于传统的RTMP推流加WebRTC分发模式通常500毫秒以上有显著改善。RTCPRTP Control Protocol实时传输控制协议与RTP配合使用传输统计信息如带宽、丢包率、抖动等用于监控传输质量和进行拥塞控制。RTPReal-time Transport Protocol实时传输协议实际承载音视频数据的传输协议负责将媒体数据打包并通过UDP进行传输。RTP包包含时间戳、序列号、负载类型等信息支持媒体流的同步和丢包检测。支持多路复用可在同一连接上传输多路媒体流。SRTPSecure Real-time Transport Protocol安全实时传输协议在RTP基础上增加安全能力。旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran思科和Rolf Blom爱立信开发的并最早由IETF于2004年3月作为RFC3711发布。SRTCPSecure RTP Control Protocol安全实时传输控制协议也叫Secure RTCP为RTCP提供安全特性。在使用RTP或RTCP时使不使用SRTP或SRTCP是可选的但即使使用SRTP或SRTCP所有它们提供的特性如加密和认证也都是可选的这些特性可被独立地使用或禁用。唯一的例外是在使用SRTCP时必须要用到其消息认证特性。RTSPReal Time Streaming Protocol实时流协议由Real Networks和Netscape共同提出用于控制多媒体流传输的应用层协议通常与RTP配合使用。RTSP本身不传输媒体数据而是负责建立和管理会话支持播放、暂停、录制等控制操作。RTSP协议类似于多媒体的远程控制协议常用于IP摄像头、监控系统、媒体播放器等场景。RTSP在专业音视频领域有着广泛应用特别是在安防监控、广播制作、视频会议等场景。RTSP支持认证机制可实现推流和拉流的权限控制。RTSP基于UDP传输延迟较低但需要处理NAT穿透和防火墙问题。SDPSession Description Protocol会话描述协议为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供多媒体会话描述。会话目录用于协助多媒体会议的通告并为会话参与者传送相关设置信息SDP即用于将这种信息传输到接收端。SDP完全是一种会话描述格式不属于传输协议只使用不同的适当的传输协议包括会话通知协议Session Announcement ProtocolSAP、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个或多个会话属性行SIPSession 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试呼叫Trying180振铃Ringing200成功响应OK404用户不存在Not Found408请求超时Request Timeout486线路忙Busy HereSIP能够连接使用任何IP网络有线LAN和WAN、公共Internet骨干网、移动2.5G、3G和Wi-Fi和任何IP设备电话、PC、PDA、移动手持设备的用户从而出现众多利润丰厚的新商机改进企业和用户的通信方式。基于SIP的应用如VOIP、多媒体会议、push-to-talk、定位服务、在线信息和IM即使单独使用也会为服务提供商、ISV、网络设备供应商和开发商提供许多新的商机。MMSMicrosoft 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连接不成功则服务器试图使用MMSTMMST是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/LiveEventswindows_media_server是Windows Media服务器名而LiveEvents是发布点名。