直播體育賽事令人興奮。 尤其是在關鍵時刻，例如在無處投籃的情況下，無法贏得比賽。 對於負責提供流暢，實時操作的技術團隊來說，這些時刻也會令人興奮。 直播體育直播必須平衡多項技術考量與權衡，平均落後於現場比賽約30秒。 為什麼要延遲？
儘管內容交付網路至關重要，但它們無法減少影片工作流其他部分造成的延遲。 例如，當影像轉換為訊號時，從擷取時開始，就會加上延遲。 然後，原始信號必須轉換為壓縮格式，並傳輸到影片處理中心，通常是在非現場，通常是在雲中，這會受到可用帶寬和基礎設施的影響。 接下來是針對各種設備和帶寬對內容進行代碼轉換和打包。 最後，在播放流媒體時，廣告可能會在流媒體通過Internet的最後一英里傳輸到觀眾的設備之前動態插入到流媒體中。 在此處，播放器緩衝區解碼，解壓縮和呈現最終的視頻片段。 在團隊贏得比賽的目標和內容交付網路之間，這是很多步驟。 它們可以加起來，尤其是當數百萬觀眾一次發生這種情況時。 例如，Super Bowl直播流中的延遲平均為28到47秒。
降低延遲已成為流媒體服務提供商的重點。 對於與兩秒內的賭注(如賽馬)相關的體育賽事，延遲流會使遠程參與者處於不利地位。 現場觀眾和新聞發布者的實時推文可能會破壞粉絲在電視和實時流媒體上觀看的精彩瞬間。 隨著越來越多的觀眾在觀看現場體育賽事的同時使用第二個顯示器，縮短現場觀看時間就不足為奇了，這將成為保持競爭力和提供出色觀看體驗的重要要求。
減少延遲是我們Edgecast (現在是Edgio)關注的一個領域。 這項工作涉及研究並實施每個處理步驟的漸進改進，以及交付直播流所涉及的其他因素。 在本篇文章中，我們將探討延遲縮短的一個具體方面，即我們的內容交付網絡如何處理日益流行的低延遲策略所導致的增加的請求量，即減小段大小。
為了縮短直播時間，流媒體服務提供商開始採用更短的HLS或DASH段持續時間。 這可以顯著減少延遲，但也會有一些折衷，例如額外開銷和增加重新緩衝的風險。 這些取捨是否值得完全取決於延遲相對於其他QoE考量的優先順序。 如上所述，在某些情況下，低延遲是首要考慮因素，而在另一些情況下，當前延遲級別可能可接受以提供個性化廣告，4K編程或允許編輯實時內容。
段大小在延遲中的作用
流影片行業長期以來一直使用自適應比特率(ABR)技術，將流分為多個單獨的影片段或片段。 每個片段都有相同的持續時間或大小，但以不同的視頻質量級別或比特率編碼，因此流可以在請求新片段時適應觀看者的可用帶寬。 Apple的HLS和MPEG-DASH這兩種主要的ABR協議都提供了調整分段大小的控件。
段大小在延遲方面起著重要作用，因為玩家必須先下載預設數量的段，然後才能開始播放直播流。 這樣做是為了讓客戶端影片播放器可以緩衝足夠的影片，以確保在網路擁塞時能夠平穩地播放影片，而無需重新緩衝。 但是，這也會從一開始就讓溪流落後。 通常，iOS設備和Web瀏攬器上的嵌入式影片播放器會在開始播放之前緩衝三個影片段。 如果某個區段長度為4秒，且玩家必須先緩衝三個區段才能開始播放，則客戶端已落後實況12秒。 DASH協議允許清單文件指定需要緩衝的文件量，從而提供了一定的靈活性。 但是，許多DASH玩家和設備尚未實現此功能。
縮短上線時間
由於緩衝三段是事實上的標準，因此縮短帶電時間的最常用技術是縮小每段的大小或持續時間。 在下麵的示例中，通過將段大小從4秒減少到2秒，實時延遲時間縮短到僅6秒，即為4秒段的一半。
較小的分段可能會導致重新緩衝
當使用較小的段大小時，影片工作流必須響應更快，才能提供無緩衝的實時影片流體驗。 這是由兩個因素造成的：
首先，通過減小段大小，存儲固定段數的播放器現在存儲的視頻較少。 由於較短的段大小意味著文件更多，因此您的影片工作流以及最重要的內容交付網路必須在給定的流媒體持續時間內處理和交付兩倍多的播放器文件請求。 由於網路擁塞期間播放器中的影片緩衝較少，因此擁塞更有可能導致重新緩衝。 現在，即使在較小的擁塞事件中，玩家也對擁塞更加敏感。
其次，正如我們在最近的一篇技術文章《優化直播流的CDN》中所解釋的那樣，在直播體育賽事中，當熱門賽事開始或接近比賽的最後一分鐘時，觀眾人數激增是很常見的。 隨著文件請求數量的增加，CDN需要在相同的時間內容納更多文件請求。 此任務因自適應比特率參數指定的各種設備類型和連接速度而復雜化。
為了說明文件量的增加，圖2顯示了以不同長度段交付的16秒影片段。 在4秒段的情況下，只需4個文件即可傳輸16秒段。 但是，當我們進入兩秒區段時，我們需要八個單獨的文件，即需要通過CDN處理的文件的兩倍。
通過熱歸檔提高分段交付性能
我們創建了一種叫做“熱歸檔”的功能，來處理許多現場觀眾同時加入流媒體的所謂“火爆人群”現象。 此功能是指將流行的部分或“熱文件”快速復制到PoP (入網點)中的其他伺服器，以便在需求迅速增加時可以迅速交付給觀眾。
通過將負載分散到多臺伺服器，熱歸檔功能可防止任何一臺伺服器因文件請求突然激增而不堪重負。 當伺服器過載(類似於拒絕服務攻擊)時，伺服器對文件請求的響應速度將會變慢，這可能導致客戶端播放器中的重新緩衝。 通過快速識別和復制熱文件，單臺伺服器超載的風險大大降低。 現在可以滿足需求的突然變化，而無需增加延遲。
圖3顯示熱文件(圖3)如何通過防止伺服器過載來提高性能。 如果沒有熱歸檔(圖3)，則一個段的所有流量都將轉至伺服器1 (S1)。 隨著觀眾需求的高峰，額外的流量會流向S1，使其超過100個用戶的容量。 這種情況繼續惡化，因爲在高峰期有200名觀眾，S1人。 相比之下，熱文件(圖3)通過將文件復制到兩臺伺服器(S1加S2)並將文件請求重新路由到新的可用伺服器來處理這一額外負載。
快速識別熱文件
我們最近通過將熱文件移動到多個伺服器的時間縮短一秒來增強了熱文件存檔功能。 我們通過更改在彈出窗口中識別熱文件的方式來縮短反應時間。 我們使用中央程序彙總檔案要求和位元組計數以進行分析。 以前，數據是從每臺伺服器上的Web伺服器進程中提取的。 儘管這樣做很好，但我們發現速度較慢的Web伺服器可能會減慢熱文件數據的聚合速度。 要解決此問題，伺服器現在每秒將其請求和位元組計數寫入磁碟。 因此，當中央進程提取數據時，它不必等待Web伺服器進程，因為數據已寫入固態磁碟。 僅此更改就足以應付大多數現場活動的負載。
快速反應時間對於直播活動至關重要，如圖3所示，它提供了有關熱存檔流程如何工作以招聘額外資源的深入資訊。 在圖3中所示的示例中，當S1伺服器超過100個用戶的容量時，文件將在容量達到時快速移至S2。 這使系統能夠迅速有效地容納所有200個用戶，並充分利用可用伺服器的全部容量。
在多個埠上進行熱歸檔
對於非常受歡迎的活動，例如職業足球季後賽或主要國際足球比賽，交通的尖峰和激增可能非常重要。 要滿足這種需求，還需要更改文件段的復制方式，以增加伺服器容量。 以前，內容交付網路僅限於將數據段復制到每臺伺服器的一個埠。 但現在，我們可以將文件復制到每臺伺服器的多個埠。 這大大提高了每臺伺服器的吞吐量，因此每個POP可以處理更多的請求，從而使實況事件比以前大得多。
在我們的系統中，負載平衡由高速緩存陣列路由協議(CARP)散列處理。 對於常規內容，我們的方法是在多個伺服器上復制文件，我們使用CARP散列從每個伺服器中選擇一個埠。 我們這樣做是為了防止重複的請求發送到源伺服器，並限制進程間通信。
當文件變得足夠熱時，CARP開始爲每臺服務器選擇多個端口以支持更多請求。 這種方法非常適用於熱文件，因爲熱文件只是服務器提供的唯一文件的一小部分。 打開的端口數取決於對熱文件的需求。 這種方法增加了每臺伺服器提供的數據量以及可用於處理這些請求的CPU功率。
結論
隨著流媒體服務提供商縮減影片段的大小以提供更低延遲的直播流，Edgio的平臺熱歸檔功能可幫助內容交付網路管理對影片文件的更多請求，特別是隨著熱門體育賽事的觀眾人數不斷增加。
