7.5.2 WebRTC：RTP 的正统继承者（WebRTC & The Real-Time Heir）
7.5.1 的结尾预告了一位口味完全不同的主角：它不要秒级的 "直播"，要的是毫秒级的 "对话"。这位主角就是 WebRTC。7.2.4 已经讲过它如何为 RTP 补齐 NAT 与信令两块时代短板，本节换个视角，端详它的全貌——一副由熟面孔拼成的协议栈。
一副全是熟面孔的协议栈
WebRTC 最令人称奇的地方在于：线上几乎没有一个新协议。它是一次对既有 IETF 协议的精心编选与组合 [9]：
| 职责 | 协议 | 备注 |
|---|---|---|
| 媒体传输 | SRTP（RFC 3711） | 加密版 RTP，强制使用——7.2 的序号、时间戳、RTCP 反馈全套保留 |
| 连接建立 | ICE（RFC 8445）+ STUN + TURN | 候选收集与连通检查，7.2.4 已详述 |
| 密钥协商 | DTLS | UDP 之上的 TLS 握手，导出 SRTP 密钥 |
| 数据通道 | SCTP over DTLS（RFC 8832） | 任意双向数据，文件、消息皆可 |
| 复用优化 | rtcp-mux（RFC 5761）、Trickle ICE（RFC 8838） | RTP/RTCP 同端口；候选边收边发 |
一次通话的建立流程，就是这副栈的依次点亮：
信令走什么通道？规范依旧不答——7.2.4 说过的那个深思熟虑的留白，SDP 经 WebSocket、HTTP 还是别的什么送达对端，协议栈一概不管 [9]。
两个标准化组织，一套分工
WebRTC 的规范身份有一处常考的细节：它由两个组织分别定义。IETF 负责线上的协议套件——RFC 8825 便是这侧的总览，把自己的角色说得很清楚：一组能通过浏览器 JavaScript API 访问、合起来足以支撑浏览器间实时音视频的 "building blocks" [9]；W3C 负责那组 API 本身——getUserMedia 采集音视频、RTCPeerConnection 管理连接，2021 年 1.0 推荐标准落地。协议线与 API 线汇合之处，开发者用几十行 JavaScript 就能在网页里拉起一路加密实时通话——这在 Flash 时代是不可想象的。
直播场景里的 WebRTC：连麦与低延迟分发
放进直播的坐标系，WebRTC 的角色清晰起来：亚秒级延迟 让它成为连麦互动、在线课堂、实时通信的首选——主播与观众的 "对话" 场景里，没有第二种主流方案能把延迟压到这个量级。它与 HLS/RTMP 并非替代关系而是分工：一对多的大规模分发交给 HTTP 系，少数人的实时互动交给 WebRTC，直播间里 "万人看 HLS、连麦走 WebRTC" 的混合架构已成常态。
代价同样直白：实时互动的服务端不再是静态文件分发，每一路媒体都要经过实时转发，SFU 这类转发架构的带宽与算力成本随在线人数线性增长——互动注定是属于 "少数人" 的奢侈，人数一上万，还得请 HLS 回来救场。
小结
WebRTC 是 7.2 埋下的伏笔最圆满的回响：RTP 的骨架原封未动，ICE、DTLS、SRTP 三件新衣一穿，三十年前的框架在浏览器里重获新生。而 UDP 低延迟这条路上还有另一位选手，它的目标不是双向互动，而是把高码率信号可靠地送过公网弱网——下一节，SRT 与它的 ARQ 药方。