Speedbump - Değişken gecikmeyi destekleyen TCP proxy

• Go diliyle yazılmış bir TCP proxy'si; çeşitli değişken ağ gecikmelerini simüle edebilir

Temel kullanım örnekleri

• 2000 portunda dinleyen yeni bir örnek oluşturup TCP trafiğini localhost:80'e proxy'lemek; varsayılan gecikme 100ms, sinüs dalgası genliği 100ms (maksimum ek gecikme 200ms, minimum 0) ve periyot 1 dakika olacak şekilde:

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

• Ya da speedbump'ı kffl/speedbump container image'ı ile çalıştırırken:

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

• Varsayılan gecikmesi 300ms olan ve aşağıdaki grafikte gösterildiği gibi genliği 200ms, periyodu 2 dakika olan testere dişi dalga gecikmesine sahip yeni bir örnek oluşturmak için:

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

• Birden fazla gecikme toplamını aynı anda çalıştırmak mümkündür.
• Speedbump, lib paketi aracılığıyla bir Go kütüphanesi olarak kullanılabilir.

---

GN⁺ görüşü:

• Speedbump, ağ gecikmesini simüle etmek için kullanışlı bir araç; ağ tabanlı uygulamaların performansını test etmeye ve optimize etmeye yardımcı olabilir.
• Go diliyle yazıldığı için Go geliştiricilerine tanıdık gelir ve çeşitli gecikme kalıplarını kolayca simüle etmeyi sağlayan özellikler sunar.
• Açık kaynaklıdır ve Apache 2.0 lisansı altında sunulduğundan, topluluk katkılarıyla sürekli geliştirilme potansiyeline sahiptir.

[GN⁺]

Hacker News görüşleri

• ActivityPub uygulamasını çeşitli ağ boyutları ve koşullarında test etmek için benzer çalışmaları araştırdım. Belirli bir arayüze gecikme eklemek için tc komutunu kullanmayı öğrendim ve bu Docker container'larında da gayet iyi çalışıyor. Zaten birçok sistemde kurulu olabilir.
  • Örnek komut: tc qdisc add dev eth0 root netem delay 100ms
• Netflix'te "latency monkey" dedikleri bir araç geliştirdik. Aşağı akış hizmetlerinin yavaşladığını tespit etmek, hizmet kullanılamaz hale geldiğinde bunu fark etmekten çok daha zor. Bu araç, yeniden iletimi tetiklemek için paketleri belli bir oranda düşürüyor; bunun sonucunda paketler gecikiyor ya da sıraları karışıyor. Ağ erişimine yönelik hata işleme kodunda çok sayıda sorun bulduk.
• İnternet uygulamaları üzerinde çalışan her yazılım mühendisi, bunun gibi araçları günlük olarak kullanmalı. Hem QUIC hem de TCP gerekli ve DNS dahil tüm UDP trafiğini yakalayabilmeli. Geliştiriciler yüksek performanslı bilgi işlem ortamı kullanmıyorsa web uygulamalarının %90'ının ortadan kalkacağına eminim.
• Birçok uygulama, kesintili ağ bağlantısında kötü performans gösteriyor. Uygulama geliştiricileri, simüle edilmiş kesintili bağlantıyı test ederek başkalarına yardımcı olabilir. Birçok uygulamada, e-posta istemcilerindeki gibi bir "giden kutusu" özelliği eksik. Afet yardımı senaryolarında yaygın bağlantı sorunlarını simüle etmek için bir referans toxiproxy "test case mutator"ı kimin geliştirebileceği soruluyor.
• Mac'te yerleşik araçlarla benzer şeyler yapılabiliyor. Ağ bağlantı hızını simüle etmek için örnek komutlar verilmiş.
• Mac'te yavaş ağı simüle etmek istediğimde Network Link Conditioner'ı keşfettim. Proxy ayarı ya da başka ayarlar gerektirmeden kullanılabiliyor; Xcode ek araçlarından kurulması gerekiyor.
• Uzun zamandır aktif değilim ama "comcast" adı tek başına çok şey anlatıyor.
• Windows'ta kullandığım benzer bir araç da "clumsy".
• FreeBSD'de de dummynet adlı bir özellik var; ipfw'nin bir parçası olarak gecikme, bant genişliği sınırlaması, kuyruk boyutu ve paket kaybı enjekte edebiliyor. MacOS'taki işleve benziyor.
• İlk işimde yöneticimin FreeBSD IPFW firewall'unu yapılandırıp ICMP yanıtlarını yavaşlattığını hiç unutamam. Biri her ping attığında yanıt süresi en yüksek görünürdü. O yönetici tam bir şakacıydı.