當你在看 YouTube 影片、Netflix 電影、Twitch 直播、或是線上體育轉播時，你看到的影片內容，很可能都是透過同一套技術送到你面前的。
這套技術就是 HLS（HTTP Live Streaming）。
這篇文章會帶你從零開始，搞懂 HLS 是什麼、它的運作原理，以及它怎麼應用在直播和一般影片點播上。
看完這篇，你就能理解為什麼網路變慢時畫質會自動變糊但影片不會斷、為什麼 Netflix 和 YouTube 用的是同一套串流技術。
📖 系列文導讀：這是直播串流系列文的第二篇。第一篇介紹了 RTMP 協定——負責直播「第一哩」的老字號。這篇接著講 HLS，也就是 RTMP 把訊號交給伺服器之後，怎麼分發給全世界觀眾的關鍵技術。
HLS 是什麼？Apple 推出的主流串流協定
HLS 的全名是 HTTP Live Streaming，中文可以翻成「HTTP 即時串流」。
在深入介紹之前，先用白話解釋什麼是「串流協定」。
先搞懂「串流協定」是什麼
「串流協定」指的是一套規範好的規則，規定「影音資料怎麼在網路上傳輸」。
你可以想像它是網路影音界的交通規則：主播端、伺服器、觀眾端這三方，要按照這套規則來打包、傳送、接收影音資料，彼此才能互相看懂。
如果沒有統一的協定會怎樣？
假設主播 A 用自己發明的一套規則送資料，觀眾 B 的播放器看不懂那套規則，畫面就播不出來。
為了避免這種混亂，業界會採用幾套大家都同意的通用協定，例如：
- RTMP：系列文第一篇介紹過的，主要負責主播推流給伺服器這一段
- HLS：就是這篇要介紹的，負責伺服器把影音送給觀眾
- DASH、WebRTC 等：其他各有用途的協定
每個協定有自己擅長的場景，HLS 則是目前「播放端」這段路用得最廣的協定。
HLS 的來歷
HLS 是 Apple 在 2009 年推出的串流協定，一開始的目的是要讓 iPhone 可以順暢地看直播和影片。
因為 Apple 的影響力很大，加上 HLS 技術夠好（後面章節會解釋為什麼），整個業界慢慢都跟著採用，最後變成幾乎所有平台都支援的標準。
具體有多主流？舉幾個你每天都在用的例子：
- YouTube：看直播和一般影片都用 HLS
- Netflix、Disney+：這類串流平台大量使用 HLS
- Twitch：直播實況用 HLS 發送給觀眾
- iPhone、iPad 原生播放器：只認 HLS，不認別的協定
如果你今天是個影音平台工程師，只要支援 HLS 一種協定，就能服務到絕大多數觀眾，這就是「主流」的具體意義。
直播和點播都通吃
雖然 HLS 名字裡有「Live（即時）」這個字，容易讓人誤會只能用在直播，但實際上 HLS 同時支援直播和隨選影片（VOD）兩種場景。
這點等等會詳細說明。
HLS 的核心原理：切片 + 播放清單
要理解 HLS，只要記住兩個關鍵字： 切片（segments） 和 播放清單（playlist）。
切片：把影片切成一小段一小段
HLS 不會把一整個影片或直播串流，當成一個大檔案傳給你。
它會把影片切成很多個小片段，每段通常只有幾秒鐘長。
這些小片段就叫做 segments。
播放清單：告訴播放器片段的順序
有了一堆切好的小片段，播放器怎麼知道要按什麼順序播放？
這時候就需要 播放清單（playlist）。
播放清單裡面記錄了：
- 有哪些影片片段
- 它們的播放順序
- 每個片段的網址在哪裡
你可以把它想像成一份「播放目錄」，播放器拿到這份目錄後，就會按順序一個一個去下載片段來播放。
在 HLS 裡，這份播放清單是用一種叫做 M3U8 的檔案格式來儲存的。
你可以把 M3U8 想像成一個文字檔（就像記事本一樣），裡面寫著所有片段的網址和播放順序。
當你看到網址結尾是 .m3u8 的連結，就知道那是 HLS 的播放清單檔案。
為什麼叫「HTTP」Live Streaming？
HLS 下載這些播放清單和片段時，用的是最普通的 HTTP 協定（跟你瀏覽網頁一樣）。
這裡可以跟系列第一篇的 RTMP 做對比：RTMP 用的是特殊協定，需要專門的串流伺服器；HLS 用的是 HTTP，一般的網頁伺服器和 CDN 就能跑。
這個差別帶來一個很大的好處：影音內容可以直接搭上「現成的網頁基礎建設」，不用特別架設。
這也是 HLS 能變得這麼主流的關鍵原因之一。
HLS 兩種應用場景：直播與 VOD 點播
同樣的 HLS 機制，可以套用在兩種完全不同的使用情境。
這兩個場景的差別不在技術本身，而在「片段什麼時候產生」。
場景一：直播（Live Streaming）
直播的特點是「邊拍邊切、邊切邊播」。
想像你在看 Twitch 實況——主播正在直播打遊戲，他的畫面是即時發生的，伺服器不可能等「整場直播結束」才開始切片，因為那樣觀眾就沒得看了。
所以直播情境下，伺服器每隔幾秒就會：
- 把剛剛收到的影像切出一個新片段（例如 3 秒一段）
- 更新播放清單，把新片段的網址加進去
- 舊的片段會慢慢從清單裡被移除（因為直播通常不能拖回去看很久以前的內容）
觀眾的播放器這邊，會做一件重複的事：不斷重新抓取最新的播放清單。
每次抓到新版清單，播放器就知道「喔，又有新片段可以下載了」，接著把新片段播出來。
這就是你看 Twitch 實況、YouTube Live、體育賽事轉播時背後發生的事。
直播的技術挑戰：因為片段是即時產生的，伺服器的切片速度、清單更新頻率、CDN 的同步速度都要夠快，不然觀眾會一直卡在「等新片段」。
場景二：隨選影片（Video on Demand，簡稱 VOD）
VOD 的特點是「先切好、再等觀眾來看」。
想像你在 YouTube 上傳了一支 10 分鐘的旅遊影片。
YouTube 收到你的檔案後，會在背景一次把整支影片切成所有片段（例如切成 200 個各 3 秒的小片段），同時也把播放清單一次做完。
這份播放清單從頭到尾都不會變，裡面完整列出這 200 個片段的順序和網址。
觀眾任何時候點進來看這支影片，播放器會做一件單純的事：把完整清單抓下來，從頭播到尾。
因為清單是完整的，播放器也知道整支影片有多長，所以你可以：
- 拖拉進度條跳到任何位置（播放器會直接去抓對應的片段）
- 倍速播放（1.25x、1.5x、2x，直接加快片段的播放速度）
- 隨時暫停、重播（因為所有片段的網址都在清單上）
像是你在 YouTube 上看一支已經上傳好的影片、在 Netflix 上看電影、或是在線上課程平台看教學影片，都是 VOD 場景。
VOD 的技術挑戰：主要在「事前準備」這個階段——上傳後的轉檔、切片、產出多種畫質版本，這些事情在觀眾看之前就要全部做完。
兩種場景的核心差異
把兩個場景放在一起比較，差異就清楚了：
以直播為例：HLS 的完整流程
接下來我們用「直播」作為例子，把 HLS 的完整流程拆開來看。
第一步：編碼器把影音壓縮
當主播開始直播時，攝影機捕捉到的原始影音檔案非常龐大，沒辦法直接從網路傳送。
所以我們需要一個 編碼器（Encoder） 來把它壓縮：
- 把影像壓縮成 H.264 格式
- 把聲音壓縮成 AAC 格式
這兩種是目前非常主流的壓縮格式，可以大幅縮小檔案大小，同時不會明顯影響畫質和音質。
第二步：用 RTMP 打包送到伺服器
壓縮完的影音，會透過 RTMP（Real-Time Messaging Protocol，即時訊息協定） 打包。
打包完之後，這個 RTMP 串流會被送到一台 邊緣伺服器（Edge Server）。
你可以把邊緣伺服器想像成一個「中繼站」，負責第一線接收主播傳來的訊號。
為什麼這裡要用 RTMP，而不是直接用 HLS？
因為 RTMP 比較適合「從主播端傳到伺服器」這段路——延遲低、適合單點對單點的即時傳輸。
而 HLS 比較適合「從伺服器傳到大量觀眾」這段路，可以搭配 CDN 做大規模分發。
（想深入了解 RTMP 的設計，可以回頭看系列第一篇。）
第三步：媒體伺服器重新打包成 HLS
邊緣伺服器接到訊號後，會轉交給 媒體伺服器（Media Server） 做兩件事：
- 把 RTMP 串流拆開
- 重新切成片段並產生播放清單，也就是打包成 HLS 格式
邊緣伺服器和媒體伺服器實務上常常是同一台機器，概念上分開是為了說明它們各自的職責。
規模大的平台（例如 Twitch、YouTube）會把它們分成不同的機器，讓系統更容易擴展；規模小的平台可能一台就包辦了。
除此之外，媒體伺服器還會做一件很關鍵的事：把同一個直播轉碼成好幾種不同的位元率。
什麼是「位元率（Bitrate）」？
位元率就是每秒鐘資料量的大小，單位通常是 Mbps（每秒多少 Mb）。
位元率越高，畫質越好，但需要的網速也越快：
- 1080p 高畫質：約 5 Mbps
- 720p 中畫質：約 2.5 Mbps
- 480p 低畫質：約 1 Mbps
媒體伺服器會同時準備這三種不同位元率的版本，供不同網速的觀眾選擇（等一下自適應位元率那節會詳細解釋怎麼選）。
第四步：送到 CDN 加速分發
媒體伺服器會把這些播放清單和多個位元率的片段，送到 CDN（Content Delivery Network，內容傳遞網路）。
CDN 會把這些內容 暫存（cache） 在全世界各地的節點伺服器上。
這樣一來，不管觀眾在哪個國家，都可以從離他最近的節點拿到內容，延遲大幅降低。
第五步：播放器開始播放
當觀眾打開播放器時，依序會發生：
- 先跟 CDN 要一份 主播放清單（Main Playlist）
- 拿到主清單後，再要求預設位元率的播放清單和對應的片段
- 這些片段會一個接一個載入
- 當播放器緩衝完前三個片段後，直播就正式開始播放了
VOD 場景的流程差異
如果是 VOD（點播）場景，流程會簡化很多：
- 第一、二步不需要：影片是事先錄好的檔案，不需要即時編碼和 RTMP 推流
- 第三步事先做好：切片和產生播放清單是上傳影片時就完成的
- 第四、五步一樣：CDN 分發和播放器播放的邏輯跟直播完全相同
簡單說，VOD 就是「事先把所有東西準備好放在 CDN 上」，觀眾來的時候從第四步開始就好。
HLS 自適應位元率：網速變慢自動降畫質
HLS 最強大的功能之一叫做 Adaptive Bitrate Streaming（ABR，自適應位元率串流）。
這個功能在直播和 VOD 都能用，原理都一樣。
我們用一個實際情境來理解。
想像你在家用 Wi-Fi 看影片看得很順，結果你走出家門連上 4G，網速突然變慢了。
如果是傳統的串流方式，畫面可能會開始卡頓，甚至直接斷線。
但 HLS 不會。
當 HLS 播放器偵測到網路頻寬變化時，它會自動跟 CDN 要一份適合當前頻寬的播放清單和片段。
比方說，從原本的 1080p（5 Mbps）自動切換到 720p（2.5 Mbps）。
整個切換過程是完全無縫的，你不會感覺到任何中斷，頂多就是發現畫質好像稍微變糊了一點。
這就是為什麼你在搭捷運看 YouTube 時，畫質會偶爾變模糊，但影片本身不會斷掉。
HLS 的優點有哪些？
HLS 之所以變成目前最主流的串流協定，有幾個關鍵原因：
- 支援 HTML5：現代瀏覽器幾乎都能直接播放 HLS，不用另外裝 plugin 或特別的播放軟體
- 更安全、更穩定：傳輸過程比較可靠，不容易斷線
- 規範公開：HLS 的技術規格是開放的，開發者可以自由根據需求來最佳化和客製化
- 可以用一般 CDN：因為底層是 HTTP，不需要特殊伺服器，大規模分發成本比較低
- 直播與 VOD 通吃：一套技術同時搞定即時串流和點播影片
這幾點加起來，讓 HLS 變成各大影音平台的首選方案。
HLS 重點整理
看到這裡，你應該對 HLS 有完整的認識了。
快速整理一下剛剛學到的重點：
- HLS 是 Apple 在 2009 年推出的 HTTP 即時串流協定，是目前最主流的影音串流技術
- 雖然名字有「Live」，但 HLS 同時支援直播和隨選影片（VOD）
- HLS 的核心機制是：把影片切成片段，用 播放清單（M3U8） 告訴播放器怎麼播
- 因為用的是 HTTP，HLS 可以直接搭配一般 CDN 來大規模分發影片（這跟 RTMP 需要特殊伺服器是關鍵差異）
- 以直播為例，完整流程是：編碼器 → RTMP 送到伺服器 → 媒體伺服器切片成 HLS → CDN 分發 → 播放器播放
- VOD 場景跳過前兩步，影片上傳時就把後面的步驟做好放在 CDN 上
- HLS 支援自適應位元率串流，會根據網路速度自動切換畫質
- HLS 的優點包括：支援 HTML5、安全穩定、規範開放、可搭配一般 CDN、直播 VOD 通吃
下次不管是看直播、還是看一般影片，你都能理解背後發生的事情了。
系列文的第三篇會介紹另一個新興的串流協定：WebRTC——主打「超低延遲」的即時通訊協定，適合視訊會議、線上拍賣這種需要即時互動的場景。