视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、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做一个横向对比，供视频从业者根据自身业务场景特性择优选用。
BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。
架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。
观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。
核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。
以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。
（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较复杂。
先说结论：
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%性能。
日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，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/rtmpap