Speedbump - TCP-Proxy mit Unterstützung für variable Latenz

 (github.com/kffl)
4 Punkte von GN⁺ 2024-01-17 | 1 Kommentare | Auf WhatsApp teilen
  • Ein in Go geschriebener TCP-Proxy, mit dem sich verschiedene variable Netzwerkverzögerungen simulieren lassen

Grundlegende Nutzungsbeispiele

  • Eine neue Instanz erstellen, die auf Port 2000 lauscht, TCP-Traffic an localhost:80 weiterleitet und eine Basislatenz von 100 ms, eine Sinus-Amplitude von 100 ms (maximale zusätzliche Latenz 200 ms, minimale 0) sowie eine Periode von 1 Minute verwendet: 
    speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • Oder Speedbump mit dem Container-Image kffl/speedbump ausführen: 
    docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
  --sine-period=1m --port=2000 localhost:80
  • Eine neue Instanz mit einer Basislatenz von 300 ms erstellen, mit einer Sägezahn-Latenz von 200 ms Amplitude und 2 Minuten Periode, wie in der folgenden Grafik dargestellt: 
    speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80
  • Es ist möglich, mehrere Latenzen gleichzeitig summiert auszuführen.
  • Speedbump kann über das Paket lib als Go-Bibliothek verwendet werden.

Meinung von GN⁺:

  • Speedbump ist ein nützliches Tool zur Simulation von Netzwerklatenz und kann dabei helfen, die Performance netzwerkbasierter Anwendungen zu testen und zu optimieren.
  • Da es in Go geschrieben ist, ist es für Go-Entwickler vertraut und bietet Funktionen, mit denen sich verschiedene Latenzmuster einfach simulieren lassen.
  • Es ist Open Source und steht unter der Apache-2.0-Lizenz, sodass es durch Beiträge der Community kontinuierlich verbessert werden könnte.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-17
Hacker-News-Kommentare
  • Um eine ActivityPub-Implementierung unter verschiedenen Netzwerkgrößen und -bedingungen zu testen, habe ich nach ähnlicher Arbeit gesucht. Ich habe gelernt, wie man mit dem Befehl tc Latenz zu einer bestimmten Schnittstelle hinzufügt, und das funktioniert auch in Docker-Containern gut. Es könnte bereits auf vielen Systemen installiert sein.
    • Beispielbefehl: tc qdisc add dev eth0 root netem delay 100ms
  • Bei Netflix wurde ein Tool entwickelt, das sie „latency monkey“ nennen. Zu erkennen, dass ein Downstream-Service langsamer wird, ist viel schwieriger, als zu erkennen, dass ein Service nicht verfügbar ist. Dieses Tool verwirft Pakete mit einer bestimmten Rate, um Neuübertragungen auszulösen, wodurch Pakete verzögert oder in ihrer Reihenfolge vertauscht werden. Damit wurden viele Probleme im Fehlerbehandlungscode für Netzwerkzugriffe gefunden.
  • Jeder Softwareingenieur, der an Internetanwendungen arbeitet, sollte solche Tools regelmäßig verwenden. Sowohl QUIC als auch TCP sind nötig, und es sollte sämtliches UDP einschließlich DNS abgefangen werden können. Ich bin überzeugt, dass 90 % der Web-Apps verschwinden würden, wenn Entwickler keine High-Performance-Computing-Umgebung nutzen würden.
  • Viele Apps funktionieren bei intermittierender Netzwerkverbindung schlecht. App-Entwickler können anderen helfen, indem sie simulierte intermittierende Konnektivität testen. Vielen Apps fehlt eine „Postausgang“-Funktion wie bei E-Mail-Clients. Es gibt die Frage, wer einen Referenz-Toxiproxy-„Testfall-Mutator“ entwickeln könnte, um typische Verbindungsprobleme in Katastrophenhilfesituationen zu simulieren.
  • Auf dem Mac kann man mit integrierten Tools etwas Ähnliches tun. Es werden Beispielbefehle genannt, um die Geschwindigkeit einer Netzwerkverbindung zu simulieren.
  • Als ich auf dem Mac ein langsames Netzwerk simulieren wollte, bin ich auf Network Link Conditioner gestoßen. Es lässt sich ohne Proxy-Einstellungen oder andere Konfiguration verwenden und muss über die zusätzlichen Xcode-Tools installiert werden.
  • Ich bin schon lange nicht mehr aktiv, aber der Name „comcast“ sagt schon vieles.
  • Ein ähnliches Tool, das ich unter Windows verwendet habe, heißt „clumsy“.
  • Auch FreeBSD hat mit „dummynet“ eine Funktion, mit der sich als Teil von ipfw Latenz, Bandbreitenbegrenzung, Queue-Größe und Paketverlust injizieren lassen. Das ist dieselbe Art von Funktion wie unter macOS.
  • Ich werde nie vergessen, wie mein Manager in meinem ersten Job eine FreeBSD-IPFW-Firewall so konfiguriert hat, dass ICMP-Antworten verlangsamt wurden. Jedes Mal, wenn jemand einen Ping schickte, sah die Antwortzeit am höchsten aus. Dieser Manager war ein Spaßvogel.