在營運大型全球網路時，確保通過公共網際網路通信的系統之間的良好連接和性能是確保積極用戶體驗的關鍵。 鑑於網際網路的復雜性和盡最大努力，即使是最可靠的提供商上配置最完善的鍊路，也有時會出現問題。
監視此類鍊路的策略有多種，包括主動測量(專門生成流量以進行測量)和被動測量(監控現有流量)。 在本文中，我們介紹了一種被動方法，它利用我們的xTCP套接字採樣系統被動地監視我們的網絡所依賴的許多此類鏈路。
為了充分利用xTCP的數據，我們進一步開發了處理這些數據的方法，解決了與Internet監控相關的一些挑戰。 特別是，我們引入了一個稱爲“重新傳輸率”的概念，它提供了內容交付網絡(CDN)站點之間所觀察到的重新傳輸的嚴重性的相對衡量標準。 我們證明，高於特定級別的重新傳輸率對應於吞吐量的下降，直接影響用戶感知的性能，因此，它成為網路自動化的良好基礎，使我們能夠解決網路性能下降的問題。
背景
CDN中的常見工作流包括一個存在點(POP)向另一個點伸出來獲取某些內容，例如，提取要暫存的內容。 這些互動通常是直接回應客戶端請求，這意味著下游請求可能正在等待此轉接完成。 通常，請求本身可能相當小，以幾千字節的順序排列。 響應的大小可能變化很大，從千字節到數兆字節不等。
圖1：請求流程發送小(訂單KBS)請求，並接收可能大的回復(可能為兆位元組)。
為了監控入網點之間連接的執行狀況，我們可以使用套接字監控工具xTCP來取樣邊緣伺服器上所有開放式套接字的當前狀態。 雖然這提供了我們面向客戶的套接字的關鍵可見性，但此套接字數據也使我們能夠查看POP之間的數據。
然而，衡量這些數據並非沒有幾個挑戰。 首先，xTCP提供不同連接的時間點樣本。 這意味著我們可能會在許多不同的傳輸點捕獲許多連接。 因此，我們所做的任何評估都必須考慮行為的更廣泛分布，而不是任何單一價值觀。
接下來，我們需要確保我們正在監控正確的方向。 雖然生成請求的POP (上圖中的POP A)和接收請求並必須響應請求的POP (上圖中的POP B)都具有套接字資訊，但它們的非對稱工作負載意味著我們預期會看到不同的行為：客戶端發送的大多數數據包將是控制數據包(初始請求，後續確認數據包)，而伺服器發送的大多數數據包將是數據包，它們更可能包含有意義的數據包。
因此，如果路徑沿途出現擁塞或其它問題，則承載數據的數據包(因此占用了更多隊列空間)更有可能遇到數據包丟失和重新傳輸問題，例如，由於繁忙的路由器上的隊列丟棄而導致數據包丟失。 為了證明這一點，我們考慮了一對POP之間10分鐘內請求和響應流中的數據包重新傳輸速率分布(計算方式是重新傳輸的數據包總數除以發送的數據段總數減去重新傳輸的數據段總數的比率)。
圖2：響應流量遇到更多重傳，可能是因為它們的大小較大。
在這裡，我們看到客戶端請求套接字在這段時間內幾乎沒有重新傳輸。 另一方面，響應顯示近85％的套接字具有非零重傳，但我們注意到，對於絕大多數連接，重傳速率遠遠低於1%。 毫不奇怪，在測試期間，我們幾乎每對彈出信號都會出現類似的情況，而且會進行非零重傳。 因此，我們側重於數據滿載的應對流程。 由於我們關心的是向原始請求的POP提供請求服務，因此我們將這些稱為“入站”流程。
我們的最後一項挑戰是由於重傳的一些一般複雜性，以及將它們用作性能降低的信號的難度。 實際上，重新傳輸可能會定期發生，而不指示特定問題，因為它們只是反映發送方狀態和重新發送數據包的次數。 這些最終可能是丟失以外的其它復雜協議行為的結果(例如尾部丟失探測)。 我們發現許多套接字從不觀察重傳，這增加了複雜性。 這意味著naïve的摘要(例如，取中位值)可能會產生非常保守的重新傳輸速率摘要，而偏差的摘要(例如，95或99個百分位數)可能會在很大程度上捕獲對一般人群無害的行為。
重新傳輸比率
為了幫助簡化這些挑戰的影響，我們考慮使用一個稱為重新傳輸比率的複合度量。 Meta的HD Ratio旨在量化能夠流式傳輸高畫質影片的客戶端的比例，這項測量的靈感來自於Meta的HD Ratio，它試圖描述出現不正常重傳水平的插槽的比例。 由於有時需要非零重傳，因此我們將重傳比率定義如下：
重要的是，使用通過xTCP提供的數據來計算此值特別容易。 根據我們的操作經驗，我們發現在正常鍊路上，重新傳輸比率的值通常很小，同時避免了原始重新傳輸速率測量中出現的幾乎始終為零的挑戰。
我們還發現，測量結果很敏感，通常會在其他性能監視系統之前生成警報。 這使得它在快速診斷網路降級時尤其有用，因為網路降級通常從小問題開始，最終形成更大的問題。
正在驗證度量
為了證明重新傳輸率與應用程式性能直接相關，我們通過考慮兩項測量來證明其有效性。 首先，我們表明，在高重新傳輸率時，客戶端應用程序(請求者)的吞吐量比低或零重新傳輸率時低。 第二，我們表明高重新傳輸率通常與其他網路信號(特別是POP之間的ICMP探測器)中的降解相對應。
為了了解對應用程式性能的影響，我們轉向明確從應用程式層進行的測量。 我們特別考慮在客戶端POP測量的吞吐量，因為這些流量代表數據發送過程中實現的功能交付率。 為了了解重新傳輸事件的影響，我們在一週內對一對彈出式事件進行了以下研究，在此期間發生了重大的提供商問題。
首先，我們會考慮發生重新傳輸事件的所有期間。 我們將重新傳輸事件定義為一對POP之間的重新傳輸比率至少連續十分鐘處於特定範圍內的任何時間段。 雖然我們注意到這不包括短期事件，但它提供了對較長事件行為的洞察。 對於每個重新傳輸事件，我們隨後會在事件期間收集相應的吞吐量值。 作為一項控制，我們收集與事件相同持續時間但提前三小時的數據。 這給我們提供了兩組吞吐量測量：“重傳期間”事件和“正常”，在無重傳期間進行。 然後，我們將“期間”測量標準化爲正常時間POP之間的吞吐量中位數。 對於閾值，我們考慮四個範圍：大於0但小於25 %，大於25但小於50 %，大於50但小於75 %，最終大於75 %。
圖3：在每次重新傳輸事件期間觀察到的與非重新傳輸週期相比的相對吞吐量。
上圖顯示測量期間觀察到的相對流量分布。 首先，我們發現，即使在最低範圍內，60 %的交易的吞吐量也低於中間值。 當我們考慮較高的重新傳輸率時，吞吐量會繼續下降，而較高的重新傳輸率對應較低的吞吐量，最壞的情況會導致相對中間值下降超過一個數量級。 這些測量表明，重新傳輸率成功捕獲了受影響流量的不良性能。
接下來，我們來看看這些事件如何與POP之間的活動ICMP測量相關聯。 在此，我們考慮一些主動監視的行為，這些監視在POP之間執行定期ICMP探測，以測量延遲模式的任何丟失或變化。 對於此分析，我們再次使用從吞吐量比較中提取的事件。 但是，這次我們查看每個閾值的時間段內的ICMP測量損失，在這種情況下，正常情況下沒有觀察到損失。 我們注意到ICMP探測中的限制會導致這些特定測量的2％的損失粒度。
圖4：每個時間段內觀察到的ICMP丟失。 較高的重新傳輸率對應較大的損耗。
在這裡，我們可以看到較低的閾值很少顯示任何損失，90％的測量都無法檢測到任何損失。 相比之下，在80閾值時，75%的測量值觀察到損耗，並觀察到相對較高的中值損耗(4 %)。 重要的是，我們注意到，重新傳輸率與顯著的吞吐量影響(例如0.25)對應的級別會導致ICMP度量的丟失很少。 這些發現重申了測量路徑性能的重要性，而不僅僅是簡單的ICMP探測，還突出了重新傳輸率能夠提供對Internet上實際流量性能的細緻視圖。
結論和其他
在本篇文章中，我們展示了重新傳輸率的價值，這是一種方便的摘要度量，也可以用xTCP套接字數據中的數據輕鬆計算。 我們還進一步證明，它能夠清楚地了解應用程式性能受到影響以及網路乾預是必要的情況。
重新傳輸率已成為我們監控過程的關鍵部分，它提供了對系統性能的清晰洞察，而無需處理更大，更難處理的應用程式日誌，也無需依賴無法捕獲某些影響的ICMP探測。
我們正在進行的工作是探索如何盡可能提高該指標的敏感性，以便對降解提供早期預警，同時為更復雜的自動化系統提供合適的輸入。
特別感謝架構和網路可靠性工程團隊對這項工作的支援！
對於有興趣了解有關Edgio Labs和Advanced項目的更多資訊或有興趣探索上述任何主題的協作工作的研究人員，請通過research@edg.io與團隊聯繫。
