![]()
全球每天有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,还是月活百万的会议产品?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.