CDN，視頻雲，已經“僧多粥少”
視頻直播的持續升溫，無意間也讓帶寬生意的爭奪變得異常殘酷。一時間，各種雲計算、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/rtmpap
