大讲堂
浏览器里跑了15年的“隐形管道”
很多人对WebRTC的印象停留在“免费开源的音视频SDK”，错得离谱。WebRTC本质上是浏览器内核原生内置的实时传输栈——你打开Chrome的开发者工具，在网络面板里翻半天，都找不到它传数据的HTTP请求，因为它根本不跟传统的HTTP服务器打交道。 从2008年Google把Gtalk的实时通信代码捐给W3C开始，这套技术就已经在所有主流浏览器的内核里悄悄迭代。核心逻辑其实很简单：不需要装插件，不需要下载客户端，只要打开一个网页，就能调用摄像头、麦克风，通过P2P直连的方式，把实时的音视频流传给对面的人。
为什么免费的东西，最后卖得比付费的还贵
很多人刚接触WebRTC的时候，都会有个错觉：既然开源免费，那为什么市面上还有那么多公司在卖实时音视频服务？ 说白了，原生WebRTC的能力，只够跑通1对1的理想场景。真到了真实的产业环境里，坑多到能把人埋了。 比如NAT穿透的成功率。在国内的网络环境下，三大运营商的NAT层级能做到三四层，还有大量企业内网把所有UDP端口封死，这时候STUN服务器根本拿不到有效的公网映射，P2P直连直接失败。按照公开的测试数据，国内网络环境下，原生WebRTC的P2P直连成功率最高也就60%，剩下的40%必须靠TURN服务器中转，带宽成本是实打实的钱。
现在的WebRTC，早就不只是用来打视频电话了
最近两年我跑了很多产业场景，发现WebRTC的应用边界，早就超出了“视频通话”的范畴。 比如远程医疗场景。之前那个客户最后选了基于WebRTC的轻量化方案——患者不用下载APP，打开个微信里的链接，就能和医生高清连麦做复诊，对不会操作智能手机的老年人太友好了。整个系统的成本，比之前对接的云厂商方案降了80%。 再比如工业互联网场景。现在很多长三角的制造工厂，给一线巡检工人配了AR眼镜，第一视角的设备画面通过WebRTC实时传到后台的专家端，专家不用跑几百公里的现场，就能远程指导工人排查设备故障。上个月去苏州看一个做工业AR的团队，他们说靠这套方案，一年能帮合作的工厂省几千万的差旅和运维成本。
未来3年，WebRTC要啃下的三块硬骨头
我对未来3-5年的WebRTC生态，其实没有那么乐观，但也绝对不悲观。 第一块硬骨头是标准收敛。现在Google自己维护的WebRTC开源代码，已经加了几百个私有优化，根本没进到W3C的正式标准里，其他浏览器厂商想兼容，就得跟着抄代码。如果未来3年标准收不住，整个生态就会变成各家各玩各的，最后所有开发者都要为兼容成本买单。 第二块硬骨头是和端侧AI的融合。现在的WebRTC传的是原始的音视频流，未来它要传的是经过端侧AI处理的实时流——比如你打开一个网页开线上会议，摄像头拍的画面直接在本地做背景虚化、语音转写、会议纪要生成，所有处理都在你的电脑上完成，不用把内容传到云端，WebRTC就是连接这些本地AI模块的高速通道。 第三块硬骨头是合规落地。现在国内的监管要求和WebRTC原生的隐私设计，其实是有冲突的。未来肯定会出现一套符合国内监管要求的合规WebRTC方案，在保障用户端到端隐私的基础上，加一个可控的内容审核节点，平衡隐私保护和公共监管的要求。 前几天翻到2015年第一次写WebRTC demo的代码，满屏幕的注释写的是“要让浏览器成为万能的实时通信终端”。快10年过去了，这个目标其实已经实现了一大半。很多人说开源的技术没有商业价值，但是WebRTC偏不——它把实时通信的门槛从百万级的研发成本，压到了几千块的服务器成本，现在哪怕是一个刚毕业的学生，花一下午时间，就能在自己的博客里加一个1对1的在线咨询功能。 这种东西，你说它没有价值？ 才怪。作者|fawen
排版|fawen
审核|小准