Speedbump - proksi TCP dengan dukungan latensi variabel

• Proksi TCP yang ditulis dalam bahasa Go, dapat mensimulasikan berbagai latensi jaringan variabel

Contoh penggunaan dasar

• Membuat instans baru yang mendengarkan di port 2000 untuk memproksikan lalu lintas TCP ke localhost:80, dengan latensi dasar 100ms, amplitudo gelombang sinus 100ms (latensi tambahan maksimum 200ms, minimum 0), dan periode 1 menit:

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

• Atau saat menjalankan speedbump menggunakan image container kffl/speedbump:

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

• Membuat instans baru dengan latensi dasar 300ms, dan latensi gelombang gigi gergaji dengan amplitudo 200ms serta periode 2 menit seperti yang ditunjukkan pada grafik di bawah:

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

• Dimungkinkan untuk menjalankan penjumlahan beberapa latensi secara bersamaan.
• Speedbump dapat digunakan sebagai pustaka Go melalui paket lib.

---

Pendapat GN⁺:

• Speedbump adalah alat yang berguna untuk mensimulasikan latensi jaringan, dan dapat membantu menguji serta mengoptimalkan performa aplikasi berbasis jaringan.
• Karena ditulis dalam bahasa Go, alat ini terasa familier bagi para pengembang Go dan menyediakan kemampuan untuk dengan mudah mensimulasikan berbagai pola latensi.
• Bersifat open source dan mengikuti lisensi Apache 2.0, sehingga berpotensi terus ditingkatkan melalui kontribusi komunitas.

[GN⁺]

Komentar Hacker News

• Saat menguji implementasi ActivityPub di berbagai ukuran dan kondisi jaringan, saya meneliti pekerjaan serupa. Saya belajar cara menambahkan latensi ke antarmuka tertentu menggunakan perintah tc, dan ini juga berfungsi baik di container Docker. Kemungkinan sudah terpasang di banyak sistem.
  • Contoh perintah: tc qdisc add dev eth0 root netem delay 100ms
• Di Netflix, mereka mengembangkan alat yang disebut 'latency monkey'. Mendeteksi saat layanan hilir mulai melambat jauh lebih sulit daripada mendeteksi saat layanan tidak dapat digunakan. Alat ini menjatuhkan paket pada rasio tertentu untuk memicu retransmisi, yang menyebabkan paket tertunda atau keluar dari urutan. Mereka menemukan banyak masalah dalam kode penanganan error untuk akses jaringan.
• Setiap software engineer yang mengerjakan aplikasi internet seharusnya menggunakan alat seperti ini secara rutin. QUIC dan TCP sama-sama diperlukan, dan alat itu harus bisa menangkap semua UDP termasuk DNS. Saya yakin 90% web app akan hilang jika para developer tidak memakai lingkungan komputasi berkinerja tinggi.
• Banyak aplikasi berkinerja buruk saat koneksi jaringan terputus-putus. Developer aplikasi bisa membantu orang lain dengan menguji konektivitas terputus-putus yang disimulasikan. Banyak aplikasi tidak memiliki fitur 'outbox' seperti klien email. Ada pertanyaan tentang siapa yang bisa membuat 'mutator test case' toxiproxy referensi untuk mensimulasikan masalah konektivitas umum dalam situasi bantuan bencana.
• Di Mac, hal serupa bisa dilakukan dengan alat bawaan. Disediakan contoh perintah untuk mensimulasikan kecepatan koneksi jaringan.
• Saat ingin mensimulasikan jaringan lambat di Mac, saya menemukan Network Link Conditioner. Bisa digunakan tanpa pengaturan proxy atau konfigurasi lain, dan harus diinstal dari Xcode Additional Tools.
• Sudah lama tidak aktif, tetapi nama 'comcast' terasa mengatakan banyak hal.
• Alat serupa yang pernah saya gunakan di Windows adalah 'clumsy'.
• FreeBSD juga memiliki fitur bernama 'dummynet' sebagai bagian dari ipfw, yang dapat menyuntikkan latensi, pembatasan bandwidth, ukuran antrean, dan packet loss. Fungsinya sama seperti di MacOS.
• Saya tidak akan pernah lupa saat di pekerjaan pertama saya, manajer saya mengatur firewall FreeBSD IPFW agar respons ICMP menjadi lambat. Setiap kali seseorang mengirim ping, waktu responsnya selalu terlihat paling tinggi. Manajer itu memang suka iseng.