Home 技術文章 大型CDN的BBR評估
Applications

About The Author

Outline

瓶頸帶寬和往返傳播時間(BBR)是一種TCP擁塞控制算法,由於它能夠提供許多內容提供商所報告的更高吞吐量,因此已引起市場的顯著關注。 在這篇文章中,我們在Verizon Media (現爲Edgio)的內容交付網路(CDN)工作負載的背景下評估BBR (版本1),該工作負載可提供大量(多Tbps)的軟體更新和流影片,並量化對流量的益處和影響。 我們希望在大型CDN進行此類評估將幫助其他內容提供商爲其流量選擇正確的擁塞控制協議。

背景

許多內容提供商和學術研究人員發現,BBR提供的吞吐量比其他協議(如TCP立方)更大。 與基於丟失的擁塞控制算法(如無處不在的TCP立方)不同,BBR有一個不同的操作模式:它根據會話迄今爲止所見到的最小RTT持續更新可在飛行中的數據量,以避免緩衝膨脹。 有關BBR操作的更多資訊,請點擊此處查看Google的原始出版物

測量和分析

爲了瞭解BBR在CDN上的潛力,我們在多個階段評估BBR,測量從幾個存在點(POPS)對TCP流量的影響。 POPS表示位於大城市區域的高速暫存伺服器集中。 最初,我們在Pop中進行了小規模BBR測試,並進行了完整的Pop測試,所有流向執行BBR的客戶端。 爲了確定客戶端將獲得的好處,我們在測試期間從內部代理Web伺服器日誌以及套接字級別分析中測量了吞吐量。

要評估的指標

我們的多租戶CDN可看到各種客戶端流量。 許多客戶擁有大量的小對象,而其他客戶則擁有更大的多GB對象。 因此,確定能夠捕獲不同流量模式中實際性能提升的成功指標至關重要。 特別是,在此次評估中,我們將吞吐量和TCP流完成時間確定爲成功參數。 在圖1中,我們顯示了從CDN請求的常見對象大小與爲其提供服務所需時間的熱圖。 顏色漸變指示每個類別中的請求數。 這些是來自一小組伺服器的代表性編號,足以僅捕獲常見行爲。

1. 顯示常見對象大小的熱圖。

熱圖讓我們瞭解不同的請求模式。 一般而言,獲得更高的吞吐量是性能增益的最佳指標。 但是,作爲測量的吞吐量可能會非常嘈雜,尤其是在對象大小較小(小於幾MB)的情況下。 因此,根據對哪些尺寸提供最可靠的吞吐量評估的單獨評估,我們僅使用大於3MB的對象大小進行吞吐量評估。 對於小於3MB的對象,跟蹤流完成時間是更好的指標。

作爲評估的第一步,我們在洛杉磯的幾臺伺服器上啓用了BBR,並監視了所有TCP流的吞吐量和流完成時間。 以下結果檢查了一些Internet服務提供商特定的案例研究。

大型無線提供商

圖2顯示了打開BBR後的差異。

2. 與立方流(控制)相比,打開BBR (測試)時,大型無線提供商的客戶端的吞吐量影響。 剩餘:兩天內的吞吐量測量。 藍色垂直線表示BBR啟動的時間。 在這裏,我們看到BBR的整體改善約爲6-8%。 右:第5百分位數吞吐量的CDF。 BBR流程顯示出顯著改善。

對於這家無線提供商來說,只要我們啓用BBR,我們的吞吐量平均就提高了6-8%。 我們還看到TCP流量完成時間總體較短。 這一發現與Spotify,Dropbox和YouTube的其他報告一致,在無線網路中,數據包丟失很常見,但這並不一定是擁塞的指標。

大型有線提供商

接下來,我們檢查了大型有線提供商的性能。 我們還看到了吞吐量(對於大型對象)和流完成時間(如圖3所示)。 使用BBR進行改進。

3. 大型有線提供商完成流程所需的平均時間。 BBR (測試)流顯示的抖動較少,完成數據傳輸所需的時間較少。 對於較大的物體,其優點更具影響力。 但是,對於立方和BBR的大文件大小,我們看到類似的抖動。

從這些測試中報告的收益顯示了客戶端流量的非常有希望的結果。

由於這些收益是在一個聚合視圖上,我們決定深入研究一下,以檢查是否所有TCP流在Pop中都看到使用BBR的好處;或者是否有一些TCP流受到影響,以及哪些?

在CDN邊緣,我們執行四種不同類型的TCP會話:

  • 彈出到客戶端(如上所示)
  • 彈出至彈出(數據中心之間)
  • Pop內通信(在同一Pop的暫存之間)
  • 彈出到源站(彈出到客戶源站數據中心)

在這項研究中,我們考慮了彈出到客戶端,彈出和彈出內部流,因爲邊緣到源端的流量不像其他三種流那樣高。

彈出到彈出和流行內流量

評估對這些TCP流的影響也很重要,因爲在許多情況下,這些流是客戶端交付(如動態內容)的阻止程序。

對於流行和流行內流量吞吐量,我們看到性能出現了大的倒退。 圖4顯示了在同一時間段內對Pop內部和Pop到Pop通信的影響:

4. 與立方流(控制)相比,打開BBR (測試)時,POP內和Pop至Pop通信的吞吐量影響。 兩天內的吞吐量測量。 藍色垂直線表示BBR啟動的時間。 使用BBR,吞吐量減少了一半左右。

以前的調查結果沒有報告流向最終用戶和數據中心之間這種明顯的性能差異。 我們需要評估這些特定TCP流量爲何受到影響;如果這是CDN上硬體或配置的僞跡;如果是,則需要更改哪些調整。

通過使用Web伺服器訪問日誌和伺服器端套接字數據的評估進行進一步調查,發現在存在高RTT流和低RTT流的情況下,使用BBR會使RTT非常低的TCP流受到影響。 我們進一步評估了傳輸數據小於0.5KB的病例,發現在大多數病例中,BBR的表現與立方厘米相似。

根據這些發現,我們得出結論,對於我們的流量模式,最好使用立方塊進行即時通信和即時通信,因爲RTT和損耗較低。 對於客戶端流量,使用BBR是值得的。

完全彈出測試

爲了大規模評估BBR的性能優勢,我們在里約熱內盧的Pop測試中針對來自我們網路的所有面向客戶的流量執行了一次完整的Pop測試。 這一流行趨勢做了一個有趣的案例研究,因爲該地區的位置和對等限制導致客戶體驗的RTT中位數高於其他地區。

圖5 使用BBR改善客戶端的吞吐量,因爲這顯示高重傳(ASN1)。

我們部署了擁塞控制算法的更改並監控了性能。 圖示爲使用BBR觀察到的吞吐量的CDF,而對於Rio的前兩個ASE (自治系統)則爲立方。 如圖5所示,整體上,BBR的獲益,而另一個則沒有。

爲了調查其背後的原因,我們使用ss實用程序查找測試期間收集的其他TCP指標。 這兩個ASE的重新傳輸速率有明顯的區別。 即使對於RTT較高的ASE,BBR也只能在重傳次數較多的情況下表現良好,換句話說,對於損失較少的ASE,BBR沒有理由後退,性能優於BBR。 但是,必須注意的是,TCP立方的許多參數已在我們的CDN上經過精心調整。

接下來,我們研究了圖5所示ASN1的所有連接是否都顯示出吞吐量的改善。 圖6是BBR和立方連接對不同對象大小所花費的時間(較低意味着更高的吞吐量)圖。 在這裏,我們看到BBR只是開始顯示明顯的好處,較大的物體,按MBs的順序。 我們確實看到一個使用BBR的異常實例,但無法將其歸因於任何特定的擁塞控制協議相關問題。

圖6 對於表現出改進的ASE,BBR的優點在具有大型文件的長期執行流中可見。

爲什麼會發生這種情況?

這些結果有兩個維度:立方對BBR和BBR對BBR。

立方與BBR

BBR在估算瓶頸帶寬時對緩衝區大小和RTT具有高度的反應性。 對於較大的緩衝區(中間框可能會建立隊列),BBR的估計RTT會增加。 由於沒有數據包丟失,因此在這種情況下,立方不會回退,也就是說,即彈出式對彈出式流量,因此立方可實現更高的吞吐量。 對於小緩衝區(如無線客戶端),緩衝區快速填充並導致丟失,從而使立方流迴流,BBR流性能更好。

BBR與BBR

在這種情況下,當出現損失時,不會回退流。 但是,當兩個具有不同RTT的流競爭佔用一部分帶寬時,具有較高RTT的流也具有較大的最小RTT,因此具有較高的帶寬延遲產品。 因此,流量以比RTT較低的流量快得多的速度增加其機內數據。 這會導致將帶寬重新分配到RTT的降序流,而RTT較高的流填充緩衝區的速度比RTT較小的流快。

在實驗室環境中重現結果

爲了進一步瞭解流程之間的交互,我們在虛擬機中創建了一個測試環境,以捕獲我們在生產中看到的行爲。 我們確定了在邊緣伺服器上類比不同流量類別的方法,如下所示:

客戶端流量延遲設定爲~50ms,損失範圍從0.001到0.1,瓶頸帶寬爲50Mbps。 同樣,對於彈出至彈出,僅限損耗和延遲設定爲~15ms和0.0001~0.01。 對於Pop內流量,我們讓虛擬機最大化可用容量。 最後,我們使用各種對象大小執行類比,以捕獲我們的流量的多租戶性質。 我們同時執行所有三種流量模式和流量的指數到達,以捕獲Poisson式流量到達分佈。 圖7顯示測試牀設定。

此測試的目標是重現我們在生產測試中看到的問題,特別是針對流行內流量和流行間的小RTT流量的吞吐量下降。

7. 使用KVM,iperf,netem和tc實用程序進行實驗設定。

使用此設定,我們使用類比後臺流量(立方和BBR)以及完成流程所需的時間進行了數百次類比。 後臺流量的目標是類比生產環境。 許多現有的研究集中在執行幾個立方和BBR流,並評估他們的行爲。 雖然在這些情況下,瞭解每流行爲非常有用,但它很少代表大型,高容量CDN的複雜性。 我們使用客戶端流完成時間作爲可靠的指標,因爲對於小文件大小,吞吐量可能會很吵。

圖8. iperf流程所需的時間。 左:客戶端流。 右:彈出到彈出流。 對象大小:3MB。 對於類比客戶端流,BBR的性能優於立方。

我們也看到測試牀上的圖案重新出現。 在圖8中,我們展示了BBR和立方iperf流在兩種方案中所花費的時間的CDF:3MB (中等大小)文件的客戶端流量和彈出到彈出流量。 在低損耗高帶寬設定中,BBR流無法趕上立方塊。 客戶端流量(低帶寬)有所改善,即BBR流量佔用的時間較少。 但是,小文件的改進幅度不大。 在測試環境中重現這些行爲使我們確信它們是不同流類型之間交互的結果。 因此,在CDN上部署BBR時,必須瞭解BBR可能對多種流量類型的混合產生的更廣泛影響。

結論

從我們的評估中,我們發現BBR流在所有情況下都表現不佳。 具體而言,使用BBR時,數據中心/存在點(POP)內的流量和數據中心之間的流量(Pop-to-Pop)流量會受到影響。 在某些極端情況下,吞吐量減少了一半。 但是,我們發現,彈出到客戶端的流量吞吐量提高了6-8%。

在這篇文章中,我們概述了在CDN上下文中對BBR (版本1)的評估。 我們開始在一個Pop中對幾臺伺服器進行小測試,並評估了我們作爲大型內容提供商感興趣的不同變量。 在大規模的全彈出測試中,我們注意到BBR在重傳率高的ASes中會起到最大的幫助,並建議使用BBR來處理大文件是值得的。

我們從這裏走向何方?

如果我們在系統級別(所有流)啓用BBR,則會面臨Pop內部和Pop到Pop通信吞吐量下降的風險。

但是,BBR已顯示出潛力,並且對客戶端通信性能良好。 這確實促使我們有選擇地爲客戶端啓用BBR,可能從無線提供商開始。 此外,這些路徑具有淺緩衝區和無線丟失,這是BBR性能優於其他立方流的理想情況。

我們希望這一大綱能明確說明大型內容提供商使用BBR的情況及其對可能共享瓶頸的不同類型流量的影響。 BBRv2的alpha版本現已推出,它應該解決其中的一些問題。 我們計劃繼續評估更新版本的BBR,並使用智能傳輸控制器,爲正確的流量選擇正確的擁塞控制。 我們將在未來分享更多細節。

感謝組織內各團隊的貢獻,讓這項分析成爲可能!