Home 技術文章 藉助更快的CDN實現低延遲實時流傳輸
Applications

藉助更快的CDN實現低延遲實時流傳輸

About The Author

Outline

現場體育是令人興奮的觀看. 特別是在關鍵時刻,例如當一次射門出局贏得比賽. 對於負責提供流暢,實時操作的技術團隊來說,這些時刻也會令人興奮。 直播體育直播必須平衡多個技術考慮和權衡,平均比現場直播遊戲落後30秒左右。 爲什麼要延遲?

雖然 內容交付網路 是必不可少的,但它們無法減少影片工作流其他部分造成的延遲。 例如,當圖像轉換爲信號時,從攝取時刻開始添加延遲。 原始信號必須轉換成壓縮格式並傳輸到影片處理中心,通常是在非現場,通常是在雲中,這可能會受到可用帶寬和基礎設施的影響。 接下來是對各種設備和帶寬的內容進行轉碼和打包。 最後,當流播放時,廣告可能會在流通過網際網路的最後一英里移動到觀衆設備之前動態插入流中。 在此處,播放器將緩衝解碼,解壓縮並渲染最終影片段。 這在團隊贏得比賽的目標和內容交付網路之間有很多步驟。 他們可以加起來,特別是當它必須同時發生在數百萬觀衆的情況下。 超級碗直播流的延遲,例如平均 28到47秒

減少延遲 已成爲流式服務提供商的焦點。 對於與秒數的遊戲投注(如賽馬)相關的體育賽事,延遲流向會讓遠距離的參與者處於不利的地位。 現場觀衆和新聞報道員的現場推文會破壞球迷在電視上觀看和直播影片的精彩時刻。 隨着越來越多的觀衆在觀看直播體育節目時使用第二個顯示器,減少直播時間已成爲保持競爭力和提供出色觀看體驗的重要要求。

減少延遲是我們在Edgecast (現爲Edgio)的關注領域。 這項工作涉及研究和實施每個處理步驟以及交付直播流所涉及的其他因素的增量改進。 在這篇文章中,我們將瞭解縮短延遲的一個具體方面涉及到什麼問題——我們的內容交付網路如何處理日益流行的低延遲策略導致的請求量增加——即減少網段大小。

爲了縮短直播時間,流媒體服務提供商開始採用更短的HLS或DASH段持續時間。 這可以顯著減少延遲,但也有一些折衷,例如額外的開銷和更高的重新緩衝風險。 這些取捨是否值得完全取決於與其他QoE考量相比,延遲的優先級。 在某些情況下,如上文所述,低延遲是首要任務,而在其他情況下,當前延遲級別可能可以接受,以提供個性化廣告,4K編程或允許編輯實時內容。

段大小在延遲中的作用

流影片行業長期以來一直使用自適應比特率(ABR)技術,將流分解爲多個單獨的影片段或塊。 每個網段的持續時間或大小都相同,但以不同的視訊品質等級或比特率編碼,因此資料串流可以隨著新的網段要求而調整,以適應檢視者的可用頻寬。 Apple的HLS和MPEG-DASH兩種主要ABR協議都提供了用於調整分段大小的控件。

片段大小在延遲中起着重要作用,因爲播放器必須下載預設數量的片段,才能開始播放直播流。 這樣,客戶端影片播放器就可以緩衝足夠的影片,以確保在網路擁塞的情況下,影片播放平穩,而不會重新緩衝。 然而,這也使流從一開始就處於現實中。 通常,iOS設備和Web瀏覽器上的嵌入式影片播放器會在開始播放前緩衝三個影片段。 如果某個片段的長度爲4秒,且玩家必須先緩衝三個片段,然後才能開始播放,則客戶端已比現場時間晚12秒。 DASH協議允許清單文件指定需要緩衝的文件量,從而提供了一定的靈活性。 然而,許多DASH播放器和設備尚未實現此功能。

縮短生活時間

由於緩衝三段是事實上的標準,因此最常用的縮短實時時間的方法是縮小每段的大小或持續時間。 在下面的示例中,通過將分段大小從4秒減少到2秒,實時後的時間將縮減到僅6秒,這是四秒分段的一半。

較小的段可能會導致重新緩衝

當使用較小的分段大小時,影片工作流必須響應更快,才能提供無緩衝區的實時影片流體驗。 這是由兩個因素造成的:

首先,通過減小片段大小,存儲固定數量的片段的播放器現在存儲的影片更少。 由於較短的段大小意味着更多文件,影片工作流以及最重要的是,內容交付網路必須在給定的流持續時間內處理和交付兩倍於播放器的文件請求。 由於在網路擁塞期間播放器中的影片緩衝較少,因此擁塞可能導致重新緩衝的可能性較大。 玩家現在對擁塞更加敏感,即使在較小的擁塞事件中也如此。

其次,正如我們在最近一篇技術文章“優化CDN以進行實時流媒體”中所解釋的那樣,在直播體育中,觀衆在熱門活動開始或接近最後一分鐘時會出現激增的現象。 隨着文件請求數量的增加,CDN需要在相同的時間內容納更多文件請求。 此任務由自適應比特率參數指定的各種設備類型和連接速度複雜化。

爲了說明文件卷的增加,圖2顯示了以不同長度段提供的16秒影片段。 對於四秒段,只需四個文件即可交付16秒段。 但是,當我們移至兩秒段時,我們需要八個單獨的文件,這是需要通過CDN處理的文件的兩倍。

通過熱歸檔提高分段交付性能

我們創建了一項名爲”熱歸檔”的功能,以應對許多現場觀衆同時加入流媒體的所謂”快閃記憶體羣”現象。 此功能指的是快速複製流行的網段或”熱文件”到POP (線上狀態點)中的其他伺服器,以便在需求迅速增加時,將其快速交付給觀衆。

通過將負載分散到許多伺服器,熱歸檔可防止任何一臺伺服器在文件請求突然激增時被淹沒。 當伺服器過載(類似於拒絕服務攻擊)時,伺服器對文件請求的響應速度會很慢,可能導致客戶端播放器中的重新緩衝。 通過快速識別和複製熱文件,單臺伺服器過載的風險大大降低。 現在可以在不增加延遲的情況下滿足需求的突然變化。

圖3顯示熱歸檔(圖3.b)如何通過防止伺服器過載來提高性能。 如果沒有熱歸檔(圖3.a),網段的所有流量都會轉到伺服器1 (S1)。 隨着受衆要求高峯,額外的流量會流向S1,使其超過100個用戶的容量。 由於中一臺在高峯期爲200名觀衆提供服務,情況繼續惡化。 相反,熱歸檔(圖3.b)通過將文件複製到兩臺伺服器(S1加S2)並將文件請求重新路由到新可用的伺服器來處理這種額外負載。

更快的熱文件識別

我們最近通過將熱文件移至多個伺服器的時間縮短一秒來增強熱歸檔功能。 我們通過更改在彈出窗口中識別熱文件的方式來縮短反應時間。 我們使用中央處理程序來彙總檔案要求和位元組計數以進行分析。 以前,數據是從每臺伺服器上的Web伺服器進程中提取的。 儘管這一點很好,但我們發現,緩慢的Web伺服器可能會降低熱文件數據的聚合速度。 爲了解決此問題,伺服器現在每秒將其請求和位元組數寫入光碟。 因此,當中央進程提取數據時,由於數據已寫入固態磁碟,因此無需等待Web伺服器進程。 僅此更改就足以適應大多數實時事件的負載。

快速響應時間對於實時事件至關重要,如圖3.c所示,該圖提供了有關熱歸檔流程如何工作以招聘額外資源的洞察。 在圖3.c所示的示例中,當S1伺服器超過其100個用戶的容量時,文件在達到容量時會快速移至S2。 這使系統能夠迅速有效地容納所有200個用戶,並充分利用可用伺服器的全部容量。

在多個埠上進行熱歸檔

對於非常受歡迎的活動,例如職業足球季後賽或主要國際足球賽,交通流量的尖峯和浪湧可能非常重要。 要滿足這種需求,還需要更改文件段的複製方式,以增加伺服器容量。 以前,內容交付網路僅限於將網段複製到每臺伺服器的一個埠。 但現在,我們可以將文件複製到每臺伺服器中的多個埠。 這大大提高了每臺伺服器的吞吐量,因此每個POP都可以處理更多的請求,從而可以處理比以前更多的實時事件。

在我們的系統中,負載平衡由高速暫存陣列路由協議(CARP)哈希處理。 對於常規內容,我們的方法是跨多個伺服器複製文件,我們使用CARP哈希從每個伺服器中選擇一個埠。 我們這樣做是爲了防止將重複的請求發送到源伺服器,並限制進程間通信。

當文件變得足夠熱時,CARP開始爲每個伺服器選擇多個埠以支援更多請求。 這種方法適用於熱文件,因爲它們只是伺服器提供的唯一文件的一小部分。 打開的埠數取決於對熱文件的需求。 這種方法增加了每臺伺服器提供的數據卷以及處理這些請求的可用CPU功率量。

結論

隨着 流媒體 服務提供商減少影片段的大小以提供更低的延遲實時流,Edgio的平臺熱歸檔功能可幫助內容交付網路管理增加的影片文件請求,尤其是隨着流行體育賽事的觀衆人數的增加。