Speedbump - Değişken gecikme destekli TCP proxy

 (github.com/kffl)
4 puan yazan GN⁺ 2024-01-17 | 1 yorum | WhatsApp'ta paylaş
  • Speedbump, Go ile yazılmış bir TCP proxy’dir; proxy’den geçen TCP trafiğine değişken ağ gecikmesi ekleyerek gecikme senaryolarını simüle eder
  • Temel gecikmeye sinüs dalgası, testere dişi dalga, kare dalga, üçgen dalga biçiminde gecikme bileşenleri eklenebilir; birden çok gecikme bileşeni aynı anda birleştirilebilir
  • Örnek, localhost:80 hedefli trafiği 2000 portunda proxy’lerken 100ms temel gecikme, 100ms sinüs dalgası genliği ve 1m periyodu uygulayan bir yapılandırmayı gösterir
  • Kurulum; sürümlere göre önceden derlenmiş ikili dosyayı indirme, kaynaktan go build ile derleme veya kffl/speedbump konteyner imajını çalıştırma yoluyla yapılabilir
  • CLI dışında Go’nun lib paketi üzerinden kütüphane olarak da kullanılabilir; tampon boyutu, gecikme kuyruğu boyutu, günlük seviyesi, dinleme host’u ve portu gibi değerler argümanlarla ayarlanabilir

TCP gecikme simülasyonu için proxy

  • Speedbump, Go ile yazılmış bir TCP proxy’dir ve değişken ağ gecikmesini simüle edebilir
  • Proxy hedefi CLI’daki <destination> argümanıyla belirtilir; biçim host:post olarak gösterilmiştir
  • Temel çalışma şekli, TCP trafiğini hedefe proxy’lerken yapılandırılan gecikmeyi eklemektir

Kurulum ve çalıştırma yöntemleri

  • En kolay kurulum yöntemi, her release için Assets bölümüne otomatik eklenen önceden derlenmiş ikili dosyayı indirmektir
  • Kaynaktan derlemek için depoyu klonladıktan sonra go build çalıştırılır
  • Konteyner olarak çalıştırmak için kffl/speedbump imajı kullanılabilir

Temel kullanım örneği

  • 2000 portunda dinleyip TCP trafiğini localhost:80 adresine proxy’lerken 100ms temel gecikme, 100ms sinüs dalgası genliği ve 1m periyodu uygulanabilir
    • Bu yapılandırma en fazla 200ms, en az 0 ek gecikme oluşturur
    • Çalıştırma örneği: speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • Aynı yapılandırma konteyner imajıyla da çalıştırılabilir
    • Örnek: docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • Testere dişi dalga gecikme bileşeni de ayarlanabilir
    • Örnek; 300ms temel gecikme, 200ms testere dişi dalga genliği, 2m periyot, 2000 portu ve localhost:80 hedefinden oluşan bir yapılandırmadır
    • Çalıştırma komutu: speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80

Gecikme bileşenlerini birleştirme

  • Speedbump, birden çok gecikme bileşenini aynı anda uygulayabilir
  • README, testere dişi dalga ile sinüs dalgasını birleştiren gecikme grafiği örneği içerir

CLI argümanları ve kütüphane olarak kullanım

  • speedbump --help, speedbump [<flags>] <destination> biçiminde kullanım bilgisi sunar
  • Başlıca ağ ayarları şöyledir
    • --host: Dinlenecek IP veya host adı; belirtilmezse tüm ağ arayüzlerine bağlanır
    • --port: Dinleme portu; varsayılan değer 8000’dir
    • --buffer: TCP okumada kullanılan tampon boyutu; varsayılan değer 64KB’dir
    • --queue-size: Okuma tamponlarını saklayan gecikme kuyruğu boyutu; varsayılan değer 1024’tür
  • Gecikmeyle ilgili varsayılanlar ve dalga biçimi seçenekleri sunar
    • --latency: Proxy trafiğine eklenen temel gecikme; varsayılan değer 5ms’dir
    • --sine-amplitude, --sine-period: Sinüs dalgası gecikme genliği ve periyodu
    • --saw-amplitude, --saw-period: Testere dişi dalga gecikme genliği ve periyodu
    • --square-amplitude, --square-period: Kare dalga gecikme genliği ve periyodu
    • --triangle-amplitude, --triangle-period: Üçgen dalga gecikme genliği ve periyodu
  • Operasyonla ilgili seçenekler de bulunur
    • --log-level: Günlük seviyesi; olası değerler DEBUG, TRACE, INFO, WARN, ERROR
    • --version: Uygulama sürümünü gösterir
  • Speedbump, Go kütüphanesi olarak da kullanılabilir ve lib paketi üzerinden sunulur
  • Lisansı Apache 2.0 License’tır

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-17
Hacker News yorumları

  • Çeşitli ActivityPub uygulamalarını farklı ağ ölçekleri ve koşullarında test etmek için benzer bir şey araştırmıştım; meğer makinemde ihtiyaç duyduğum her şey tc ile zaten kuruluymuş
    Benim dağıtımımda iproute2 paketinin içindeydi; açıklaması burada da var: https://wiki.archlinux.org/title/advanced_traffic_control
    Belirli bir arayüze gecikme eklemek için tc qdisc add dev eth0 root netem delay 100ms gibi çalıştırabilirsiniz
    Kullanımı kolay, Docker container'larında da iyi çalışıyor; gecikme, paket kaybı, yineleme gibi koşulları uygulayabiliyor ve muhtemelen zaten kurulu olabilir

    • tc/netem/tbf gerçekten çok iyi. Bunun üzerine basit bir Python GUI yaptım ve dokunmatik ekranlı bir kasaya yerleştirilmiş Pi üzerinde çalıştırdım; “Paket düşürme: [0%] [1%] [10%] [50%] / Paket bozulması: ...” gibi küçük siyah bir kutuydu ve müşteriler epey etkilenmişti
      Benzer bir ön yüzün ticari donanım ürünü olarak pek görünmemesi şaşırtıcı; aramalarda kaçırmadıysam piyasada yok gibi
    • tcnin dezavantajı, gelen paketlere uygulamak istediğinizde biraz tuhaf ve zahmetli olması
      Bir zamanlar belirli bir ticari uydu terminalini taklit etmek için kendi emülatörümü yapmıştım. Bu terminal paketleri kuyruğa alıyor, belirli bir eşiğe ulaştığında veya zaman aşımını geçtiğinde hepsini bir blok halinde dışarı fırlatıyordu; küçük paketleri “nazikçe” kuyruğun önüne yeniden sıralayıp gecikmeyi azaltmaya çalışıyordu ama TCP yığını bundan hiç hoşlanmıyordu
    • speedbump'ın iyi tarafı arıza koşullarını zaman içinde ayarlayabilmesi. tc bunu yapamıyor
      Zamanla değişen uydu/RF hava etkilerini simüle etmek için oldukça kullanışlı olabilir

  • Netflix'in yaptığı şey tam olarak buydu; adı latency monkey idi
    Alt hizmetin “yavaş” olup olmadığını belirlemenin “kullanılamaz” olup olmadığını belirlemekten çok daha zor olduğunu öğrendik; bu yüzden hizmet yavaşlamasını ve ağ sorunlarını nasıl ele aldığını test etmenin önemli bir yoluydu
    Uygulaması çok basitti: yapılandırılabilir bir oranla paketleri düşürüyordu; bu da yeniden iletimi zorunlu kılıyor, karşı tarafa paketlerin gecikmeli ve sırası karışmış şekilde ulaşmasına neden oluyordu
    Sonuçta ağ erişimiyle ilgili hata işleme kodunda birçok sorun bulduk

  • Etkileşimli internet uygulamaları geliştiren her yazılım mühendisi, günlük işinde mutlaka böyle araçlar kullanmalı diye düşünüyorum. Yalnızca TCP değil, QUIC de gerekli; DNS'i de yakalamak için ideal olarak tüm UDP de dahil olmalı
    Bunları geliştirenler yalnızca altın kaplama Cadillac gibi bilgi işlem ortamları kullanmasaydı, web uygulaması şişkinliğinin %90'ının ortadan kalkacağına eminim

  • Afet yardımı gibi ağ bağlantısının aralıklı olarak koptuğu ortamlarda birçok uygulama berbat çalışıyor
    Daha fazla uygulama geliştiricisi aralıklı bağlantıyı simüle edip test etse başkalarına faydası olabilir
    “Toxiproxy is a framework for simulating network conditions” (2021) https://news.ycombinator.com/item?id=29084277#29088775 başlığında geçenler:

    Birçok uygulamada, örneğin bir e-posta istemcisinden beklediğiniz ‘giden kutusunda beklet’ işlevi yok

    • [ ] Genel #DisasterRelief bağlantı sorunlarını simüle eden referans bir toxiproxy ‘test vakası mutatörü’ setini kim yapabilir?
    • En nefret ettiğim şey, paket göndermeden önce buffer'ı doldurmamaları. Böyle olunca kötü bir internet bağlantısında, yani paket düşmesi ve yüksek gecikme yüzünden TCP yeniden iletimlerinin olduğu bir ortamda, bir anda yalnızca 120 kps alıyorsunuz
      Çünkü sadece 50 baytlık paketler gönderiyorsunuz ve bunların 10'da 1'i kayboluyor. Bu sırada sunucudaki bir thread işe yarar hiçbir şey yapamıyor

  • Mac'te yerleşik araçlarla da aynı şeyi yapabilirsiniz

    # Setup pipe  
sudo dnctl pipe 1 config bw 1Kbit/s delay 800

# Setup matching pf rule  
echo "dummynet out proto tcp from any to 127.0.0.1 port 11211 pipe 1" | sudo pfctl -f -

# Turn on firewall  
sudo pfctl -e

# Test  
time nc -vz 127.0.0.1 11211  
Connection to 127.0.0.1 port 11211 [tcp/*] succeeded!  
nc -vz 127.0.0.1 11211 0.01s user 0.00s system 0% cpu 1.333 total
    • Dummynet ve bu özellikler FreeBSD'den geliyor; orada uzun zamandır var. 15 yıldan da uzun süre önce bununla paket kaybı testi yapmıştım ve iyi çalışmıştı

  • Bir süredir pasif olan ama adı tek başına çok şey anlatan bir proje var: https://github.com/tylertreat/comcast

  • Yakın zamanda Mac'te yavaş ağı simüle etmeye çalışırken Network Link Conditioner'ı buldum; oldukça iyi. Proxy gibi bir şey ayarlamaya gerek yok
    Xcode ek araçlarından kurulması gerekiyor
    https://nshipster.com/network-link-conditioner/

  • Shopify'ın harika aracı toxiproxy de bakmaya değer: https://github.com/Shopify/toxiproxy
    Ağ kütüphanesini bizzat geliştirip test etmek için de çok iyi bir yöntem. Çünkü yığının olumsuz durumların çoğunu düzgün şekilde ele alabilmesi gerekir
    ‘Kaos mühendisliği’ fikri güzel

    • Ben de başta toxiproxy aramıştım ama istemci-sunucu modeli bana uymadı; speedbump ise HTTP gecikmesi simülasyonu olan kullanımım için tam uygundu
      Bir web crawler için ilerleme çubuğu geliştiriyorum; localhost'ta test edince çok hızlı olduğu için bir sorun olup olmadığını anlamak zorlaşıyor
      speedbump ile sadece podman run --net=host kffl/speedbump:latest --latency=1s --port=8001 localhost:8000 çalıştırıp crawler'ı http://localhost:8001 üzerinden test etmek yeterli
      Temiz bir araç

  • Windows'ta kullandığım benzer bir araç var
    https://jagt.github.io/clumsy/

    • Yaklaşık 10 yıl önce çeşitli kıtalararası ağ koşullarını test etmek için kullandım; sonuçlar gerçekle iyi örtüşüyordu. Tavsiye edilir
    • Güzel görünüyor ama ekran görüntülerine bakınca adaptör bazında uygulamadan çok, filtreli sistem geneli uygulama gibi görünüyor

  • FreeBSD'de de ipfw'nin parçası olarak dummynet var; gecikme, bant genişliği sınırlaması, kuyruk boyutu ve paket kaybı enjekte edebiliyor. MacOS'takiyle aynı işlev

    • Linux'taki tc ile aynı şey mi?