Pengembangan zond untuk mengukur kecepatan internet



Selamat siang untuk semua pengguna habra.



Saya terus-menerus membaca artikel tentang Habré tentang pengembangan fungsi ini atau itu di "Malinka". Saya memutuskan untuk membagikan pekerjaan saya di sini.



Latar Belakang



Saya bekerja di perusahaan yang menyediakan TV kabel dan layanan akses Internet. Dan, seperti halnya di perusahaan-perusahaan tersebut, saya secara berkala mendengar keluhan tentang ketidakkonsistenan rencana tarif dengan yang tercantum dalam kontrak. Sekarang pengguna mengeluh tentang kecepatan rendah "over the cable", kemudian tentang ping tinggi layanan tertentu, kadang-kadang tentang tidak adanya Internet pada waktu tertentu dalam sehari. Seringkali, keluhan semacam itu berakhir di kumpulan aplikasi, yang menurutnya salah satu karyawan dengan laptop yang berfungsi, di mana semua pengukuran dilakukan, dikirim ke situs. Dan, seringkali, ternyata semuanya sesuai dengan kecepatan. Dan kecepatan rendah sebenarnya di ponsel, melalui wi-fi, di balkon. Ya atau semacamnya.



Sayangnya, tidak mungkin untuk pergi ke pelanggan misalnya di 21:37, ketika ia memiliki kecepatan terendah. Meski demikian, hari kerja karyawan terbatas. Mengganti router tidak berpengaruh. rentang frekuensi untuk wi-fi di negara kita sangat berantakan.



Untuk referensi - penyedia negara di Republik Belarus secara paksa mengaktifkan wi-fi pada semua perangkat yang disediakan untuk digunakan dan menyiarkan SSID ByFly dari setiap perangkat. Bahkan jika pelanggan tidak memiliki layanan Internet, tetapi hanya telepon rumah. Ini dilakukan untuk penjualan tambahan. Anda dapat membeli kartu dari operator ini di sebuah kios, terhubung ke titik mana pun dengan nama ByFly dan, dengan memasukkan data dari kartu, menerima layanan Internet. Mempertimbangkan cakupan hampir 100% dari kota-kota dan cakupan yang signifikan dari sektor swasta dan daerah pedesaan, menemukan titik koneksi bukanlah masalah.



Mengamati saluran komunikasi eksternal kami menunjukkan bahwa ada cadangan bandwidth yang diberikan. Dan pelanggan secara total tidak mengkonsumsi saluran yang tersedia, bahkan selama jam sibuk. Dengan ini kita semua sangat serius. Penggunaan berbagai layanan dan server yang berbeda untuk mengukur kecepatan telah menghasilkan hasil yang menarik. Ternyata tidak semua layanan sama-sama bermanfaat ... Terutama di malam hari. Dan Anda seharusnya tidak mempercayai mereka dengan jelas. Banyak operator dari jaringan Ookla yang sama tidak memiliki saluran komunikasi yang luas, atau mereka bekerja dari ujung ke ujung. Ini berarti bahwa seringkali hampir tidak mungkin untuk mendapatkan hasil yang jujur ​​di malam hari. Dan jalan raya berdosa. Misalnya, upaya untuk mengukur kecepatan di Jepang menunjukkan hasil yang sangat menyedihkan ...



Solusi utama





Foto untuk tujuan ilustrasi



Dua server kontrol kecepatan dikerahkan. Yang pertama adalah LibreSpeed , yang kedua adalah Speedtest dari OOKLA . Kinerja kedua layanan dibandingkan. Kami memutuskan untuk berhenti di Ookla. hingga 90% pelanggan menggunakan layanan khusus ini.



Selanjutnya, instruksi ditulis untuk pengguna dan karyawan tentang cara mengukur kecepatan di dalam jaringan dan di luar. Itu saat memulai tes, kecepatan diukur dalam jaringan secara default. Server terletak di kantor pusat kami, dan solusi Ookla, secara default, memilih server terdekat dengan pelanggan. Jadi, kami memeriksa operasi jaringan transmisi data kami sendiri.



Untuk mengukur kecepatan di dalam negara (kami memiliki jaringan terpisah untuk operator telekomunikasi, yang menyatukan semua operator dan pusat data utama di dalam negara), Anda harus memilih penyedia di dalam negara dan mengukur ulang. Kami telah mengidentifikasi secara empiris beberapa server yang memberikan hasil yang lebih atau kurang stabil setiap saat sepanjang hari dan meresepkannya seperti yang direkomendasikan dalam instruksi.



Nah, tindakan serupa untuk saluran komunikasi eksternal. Kami menemukan operator besar dengan saluran besar di server speedtest dan menulisnya dalam rekomendasi (maaf Moskva - Rostelecom dan Riga - Baltcom, tetapi saya akan merekomendasikan node ini untuk mendapatkan angka yang memadai. Secara pribadi, saya menerima hingga ~ 870 megabit dari server ini. selama jam sibuk).



Mengapa, Anda bertanya, kesulitan seperti itu? Semuanya sangat sederhana. Kami telah menerima alat yang cukup nyaman yang, di tangan yang cakap, memungkinkan kami untuk menentukan: apakah ada masalah di jaringan kami, apakah ada masalah di jaringan republik, apakah ada masalah dengan bagasi. Jika seseorang mengeluh tentang kecepatan unduh yang rendah dari suatu layanan, kita dapat mengukur kecepatan saluran pelanggan dan kemudian membandingkannya dengan apa yang dia terima dari layanan tersebut. Dan dikatakan untuk menunjukkan bahwa kami dengan jujur ​​menyoroti saluran yang ditentukan dalam kontrak. Dan kami juga dapat menjelaskan alasan yang mungkin untuk perbedaan kecepatan tersebut.



Solusi sekunder



Pertanyaan tentang penurunan kecepatan di malam hari / siang hari tetap terbuka. Bagaimana cara melakukan hal yang sama tanpa berada di rumah pelanggan? Ambil papan tunggal murah dengan jaringan gigabit dan buat apa yang disebut probe. Perangkat harus melakukan pengukuran kecepatan melalui kabel pada interval waktu tertentu. Solusinya harus open source, sesering mungkin, dengan panel admin yang nyaman untuk melihat hasil pengukuran. Perangkat harus semurah mungkin sehingga dapat dengan mudah diganti dan dibiarkan dengan pelanggan selama n hari tanpa rasa takut.



Penerapan







BananaPI (model M1) diambil sebagai dasar. Sebenarnya ada dua alasan untuk memilih.



  1. Port Gigabit.
  2. Dia baru saja berbaring di nakas.


Selanjutnya, diputuskan untuk menggunakan klien python speedtest-cli untuk layanan Speedtest oleh Ookla sebagai backend untuk mengukur kecepatan. Pustaka pythonping untuk mengukur kecepatan ping. Nah, dan php untuk area admin. Demi kenyamanan, saya menggunakan bootstrap .



Karena fakta bahwa sumber daya raspberry bukan karet, banyak nginx + php-fpm + sqlite3 digunakan. Kami ingin meninggalkan MySQL karena beratnya dan redundansi. Mengantisipasi pertanyaan tentang Iperf. Itu harus ditinggalkan karena tidak mungkin menggunakannya dalam arah selain yang lokal.



Awalnya saya mengikuti jalur banyak di situs ini. Memodifikasi klien speedtest-cli. Tapi kemudian, setelah sedikit merenung, dia meninggalkan ide itu. Saya menulis pekerja saya sendiri yang menggunakan kemampuan klien asli.



Untuk menganalisis ping, saya cukup menulis handler terpisah. Kami mengambil nilai rata-rata dengan pengukuran. Pingovalka tahu alamat IP dan nama domain.



Saya tidak mencapai pekerjaan asinkron. Dia tidak terlalu dibutuhkan dalam kasus ini.



Panel admin untuk mengevaluasi hasil ternyata sangat minimalis.



Ara. Jendela admin utama dengan hasil tes



Ara. Pengaturan pengujian





Ara. Memperbarui Daftar Server Speedtest



Itu saja. Gagasan itu direalisasikan pada lutut, di waktu luang dari pekerjaan. Tes lapangan belum dimulai. Tapi kami berencana untuk meluncurkan prototipe dalam waktu dekat. Anda dapat menggunakan penyedia di sana dan klien penyedia. Tidak ada yang mengganggu untuk melakukan pengukuran di rumah sepanjang waktu. Satu-satunya hal yang perlu diingat adalah bahwa jika Anda secara aktif menjelajahi internet atau mengunduh sesuatu, maka pengukurannya akan menjadi lebih rendah dari yang asli. Jadi, idealnya, probe harus dibiarkan di jaringan sebagai satu-satunya konsumen lalu lintas.



PS: tolong jangan menendang untuk kualitas kode. Saya belajar sendiri tanpa pengalaman. Kode sumber di GitHub . Kritik itu diterima.



All Articles