rperf

效能

rperf是 3D-P 開發的基於 Rust 的iperf替代品，旨在避免iperf3中發現的一些可靠性和一致性問題，同時提供更豐富的指標數據，重點是在丟失容忍、更像物聯網的環境中運行。雖然它可以用作iperf的近乎直接替代品，並且這樣做可能有好處，但它的重點是封閉網路中監控能力的定期資料收集，這意味著它不適合所有領域iperf可以提供服務。

發展

rperf是一個獨立的實現，引用iperf3和zapwireless的演算法來評估正確性並得出適當的更正，但不複製任何程式碼。

尤其是iperf3解決的最重要問題如下：

• 任何給定的伺服器都支援多個並發客戶端。

• rperf用於流抖動計算的 RFC 1889 實現首先假設序列中第一個和第二個資料包之間的增量以及序列中的間隙觸發計數重設。相較之下， iperf3從 0 開始，這會人為地創建低值，而在出現間隙時，它只是簡單地繼續，這會人為地創建高值。

• 重複資料包在 UDP 交換中被考慮，無序資料包被計算為獨立事件。

• 所有流量都可以按規則的亞秒間隔按比例發出，從而允許更準確地反映真實資料傳輸和發送演算法的配置。

  • 這解決了類似嵌入式系統中常見的情況，其中一台設備具有作業系統不知道的非常小的發送或接收緩衝區，並且在單次突發中接收大量資料時只會丟棄資料包，錯誤地少報了網路容量。

• 流配置和結果透過專用連接進行交換，並且每個資料路徑都具有明確定義的逾時、完成和失敗語義，因此當關鍵資料包遺失時，執行不會無限期地掛在測試的兩側。

• rperf的 JSON 輸出在結構上是合法的。沒有不帶引號的字串、重複的按鍵或懸空逗號，所有這些都需要在使用之前進行預處理，否則會導致意外錯誤。

與zapwireless相比，實現了以下改進：

• rperf使用經典的客戶端伺服器架構，因此無需在等待測試執行請求的裝置上維護正在執行的進程。

• 計算抖動。

• 支援 IPv6。

• 作為測試的一部分，多個流可以並行運行。

• 可以使用omit選項從結果中丟棄 TCP 加速時間。

• 輸出以 JSON 格式提供，以便更輕鬆地收集遙測資料。

平台

rperf應該在所有主要平台上建置和工作，儘管它的開發和使用重點是基於 Linux 的系統，因此這是它功能最完整的地方。

歡迎請求為其他系統實現等效功能。

用法

所有內容都在--help的輸出中概述，大多數熟悉類似工具的使用者應該會立即感到舒適。

rperf 的工作方式與iperf3非常相似，共享許多概念甚至命令列標誌。它的一個關鍵區別在於客戶端驅動所有配置過程，而伺服器只是盡其所能並提供結果流。這意味著伺服器不會直接透過其介面呈現測試結果，並且 TCP 和 UDP 測試可以針對相同實例運行，可能由許多客戶端同時運行。

在正常操作模式下，客戶端會將資料上傳到伺服器；當reverse標誌被設定時，客戶端將接收資料。

與iperf3不同， rperf預設不使用保留的連接埠範圍。這樣它就可以並行支援任意數量的客戶端，而不會在實際上只能是少量連續連接埠的情況下發生資源爭用。就其預期能力而言，這應該不是問題，但在涉及非寬鬆防火牆和 NAT 設定的情況下， --tcp[6]-port-pool和--udp[6]-port-pool選項可能會出現問題用於將非連續連接埠指派給將用於接收流量的連接埠集。

也沒有測試相對於固定資料量的吞吐量的概念。相反，唯一的重點是測量大致已知的時間段內的吞吐量。

同樣重要的是，如果伺服器在 IPv6 模式下運行並且其主機支援雙堆疊配置中的 IPv4 映射，則 IPv4 和 IPv6 用戶端都可以連接到相同實例。

大樓

rperf使用貨物。典型的過程很簡單： cargo build --release 。

Cargo-deb也受支持，並將產生一個可用的 Debian 軟體包，該軟體包安裝預設為停用的rperf systemd服務。啟動時，它以nobody:nogroup運行，假設預設支援 IPv6。

操作理論

與同時代的產品一樣， rperf的核心概念是以預先安排的目標速度向 IP 目標發射 TCP 或 UDP 資料流。觀察實際接收到的資料量並用於衡量網路連結的容量。

在這些領域內，收集有關交換品質的其他資料並可供審查。

從架構上來說， rperf讓客戶端建立到伺服器的 TCP 連接，之後客戶端發送有關要執行的測試的詳細信息，伺服器強制執行，在整個測試過程中向客戶端報告觀察結果。

客戶端可以請求使用多個平行流進行測試，這可以透過在兩側建立多個TCP 連接或UDP 套接字以及各自的專用線程來實現，這些連接可以進一步固定到單個邏輯CPU 核心以減少頁面的影響- 資料交換故障。

實施細節

客戶端-伺服器關係被視為此設計的一個非常核心的方面，這與iperf3和 zapwireless 形成鮮明對比，在 iperf3 中，它們更像是對等體，在zapwireless中，每個參與者運行自己的守護進程，並由第三個進程協調通訊。

值得注意的是，所有資料收集、計算和顯示都發生在客戶端，伺服器僅傳回其觀察到的內容。這可能會導致記錄出現一些偏差，特別是在涉及時間的情況下（伺服器間隔比相應的客戶端值長幾毫秒的情況並不罕見）。然而，假設連接沒有遺失，觀察到的數據總數將在所有操作模式下匹配。

伺服器使用三層線程：一層用於主線程，一層用於所服務的每個客戶端，還有一層用於與客戶端通訊的每個流。在客戶端，主執行緒用於與伺服器通信，並為與伺服器通訊的每個流產生一個附加執行緒。

當伺服器收到來自客戶端的請求時，它會產生一個執行緒來處理該客戶端的特定請求；在內部，測試的每個流都會在兩側產生一個類似迭代器的處理程序。客戶端和伺服器都非同步執行這些迭代器模擬，直到測試週期結束，此時發送方指示其流中的完成。

為了可靠地處理流級別斷開連接的可能性，客戶端-伺服器流中的保活機制（透過該機制定期從伺服器發送測試結果）將在幾秒鐘不活動後終止未完成的連接。

主機作業系統的 TCP 和 UDP 機制用於所有實際交換的流量，並公開一些調整參數。選擇這種方法而不是第 2 層或第 3 層之上的使用者空間實現，因為它最準確地代表了現實世界應用程式的行為方式。

考慮因素

JSON 序列化間隔資料中可見的「時間戳記」值是與主機相關的，因此除非您的環境具有非常高的系統時鐘精度，否則發送時間戳只能與其他發送時間戳進行比較，對於接收時間戳也是如此。然而，一般來說，這些數據在正確性驗證之外沒有用處。

在每個交換間隔期間，一次嘗試發送length字節，直到寫入流的數量達到或超過頻寬目標，此時發送方將保持沉默，直到下一個間隔開始；一個時間間隔內發送的資料應該在該時間段內均勻分佈。

流索引從0開始，而不是1 。這可能不會讓任何人感到驚訝，但在報告中看到「stream 0」並不值得擔心。

版權和發行

rperf由 Evtech Solutions, Ltd.（dba 3D-P）根據 GNU GPL 版本 3 分發，其文字可以在COPYING中找到。

作者身分詳細資訊、版權細節和可轉讓性說明都存在於原始碼本身。