大概在2017年的时候，直播整个行业变化，很多企业转向了互动连麦的方向。因为以上的解决方案，只适合一个人推流，其他人观看，延时高。但面向互动连麦的方向，产品也遇到了很多挑战。
新的挑战：如何实时互动连麦
互动连麦，包括1V1，或者多对多的互动连麦场景，画面的相互订阅观看。
互动基础技术简要介绍
什么是WebRTC?
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。(百度百科)
百度百科很长，产品经理不需要全部理解，总结一下：
- 一个W3C和IETF制定的标准；
- 是一群音视频算法和网络适应性算法的工程；
- 一个开源工程。
支持的平台
WebRTC 技术由 Google 最先提出，目前主要在桌面版 Chrome 浏览器、桌面版 Safari 浏览器以及移动版的 Safari 浏览器上有较为完整的支持，其他平台（例如 Android 平台的浏览器）支持情况均比较差。
在移动端推荐使用 小程序 解决方案，微信和手机 QQ 小程序均已支持，都是由各平台的 Native 技术实现，音视频性能更好，且针对主流手机品牌进行了定向适配。
-图片来源-腾讯云
互动直播的架构
普通直播的结构是1对多，互动直播的形式是多对多结构。目前技术架构，比较常见的是SFU架构和MCU架构。
图片来源网络-侵权请联系删除
一、Mesh架构
即：每个端都与其它端互连。以上图最左侧为例，5个浏览器，二二建立p2p连接，每个浏览器与其它4个建立连接，总共需要10个连接。如果每条连接占用1m带宽，则每个端上行需要4m，下行带宽也要4m，总共带宽消耗20m。而且除了带宽问题，每个浏览器上还要有音视频“编码/解码”，cpu使用率也是问题，一般这种架构只能支持4-6人左右，不过优点也很明显，没有中心节点，实现很简单。
二、MCU (MultiPoint Control Unit)
这是一种传统的中心化架构(上图中间部分)，每个浏览器仅与中心的MCU服务器连接，MCU服务器负责所有的视频编码、转码、解码、混合等复杂逻辑，每个浏览器只要1个连接，整个应用仅消耗5个连接，带宽占用(包括上行、下行）共10m，浏览器端的压力要小很多，可以支持更多的人同时音视频通讯，比较适合多人视频会议。但是MCU服务器的压力较大，需要较高的配置。
三、SFU(Selective Forwarding Unit)
上图右侧部分，咋一看，跟MCU好象没什么区别，但是思路不同，仍然有中心节点服务器，但是中心节点只负责转发，不做太重的处理，所以服务器的压力会低很多，配置也不象MUC要求那么高。但是每个端需要建立一个连接用于上传自己的视频，同时还要有N-1个连接用于下载其它参与方的视频信息。所以总连接数为5*5，消耗的带宽也是最大的，如果每个连接1M带宽，总共需要25M带宽，它的典型场景是1对N的视频互动。
总结一下三种架构，
Mesh，没有中心服务，p2p, 点对点服务。 但在实际的直播场景中，我们需要服务中心对流做处理，如前文介绍的直播管理服务，和直播处理服务等。
MCU，在服务端合成，其他观众看合流，旁路。5个人参会，只推自己的流，然后在服务端拉其它4个人的合流，只需要消耗一路上行，一路下行。缺点：MCU合流成本很大。纯粹的MCU架构，一般应用在视频会议比较多。
SFU，在线教育公司小班课，通常采用SFU架构 ，用户推一路流，拉4路流，这个结构很消耗网络资源，所以没有办法做到无限制的N对N。这便是产品需要知道的技术边界，如果互动课堂产品提出太多的学员加入，是很难控制的。
信令交互
信令服务主要应用在直播场景中的消息发送和应答，是整个互动连麦比较重要的部分，和媒体服务并存。
这里有些名词：Publish(推流)，Subscribe（订阅）
- LocalStream（本地流）：自己的画面采集，要推上去的流，
- RemoteStream(远端流)：我要订阅的，需要拉的流。
互动连麦的基础流程
两个连麦端，通过信令服务确定连接消息。媒体服务负责流的处理，能够实现 连麦端A 和连麦端B，实现互动连麦。
到这里，和普通直播一样，我们搭建完基础结构，不断的会有新的业务增加。
互动的场景怎么对接大并发直播？
这里的场景，两个人互动连麦，有大量的用户在观看。比如在线教育场景里的大班课。
这里的解决方案，采用，互动直播+普通直播的方式，核心就是MCU的旁路混流。
A与B互动连麦，通过混流后，通过直播系统CDN封装好，给观看用户，这样可以支撑上万人的观看。
但这里存在一个问题，A和B是无延时的互动，另外的一万观看就存在延时情况。
互动人数受限，地理分布不均怎么办？
sfu接入的宽带计算：
8人互动房间，如果假设互动流480p，0.5Mbps，出口宽带 = 0.5Mb *（8*7）=28MB
16人互动房间，假设互动流位720P， 1MBPS, 出口宽带 = 1MB* （16*15）= 240mb
这种情况，对整个结构，人数已经受限了，已经到顶了，但产品的需求是不会受限，总会有新的业务需求。
另外地理位置分布不同，如果16个互动，就相当于从一个SFU节点，如果在北京，深圳，新疆，如果都连北京节点，如何保证网络？
这时候，产品经理如果认为需求已经到极限了，当然不存在，采用SFU级联网络方案，可以缓解瓶颈。
SFU级联网络和CDN很像，都是增加节点部署，每个SFU都能进行转分发和转订阅。这样能分担带宽，并且就近接入节点。
互动人数太多，个人电脑的宽带不够用怎么办？
比如，刚刚16人互动，功能可以满足，但是用户的电脑订阅15个流，个人电脑也承受不住。
这时候需要采用 互动双流策略（simulcast）
比如，发起端推了一个2M的码流，在一条流里分成两层一个1.5M的流和一个0，5M的流，当然分辨率会有差距，一个大分辨率，一个小分辨率。订阅端，会根据网络情况选择订阅的流。同时也会根据物理结构，比如窗口大小订阅码流。这时候产品策略上，可以采用大窗订大流，小窗订小流，因为小窗订阅大流意义不大。
在实际的业务应用中，比如在线教育的小班课，每个互动用户的窗口都不需要很大，这时候就订阅小流就可以，完成多人互动。
在观看互动直播的旁路用户，需要更低的延时怎么办？
在互动直播+普通直播的方式，核心就是MCU的旁路混流。但是看旁路的用户，就算是用HTTP-FLV，也会有3秒左右的延时，如果这部分用户，需要更低延时怎么办？目前这个就需要rd伙伴找到解决方法了。现在的技术条件，暂时还无法满足。
这个就是可以想象的场景是在线会议，参会听的人，希望能够和互动的人保持一个时间点。
以上，就是普通直播，和互动直播的发展过程，是基础的技术框架。直播产品经理平时会参与到更多的业务当中，但都离不开这些技术能力。
另外娱乐直播不能依赖webrtc，因为webrtc 音频的支持，不能够满足 PK场景中的歌曲要求。
在满足直播基础上，娱乐直播，更多的是，用户增长，礼物打赏互动，收入增长，社区等业务能力上的思考。
在线教育，更应该去了解这些技术业务，这样你才能很好的抽象课型，比如1V1、小班课、大班课、公开课等。如果设计产品，如何去设计文档、答题、或更多的课堂业务。
原创声明：本文由顽童LOCK原创，转摘请注明出处和作者。
发现telegram上几乎没有产品经理的存在，抱着试试看的态度，如果有产品经理使用tg，加入telegram的产品经理群https://t.me/WeArePM
tg：wangtong73
twitter：@wangtong_73
wx:pmideas
网友评论