目录

前言 

背景

业界综述

简介

三大直播协议

五大应用场景

小结

设计考虑

功能属性

质量属性

易用性

兼容性

可靠性

​​​​​​​时间特性

​​​​​​​可维护性

​​​​​​​约束

---

​​​​​​​

前言 

该专栏文章需要你已经懂的docker的基本使用。专栏使用的基本技术栈是：

1. window desktop
2. docker
3. centos7

如果desktop和docker并不熟悉，没事请移步作者的另外一个专栏《docker从0到1》

背景

公司内部项目需要引入直播场景的解决方案。目前可选方案包括自建本地化的直播服务平台、直接购买第三方的云视频直播服务。这两个方案的宏观优缺点如下：

方案	自建直播服务	购买云直播服务
技术难度	大	小
稳定性	偏低	高
成本	低	高
方案	基于SRS的直播平台、基于webRtc的p2p直播平台	多，比如腾讯云、阿里云、华为云均有提供

因此，本次的问题就是如何投入最低的代价实现直播功能，同时也要考虑未来的业务的延展性。

附：

SRS:(Simple RTMP Server)是一款开源的流媒体服务器

业界综述

通过查找直播的方案，发现自建直播服务，目前（2021年）比较成熟的解决方案是基于srs的直播服务器。因此本次研究，先以自研srs实现直播为主要工作，然后再跟各大产商商用的直播服务做比较。

简介

SRS定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。提供比较多的协议方案，供用户自己按照实际需要进行选择。

三大直播协议

本次主要选择了SRS里头如下四种协议来进行比较和筛选：

协议	传输协议	延时	优点	缺点
RTMP	TCP	6s	老牌、稳定	H5播放需要插件
WEBRTC	UDP	1s以内	延迟低	稳定性相对差、黑屏、卡顿、不支持集群
HTTP-FLV	HTTP	3s	延迟低	连续流、性能低、H5播放需要插件
HLS	HTTP	10s	性能高、平台兼容性好	延迟高

其中RTMP/HLS/HTTP-FLV为常见的三大直播协议。

附：

RTMP:RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种

1)RTMP工作在TCP之上，默认使用端口1935；

2)RTMPE在RTMP的基础上增加了加密功能；

3)RTMPT封装在HTTP请求之上，可穿透防火墙；

4)RTMPS类似RTMPT，增加了TLS/SSL的安全功能；

五大应用场景

下面是SRS官方给出的SRS致力于解决的五大应用场景：

1. 全平台直播，小荷才露尖尖角。只需要上图的Encoders(FFmpeg/OBS)推送RTMP到SRS；一台SRS Origin(不需要Cluster)，转封装成HTTP-FLV流、转封装成HLS；Players根据平台的播放器可以选HTTP-FLV或HLS流播放。
2. WebRTC通话业务，一对一通话，多人通话，会议室等。WebRTC是SRS4引入的关键和核心的能力，从1到3秒延迟，到100到300毫秒延迟，绝对不是数字的变化，而是本质的变化。
3. 监控和广电上云，各行业风起云涌。除了使用FFmpeg主动拉取流到SRS，还可以广电行业SRT协议推流，或监控行业GB28181协议推流，SRS转换成互联网的协议观看。
4. 直播低延迟和互动，聚变近在咫尺。RTMP转WebRTC播放降低播放延迟，还能做直播连麦，或者使用WebRTC推流，未来还会支持WebTransport直播等等。
5. 大规模业务，带你装逼带你飞。如果业务快速上涨，可以通过Edge Cluster支持海量Players，或者Origin Cluster支持海量Encoders，当然可以直接平滑迁移到视频云。未来还会支持RTC的级联和集群（经过笔者试验，目前最新的4.0.99版本支持RTC单节点直播，暂时还不支持RTC集群）。 

小结

SRS支持面向场景的直播协议的选择和应用。支持基于Origin+Edge模式的集群。考虑到公司业务场景，只需要SRS支持尽可能的低延迟直播+弹性增加集群节点即可。因此初步得到一个结论：基于SRS的直播方案满足本次业务的要求。

设计考虑

从软件设计层面来评估SRS能否胜任。

功能属性

直播技术选型要求至少满足：

功能	解释
音视频接入	直播端
音视频播放	播放端
播放平台形式尽可能丰富	至少要求在h5里头可以播放（微信打开、手机/电脑浏览器打开）
支持多路直播	要支持同时有20个人在直播
支持多路播放	要支持同时2000个人观看

质量属性

质量	解释
易用性	音视频接入和播放的步骤要少而简单
可靠性	容错性
稳定性	音视频接入和播放不要出现卡顿、黑屏、宕机等
低延迟	延迟时间控制在5s以内
可维护性	容易增加集群节点数量、测试方便简单
可移植性	安装配置容易

易用性

要保证接入的方案，从推流到拉流都要简单易用。从技术实现层面，开发对接需要尽可能的简单，从使用方便，客户使用复杂度也要尽可能的小。

兼容性

主要是针对播放端的兼容性的考虑。需要兼容至少要求在h5里头可以播放（微信打开、手机/电脑浏览器打开）

​​​​​​​可靠性

直播过程的可靠性决定了直播的体验，要确保有一定的容错性，比如比如支持集群和负载均衡来实现等。另外音视频接入和播放不要出现卡顿、黑屏、宕机等。

​​​​​​​时间特性

直播过程，从推流到拉流完毕并播放，时延不能超过5s。

​​​​​​​可维护性

直播的播放路数可能会有一个比较大的波动，需要能根据业务场景，快速的增加服务节点来降低负荷。

​​​​​​​约束

成本约束，要求整个方案的造价合理，并远低于云服务产商的造价。另外，方案的实现，极度依赖带宽，因此建设直播的点是否支持超大链路数的直播，建设点的网络硬件环境也是一个约束，因为集群负荷能承受住压力，但是带宽硬件可能支持不来。

下一篇：单机SRS的直播能力验证