引言
在对外购的音视频通讯服务端做压测的时候，发现在测试环境视频通话最多进9个人，其他人无法接入，存在明显的带宽不足现象，所以收集了一些和带宽相关的资料。
1. 影响因素
当前工作的计算机的网口的最大工作速率——决定发送到网络上的流量上限
音视频文件本身——决定实时的发送流量
音视频文件编码方式——决定码率
2. 音视频传输所占带宽计算
实占带宽 = 单个用户所占带宽 X 订阅人数 = （文件大小 / 播放时长）X 订阅人数
若要传输一个时长为3分钟大小为4.56M的视频文件，
单个用户所占带宽=4.56x1024x1024x8/（3x60）=212511.4bps
1000M网卡最多支持同时（1000x1024x1024）/212511.4=4934人同时在线收听
3. webrtc模式下的音视频通话所占路流计算
如果有n人参与通话，通过所需的流量m，则所占路流为nxn，所占带宽为nxnxm
计算方式为，每个人上推一路流，下拉n-1路流
对上行来说，就是n路，对下行来说，就是n（n-1）路
4. webrtc三种类型的多方通信架构
Mesh方案
多个终端两两相连，形成网状网络。对各终端的带宽要求比较高。
项目：几乎没有
MCU方案
由一个服务器和多个终端组成一个星型结构。各终端将自己要共享的音视频发送给服务器，服务端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频再发给各个终端，这样各终端就可以看到其他终端的音视频了，实际上服务器端就是一个音视频混合器，对服务器的压力非常大
优势：技术非常成熟，在硬件视频会议中应用非常广泛；作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求，提升用户体验和产品竞争力；将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。
不足：重新解码、编码、混流，需要大量的运算，对CPU资源的消耗很大；重新解码、编码、混流会带来延迟；机器资源耗费很大，MCU所提供的容量有限，一般十几路视频就是上限了。
项目：FreeSwitch
SFU方案
由一个服务器和多个终端组成一个星型结构。收到某个终端共享的音视频流之后，就直接将该音视频流转发给房间内其他终端，实际上就是一个音视频路由转发器。
优势：数据包直接转发，不需要编码解码，对CPU的资源消耗很小；直接转发极大地降低了延迟，提高了实时性；带来了很大的灵活性，能够更好得适应不同的网络状况和终端类型
不足：参与人观看多路视频时可能出现不同步，不同的参与人看到的画面可能不一致；对多人实时通信进行录制时，多路流会带来回放的困难，在整体性和一致性的表现上会比较差
