flowgrind - En ligne dans le Cloud

PROGRAMME:

Nom

flowgrind - générateur de trafic TCP avancé pour Linux, FreeBSD et Mac OS X

SYNOPSIS

broyeur à flux [OPTION] ...

DESCRIPTION

affiner est un générateur de trafic TCP avancé pour tester et comparer Linux,
Piles FreeBSD et Mac OS X TCP/IP. Contrairement à d'autres outils de mesure du rendement, il
dispose d'une architecture distribuée, où le débit et d'autres métriques sont mesurés
entre les processus de serveur flowgrind arbitraires, le démon flowgrind flowgrind (1).

Flowgrind mesure en plus du goodput (débit), le temps d'interarrivée de la couche d'application
(IAT) et temps aller-retour (RTT), nombre de blocs et transactions/s réseau. Contrairement à la plupart des croix-
outils de test de plate-forme, flowgrind collecte et rapporte les métriques TCP renvoyées par le
Option de socket TCP_INFO, qui sont généralement internes à la pile TCP/IP. Sous Linux et
FreeBSD cela inclut entre autres l'estimation du noyau du RTT de bout en bout, la taille
de la fenêtre de congestion TCP (CWND) et du seuil de démarrage lent (SSTHRESH).

Flowgrind a une architecture distribuée. Il est divisé en deux composants : le flowgrind
démon, flowgrind(1), et le affiner manette. À l'aide du contrôleur, circule entre
deux systèmes exécutant le démon flowgrind peuvent être configurés (tests tiers). À régulier
intervalles pendant le test, le contrôleur collecte et affiche les résultats mesurés à partir de
les démons. Il peut exécuter plusieurs flux à la fois avec des paramètres identiques ou différents et
planifier individuellement chacun. La connexion de test et de contrôle peut éventuellement être déviée vers
différentes interfaces.

La génération de trafic elle-même est soit un transfert en masse, à débit limité ou sophistiqué
tests requête/réponse. Flowgrind utilise libpcap pour vider automatiquement le trafic pour
analyse qualitative.

OPTIONS

Il s'agit de deux groupes d'options importants : les options de contrôleur et les options de flux. Comme le
le nom l'indique, les options du contrôleur s'appliquent globalement et affectent potentiellement tous les flux, tandis que
les options spécifiques au flux ne s'appliquent qu'au sous-ensemble de flux sélectionné à l'aide de la -F option.

Les arguments obligatoires pour les options longues est obligatoire pour les options courtes.

Général Options
-h, --Aidez-moi[=EN QUOI]
afficher l'aide et quitter. QUOI facultatif peut être soit « socket » pour obtenir de l'aide sur le socket
options ou aide à la génération de trafic 'trafic'

-v, --version
imprimer les informations sur la version et quitter

Options
-c, --show-colon=TYPE[,TYPE] ...
afficher la colonne de rapport d'intervalle intermédié TYPE en sortie. Valeurs autorisées pour
TYPE sont : 'interval', 'through', 'transac', 'iat', 'kernel' (tous affichés par défaut),
et 'blocks', 'rtt', 'delay' (facultatif)

-d, --déboguer
augmenter la verbosité du débogage. Ajouter une option plusieurs fois pour augmenter la verbosité

-e, --dump-préfixe=PRE
ajouter le préfixe PRE pour vider le nom du fichier (par défaut : "flowgrind-")

-i, --report-intervalle=#.#
intervalle de rapport, en secondes (par défaut : 0.05 s)

--fichier journal[=DOSSIER]
écrire la sortie dans le fichier journal FILE (par défaut : flowgrind-'timestamp'.log)

-m débit de rapport en 2**20 octets/s (par défaut : 10**6 bits/s)

-n, --flux=#
nombre de flux de test (par défaut : 1)

-o écraser les fichiers journaux existants (par défaut : ne pas le faire)

-p ne pas imprimer de valeurs symboliques (comme INT_MAX) au lieu de nombres

-q, --silencieux
soyez silencieux, ne vous connectez pas à l'écran (par défaut : désactivé)

-s, --tcp-pile=TYPE
ne détermine pas automatiquement l'unité des piles TCP source. Forcer l'unité à TYPE, où
TYPE est « segment » ou « octet »

-w écrire la sortie dans le fichier journal (identique à --fichier journal)

Flow Options
Tous les flux ont deux points de terminaison, une source et une destination. La distinction entre la source
et les points de terminaison de destination n'affectent que l'établissement de la connexion. Lors du démarrage d'un flux, le
le point de terminaison de destination écoute sur un socket et le point de terminaison source s'y connecte. Pour le
test réel, cela ne fait aucune différence, les deux points de terminaison ont exactement les mêmes capacités.
Les données peuvent être envoyées dans les deux sens et de nombreux paramètres peuvent être configurés individuellement pour
chaque point final.

Certaines de ces options prennent le point de terminaison du flux comme argument, indiqué par « x » dans l'option
syntaxe. « x » doit être remplacé par « s » pour le point de terminaison source, « d » pour le
point de terminaison de destination ou « b » pour les deux points de terminaison. Pour spécifier des valeurs différentes pour chacun
points de terminaison, séparez-les par une virgule. Par exemple -W s=8192,d=4096 définit l'annonce
fenêtre à 8192 à la source et 4096 à la destination.

-A x utiliser la taille de réponse minimale nécessaire pour le calcul du RTT
(pareil que -G s=p,C,40)

-B x=# définir le tampon d'envoi demandé, en octets

-C x arrêter le flux s'il connaît une congestion locale

-D x=DSCP
Valeur DSCP pour l'octet d'en-tête IP du type de service (TOS)

-E énumérer les octets dans la charge utile au lieu d'envoyer des zéros

-F #[,#] ...
les options de flux suivant cette option s'appliquent uniquement aux ID de flux donnés. Utile dans
combinaison avec -n pour définir des options spécifiques pour certains flux. La numérotation commence
avec 0, donc -F 1 fait référence au deuxième flux. Avec -1 tous les flux peuvent être référencés

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]
activer la génération de trafic stochastique et définir les paramètres en fonction du
Distribution. Pour plus d'informations, consultez la section « Option de génération de trafic »

-H x=HÔTE[/CONTRÔLE[:PORT]]
test de/vers HOST. L'argument facultatif est l'adresse et le port du CONTROL
connexion au même hôte. Un point de terminaison qui n'est pas spécifié est supposé être
localhost

-J # utiliser la graine aléatoire # (par défaut : lire / Dev / urandom)

-I activer le calcul du délai unidirectionnel (pas de synchronisation d'horloge)

-L appelez connect() sur le socket de test juste avant de commencer à envoyer des données (en retard
relier). Si non spécifié, la connexion de test est établie dans la préparation
phase avant le début du test

-M x vider le trafic en utilisant libpcap. flowgrind(1) doit être exécuté en tant que root

-N shutdown () dans chaque direction de socket après le flux de test

-O x=OPT
définissez l'option de prise OPT sur la prise de test. Pour plus d'informations, voir la section
'Options de socket'

-P x ne parcourez pas select() pour continuer à envoyer au cas où la taille du bloc ne serait pas
suffire à remplir la file d'attente d'envoi (poussant)

-Q résumer uniquement, aucun rapport d'intervalle intermédiaire n'est calculé (silencieux)

-R x=#.#(z|k|M|G)(b|B)
envoyer au taux spécifié par seconde, où : z = 2**0, k = 2**10, M = 2**20, G =
2**30, et b = bits/s (par défaut), B = octets/s

-S x=# définir la taille du bloc (message), en octets (identique à -G s=q,C,#)

-T x=#.#
définir la durée du débit, en secondes (par défaut : s=10,d=0)

-U # définir la taille du tampon de l'application, en octets (par défaut : 8192) tronque les valeurs si elles sont utilisées avec
génération de trafic stochastique

-W x=# définir le tampon du récepteur demandé (fenêtre annoncée), en octets

-Y x=#.#
définir le délai initial avant que l'hôte ne commence à envoyer, en secondes

CIRCULATION GÉNÉRATION OPTION

Par option -G flowgrind prend en charge la génération de trafic stochastique, ce qui permet de conduire
en plus du volume normal, des transferts de données avancés à débit limité et demande-réponse sont également avancés.

L'option de génération de trafic stochastique -G prend le point de terminaison du flux comme argument, noté
par 'x' dans la syntaxe des options. « x » doit être remplacé par « s » pour la source
point de terminaison, « d » pour le point de terminaison de destination ou « b » pour les deux points de terminaison. Cependant, veuillez noter
que la génération de trafic bidirectionnel peut conduire à des résultats inattendus. Pour spécifier différents
valeurs pour chaque point de terminaison, séparez-les par une virgule.

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]

Paramètre de débit :

q taille de la requête (en octets)

p taille de la réponse (en octets)

g demande d'écart interpaquet (en secondes)

Répartition :

C constante (#1: valeur, #2: non utilisé)

U uniforme (#1: mini, #2: maxi)

E exponentielle (#1: lamba - à vie, #2: non utilisé)

N Ordinaire (#1: mu - valeur moyenne, #2: sigma_square - écart)

L log-normale (#1: zêta - signifie, #2: sigma - développement std)

P Pareto (#1: k - forme, #2: x_min - échelle)

W Weibull (#1: lambda - échelle, #2: k - forme)

Les distributions avancées comme weibull ne sont disponibles que si flowgrind est compilé
avec prise en charge de libgsl.

-U # spécifier un plafond pour les valeurs calculées pour les tailles de demande et de réponse, nécessaire
parce que les valeurs distribuées avancées sont illimitées, mais nous devons connaître les
buffersize (il n'est pas nécessaire pour les valeurs constantes ou la distribution uniforme). Valeurs
en dehors des limites sont recalculés jusqu'à ce qu'un résultat valide se produise mais au plus 10
fois (alors la valeur liée est utilisée)

PRISE OPTION

Flowgrind permet de définir les options de socket standard et non standard suivantes via l'option
-O.

Toutes les options de socket prennent le point de terminaison du flux comme argument, indiqué par « x » dans l'option
syntaxe. « x » doit être remplacé par « s » pour le point de terminaison source, « d » pour le
point de terminaison de destination ou « b » pour les deux points de terminaison. Pour spécifier des valeurs différentes pour chacun
points de terminaison, séparez-les par une virgule. De plus, il est possible de passer plusieurs fois le même
point de terminaison afin de spécifier plusieurs options de socket.

Standard douille Options
-O x=TCP_CONGESTION=ALG
définir l'algorithme de contrôle de congestion ALG sur la prise de test

-O x=TCP_CORK
définir TCP_CORK sur le socket de test

-O x=TCP_NODELAY
désactiver l'algorithme Nagle sur le socket de test

-O x=SO_DEBUG
définir SO_DEBUG sur le socket de test

-O x=IP_MTU_DÉCOUVERTE
définir IP_MTU_DISCOVER sur le socket de test s'il n'est pas déjà activé par défaut du système

-O x=ROUTE_ENREGISTREMENT
définir ROUTE_RECORD sur le socket de test

Non standard douille Options
-O x=TCP_MTCP
définir TCP_MTCP (15) sur le socket de test

-O x=TCP_ELCN
définir TCP_ELCN (20) sur le socket de test

-O x=TCP_LCD
définir TCP_LCD (21) sur le socket de test

EXEMPLES

affiner
test des performances TCP IPv4 localhost avec les paramètres par défaut, comme flowgrind -H
b=127.0.0.1 -Ts=10,d=0. Le démon flowgrind doit être exécuté sur localhost

affiner -H b=::1/127.0.0.1
comme ci-dessus, mais en testant les performances TCP IPv6 de l'hôte local avec les paramètres par défaut

affiner -H s=hôte1,d=hôte2
transfert TCP en masse entre host1 et host2. Host1 agit comme source, host2 comme
point de terminaison de destination. Les deux points de terminaison doivent exécuter le démon flowgrind. Les
les options de flux par défaut sont utilisées, avec une durée de flux de 10 secondes et un flux de données
de l'hôte1 à l'hôte2

affiner -H s=hôte1,d=hôte2 -T s=0,d=10
Identique à ce qui précède mais à la place avec un flux envoyant des données pendant 10 secondes de host2 à
host1

affiner -n 2 -F 0 -H s=192.168.0.1,d=192.168.0.69 -F 1 -H s=10.0.0.1,d=10.0.0.2
configurer deux flux parallèles, le premier flux entre 192.168.0.1 et 192.168.0.69, le second
débit entre 10.0.0.1 à 10.0.0.2

affiner -p -H s=10.0.0.100/192.168.1.100,d=10.0.0.101/192.168.1.101 -A s
configurer un flux entre 10.0.0.100 et 10.0.0.101 et utiliser les adresses IP 192.168.1.x
pour contrôler le trafic. Activer la réponse minimale pour le calcul du RTT

affiner -i 0.001 -T s = 1 | égrep ^S | gnuplot -persister -e 'terrain "-" en utilisant 3:5 avec lignes
titre "Débit" '
configurer un flux sur un périphérique de bouclage et tracer les données de l'expéditeur avec l'aide
de gnuplot

affiner -G s=q,C,400 -G s=p,N,2000,50 -G s=g,U,0.005,0.01 -U 32000
-G s=q,C,400 : utiliser une taille de requête constante de 400 octets
-G s=p,N,2000,50 : utilise une taille de réponse distribuée normale avec une moyenne de 2000 octets et
écart 50
-G s=g,U,0.005,0.01 : utiliser un écart interpaquet distribué uniforme avec au moins 0.005 s et
et max 10ms
-U 32000 : taille des blocs tronqués à 32 ko (nécessaire pour une distribution normale)

CIRCULATION SCÉNARIOS

Les exemples suivants montrent comment la capacité de génération de trafic de flowgrind peut être
utilisé. Ceux-ci ont été incorporés dans différents tests pour le flowgrind et ont fait leurs preuves
significative. Cependant, comme le trafic Internet est diversifié, il n'y a aucune garantie qu'ils soient
approprié dans chaque situation.

Demande Réponse Style (HTTP)
Ce scénario est basé sur les travaux de
http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf.

affiner -M s -G s=q,C,350 -G s=p,L,9055,115.17 -U 100000
-M s : décharger le trafic côté expéditeur
-G s=q,C,350 : utilise une taille de requête constante de 350 octets
-G s=p,L,9055,115 : utiliser une distribution lognormale avec une moyenne de 9055 et une variance de 115 pour
taille de la réponse
-U 100000 : réponse tronquée à 100 ko

Pour ce scénario, nous avons recommandé de nous concentrer sur RTT (des valeurs inférieures sont meilleures) et sur le réseau
Transactions/s en tant que métrique (des valeurs plus élevées sont meilleures).

interactif Session (Telnet)
Ce scénario émule une session telnet.

affiner -G s=q,U,40,10000 -G s=q,U,40,10000 -O b=TCP_NODELAY
-G s=q,U,40,10000 -G s=q,U,40,10000 : utiliser une requête et une réponse distribuées uniformes
taille entre 40B et 10ko
-O b=TCP_NODELAY : définit les options de socket TCP_NODELAY utilisées par les applications telnet

Pour ce scénario, le RTT (plus faible est le meilleur) et les transactions réseau/s sont des métriques utiles
(plus c'est mieux).

Tarif limité (Diffusion Médias)
Ce scénario émule un transfert de flux vidéo avec un débit de 800 kbit/s.

affiner -G s=q,C,800 -G s=g,N,0.008,0.001
Utiliser un écart interpaquet distribué normal avec une moyenne de 0.008 et une petite variance
(0.001). En conjonction avec la taille de la requête 800 octets, un débit binaire moyen d'environ 800
kbit/s est atteint. La variance est ajoutée pour émuler un débit variable comme si c'était
utilisé dans les codecs vidéo d'aujourd'hui.

Pour ce scénario, l'IAT (le plus bas est le meilleur) et le débit minimal (le plus haut est le meilleur) sont
métriques intéressantes.

SORTIE COLONNES

Flux/point final Identificateurs
# point de terminaison du flux, soit « S » pour la source ou « D » pour la destination

ID identifiant de flux numérique

commencer ainsi que fin
limites de l'intervalle de mesure en secondes. Le temps affiché est le temps écoulé
temps écoulé depuis la réception du message RPC pour démarrer le test à partir du point de démons de
vue

Candidature couche métrique
à travers
transmettre le bon débit du point final de débit pendant cet intervalle de mesure,
mesuré en Mbit/s (par défaut) ou en Mo/s (-m)

transaction
nombre de blocs de réponse reçus avec succès par seconde (nous l'appelons réseau
opérations/s)

demande/resp
nombre de bloc requête et réponse émis durant cet intervalle de mesure (colonne
désactivé par défaut)

IAT bloc de temps inter-arrivées (IAT). Avec le minimum et le maximum, le
la moyenne arithmétique pour cet intervalle de mesure spécifique est affichée. Si aucun bloc n'est
reçu pendant l'intervalle de rapport, 'inf' s'affiche.

DLY ainsi que RTT
Retard de bloc à 1 et 2 voies respectivement la latence de bloc et l'aller-retour de bloc
temps (RTT). Pour les deux retards, les valeurs minimales et maximales rencontrées dans ce
l'intervalle de mesure sont affichés avec la moyenne arithmétique. Si pas de bloc,
respectivement l'accusé de réception de bloc est arrivé pendant cet intervalle de rapport, 'inf' est
affiché. Les retards de blocage unidirectionnel et bidirectionnel sont tous deux désactivés par défaut (voir
option -I ainsi que -A).

Noyau métrique (TCP_INFO)
Toutes les métriques spécifiques à TCP suivantes sont obtenues à partir du noyau via TCP_INFO
option de prise à la fin de chaque intervalle de rapport. Le taux d'échantillonnage peut être modifié via
option -i.

cwnd (tcpi_cwnd)
taille de la fenêtre de congestion TCP (CWND) en nombre de segments (Linux) ou en octets
(GratuitBSD)

qch (tcpi_snd_sshtresh)
taille du seuil de démarrage lent en nombre de segments (Linux) ou d'octets (FreeBSD)

euh (tcpi_unacked)
nombre de segments actuellement non reconnus, c'est-à-dire nombre de segments en vol
(FlightSize) (Linux uniquement)

sac (tcpi_sacked)
nombre de segments reconnus sélectivement (Linux uniquement)

perdu (tcpi_lost)
nombre de segments supposés perdus (Linux uniquement)

retr (tcpi_retrans)
nombre de segments retransmis non acquittés (Linux uniquement)

tret (tcpi_retransmit)
nombre de retransmissions déclenchées par un délai de retransmission (RTO) (Linux uniquement)

fack (tcpi_fackets)
nombre de segments entre SND.UNA et le plus élevé sélectivement reconnu
numéro de séquence (SND.FACK) (Linux uniquement)

réor (tcpi_reordering)
métrique de réorganisation des segments. Le noyau Linux peut détecter et gérer la réorganisation
sans perte significative de performance si la distance sur laquelle un segment est déplacé ne
ne pas dépasser la métrique de réorganisation (Linux uniquement)

rtt (tcpi_rtt) et rttvar (tcpi_rttvar)
Temps d'aller-retour TCP et sa variance donnés en ms

rto (tcpi_rto)
le timeout de retransmission donné en ms

bkof (tcpi_backoff)
nombre d'interruptions de RTO (Linux uniquement)

ca Etat (tcpi_ca_state)
état interne de la machine d'état de contrôle d'encombrement TCP telle qu'implémentée dans le
Noyau Linux. Peut être l'un des ouvert, trouble, file d'attente, récupération or perte (Linux uniquement)

Ouvert est l'état normal. Il indique qu'aucun accusé de réception en double (ACK) n'est
reçu et aucun segment n'est considéré comme perdu

Trouble
est inscrit à la réception du premier double ACK consécutif ou
reconnaissance sélective (SACK)

CWR est entré lorsqu'une notification de la notification explicite d'encombrement (ECN)
est reçu

Récupération
est entré lorsque trois ACK en double ou un nombre équivalent de SACK sont
a reçu. Dans cet état, les procédures de contrôle d'encombrement et de récupération des pertes comme
La retransmission rapide et la récupération rapide (RFC 5861) sont exécutées

Perte est entré si le RTO expire. Encore une fois le contrôle de la congestion et la récupération des pertes
les procédures sont exécutées

smss ainsi que pmtu
taille de segment maximale de l'expéditeur et unité de transmission maximale du chemin en octets

Interne affiner Etat (seulement activé in déboguer construit)
statuts état de l'écoulement à l'intérieur du flowgrind à des fins de diagnostic. C'est un tuple de deux
valeurs, la première pour l'envoi et la seconde pour la réception. Idéalement, les états de
les points de terminaison source et destination d'un flux doivent être symétriques, mais puisque
ils ne sont pas synchronisés, ils peuvent ne pas changer en même temps. Les valeurs possibles
sont:

c Direction terminée envoi/réception

d En attente du délai initial

f État de défaut

l État actif, rien encore transmis ou reçu

n Activité normale, certaines données ont été transmises ou reçues

o Le flux a une durée nulle dans cette direction, aucune donnée ne sera échangée

AUTEURS

Flowgrind a été lancé à l'origine par Daniel Schaffrath. La mesure distribuée
l'architecture et la génération de trafic avancée ont été ajoutées plus tard par Tim Kosse et
Christian Samsel. Actuellement, flowgrind est développé et maintenu Arnd Hannemann et
Alexandre Zimmermann.

Utiliser flowgrind en ligne à l'aide des services onworks.net