WebRTC把视频通话做成"相亲流程"：8步拆解后，开发者集体沉默了

全球每天有35亿分钟视频通话通过浏览器完成，但90%的开发者第一次看WebRTC文档时，会被SDP、ICE、STUN、TURN四个缩写直接劝退。

这不是技术门槛，是表达方式的问题。当你把WebRTC想象成两个陌生人相亲，整个流程突然变得像常识一样简单。

第一步：先找个中间人传话

浏览器不会直接握手。Rahim（工程师）和Aisha（产品经理）同时连上一个"会议协调员"——这叫信令服务器（Signaling Server）。

信令服务器不干别的，只负责递纸条。

两人先交换家底："我有摄像头、麦克风，支持这些格式。"这份自我介绍叫SDP（会话描述协议）。Rahim把SDP塞进WebSocket发给服务器，服务器转给Aisha；Aisha也一样回一份。双方确认"能聊"，但还没真正连上。

这个阶段像相亲前的资料交换——知道对方存在，但没见过面。

第四步：发现根本找不到对方

真正的麻烦才开始。Rahim在家用WiFi，Aisha在公司内网，两台电脑都不知道怎么直接找到彼此。NAT（网络地址转换）和防火墙把内网IP藏得严严实实，就像两个人都在密室，互相不知道门牌号。

这时候需要STUN服务器出场。

STUN像个查号台。Rahim问："我在互联网上看长什么样？"STUN回："你公网地址是103.xx.xx.xx:54321。"Aisha也得到自己的公网地址。两人交换这个信息，尝试直接连——这叫ICE（交互式连接建立）候选地址交换。

第六步：实在连不上，只能走中继

直接连接有时成功，有时失败。公司防火墙、对称NAT、端口限制……各种原因会让直连泡汤。这时候启动Plan B：TURN服务器。

TURN是个中转站。两人把视频流先发给TURN，TURN再转发给对方。延迟增加几十毫秒，成本上升（流量费×2），但保证能通。就像相亲双方被隔在两间屋子，只能通过对讲机说话。

代码层面，这一切被封装在RTCPeerConnection里：

const pc = new RTCPeerConnection({
iceServers: [
{ urls: "stun:stun.l.google.com:19302" },
{ urls: "turn:your-turn-server.com", username: "user", credential: "pass" }
]
});

STUN免费，TURN烧钱。产品决策的关键：你的用户有多少在企业内网？

第八步：视频终于亮了

ICE候选交换完成，连接建立，ontrack事件触发。Rahim的摄像头画面出现在Aisha的video元素里，反之亦然。从打开网页到画面出现，理想情况下300毫秒内完成。

整个过程的核心就三句话：信令服务器牵线，STUN查公网地址，TURN保底中继。其他都是浏览器自动处理的细节。

但大多数教程不会告诉你的是：WebRTC的"简单"是有代价的。信令服务器要自己搭，TURN服务器按流量计费，移动端耗电像倒水，大规模会议还得换SFU（选择性转发单元）架构。那个"简单"的demo，离生产环境还有十个坑要填。

当你下次听到有人说"WebRTC很简单"，可以反问：你指的demo，还是月活百万的会议产品？