浏览器之间想直接传音频、视频和数据，靠的是WebRTC这套开放标准。它不需要插件，不需要原生应用，浏览器里已经内置了对应的API。但WebRTC只覆盖"媒体路径"这一段：一旦两个对等端互相找到了对方，从编解码器协商到编码再到传输，它全包了。

它从来不负责的，是"找到"这个动作本身。

打开网易新闻 查看精彩图片

这套规范由三个JavaScript API组成，而信令和NAT穿透被刻意留在了规范之外。理解这个缺口，以及它如何决定媒体本身的扩展方式，是看懂WebRTC规模化的关键。

三个API，一个缺口

WebRTC对外暴露的三个API分工明确：

  • RTCPeerConnection：在两个对等端之间协商编解码器，连接建立后负责媒体流的编码、解码和传输。
  • MediaStream：给它提供要发送的内容，封装对摄像头或麦克风的访问。
  • RTCDataChannel：与媒体连接并行运行，承载非音频视频的数据——聊天消息、文件分片、游戏状态，任何不需要编解码器的应用数据。

这三个API都不知道如何自行找到远端对等端。这正是WebRTC完全留白的那部分。

信令与offer/answer交换

两个对等端在交换媒体之前，必须先交换一份描述各自能力的信息：编解码器、网络信息、媒体类型，编码为SDP（会话描述协议）。WebRTC没有提供任何在对等端之间实际传递这份描述的机制。这就是信令，规范故意把它留给上层构建者，通常走WebSocket或HTTP长轮询。

交换本身遵循固定形态：发起呼叫的一方发出offer，接收的一方回以answer。整个流程里真正干活的只有setLocalDescription和setRemoteDescription两个调用，其余工作只是把SDP数据块从一个对等端的信令连接送到另一个对等端。

NAT穿透：ICE、STUN和TURN

SDP交换只告诉每个对等端对方"能做什么"，但大多数设备并不直接暴露在公网上，它们躲在NAT后面。要让媒体真正流动起来，还需要穿透这层地址转换，这部分由ICE框架配合STUN和TURN服务器完成。

STUN负责帮对等端发现自己在公网上的映射地址，TURN则在中继模式下转发流量，用于双方无法直连的场景。这三者构成了WebRTC连接建立的实际基础设施，而它们同样不在WebRTC规范之内。

拓扑决定媒体如何扩展

信令和穿透解决的是"连得上"的问题，但媒体本身怎么扩展，取决于选择哪种拓扑结构。三种主流方案各有取舍：

  1. 点对点（P2P）：对等端直接互连，延迟最低，但连接数随参与者增加呈平方级增长。
  2. 选择性转发单元（SFU）：服务器接收每个参与者的流，选择性转发给其他人，不混合媒体，兼顾质量和扩展性。
  3. 多点会议单元（MCU）：服务器混合所有媒体流再分发，客户端负担最轻，但服务器成本和延迟最高。

规模化的其他关键因素还包括：负载下的信令处理、浏览器支持差异、安全性以及可靠性。这些环节共同决定了WebRTC应用在用户量增长时能否稳住。