Netflix 的系統如何支撐千萬人同時觀看直播?

前陣子 Alex Honnold 不帶任何裝備徒手爬上台北 101 大樓的最高點，在全球掀起一陣討論。身為軟體工程師，在看直播流手汗的同時，不免好奇「Netflix 的直播背後是如何撐起全球觀眾同時收看」這個問題。具體查了一下，Netflix 截至今最多人觀看的直播節目，有超過六千五百萬人同時收看，是個非常驚人的數字。

雖然我們自己沒有開發過直播平台，不過 Netflix 的官方技術部落格，有出過不少篇跟直播相關的技術文章。對此，希望透過這篇文章，展開討論 Netflix 工程團隊的分享，來一探相關的技術精華。

比起隨選串流，直播有哪些技術挑戰?

在讀 Netflix 的直播相關技術文章前，我們有的第一個疑問是「Netflix 的隨選串流 (on-demand streaming) 已經在高吞吐、低延遲，以及可靠都做很好，直播有哪些額外技術挑戰是原本的技術無法解決的呢?」。換句話說，雖然直播同時有六千多萬人觀看，但在熱門節目上線時 (例如當年的魷魚遊戲風潮)，同時觀看人數也不會少去哪，直播為什麼在技術上更有挑戰性?

直播比起隨選串流，需要在極短的時間，完成從攝影機接收、編碼和傳輸，即時處理要保持低延遲並不容易。在觀看模式上，由於直播可能因為突發事件而湧入大量觀眾 (例如某個明星發了一個限動說自己在看，如果是直播，觀眾多半會想馬上轉來看，但如果是隨選的串流，就比較不會有這種想馬上跟看的急迫性)。

在播放緩衝上，隨選的串流可以預先把所有內容都預載；但是直播沒有辦法，所以緩衝的片段比較少。同時因為是即時的，觀眾對於錯誤容忍度比較低 (多數人比較不能接受直播被中斷)，因此團隊在維運上的壓力比較大。

在了解這些區別後，接著讓我們來看 Netflix 團隊如何架構與應對這些挑戰。

整體架構

首先，讓我們看到 Netflix 直播的整體架構，我們大致可以把直播架構分成三個部分。

這三部分別為：

• 獲取直播內容：直播的起點來自於攝影機與收音設備等捕捉到的內容。收到內容後會先進到營運中心做基本檢測 (例如內容沒問題、訊號品質沒問題)。先前 Netflix 有說 Alex Honnold 的直播有 10 秒延遲，如果他不幸摔下會即時切斷，切斷會在這個步驟進行。
• 串流即時處理：直播內容通過檢測後，會進行影片的轉碼，這樣直播影片才能相容於不同使用者的裝置；接著也會進行封裝，讓分發可以更緊密整合到播放系統中。
• 在全球分發直播內容：處理完後的直播內容會透過 CDN 從源站分發到全球各地的邊緣伺服器，讓觀眾可以從最近的伺服器取得內容，降低延遲。

如何確保可用?

對於直播服務來說，要面對的各種不同裝置，例如電視 App、網頁 App、手機的 App，不同裝置支援的格式可能不同；同時也需要面對不同的網路傳輸速度，例如在開發中的國家，可能會遇到網速低與不穩定的狀況。

要確保不論使用者用哪種裝置、不論哪種網速與穩定度，都要能順暢播放直播，就需要轉碼的過程。

具體來說，當收到最初的訊號源後，在轉碼的過程會轉成多種不同影音格式、多種不同畫質的位元率；這樣即使在比較低階的裝置，或者比較慢的網速，也能夠觀看直播。假如沒有做這個步驟，Netflix 在拍攝直播都是用最高規格的攝影機，拍出超高解析度的影片，可能在舊一點的裝置播不了，網速慢一點可能也下載不動。

在上圖的架構中，有一個關鍵是冗餘 (redundancy)。Netflix 為了避免單點故障 (single points of failure)，建立了兩條獨立的直連網路來接收訊號，並且確保中間從轉碼到封裝都獨立進行。這樣一來，即使其中一條有網路問題或設備故障，也能確保有另一層防護。

如何降低延遲?

當提到延遲，就不能不討論傳輸協定。當談到加快傳輸速度，多數人可能會想到在傳輸層使用 UDP 這個協定，而非使用 TCP。

UDP 比起 TCP 的一大特色，是如果傳輸過程中封包有丟失，UDP 不會管，就放其丟失，所以傳輸速度比 TCP 快。對比起來，TCP 的傳輸更可靠，但因為求可靠，封包丟失時會等待重傳，自然會比較慢一點。

雖然重視低延遲，不過 Netflix 並沒有使用 UDP，而是使用基於 TCP 的 HTTP。之所以會有這個技術選擇，主要有幾個原因，第一個是對於直播品質的考量，Netflix 希望做到高品質的直播穩定性，用 UDP 可能導致掉幀，這是從品質角度來看希望能避免的。除此之外，選擇 HTTP 的好處在於，各類裝置幾乎都對 HTTP 支援，所以能在編碼與分發上，都能夠相容。

而從延遲的角度來看，Netflix 透過把檔案切割成一小段一小段來傳輸的方式，有效降低延遲度。具體來說，Netflix 採用 2 秒片段時長的切割 (2-second segment duration)。當這麼做，編碼器 (encoder) 只要每生成一個 2 秒的片段，就可以傳出去，讓終端的播放器可以消費，不用等到整段片段都生成好後才能傳輸。

當然，這個選擇也不是沒有成本，因為從壓縮的效率來看，片段越長的壓縮效率越高，對伺服器負擔會比較小。不過在權衡之下，選擇 2 秒片段時長的切割，能確保直播穩定不掉幀，同時讓延遲度達到業界標準。

閱讀更多

如果對 Netflix 團隊如何讓系統有效擴展、實務上如何做可靠性工程感興趣，我們在 E+ 成長計畫中的主題文都有談到。

對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。