视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵，揭竿而起的新生起义军们也正马不停蹄的赶往这方战场，各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏，让人眼花缭乱，“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下，视频云和CDN们，技术上到底是在竞争什么？作为视频平台和即将要进入视频领域的运营者，在技术平台的选型和搭建上又如何才能避免掉入大坑？


一个播放器的背后

谁都知道视频直播最重要的是流畅和高清，但这光鲜亮丽的背后是技术和成本的双高门槛，是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播，主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节，还要求在数秒内完成，除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。

再如下图，仅一个屌丝观众从播放器看这个主播，就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样？使用的系统环境又怎么样？一个观众尚且如此，要保障百万千万级别流畅的观看，难度可想而知。


高清流畅到底靠的是什么

也许对于部分视频运营商和新进入者来说，直播推流端和播放器端依然觉得头大，但整体来说，除移动端外，PC端推流和播放技术已经比较成熟。难，主要难在传输和分发！正常情况下，只要推流端网络状况良好，传输和分发决定着直播是否能够流畅。

传输和分发，涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂。也因为如此，视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层，如下图：


L2资源层：对视频云和CDN来说，资源的确存在差别，但在其可承受范围内，可以视为差别不大；

L4传输层：传输层可针对不同业务场景，比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障，不同应用场景的支持后续文章将专门介绍；

L3网络层：视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要，随着CDN技术的日益成熟，虽然各家可能存在架构区别，但基本都能保障网络路由正常运转；

L7应用层：抛开细枝末节，视频流的主线还是输入、传输与输出，承担这些工作的就是视频平台最核心组件流媒体服务器，这就是视频直播分发最本质的特点，需要专门的流媒体服务器来分发，所有视频云和CDN，都需要在中心层和边缘层部署流媒体Server。

 

通过以上逐层分析可知，当资源和网络层面相差不大的情况下，流媒体Server的性能决定了视频流分发的效果和质量，故流媒体Server才是视频云和CDN技术竞争的至高点。


市面主要的流媒体服务器对比

目前市面上主流的流媒体服务器，有以Adobe FMS、Real Helix、Wowza为代表的第一代产品，它们的特点是单进程多线程。基于Linux2.7 epoll技术，出现了以多进程单线程为特点的第二代流媒体服务器，NginxRTMP、Crtmpd为其优秀的代表，另外还有基于JAVA的流媒体祖先Red5等。

观止云开源流媒体服务器SRS（Simple RTMP Server），凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务，高升CDN基于SRS搭建其流媒体基础平台，其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server，在中国流媒体业界实属难能可贵。


观止云源站集群BMS（Bravo Media Server）是SRS的商业版，BMS在SRS基础上增强了11项大功能，新增了9个大功能：

增项的11项大功能：


新增的9项大功能：



流媒体Server的话说来也不短，上述列举的目前市面上主流流媒体服务器中，有名副其实的先烈RED5，有生不逢时的CRTMPD，都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp，以下是nginx-rtmp几个盛行于世的重要因素：

  • 2012年CDN业务开始极增长，随之直播需求也多了起来，彼时业界都还没有一套公认的特别满意的流媒体服务器；

  • Nginx是HTTP领域绝对的霸主，大家（尤其是CDN运维）对Nginx熟悉程度很高，便于上手维护；

  • 基于Nginx，直播点播使用一套服务器，这也极具诱惑力，一套管理起来总比多套要简单；

  • CDN是靠运维的行当，运维的信心都是长年运出来的，Nginx在图文上那么优秀，Nginx RTMP也差不了。


nginx-rtmp确实生来就自带光环外，性能也的确是高，比Crtmpd还要高。然而，时过境迁，随着互动直播、移动直播的强势兴起的大直播时代，选择nginx-rtmp到底是福还是祸？

下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比，供视频从业者根据自身业务场景特性择优选用。


1 网络协议对比

BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。


2 体系架构对比

架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。

观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。


3 核心功能对比

核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。


4 配置运维对比

以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。

（1）vhost配置

FMS

拷贝默认vhost目录： sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com


nginx-rtmp

不支持


SRS/BMS

动态获取配置文件：vhost bravo.sina.com { }

结论：BMS动态获取配置最简单

（2）app配置

 FMS

拷贝默认app目录：cp applications/live applications/mylive -r


nginx-rtmp

修改配置文件，增加如下内容：application live {  live on; }


SRS/BMS

无需配置

结论：BMS无需配置，最简单 

（3）http配置

在输出为hls、http-flv等基于http协议的直播流时，需要配置http服务

FMS

配置FMS内置的Apache服务器文件：Apache2.2/conf/httpd.conf

再修改如下字段：

<Location /hds-live>

    HttpStreamingEnabled true

    HttpStreamingLiveEventPath "../applications" 

    HttpStreamingContentPath "../applications" 

    HttpStreamingF4MMaxAge 2

    HttpStreamingBootstrapMaxAge 2

    HttpStreamingFragMaxAge -1

    Options -Indexes FollowSymLinks

</Location


nginx-rtmp

nginx本身就是一个http服务器，

修改其配置文件：

conf/nginx.conf

设置端口和根目录：

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  localhost;

        location /dash {

            root /tmp;

            add_header Cache-Control no-cache;

        }

    }

}


SRS/BMS

修改其配置文件：

conf/http.hls.conf

设置端口和根目录：

http_stream {

    enabled         on;

    listen          8080;

    dir             ./objs/nginx/html;

}

结论：nginx-rtmp需指定与app对应的ts文件存放目录，SRS/BMS会自动生成，更简单。

（4）推流、播放URL配置

RTMP直播时，各大服务器推流、播流URL均为：

rtmp://server_ip_or_dns/app/stream


用作HLS直播时，

FMS 

推流域名：

rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent

播流域名：

http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m


nginx-rtmp

推流域名：

rtmp://server_ip_or_dns/app/stream

播流域名：

http://server_ip_or_dns/app/stream.m3u8


SRS/BMS

同nginx-rtmp

结论：nginx-rtmp、SRS/BMS均简单，FMS较复杂。


5 性能

先说结论：

SRS单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5

 

再例举SRS性能如此高的几个原因：

1. st-load，这个是SRS能做到高性能的最重要的原因，一个st-load可以模拟2000+的客户端，如果没有st-load，如何知道系统的性能瓶颈在哪里？总不能打开3000个flash页面播放rtmp流吧？开启3000个ffmpeg来抓流？高性能不是想象和猜测出来的，而是反复测试、调试和改进出来的。

2. gperf/gprof性能，编译SRS时，就可以打开gcp或者gprof的性能分析选项，非常方便的拿到数据。缩短了改进和优化开发周期。

3. 引用计数的msgs避免内存拷贝。

4. 使用writev发送chunked包，避免消息到chunked包的内存拷贝。

5. mw(merged-write)技术，即一次发送多个消息。

6. 减少timeout recv，每个连接都是一个st-thread在服务。

7. fast buffer和cache。

8. vector还是list？vector！vector比list高10%性能。


6 服务器日志

日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，10分钟的排错，谁都会觉得长。然而，当前的视频云或CDN，谁又能做到10分钟呢？

来看看日志吧。

FMS的日志是这样的，恕我愚钝，你能看得出什么信息么？

2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-

702111234525315439     3130         3448         normal      livestream         -        -         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        -        flv     -        -        0       -        0       0         -        -    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         

crtmpd的日志详细，但我又愚钝，若是上千人在线，你又能看出什么有用的东西么？

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935

/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpappprotocolhandler.cpp:83Selected application: flvplayback (live)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:246Protocol CTCP(17) <-> TCP(18) <-> [IR(19)] unregistered fromapplication: appselector

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:257Stream NR(5) with name `` registered to application `flvplayback` from protocolIR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:268Stream NR(5) with name `` unregistered from application `flvplayback` fromprotocol IR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:257Stream NR(6) with name `` registered to application `flvplayback` from protocolIR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:1043Play request for stream name `livestream`. Start: -2000; length: -1000

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:268Stream NR(6) with name `` unregistered from application `flvplayback` fromprotocol IR(19)   

到了nginx-rtmp，日志总算有进步了，能按照连接区分了。只是可惜，nginx日志也就只能知道这个连接而已，这个连接在CDN多层网络中的路径，这个连接本身的网络状况等依然不知。

2015/03/2411:42:01 [info] 7992#0: *3 client connected '192.168.1.141'

2015/03/2411:42:01 [info] 7992#0: *3 connect: app='live' args='' flashver='MAC17,0,0,134'swf_url='http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23'tc_url='rtmp://192.168.1.173:1935/live'page_url='http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935'acodecs=3575 vcodecs=252 object_encoding=3, client: 192.168.1.141, server:0.0.0.0:1935

2015/03/2411:42:01 [info] 7992#0: *3 createStream, client: 192.168.1.141, server:0.0.0.0:1935

2015/03/2411:42:01 [info] 7992#0: *3 play: name='livestream' args='' start=0 duration=0reset=0 silent=0, client: 192.168.1.141, server: 0.0.0.0:1935


在SRS，尤其是BMS身上，终于有了流媒体可追溯日志，能从播放连接追到对应的推流连接，打印出连并接的摘要信息，这也是观止云能将故障定位时间控制到分钟级别的原因。之前小编专门介绍过观止云可追溯日志，有兴趣可参考《可追溯日志：视频云时代的新运维大胸器》，此处简单看看可追溯日志运行方式：

播放流：rtmp://dev:1935/live/livestream 客户端显示ID能看到SrsIp，即服务器IP为192.168.1.107，由此知道是哪个边缘节点在提供该流的服务。SrsPid为12665，SrsId为114，所以去这个服务器上grep关键字“[12665] [114]”。




连续grep追踪，最终发现这是source_id=149 的编码器推上来的流ID。再去查149的日志，整个流的日志将快速呈现在眼前。Encoder => Origin => Edge => Player，流在观止云整体分发过程中的日志能够几分钟内找到。


7 数据

小编尚且不完全知晓，数据对于一个视频运营平台来说价值到底有多大。小编知道的，至少对于视频直播，依托于越实时的数据，越能够快速定位、解决部分用户故障问题；保障不同付费等级、不同终端、不同区域、不同内容等的观看体验；进行CDN计费数据对账；精准广告等等。

所以观止云BMS还是尽能力的提供了一些数据，而且是几乎实时的数据，上几张图：


可以看到实时在线观看人数，以及区域、运营商分布，观看流畅度，实时带宽负载等

 


可定位到某个具体用户，监控用户的终端环境（操作系统、浏览器、播放器版本），观看体验。

 

其它系统呢，对不起，小编没有见到过。

 

结语        

视频直播的大伙还将持续燃烧，全民直播大时代的背后是靠视频技术、云计算技术的支撑，未来在全景直播、VR直播全面来临时，更需要重视视频平台的技术提升和稳定。对于视频运营者来说，选择一个靠谱的云平台大幅缩减自身基础设施以及研发投入，将重心前移到业务和产品上是为上策。对于视频云平台和CDN服务商来说，当直播市场大浪淘沙归于平静后，视频技术终将成为核心竞争力，其中可管可控的流媒体服务器集群是重中之重，不管你是IaaS、PaaS、SaaS，最后那个S都是Service。

Logo
华为开发者空间

华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。

更多推荐

cover

华为云数据仓库专业级开发者认证重磅发布

avatar 华为开发者空间
cover

KubeEdge 新版本5大特性解读：更完备的节点设备能力，全新的Dashboard体验

avatar 华为开发者空间
cover

一文带你搞懂GaussDB数据库性能调优

avatar 华为开发者空间