流媒體選擇Nginx是福還是禍？

標籤：

CDN，視頻雲，已經“僧多粥少” ApsaraVideo for Live的持續升溫，無意間也讓頻寬生意的爭奪變得異常殘酷。一時間，各種雲端運算、CDN、視頻雲供應商都在視頻尤其是直播上投入重兵，揭竿而起的新生起義軍們也正馬不停蹄的趕往這方戰場，各種號稱可以在IaaS、PaaS、SaaS不同層面提供平台級、介面級以及產品級服務的花式作戰口號此起彼伏，讓人眼花繚亂，“僧多粥少”可能成為了當前支撐視頻技術解決方案市場最恰當的提法。如此局面之下，視頻雲和CDN們，技術上到底是在競爭什嗎？作為視頻平台和即將要進入視頻領域的運營者，在技術平台的選型和搭建上又如何才能避免掉入大坑？ 一個播放器的背後 誰都知道ApsaraVideo for Live最重要的是流暢和高清，但這光鮮亮麗的背後是技術和成本的雙高門檻，是諸多技術環節艱難積累和苦逼的人肉營運。主播發起一個簡單的直播，主幹流程就曆經了採集、編碼、推流、轉碼、分發、拉流、解碼和播放這麼多環節，還要求在數秒內完成，除此之外直播還有如錄製、流控、安全、審核等等諸多複雜功能需求。 再如，僅一個屌絲觀眾從播放器看這個主播，就可能出現如此多不可知情形發生。這個屌絲的接入網路怎麼樣？使用的系統內容又怎麼樣？一個觀眾尚且如此，要保障百萬千萬層級流暢的觀看，難度可想而知。 高清流暢到底靠的是什麼 也許對於部分視頻電訊廠商和新進入者來說，直播推流端和播放器端依然覺得頭大，但整體來說，除移動端外，PC端推流和播放技術已經比較成熟。難，主要難在傳輸和分發！正常情況下，只要推流端網路狀況良好，傳輸和分發決定著直播是否能夠流暢。 傳輸和分發，涉及到了視頻最核心技術、巨額伺服器和頻寬成本以及國內網路環境極度錯綜複雜。也因為如此，視頻平台基本上都將傳輸和分發環節交由專業的第三方視頻雲端服務商或CDN服務商來完成。我們從網路傳輸的七層中拿出與視頻傳輸分發相關的四層，如： L2資源層：對視頻雲和CDN來說，資源的確存在差別，但在其可承受範圍內，可以視為差別不大； L4傳輸層：傳輸層可針對不同業務情境，比如針對超低延遲可以基於UDP做私人協議等。本文側重闡述視頻流暢的保障，不同應用情境的支援後續文章將專門介紹； L3網路層：視頻雲和CDN公司在該層實現各電訊廠商網間打通、多層Cache系統設計以及使用者就近調度。該層的設計及最佳化對訪問品質極為重要，隨著CDN技術的日益成熟，雖然各家可能存在架構區別，但基本都能保障網路路由正常運轉； L7應用程式層：拋開細枝末節，視頻流的主線還是輸入、傳輸與輸出，承擔這些工作的就是視頻平台最核心組件流媒體伺服器，這就是ApsaraVideo for Live分發最本質的特點，需要專門的流媒體伺服器來分發，所有視頻雲和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 再修改如下欄位： HttpStreamingEnabled true HttpStreamingLiveEventPath "../applications" HttpStreamingContentPath "../applications" HttpStreamingF4MMaxAge 2 HttpStreamingBootstrapMaxAge 2 HttpStreamingFragMaxAge -1 Options -Indexes FollowSymLinks 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資料 小編尚且不完全知曉，資料對於一個視頻運營平台來說價值到底有多大。小編知道的，至少對於ApsaraVideo for Live，依託于越即時的資料，越能夠快速定位、解決部分使用者故障問題；保障不同付費等級、不同終端、不同地區、不同內容等的觀看體驗；進行CDN計費資料對賬；精準廣告等等。 所以觀止雲BMS還是盡能力的提供了一些資料，而且是幾乎即時的資料，上幾張圖： 可以看到即時線上觀看人數，以及地區、電訊廠商分布，觀看流暢度，即時頻寬負載等 可定位到某個具體使用者，監控使用者的終端環境（作業系統、瀏覽器、播放器版本），觀看體驗。 其它系統呢，對不起，小編沒有見到過。 結語 ApsaraVideo for Live的大夥還將持續燃燒，全民直播大時代的背後是靠視頻技術、雲端運算技術的支撐，未來在全景直播、VR直播全面來臨時，更需要重視視頻平台的技術提升和穩定。對於視頻運營者來說，選擇一個靠譜的雲平台大幅縮減自身基礎設施以及研發投入，將重心前移到業務和產品上是為上策。對於視頻雲平台和CDN服務商來說，當直播市場大浪淘沙歸於平靜後，視頻技術終將成為核心競爭力，其中可管可控的流媒體伺服器叢集是重中之重，不管你是IaaS、PaaS、SaaS，最後那個S都是Service。


頭條號 / 新媒體大趨勢
連結：http://toutiao.com/i6272689973091107329/
來源：頭條號（今日頭條旗下創作平台）
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

流媒體選擇Nginx是福還是禍？