289 votes

Simuler des paquets retardés et abandonnés sous Linux

Je voudrais simuler le retard et la perte de paquets pour UDP et TCP sur Linux pour mesurer les performances d'une application. Existe-t-il un moyen simple de le faire ?

0 votes

1 votes

368voto

ephemient Points 87003

netem exploite les fonctionnalités déjà intégrées à Linux et aux utilitaires de l'espace utilisateur pour simuler des réseaux. C'est en fait ce à quoi la réponse de Mark fait référence, sous un autre nom.

Les exemples sur leur page d'accueil montrent déjà comment vous pouvez obtenir ce que vous avez demandé :

Exemples

Emulation des délais du réseau étendu

C'est l'exemple le plus simple, il ajoute simplement une quantité fixe de retard à tous les paquets sortant de l'Ethernet local.

# tc qdisc add dev eth0 root netem delay 100ms

Maintenant, un simple test ping vers un hôte sur le réseau local devrait montrer une augmentation de 100 millisecondes. Le délai est limité par la résolution de l'horloge du noyau (Hz). Sur la plupart des systèmes 2.4, l'horloge système fonctionne à 100 Hz, ce qui permet des délais 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 permettent de modifier 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

Le délai supplémentaire est donc de 100 ± 10 ms. La variation du délai du réseau n'est pas purement aléatoire, donc pour émuler cela, il y a aussi une valeur de corrélation.

# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%

Le délai supplémentaire est donc de 100 ± 10 ms, l'élément aléatoire suivant dépendant à 25 % du précédent. Ce n'est pas une vraie corrélation statistique, mais une approximation.

Distribution des retards

En général, 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 délai. 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 d'iproute2 et placées dans /usr/lib/tc ; il est donc possible, moyennant quelques efforts, de créer votre propre distribution basée sur des données expérimentales.

Perte de paquets

La perte aléatoire de paquets 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 entraîne l'abandon aléatoire de 1/10e de pourcentage (c'est-à-dire 1 sur 1000) de paquets.

Une corrélation facultative peut également être ajoutée. Cela rend le générateur de nombres aléatoires moins aléatoire et peut être utilisé pour émuler des pertes de paquets en rafale.

# tc qdisc change dev eth0 root netem loss 0.3% 25%

Ainsi, 0,3% des paquets seront perdus, et chaque probabilité successive dépend d'un quart de la dernière.

Probabilité n \= 0,25 × Prob n-1 + 0,75 × aléatoire

Notez que vous devez 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. Si vous essayez d'utiliser tc qdisc change sur une interface sans règles donnera une erreur RTNETLINK answers: No such file or directory .

2 votes

Le site original a cette erreur, j'ai juste copié ce texte directement. Mais oui, 2^(-32)=2.33e-10

44 votes

Notez que tc -p qdisc ls dev eth0 listera les règles définies actuelles, et tc qdisc del dev eth0 root les supprimera

1 votes

Upvoted pour avoir signalé l'erreur lorsqu'on essaie de modifier une entrée non existante

110voto

Pour les paquets abandonnés, j'utiliserais simplement iptables et le module statistique.

iptables -A INPUT -m statistic --mode random --probability 0.01 -j DROP

Ci-dessus, un paquet entrant sera abandonné avec une probabilité de 1%. Soyez prudent, tout ce qui est supérieur à 0.14 et la plupart de vos connexions tcp vont probablement se bloquer complètement.

Consultez man iptables et recherchez "statistic" pour plus d'informations.

7 votes

Pourquoi les connexions TCP se bloquent-elles à plus de 14 % ?

3 votes

@DavidWolever : A cause de la façon dont la taille de tcp sliding Windows est ajustée. Mais le 14% est purement par expérience, faites un essai vous-même et vous verrez que ssh devient pratiquement inutilisable à 14% et plus, mais fonctionne en fait assez bien à des niveaux inférieurs de taux de chute de paquets.

18 votes

Par sécurité, il est probablement préférable de limiter la règle pour qu'elle s'applique uniquement au(x) port(s) que vous souhaitez tester : iptables -A INPUT --dport FOO -m statistics .... De cette façon, vos connexions ssh et autres ne seront pas perturbées et vous pourrez augmenter le taux de chute du service concerné afin de pouvoir reproduire plus rapidement les problèmes qu'il rencontre.

6voto

hillu Points 4033

Iptables(8) possède un module de statistiques qui peut être utilisé pour faire correspondre chaque nième paquet. Pour abandonner ce paquet, il suffit d'ajouter -j DROP .

6voto

Mark Points 14208

Un de mes collègues utilise tc pour faire cela. Reportez-vous à la page de manuel pour plus d'informations. Vous pouvez voir un exemple de son utilisation ici .

0 votes

Je pense qu'il est plus facile d'utiliser iptables :)

1 votes

Bien sûr, mais tc est beaucoup plus rapide qu'iptables

3voto

Judge Maygarden Points 14964

Ce site tutoriel sur les simulations de physique en réseau contient une classe C++ dans le exemple de code pour simuler la latence et la perte de paquets dans une connexion UDP et peut être utile. Voir le site public latence et perte de paquets les variables de l Connexion qui se trouve dans le Connexion.h du fichier code source téléchargeable .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X