Home Blogs 使用重新傳輸比率測量中間值
Applications

使用重新傳輸比率測量中間值

About The Author

Outline

在營運大型全球網路時,確保通過公共網際網路通信的系統之間的良好連接和性能是確保良好用戶體驗的關鍵。 鑑於網際網路的複雜性和最大努力性,即使是最可靠的提供商的最完善的鏈接有時也會出現問題。

監控此類鏈路的策略有多種,包括 主動測量(可生成專門用於測量的流量)和 被動測量(可監控現有流量)。 在本文中,我們介紹了一種被動方法,它利用我們的 xTCP 套接字採樣系統被動地監視我們網路依賴的許多此類鏈路。

爲了充分利用xTCP的數據,我們進一步開發了處理此數據的方法,解決了與Internet監控相關的一些難題。 特別是,我們引入了一種稱爲”重新傳輸比率”的概念 ,它提供了內容交付網路(CDN)站點之間觀察到的重新傳輸的嚴重性的相對衡量標 準。 我們證明,超過特定級別的重新傳輸率對應於吞吐量的下降,直接影響用戶感知的性能,從而使其成爲網路自動化的良好基礎,使我們能夠解決網路性能下降的問題。

背景

CDN中的一個常見工作流涉及一個連線點(POP)向另一個連線點,以獲取某些內容,例如,將一部分內容提取到暫存。 這些交互通常是直接響應客戶端請求而進行的,這意味着下游請求可能正在等待此傳輸完成。 通常,請求本身可能相當小,按幾千位元組的順序。 響應的大小可能有很大的變化,從千位元組到許多兆位元組。

圖1:請求流發送少量(訂單KBS)請求,並接收可能較大的響應(可能爲兆位元組)。

爲了監控存在點之間連接的執行狀況,我們可以使用套接字監控工具xTCP來採樣邊緣伺服器上所有打開的套接字的當前狀態。 雖然這在面向客戶的套接字中提供了關鍵的可見性,但此套接字數據也使我們可以查看POPS之間的數據。

然而,衡量這些數據並非沒有幾個挑戰。 首先,xTCP提供了不同連接的時間點示例。 這意味着我們可能會在傳輸的許多不同點捕獲許多連接。 因此,我們所做的任何評估都必須考慮行爲的更廣泛分佈,而不是任何單一的價值觀。

接下來,我們需要確保監控正確的方向。 雖然生成請求的POP (上圖中的POP A)和接收請求並必須響應請求的POP (上圖中的POP B)都具有套接字資訊,但它們的非對稱工作負載意味着我們希望看到不同的行爲: 客戶端發送的大多數數據包將是控制數據包(初始請求,後續確認數據包),而伺服器發送的大多數數據包將是數據包,它們更可能包含有意義的數據量。

因此,如果路徑上存在擁塞或其他問題,則承載數據的數據包(因此佔用更多隊列空間)更有可能遇到數據包丟失和重新傳輸,例如由於繁忙的路由器上的隊列丟棄。 爲了證明這一點,我們考慮在10分鐘的時間內在請求和響應流中觀察到的數據包重新傳輸速率的分佈(計算爲總重新傳輸數據包的比率除以發送的數據段總數,減去重新傳輸)。

圖2:響應流量遇到更多的重新傳輸,可能是因爲它們的大小較大。

在這裏,我們看到客戶端請求套接字在這段時間內幾乎沒有重新傳輸。 另一方面,響應顯示近85%的套接字具有非零重傳,但是,我們注意到,對於絕大多數連接,重傳率遠低於1%。 毫不奇怪,我們在測試期間觀察到幾乎每對彈出信號都有類似的行爲,並且這些信號在非零重傳的情況下都會發生。 因此,我們將重點放在大量數據的應對流程上。 因爲我們關心的是爲原始請求POP提供服務,所以我們將這些請求稱爲”入站”流。

我們的最終挑戰來自於有關重新傳輸的一些一般複雜性,以及將其用作性能下降信號的困難。 實際上,重新傳輸可能會定期發生,而不指明特定問題,因爲它們只是反映了發送方的狀態和重新發送數據包的次數。 這些最終可能是其他複雜的協議行爲的結果,除了丟失(例如 尾部丟失探測)。 增加了複雜性,我們發現許多套接字從不觀察重新傳輸。 這意味着naïve摘要(例如,取中值)可能會導致對重新傳輸速率的非常保守的摘要,而偏移的摘要(例如第95或第99百分位數)可能會在很大程度上捕獲對一般人羣無害的行爲。

重新傳輸比率

爲了幫助簡化這些挑戰的影響,我們考慮了一個稱爲重傳率的複合指標。 Meta的HD比率旨在量化能夠流式傳輸高畫質影片的客戶端的比例,這項措施的啓發 是爲了描述出現不健康的重新傳輸級別的插座的比例。 由於有時預期非零重傳,因此我們定義的重傳比率如下:

關鍵是,使用通過xTCP提供的數據來計算此值尤其容易。 在我們的營運經驗中,我們發現在正常鏈路上,重新傳輸比率的值通常很小,同時避免了原始重新傳輸速率測量中幾乎總是零的挑戰。

我們還發現該測量是敏感的,通常會在其他性能監視系統之前生成警報。 這使得它在快速診斷網路性能下降時特別有用,而網路性能下降通常從小問題開始,這些問題最終會級聯爲較大的問題。

驗證度量

爲了證明重新傳輸比率與應用性能直接相關,我們通過考慮兩個測量來證明其有效性。 首先,我們顯示,在高重新傳輸比率的時候,與低或零重新傳輸比率的時候相比,客戶端應用程式(請求者)的吞吐量更低。 其次,我們顯示高重傳率通常與其他網路信號(特別是POPS之間的ICMP探測器)的降解相對應。

爲了探索對應用程式性能的影響,我們將從應用程式層顯式進行測量。 我們特別考慮在客戶端Pop上測得的流量,因爲這些流量代表了在數據發送過程中實現的功能交付率。 爲了瞭解重新傳輸事件的影響,我們在一週內對一對POP進行了以下研究,在此期間,出現了一個顯著的提供者問題。

首先,我們考慮發生重新傳輸事件的所有期間 。 我們將重新傳輸事件定義爲一對POPS之間的重新傳輸比率位於特定範圍內至少連續十分鐘的任何時間段。 雖然我們注意到這不包括短期事件,但它提供了對較長期事件行爲的深入見解。 對於每個重新傳輸事件,我們將在事件期間收集相應的吞吐量值。 作爲一項控制措施,我們會在與事件相同的時間內收集數據,但在三小時前。 這爲我們提供了兩組吞吐量測量:”在重新傳輸事件期間”和”正常”,在無重新傳輸時進行。 然後,通過正常時間內在POPS之間實現的中位吞吐量來標準化“期間”測量。 對於我們的閾值,我們考慮四個範圍:大於0但小於25%,大於25但小於50%,大於50但小於75%,最後大於75%。

圖3:在每次重新傳輸事件中觀察到的與非重新傳輸週期相比的相對吞吐量。

上圖顯示了測量期間觀察到的相對流量的分佈。 首先,我們看到,即使在最低範圍內,60%的交易的吞吐量也低於中位數。 當我們考慮到更高的重新傳輸率時,吞吐量會繼續下降,而更高的重新傳輸率對應於更低的吞吐量,最壞的情況是導致相對中位值下降超過一個數量級。 這些測量結果表明,重新傳輸比率成功地捕獲了受影響流量的不良性能。

接下來,我們將探討這些事件與我們在POPS之間的活動ICMP測量值之間的關聯。 在這裏,我們考慮我們的一些主動監測的行爲,它在POPS之間定期執行ICMP探測,以衡量是否有任何丟失或延遲模式的變化。 對於此分析,我們再次使用從吞吐量比較中提取的事件。 但是,這次我們看一下每個閾值的時間段的ICMP測量損失,在這種情況下,正常情況下沒有損失。 我們注意到,ICMP探測的侷限性會導致這些特定測量的損失粒度達到2%。

圖4:每個時間段內觀察到的ICMP丟失。 較高的重新傳輸率對應較大的損耗。

在這裏,我們看到較低的閾值很少顯示任何損失,90%的測量結果沒有檢測到任何損失。 相反,在0.75閾值時,80%的測量值觀察到了損耗,並觀察到相對較高的中位損耗4%。 重要的是,我們注意到重新傳輸比率與顯著的吞吐量影響(例如0.25)相對應的水平,因此ICMP指標幾乎不會丟失。 這些研究結果重申了測量簡單ICMP探測器之外的路徑性能的重要性,並強調了重新傳輸比率能夠提供對Internet上實際流量性能的細緻視圖。

結論及其他方面

在這篇文章中,我們展示了重新傳輸比率的值,這是一個方便的總結指標,可以很容易地用xTCP套接字數據的可用數據來計算。 我們進一步表明,它提供了對應用程式性能受到影響的案例和網路干預的清晰洞察。

重新傳輸比率已成爲我們監控過程的關鍵部分,可清楚地瞭解系統性能,無需處理更大,更不易使用的應用程式日誌,也無需依賴ICMP探針,因爲這些探針無法捕捉到某些影響。

我們正在進行的工作正在探討如何使該指標儘可能敏感,以便對降解提供早期預警,同時爲更復雜的自動化系統提供適當的投入。

特別感謝架構和網路可靠性工程團隊對此工作的支援!

對於有興趣瞭解更多關於Edgio Labs & Advanced Projects的資訊,或有興趣探索上述任何主題的協作作品的研究人員,請通過research@edg.io與團隊聯繫