透過網路流媒體，讓用戶可實時在線直播或點播多媒體數字內容，是目前相當熱門的應用。其中，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基礎設施的漸趨完備，使得它成為目前多媒體流媒體服務的主流選項。以現在服務的質量及規模來看，這個組合會流行好一陣子。

推薦閱讀：

相關文章