rperf
v0.1.8
rperf ist eine Rust-basierte iperf- Alternative, die von 3D-P entwickelt wurde und darauf abzielt, einige in iperf3 auftretende Zuverlässigkeits- und Konsistenzprobleme zu vermeiden und gleichzeitig umfangreichere Metrikdaten bereitzustellen, wobei der Schwerpunkt auf dem Betrieb in einer verlusttoleranten, eher IoT-ähnlichen Umgebung liegt. Obwohl es als nahezu direkter Ersatz für iperf verwendet werden kann und möglicherweise Vorteile mit sich bringt, liegt sein Schwerpunkt auf der regelmäßigen Datenerfassung mit Überwachungsfunktion in einem geschlossenen Netzwerk, was bedeutet, dass es nicht für alle Domänen geeignet ist dass iperf dienen kann.
rperf ist eine unabhängige Implementierung, die sich auf die Algorithmen von iperf3 und zapwireless bezieht, um die Korrektheit zu bewerten und geeignete Korrekturen abzuleiten, aber keinen Code von beiden kopiert.
Im Folgenden werden insbesondere die wichtigsten von iperf3 behandelten Probleme aufgeführt:
Jeder Server unterstützt mehrere gleichzeitige Clients.
Die Implementierung von RFC 1889 für die Streaming-Jitter-Berechnung durch rperf beginnt mit der Annahme eines Deltas zwischen dem ersten und dem zweiten Paket in einer Sequenz, und Lücken in einer Sequenz lösen ein Zurücksetzen der Zählung aus. Im Vergleich dazu beginnt iperf3 mit 0, was künstlich niedrige Werte erzeugt, und im Falle einer Lücke geht es einfach naiv weiter, was künstlich hohe Werte erzeugt.
Doppelte Pakete werden beim UDP-Austausch berücksichtigt und Pakete in der falschen Reihenfolge werden als unabhängige Ereignisse gezählt.
Der gesamte Datenverkehr kann proportional in regelmäßigen Abständen von weniger als einer Sekunde ausgegeben werden, was Konfigurationen ermöglicht, die die tatsächlichen Datenübertragungs- und Sendealgorithmen genauer widerspiegeln.
Stream-Konfiguration und Ergebnisse werden über eine dedizierte Verbindung ausgetauscht und jeder Datenpfad verfügt über eine klar definierte Timeout-, Abschluss- und Fehlersemantik, sodass die Ausführung nicht auf unbestimmte Zeit auf einer Seite eines Tests hängen bleibt, wenn Schlüsselpakete verloren gehen.
Die JSON-Ausgabe von rperf ist strukturell zulässig. Keine Zeichenfolgen ohne Anführungszeichen, wiederholte Schlüssel oder freie Kommas, die alle vor der Verwendung eine Vorverarbeitung erfordern oder unerwartete Fehler verursachen.
Im Gegensatz zu zapwireless werden folgende Verbesserungen realisiert:
rperf verwendet eine klassische Client-Server-Architektur, sodass kein laufender Prozess auf Geräten aufrechterhalten werden muss, der auf eine Testausführungsanforderung wartet.
Jitter wird berechnet.
IPv6 wird unterstützt.
Im Rahmen eines Tests können mehrere Streams parallel ausgeführt werden.
Es ist eine Option omit verfügbar, um die TCP-Hochlaufzeit aus den Ergebnissen zu verwerfen.
Die Ausgabe ist in JSON verfügbar, um die Telemetrieerfassung zu vereinfachen.
rperf sollte auf allen wichtigen Plattformen funktionieren und funktionieren, obwohl sein Entwicklungs- und Nutzungsschwerpunkt auf Linux-basierten Systemen liegt, sodass es dort den umfassendsten Funktionsumfang aufweist.
Pull-Requests für Implementierungen gleichwertiger Funktionen für andere Systeme sind willkommen.
Alles ist in der Ausgabe von --help beschrieben und die meisten Benutzer, die mit ähnlichen Tools vertraut sind, sollten sich sofort wohl fühlen.
rperf funktioniert ähnlich wie iperf3 und teilt viele Konzepte und sogar Befehlszeilen-Flags. Ein wesentlicher Unterschied besteht darin, dass der Client den gesamten Konfigurationsprozess steuert, während der Server nur sein Bestes tut und einen Strom von Ergebnissen bereitstellt. Das bedeutet, dass der Server Testergebnisse nicht direkt über seine Schnittstelle präsentiert und dass TCP- und UDP-Tests auch für dieselbe Instanz ausgeführt werden können, möglicherweise von vielen Clients gleichzeitig.
Im normalen Betriebsmodus lädt der Client Daten auf den Server hoch; Wenn das reverse Flag gesetzt ist, empfängt der Client Daten.
Im Gegensatz zu iperf3 verwendet rperf standardmäßig keinen reservierten Portbereich. Auf diese Weise kann eine beliebige Anzahl von Clients parallel unterstützt werden, ohne dass es zu Ressourcenkonflikten auf praktisch nur einer kleinen Anzahl zusammenhängender Ports kommt. In der beabsichtigten Funktion sollte dies kein Problem darstellen, aber wenn es um nicht-permissive Firewalls und NAT-Setups geht, können die Optionen --tcp[6]-port-pool und --udp[6]-port-pool Problem sein Wird verwendet, um dem Satz nicht zusammenhängende Ports zuzuweisen, die zum Empfangen von Datenverkehr verwendet werden.
Es gibt auch kein Konzept zum Testen des Durchsatzes im Verhältnis zu einer festen Datenmenge. Der Fokus liegt vielmehr ausschließlich auf der Messung des Durchsatzes über einen ungefähr bekannten Zeitraum.
Von Bedeutung ist auch, dass sowohl IPv4- als auch IPv6-Clients eine Verbindung mit derselben Instanz herstellen können, wenn der Server im IPv6-Modus läuft und sein Host IPv4-Mapping in einer Dual-Stack-Konfiguration unterstützt.
rperf verwendet Ladung . Der typische Prozess ist einfach cargo build --release .
cargo-deb wird ebenfalls unterstützt und erstellt ein verwendbares Debian-Paket, das einen standardmäßig deaktivierten rperf systemd- Dienst installiert. Beim Start wird es als nobody:nogroup ausgeführt, wobei standardmäßig IPv6-Unterstützung vorausgesetzt wird.
Wie bei seinen Zeitgenossen besteht das Kernkonzept von rperf darin, einen Strom von TCP- oder UDP-Daten mit einer vorab festgelegten Zielgeschwindigkeit auf ein IP-Ziel abzufeuern. Die Menge der tatsächlich empfangenen Daten wird beobachtet und zur Beurteilung der Kapazität einer Netzwerkverbindung verwendet.
Innerhalb dieser Bereiche werden zusätzliche Daten über die Qualität des Austauschs gesammelt und zur Überprüfung bereitgestellt.
Architektonisch sieht rperf vor, dass Clients eine TCP-Verbindung zum Server herstellen. Anschließend sendet der Client Details über den durchzuführenden Test und der Server verpflichtet sich, Beobachtungsergebnisse während des gesamten Testprozesses an den Client zu melden.
Der Client kann die Verwendung mehrerer paralleler Streams zum Testen anfordern. Dies wird durch die Einrichtung mehrerer TCP-Verbindungen oder UDP-Sockets mit einem eigenen dedizierten Thread auf beiden Seiten erleichtert, die außerdem an einen einzelnen logischen CPU-Kern angeheftet werden können, um die Auswirkungen der Seite zu reduzieren -Störungen beim Datenaustausch.
Die Client-Server-Beziehung wird als sehr zentraler Aspekt dieses Designs behandelt, im Gegensatz zu iperf3 , wo sie eher wie Peers sind, und zapwireless , wo jeder Teilnehmer seinen eigenen Daemon betreibt und ein dritter Prozess die Kommunikation orchestriert.
Insbesondere erfolgt die gesamte Datenerfassung, -berechnung und -anzeige clientseitig, wobei der Server lediglich das zurückgibt, was er beobachtet hat. Dies kann zu einer gewissen Abweichung bei den Aufzeichnungen führen, insbesondere wenn es um die Zeit geht (Serverintervalle, die ein paar Millisekunden länger sind als die entsprechenden Clientwerte, sind keine Seltenheit). Unter der Annahme, dass die Verbindung nicht unterbrochen wurde, stimmen die Gesamtwerte der beobachteten Daten jedoch in allen Betriebsmodi überein.
Der Server verwendet drei Threading-Ebenen: eine für den Hauptthread, eine für jeden bedienten Client und eine weitere für jeden Stream, der mit dem Client kommuniziert. Auf der Clientseite wird der Hauptthread für die Kommunikation mit dem Server verwendet und erzeugt für jeden Stream, der mit dem Server kommuniziert, einen zusätzlichen Thread.
Wenn der Server eine Anfrage von einem Client empfängt, erzeugt er einen Thread, der die spezifische Anfrage dieses Clients verarbeitet. Intern erzeugt jeder Stream für den Test auf beiden Seiten einen Iterator-ähnlichen Handler. Sowohl der Client als auch der Server führen diese Iterator-Analoga asynchron gegeneinander aus, bis der Testzeitraum endet. Zu diesem Zeitpunkt gibt der Absender in seinem Stream den Abschluss an.
Um die Möglichkeit von Verbindungsabbrüchen auf Stream-Ebene zuverlässig zu bewältigen, beendet ein Keepalive-Mechanismus im Client-Server-Stream, über den in regelmäßigen Abständen Testergebnisse vom Server gesendet werden, ausstehende Verbindungen nach einigen Sekunden Inaktivität.
Die TCP- und UDP-Mechanismen des Host-Betriebssystems werden für den gesamten tatsächlich ausgetauschten Datenverkehr verwendet, wobei einige Optimierungsparameter offengelegt werden. Dieser Ansatz wurde gegenüber einer Userspace-Implementierung auf Layer-2 oder Layer-3 gewählt, da er das Verhalten realer Anwendungen am genauesten widerspiegelt.
Die in JSON-serialisierten Intervalldaten sichtbaren „Zeitstempel“-Werte sind hostbezogen. Wenn Ihre Umgebung also nicht über eine sehr hohe Systemtaktgenauigkeit verfügt, sollten Sendezeitstempel nur mit anderen Sendezeitstempeln und Empfangszeitstempeln verglichen werden. Im Allgemeinen sind diese Daten jedoch außerhalb der Korrektheitsvalidierung nicht nützlich.
Während jedes Austauschintervalls wird versucht, jeweils length zu senden, bis die in den Stream geschriebene Menge das Bandbreitenziel erreicht oder überschreitet. Ab diesem Zeitpunkt bleibt der Absender bis zum Beginn des nächsten Intervalls stumm. Die innerhalb eines Intervalls gesendeten Daten sollten gleichmäßig über den Zeitraum verteilt sein.
Stream-Indizes beginnen bei 0 , nicht bei 1 . Das wird wahrscheinlich niemanden überraschen, aber „Stream 0“ in einem Bericht zu sehen, ist kein Grund zur Sorge.
rperf wird von Evtech Solutions, Ltd., dba 3D-P, unter der GNU GPL Version 3 vertrieben, deren Text in COPYING zu finden ist.
Angaben zur Urheberschaft, Einzelheiten zum Urheberrecht und Hinweise zur Übertragbarkeit sind im Quellcode selbst enthalten.
