聽程序員GG講直播那些事
2016年,直播大火。涌現出了一個個直播產品,映客、花椒、斗魚……嗅到了風口的氣息,一些視頻網站在線教育平臺也開始引入直播。作為一名敬業的產品汪,雖然不負責直播業務,但也對直播頗有興趣,幸得wuli程序員男票也從事直播相關的工作,便有幸一探直播的真相。
1、直播流示意圖
直播流示意圖
- 直播間:視頻采集端,包含一些直播設備。以在線教育直播為例,直播間是老師錄制課程的地方。
- 源站:接受直播間傳送的視頻流,并進行存儲和轉發,由多臺服務器組成。源站相對于CDN來講,是源頭,故而稱之為源站。
- CDN:主動向源站獲取視頻流,并進行存儲和轉發。CDN在這個直播的整個環節中扮演的角色類似于計算機存儲系統中的緩存。
- 用戶:接收CDN傳送的視頻流,觀看直播。
2、直播間-源站的關系
(1)直播間主動向源站傳輸視頻流,這個動作叫推流。
那么問題來了——直播間是如何確定把視頻流推送到哪臺服務器上?
直播間可以配置服務器對應的ip地址。比如:直播間1配置了服務器A和服務器B的IP地址,那么當直播間1產生視頻流的時候,會把視頻流同時傳輸到服務器A和服務器B上。
(2)直播間與源站之間常用的傳輸協議:rtmp協議,hls協議。
傳輸協議是什么鬼?舉個不恰當的例子,傳輸協議相當于是翻譯媒介。一個日本人,和一個俄國人,如果日本人講日語,俄國人講俄語,那么他們是無法溝通的。但如果他們有一門共通的語言,比如英語,在遵從英語的語言規范的前提下,他們是能夠進行溝通的。傳輸協議就是直播間與源站之間的共通語言。
RTMP是Adobe公司的流媒體傳輸協議,普通網絡用戶均可使用,包括非IOS平臺用戶。
HLS是IOS平臺下的流媒體傳輸協議。
3、用戶與CDN
用戶在終端進行觀看直播的操作,相當于向CDN發送獲取視頻流的請求。
那么問題來了,用戶終端發起獲取視頻流請求的時候,是如何確定向哪個CDN獲取?
在用戶發起獲取視頻流請求的時候,出于傳輸效率的考慮,用戶與CDN之間有一套路由算法(這個算法一般是由CDN設定的)。比如這樣一個場景,XX公司/XX產品的直播間在北京,用戶在西安。當這個西安用戶發起獲取直播流的請求時,XX公司/XX產品在西安、上海、南京、廣州、太遠都有CDN,那么路由算法會告訴用戶終端,該獲取哪個CDN,比如獲取西安CDN能夠獲得較高的傳輸速率,那么該用戶的終端就會向西安CDN獲取視頻流。
4、CDN與源站
當用戶向CDN發送獲取視頻流的請求之后,CDN會向對應的源站服務器獲取視頻流,這個動作叫做“回流”。
那么問題又來了,CDN如何知道向哪個服務器獲取視頻流?
用戶終端向CDN請求獲取視頻流的時候,在傳送請求的時候,會告訴CDN向哪臺源站服務器獲取視頻流,會在傳送的數據中含有所獲取源站服務器的IP信息。我們通常所說的切換線路,指的就是用戶在向CDN發送獲取視頻的請求時,更換了獲取源站服務器的IP信息。
5、補充——為什么需要CDN?
解決帶寬問題。用戶對直播的播放流暢度、互動實時性有較高的要求。對于這樣的性能要求,需要通過提高帶寬來解決。如果直播服務提供者的帶寬非常高,那么源站服務器的數據傳送效率就大大提高,流暢度和實時性是完全能夠滿足的。但考慮到成本的問題,服務提供者一般會選擇使用CDN,將源站服務器的數據傳送到CDN,通過CDN進行存儲轉發。我們可以想象,如果用戶直接向源站服務器請求獲取視頻流,會導致源站服務器壓力過大,畢竟在大多場景下,直播的觀看人數是比較多的,而通過CDN的存儲轉發可以降低源站服務器的壓力。
本文系人人都是產品經理團隊@張婷?原創發布,未經許可,不得轉載。
- 目前還沒評論,等你發揮!