【計算機網路筆記】2.6 Video Streaming and Content Distribution Networks

Hello Guys, I’m LukeTseng. 歡迎你也感謝你點入本篇文章，本系列主要讀本為《Computer Networking: A Top-Down Approach, 8th Edition》，就是計算機網路的聖經，會製作該系列也主要因為修課上會用到。若你喜歡本系列或本文，不妨動動你的手指，為這篇文章按下一顆愛心吧，或是追蹤我的個人公開頁也 Ok。

2.6.1 Internet Video（網際網路視訊）

在此探討的為預錄視訊串流（Streaming Stored Video）。

其運作模式是將預先錄製好的媒體（如電影、電視節目、UGC 影片）放置在伺服器上，使用者根據需求（On-demand）發送請求來觀看。

視訊本質上是連續的影像，資料量極其龐大，它是網際網路上對頻寬需求最高、對效能最敏感的應用類型之一。

其中所面臨的挑戰：如何在頻寬有限且會波動的網路環境中，傳送高位元率（High Bit Rate）的資料，並保持播放的流暢度。

術語解析

  1. 位元率（Bit Rate）：視訊每秒傳輸所需的資料量。從低畫質的 100 kbps 到 4K 串流的 10 Mbps 以上不等，為衡量網路負載的關鍵指標。
  2. 壓縮（Compression）：將原始數位影像進行編碼以減少資料量的過程。位元率越高，影像品質越好，但檔案越大，因此需要做壓縮。
  3. 端對端吞吐量（End-to-End Throughput）：從伺服器到客戶端這條路徑上，網路實際能傳送資料的速率。

視訊的本質與數位化

以電腦科學的角度看，視訊其實就是一系列以固定速率（例如每秒 24 或 30 張）播放的影像（Images）。

  • 未壓縮的數位影像是由像素（Pixels）陣列組成的。
  • 每個像素由數個位元編碼，代表亮度和顏色。

壓縮的必要性與權衡

若不壓縮視訊，原始資料量會大到無法在網路上傳輸，因此需使用現成的壓縮演算法來處理視訊。

我們可將視訊壓縮到幾乎任何我們想要的位元率，但代價是畫質的損失，因此這是一種位元率與畫質之間的權衡問題。

位元率數據級距：

  • 低品質視訊：約 100 kbps。
  • 高畫質電影（HD）：超過 4 Mbps。
  • 4K 串流：超過 10 Mbps。

網路傳輸的黃金法則

為了確保使用者能順暢觀看，網路必須滿足一個簡單但嚴苛的數學條件：平均端對端吞吐量（Average Throughput） ≥\ge 視訊的壓縮位元率（Encoded Bit Rate）

  • 吞吐量 << 位元率：播放就會卡頓（Buffer），因為客戶端消耗數據的速度比接收數據的速度快。
  • 舉例：一小時的高畫質影片（假設 2 Mbps）會消耗約 1 GB 的流量，這對儲存和傳輸都是巨大的挑戰。

適應性策略：多版本製作

現實世界中，使用者的網路環境差異極大（有人用光纖，有人用 4G 網路等等）。

為了不讓低頻寬使用者無法觀看，也不讓高頻寬使用者忍受低畫質，內容提供者會採用以下策略：

  • 預先處理：將同一部影片壓縮成多個不同品質的版本。
  • 分級範例：
    • 300 kbps（適合手機/3G）
    • 1 Mbps（適合一般寬頻）
    • 3 Mbps（適合高速網路）
  • 使用者選擇：使用者（或客戶端軟體）根據當前的可用頻寬，選擇最適合的版本進行觀看。

更具體的例子是到 youtube 看影片的時候，你可以自己選擇要 1080p 還是 720p，或者是切到自動模式。

2.6.2 HTTP Streaming and DASH（HTTP 串流與 DASH）

該節探討如何利用現有的 Web 基礎設施（HTTP 伺服器）來傳送視訊，重點從早期的「單一版本傳輸」演進到現代的「動態適應性傳輸」。

這一個演進的過程解決以下問題：

  • 頻寬異質性（Heterogeneity）：使用者的網路速度差異極大（有人用光纖，有人用 4G 的手機等等）。
  • 頻寬波動（Fluctuation）：同一個使用者的網速會隨時間變化（例如拿著手機移動）。

而傳統方法是給所有人都傳送同樣畫質的影片，這會導致網速慢的人看不了（一直轉圈圈），網速快的人畫質卻不夠好。

解決方案：DASH（Dynamic Adaptive Streaming over HTTP，HTTP 上的動態自適應串流）。

DASH 使讓客戶端（Client）可根據當下的網速，動態選擇最適合的畫質片段來下載。

術語解析

同樣地，繼續下去之前先來個術語解析：

  1. HTTP 串流（HTTP Streaming）：最基礎的實作方式。
    • 視訊只是一個放在 HTTP 伺服器上的普通檔案（有特定的 URL）。
    • 客戶端建立 TCP 連線，發送 GET 請求，伺服器就盡可能快地發送資料。
    • 客戶端一邊接收、一邊緩衝、一邊播放。
  2. DASH（Dynamic Adaptive Streaming over HTTP，HTTP 上的動態自適應串流）：現代串流媒體的標準。
    • 它不把影片看作一個大檔案，而是切成無數個小片段，並提供多種畫質選擇。
  3. 清單檔案（Manifest File）：像是影片的「菜單」。
    • 它列出了影片有哪些版本（解析度、位元率）、每個版本的 URL 是什麼。
    • 客戶端必須先下載這個檔案，才知道如何選擇片段。
  4. 視訊片段（Chunks）：DASH 將影片切分成數秒鐘（例如 2 到 10 秒）長度的小檔案。

傳統 HTTP 串流

先從傳統的角度來看，此為 YouTube 早期使用的方式。

運作流程：

  1. 伺服器將影片作為一個普通檔案儲存。
  2. 客戶端要看影片，因此建立 TCP 連線。
  3. 接著客戶端對該 URL 發送 HTTP GET 請求。
  4. 伺服器盡全力發送資料。
  5. 客戶端將資料存入應用程式緩衝區。
  6. 當緩衝區累積到一定程度，開始播放。

缺點：

  • 一體適用：所有客戶端收到的是同樣位元率的影片。
  • 如果影片是 3 Mbps，網速只有 1 Mbps 的使用者會一直卡頓，而網速有 100 Mbps 的使用者則覺得畫質太差。

DASH 的運作機制

DASH 的設計機制是將決策權交給客戶端。

  1. 伺服端的工作：
    • 多版本製作：將同一部影片編碼成多種不同的位元率（例如：低畫質、中畫質、高畫質）。
    • 切片與索引：將這些版本切成時間長度相同的小片段（Chunks），並建立一個 Manifest File（清單檔案）來索引這些區塊的 URL。
  2. 客戶端的工作：主要做以下這四件事的迴圈。
    1. 取得清單：首先請求 Manifest File，了解有哪些版本可選。
    2. 測量網速：監測當前接收資料的速率。
    3. 決策演算法（Rate Determination Algorithm）：
      • 如果頻寬充裕，則請求高位元率的片段（Chunk）。
      • 如果頻寬變差，則請求低位元率的片段。
    4. 發送請求：使用 HTTP GET 請求下一個時間片段的特定版本。

傳統 HTTP 串流 vs DASH

比較項目傳統 HTTP 串流DASH
編碼版本單一版本多版本（Multi-version）
傳輸單位單一大檔案小段的片段（Chunks）
適應性無（被動接收）高（主動切換畫質）
決策者無（伺服器只負責送）客戶端（Client）
主要優點簡單使用者體驗佳、適應移動環境

2.6.3 Content Distribution Networks（內容傳遞網路）

如何將海量的數據（如 Netflix 影片、YouTube 內容等）傳送給全球分佈的百萬級使用者？

直觀但錯誤的解法：建立一個超級巨大的單一資料中心（Single Massive Data Center）。

為什麼行不通？主要有三個問題：

  1. 距離太遠：如果客戶端在地球另一端，封包要經過太多路由器，延遲太高，且中間任何一個環節出錯都會導致卡頓。
  2. 重複流量（Redundancy）：同一部熱門電影，如果由資料中心重複傳送幾百萬次經過同一條連結，會造成巨大的頻寬浪費和成本問題。
  3. 單點失效（Single Point of Failure）：資料中心一旦斷線或發生災難，全球服務就掛了。

正確解法：CDN（Content Distribution Networks，內容傳遞網路）。

不把雞蛋放在同一個籃子裡。與 DNS 一樣建立一個分佈式的伺服器網路，將內容複製並儲存在多個地點，讓使用者從「最近」或「路徑最好」的伺服器下載。

術語解析

  1. CDN（Content Distribution Network）：管理分佈在多個地理位置的伺服器群，儲存內容副本（如影片、圖片），並將使用者導向至最佳伺服器的一種系統。
    • CDN 可以是私有的 CDN（private CDN），即由內容提供商本身所擁有。
  2. 深度進入（Enter Deep）：一種 CDN 設計理念，由 Akamai 提出。主要是將伺服器群直接放進存取端 ISP（Access ISPs）的網路內部。
    • 特點：離使用者最近，效能最好，但維護成千上萬個分散的小節點非常困難。
  3. 帶回家（Bring Home）：另一種 CDN 設計理念，由 Limelight 及許多其他 CDN 公司共同提出。將較少數量（例如幾十個）的大型伺服器群放在重要的位置（如 IXP 網際網路交換點）。
    • 特點：離使用者稍遠，但維護和管理成本較低。
  4. DNS 轉址（DNS Redirection）：讓 CDN 運作的核心。利用 DNS 系統將使用者的請求「轉發」到 CDN 的伺服器，而不是原始內容提供者的伺服器。

CDN 的運作流程

假設有一家電影公司 NetCinema，它付錢請一家 CDN 公司 KingCDN 來幫忙傳送影片，接下來會有以下六個步驟：

  1. 使用者造訪 NetCinema 的網頁。
  2. 使用者點擊連結 http://video.netcinema.com/6Y7B23V 時，使用者的主機向本地 DNS 伺服器（Local DNS Server）查詢 video.netcinema.com 這個 IP 位址。
  3. 本地 DNS 伺服器將 DNS 查詢轉發給 NetCinema 官方 DNS 伺服器。
    • NetCinema 官方 DNS 伺服器不回傳 IP 位址。
    • 其官方 DNS 伺服器回傳 KingCDN 域中的主機名稱給本地 DNS 伺服器，主機名稱如：a1105.kingcdn.com。
  4. 此時 DNS 查詢進入 KingCDN 的專屬 DNS 基礎建設。
    • 本地 DNS 伺服器對 a1105.kingcdn.com 發送查詢（目前總共第二筆查詢）。
    • KingCDN 的 DNS 系統回傳 KingCDN 內容伺服器的 IP 位址給本地 DNS 伺服器。
  5. 本地 DNS 伺服器轉發內容服務 CDN 節點的 IP 位址給主機。
  6. 客戶端拿到 KingCDN 的伺服器 IP 位址，開始直接跟它建立 TCP 連線並對視訊做 HTTP GET 請求（使用 DASH 協定）。

上述步驟如下圖所述：

image

Image Source：Computer Networking: A Top-Down Approach (8th ed., p. 178, Figure 2.25)

叢集挑選策略（Cluster Selection Strategy）

CDN 的 DNS 伺服器如何決定要把哪個 IP 給使用者用？

策略原理優點缺點
地理位置最接近的叢集根據使用者的 IP 判斷地理位置，指派物理距離最近的伺服器。簡單。物理距離近不代表網路速度快（可能中間線路壅塞），有些使用者的本地 DNS 伺服器離自己很遠，會導致誤判。
即時測量（Real-time Measurements）CDN 伺服器定期向全球的本地 DNS 伺服器發送探測（如 ping 訊息或 DNS 查詢），測量延遲和丟包率。能反映當下真實的網路狀況，選擇最佳路徑。會產生額外流量，許多本地 DNS 伺服器會用防火牆阻擋探測，導致無法測量。

2.6.4 Case Studies: Netflix and YouTube（案例研究：Netflix 與 Youtube）

Netflix

Netflix 的架構非常獨特，它採用了一種混合雲（Hybrid Cloud）的策略，可將其拆解為「大腦」和「肌肉」兩部分來看。

  • 大腦：亞馬遜雲端服務（Amazon Cloud / AWS）
    • Netflix 並沒有建立自己的資料中心來處理所有事情，它將幾乎所有的運算邏輯都放在了 Amazon 的雲端上。
    • 功能：網站註冊、登入、計費、電影目錄瀏覽、推薦演算法等等，都在 AWS 上運行。
    • 內容攝取與處理（Ingestion & Processing）：
      • 當 Netflix 收到片商的電影母帶後，會上傳到 AWS。
      • AWS 上的機器會將電影轉碼成多種格式（適應電視、手機、電腦等裝置）和多種位元率（Bit Rate），以支援 DASH 技術。
  • 肌肉：私有 CDN（Private CDN）
    • 雖然大腦在 Amazon，但傳送影片流量需要極大的頻寬，這部分 Netflix 選擇自己動手，建立了私有 CDN，稱為 Netflix Open Connect。
    • 硬體部署：Netflix 研發了專用的伺服器機櫃（Server Racks），直接安裝在網際網路交換點（IXPs）甚至是住宅區 ISP 的機房內部。
    • 優勢：此為深度進入（Enter Deep），伺服器離使用者的家越近，影片傳輸就越快，畫質就越好。

Netflix 的關鍵策略：推送式快取（Push Caching）

  • 運作方式：
    • Netflix 不會等到有人想看某部電影才去下載（此為拉取式 Pull）。
    • 正好相反，Netflix 會在離峰時段預先將熱門電影推送到各地的 CDN 伺服器上儲存。
  • 為什麼這麼做？因為一部電影的熱度是可以預測的（今天剛上的大片，明天一定很多人看），這樣做可以有效利用半夜閒置的頻寬，避開網路塞車。

客戶端互動流程

當使用者在手機上點選播放一部電影時，背後會發生什麼事情？

  1. 請求：使用者的手機連上 AWS 上的 Netflix 伺服器。
  2. 決策：AWS 上的軟體判斷哪個 CDN 伺服器有這部片，且離使用者最近、負載最低。
  3. 回應：AWS 直接回傳該 CDN 伺服器的 IP 以及清單檔案（Manifest File）。
  4. 播放：使用者的手機直接跟該 CDN 伺服器建立連線，利用 DASH 協定開始串流。

註：Netflix 不使用 DNS 轉址（DNS Redirection）來選擇伺服器，這是它與傳統 CDN 最大的不同。它依賴於應用層的軟體邏輯，直接告訴客戶端要去哪裡抓檔案。

YouTube

YouTube 的問題與 Netflix 略有不同。

Netflix 是少數精選內容（專業電影），YouTube 則是海量的使用者生成內容（UGC，User-Generated Content）。

基礎設施：Google 私有 CDN

YouTube 於 2006 年被 Google 收購，自然就使用了 Google 強大的基礎設施。

  • 部署：Google 同樣擁有龐大的私有 CDN，伺服器遍布全球的 IXP 和 ISP。
  • 私有網路：Google 擁有自己的全球骨幹網路，將這些資料中心連接起來，盡可能繞過公共網際網路的擁塞路徑。

策略：拉取式快取（Pull Caching）

  • 問題：因為 YouTube 影片數量太多（每分鐘有數百小時的影片上傳），不可能把所有影片都推送到所有伺服器。
  • 策略：若使用者請求的影片不在當地的 CDN 伺服器上，該伺服器會去別處（例如更大的資料中心）把影片拉取過來存著，同時播給使用者觀看。

客戶端互動流程

與 Netflix 不同，YouTube 採用了經典的 CDN 導流方式：

  • DNS 轉址（DNS Redirection）：
    • 當使用者請求影片時，Google 的 DNS 系統會介入。
    • 它會根據使用者的 IP 位置，以及伺服器負載，將網域名稱解析到一個最適合使用者的 CDN 伺服器 IP。
  • 串流協定：YouTube 早期主要使用標準的 HTTP 串流，現在也逐漸轉向類似 DASH 的自適應技術，但與 Netflix 的專有 DASH 實作有所不同。

Netflix vs Youtube

比較項目NetflixYoutube
雲端服務Amazon AWS（網站、邏輯、資料庫）Google Cloud
CDNNetflix Open Connect（私有 CDN）Google CDN（私有 CDN）
快取策略（Caching Strategy）推送式（Push Caching）：利用離峰時間預先派送熱門內容。拉取式（Pull Caching）：有人看才去抓。
伺服器選擇機制應用程式邏輯：AWS 直接告訴客戶端去連哪個 IP。DNS 轉址（DNS Redirection）：透過 DNS 解析給出最佳 IP。
串流技術DASH早期：HTTP 串流
後期：DASH
面臨的挑戰長時間的高畫質電影，需保證極高的觀看體驗。海量的短影片，需處理巨大的上傳量與儲存需求。

總整理

2.6.1 Internet Video（網際網路視訊）

  1. 視訊本質與挑戰
    • 本質：視訊為連續影像（Images）的序列，資料量極大。
    • 挑戰：在頻寬有限且波動的網路中，傳送高位元率資料並維持流暢。
    • 術語：
      • 位元率（Bit Rate）：傳輸所需資料量（100 kbps ~ 10 Mbps+）。
      • 壓縮（Compression）：權衡畫質與檔案大小（畫質 ∝\propto 位元率）。
      • 端對端吞吐量（End-to-End Throughput）：從伺服器到客戶端這條路徑上，網路實際能傳送資料的速率。
  2. 傳輸黃金法則
    • 為了避免卡頓 (Buffering)，必須滿足：$$\text{平均端對端吞吐量} \ge \text{視訊壓縮位元率}$$
  3. 適應性策略（多版本製作）
    • 針對不同使用者的頻寬差異，伺服器將影片預處理為多個版本：
      • 低畫質（如 300 kbps）→\to 適合 4G/手機。
      • 高畫質（如 3 Mbps） →\to 適合光纖/寬頻。
      • 機制：由使用者或客戶端軟體依當前頻寬選擇合適版本。

2.6.2 HTTP Streaming and DASH

  1. 傳統 HTTP 串流（早期 YouTube）
    • 運作：透過 TCP 連線發送 HTTP GET，伺服器盡全力發送，客戶端緩衝後播放。
    • 缺點：一體適用。無法適應網速變化，導致慢速者卡頓、快速者畫質受限。
  2. DASH（Dynamic Adaptive Streaming over HTTP）
    • 現代標準，將決策權交給客戶端 (Client)。
    • 伺服器端：
      • 多版本：影片轉碼為多種位元率。
      • 視訊片段（Chunks）：切成數秒的小片段。
      • 清單檔案（Manifest File）：索引各版本 URL 的「菜單」。
    • 客戶端端（迴圈）：
      1. 下載清單檔案。
      2. 測量當前網速。
      3. 決策演算法：網速快抓高品質片段，網速慢抓低品質片段。
      4. 發送 HTTP GET 請求。
  3. 比較：傳統 vs. DASH：
比較項目傳統 HTTP 串流DASH
編碼版本單一版本多版本（Multi-version）
傳輸單位單一大檔案小段的片段（Chunks）
適應性無（被動接收）高（主動切換畫質）
決策者無（伺服器只負責送）客戶端（Client）
主要優點簡單使用者體驗佳、適應移動環境

2.6.3 Content Distribution Networks（CDN）

CDN 用於解決如何將海量內容傳送給全球使用者的問題。

  1. 架構演進
    • 單一巨型資料中心（錯誤解法）：有距離過遠（高延遲）、重複流量浪費、單點失效風險。
    • CDN（正確解法）：分散式網路，將內容複製儲存於多地。
      • 深度進入（Enter Deep）：伺服器進駐 ISP 內部（離使用者近，難維護）。
      • 帶回家（Bring Home）：伺服器建在 IXP 關鍵節點（離使用者稍遠，易維護）。
  2. 運作核心：DNS 轉址（DNS Redirection）
    • 使用者不直接連源伺服器，而是透過 DNS 導流至 CDN。
    • 流程簡述：
      1. 使用者訪問影片連結。
      2. 本地 DNS 查詢源站（如 NetCinema），源站 DNS 回傳 CDN 域名（如 KingCDN）。
      3. 本地 DNS 查詢 CDN 域名，CDN DNS 系統依策略回傳最佳 CDN 節點 IP。
      4. 使用者直接向該 IP 請求影片（DASH）。
  3. 節點挑選策略
    • 地理位置：依 IP 判斷距離。優點簡單，但可能誤判網路壅塞狀況。
    • 即時測量：CDN 定期探測延遲。優點精準，但有額外流量且易被防火牆阻擋。

2.6.4 Case Studies: Netflix vs. YouTube

  1. Netflix（混合雲架構）
    • 大腦（AWS）：處理邏輯、註冊、推薦、轉碼。
    • 肌肉（Private CDN - Open Connect）：負責傳送影片流量，伺服器架設在 ISP/IXP。
    • 關鍵策略：
      • 推送式快取（Push Caching）：離峰時段預先將熱門片推送到 CDN（因為熱度可預測）。
      • 應用層導流：不靠 DNS，由 AWS 運算後直接告訴客戶端去連哪個 IP。
  2. YouTube（Google 基礎設施）
    • 架構：Google 私有 CDN 與全球骨幹網路。
    • 關鍵策略：
      • 拉取式快取（Pull Caching）：影片量太大（UGC），無法全推，有人看的影片且本地沒有時，才去後端拉取。
      • DNS 導流：傳統 CDN 方式，透過 DNS 解析指派 IP。
比較項目NetflixYoutube
雲端服務Amazon AWS（網站、邏輯、資料庫）Google Cloud
CDNNetflix Open Connect（私有 CDN）Google CDN（私有 CDN）
快取策略（Caching Strategy）推送式（Push Caching）：利用離峰時間預先派送熱門內容。拉取式（Pull Caching）：有人看才去抓。
伺服器選擇機制應用程式邏輯：AWS 直接告訴客戶端去連哪個 IP。DNS 轉址（DNS Redirection）：透過 DNS 解析給出最佳 IP。
串流技術DASH早期：HTTP 串流
後期：DASH
面臨的挑戰長時間的高畫質電影，需保證極高的觀看體驗。海量的短影片，需處理巨大的上傳量與儲存需求。