前言
隨著直播行業大火，各種直播類產品和產品層出不窮，能夠滿足各方人員的需求和互動，也使得斗魚、虎牙、抖音都隨著直播業的大火而欣欣向榮，
大家也對直播平臺了解不少，也參與使用，但是怎么樣才能研發出視頻直播平臺呢？那么針對于這個問題就是我今天想給大家講解的一些東西，首先要對直播協議有所了解，然后怎么樣使用作者研發的surging 去搭建直播平臺，首先接下來，我就給大家簡單介紹下常見的直播協議，
常見的直播協議
國內常見的直播協議有幾個：RTMP、HLS、HTTP-FLV，下面我們來一一介紹，
RTMP，全稱 Real Time Messaging Protocol，即實時訊息傳送協議，Adobe 公司為 Flash 播放器和服務器之間音視頻資料傳輸開發的私有協議，作業在 TCP 之上的明文協議，默認使用埠 1935，協議中的基本資料單元成為訊息（Message），傳輸的程序中訊息會被拆分為更小的訊息塊（Chunk）單元，最后將分割后的訊息塊通過 TCP 協議傳輸，接收端再反解接收的訊息塊恢復成流媒體資料，
RTMP 主要有以下幾個優點：RTMP 是專為流媒體開發的協議，對底層的優化比其它協議更加優秀，同時它 Adobe Flash 支持好，基本上所有的編碼器（攝像頭之類）都支持 RTMP 輸出，現在 PC 市場巨大，PC 主要是 Windows，Windows 的瀏覽器基本上都支持 Flash，另外RTMP適合長時間播放，曾經有過測驗，連續 10 天多連續播放沒有出現問題，最后 RTMP 的延遲相對較低，一般延時在 1-3s 之間，一般的視頻會議，互動式直播，完全是夠用的，
當然 RTMP 并沒有盡善盡美，它也有不足的地方，一方面是它是基于 TCP 傳輸，非公共埠，可能會被防火墻阻攔；另一方面，也是比較坑的一方面是 RTMP 為 Adobe 私有協議，很多設備無法播放，特別是在 iOS 端，需要使用第三方解碼器才能播放，
FLV (Flash Video) 是 Adobe 公司推出的另一種視頻格式，是一種在網路上傳輸的流媒體資料存盤容器格式，其格式相對簡單輕量，不需要很大的媒體頭部資訊，整個 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 組成，因此加載速度極快，采用 FLV 格式封裝的檔案后綴為 .flv，
而我們所說的 HTTP-FLV 即將流媒體資料封裝成 FLV 格式，然后通過 HTTP 協議傳輸給客戶端，
HTTP-FLV 依靠 MIME 的特性，根據協議中的 Content-Type 來選擇相應的程式去處理相應的內容，使得流媒體可以通過 HTTP 傳輸，相較于 RTMP 協議，HTTP-FLV 能夠好的穿透防火墻，它是基于 HTTP/80 傳輸，有效避免被防火墻攔截，除此之外，它可以通過 HTTP 302 跳轉靈活調度/負載均衡，支持使用 HTTPS 加密傳輸，也能夠兼容支持 Android，iOS 的移動端，
說了這么多優點，也來順便說下 HTTP-FLV 的缺點，由于它的傳輸特性，會讓流媒體資源快取在本地客戶端，在保密性方面不夠好，因為網路流量較大，它也不適合做拉流協議，
上述兩個協議都是有Adobe公司推出的，而下面要講的 HLS (HTTP Live Streaming) 則是蘋果公司基于 HTTP 的流媒體傳輸協議，主要應用于 iOS 設備，包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音視頻直播服務和錄制內容（點播）等服務，
相對于常見的流媒體協議，HLS 最大的不同在于它并不是一下請求完整的資料流，它會在服務器端將流媒體資料切割成連續的時長較短的 ts 小檔案，并通過 M3U8 索引檔案按序訪問 ts 檔案，客戶端只要不停的按序播放從服務器獲取到的檔案，從而實作播放音視頻，
流媒體協議 RTMP, HTTP-FLV, HLS 簡單對比
| 協議 | 傳輸協議 | 格式 | 延時 |
| rtmp | Tcp | flv | 1-3秒 |
| http-flv | http | flv | 1-3秒 |
| hls | http | m3u8 | 4-10秒 |
RTMP 協議為流媒體而設計，在推流中用的比較多，同時大多 CDN 廠商支持RTMP 協議，
HTTP-FLV 使用類似 RTMP流式的 HTTP 長連接，需由特定流媒體服務器分發的，兼顧兩者的優點，以及可以復用現有 HTTP 分發資源的流式協議，它的實時性和 RTMP 相等，與 RTMP 相比又省去了部分協議互動時間，首屏時間更短，可拓展的功能也更多，
HLS 作為蘋果提出的直播協議，在 iOS 端占據了不可撼動的地位，Android 端也同時提供相應的支持，
如何架構實作
rtmp 協議架構圖
調度服務網關是針對于外網服務呼叫， ， 提供基于rest 查詢流對應的服務器地址，
直播終端通過調度服務網關獲取的rtmp 服務地址，通過地址進行推流，rtmp服務獲取到資料后，然后轉推到其它的rtmp服務上，rtmp再把流推給訂閱的客戶端
http-flv 架構圖
以上是通過rtmp 服務轉推給http-flv 訂閱的客戶端
基于surging 微服務引擎如何實作
比如現在需要獲取live1/livestream直播地址, 那么首先可以通過地址/locate 獲取wanip外網地址， routepath 是rtmp服務的服務路由路徑，key是直播需要傳過去地址livestream,然后rtmp 埠定義為76,那么接下來獲取的地址就是
http://192.168.249.103:76/live1/livestream
surging 需要參考liveStream 模塊，這樣就能支持直播協議rtmp,http-flv,hls(暫時還未實作)，然后還需要通過配置surgingsetting， 配置如下：
"LiveStream": { "RtmpPort": 76, //rtmp 埠 "HttpFlvPort": 77, //HttpFlv 埠 "EnableLog": true, //是否啟用log "RouteTemplate": "live1", //直播服務路由規則名稱，可以根據規則設定，比如集群節點2，可以設定live2, 集群節點3，可以設定live3 "ClusterNode": 2 //集群節點數里，會根據routetemplate 轉推流 }
然后可以通過ffmpeg或者obs進行推流，以ffmpeg 工具為例，可以輸入以下命令
ffmpeg -re -i D:/大H包.HDTC1280高清國語中字版.mp4 -c copy -f flv rtmp://127.0.0.1:76/live1/livestream2 客戶端采用PotPlayer進行播放，比如可以添加地址rtmp://127.0.0.1:76/live1/livestream2 ，如果你部署了另外一臺rtmp服務，設定的是65埠，那么可以添加rtmp://127.0.0.1:65/live1/livestream2進行播放
可以支持一臺N個推流，N個訂閱播放，如下圖：
總結
surging 現在分為兩個版本，一個是社區版本surging ，一個是企業版本microsurging/SurgingVista, 企業版不僅功能強大，支持流媒體服務等協議組件和中間件，并且還支持多語言定制化需求，完全可以滿足各大公司的需要，如有意見，可以和作者聯系，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/281370.html
標籤：.NET技术