Computer Networking — 2.6 Video Streaming and Content Distribution Networks

contributed by <kaeteyaruyo>

tags: Computer Networking

預錄影片的串流流量現在已經佔據了北美的家用接取網路 ISP 絕大部分的頻寬。特別是 Netflix 和 YouTube，在 2015 年，這兩個服務各自就消耗了家用網路 ISP 37% 和 16% 的流量 [Sandvine 2015]。在本小節中，我們將會介紹現今網際網路上最受歡迎的影音串流服務是怎麼實作的。我們將會發現這些服務是由應用層協定所實作的，並且他們的伺服器是以某種快取機制在運作的。而第九章則會完全專注在介紹多媒體聯網，屆時我們將會更深入探討網際網影音與其他的多媒體服務。

2.6.1 Internet Video

在預錄影音串流應用程式中，它們所傳輸的媒體是預先錄好的影片，像是電影、電視節目、預錄的體育賽事，或是預錄的使用者生成影片 (user-generated video)（我們最常在 YouTube 上看到這類影片）。這些預錄好的影片被放在伺服器上，使用者隨時想看影片時就可以向伺服器發送請求要這些影片。現今已經有許多網際網路公司提供影片串流服務，包含 Netflix、YouTube (Google)、Amazon，還有優酷 (Youku)。

但是在我們認真開始討論影音串流之前，我們應該要先來好好認識一下被傳送的這個影音媒體本身到底是什麼。影片是由一連串的照片所組成的，一般來說會以固定的幀率進行播放，例如：每秒 24 或 30 張照片等等。一張無壓縮、數位編碼的圖片是由點陣 (pixel) 的陣列所組成的，而每一個點陣則又被編碼成數個位元，用來表達該點陣的亮度與顏色。影片有一個很重要的特性，那就是影片可以被壓縮，因此我們就可以在影片畫質與 位元速率（這裡我分不出來是傳輸的位元速率還是多媒體編碼的位元速率） 之間做取捨。現今存在的多種壓縮演算法幾乎已經可以把影片壓縮到任意的位元速率。當然，位元速率愈高，圖片的畫質就會愈好，因此整體的使用者觀看體驗也就會愈好。

從網路傳輸的角度來看，影音這個東西最令人在意的特徵應該就是他的高位元率。一般來說，壓縮過後的網際網路影音從 100 kbps 的低畫質影片到 3Mbps 的高畫質串流電影都有；4K 串流則設想了（現在應該已經是成真了）超過 10Mbps 的位元速率。這樣的高位元率會轉化為巨大的網路流量以及大量的儲存空間，尤其是那些高檔的影片更是如此。例如：單一個 2Mbps 位元率、長達 67 分鐘的影片，就會消耗掉 1 GB 的儲存空間與傳輸頻寬。截至目前為止，我們用來評估影音串流服務最重要的效能指標就是端到端的吞吐量。為了讓影片得以持續播放，網路必須要提供串流服務至少跟該影片的位元速率一樣高的平均吞吐量，才不會有卡頓發生。

我們也可以使用影片壓縮技術，來做出同一個影片的不同壓縮率的版本。例如：我們可以壓出同一個影片的 300 kbps、1 Mbps 和 3 Mbps 的三個版本，接著使用者就可以根據他們目前擁有多少網路頻寬，自行決定要看哪一個版本的影片。有高速網路可以用的使用者或許就會選擇 3 Mbps 的版本，而使用 3G 網路在手機上看影片的人可能就會選擇 300 kbps 的版本。（好有年代感的敘述www）

2.6.2 HTTP Streaming and DASH

在基於 HTTP 的串流服務中，影片單純就只是一個有特定 URL 的、被儲存在 HTTP 伺服器上的檔案。當使用者想要看影片時，客戶端會跟伺服器建立起一個 TCP 連線，並發送一個 HTTP GET 請求去要那個 URL 指向的檔案。接著伺服器就會回傳 HTTP 回應訊息，以當前網路狀態可允許的最大速度儘快把影片回傳給客戶端。在客戶端那邊，影片的每一個位元組都會被蒐集到客戶端應用程式的緩衝區裡面。一旦在緩衝區中的位元組數量超過了預先規定好的某個閾值，應用程式就會開始播放影片 —— 準確來說，一個影音串流應用程式會週期性地從使用者的應用程式緩衝區抓一些影格起來、把影格解壓縮，並把這些影格顯示到使用者的螢幕上。因此，影音串流應用程式是一邊播放影片，同時又一邊在接收和暫存這個影片更後面段落的影格的。

雖然在上文中所描述的這種 HTTP 串流系統已經被廣泛地實作並佈署了（例如： YouTube 一開始就是做這個起家的），它還是有一個很大的缺陷：儘管客戶端在可用頻寬上有著極大程度的多元性，所有的客戶端依然都會收到以同樣方式編碼的影片（無論是對於不同的使用者，或是對不同時刻的同一個使用者來說都是）。這個問題催生了一種新型態的基於 HTTP 的串流方式，我們通常稱之為基於 HTTP 的動態自適應串流 (Dynamic Adaptive Streaming over HTTP, DASH)。在 DASH 當中，一個影片會被編碼成多個不同的版本，每一個版本都有不同的位元率，也因此就對應到不同的畫質。客戶端可以動態要求數秒鐘長的影片片段（的資料塊）。當可用的頻寬很高時，客戶端自然而然會選擇畫質最好的版本；而當可用頻寬很低時，客戶端也自然而然會選擇畫質較低的版本。客戶端會以 HTTP GET 請求，一次請求一個影片段落的資料塊 [Akhshabi 2011]。

DASH 允許擁有不同網際網路存取速率的客戶端以不同的編碼速率 (encoding rate) 來觀看串流影片。使用低速的 3G 連線的使用者可以收到低位元率（因此是低畫質）的版本，而使用光纖上網的使用者則可以收到高畫質的版本。DASH 同時也允許客戶端可以依端到端的連線狀況調整到適合當前可用頻寬的播放速率，即便在同一個 session 內可用頻寬有所改變也沒關係。這個特色對於使用行動裝置的使用者來說是至關重要的，因為這些人的可用頻寬會隨著他們在不同基地台之間移動時有所浮動。

在 DASH 的架構下，每一個影片的不同版本都被儲存在 HTTP 伺服器當中，並且有著不同的 URL。而 HTTP 伺服器也會有一個清單檔案 (manifest file)，檔案中會載明每一個影片版本的 URL 和它所對應的位元率。客戶端一開始必須先請求這個清單，以得知這個影片的不同版本相關的資訊。客戶端接著再以 HTTP GET 請求，在請求中選擇特定的 URL 和位元範圍 (byte range)（為什麼是範圍），去一個一個下載影片的資料塊。在下載影片資料塊時，客戶端也會去測量當前的頻寬，並執行一個決定位元率的演算法，來選擇下一次要要求哪一個版本的資料塊。很自然地，如果客戶端當前已經緩衝了很長一部份的影片，而且頻寬也很高時，它就會選擇高位元率的版本。而當客戶端目前存放在緩衝區的影片只剩一點點，而且頻寬也很低時，它就會選擇低位元率的版本。DASH 藉此允許客戶端自由在不同畫質之間做選擇。

2.6.3 Content Distribution Networks

現今，許多網際網路影片公司每天都需要傳送 (distributing) 隨選隨播、數 Mbps 的串流影片給上百萬的使用者。以 YouTube 為例，這間公司的資料庫中存有上億個影片，而且他們每天都需要將這上億個影片串流給在世界各地的使用者看。要將這些網路流量傳遞到世界各地，同時還得提供持續性的放送和高度的互動性，這很顯然是一個非常具有挑戰性的任務。

對於網際網路影片公司來說，提供影片串流服務最直覺性的作法應該就是建造單一一個超大型的資料中心，把所有的影片都放進資料中心裡面，並且直接從這個資料中心將影片串流到世界各地的使用者手上。但這個作法有三個大問題：第一，如果客戶端距離資料中心很遠的話，從伺服器出發到客戶端的封包將會跨越非常多條傳輸鍊路，並且很可能會經過很多個 ISP，而當中某些 ISP 還可能分散在不同的洲。只要這中間有任何一條傳輸鍊路提供的吞吐量低於客戶端所需的播放速率 (comsumption rate)，那整體的端到端吞吐量也就跟著會低於客戶端所需的播放速率，這會導致使用者收看影片時，會有很煩人的斷斷續續的現象（你可以回顧第一章的內容，我們當時有提到一個串流的端到端吞吐量是由當中的瓶頸線路的吞吐量所決定的）。這種事情發生的機率會隨著端到端傳輸中所經過的線路數量增加而增加。第二個問題是，熱門影片可能會在同一個傳輸鍊上被重複傳遞好多次。這不僅浪費了網路頻寬，網際網路影片公司也會因此需要支付他的網路服務供應商（直接接到他資料中心的那一間）大筆費用，只為了一直重複傳輸相同的資料位元到網路上。第三個問題，單一個資料中心就意味著會有單點故障的問題 —— 如果今天資料中心或是他要接到網際網路上的那條線路壞掉了，那麼它就無法傳輸任何影片出去了。

為了要解決這些在傳輸大量影片資料給分散在世界各地的使用者時會遇到的大問題，幾乎所有在做影片串流的大公司都選擇了利用內容傳遞網路 (Content Distribution Networks, CDNs) 來傳遞影片。在 CDN 中，伺服器們是在地理位置上四散於各處的，影片（還有其他各種類型的 Web 內容，像是文件、圖片和音訊等）的複本 (copy) 會被存放在這些伺服器中，而這個系統會試著將使用者的請求導向到可以提供最佳使用者體驗的 CDN 所在地。一個 CDN 可以是一個私人 CDN (private CDN)，也就是只由 CDN 提供者所擁有的網路，例如：Google 的 CDN 就被用來傳送 YouTube 影片和其他類型的內容。但 CDN 也可以是一個第三方 CDN (third-party CDN)，以代理其他多個內容提供者的形式來傳遞內容，例如：Akamai、Limelight 和 Level-3 這幾間公司都有提供第三方 CDN 的服務。關於現代 CDN 系統，有幾篇非常值得一讀的文獻 [Leighton 2009; Nygren 2010]。

一般來說，CDN 系統在選擇擺放伺服器的地理位置時，通常會遵循下列兩個原則的其中一種 [Huang 2008]：

• Enter Deep: 由 Akamai 首創的第一個原則，就是要透過把伺服器叢集 (cluster) 佈署到世界各地的存取網路供應商當中，以深入 (enter deep) ISP 的存取網路中（關於存取網路，我們在 1.3 節有提過）。Akamai 採取了這個方法，在世界各地約 1,700 個地點佈署了伺服器叢集。這個作法的目標是要儘可能讓伺服器接近使用者，藉此降低使用者到傳送訊息的伺服器中間可能經過的鍊路和路由器的數量，以改進使用者所體驗到的延遲和吞吐量。因為這個設計具有高度的分散性，要維護和管理這樣的系統是非常具有挑戰性的。
• Bring Home: 第二種設計原則，被 Limelight 和許多其他的 CDN 公司給採用，則是透過在少數幾個（例如：十個）站點內建造較大規模的伺服器叢集，來把 ISP 帶回家 (bring the ISPs home)。在這種作法中，CDN 並非把伺服器放進 ISP 存取網路中，反而通常是把他們放在網際網路交換中心 (Internet Exchange Points, IXP)（請參考 1.3 節）裡面。相較於深入 ISP 的作法，這種把 ISP 帶回家的設計通常會有較低的維護和管理成本，但代價就是會對終端使用者造成較高的延遲以及較低的吞吐量。

一旦伺服器叢集的位置選定了，CDN 就會開始將他們要提供的內容一一複製到每一個叢集當中。CDN 可能不會想要把每一個影片的複本都放到每一個叢集中，因為有些影片可能比較少被觀看，或是只在特定地區流行。事實上，許多 CDN 並非主動上傳影片到他們的伺服器叢集當中，反而是採用一種很簡單的請求策略：如果客戶端從一個沒有儲存該影片的叢集中請求了一個影片，那麼該叢集就會去（向中央資料庫或是其他叢集）索取該影片，並在把影片串流給客戶端的同時儲存一份該影片的複本在自己的本機中。跟 Web caching 的機制類似（請參見 2.2.5），當一個叢集的儲存空間已經滿了，他就會把比較沒有人求的影片給移除掉。

Google's Network Infrastructure

為了要提供五花八門的雲端服務（包含搜尋引擎、Gmail、日曆、YouTube 影片、地圖、共編文件，以及社群網站），Google 佈署了非常廣泛的 (extensive) 私人網路和 CDN 基礎建設。Google 的 CDN 基礎建設分成3個等級的伺服器叢集：

• 14 個「巨型資料中心 (mega data center)」，其中有 8 個在北美、4 個在歐洲，還有 2 個在亞洲 [Google Locations 2016]，每一個資料中心擁有的伺服器數量都在數十萬等級。這些巨型資料中心負責提供動態內容（通常是個人化的內容），像是搜尋結果還有 Gmail 訊息。
• 大約 50 個叢集散佈在世界各地的 IXP 當中，每一個叢集是由大約 100-500 台伺服器所組成的 [Adhikari 2011a]。這些叢集負責提供靜態內容，包含 YouTube 影片等 [Adhikari 2011a]。
• 數百個 "enter-deep" 叢集，坐落在存取網路的 ISP 當中，這類叢集通常是由大約幾十台放在同一個架子上的 (within a single rack) 伺服器所組成的。這些 enter-deep 伺服器負責進行 TCP 負載分割 (TCP splitting)（參見 3.7 節）以及提供靜態內容 [Chen 2011]，像是網頁的靜態部份的內容。

這些資料中心和伺服器叢集都由 Google 的私人網路串聯起來。當一個使用者下了一個搜尋時，這個搜尋通常會先透過區域 ISP 送到附近的 enter-deep 快取，在這裡可以取得靜態的網頁內容；附近的快取在提供靜態內容給客戶端時，他同時也會把這個請求再透過 Google 的私人網路轉發到其中一個巨型資料中心，去取得個人化的內容。至於 YouTube 影片的話，影片檔案本身可能會來自某一個 bring-home 快取，但是除了影片之外的網頁內容可能是從附近的 enter-deep 快取來的，而頁面中的廣告則可能是從資料中心來的。總結來說，除了區域 ISP 的部份，Google 的雲端服務有很大一部份是由獨立於公共網際網路的私人網路基礎建設來提供的。

CDN Operation

現在我們已經知道了佈署 CDN 的兩種最主要的方法，我們可以接著來認識 CDN 運作的原理原則了。當使用者的瀏覽器（透過某個 URL）請求要下載某個特定的影片時，CDN 必須要把這個請求給攔截下來，如此一來它才能 (1) 決定當下要用哪一個伺服器叢集來服務這個客戶端最合適，(2) 把該客戶端的請求重新導向到位於該叢集內的某一台伺服器。我們會簡短的說明 CDN 是怎麼決定哪一個叢集最合適的。但在這之前，我們先來看看這個攔截並重新導向請求的機制是怎麼做到的。

大多數的 CDN 都會利用 DNS 系統來攔截並轉發使用者的請求；關於這樣利用 DNS 的作法有一篇有趣的討論在 [Vixie 2009]。讓我們來假設一個簡單的範例，來描述一般來說 DNS 是怎麼牽涉其中的。假設有一個內容供應商叫作 NetCinema，他僱用了一間第三方 CDN 公司，叫作 KingCDN，來幫助他傳遞影片給使用者。在 NetCinema 的網頁上，每一個影片都會被指定一個 URL，該 URL 會包含 "video" 這個字串和一個獨一無二的識別符，例如：《變形金剛 7》被指定的 URL 可能會是 http://video.netcinema.com/6Y7B23V 之類的。接著會進行以下六個步驟，如 Figure 2.25 所示：

Figure 2.25 DNS 服務將使用者的請求導向給 CDN 伺服器

1. 使用者造訪了 NetCinema 的網頁
2. 當使用者點擊了 http://video.netcinema.com/6Y7B23V 的超連結後，使用者的主機會送出一個 DNS 請求去詢問 video.netcinema.com 的 IP 位址
3. 使用者的本地 DNS 伺服器 (Local DNS Server, LDNS) 會將該請求轉發到負責 NetCinema 的權威域名伺服器去，這台伺服器會發現請求的網址內有 "video" 這個字串。為了將這個 DNS 請求「轉交」給 KingCDN，NetCinema 的權威域名伺服器會回傳一個在 KingCDN 的網域底下的主機名稱回去給 LDNS（例如：a1105.kingcdn.com），而非回傳一個 IP 位址
4. 從這一步開始，該 DNS 請求就進入了 KingCDN 私人的 DNS 基礎建設中了。接著使用者的 LDNS 會送出第二個請求給 a1105.kingcdn.com，而 KingCDN 的 DNS 系統最終將會回傳一個 KingCDN 的內容伺服器的 IP 位址給 LDNS。也因此，藉由 KingCDN 的 DNS 系統，使用者才會從 CDN 伺服器得到他所指定的內容
5. LDNS 將提供檔案的 CDN 節點的 IP 位址轉發給使用者的主機
6. 一旦使用者收到了 KingCDN 的內容伺服器的 IP 位址，他就可以透過該位址跟該伺服器建立起一個直通的 TCP 連線，並且發送一個 HTTP GET 請求要求下載該影片。如果有使用 DASH，則該伺服器首先會給送給客戶端一個列有許多 URL 的 manifest 檔案，每一個 URL 都代表影片的某一個版本，客戶端那邊就會自動從這些版本當中選擇最恰當的一個來下載資料塊

Cluster Selection Strategies

任何 CDN 佈署的核心都在於他的叢集挑選策略 (cluster selection strategy)，也就是關於如何在一個 CDN 系統內動態地將客戶端的請求導向到一個伺服器叢集或是資料中心的機制。就如同我們剛剛所見，CDN 系統會從客戶端送出的 DNS 請求當中得知客戶端的 LDNS 伺服器的 IP 位址。在得知這個 IP 位址後，CDN 系統必須要根據這個 IP 位址選擇一個恰當的伺服器叢集來服務它。一般來說，CDN 系統所使用的叢集挑選策略都是企業專有的。以下我們來簡單看看幾種策略，每一種都有它的優點和缺點。

一種簡單的策略是將使用者的請求指定送給在地理位置上離它最近的叢集。利用一些商用資料庫（像是 Quova [Quova 2016] 和 MaxMind [MaxMind 2016] 等），每一個 LDNS 的 IP 位址都可以對應到一個實體的地理位置。每當 CDN 系統從特定的 LDNS 那裡收到一個 DNS 請求時，他選擇的叢集都會是地理位置上距離該 LDNS 最近的，也就是直線距離上距離該 LDNS 公里數最少的那一個。這樣的作法對於大部分的客戶端來說都可以得到不錯的效果 [Agarwal 2009]。然而，對於某些客戶端來說，這樣的作法會讓他們有相當糟糕的使用者體驗，因為有時候地理位置上最近的叢集或許並不是在網路連線上經過最少個節點或最短的路徑就能抵達的叢集。再來，任何基於 DNS 系統實作的方法都會有一個與生俱來的問題，那就是有些終端使用者被設定成會使用位於遠處的 LDNS [Shaikh 2001; Mao 2002]，在這種情況下，使用者的 LDNS 或許會在地理位置上距離它非常遠。更糟的是，這個簡單的策略無視了路徑上的延遲和可用頻寬隨著時間的變化，永遠都會指定同樣的叢集來服務特定的客戶端。

為了根據當前的網路狀況選擇最佳的叢集來服務客戶端，CDN 系統可以改為定期在客戶端和他們的叢集之間執行網路延遲和掉包率的即時測量 (real-time measurement)。例如：一個 CDN 可以讓他的每一個叢集都定期送出一個探測訊息 (probe)（像是 ping 訊息或是 DNS 請求）給世界上的每一個 LDNS。但這個作法也有一個缺點，那就是許多的 LDNS 被設定成不會回應這類的探測訊息。

2.6.4 Case Studies: Netflix, YouTube, and Kankan

作為本節的總結，我們來看看三個極度成功的大規模影音串流服務實例：Netflix, YouTube 和 Kankan。我們將會觀察到這些系統分別採用了差異相當大的實作方法，但卻也都應用了在本節當中所提到的幾個底層原則。

Netflix

在 2015 年間，Netflix 總共佔據了北美的存取網路 ISP 約 37% 的下載流量，無非是美國的線上電影和電視劇服務供應商的龍頭 [Sandvine 2015]。接下來我們將會提到，Netflix 的影片傳遞服務包含了兩大元件：Amazon cloud 和 Netflix 自己的 CDN 基礎建設。

Netflix 有一個網站負責提供數量眾多的功能，包含使用者註冊和登入、計費、用來搜尋和瀏覽的影片目錄，以及影片推薦系統。如同 Figure 2.26 所示，這個網站（還有其相關的後端資料庫）完全是運作在 Amazon cloud 的 Amazon 伺服器上的。除此之外，Amazon cloud 還負責提供以下幾個關鍵性的功能：

Figure 2.26 Netflix 影片串流平台

• 內容攝取 (Content ingestion)：在 Netflix 得以將影片傳送給使用者之前，他必須先把影片傳入資料中心並將其處理好才行。Netflix 會從影片工作室那裡得到影片的主要版本，並將這些影片上傳到 Amazon cloud 上的主機裡面。
• 內容處理 (Content processing)：在 Amazon cloud 當中的電腦會給每個影片產生出各種不同格式的版本，以便對應相當多元的客戶端播放軟體，這些軟體可能分別跑在桌機上、智慧型手機上，或是接到電視的遊戲主機上。影片會有對應不同格式的各種版本，還有各種位元率的版本，如此一來就能使用 DASH 達成運作在 HTTP 之上的自適性串流。
• 上傳各種版本到 CDN 系統中 (Uploading versions to its CDN)：一旦影片的所有版本都已經準備好了，Amazon cloud 裡的主機就會把所有的版本都放到他的 CDN 裡面。

在 2007 年當時 Netflix 剛推出他的影音串流服務時，他們僱用了三間第三方 CDN 公司來協助他們傳遞影片內容。但在 Netflix 建立了自己的私有 CDN 之後，現在所有的影片都是由他們自己來傳送了（不過 Netflix 還是繼續採用 Akamai 來幫他們傳遞網頁內容就是了）。為了建立自己的 CDN， Netflix 在 IXP 和家用網路 ISP 的機房安裝了他們自己的伺服器機櫃。Netflix 現在在超過 50 個 IXP 站點設置了自己的伺服器機櫃，你可以在 [Netflix Open Connect 2016] 當中找到目前有擺放 Netflix 的機器的 IXP 站點列表。另外也有上百間的 ISP 機房放有 Netflix 的伺服器機櫃，同樣可以參見 [Netflix Open Connect 2016]，在這裡面 Netflix 也有提供他們潛在的 ISP 伙伴如何免費在他們的機房安裝 Netflix 伺服器機櫃的說明步驟。在機櫃上的每一台伺服器都有數個 10Gpbs 的乙太網路埠口和超過 100 TB 的儲存空間。每個機櫃上放有幾台伺服器不一定：安裝在 IXP 裡面的機櫃通常會有數十台伺服器，並且會存放完整的 Netflix 影片資料庫，包含可以支援 DASH 的各種版本；而區域型 IXP 可能就只會有一台伺服器，並且可能只會存放最熱門的那些影片而已。Netflix 並沒有使用 pull-caching 機制（參見 2.2.5 節）來新增資料到他們在 IXP 或是 ISP 當中的 CDN 伺服器上。相反地，Netflix 會在離峰時段自行把影片上傳到他們的 CDN 伺服器。對於那些無法存放完整資料庫內容的 CDN， Netflix 就只會上傳最熱門的那些影片，而熱門影片是會每天都更新一次的。在 YouTube 上有一些影片詳細介紹了 Netflix 的 CDN 系統的設計細節，請參見 [Netflix Video 1] 和 [Netflix Video 2]。

在看過 Netflix 所使用的架構當中出現的各個元件後，我們現在來進一步看看在影片傳輸的過程當中，客戶端和各個不同的伺服器之間是怎麼進行互動的。就像我們先前提到的，讓使用者可以瀏覽影片目錄的網頁本身是透過 Amazon cloud 上的機器來提供的。每當使用者選擇了一個影片來播放，跑在 Amazon cloud 上的 Netflix 的軟體，首先會先找出有哪些 CDN 伺服器是持有使用者所選的那支影片的。在所有持有那支影片的伺服器當中，軟體會再挑一個「最適合」服務使用者的伺服器來回應請求。如果使用者正在使用的網路是由裝有 Netflix 伺服器機櫃的存取網路 ISP 所供應的，而且該機櫃上的機器也同時持有使用者所選的影片的複本的話，那通常就會選擇在這台機櫃上的某一台伺服器來負責處理請求。若沒有，則通常就會選擇鄰近的 IXP 來處理請求。

一旦 Netflix 的軟體決定好要用哪一台 CDN 伺服器來傳遞內容了，他就會把那一台伺服器的 IP 位址回傳給客戶端，並且附上一個列有該影片所有版本的 URL 的 manifest 檔案。接著客戶端就會直接和 CDN 伺服器進行互動，並且使用專有軟體版本的 DASH。具體來說，就如同我們在 2.6.2 中所描述的一樣，客戶端會在 HTTP GET 請求訊息中使用 byte-range 標頭，從影片的各個版本當中下載資料塊。Netflix 使用的資料塊大小大概是 4 秒鐘長的影片 [Adhikari 2012]。每當客戶端正在下載一個資料塊時，他同時會去測量資料接收的吞吐量，並執行決定位元率的演算法，來選擇下一次要下載的資料塊的畫質。

Netflix 體現了我們在本節中所探討的多個關鍵性原則，包含自適性串流和 CDN 內容傳遞等。然而，由於 Netflix 使用的是他們自己的私人 CDN，這個系統只會用來傳遞影片（而不傳遞網頁），因此 Netflix 才得以簡化並量身打造他們的 CDN 設計架構。具體來說，Netflix 不需要使用到 DNS 重導向來讓特定客戶端可以連線到 CDN 伺服器，就像我們在第 2.6.3 節中提到的一樣；Netflix（跑在 Amazon cloud 上的）軟體反而是直接告訴客戶端去使用特定的 CDN 伺服器。此外，Netflix 的 CDN 是使用 push caching 而不是 pull caching（參見 2.2.5 節）：影片內容是固定在離峰時段被上傳到伺服器裡面去的，而不是動態地在 cache miss 的時候取得的。

YouTube

作為一個平均每分鐘會有 300 小時的影片被上傳、每天都有數十億的影片觀看數的影音平台， YouTube 無疑是世界上最大的影音分享網站 [YouTube 2016]。YouTube 在 2005 年 4 月開始了他的服務，並在 2006 年 11 月被 Google 收購。雖然 Google/YouTube 的平台設計和通訊協定是專有軟體，但透過幾個獨立的測量工作，我們還是可以大致了解 YouTube 基本上是怎麼運作的 [Zink 2009; Torres 2011; Adhikari 2011a]。就跟 Netflix 一樣，YouTube 廣泛地使用了 CDN 技術來傳遞影音內容 [Torres 2011]。跟 Netflix 相似的是，Google 也使用了私人的 CDN 來傳遞 YouTube 影片，也在上百個不同的 IXP 和 ISP 地點安裝了自己的伺服器機櫃。Google 從這些地方，也直接從他們巨大的資料中心，將 YouTube 影片傳送出去 [Adhikari 2011a]。但跟 Netflix 不一樣的是，Google 使用的是像我們在 2.2.5 節中所描述的 pull caching，以及我們在 2.6.3 節提到的 DNS 重導向機制。大多時候，Google 的叢集選擇策略都會把使用者導向到跟他之間來回通訊延遲 (RTT) 最短的那個叢集去；但為了要平衡叢集之間的負載，有時候使用者也會被導向去更遠的叢集 [Torres 2011]。

YouTube 使用的是 HTTP 串流，通常每一個影片都會有幾個不同位元率的版本，對應到不同的畫質。YouTube 並沒有實作自適性串流（像是 DASH），而是讓使用者自行選擇想要觀看的畫質版本。為了節省在重新定位 （repositioning，應該是指在看影片的時候拉動進度條到任意時間點的行為）或是提前結束影片時可能被浪費掉的頻寬或是伺服器資源，YouTube 利用了 HTTP 的 byte range 請求，在已經事先載入一定份量的目標影片的情況下，限制資料傳輸流 （的數量？）。

每天都有上百萬個影片被上傳到 YouTube。YouTube 不只透過 HTTP 把影片串流到客戶端，當影片上傳者要把影片從客戶端傳到伺服器時，也是走 HTTP 的。YouTube 會處理每一個他收到的影片、把他轉換成 YouTube 影片的格式，並產生多個不同位元率的版本。這整個過程都是在 Google 的資料中心當中進行的（請參見在 2.6.3 節中我們所提到的 Google 網路基礎建設的按例探討）。

KanKan

在剛才的例子中，我們觀察到運作在私有 CDN 當中的專用伺服器是如何傳遞 Netflix 和 YouTube 影片給客戶端的了。Netflix 和 YouTube 不僅要付出伺服器的硬體成本，還得要支付這些伺服器在傳遞影音時所使用的頻寬費用。以這裡兩個服務的規模以及他們所耗費的頻寬來說，佈署這種等級的 CDN 系統想必是相當花錢的。

作為本節的結尾，我們來看一個跟前兩個平台使用了完全不同的策略的大規模網際網路隨選影音供應系統 —— 這個策略可以大幅節省服務供應商在基礎建設和頻寬上的開銷。就跟你猜的一樣，這個設計使用了對等式架構，而不是（或是說只是作為輔助使用了）主從式架構來傳遞影片。自 2011 年起，迅雷看看（由迅雷擁有並維護）所佈署的 P2P 影音傳遞平台已經取得了巨大的成功，每個月都有數千萬的使用者上線 [Zhang 2015]。

整體來說，P2P 影音串流和 BitTorrent 檔案下載系統是非常相似的。每當有一個 peer 想要觀看某個影片時，他就要先跟 tracker 溝通，以找出系統中有哪些其他的 peer 手上有自己想看的影片。接著這個想看影片的 peer 會平行化地同時跟所有其他有影片檔案的 peer 發出請求，要求下載影片的資料塊。但跟使用 BitTorrent 下載檔案不一樣的地方在於，那些即將要被播放的影片片段的資料塊會優先被請求，如此才能確保影片可以流暢地播放。

近期，迅雷看看已經被移植到一個 CDN-P2P 混成的串流系統當中了 [Zhang 2015]。準確來說，迅雷看看已經在中國佈署了幾百台的伺服器，並把影片內容上傳到這些伺服器當中。這些看看的 CDN 在影片串流的初期扮演著重要的角色。在大多數情況下，客戶端會從 CDN 伺服器當中取得影片內容的最一開始的片段，同時平行化地去跟其他 peer 要求影片內容。當完整的 P2P 流量是足以支援影片的播放時，客戶端就會停止向 CDN 下載影片，只會使用繼續從其他 peer 接收影片串流。但如果 P2P 串流的流量不夠用了，此時客戶端就會重啟通往 CDN 的連線並回到 CDN-P2P 混成串流的模式。如此一來，看看就能確保影片初期能以較小的延遲來播放，但又能最小化地依賴非常花錢的基礎建設和伺服器頻寬。

---

<< 2.5 Peer-to-Peer File Distribution | 目錄 | 2.7 Socket Programming: Creating Network Applications >>