Speedbump - Proksi TCP dengan dukungan latensi variabel

 (github.com/kffl)
4 poin oleh GN⁺ 2024-01-17 | 1 komentar | Bagikan ke WhatsApp
  • Speedbump adalah proksi TCP yang ditulis dalam Go, yang mensimulasikan kondisi keterlambatan dengan menambahkan latensi jaringan variabel pada traffic TCP yang diproksikan
  • Komponen latensi berbentuk gelombang sinus, gelombang gigi gergaji, gelombang persegi, dan gelombang segitiga dapat ditambahkan ke latensi dasar, dan beberapa komponen latensi dapat dikombinasikan secara bersamaan
  • Contohnya menunjukkan konfigurasi yang memproksikan traffic menuju localhost:80 dari port 2000 sambil menerapkan delay dasar 100ms, amplitudo sinus 100ms, dan periode 1m
  • Instalasi dapat dilakukan dengan mengunduh binary pra-build per rilis, menjalankan go build dari source, atau menjalankan container image kffl/speedbump
  • Selain CLI, Speedbump juga dapat digunakan sebagai library melalui paket lib Go, dengan argumen untuk menyesuaikan ukuran buffer, ukuran antrean delay, level log, host dan port listening, dan lainnya

Proksi untuk simulasi delay TCP

  • Speedbump adalah proksi TCP yang ditulis dalam Go dan dapat mensimulasikan latensi jaringan variabel
  • Target proksi ditentukan dengan argumen <destination> pada CLI, dengan format yang dijelaskan sebagai host:post
  • Perilaku dasarnya adalah memproksikan traffic TCP ke tujuan sambil menambahkan delay yang dikonfigurasi

Cara instalasi dan menjalankan

  • Cara instalasi termudah adalah mengunduh binary pra-build yang otomatis dilampirkan di Assets pada setiap release
  • Untuk build dari source, clone repository lalu jalankan go build
  • Untuk menjalankannya sebagai container, gunakan image kffl/speedbump

Contoh penggunaan dasar

  • Anda dapat listening di port 2000, memproksikan traffic TCP ke localhost:80, dan menerapkan delay dasar 100ms serta amplitudo sinus 100ms dengan periode 1m
    • Konfigurasi ini menghasilkan latensi tambahan maksimum 200ms dan latensi tambahan minimum 0
    • Contoh eksekusinya adalah speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • Konfigurasi yang sama juga dapat dijalankan dengan container image
    • Contohnya adalah docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • Komponen delay gelombang gigi gergaji juga dapat dikonfigurasi
    • Contohnya adalah konfigurasi dengan delay dasar 300ms, amplitudo gelombang gigi gergaji 200ms, periode 2m, port 2000, dan tujuan localhost:80
    • Perintah eksekusinya adalah speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80

Kombinasi komponen latensi

  • Speedbump dapat menerapkan beberapa komponen latensi secara bersamaan
  • README menyertakan contoh grafik delay yang mengombinasikan gelombang gigi gergaji dan gelombang sinus

Argumen CLI dan penggunaan sebagai library

  • speedbump --help menyediakan cara penggunaan dalam format speedbump [<flags>] <destination>
  • Pengaturan jaringan utama adalah sebagai berikut
    • --host: IP atau hostname untuk listening; jika tidak ditentukan, akan bind ke semua interface jaringan
    • --port: port listening, dengan nilai default 8000
    • --buffer: ukuran buffer yang digunakan untuk membaca TCP, dengan nilai default 64KB
    • --queue-size: ukuran antrean delay untuk menyimpan buffer baca, dengan nilai default 1024
  • Menyediakan nilai default terkait delay dan opsi waveform
    • --latency: latensi dasar yang ditambahkan ke traffic proksi, dengan nilai default 5ms
    • --sine-amplitude, --sine-period: amplitudo dan periode latensi gelombang sinus
    • --saw-amplitude, --saw-period: amplitudo dan periode latensi gelombang gigi gergaji
    • --square-amplitude, --square-period: amplitudo dan periode latensi gelombang persegi
    • --triangle-amplitude, --triangle-period: amplitudo dan periode latensi gelombang segitiga
  • Opsi terkait operasional juga disertakan
    • --log-level: level log; nilai yang mungkin adalah DEBUG, TRACE, INFO, WARN, ERROR
    • --version: menampilkan versi aplikasi
  • Speedbump juga dapat digunakan sebagai library Go, yang disediakan melalui paket lib
  • Lisensinya adalah Apache 2.0 License

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-17
Opini Hacker News

  • Saya sempat mencari sesuatu yang mirip untuk menguji berbagai implementasi ActivityPub pada beragam skala dan kondisi jaringan, tetapi ternyata semua yang saya butuhkan sudah terpasang di mesin saya lewat tc
    Di distro saya, itu termasuk dalam paket iproute2, dan penjelasannya juga ada di sini: https://wiki.archlinux.org/title/advanced_traffic_control
    Untuk menambahkan latensi pada antarmuka tertentu, jalankan seperti tc qdisc add dev eth0 root netem delay 100ms
    Mudah dipakai, bekerja baik di container Docker, bisa menerapkan kondisi seperti latensi, packet loss, dan duplikasi, serta kemungkinan sudah terpasang

    • tc/netem/tbf benar-benar bagus. Saya membuat GUI Python sederhana di atasnya dan menjalankannya di Pi yang dimasukkan ke casing layar sentuh; bentuknya seperti kotak hitam kecil dengan “packet drop: [0%] [1%] [10%] [50%] / packet corruption: ...”, dan pelanggan cukup terkesan
      Saya agak heran frontend semacam itu tidak banyak terlihat sebagai produk hardware komersial; kalau saya tidak melewatkannya dalam pencarian, sepertinya memang belum ada di pasar
    • Kekurangan tc adalah penerapannya pada paket masuk agak aneh dan merepotkan
      Dulu saya pernah membuat emulator sendiri untuk meniru terminal satelit komersial tertentu. Terminal itu menumpuk paket dalam antrean lalu, ketika ambang tertentu tercapai atau batas waktu terlewati, mengeluarkannya sekaligus dalam satu burst; ia juga “berbaik hati” mengurutkan ulang paket kecil ke bagian depan antrean untuk mengurangi latensi, tetapi stack TCP sangat tidak menyukainya
    • Hal bagus dari speedbump adalah kondisi gangguan bisa disesuaikan seiring waktu. tc tidak bisa melakukan itu
      Ini bisa sangat berguna untuk mensimulasikan pengaruh cuaca pada satelit/RF yang berubah dari waktu ke waktu

  • Yang dibuat Netflix persis seperti ini, namanya latency monkey
    Mereka menyadari bahwa menentukan apakah layanan downstream “lambat” jauh lebih sulit daripada menentukan apakah layanan itu “tidak tersedia”, sehingga ini menjadi cara penting untuk menguji bagaimana layanan menangani perlambatan dan masalah jaringan
    Implementasinya sangat sederhana: menjatuhkan paket dengan rasio yang bisa dikonfigurasi, sehingga retransmisi dipaksa dan di sisi lawan paket tiba terlambat serta tidak berurutan
    Pada akhirnya, banyak masalah ditemukan pada kode penanganan error terkait akses jaringan

  • Menurut saya setiap software engineer yang membuat aplikasi internet interaktif wajib menggunakan alat seperti ini dalam pekerjaan sehari-hari. Bukan hanya TCP, tetapi juga QUIC, dan idealnya semua UDP juga perlu dicakup jika ingin menangani DNS
    Saya yakin 90% pembengkakan web app akan hilang seandainya para pembuatnya tidak hanya memakai lingkungan komputasi ala Cadillac berlapis emas

  • Dalam lingkungan dengan koneksi jaringan yang terputus-putus, seperti situasi bantuan bencana, banyak aplikasi berperilaku sangat buruk
    Jika lebih banyak pengembang aplikasi menguji dengan mensimulasikan koneksi terputus-putus, itu bisa membantu orang lain
    Dari “Toxiproxy is a framework for simulating network conditions” (2021) https://news.ycombinator.com/item?id=29084277#29088775:

    Banyak aplikasi tidak memiliki fitur ‘tahan di outbox’ seperti yang kita harapkan dari, misalnya, klien email

    • [ ] Bisakah seseorang membuat sekumpulan ‘mutator test case’ toxiproxy referensi yang mensimulasikan masalah konektivitas #DisasterRelief yang umum?
    • Yang paling saya benci adalah ketika aplikasi tidak mengisi buffer sebelum mengirim paket. Akibatnya, pada koneksi internet buruk—yaitu lingkungan dengan packet drop dan latensi tinggi yang memicu retransmisi TCP—throughput tiba-tiba hanya 120 kps
      Karena yang dikirim hanya paket 50 byte, dan 1 dari 10 paket itu hilang. Sementara itu, satu thread di server tidak melakukan pekerjaan yang berguna

  • Di Mac, hal yang sama bisa dilakukan hanya dengan tool bawaan

    # 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 dan fitur-fitur ini berasal dari FreeBSD, dan sudah lama ada di sana. Lebih dari 15 tahun lalu saya memakainya untuk pengujian packet loss dan itu bekerja dengan baik

  • Ada proyek yang sudah tidak aktif cukup lama, tetapi namanya saja sudah menjelaskan banyak hal: https://github.com/tylertreat/comcast

  • Baru-baru ini saya mencoba mensimulasikan jaringan lambat di Mac dan menemukan Network Link Conditioner; cukup bagus. Tidak perlu menyiapkan semacam proxy
    Harus dipasang dari alat tambahan Xcode
    https://nshipster.com/network-link-conditioner/

  • Tool hebat dari Shopify, toxiproxy, juga layak dilihat: https://github.com/Shopify/toxiproxy
    Ini juga cara yang sangat baik untuk menguji implementasi library networking buatan sendiri, karena stack harus mampu menangani sebagian besar kondisi buruk dengan benar
    Gagasan ‘chaos engineering’ memang keren

    • Awalnya saya juga mencari toxiproxy, tetapi model client-server-nya tidak cocok untuk saya, sementara speedbump pas sekali untuk kebutuhan saya mensimulasikan latensi HTTP
      Saya sedang mengembangkan progress bar untuk web crawler, dan saat dites di localhost terlalu cepat sehingga sulit mengetahui apakah ada masalah
      Dengan speedbump, cukup jalankan podman run --net=host kffl/speedbump:latest --latency=1s --port=8001 localhost:8000 lalu uji crawler di http://localhost:8001
      Tool yang rapi

  • Ada tool serupa yang pernah saya pakai di Windows
    https://jagt.github.io/clumsy/

    • Sekitar 10 tahun lalu saya memakainya untuk menguji berbagai kondisi jaringan antarbenua, dan hasilnya cukup sesuai dengan kenyataan. Layak direkomendasikan
    • Terlihat keren, tetapi dari screenshot saja kelihatannya ini berlaku ke seluruh sistem dengan filter, bukan diterapkan per adaptor

  • FreeBSD juga punya dummynet sebagai bagian dari ipfw, yang bisa menyuntikkan latensi, pembatasan bandwidth, ukuran antrean, dan packet loss. Ini fitur yang sama dengan yang ada di MacOS

    • Apakah itu sama seperti tc di Linux?