rperf
v0.1.8
rperf adalah alternatif iperf berbasis Rust yang dikembangkan oleh 3D-P, yang bertujuan untuk menghindari beberapa masalah keandalan dan konsistensi yang ditemukan di iperf3 , sekaligus menyediakan data metrik yang lebih kaya, dengan fokus pada pengoperasian di lingkungan yang lebih toleran terhadap kerugian dan lebih mirip IoT. Meskipun dapat digunakan sebagai pengganti iperf , dan mungkin ada manfaatnya, fokusnya adalah pada pengumpulan data berkala dalam kapasitas pemantauan di jaringan tertutup, yang berarti tidak cocok untuk semua domain. iperf itu bisa melayani.
rperf adalah implementasi independen, merujuk pada algoritma iperf3 dan zapwireless untuk menilai kebenaran dan mendapatkan koreksi yang sesuai, tetapi tidak menyalin kode dari keduanya.
Secara khusus, permasalahan paling signifikan yang ditangani dari iperf3 adalah sebagai berikut:
Beberapa klien secara bersamaan didukung oleh server tertentu.
Implementasi rperf RFC 1889 untuk perhitungan jitter streaming dimulai dengan mengasumsikan delta antara paket pertama dan kedua secara berurutan dan celah dalam urutan memicu reset hitungan. Sebagai perbandingan, iperf3 dimulai dengan 0, yang menciptakan nilai-nilai yang sangat rendah, dan jika ada kesenjangan, ia terus berlanjut secara naif, yang menciptakan nilai-nilai yang sangat tinggi.
Paket duplikat dicatat dalam pertukaran UDP dan paket yang rusak dihitung sebagai kejadian independen.
Semua lalu lintas dapat dipancarkan secara proporsional pada interval sub-detik yang teratur, memungkinkan konfigurasi yang lebih akurat mencerminkan transmisi data nyata dan algoritma pengiriman.
Konfigurasi aliran dan hasil dipertukarkan melalui koneksi khusus dan setiap jalur data memiliki batas waktu habis, penyelesaian, dan semantik kegagalan yang jelas, sehingga eksekusi tidak terhenti tanpa batas waktu di kedua sisi pengujian ketika paket kunci hilang.
Output JSON rperf secara struktural legal. Tidak ada string yang tidak dikutip, kunci yang berulang, atau koma yang menjuntai, yang semuanya memerlukan pra-pemrosesan sebelum digunakan atau menyebabkan kesalahan yang tidak terduga.
Berbeda dengan zapwireless , peningkatan berikut diwujudkan:
rperf menggunakan arsitektur klien-server klasik, sehingga tidak perlu mempertahankan proses yang berjalan pada perangkat yang menunggu permintaan eksekusi pengujian.
Jitter dihitung.
IPv6 didukung.
Beberapa aliran dapat dijalankan secara paralel sebagai bagian dari pengujian.
Opsi omit tersedia untuk membuang waktu ramp-up TCP dari hasil.
Output tersedia dalam JSON untuk memudahkan pengambilan telemetri.
rperf harus membangun dan bekerja pada semua platform utama, meskipun fokus pengembangan dan penggunaannya adalah pada sistem berbasis Linux, sehingga di situlah ia akan memiliki fitur yang paling lengkap.
Permintaan tarik untuk penerapan fitur serupa pada sistem lain dipersilakan.
Semuanya diuraikan dalam keluaran --help dan sebagian besar pengguna yang akrab dengan alat serupa akan segera merasa nyaman.
rperf bekerja seperti iperf3 , berbagi banyak konsep dan bahkan flag baris perintah. Salah satu area utama yang membedakannya adalah klien mengendalikan seluruh proses konfigurasi sementara server hanya mematuhi kemampuan terbaiknya dan memberikan aliran hasil. Ini berarti bahwa server tidak akan menampilkan hasil pengujian secara langsung melalui antarmukanya dan juga pengujian TCP dan UDP dapat dijalankan terhadap instance yang sama, kemungkinan oleh banyak klien secara bersamaan.
Dalam mode operasi normal, klien akan mengunggah data ke server; ketika bendera reverse disetel, klien akan menerima data.
Berbeda dengan iperf3 , rperf tidak menggunakan rentang port yang dicadangkan secara default. Hal ini dilakukan agar dapat mendukung sejumlah klien secara paralel tanpa adanya pertentangan sumber daya pada sejumlah kecil port yang berdekatan. Dalam kapasitas yang diharapkan, hal ini seharusnya tidak menjadi masalah, tetapi jika menyangkut firewall non-permisif dan pengaturan NAT, opsi --tcp[6]-port-pool dan --udp[6]-port-pool mungkin menjadi masalah. digunakan untuk mengalokasikan port non-kontinyu ke set yang akan digunakan untuk menerima lalu lintas.
Juga tidak ada konsep pengujian throughput relatif terhadap jumlah data yang tetap. Sebaliknya, satu-satunya fokus adalah mengukur throughput selama periode waktu yang diketahui secara kasar.
Yang juga relevan adalah, jika server berjalan dalam mode IPv6 dan hostnya mendukung pemetaan IPv4 dalam konfigurasi dual-stack, klien IPv4 dan IPv6 dapat terhubung ke instance yang sama.
rperf menggunakan kargo . Proses umumnya adalah cargo build --release .
cargo-deb juga didukung dan akan menghasilkan paket Debian yang dapat digunakan yang menginstal layanan rperf systemd yang dinonaktifkan secara default. Ketika dimulai, ini berjalan sebagai nobody:nogroup , dengan asumsi dukungan IPv6 secara default.
Seperti orang-orang sezamannya, konsep inti rperf adalah menembakkan aliran data TCP atau UDP pada target IP dengan kecepatan target yang telah diatur sebelumnya. Jumlah data yang sebenarnya diterima diamati dan digunakan untuk mengukur kapasitas link jaringan.
Dalam domain tersebut, data tambahan tentang kualitas pertukaran dikumpulkan dan tersedia untuk ditinjau.
Secara arsitektural, rperf meminta klien membuat koneksi TCP ke server, setelah itu klien mengirimkan rincian tentang pengujian yang akan dilakukan dan server mewajibkan, melaporkan hasil observasi kepada klien selama seluruh proses pengujian.
Klien dapat meminta agar beberapa aliran paralel digunakan untuk pengujian, yang difasilitasi dengan membuat beberapa koneksi TCP atau soket UDP dengan thread khusus mereka sendiri di kedua sisi, yang selanjutnya dapat disematkan ke satu inti CPU logis untuk mengurangi dampak halaman. -kesalahan pada pertukaran data.
Hubungan klien-server diperlakukan sebagai aspek yang sangat sentral dalam desain ini, berbeda dengan iperf3 , di mana mereka lebih seperti rekan, dan zapwireless , di mana setiap peserta menjalankan daemonnya sendiri dan proses ketiga mengatur komunikasi.
Khususnya, semua pengumpulan data, perhitungan, dan tampilan terjadi di sisi klien, dengan server hanya mengembalikan apa yang diamatinya. Hal ini dapat menyebabkan beberapa penyimpangan dalam rekaman, terutama jika menyangkut waktu (interval server yang beberapa milidetik lebih lama dari nilai klien terkait bukanlah hal yang aneh). Namun, dengan asumsi koneksi tidak terputus, total data yang diamati akan cocok di semua mode operasi.
Server menggunakan tiga lapisan threading: satu untuk thread utama, satu untuk setiap klien yang dilayani, dan satu lagi untuk setiap aliran yang berkomunikasi dengan klien. Di sisi klien, thread utama digunakan untuk berkomunikasi dengan server dan memunculkan thread tambahan untuk setiap aliran yang berkomunikasi dengan server.
Saat server menerima permintaan dari klien, server akan memunculkan thread yang menangani permintaan spesifik klien tersebut; secara internal, setiap aliran untuk pengujian menghasilkan penangan seperti iterator di kedua sisi. Baik klien maupun server menjalankan analog-iterator ini satu sama lain secara asinkron hingga periode pengujian berakhir, pada titik mana pengirim menunjukkan penyelesaian dalam alirannya.
Untuk menangani kemungkinan pemutusan sambungan pada tingkat aliran secara andal, mekanisme keepalive dalam aliran klien-server, yang melaluinya hasil pengujian dikirim dari server secara berkala, akan menghentikan koneksi yang luar biasa setelah beberapa detik tidak aktif.
Mekanisme TCP dan UDP OS host digunakan untuk semua lalu lintas aktual yang dipertukarkan, dengan beberapa parameter penyetelan diekspos. Pendekatan ini dipilih dibandingkan implementasi ruang pengguna di atas lapisan-2 atau lapisan-3 karena pendekatan ini paling akurat mewakili perilaku aplikasi di dunia nyata.
Nilai "stempel waktu" yang terlihat dalam data interval berseri JSON bersifat relatif terhadap host, jadi kecuali lingkungan Anda memiliki akurasi jam sistem yang sangat tinggi, stempel waktu pengiriman hanya boleh dibandingkan dengan stempel waktu pengiriman lainnya dan juga stempel waktu terima. Namun secara umum, data ini tidak berguna di luar validasi kebenaran.
Selama setiap interval pertukaran, upaya dilakukan untuk mengirimkan byte length pada suatu waktu, hingga jumlah yang ditulis ke aliran memenuhi atau melampaui target bandwidth, pada titik mana pengirim terdiam hingga dimulainya interval berikutnya; data yang dikirim dalam suatu interval harus didistribusikan secara seragam selama periode tersebut.
Indeks aliran dimulai dari 0 , bukan 1 . Ini mungkin tidak mengejutkan siapa pun, tetapi melihat "aliran 0" dalam laporan tidak perlu dikhawatirkan.
rperf didistribusikan oleh Evtech Solutions, Ltd., dba 3D-P, di bawah GNU GPL versi 3, teksnya dapat ditemukan di COPYING .
Detail kepengarangan, spesifikasi hak cipta, dan catatan pengalihan ada dalam kode sumber itu sendiri.
