rperf
v0.1.8
rperf est une alternative iperf basée sur Rust développée par 3D-P, visant à éviter certains problèmes de fiabilité et de cohérence rencontrés dans iperf3 , tout en fournissant simultanément des données de métriques plus riches, en mettant l'accent sur le fonctionnement dans un environnement plus tolérant aux pertes et plus proche de l'IoT. Bien qu'il puisse être utilisé comme un substitut quasi immédiat à iperf , et que cela puisse présenter des avantages, il se concentre sur la collecte périodique de données dans le cadre d'une capacité de surveillance dans un réseau fermé, ce qui signifie qu'il ne convient pas à tous les domaines. que iperf peut servir.
rperf est une implémentation indépendante, faisant référence aux algorithmes d' iperf3 et de zapwireless pour évaluer l'exactitude et dériver les corrections appropriées, mais ne copiant aucun code de l'un ou l'autre.
En particulier, les problèmes les plus importants résolus par iperf3 sont les suivants :
Plusieurs clients simultanés sont pris en charge par un serveur donné.
L'implémentation par rperf de la RFC 1889 pour le calcul de la gigue de streaming commence par supposer un delta entre le premier et le deuxième paquets d'une séquence et des écarts dans une séquence déclenchent une réinitialisation du décompte. Comparativement, iperf3 commence par 0, ce qui crée des valeurs artificiellement basses, et en cas d'écart, il continue naïvement, ce qui crée des valeurs artificiellement élevées.
Les paquets en double sont pris en compte dans les échanges UDP et les paquets dans le désordre sont comptés comme des événements indépendants.
Tout le trafic peut être émis proportionnellement à des intervalles réguliers de moins d'une seconde, ce qui permet des configurations qui reflètent plus précisément les algorithmes réels de transmission et d'envoi de données.
La configuration du flux et les résultats sont échangés via une connexion dédiée et chaque chemin de données a une sémantique de délai d'attente, d'achèvement et d'échec clairement définie, de sorte que l'exécution ne soit pas suspendue indéfiniment d'un côté ou de l'autre d'un test lorsque des paquets clés sont perdus.
La sortie JSON de rperf est structurellement légale. Pas de chaînes sans guillemets, de clés répétées ou de virgules pendantes, qui nécessitent tous un prétraitement avant consommation ou provoquent des erreurs inattendues.
Contrairement au zapwireless , les améliorations suivantes sont réalisées :
rperf utilise une architecture client-serveur classique, il n'est donc pas nécessaire de maintenir un processus en cours d'exécution sur les appareils qui attend une demande d'exécution de test.
La gigue est calculée.
IPv6 est pris en charge.
Plusieurs flux peuvent être exécutés en parallèle dans le cadre d'un test.
Une option omit est disponible pour ignorer le temps de montée en puissance TCP des résultats.
La sortie est disponible en JSON pour faciliter la récolte de télémétrie.
rperf devrait être construit et fonctionner sur toutes les principales plates-formes, bien que son développement et son utilisation soient axés sur les systèmes basés sur Linux, c'est donc là qu'il sera le plus complet en termes de fonctionnalités.
Les demandes d'extraction pour l'implémentation de fonctionnalités équivalentes pour d'autres systèmes sont les bienvenues.
Tout est décrit dans le résultat de --help et la plupart des utilisateurs familiers avec des outils similaires devraient se sentir immédiatement à l'aise.
rperf fonctionne un peu comme iperf3 , partageant de nombreux concepts et même des indicateurs de ligne de commande. Un domaine clé dans lequel cela diffère est que le client pilote tout le processus de configuration tandis que le serveur se contente de se conformer au mieux de ses capacités et fournit un flux de résultats. Cela signifie que le serveur ne présentera pas les résultats des tests directement via son interface et que les tests TCP et UDP peuvent également être exécutés sur la même instance, potentiellement par plusieurs clients simultanément.
Dans son mode de fonctionnement normal, le client téléchargera les données sur le serveur ; lorsque l'indicateur reverse est défini, le client recevra des données.
Contrairement à iperf3 , rperf n'utilise pas de plage de ports réservée par défaut. Cela lui permet de prendre en charge un nombre arbitraire de clients en parallèle sans conflit de ressources sur ce qui ne peut pratiquement être qu'un petit nombre de ports contigus. Dans la mesure prévue, cela ne devrait pas poser de problème, mais en ce qui concerne les pare-feu non permissifs et les configurations NAT, les options --tcp[6]-port-pool et --udp[6]-port-pool peuvent être utilisé pour allouer des ports non continus à l'ensemble qui sera utilisé pour recevoir le trafic.
Il n’existe pas non plus de concept de test du débit par rapport à une quantité fixe de données. L’objectif principal est plutôt de mesurer le débit sur une période de temps à peu près connue.
Il est également important que si le serveur s'exécute en mode IPv6 et que son hôte prend en charge le mappage IPv4 dans une configuration à double pile, les clients IPv4 et IPv6 peuvent se connecter à la même instance.
rperf utilise cargo . Le processus typique sera simplement cargo build --release .
cargo-deb est également pris en charge et produira un paquet Debian utilisable qui installe un service rperf systemd désactivé par défaut. Au démarrage, il s'exécute sous le nom nobody:nogroup , en supposant la prise en charge IPv6 par défaut.
Comme ses contemporains, le concept de base de rperf consiste à envoyer un flux de données TCP ou UDP sur une cible IP à une vitesse cible prédéfinie. La quantité de données réellement reçues est observée et utilisée pour évaluer la capacité d'une liaison réseau.
Dans ces domaines, des données supplémentaires sur la qualité de l'échange sont collectées et mises à disposition pour examen.
Sur le plan architectural, rperf demande aux clients d'établir une connexion TCP au serveur, après quoi le client envoie des détails sur le test à effectuer et le serveur s'y oblige, rapportant les résultats des observations au client pendant tout le processus de test.
Le client peut demander que plusieurs flux parallèles soient utilisés pour les tests, ce qui est facilité par l'établissement de plusieurs connexions TCP ou sockets UDP avec leur propre thread dédié de chaque côté, qui peuvent en outre être épinglés sur un seul cœur de processeur logique pour réduire l'impact de la page. -des défauts sur l'échange de données.
La relation client-serveur est traitée comme un aspect très central de cette conception, contrairement à iperf3 , où ils ressemblent davantage à des pairs, et à zapwireless , où chaque participant exécute son propre démon et où un troisième processus orchestre la communication.
Notamment, toutes les collectes de données, calculs et affichages se font côté client, le serveur renvoyant simplement ce qu'il a observé. Cela peut entraîner une certaine dérive dans les enregistrements, en particulier en ce qui concerne le temps (les intervalles du serveur étant de quelques millisecondes plus longs que leurs valeurs client correspondantes n'est pas du tout rare). Toutefois, en supposant que la connexion n'a pas été perdue, les totaux des données observées correspondront dans tous les modes de fonctionnement.
Le serveur utilise trois couches de thread : une pour le thread principal, une pour chaque client servi et une autre pour chaque flux qui communique avec le client. Côté client, le thread principal est utilisé pour communiquer avec le serveur et génère un thread supplémentaire pour chaque flux qui communique avec le serveur.
Lorsque le serveur reçoit une requête d'un client, il génère un thread qui gère la requête spécifique de ce client ; en interne, chaque flux du test produit un gestionnaire de type itérateur de chaque côté. Le client et le serveur exécutent ces analogues d'itérateur les uns contre les autres de manière asynchrone jusqu'à la fin de la période de test, moment auquel l'expéditeur indique l'achèvement dans son flux.
Pour gérer de manière fiable la possibilité de déconnexions au niveau du flux, un mécanisme keepalive dans le flux client-serveur, sur lequel les résultats des tests sont envoyés depuis le serveur à intervalles réguliers, mettra fin aux connexions en attente après quelques secondes d'inactivité.
Les mécanismes TCP et UDP du système d'exploitation hôte sont utilisés pour tout le trafic réel échangé, avec certains paramètres de réglage exposés. Cette approche a été choisie plutôt qu'une implémentation dans l'espace utilisateur au-dessus de la couche 2 ou de la couche 3, car elle représente le plus précisément possible le comportement des applications du monde réel.
Les valeurs « d'horodatage » visibles dans les données d'intervalle sérialisées JSON sont relatives à l'hôte, donc à moins que votre environnement n'ait une très grande précision d'horloge système, les horodatages d'envoi ne doivent être comparés qu'à d'autres horodatages d'envoi et de même pour les horodatages de réception. En général, ces données ne sont cependant pas utiles en dehors de la validation de l’exactitude.
Au cours de chaque intervalle d'échange, une tentative est effectuée pour envoyer des octets length à la fois, jusqu'à ce que la quantité écrite dans le flux atteigne ou dépasse l'objectif de bande passante, auquel cas l'expéditeur reste silencieux jusqu'au début de l'intervalle suivant ; les données envoyées dans un intervalle doivent être uniformément réparties sur la période.
Les index de flux commencent à 0 , et non à 1 . Cela ne surprendra probablement personne, mais voir le « flux 0 » dans un rapport n’est pas préoccupant.
rperf est distribué par Evtech Solutions, Ltd., dba 3D-P, sous la GNU GPL version 3, dont le texte peut être trouvé dans COPYING .
Les détails de la paternité, les spécificités du droit d'auteur et les notes de transférabilité sont présents dans le code source lui-même.
