网页端实时音视频服务架构与实践
最近一直在研究网页端实时音视频这块业务，从调研技术方案、搭Demo，到踩坑商用化的各种问题，算是把WebRTC和网页实时通信的架构、痛点摸了个遍。今天就以一个一线开发者的视角，跟大家聊聊：网页端实时音视频到底是什么、能做什么、技术成熟度如何、架构该怎么选，以及从Demo落地到商用服务，我们到底要面对哪些真实难题。
一、先聊点直观的：网页端实时通信，到底好在哪？
做了这么多年前端和网页应用，我切身感受到网页端实时通信和移动端、PC客户端完全不是一个逻辑，它的核心优势其实特别贴合当下的产品需求：
浏览器原生能力强，体验底子好
现在的浏览器获取音视频、渲染画面的能力越来越强，高清通话、大屏展示都能hold住。而且PC端屏幕大、视窗灵活，不管是主播开播、多房间监控，还是会议画面展示，网页端的先天优势很明显。真正的跨平台，一套代码跑多端
不管是PC浏览器、手机浏览器，还是微信、各类APP里的内置Webview，只要浏览器支持，就能跑通。不用为不同系统单独开发，这对我们开发来说太省心了。免安装，零门槛接入
这是最核心的一点。以前做网页实时通信，要么装插件，要么装客户端，用户门槛极高。而WebRTC普及后，不用插件、不用安装，打开网页就能用，用户体验直接上一个台阶。
二、这些场景，网页端实时音视频是真的香
结合我们项目的实际落地情况，网页实时通信的应用场景非常明确，而且都是刚需：
直播场景
主播用网页开播，大屏清晰、处理能力强，不用装推流客户端；还有直播监控，一个网页能同时看40-50个房间，做直播巡检再合适不过。在线教育
老师基本都用PC，让他们装客户端、配环境太麻烦了。网页免安装方案完美解决这个问题，再加上H5的屏幕共享、白板，和Web SDK集成无缝衔接，教学体验直接拉满。视频会议 & 企业协作
以前的视频会议操作复杂、安装繁琐，现在WebRTC一键入会，远程医疗、企业内部协作都能轻松覆盖。
可以说，只要是低门槛、跨平台、实时互动的场景，网页端音视频都是最优解。
三、灵魂拷问：2017年，WebRTC真的成熟了吗？
刚接触这块的时候，我和很多开发者一样，心里打鼓：WebRTC到底能不能商用？会不会半途而废？浏览器支持到底怎么样？
调研完一圈，我可以很肯定地说：WebRTC已经准备好了，正处在最好的时代。
浏览器支持：除了IE，全覆盖
去caniuse上一查就清楚，Chrome、Firefox、Edge、国内各大套壳浏览器，全都支持WebRTC，只有IE（市场份额8%左右）不支持，完全不影响商用。协议栈：WebRTC 1.0 基本定稿
标准已经稳定，各大浏览器厂商的兼容度越来越高，不用再担心标准变来变去。开源生态：可选的轮子非常多
我们调研了几个主流开源项目，直接能搭架构：- Kurento：功能强，支持转码、OpenCV，适合做媒体服务器
- Licode：轻量，纯转发模式，上手简单
- Janus：轻量网关，适合做信令和媒体转发
甚至还有React-Native-WebRTC，前端JS开发者也能轻松在移动端做WebRTC应用。
商业生态：CPaaS赛道已经成熟
声网、Twilio、Tokbox这些厂商都在做WebRTC相关服务，市场也极度看好。
不管是技术标准、开源支持，还是商业落地，WebRTC在2017年已经完全具备商用能力。
四、从Demo到产品：我踩过的WebRTC架构坑
很多刚接触WebRTC的开发者，都会和我一开始一样：产品说要做个WebRTC系统，直接上手写个P2P点对点的Demo，觉得完事了。
但真正做下来才发现，架构选错，直接没法商用。WebRTC的架构一共分三代，我挨个踩了一遍：
1. 纯P2P架构：爽是爽，商用根本不行
最基础的方案，用户之间直接传流。
- 优点：延时极低
- 致命缺点：每个用户要给所有对端发自己的流，上行带宽压力爆炸；而且每个流都要单独采集编码，浏览器CPU直接拉满。
行业统计也很真实：纯P2P的WebRTC系统，只占19%。
我们一开始做的多人通话Demo，超过3个人就卡到没法用，直接被产品打回。
2. SFU转发架构：解决上行痛点，是目前主流
为了解决P2P的问题，我们引入了媒体服务器做转发，也就是SFU架构。
- 原理：每个用户只上传1路流到服务器，服务器转发给所有接收端
- 优点：极大节省上行带宽，延时影响小
- 缺点：服务器只转发不转码，下行终端带宽不一样（比如有人500K，有人2M），没法适配，差网用户直接看不了。
Licode、Janus这些开源项目，都是典型的SFU方案，也是我们目前项目的主力架构。
3. MCU混流架构：完美适配下行，但成本高
为了解决SFU的下行适配问题，就要在服务器做混流+转码：
- 原理：服务器解码所有流，拼接合成后再编码，根据不同终端的带宽发不同画质的流
- 优点：完美适配多终端下行，多用户场景体验好
- 缺点：转码增加延时，服务器成本极高
三种架构，从P2P到SFU再到MCU，是WebRTC从Demo走向商用的必经之路，没有最优解，只有适合自己业务的方案。
五、真实商用：这些技术难点，Demo里永远不会告诉你
架构搭完，以为能上线了？真正做商用服务，才发现隐藏的坑多到离谱，这也是我们团队花了大量时间攻克的点：
可用性问题：P2P打洞、穿透太难了
WebRTC基于P2P，内网穿透、NAT打洞成功率直接影响通话可用性，这是一直以来的痛点，没有成熟的经验根本搞不定。平台互通：和自研协议兼容，坑无数
很多老项目、Native端都是自研的音视频协议，要和WebRTC互通，端到端的传输策略、RTCP优化，全是匹配工作，极其繁琐。编码器选择：VP8和H.264的两难
WebRTC支持VP8/9、H.264。H.264移动端适配好，但Chrome上不成熟；商用产品大多还在用VP8，一涉及移动端互通，编码器选型就很头疼。弱网对抗：浏览器+服务器，上下行要分别优化
WebRTC自带丢包重传、FEC、码率调整，但弱网下必须靠转发节点做链路优化，上行、下行分别调优，少一步都不行。多用户场景：人多画面直接糊
多人通话/直播场景，接收端超过4-5个，WebRTC的发送码率会被压得极低，画面模糊到没法看，这是原生策略的硬伤。
浏览器兼容、传输优化、多端适配……从Demo到商用，每一步都是坎。
六、最后说说我们的项目：旧方案必淘汰，WebRTC是未来
结合我们自己的直播项目，目前还是浏览器插件+客户端采集的混合方案，体验差、维护成本高，用户也不买账。
通过这段时间的调研和实践，我可以很确定地说：这种旧方案，未来两年一定会被彻底淘汰。
想要做体验更好、零门槛、跨平台的网络直播和实时音视频服务，我们必须提前布局：要么基于开源项目自研，要么接入第三方成熟的WebRTC SDK，把插件、客户端的包袱彻底丢掉。
最后总结一句：
网页端实时音视频，WebRTC是唯一的最优解。从Demo到商用，拼的不是会不会写代码，而是音视频专业能力、传输优化经验、架构设计能力。只有专业的团队，才能做出真正稳定、可用的实时音视频服务。
也希望和更多做WebRTC、实时音视频的同学交流，一起踩坑，一起成长。