实时音视频RTC服务架构现代 RTC 系统通常采用“信令与媒体分离”的双通道设计信令服务器 (Signaling Server)负责传输控制类指令如呼叫建立、SDP 交换、房间状态同步。通常使用WebSocket实现全双工通信确保控制消息不丢失。因信令不涉及媒体数据可独立于媒体服务器部署。媒体处理转发系统流媒体服务器负责接收、处理和转发音视频流。主流架构SFU (选择性转发单元)是目前的主流选择。它只转发媒体包不进行编解码混流因此延迟低、CPU消耗小。通过支持Simulcast技术SFU能根据每个接收端的网络状况智能选择最合适分辨率的流进行转发优化弱网体验。NAT穿透服务器 (STUN/TURN)连接可靠性的“最后防线”STUN (简单UDP穿透NAT)轻量级服务帮助客户端发现其公网IP和端口。但对对称型NAT无效。TURN (使用中继穿透NAT)当直连失败时作为媒体流的中转站保证连接成功。由于TURN需要处理媒体数据流量部署时需考虑带宽成本和全球分布式节点布局以降低延迟WebRTCWeb Real-Time Communication网页实时通信W3C IETF 标准、Google 开源浏览器 / 客户端原生内置的实时音视频 数据传输协议栈不需要插件底层默认 UDP 低延迟传输、强制加密。WebRTC 是客户端能力标准SFUmediasoup/MediaSFU是服务端转发架构。三大核心 APIJS 层面getUserMedia / getDisplayMedia获取摄像头、麦克风、屏幕共享媒体流RTCPeerConnection核心管理连接SDP 协商、ICE 打洞、DTLS 加密、RTP 媒体收发、带宽评估 BWE、NACK 丢包重传RTCDataChannelUDP 可靠 / 不可靠二进制通道用来传文字、文件、指令、白板数据不经过音视频核心底层协议栈SDP会话描述协商双方能力支持什么编码、分辨率、采样率等Offer/AnswerICE STUN TURNNAT 内网穿透STUN拿到本机公网 IP优先尝试 P2P 直连TURN直连失败时数据包走服务器中继兜底Coturn 就是常用 TURN 服务DTLS-SRTP强制加密RTP 音视频数据包加密传输RTP/RTCP媒体包封装 网络反馈带宽、丢包、延迟用来动态调码率SCTPDataChannel 底层传输实时音视频RTC服务架构主流架构有以下几种音视频数据的流动路径、处理方式、支持的并发规模以及最终的用户体验如延迟、画质、流畅度Mesh 架构点对点P2P架构MCU 架构多点控制单元架构SFU架构选择性转发单元架构Selective Forwarding Unit选择性转发单元是目前最流行的实时音视频通信架构。只转发流不解码合成性能高多人会议首选混合架构Hybrid Architecture技术选型对比维度mediasoupZLMediaKitSRS核心定位专业 WebRTC SFU 底层库专注多人实时音视频通话全能流媒体网关框架主打多协议互转、安防 / 车载设备接入轻量化直播服务器互联网大规模低延迟直播、连麦语言架构C Worker Node/Rust 上层 API多 Worker 隔离扩容C11多线程异步 IO跨平台ARM / 国产芯片友好C单进程事件驱动集群 / 边缘成熟WebRTC 能力⭐⭐⭐⭐⭐原生 SFU、Simulcast/SVC、TWCC、NACK、DataChannel多人会议最优⭐⭐⭐⭐支持 WebRTC 推拉流但不是强 SFU 设计多人会议适配弱⭐⭐⭐⭐新版支持 WHIP/WHEP、SFU 模式适合直播连麦复杂多人会议弱协议栈WebRTC、裸 RTP不擅长传统流媒体协议最全RTSP/RTMP/HLS/HTTP-FLV/GB28181/WebRTC任意互转RTMP/HLS/HTTP-FLV/SRT/WebRTC传统直播协议成熟开箱程度极低无内置信令、房间管理、录制业务层全自研中等自带 REST/API可快速做协议转发、设备接入高配置简单自带集群、转码、录制快速上线直播典型场景多人视频会议、在线课堂、多人实时协同、纯 WebRTC 互动安防监控、车载 JT1078、GB28181 设备接入、RTSP 转 WebRTC 网关秀场直播、低延迟大规模 CDN 分发、主播连麦开发成本高需要自研 WebSocket 信令、房间、鉴权、负载均衡中重点在业务逻辑协议转换底层成熟低少量配置即可跑通大规模直播社区生态海外强WebRTC 领域标杆国内资料偏少国内非常活跃安防 / 物联网圈大量落地国内最强直播行业大规模商用验证短板不支持 RTSP/GB28181 等传统设备接入开发量大多人 WebRTC 会议体验不如 mediasoupSVC / 多层流支持弱复杂多人会议30 人以上不推荐SFU 能力不如 mediasoup