Janus网关的集成与优化( 四 ) _Janus网关

整个图从下往上看，就是从RTP数据流中提取出来H.264编码数据的过程，完成提取后再封装成自研RTC系统的格式，发送到客户端上进行数据的还原，再经过H.264解码器的解码，得到原始的视频数据并在界面上渲染出来.
3.3 集成效果

文章插图

这个测试主要是想知道中间转换部分的开销, 因此这里不考虑客户两端到服务器的弱网情况. 首先是稳定WiFi，到服务器RTT是30毫秒，视频分辨率是320×240，帧率是20帧。整个过程下来音视频流畅，媒体延迟小于100毫秒。

文章插图

测试方法借助了一个在线秒表的时间跳动的画面，虚拟摄像头采集在线秒表的动画，通过PC端进行编码，然后上传到自研RTC服务器, 转换成RTP格式, 通过RUDP通道传输到Janus网关, 再通过网关发送到浏览器上还原出视频画面。对比PC端和Web端看到的视频画面，就可以得出他们观看的时间差。
图中可以看出PC客户端的画面时间和Web的画面时间相差大概几十个毫秒。由于PC端有一些相应的处理(如美颜)，而且存在渲染的时间消耗, 实际的差值会比这个大一些, 整体的时间延迟估计是100毫秒左右，效果还是不错的。
4 Janus网关优化

文章插图

这部分我会从现象入手，介绍集成过程中所做的一些优化，这里主要介绍CPU优化和端口优化。
首先在CPU方面，在测试时我们发现，在同一个房间里进入12个人，八个人开麦进行音视频互动的话，Janus近程的CPU大概占到30%多。如果是一个四核的CPU, 算打到300%的话，也只能支撑120多个人，这样的话承受能力会非常有限。因此需要对CPU进行优化。
其次是端口，Janus在服务部署的过程中需要开放大量的端口. 这是因为Janus对于每一路上传和每一路观看都需要为它分配一个外网端口。分配过多的端口不管从安全管理上还是运维部署上都会带来不便。在我们实验室实际开发过程中就遇到过，当同时开3、4个视频时，整个视频的数据下发不来, Web上看到的画面是黑的. 经过找相应的IT人员一起定位分析后，发现是办公室交换机出口对UDP访问端口做了限制导致的，因为每一路视频上传下载都需要分配端口, 在交换机策略看来, 多个内网的机器访问了同一个外网IP(janus网关的IP)的大量不同端口, 被判定是异常状态了。因此，不管从安全性、运维部署，还是服务质量上来讲，最好是用少量的端口来完成同样的事情。
4.1 CPU优化

文章插图

这部分介绍针对上述两个问题的分析和相应的解决方法。CPU问题的原因主要有3个：一是SFU的转发关系复杂度为M*N，其中M是上麦人数，N是房间内的总人数。假设房间里有100个人，其中10个人上麦，那么转发的复杂度就是10×100，因为对每一路上传的视频都需要转给其他99个人，一路上传加上99路转发就是100处理量，10个人就是1000 。
二是对于每一路上传和转发，Janus都分配一个对应的UDP端口和socket描述符，该分配行为是Janus所使用的网络库Libnice决定的。
三是Libnice的内部采用poll做事件处理，在描述符量很大时，它的效率很低。因为poll在调用时, 需要把所有描述符以数组的形式传递到内核, 内核需要对每个描述符进行查询处理，并且还要注册相应的事件监听。如果当前这次调用没有收集到任何事件的话, 它会进行等待, 在等待过程中, 它会把当前线程注册到所有描述符的通知等待队列里，然后被动等待相应事件的唤醒。在事件到达唤醒后, 返回的过程中又需要把当前线程移出所有描述符的等待队列，这其中涉及到大量锁操作。以上三个原因叠加起来，就造成了高CPU的情况。

文章插图

CPU优化的对策主要是从两方面入手: 减少端口的使用, 以及把glib内的poll调用改为epoll 。
在使用上，端口的问题的使用可以采用以下一些办法来缓解：
一是通过ice_enforce_list限定ICE收集candidate的网卡。默认情况下，Janus会对所有的网卡都做端口收集。我们在开发的过程中所部署的机子上正好有两个网卡，测试时发现，它所收集的端口数量比单网卡下多了一倍，在开启这个的配置后，数据数量立马减半，CPU也降低了很多。