Home 技術文章 如何使用RTT指標來改善串流效能
Applications

如何使用RTT指標來改善串流效能

About The Author

Outline

高質量的影片流取決於數百萬件事情的正確執行,例如管理不斷波動的工作負載,或在大量觀衆同時進入流媒體時處理“快閃記憶體”。 這就是爲什麼在付費服務中提供可靠,高質量的影片流(觀衆期望像電視一樣的體驗)需要工具和指標來精確闡明性能挑戰,以便您知道解決問題的位置和方法。

CDN是視訊串流中不可或缺的解決方案,因爲它們能在全球提供低延遲可擴充性。 除了優化方式之外,CDN還能平衡現場直播時可能伴隨的混亂觀衆增長,爲最終用戶提供出色的性能需要額外的可視性,指標,工具和自動化層。

在這篇文章中,我們將回顧我們最近爲大型北美vMVPD流媒體服務進行的性能優化示例,包括:

  • 我們用於改善/修復性能問題的指標
  • 如何定義性能以及如何衡量性能
  • 我們持續進行優化以提高影片性能

自治系統編號:背後的複雜性

現代Web圍繞多個相互連接的網路層構建,稱爲ASN(自治系統編號),每個層由大量IP地址組成,加上CDN (內容交付網路),這些CDN通過在邊緣提供內容來減少擁塞。 從本質上講,如下所示,網際網路由一個網路組成,每個網路都有其獨特的業務模式和優先級。

資料來源:Research Gate

加上ASN彼此互動的固有複雜性,其範圍和規模都很大。 vizAS工具試圖按國家/地區顯示許多ASN之間的相互聯繫。 例如,僅在美國,網路之間就有16,979個ASN和24,905個對等關係。 全球有超過90,000個ASN。

https://stats.apnic.net/vizas/index.html

從我們作爲CDN提供商的角度來看,連接數千個ASN所涉及的複雜性由於需要滿足每個客戶的性能要求,使用情況,流量類型和許多其他因素而變得更加複雜。 例如,像Twitter這樣的服務將具有與推出重大更新的遊戲公司不同的使用配置文件或佔用空間。 同樣,廣播公司流媒體直播體育賽事的配置文件與按需流媒體服務不同。 即使是兩個實時流媒體服務也可能有不同的配置文件,每個服務都需要定製的性能優化。

在後臺,我們有大量的配置設定可供調整和調整,以幫助客戶實現其性能目標和要求。 對於某些人來說,性能可能是他們從開始時所期望的(或更好的),我們不需要改變任何東西。 其他人可能有特定的目標,例如更快的TTFB (第一位元組時間),這是流式傳輸服務的重要指標,需要解決。

鑑於網際網路的複雜性和規模,不可能通過”黑客攻擊”或散點攻擊方法來提供有用且一致的性能改進。 通過全面的數據收集和密集的數據分析來確定問題的根本原因,或主動深入瞭解將使客戶受益最大的網路配置更改,從而獲得真正的收益。

通過Stargazer提供RTT見解

確定網路延遲和整體性能執行狀況的最重要指標之一是RTT (往返時間)。 這是定義爲數據包從源傳輸到目標的持續時間,以及將響應發送回源的持續時間(以毫秒爲單位)。 它可用於診斷和改善多個向量之間的網路性能,包括擁塞,硬體問題,配置錯誤和路由問題。

鑑於此指標的重要性,我們構建了一個名爲Stargazer的內部系統,用於彙總來自各種來源的RTT數據,包括我們的傳感器,我們從客戶導入的數據以及同時監控RTT資訊的第三方。 Stargazer監視發送到客戶端的出站響應時間。 其他數據源包括路由器的BGP (邊界閘道器協議)表,路由器到地理位置的映射,客戶端連接的RTT日誌以及流量資訊。 此外,系統還可以在必要時執行主動探測,如跟蹤和ping。

在監控活動的背後,Stargazer與我們開發的其他工具一起,使我們能夠查詢我們收集的所有數據,並執行深入分析,爲持續改進打開大門。 我們的網路管理員可以使用此資訊來隔離問題,並確定網路路由或配置,以優化特定客戶目標和要求的性能。 此外,正如後面將討論的那樣,它也有助於瞭解新技術(如BBR (瓶頸帶寬和往返傳播時間)協議)對性能的影響。

優化原始伺服器

爲了更深入地瞭解性能優化在實踐中的工作原理,讓我們看看一個例子,其中涉及最近添加的現場影片流客戶,該客戶需要優化 多CDN架構。 在傳統的CDN客戶端架構中,客戶端向我們的一個POPS發出請求,彈出暫存從源站填充,如下所示。

但是,該客戶選擇利用多CDN架構來增加冗餘和恢復能力,並可能提高性能。 這是由我們的Origin Shield架構啓用的,如圖4所示。 Origin Shield可更好地控制如何路由各種客戶端的流量,以獲得最佳性能。

與傳統的CDN關係不同,所有流量(包括第二個CDN提供的流量)都會流回位於亞特蘭大的一個POPS (AGA),以進行高速暫存填充。 然後,AGA Popp充當源伺服器,或者更具體地說,它被稱爲源伺服器,從而減輕了客戶源伺服器的沉重負擔。 AGA Pop被選爲原始伺服器屏蔽位置,因爲其高速暫存命中率和性能比第二個CDN更高。 但是,一個主要的問題是優化兩個CDN之間的性能。

該過程的第一步是研究優化第二個CDN到AGA的路由,並將其作爲源站屏蔽。 一個立即明顯的問題是CDN之間的性能不佳以及大量的連接超時影響TTFB。 爲了深入瞭解性能問題,我們使用Stargazer將跟蹤路由從AGA發送到目標目的地,並捕獲用於每個躍點的ASN。

如下面的摘要所示,跟蹤路由從AGA發送到第二個CDN的IP地址,類比客戶端的路徑。

我們注意到ASN 7018中有幾個跳數,這不是首選的路由,因爲它涉及更多跳數和更多擁塞。 使用Stargazer,我們迅速確認了問題並進行了相應的網路更改。 如下面的traceroute摘要所示,在進行網路更改後,我們通過切換到ASN 7922減少了跳數並改進了RTT,後者也解決了TTFB超時問題。

在另一個示例中,我們使用Stargazer工具來確定通往位於東海岸的客戶原始伺服器的最佳原始伺服器路徑。 爲了有效地減少客戶原產地的負載並提高交貨性能,原產地屏蔽彈出應靠近原產地。 有時,它並不一定是最接近的物理流行。 它是最少的ASN,最少的擁塞量和低RTT時間的組合。 如下圖前後所示,Stargazer traceroute顯示,從紐約流行到DCC (華盛頓特區)流行將跳數減少到3個,從而使RTT性能得到整體改善。

使用掃地魚進行更深入的分析

我們的CDN在全球範圍內擁有7,000多個互連和超過300個POPS,因此仍有大量持續的優化工作。 爲了避免在可能沒有多大差別的任務上推波助瀾,我們需要一種高效的方法來優先安排營運團隊所採取的行動。 這種需要導致了Stargazer的配套工具的開發,稱爲Sweeper Fish ,它對存在問題的地方進行評分,並使我們能夠以優先的方式將問題泡上去。

Sweeper Fish也可用於確定路由是否堵塞以及是否可能引起問題。 回到多CDN示例,我們使用Sweeper Fish來發現哪些路由出現擁塞。 爲此,Sweeper Fish在通往AGA POP的所有路徑上測量了所有客戶端RUM (真實用戶測量)數據的第25至第75百分位數之間的差值,重點是第二個CDN通向我們的路徑ASN7922。 此ASN上所有流量的標準差如下所示。

我們還確認,通過ASN7018進行的先前配置並不適合。 Sweeper Fish分析顯示,由於此路由的擁塞,IQR (InterQuartile範圍)的峯值達到20-60至毫秒(見圖9)。 IQR也稱爲中間分佈或中間50%,提供了一種有用的方法來快速分析路由並標記問題。 IQR越低,越好。

相反,AGA POP在我們最後使用的路線ASN7922上一致介於10-22毫秒之間,如下所示。 通過比較不同的ASN,Sweeper Fish使我們能夠選擇最佳,最少擁擠的路由和/或確定需要補救的問題。

TCP調整

擁塞還會導致數據包丟失並重新傳輸。 這是在POPS之間的路徑遙遠且TCP算法未優化時發生的。 由於AGA是我們的例子的起源,到達AGA的遙遠的POPS有可能出現這一問題。 儘管分佈在許多POPS中,但下面彙總的CDN日誌使我們能夠識別方框所示的問題區域。

圖11. 聚合的伺服器日誌可快速識別數據包被丟棄和重新傳輸的問題區域。

評估BBR

瓶頸帶寬和往返傳播時間(BBR)是Google開發的替代TCP擁塞控制算法,已開始獲得一些牽引。 它與基於丟失的擁塞控制算法不同,如普遍存在的TCP立方,並引入了不同的操作模式。 它會根據會話迄今爲止所見到的最小RTT持續更新可執行的數據量,以避免緩衝區膨脹。

我們的分析發現BBR有助於提高RTT性能,但並不符合通用解決方案。 有時您想要使用它,有時您不想使用它。 Stargazer通過跟蹤RTT在一段時間內對目的地的一致性配置文件來幫助我們確定何時需要使用它。 這使我們能夠確定應用BBR的最佳位置,以幫助減少重新傳輸並改善流量控制。

根據下圖所示的分析,我們得出結論,轉換到BBR將略微提高AGA POP到第二個CDN和客戶來源的性能。 第一組圖形顯示從TCP立方向TCP BBR的更改會導致重新傳輸的減少,而第二組圖形則表示對BBR的更改會使平均吞吐量略有增加。

圖12. 在本例中,從TCP立方更改爲TCP BBR會導致重新傳輸減少

圖13. 在本例中,從AGA POP的TCP立方控制切換到BBR以減少重新傳輸,並略微提高平均吞吐量。

結論

網際網路是龐大而複雜的–它本質上是一個網路網路。 對於Edgecast (現爲Edgio)而言,如果沒有深入的分析來深入瞭解問題區域並測試可能的配置更改,針對客戶使用案例優化性能幾乎是不可能的。 爲了提高客戶的性能,我們開發了一套強大的工具來持續監控RTT,以便我們能夠快速高效地在整個網路中進行改進。 對於實時影片流服務,我們找到了一些方法來優化性能以滿足其獨特要求,同時還評估了BBR在其應用中的使用情況。 結果是一個 利用兩個CDN的高性能流式解決方案 。 我們還沒有完成。 隨着網路擁塞不斷加劇,我們將始終不斷優化我們的網路,以確保我們的客戶及其客戶擁有最佳的線上體驗。