0.引言

本篇文章主要讲解前面关于webrtc和项目经验的总结。为了更好理解本篇文章，也给出了前面文章的参考列表，如下:

webrtc之一对一通话原理(1)

webrtc之一对一通话实战与原理(2)

webrtc之一对一通话实战与原理(3)

详细讲解webrtc原理(1)

WebRtC音视频通话之AppRTC实战(2)

WebRtC音视频通话之AppRTC实战(1)

手把手实现WebRtc一对一视频通话实战(7)

webrtc实战打开摄像头和麦克风

手把手实现WebRtc一对一视频通话实战(5)

手把手实现WebRtc一对一视频通话实战(1)

手把手实现WebRtc一对一视频通话实战(2)

手把手实现WebRtc一对一视频通话实战(3)

手把手实现WebRtc一对一视频通话实战(9)

手把手实现WebRtc一对一视频通话实战(6)

手把手实现WebRtc一对一视频通话实战(4)

手把手实现WebRtc一对一视频通话实战(8)

WebSocket基础讲解(2)

websocket聊天实战(1)

websocket聊天实战(3)

WebSocket基础讲解(1)

websocket聊天实战(4)之js补充

1.WebRtc基本介绍

WebRtc支持主流浏览器，Android、IOS、win、linux原生API。比如支持js/API/java/obkect-c/c++。Flutter跨IOS/Android。IE(微软)是不支持WebRtc。新的IE也是使用谷歌的内核。

刚开始学习，一定不要编译WebRtc的源码，为什么呢？

(1)因为，首先国内的网是没办法访问WebRtc的官网。

(2)然后，需要翻墙，翻墙后能够访问，但是也未必能够下载下来。可以在国外的服务器编译完，再把编译后的文件，拷贝回大陆的服务器。这个过程是非常麻烦。

(3)最后，推荐一个声网的镜像，但是这个也很慢，我试过，下载了好多天，都没有下载完全，中间还要搭建各种网络环境。所以这个过程是非常费时间。

如果不需要修改源码，网上，有直接编译好的库，就可以用。

WebRtc技术细节

分辨率的限制

码率限制

多个人通话

网上搜的文章，很多都是描述的不够细致。健壮性也不是很好。涉及的知识点也很多。

2.单人通话模型

P2P就是表示A端和B端在传输数据的时候就是点对点。A端和B端直通成功就表示p2p成功。如果不成功就需要通过turn去转发。P2P成功，可以节省服务器带宽。turn和信令服务器是需要自己搭建。

3.多人通话模型

3.1 Mesh 模型

对于N方通话来说，任意一个终端来说，如这里的A端要发送的数据的路数是N-1。对于Mesh模型来说，无论P2P是否成功，都需要发送N-1路数的数据。如果7人通话来说，对于任意客户端来说上行6路码流，这里的带宽压力就非常大。不支持转发N-1路数据，只是简单的中继转发数据。转发N-1路数据就是由SFU模型去做。Mesh模型的开发相对简单，前面WebRTC实战中，我们就使用的这种模型。

适合场景:

Mesh方案无法适应多人通话(为了节省客户端的上行带宽，期望P2P成功，P2P成功率也不是百分百成功的)，也无法实现服务端的各种视频处理需求，如录制(没办法在服务器上录制)，一般只只适合三方以下通话的需求。据说，有些公司可以支持到6人通话。

3.2 SFU模型

SFU的服务器，也是需要自己搭建。当N方通话时，对于任意终端来说，终端A的数据只需要发送一次。这种就类似于发布-订阅模式。对于C来说，如果需要听到A和B端的数据，需要订阅A和B的数据。这种方式对于客户端来说，上行带宽压力就没那么大。同样上面的例子，如果使用7路，那上行的带宽就只有1路，客户端压力就会小很多。市面上，大部分是选择SFU这种模型。SFU开发难度较大。

注意:微信的通话质量还是会显得一般，如果和声网的对比，就会发现，差距还是挺大。

适合场景:

SFU相比MCU，服务器的压力更小，适合纯转发，无转码合流，灵活性更好，可以选择开关任意一路数据的上下行等。SFU也是比较主流方案，常见的开源SFU服务器有Licode，janus，jitsi，mediasoup，Medooze等，各有特点，可以去官网了解。

3.3 MCU模型

MCU模型又被称为混合模型，是另外的种策略。该模型的特点就是将各路客户端上行的视频流合称为一路，再转发给其它客户端。这种模型相比SFU转发N-1路数据来说，降低了下行带宽的压力。但是由于合流要转码操作(服务器需要做解码再编码)，对服务器的压力较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。这种模型对于客户端来说，是非常友好的。SFU是独立的去拉取A\B\C的流，而MCU是拉取的ABC混合数据。特别是对于路数越多，MCU方案对于服务器的压力就越大。MCU开发难度较大。

适合场景:

适合服务器性能好，混流，音视频通话路数较小的方案。一般可以根据情况去选择SFU+MCU的混合方案，灵活应对不同的场景的应用需要。

声网目前是最高支持到17路。如下图所示:

这里会配合业务系统去做，业务系统主要还是去控制作用。

一般情况下学生客户端的视频是关掉，只开音频。学生要举手，老师确认了，才允许学生客户端开启视频，最后去推流。业务系统再通知其它客户端和老师端去拉流。

注意:这里说的17路，一般也不是每个客户端都要拉16路流，这种可能性也很小。

qq基本是p2p通话，需要提高打洞成功率，非常有难度。开源方案coturn小于qq的打洞方案，难度很大。

4.WebRtc多人会议系统框架

不管是用什么方案，信令服务器都是要做二次开发。

5.WebRtc应用领域

6.基于WebRtc开源方案比较

关于janus、licode、jitsi、AppRtc、kurento方案比较，根据不同的使用场景去使用，如下:

janus支持的比较好，可以直接应用在自己的商用方案中，使用C语言开发。licode使用c++开发，开发难度较大。jitsi使用的比较少，不是音视频流媒体主流方案。AppRTC是谷歌开源，提供了一整套方案，可以使用js端的思想，可以借鉴js的代码，使用的是Mesh模型，不太建议3人以上的群聊。即构科技，融云，就有使用kurento方案。如下图所示:

上图中表面，服务器的录制功能是很关键。即构科技，融云的音视频通话都是双向收费，当多路时，就是只要参与通话就收钱。视频录制，也是收费。当大规模的使用，难度就很大。如果给政府部门做项目，需要搭建私有的服务，肯定不会采用声网等公司的方案，因为这个私密性不太可靠。特别是小团队或团队经验不够，专业性不够，要想全国用户都使用，用户量大的时候，就会暴露出很多的问题。

7.国内音视频通话方案公司

声网目前是做的比较好了。特别是如果有海外业务的需求，如印度到中国的，声网效果是最好，腾讯的方案，都没办法比及。阿里云的直播业务，如RTMP的业务还是很多。

声网的js代码做了打包，没办法看到实际的源码。

8.WebRtc开发之SFU级联

如果不做SFU级联，所有的人都需要加到这个级联当中去，特别是跨国的通话，对于服务器的选址，难度也是非常大。在下图中，A要发送数据到SFU1，SFU1再发送数据到SFU2，而且服务器直接的传输更加通畅。这里的SFU2充当了一个订阅的模式，那C和D是直接去拉取一个SFU2的备份的A的码流。所以SFU的选址也是很关键。

9.AppRtc基本原理

AppRtc官方demo测试地址:

(1)浏览器以HTTPS方式访问Web服务器加载页面，并申请要加入的房间。

(2)Offer向信令服务器申请加入xxx房间，如果房间号已经存在则直接加入，如果不存在则创建。

(3)Answer向信令服务器申请加入xxx房间，如果房间号已经存在则直接加入并通知其它同个房间的加入者。

(4)offer和Answer以SDP格式通过信令服务器交换媒体信息。SDP包括包括音视频的格式等。

(5)offer和Answer都向STUN/TURN/ICE服务器申请打洞穿透，如果成功则offer和Answer进行直连通性，否则需要通过TURN中继服务器进行，否则需要通过TURN中继服务进行。

(6)以上步骤正常的情况下则offer和Answer进行音视频通话。

其中信令服务器的代码路径在apprtc/src/collider，web服务器是在apprtc/src/web_app/js，turn服务器使用的是开源的coturn方案。最具参考价值的就是web服务器js的代码，信令服务器也可以参考。

注意:这个APPRtc一般是针对一对一通话。AppRtc这个框架会涉及到google_appengine、python、nodejs。其中信令服务器还涉及到go语言。

web端是一定要使用https才有权限才能打开摄像头和麦克风，所以就有后面的使用Nginx做代理。如下图所示:

(1)大部分浏览器只有在HTTPS协议才能打开摄像头，因此web服务器需要提供HTTPS访问，但APPRtc的Web服务端是基于HTTP协议，这就直接冲突了，所以需要使用Nginx做Https的代理，再去当问AppRtc的Web服务端。

(2)在HTTPS方式访问时，对于信令服务器的访问需要提供域名才能正常使用wss协议的websocket，因此在访问信令服务器前也通过Nginx做代理连接，客户端访问Nginx，再有Nginx访问信令服务器。

(3)开放端口TCP/UDP 3478，以及30000以上的UDP端口，可以在turnserver配置范围。

注意:对于云服务器来说，使用nc命令可以查看端口是否有开通。nc -l 8099。如下图所示:

10.WebRtc通信的基本信令设计

主要就是包括媒体协商+网络信息candidate+房间人员管理。

(1)join加入房间

(2)resp-join：当join房间后发现该房间里已经存在另一个人时则返回另一个人的uid，如果只有自己则不返回。

(3)leave：离开房间，服务器收到Leave信令，则检查同一房间是否有其它人，如果有则通知其他人离开。

(4)new-peer：服务器通知客户端有新人加入，收到new-peer则发起连接请求。

(5)peer-leave:服务器通知客户端有人离开。

(6)answer:转发answer sdp。

(7)candidate:转发candidate。

注意:信令服务器自己开发，偏业务，一般可以用js/go去开发，使用c++开发少，为什么呢？信令服务器的接口大都是websocket，如果是用c++，就要去移植一个websocket，本身就会增加麻烦。如果使用go开发，就内嵌有websocket的模块，设计起来高效。

为什么信令服务器就要使用websocket协议呢？

在web端，一般就就有http(轮询机制，很少用)、https、websocket，socketio。

注意:如janus的媒体服务器，stun、turn都是使用开源方案。如apprtc就是使用mesh模型。

对于我们开发人员来说，就会涉及到客户端开发(web相对更简单)，信令服务器的开发等。

11.WebRtc学习资源

WebRtc的学习资源如下:

根据以上描述就知道了，如果搞WebRtc单纯的只懂c++，是不够的。需要会写一些简单的js/go。后面会介绍一些学习链接。

12.总结

关于前面文章的总结，就讲到这里。欢迎关注，转发，收藏，点赞。

关于后期项目相关的知识，可以关注微信公众号"记录世界 from antonio"