30-24之直播與點播可動版的改良 ( 正式版 )

正文開始

上一篇文章中咱們學習完了 CDN 的相關知識以後,接下來這篇文章,我們將要將上一篇所學的來改善咱們以下兩篇文章可動版的架構。

使用 CDN 來調整可動版的架構

30-20之如何建立像 KKTV 一樣的點播功能呢 ? 30-21之如何建立的像 17 一樣的直播功能呢 ?

點播

直播

本篇文章會分成以下幾個章節:

  • 可動版本的問題。
  • 點播的架構改善版本。
  • 直播的架構改善版本。

可動版本的問題

在筆者這篇文章中『30-22之點播與直播可動版問題探討』,我們探討了可動版有以下的問題:

  1. 人多時連線數限制問題。
  2. 人多時頻寬問題。
  3. 人多時效能消耗問題。
  4. 遠距離看片卡頓的問題。

基本上 1、3 我們可以用傳統的方法(加機器)來解決,而 2、4 就無法使用加機器來進行解決,因為以 2 的頻寬問題,就算你加了在多的機器,如果你在出去的網路還是在同一條,那頻寬還是沒加大,問題還是沒解決。而 4 的話就更不用說,只能讓使用者離機器更近一點才能解決。

點播架構的改善版本

基本上點播的架構會改成如下圖,它會將 CDN 加上去,而這樣就可幫助我們解決頻寬距離看片卡頓的問題。

先來說說頻寬的部份, CDN 基本上分散在不同的地方,這也代表這基本上它們的頻寬是各別獨立的,所以不太會發生搶頻寬的問題,而另一點距離的問題,由於大部份的 CDN 都會搭配使用智能 DNS 來幫助找到最近的 CDN,因此可以解決因為離影片來源太遠,而容易造成封包遺失與封包順序不一致問題。

而且用了 CDN 事實上還有一個好處,那就是可以保證接近 100 的機率可以看片,你想想如果是自已建的一台 Media Server 來提供看片,如果它倒了,不就不能看片了,而有 CDN 就可以自動的轉到另一個臨近的 CDN 來取得資料。

接下來說說它的運行流程,基本上如下 (以 HLS 拉流為範例):

  1. Media Server 收到新的影片檔,然後它會將他進行切片,分成一小個一小個檔案 .ts。
  2. 接下來會分發到各 CDN 上。
  3. 有個用戶發送 Http 請求到智能 DNS 會給予最近的 CDN 位置。
  4. 用戶在發送請求給 CDN 取得影片,CDN 開始將一小段一小段 .ts 傳送給用戶。

直播架構的改善版本

首先我們先看加了 CDN 的第一種的改善版如下圖。這種架構基本上一樣可以解決掉頻寬與遠距離觀看會卡頓的問題。

它的運行流程如下:

  1. 直播主推送 RTMP 到 Media Server。
  2. Media Server 將 RMTP 依據所需支援的協議,切分成小檔案 (ex. HLS 的 .ts)
  3. Media Server 推送到 CDN。
  4. 聽眾使用拉流 (ex. HLS、HTTP-FLV、Dash、RTMP) 來觀看直播主。

上面這個版本有啥問題嗎 ?

如果這是個非互動性要求的直播 (ex. 運動賽事直播) 的話,那問題不大。

但如果是要求互動性的直播,那就有問題了,因為它的延遲會比沒有使用 CDN 還高,也就說沒使用 CDN 時直播主說話後要 5 秒鐘才能聽的到的話,那用了 CDN 可能就要 10 秒,原因如下圖,因為它要多傳輸不少東西。

因此後來有人就提出直接將直播主的聲音丟到 CDN,然後由 CDN 來處理切分這些事情,架構圖與執行流程如下。但是相對的此架構的成本一定會比上述的還高,因為 CDN 要幫你多做不少事情。

  1. 直播主推送 RTMP 到離它最近的 CDN。
  2. CDN 幫你依據所需支援的協議,切分成小檔案。
  3. 聽眾使用拉流 (ex. HLS、HTTP-FLV、Dash、RTMP) 來去最近的 CDN 觀看直播主。
  4. 離聽眾最近的 CDN 會使用拉流來將直播主所在的 CDN 進行畫面拉去。

結論

基本上以上的點播與直播的改善版本,應該就是大部份雛形,然後你只要記好,在直播與點播的應用中,沒有 CDN 應該是無法做起來的,所以入深入的理解 CDN 的原因與理解各家 CDN 的應用,相信可以幫助你做出各優質的點播與直播的應用。

接下來下一篇文章,我們就要來研究看看互動直動的一些挑戰。

參考

comments powered by Disqus