场景1-直播：一对多技术方案
推流：
很多直播方都推荐用OBS推流，OBS具有开源 可改造等等优点.
协议：
rtmp
hls
websocket
流媒体：
SRS
CDN
集群：
Forward
场景2-连麦：连麦场景技术方案
介绍：
直播主播可以满足粉丝的参与感.让粉丝产生幸福感。
模型图1：
说明：
连麦用户向信令服务器发送连麦请求，信令服务器通知连麦主用户，若接受，双方向TURN请求各自本端IP或TURN端分配好的公网IP，通过信令服务器交换又方的网络信息，双方优先以P2P方式尝试联接对方的公网IP地扯，若超时失败，尝试联接对方在TURN服务器分配的IP与端口号，这时通过TURN服务器中转双方媒体流，保证无论如何P2P都是可成功的，然后连麦主用户混音、混屏后将多媒体流以RTMP方式发送给弱实时流媒体服务器集群，同时发送本端非混音、混屏码流给连麦用户A，连麦用户A切断从弱实时流媒体系统获取音视频流，开始接受连麦主用户的媒体流解码渲染并且同时将本端采集到的媒体流编码后发送给连麦主用户，供连麦主用户端播放输出与混音、混屏。
适合单个主播同时与少数（2个左右）用户同时连麦 增加主播端终端性能压力 主要实现集中于客户端，可参考WEBRTC实现
连麦码流采用高实性协议传输 少了服务器中转环节，更低的时延 弱侵入性，对现有弱实时流系统无需大规模改造 不增加服务器带宽流量
模型图2：
说明：
连麦用户A通过信令控制服务器向连麦主用户请求连麦，连麦主同意后，连麦用户A向高实时流媒体服务器发送媒体流，同时信令控制服务器向所有观众广播准备好获取连麦用户的媒体流，连麦主播与所有观众端接受到连麦用户A的媒体流后分别解码，转出时若为连麦主用户直接语音直接输出到音频设备并且视频要混屏渲染，若为观众要混音、混屏后输出给音频设备与渲染到屏幕；连麦用户A不需要断开接受连麦主用户的媒体流，跟据需要只混屏或不混屏显示视频即可。
适合多个主播与多用户互动场景 高实时流媒体系统复杂度与耦合性较低，便于扩展 服务器端由于不需要混音、混屏CPU压力低
主要实现集中于服务器端，便于服务升级 带宽过大 对于观众端来说，连麦主用户与连麦用户A的媒体流间时序差
高侵入性，要对现在弱实时流媒体系统进行大规模改造
模型图3：
说明：
连麦用户A通过信令控制服务器发连麦主用户发起连麦请求，连麦主用户同意后，连麦用户A断开弱媒体流，同时向高实时流媒体服务器获取连麦主用户媒体并且发布自身媒体流，连麦主用户通过也通过高实时流媒体服务器获取连麦用户的媒体后，在高实时流媒体服务器收到连麦用户的媒体流后，开始解码、混音、混屏、重编码按原来的通道发送媒体流至弱实时流媒体服务器，观众端即可感知到混合后的媒体。
适合多个主播与多用户互动场景 流量较低，连麦用户上下麦，观众端几呼无感知 由于服务器端混音、混屏，加大服务器端压力
侵入性适中，弱实时流媒体系统可维持不变 实时性较P2P模式稍差 与前两个模型比较，实现复杂度最高
所以这里选择模型一.
协议：rtmp，hls，webrtc.
流媒体： SRS，Nginx-remp
