Je voudrais simuler le retard et la perte de paquets pour UDP
et TCP
sur Linux afin de mesurer les performances d'une application. Existe-t-il un moyen simple de procéder?
Je voudrais simuler le retard et la perte de paquets pour UDP
et TCP
sur Linux afin de mesurer les performances d'une application. Existe-t-il un moyen simple de procéder?
Réponses:
netem tire parti des fonctionnalités déjà intégrées à Linux et aux utilitaires de l'espace utilisateur pour simuler les réseaux. C'est en fait ce à quoi la réponse de Mark fait référence, sous un nom différent.
Les exemples sur leur page d'accueil montrent déjà comment vous pouvez réaliser ce que vous avez demandé:
Exemples
Émulation des retards du réseau étendu
Ceci est l'exemple le plus simple, il ajoute simplement un délai fixe à tous les paquets sortant de l'Ethernet local.
# tc qdisc add dev eth0 root netem delay 100ms
Désormais, un simple test ping à héberger sur le réseau local devrait montrer une augmentation de 100 millisecondes. Le retard est limité par la résolution d'horloge du noyau (Hz). Sur la plupart des systèmes 2.4, l'horloge système fonctionne à 100 Hz, ce qui permet des retards par incréments de 10 ms. Sur 2.6, la valeur est un paramètre de configuration de 1000 à 100 Hz.
Les exemples ultérieurs modifient simplement les paramètres sans recharger le qdisc
Les réseaux étendus réels présentent une variabilité, il est donc possible d'ajouter une variation aléatoire.
# tc qdisc change dev eth0 root netem delay 100ms 10ms
Cela entraîne un retard supplémentaire de 100 ± 10 ms. La variation du retard du réseau n'est pas purement aléatoire, donc pour émuler qu'il existe également une valeur de corrélation.
# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
Cela entraîne un retard supplémentaire de 100 ± 10 ms, l'élément aléatoire suivant dépendant de 25% du dernier. Ce n'est pas une vraie corrélation statistique, mais une approximation.
Distribution de retard
En règle générale, le retard dans un réseau n'est pas uniforme. Il est plus courant d'utiliser quelque chose comme une distribution normale pour décrire la variation du retard. La discipline netem peut prendre un tableau pour spécifier une distribution non uniforme.
# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
Les tables réelles (normal, pareto, paretonormal) sont générées dans le cadre de la compilation iproute2 et placées dans / usr / lib / tc; il est donc possible avec un certain effort de faire votre propre distribution sur la base de données expérimentales.
Perte de paquets
La perte de paquets aléatoire est spécifiée dans la commande 'tc' en pourcentage. La plus petite valeur non nulle possible est:
2 −32 = 0,0000000232%
# tc qdisc change dev eth0 root netem loss 0.1%
Cela provoque la suppression aléatoire de paquets au 1 / 10ème de pour cent (c'est-à-dire 1 sur 1000).
Une corrélation facultative peut également être ajoutée. Le générateur de nombres aléatoires est ainsi moins aléatoire et peut être utilisé pour émuler des pertes de salves de paquets.
# tc qdisc change dev eth0 root netem loss 0.3% 25%
Cela entraînera la perte de 0,3% des paquets, et chaque probabilité successive dépend d'un quart du dernier.
Prob n = 0,25 × Prob n-1 + 0,75 × Aléatoire
Notez que vous devez l'utiliser tc qdisc add
si vous n'avez pas de règles pour cette interface ou tc qdisc change
si vous avez déjà des règles pour cette interface. Tenter d'utiliser tc qdisc change
sur une interface sans règles donnera l'erreur RTNETLINK answers: No such file or directory
.
tc -p qdisc ls dev eth0
tc qdisc del dev eth0 root
Pour les paquets perdus, j'utiliserais simplement iptables et le module statistique .
iptables -A INPUT -m statistic --mode random --probability 0.01 -j DROP
Ci-dessus supprimera un paquet entrant avec une probabilité de 1%. Soyez prudent, tout ce qui dépasse 0,14 et la plupart d'entre vous, les connexions TCP seront probablement bloquées complètement.
Jetez un oeil à man iptables et recherchez "statistique" pour plus d'informations.
DROP
sur les connexions sortantes, les send()
opérations reviennent plutôt ridiculement EPERM
, plutôt que de simplement supprimer des paquets (comme il se doit).
iptables -D INPUT -m statistic --mode random --probability 0.01 -j DROP
Un de mes collègues utilise tc pour ce faire. Reportez-vous à la page de manuel pour plus d'informations. Vous pouvez voir un exemple de son utilisation ici .
Ce didacticiel sur les simulations physiques de réseau contient une classe C ++ dans l' exemple de code pour simuler la latence et la perte de paquets dans une connexion UDP et peut être utile. Voir les variables de latence publique et packetLoss de la classe Connection trouvées dans le fichier Connection.h du code source téléchargeable .
Je ne l'ai pas essayé moi-même, mais cette page contient une liste de modules d'extension qui fonctionnent dans le système de filtrage IP iptables intégré à Linux. L'un des modules est appelé "nième" et vous permet de mettre en place une règle qui supprimera un taux configurable des paquets. Ce pourrait être un bon point de départ, au moins.
Vous pouvez essayer http://snad.ncsl.nist.gov/nistnet/ C'est un projet NIST assez ancien (dernière version 2005), mais cela fonctionne pour moi.
Saboteur est un outil d'injection de pannes réseau facile à utiliser . Il peut simuler:
- Partition réseau totale
- Service distant mort (pas d'écoute sur le port attendu)
- Retards
- Perte de paquets - Délai d'expiration de la connexion TCP (comme cela arrive souvent lorsque deux systèmes sont séparés par un pare-feu dynamique)
L'un des outils les plus utilisés dans la communauté scientifique à cette fin est DummyNet . Une fois que vous avez installé le ipfw
module du noyau, afin d'introduire un délai de propagation de 50 ms entre 2 machines, exécutez simplement ces commandes:
./ipfw pipe 1 config delay 50ms
./ipfw add 1000 pipe 1 ip from $IP_MACHINE_1 to $IP_MACHINE_2
Afin d'introduire également 50% des pertes de paquets, vous devez exécuter:
./ipfw pipe 1 config plr 0.5
Voici plus de détails.