目录：
-
媲美zoom的视频会议app
-
WebRTC的行业地位
-
RTC架构
-
动态分辨率调整
媲美zoom的视频会议app
上一期《WebRTC安全问题：私有IP与mDNS》中介绍了私有IP地址泄露的问题，关于私有IP泄露问题可以搜索关键词WebRTC+IP+leakage，或者查看Mozilla的bug报告：https://bugzilla.mozilla.org/show_bug.cgi?id=959893。
由于WebRTC的安全考虑，有时候WebRTC并没有权限获取本机的网卡IP地址，取而代之的是一个mDNS域名，但是由于mDNS尚未普及，设备不一定支持。所以不依赖WebRTC的“host candidate”，需要主动维护所有app设备的IP地址，通过心跳连接让中心的web端主动汇聚所有app的IP地址，并交换。一句话概括：手机的IP让web端来找，别自己找。
本文是WebRTC系列教程第四篇，仍然围绕理论基础，扯点有的没的。事实上，WebRTC的性能丝毫不弱于风靡全世界，行业领先的zoom，一般想要实现这样一个能提供高清画质的app，需要部署以下几个子系统：
-
WebRTC音视频编解码技术
-
信令服务，用于网络层打洞（园区内网可能不需要）
-
房间控制/认证（WebSocket，同上）
-
RTC架构：全互联mesh/中心化SFU
WebRTC的行业地位
如果按照时间性能和空间性能（数据量）这2个维度对所有网络通讯应用进行分类，大致可以分为3类：常规通讯、即时（消息）通讯、即时音视频通讯，共三种不同性能要求的通讯场景。
| 类型 | 时间要求 | 数据量 | 场景 | |
|---|---|---|---|---|
| 1 | 通讯 | 低 | 小 | HTTP网页、文件传输、电子邮件 |
| 2 | 即时通讯 | 高 | 小 | 聊天室、电话、网络游戏 |
| 3 | 即时音视频通讯 | 高 | 大 | 视频通讯、远程桌面、3D像素流 |
这3类app对性能的要求递增，很显然WebRTC是为了解决第3类应用场景。此类通讯的难度最大，单位时间内传递的数据量巨大，同时要求低延迟。遍历整个互联网，找不到比即时音视频通讯更难的需求，WebRTC技术本身就横跨多个基础学科，包括图论、信息论、控制论等，其行业地位可想而知。
RTC架构
如果只有2个人，自然p2p通讯是最佳方案；如果有3到5人的通讯，采用两两相连的全互联结构（full mesh）也是可以接受；如果人数增长至5以上，至少要考虑2点性能优化方案：
-
复用媒体流：可以利用中心节点（如SFU）将重复的媒体流汇聚至上行链路（uplink）。
-
有损压缩：用户不一定需要每个peer都传入100%分辨率的媒体流，比如视频会议中的缩略头像。
其实，如果打算开发一个不到10人的视频会议，mesh结构没得问题，mesh（网格）架构是最简单的全互联架构。全互联是图论的一个术语，代表所有节点两两相连，逻辑网络如下图：
注意，这张图只是逻辑上的网线，并非物理网线，根据组合数公式，全互联网络有C(n, 2)=n(n-1)/2个连接。这是一个二次多项式的复杂度，当n大于10以后是很恐怖的，真实物理链路利用中心的交换机将链路数量降至线性增长，不然太恐怖了。
动态分辨率调整
有时候，我们并不需要看到每个人的高清画质。
WebRTC接收的媒体流对象可以设置各种限制（constraints），包括空间上的分辨率和时间上的帧率（fps），这些限制可以节省流量。现代手机摄像头的分辨率大多是1080p（30fps），但是每个用户只接受2种分辨率，一种是类似监控中心的缩略版，一种是聚焦到某个用户时的完整图像。所以需要通在app中按需限流，除此之外，WebRTC也会根据网络环境对分辨率和帧率进行微调。
<完>
