Selamat siang untuk semua pengguna Habra.
Saya terus-menerus membaca artikel di Habré tentang pengembangan fungsi ini atau itu di Malinka. Saya memutuskan untuk membagikan pekerjaan saya di sini.
prasejarah
Saya bekerja di sebuah perusahaan yang menyediakan layanan televisi kabel dan akses Internet. Dan, seperti yang terjadi di perusahaan-perusahaan seperti itu, saya secara berkala mendengar keluhan tentang ketidaksesuaian rencana tarif dengan yang tercantum dalam kontrak. Entah pengguna mengeluh tentang kecepatan rendah "melalui kabel", lalu tentang ping yang tinggi pada layanan tertentu, terkadang tentang tidak adanya Internet sama sekali pada waktu-waktu tertentu dalam sehari. Seringkali, keluhan seperti itu berakhir dengan kumpulan permintaan, yang menjadi dasar salah satu karyawan pergi “ke lokasi” dengan laptop yang berfungsi, tempat semua pengukuran dilakukan. Dan, seringkali, ternyata semuanya baik-baik saja dengan kecepatannya. Dan kecepatan rendahnya sebenarnya di ponsel, lewat wi-fi, di balkon. Ya, atau yang serupa.
Sayangnya, tidak mungkin untuk mengunjungi pelanggan, misalnya pada pukul 21:37, saat kecepatannya paling rendah. Pasalnya, jam kerja karyawan dibatasi. Mengganti router tidak berpengaruh, karena... Rentang frekuensi wi-fi di negara kita sangat berantakan.
Sebagai catatan — penyedia negara di Republik Belarus secara paksa menyalakan wi-fi di semua perangkat yang disediakan untuk digunakan dan menyiarkan SSID ByFly dari setiap perangkat. Sekalipun pelanggan tidak memiliki layanan Internet, melainkan hanya telepon rumah. Ini dilakukan untuk penjualan tambahan. Anda dapat membeli kartu dari operator ini di kios, terhubung ke titik mana pun bernama ByFly dan, dengan memasukkan data dari kartu, menerima layanan Internet. Mengingat hampir 100% cakupan wilayah perkotaan dan cakupan sektor swasta dan wilayah pedesaan yang signifikan, menemukan titik penghubung bukanlah suatu masalah.
Pengamatan terhadap saluran komunikasi eksternal kami menunjukkan bahwa terdapat cadangan bandwidth tertentu. Dan pelanggan tidak menggunakan saluran yang tersedia secara total, bahkan pada jam sibuk. Kami sangat serius dalam hal ini. Penggunaan layanan yang berbeda dan server pengukuran kecepatan yang berbeda memberikan hasil yang menarik. Ternyata tidak semua layanan sama bermanfaatnya... Apalagi di malam hari. Dan Anda tidak seharusnya mempercayai mereka. Banyak operator di jaringan Ookla yang sama tidak memiliki saluran komunikasi yang luas, atau bekerja saling membelakangi. Artinya, pada malam hari seringkali hampir tidak mungkin mendapatkan hasil yang jujur. Ya, dan jalan raya ternyata penuh dosa. Misalnya, upaya mengukur kecepatan di Jepang menunjukkan hasil yang sangat buruk...
Keputusan utama
Foto adalah ilustrasi
Dua server kontrol kecepatan dikerahkan. Yang pertama adalah , kedua - . Kinerja kedua layanan dibandingkan. Bagaimanapun, kami memutuskan untuk berhenti di Ookla karena... hingga 90% pelanggan menggunakan layanan ini.
Selanjutnya, instruksi ditulis untuk pengguna dan karyawan tentang cara mengukur kecepatan di dalam dan di luar jaringan. Itu. Saat pengujian dimulai, secara default kecepatan dalam jaringan diukur. Server terletak di headend kami, dan solusi Ookla secara default memilih server yang paling dekat dengan pelanggan. Dengan cara ini kami memeriksa pengoperasian jaringan transmisi data kami sendiri.
Untuk mengukur kecepatan di dalam negeri (kami memiliki jaringan terpisah untuk operator telekomunikasi, yang menyatukan semua operator dan pusat data utama di dalam negeri), Anda perlu memilih penyedia di dalam negara tersebut dan melakukan pengukuran kedua. Kami secara empiris telah mengidentifikasi beberapa server yang memberikan hasil yang kurang lebih stabil setiap saat sepanjang hari dan telah mencantumkannya seperti yang direkomendasikan dalam petunjuk.
Nah, tindakan serupa untuk saluran komunikasi eksternal. Kami menemukan operator besar dengan saluran besar di server speedtest dan menuliskannya dalam rekomendasi (maaf “Moskva - Rostelecom” dan “Riga - Baltcom”, tapi saya akan merekomendasikan node ini untuk mendapatkan jumlah yang memadai. Secara pribadi, saya menerima hingga ~870 megabit dari server ini selama jam sibuk).
Anda bertanya, mengapa kesulitan seperti itu? Semuanya sangat sederhana. Kami telah menerima alat yang cukup mudah digunakan yang, di tangan yang cakap, memungkinkan kami menentukan apakah ada masalah di jaringan kami, apakah ada masalah di jaringan republik, atau apakah ada masalah dengan tulang punggung. Jika seseorang mengeluh tentang kecepatan unduh yang rendah dari suatu layanan, kami dapat mengukur kecepatan saluran pelanggan dan kemudian membandingkannya dengan apa yang dia terima dari layanan tersebut. Dan masuk akal untuk menunjukkan bahwa kami dengan jujur mengalokasikan saluran yang ditentukan dalam kontrak. Kami juga dapat menjelaskan kemungkinan alasan perbedaan kecepatan tersebut.
Solusi sekunder
Pertanyaan tentang penurunan kecepatan di malam hari/siang hari tetap terbuka. Bagaimana cara melakukan hal yang sama tanpa harus berada di rumah pelanggan? Ambil kartu papan tunggal murah dengan jaringan gigabit dan buatlah apa yang disebut probe darinya. Perangkat harus melakukan pengukuran kecepatan di sepanjang kabel pada interval waktu tertentu. Solusinya harus open source, sesederhana mungkin, dengan panel admin yang nyaman untuk melihat hasil pengukuran. Perangkat harus semurah mungkin agar mudah diganti dan diserahkan kepada pelanggan selama n hari tanpa rasa takut.
Implementasi
BananaPI (model M1) diambil sebagai dasar. Sebenarnya ada dua alasan untuk pilihan ini.
- Pelabuhan Gigabit.
- Benda itu tergeletak begitu saja di meja samping tempat tidur.
Selanjutnya diputuskan untuk menggunakan klien python untuk layanan Speedtest by Ookla sebagai backend untuk mengukur kecepatan. perpustakaan untuk mengukur kecepatan ping. Nah, dan php untuk panel admin. Untuk kemudahan persepsi saya menggunakan .
Karena sumber daya Raspberry tidak fleksibel, kombinasi nginx+php-fpm+sqlite3 digunakan. Saya ingin melepaskan MySQL karena berat dan redundansinya. Saya mengantisipasi pertanyaan tentang Iperf. Itu harus ditinggalkan karena ketidakmungkinan menggunakannya ke arah selain arah lokal.
Awalnya saya mengikuti jalur banyak orang di situs ini. Memodifikasi klien speedtest-cli. Tapi kemudian, setelah berpikir sejenak, dia meninggalkan ide ini. Saya menulis pekerja saya sendiri yang menggunakan kemampuan klien asli.
Untuk menganalisis ping, saya cukup menulis penangan terpisah. Kami mengambil nilai rata-rata dari pengukuran. Alat ping dapat menangani alamat IP dan nama domain.
Saya tidak mencapai pekerjaan asinkron. Hal ini tidak terlalu diperlukan dalam kasus ini.
Panel admin untuk mengevaluasi hasil ternyata cukup minimalis.
Fig. Jendela admin utama dengan hasil pengujian
Fig. Pengaturan pengujian
Fig. Perbarui daftar server Speedtest
Itu saja. Ide itu diimplementasikan sambil berlutut, di waktu luang saya. Uji lapangan belum dimulai. Namun kami berencana meluncurkan prototipe dalam waktu dekat. Ini dapat digunakan baik oleh penyedia di sana maupun oleh klien penyedia. Tidak ada yang mengganggu Anda untuk melakukan pengukuran di rumah sepanjang waktu. Satu-satunya hal yang harus Anda ingat adalah jika Anda aktif menjelajahi Internet atau mengunduh sesuatu, maka pengukurannya akan lebih rendah dari yang sebenarnya. Jadi, idealnya, Anda harus membiarkan probe di jaringan sebagai satu-satunya konsumen lalu lintas.
PS: tolong jangan mengkritik saya karena kualitas kodenya. Saya otodidak tanpa pengalaman. Kode sumber untuk . Kritik diterima.
Sumber: www.habr.com