Speedbump - un proxy TCP prenant en charge une latence variable

• Un proxy TCP écrit en Go, capable de simuler diverses latences réseau variables

Exemples d’utilisation de base

• Créer une nouvelle instance écoutant sur le port 2000 pour proxifier le trafic TCP vers localhost:80, avec une latence de base de 100 ms, une amplitude sinusoïdale de 100 ms (latence supplémentaire maximale de 200 ms, minimale de 0) et une période d’1 minute :

  speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80  
  

• Ou lors de l’exécution de speedbump avec l’image de conteneur kffl/speedbump :

  docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
    --sine-period=1m --port=2000 localhost:80  
  

• Créer une nouvelle instance avec une latence de base de 300 ms, et une latence en dent de scie d’amplitude 200 ms et de période 2 minutes, comme montré dans le graphique ci-dessous :

  speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80  
  

• Il est possible d’exécuter simultanément l’addition de plusieurs latences.
• Speedbump peut être utilisé comme bibliothèque Go via le package lib.

---

Avis de GN⁺ :

• Speedbump est un outil utile pour simuler la latence réseau, et peut aider à tester et optimiser les performances des applications basées sur le réseau.
• Écrit en Go, il est familier aux développeurs Go et offre des fonctionnalités permettant de simuler facilement divers schémas de latence.
• C’est un projet open source sous licence Apache 2.0, avec un potentiel d’amélioration continue grâce aux contributions de la communauté.

[GN⁺]

Avis sur Hacker News

• En cherchant des travaux similaires pour tester une implémentation d’ActivityPub dans différentes tailles et conditions de réseau, j’ai appris à utiliser la commande tc pour ajouter de la latence à une interface donnée, et cela fonctionne aussi très bien dans des conteneurs Docker. Il est possible qu’elle soit déjà installée sur de nombreux systèmes.
  • Exemple de commande : tc qdisc add dev eth0 root netem delay 100ms
• Chez Netflix, ils ont développé un outil appelé « latency monkey ». Détecter le fait qu’un service en aval ralentit est bien plus difficile que de détecter qu’il est indisponible. Cet outil laisse tomber des paquets selon un certain pourcentage afin de provoquer des retransmissions, ce qui entraîne des retards de paquets ou un ordre inversé. Cela a permis de découvrir de nombreux problèmes dans le code de gestion d’erreurs lié à l’accès réseau.
• Tous les ingénieurs logiciel qui travaillent sur des applications Internet devraient utiliser ce type d’outils au quotidien. Il faut à la fois QUIC et TCP, et il devrait être possible d’intercepter tout l’UDP, y compris le DNS. Je suis convaincu que 90 % des web apps disparaîtraient si les développeurs n’utilisaient pas des environnements de calcul haute performance.
• Beaucoup d’applications se dégradent lorsque la connectivité réseau est intermittente. Les développeurs d’apps peuvent aider les autres en testant une connectivité intermittente simulée. Beaucoup d’apps n’ont pas de fonction de type « boîte d’envoi » comme les clients email. Il y a une question sur qui pourrait développer, pour toxiproxy, un « mutateur de cas de test » de référence afin de simuler les problèmes de connectivité courants dans les situations de secours en cas de catastrophe.
• Sur Mac, on peut faire quelque chose de similaire avec les outils intégrés. Un exemple de commande permettant de simuler la vitesse d’une connexion réseau est donné.
• En voulant simuler un réseau lent sur Mac, j’ai découvert Network Link Conditioner. On peut l’utiliser sans configuration de proxy ni autres réglages, mais il faut l’installer depuis les outils additionnels de Xcode.
• Cela fait longtemps que je n’y ai pas touché, mais le nom « comcast » en dit long.
• Un outil similaire que j’ai utilisé sous Windows s’appelle « clumsy ».
• FreeBSD dispose aussi d’une fonctionnalité appelée « dummynet », qui permet, dans le cadre d’ipfw, d’injecter de la latence, des limitations de bande passante, une taille de file d’attente et des pertes de paquets. C’est la même fonctionnalité que sur MacOS.
• Je n’oublierai jamais qu’à mon premier emploi, mon manager avait configuré le pare-feu FreeBSD IPFW pour ralentir les réponses ICMP. Chaque fois que quelqu’un envoyait un ping, le temps de réponse paraissait maximal. Ce manager était un sacré farceur.