WebRTC不是一种编程语言，也不是一个框架。它是一组浏览器原生支持的API，让两个设备之间可以直接传输音视频和数据，不需要中间服务器转发内容。Chrome、Firefox、Safari、Edge全都内置了它。你的手机浏览器打开一个网页，就能和另一台设备上的浏览器建立点对点的连接——这听起来像魔法，其实是数学和协议堆出来的工程奇迹。
我最初接触它是在2020年做在线教育项目时。当时团队在纠结用第三方SDK还是自研，最后选了WebRTC，因为它的延迟能压到400毫秒以内。第三方服务商往往要经过他们的服务器中转，多一跳就多几十毫秒，对实时互动来说，体感差异很大。WebRTC的核心理念就是绕开那些中转，让数据走最短路径。
它的实现过程相当硬核。首先，两个设备得互相找到对方——这叫信令。WebRTC本身不定义信令协议，你可以用WebSocket、HTTP轮询甚至鸽子传书来实现。找到之后，它要穿透NAT和防火墙。大多数设备都在路由器后面，没有公网IP。这时候STUN服务器帮设备发现自己的公网地址，如果穿透失败，TURN服务器就作为中继兜底。但TURN只转发加密数据，不能窥探内容。
真正让我觉得惊艳的是它的自适应能力。网络抖动时，它会自动降低视频码率而不是卡顿。丢包了，它用前向纠错和重传机制恢复。这些策略在浏览器底层跑着，开发者根本不用关心。你只需要调用getUserMedia拿到摄像头流，RTCPeerConnection建立连接，RTCDataChannel传文件——三行核心代码就能跑通一个视频通话。
但WebRTC也有坑。它的API设计得很底层，像是给你一堆乐高零件而不是一个成品玩具。信令交换、连接状态管理、设备切换、回声消除、带宽估计——所有细节都要自己拼。我见过很多团队在这里翻车，比如忘记处理SDP中的ICE候选，导致连接成功率只有70%。还有浏览器对H.264和VP8的编解码支持不一致，跨浏览器通话时要协商半天。
另一个现实问题是移动端。iOS的Safari对WebRTC的支持比Chrome晚了好几年，而且内存占用高得吓人。我在低端安卓机上测试过，同时开三个视频流，页面直接被杀掉。不过这些问题正在好转，苹果在iOS 14.3之后对WebRTC的优化明显改善，谷歌也在推AV1编解码来省带宽。
WebRTC真正改变的是应用形态。以前做直播需要推流到CDN，观众看的是延迟几秒的流。现在用WebRTC，主播和观众之间延迟不到一秒，弹幕和礼物能实时互动。医疗上，远程手术指导需要看到毛细血管级别的细节，WebRTC配合1080P60帧完全够用。甚至有人用它做P2P CDN，让用户之间互相分享内容，减轻服务器压力。
说到底，WebRTC把实时通信能力从专业软件下沉到了浏览器里。过去要装Zoom、装Teams，现在打开网页就能开会。这个转变不只是技术上的，更是产品思维上的——通信功能变成了网页的一个模块，可以随意嵌入任何业务场景。我最近在做一个二手交易平台，买家看商品时想直接视频验货，用WebRTC十分钟就接好了。放在五年前，这得专门开发一个App。
它不完美，调试工具稀疏，文档晦涩，跨浏览器兼容性还得靠polyfill。但方向是对的：让实时连接像打开网页一样简单。下次你打开一个网页视频会议，记得里面那套复杂的ICE协商、DTLS加密、SRTP传输，全都在毫秒级完成了。这玩意儿，确实有两把刷子。