聊聊WebRTC网关服务器2：如何选择PeerConnection方案？

《聊聊WebRTC网关服务器》系列文章系由WebRTCon2018中网易云信音视频技术专家的分享内容《从零开始构建音视频网关服务器》整理而成，该系列文章将和大家分享网易NRTC在WebRTC网关项目的自研过程中遇到的一些问题，以及我们最终的解决方法。

《聊聊WebRTC网关服务器》第二篇文章将和大家分享如何选择PeerConnection方案。

在会议场景下，网易NRTC的WebRTC网关使用的是SFU方案，如上图举例所示，每个WebRTC上行一路媒体数据到WebRTC网关服务器，同时还需要从网关接收下行的三路媒体数据，对于一个WebRTC客户端来说就有多路流。对于这种多流的场景，我们有两种PeerConnection方案可以使用：

1）单个PeerConnection里有多个media stream（bundle）；

2）为不同的media stream创建不同的PeerConnection。

那我们如何选择PeerConnection的方案呢？

首先我们来看看单PeerConnection方案，所有的客户端和服务器之间只需要建立一个PeerConnection，这个PeerConnection是一个双向的PeerConnection，它既可以发数据，也可以收数据，这个方案简单明了，实现时候要注意一个问题，就是Chrome和Firefox在实现单PeerConnection bundle时采用的SDP方案是不一样的。Chrome是用了Plan B的方案，Firefox是用了Unified Plan的方案。当然Chrome未来即将支持Unified Plan，而当前要使用单PeerConnection方案就必须在Server端编写兼容代码。PlanB采用的是一个m行，多个a行来描述多流，而Unified Plan是多个m行，描述多流，具体的做法RFC草案文档里面有详细描述，我这里就不赘述了。

那么单PeerConnection有什么优势呢？

1）Server端媒体处理代码相对简单；

2）服务端性能较好，只需要建立一个PeerConnection连接，DTLS握手只需要做一次。单PeerConnection又有什么劣势？

1）服务器需要编写兼容不同浏览器的代码；

2）不同用户的下行媒体流过多后，SDP里面m行或a很多，导致SDP长度过长；特别是当用户频繁进出或者媒体状态发生改变时，SDP需要进行频繁Update， SDP传输耗费的带宽就会很多；

3）Firefox Unified Plan在多人场景下，较高的概率下会出现崩溃Bug，我们已经向Firefox提交了bug。

而相对单PeerConnection，多PeerConnection的方案就比较便于理解了，如图A/B/C/D四个人的会，对于A来说有一个上行的PeerConnection，以及3个下行的 PeerConnection对应B/C/D。每一个用户的上下行数据都是分开的，这个也是WebRTC比较推荐的方案。

这个方案主要的难点是服务端要去维护每个用户的上下行PeerConnection对应关系，整体的代码逻辑较复杂。但是它的兼容性比较好。所以NRTC的WebRTC网关最终选择了多PeerConnection方案。

在分享完PeerConnecton的方案后，下面就进入Server的线程方案的选择和优化。这个也是网关服务器架构设计的核心部分。《聊聊WebRTC网关服务器》第三篇文章将具体为大家介绍如何优化Server的线程方案。