HLS+CDN巧妙的串流技術組合

在現今的網路環境，基於CDN（Content  Delivery Network）來提供串流服務已成主流，不論是直播或是「點播（即隨選視訊－Video On Demand）」皆然。

直播指的是和內容來源同步播放，僅維持一定的時間差，像電視頻道或是實況轉播的節目，都是採用直播的形式。在直播的情況下，內容無法快轉或倒轉，只能隨著時間播放。

而點播就不同了，點播的內容，都是早就存在好的檔案，並不像直播內容，都是由直播內容來源即時的產生。也因此，二者運用的技術會有所差異。

在過去，直播不是透過即時的串流協定，就是透過P2P的即時串流來做到，理由之一，便是因為直播內容是即時產生，不方便事先產生一個靜態的檔案來供接收端取用。但目前使用CDN的方式來提供接收端存用，卻都是以靜態檔案的方式，因為，CDN的作用基本上，就是把靜態檔案分布到多個快取伺服器上去，以降低各地客戶端存取的延遲時間及分散流量。

HLS協定為HTTP提供網路內容直播技術

那麼直播要如何基於CDN來做到呢？要回答這個問題，就得從HLS說起了。

HLS（HTTP Live Streaming）通訊協定是由Apple所提出的，現在雖然尚未成為IETF的標準，但是因為主流的平臺，諸如iOS/Android等重要的手持裝置平臺，皆已支援，使得它儼然成為在業界流通的準標準了。

那什麼是HLS呢？簡單的來說，HLS就是一種基於HTTP協定之上的串流協定，而且可適用於即時的直播用途。

HTTP的基本運作原則，就是一個請求可以取得一個檔案。倘若想要取得一個不知道長度有多長的檔案，像即時的串流就是如此，它很有可能不只是不知道有多長，甚至，它不會有結束。過去，有些人會基於HTTP做一些Hacks，例如設一個非常大的檔案長度，來表示一個即時的串流。但是，有些多媒體檔案格式，在串流內容還沒結束時，形同檔案沒有完成，接收端也可能無法正確的剖析及使用。

所以，要怎麼運用HTTP來做直播呢？

HLS的核心想法，是將串流的內容切割成一個個短的片段，例如，如果是影音內容的話，就把內容切割成約十秒左右的片段。不一定要切成十秒，究竟要切成幾秒，還可以考慮其他的因素。通常，這十秒的片段的格式其容器（container）格式為MPEG-TS，所包裝的視訊格式為H.264 ，而音訊格式為AAC。因此，整個影音的內容，就會被切割成許許多多的小片段。

當支援HLS的播放器要播放時，是從一個 .M3U8格式的播放清單開始，在這個播放清單中，會有一連串的MPEG-TS檔案的網址。此時，播放器只需要逐一的取出每個MPEG-TS檔案的網址，並且透過HTTP協定持續取得每一個MPEG-TS檔案，就能夠持續的播放整個串流的內容。

有一點很重要的是，在播放器播放某個MPEG-TS檔案的內容時，它可以取得整個清單中更之後的MPEG-TS檔案，甚至做一定程度的預儲，這使得前一個MPEG-TS播放完成時，下一個MPEG-TS已經準備好了，因此可以達到流暢的播放。若是預儲的份量夠，則可以提供足夠的緩衝效果，來因應時有的網路傳輸速度短暫、不穩定情況。

正因為它是把整個串流的內容切割成多個小檔案，因此，得以實現即時的串流。

但說是即時，也不那麼的完全即時。因為，整個內容來源就算很快的完成格式的轉換、壓縮、及切割，客戶端也要載入起碼一個MPEG-TS，之後才能播放，也就是說，起碼也要再等十秒（若是單一個MPEG-TS切割成十秒的話），才能看到直播的內容。但是，絕大多數的應用情境，都可以接受一定程度的直播延遲，這使得HLS有機會成為網路串流直播的主要選項。

當初HLS選擇基於HTTP是個不錯的決定，怎麼說呢？第一個考量是，HTTP是一個「穿透率」比較好的協定，因為它是瀏覽網站時所需的協定，因此，許多防火牆都會開放HTTP通過。倘若是其他的串流協定，不見得就會出現在防火牆的開放清單中。

CDN技術的應用，協助快速擴展執行規模

此外，還有一個重要的好處，就是有許多擴展規模的技術，都是基於HTTP而做的，這是為了開發能承載高流量、大規模的網站而研發的，如今都可以運用在HLS服務的擴展規模之上，例如CDN就是其中之一。

當串流內容經過如上所描述的一連串程序，產生一個個MPEG-TS檔案之後，即可將它們送至CDN之上，接著再利用CDN的機制，將不同客戶端的來源，分配至不同的快取伺服器。如此一來，客戶端可以更就近、快速取得檔案，而流量也都不需要集中在特定的伺服器或機房，而可以分散掉，而分散化就是得到規模可擴充性的主要手段之一。

此外，同一個內容，還可以被編碼成不同的位元率（bitrate），也就是會提供不同的品質。因為透過網路連接上串流服務的客戶端，可能會有各種不同可能的連線頻寬，針對不同連線頻寬的客戶端，就可以藉此提供不同的品質，使得它們都可以流暢的觀看。

而使用HLS的好處之一，也包括了播放過程中，可因應客戶端連線頻寬變化而執行品質的調整。

當播放時，發現客戶端的頻寬持續不足的情況，便可以將它導向另一組位元率較低的MPEG-TS檔案，以提高它播放的流暢度，而這個轉換的動作，在HLS的設計下，是可以動態的進行。所以，你可以看得出來，這樣的設計，有助於行動裝置在多媒體串流的播放，因為行動裝置的連線品質通常變化動態，會比個人電腦來得還大。

所以，經過這樣的說明，就不難了解HLS和CDN之間的關聯性。倘若只有HLS，最終還是必須面臨傳統集中式架構的問題，即頻寬使用集中、無法分散的缺點。但正如前面所述及的，選擇了HTTP，等於選擇了為HTTP所開發出來的各種擴展規模的技術，包括CDN在內。這使得立足於CDN的HLS，有了優秀的規模可擴充性。

現在，許多雲端平臺都提供CDN的服務，例如Amazon的CloudFront，這更便於串流服務的提供者，因為只需將串流內容直接送往CDN，即可處理掉擴展服務規模的許多技術議題。在這裡，雲端的平臺技術，對即時串流服務，起了很大的作用。

應用HLS+CDN的成本不一定低

此外，即使不是即時的串流，也可以使用HLS+CDN的技術組合。也有不少「點播」的服務者，使用靜態檔案部署於CDN的方式，來提供點播的檔案，例如使用 .MP4 做為容器格式，內含H.264 及AAC格式的視訊及音訊。

這也行的通，但是MP4 的容器格式對播放器來說，需要多花點時間，才能取得相關的一些索引資訊，因此，在載入時間上就不像HLS那樣的短。在播放時，需要更多的時間才能開始收看。此外，這種方式在CDN上，會比HLS成本更高。

但HLS也並非毫無缺點，舉例來說，MPEG-TS格式的額外負擔比較重，因此，會提高整體傳輸時所需的位元率。

總而言之，HLS的設計搭上CDN基礎設施的愈趨完備，使得它成為目前多媒體串流服務的主流選項。以現在服務的品質及規模來看，這個組合會流行好一陣子。