引言：实时音视频的协议丛林
WebRTC(Web Real-Time Communication)并不是某一单一技术，而是一个协议族的集合。与HTTP的请求-响应模型不同，WebRTC需要在浏览器之间建立直接的媒体传输路径(DataChannel用于数据、RTP用于音视频)。这种P2P模型穿越的不是简单网络拓扑，而是多层NAT和防火墙构建的复杂边界。
1. 整体协议栈概览
WebRTC完整协议栈分为三层：应用层(媒体处理)、会话层(连接建立)、传输层(数据发送)。
┌──────────────────────────────────────────────────────────┐
│ 应用层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ VP8/9/HV │ │ Opus/PCM │ │ DataCh. │ │ FEC/RED ││
│ │ 视频编解码│ │ 音频编解码│ │ 数据通道 │ │ 前向纠错 ││
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘│
├──────────────────────────────────────────────────────────┤
│ 会话层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ ICE │ │ DTLS │ │ SCTP │ │ SDP ││
│ │ 连接建立 │ │ 密钥协商 │ │ 数据通道 │ │ 会话描述 ││
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘│
├──────────────────────────────────────────────────────────┤
│ 传输层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ RTP │ │ RTCP │ │ SRTP │ │ UDP ││
│ │ 媒体传输 │ │ 传输控制 │ │ 加密传输 │ │ 网络层 ││
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘│
└──────────────────────────────────────────────────────────┘2. NAT穿透：ICE框架的工程实现
NAT有四种主要类型，穿透难度递增：
- Full Cone NAT：内网主机映射为公网IP:Port后，任何外部主机都可以向该地址发送数据包
- Restricted Cone NAT：只有通信过的外部IP可以发送数据包(不限制端口)
- Port Restricted Cone NAT：只有通信过的外部IP:Port可以发送数据包
- Symmetric NAT：同一内网主机访问不同外部地址时映射到不同的公网Port，穿透难度最高
ICE(Interactive Connectivity Establishment)框架整合多种地址收集策略：
ICE候选地址收集:
1. 主机候选(Host Candidate) - 本地网络接口IP地址
2. 反射候选(Server Reflexive Candidate) - 通过STUN服务器发现的公网映射地址
3. 中继候选(Relayed Candidate) - TURN服务器分配的中继地址
4. 对等反射候选(Peer Reflexive Candidate) - 在对端发现的映射地址ICE通过连通性检查确定最佳路径：将各候选地址按优先级排序，使用STUN Binding Request进行探测。当双方通过某种候选对成功交换Binding时，该路径被选为有效媒体路径。
STUN/TURN协议工作原理
STUN用于获取NAT后的公网地址，TURN是穿透失败的保底方案：
STUN流程:
1. A向STUN服务器发送Binding Request
2. STUN服务器在Response中携带XOR-MAPPED-ADDRESS
3. A获得自己的公网地址(pub_ip:pub_port)
4. A通过信令服务器将公网地址告知B
5. B直接向pub_ip:pub_port发送包
6. 若双向连通，则P2P通道建立
TURN流程(当P2p不通时):
1. A向TURN服务器(Allocate)请求分配中继地址
2. TURN服务器分配relay_addr给A
3. A通过信令服务器将relay_addr告知B
4. B通过TURN的ChannelData/Send向relay_addr发送数据
5. TURN服务器将数据转给A(增加一跳延迟和服务器带宽成本)3. 媒体传输层：RTP/RTCP与SRTP
RTP负责承载音视频媒体数据。关键字段包括：
- Sequence Number：包排序和丢包检测
- Timestamp：媒体采样时间戳，供接收端做音视频同步
- SSRC：同步源标识，区分RTP会话中的不同媒体流
- Payload Type：标识编码格式(如Opus为111，H264为96-127)
RTCP负责传输质量反馈：SR(发送端报告)和RR(接收端报告)携带丢包率、往返延迟、抖动等统计信息，是拥塞控制算法的关键输入。
SRTP(Secure RTP)强制所有媒体传输加密：使用HMAC-SHA1做认证(32-bit auth tag)，AES-CTM/GCM模式做加密，重放保护通过滑动窗口实现。WebRTC不允许明文RTP。
4. 拥塞控制：GCC算法
WebRTC不能简单照搬TCP的Loss-Based拥塞控制(音视频要求低延迟)。GCC(Google Congestion Control)是当前默认方案，由两个控制器组成：
- 延迟控制器(Arrival-time Filter + Overuse Detector)：基于排队延迟梯度检测拥塞。使用Kalman滤波器从延迟梯度估计可用带宽
- 丢包控制器(Loss Controller)：基于丢包率做微调。连续丢包超过阈值时降速，低于阈值时小幅提速
GCC在带宽利用率与延迟之间保持平衡。新发展的替代方案包括SCReAM(Self-Clocked Rate Adaptation for Multimedia)和BBR在实时媒体的适配，前者在Wi-Fi弱网场景响应更快。
5. 编解码器与自适应码率
WebRTC支持的编解码器：
- 视频：VP8(开源免版税，广泛支持)，H264(硬件编码支持好，Constrained Baseline Profile)，AV1(压缩效率提升30%但编码复杂度极高)
- 音频：Opus(事实标准，6kbps到510kbps全码率范围，PLC内置)
WebRTC实现了自适应码率控制：根据GCC输出动态调整编码参数。调节优先级为：先降帧率(30fps→15fps→5fps)，仍不足时降分辨率(720p→480p→360p)，最后降至最低保障码率。
NetEQ是Google开发的WebRTC核心音频引擎：实现抖动缓冲(Jitter Buffer)和丢包隐藏(PLC)，动态调整播放缓冲深度来吸收网络抖动。
6. 多人会议架构：Mesh/SFU/MCU
WebRTC的多人会议有三种拓扑：
- Mesh(P2P全连接)：复杂度O(n^2)，仅适合3-4人
- MCU(Multipoint Control Unit)：服务器混合多路音视频为单路流
- SFU(Selective Forwarding Unit)：服务器仅转发流，不做编解码。当前主流方案
SFU的核心优化技术：
- Simulcast：发送端同时编码多路分辨率(高中低)，SFU按需转发最合适的一路
- SVC(Scalable Video Coding)：在编码端通过分层编码达到类似Simulcast效果
- 带宽分配：决定多个远端观众的接收优先级
- Temporal Layer Selection：根据可用带宽选择性丢弃时域分层
7. DataChannel与SCTP
DataChannel基于SCTP-over-DTLS-over-UDP，提供可靠/有序或不可靠/无序两种传输模式。关键特性：多复用流(Multistreaming)在单ICE连接上复用多条逻辑流，避免行首阻塞。
WebRTC未指定信令协议(允许WebSocket/SIP等)。信令负责交换SDP Offer/Answer(媒体协商)、ICE候选、DTLS指纹。
8. 总结与展望
WebRTC将复杂P2P媒体工程封装为简洁JavaScript API，使任何Web应用都能快速实现实时音视频。其协议栈每层的选择(强制DTLS、GCC拥塞控制、ICE候选排序)都体现了对低延迟的系统性优化。
下一代方向：WebTransport(基于QUIC的轻量级传输)作为DataChannel替代、超低延迟直播、云游戏、以及WebCodecs/WebTransport组合绕过部分WebRTC原生栈以获得更灵活的底层控制。这预示着一个更开放的实时通信生态。
发表评论 取消回复