当你入门 WebRTC 之后，很快就会接触到一个名词，叫做：SFU，你可能很容易就在网上寻找到很多 SFU 的开源实现，并并兴致勃勃地开始编译、部署和测试这些服务器，但是可曾想过，为啥我们的 WebRTC 应用需要 SFU 服务器 ？
如图是 WebRTC P2P 模式下的网络拓扑结构，ClientA 和 ClientB 如果能够顺利建立 P2P 的连接，则可直接通过 P2P 互相交换数据。如果由于某些网络环境原因，无法成功打通 P2P 连接的话，则可以通过一台 TURN Server 来中转数据给对方。
这个 TURN Server 是指支持 TURN 协议 的服务器，它扮演着一种网络中继的角色，支持把一个 Client 的数据包透明转发到多个其他的 Client 客户端。
在这种简单的 P2P 通话场景下，其实这种模型基本够用了，根本不需要架设什么 SFU 服务器。
下面我们再近一步，看看多人通话的场景：
如图所示，多人通话跟单人通话唯一的不同就是每个客户端都需要跟其他两个端都分别建立 P2P 连接，我在《WebRTC 开发实践：从一对一通话到多人会议》也介绍过这个场景。与一对一通话一样，如果两个端能够顺利建立 P2P 的连接，则直接通过 P2P 互相交换数据；如果无法打通，则利用 Turn Server 来中转数据。
我们把这种完全使用 P2P 方式的网络拓扑结称之为 Mesh 结构，下面我们谈谈它的优劣点。
逻辑简单，容易实现
服务端比较 “轻量”，TURN 服务器比较简单，一定比例的 P2P 成功率可极大减轻服务端的压力
每新增一个客户端，所有的客户端都需要新增一路数据上行，客户端上行带宽占用太大。因此，通话人数越多，效果越差
无法在服务端对视频进行额外处理，如：录制存储回放、实时转码、智能分析、多路合流、转推直播等等
由此可以看到，mesh 结构的缺点影响还是比较大的，真正商业化的应用，是需要具备良好的通话质量、服务稳定性和可扩展性的，因此，亟需一种新的网络拓扑结构，能够很好的规避 mesh 结构的这些短板。
SFU 的全称是：Selective Forwarding Unit，是一种通过服务器来路由和转发 WebRTC 客户端音视频数据流的方法。
如图所示，SFU 服务器最核心的特点是把自己 “伪装” 成了一个 WebRTC 的 Peer 客户端，WebRTC 的其他客户端其实并不知道自己通过 P2P 连接过去的是一台真实的客户端还是一台服务器，我们通常把这种连接称之为 P2S，即：Peer to Server。除了 “伪装” 成一个 WebRTC 的 Peer 客户端外，SFU 服务器还有一个最重要的能力就是具备 alt="WebRTC 开发实践：为什么你需要 SFU 服务器">
这种网络拓扑结构，被称之为 MCU，它的特点是，由 MCU Server 将各路客户端上行的视频流合成为一路，再转发给其他客户端。这种模型相比于 SFU 降低了多人视频通话场景下客户端的下行带宽压力，但是由于合流需要转码操作，对服务器端压力比较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。
综上所述，纯 mesh 方案无法适应多人视频通话，也无法实现服务端的各种视频处理需求，最先排除在商业应用之外。
SFU 相比于 MCU，服务器的压力更小（纯转发，无转码合流），灵活性更好（可选择性开关任意一路数据的上下行等），受到更广泛的欢迎和应用，常见的开源 SFU 服务器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等，各有特点，大家可以去项目主页了解更详细的情况。
当然，也可以组合使用 SFU + MCU 的混合方案，以灵活应对不同场景的应用需要。
关于 WebRTC SFU 相关知识点就分享到这里了，如有疑问的小伙伴欢迎来信 lujun.hust@gmail.com 交流。另外，也欢迎大家关注我的新浪微博 @卢_俊 或者 微信公众号 @Jhuster 获取最新的文章和资讯。
