使用xTCP進行大規模套接字性能監控

背景

CDN和雲提供商在網際網路上提供大量流量，並使用廣泛的監控工具來確保性能和可靠性。 這些工具包括涵蓋不同層流量傳輸的工具，例如網路，伺服器，應用程式等 TCP/IP佔這種流量的大部分(雖然基於UDP的QUIC在全球範圍內呈上升趨勢，但與TCP相比，它仍然只佔總流量的一小部分)。

套接字是連接用於傳輸數據的客戶端和伺服器連接的操作系統抽象。 因此，網路問題直接反映在每個套接字存儲的數據中。 例如，網路擁塞可能導致響應時間變慢，往返時間(RTT)增加。 網路帶寬也可能可用，但應用程式被太多請求淹沒，無法填充足夠的數據以充分利用可用帶寬，從而導致應用程式受限的異常。 伺服器通常同時處理多個插槽，這可能會導致資源爭用對CPU和記憶體等系統資源造成壓力。

因此，大規模監控TCP套接字的性能可以提供對流量行爲(例如響應速度慢或連接中斷)的關鍵理解，並確定可以改進的情況。

現有工具

Linux中的”ss”實用程序是用於獲取套接字統計資訊的常用工具。 與”netstat”類似，ss通過允許對套接字狀態，協議和地址進行篩選，提供了更快，更靈活的機制來獲取資訊。 我們也從ss開始了插座監控之旅。 雖然它是快速獲取套接字列表和相關度量的強大工具，但ss的主要挑戰是它可以消耗大量資源，特別是在具有大量套接字的系統上使用時。 這會影響系統性能並降低其他進程的速度。 此外，由於密鑰不一致，ss輸出並不適合分析，因爲密鑰的使用不一致，並且大大複雜了從數千臺伺服器流式傳輸收集的數據的能力。

我們使用ss的第一個套接字集合版本是在選定的高速暫存伺服器上執行的bash腳本，我們將”ss–tcp–info”的輸出導出到文件中。 然後，該文件將被rsync到堡壘主機，python腳本將從中讀取該文件，並將其解析並插入到ElasticSearch中。 這項工作已經完成，但遠遠沒有達到我們所需要的規模。 下一個重複的工作是在高速暫存伺服器上有一個python腳本，該腳本將從HTTP接口調用，並返回聚合的統計數據以插入ElasticSearch羣集。 這種方法將分析瓶頸從中央後臺位置擴展到單個暫存伺服器，但導致套接字數量顯著較高的伺服器上的記憶體利用率較高。 最終，我們認識到需要以輕質方式替換系統的ss部分。

我們對這一新工具的主要要求是，它應該是輕量級的，可以擴展到CDN伺服器擁有的大量套接字，並且能夠使用有效的機制(如協議緩衝區)將數據流回。 MeasurementLab的TCP-info 工具 是在Golang中實現的一個很好的實用程序。 但是，它設計用於隨時間推移跟蹤相同的套接字。 鑑於我們的插座連接量很大，我們選擇了不跟蹤單個插座的設計選擇。 相反，讓每個輪詢循環獨立，提供開放套接字當前狀態的快照。 這裏的主要目標是跟蹤系統的整體性能，而不是單個插槽。

xtcp

爲了解決這些挑戰,我們引入了 開源xTCP (提取，導出，Xray TCP )。 xTCP是一種用於大規模捕獲和流化套接字數據的Golang實用程序。 xTCP使用Netlink捕獲套接字資訊,將數據打包到protobufs中,並通過UDP埠發送出去(最終發送到Kafka等)或寫入 NSQ。

NetLink 爲用戶空間和內核空間之間的通信提供了通用接口。 套接字監控工具ss，tcp-info使用NetLink_iNet_DIAG (Netlink協議家族的一部分)將套接字資訊從內核獲取到用戶空間(手冊頁中的註釋：NetLink_iNet_DIAG是在Linux 2.6.14中引入的，僅支援AF_iNet和AF_inet6套接字。 在Linux 3.3中,它被重命名爲NetLink_sock_DIAG並擴展爲支援AF_UNIX套接字。

xTCP 以高速率提取內核TCP iNet_DIAG數據並通過protobufs導出該數據。 在~120k插槽的計算機上，Netlink消息約爲~5-6MB，但是ss的ASCII輸出約爲~60MB。 此外，ss在預設情況下以~3KB塊的形式從內核讀取數據。 xTCP讀取32KB塊，從而最小化系統調用。 xTCP使用多個工作人員同時讀取Netlink套接字數據，以儘可能快地排空隊列，併發分析Netlink消息以進行流式傳輸。 所有這些優化使xTCP在生產高速暫存伺服器上執行的佔用空間更小。

Edgio上的用途

我們大量使用xTCP數據來分析客戶端性能。 通常我們會跟蹤RTT並重新傳輸由存在點(POP)和ASN聚合的數據。