Selamat petang kepada semua pengguna Habra.
Saya sentiasa membaca artikel tentang Habré tentang pembangunan fungsi ini atau itu pada Malinka. Saya memutuskan untuk berkongsi kerja saya di sini.
prasejarah
Saya bekerja untuk sebuah syarikat yang menyediakan perkhidmatan televisyen kabel dan akses Internet. Dan, seperti yang berlaku di syarikat sedemikian, saya secara berkala mendengar aduan tentang ketidakkonsistenan pelan tarif dengan apa yang dinyatakan dalam kontrak. Sama ada pengguna mengadu tentang kelajuan rendah "melalui kabel", kemudian mengenai ping tinggi perkhidmatan tertentu, kadang-kadang mengenai ketiadaan Internet sepenuhnya pada masa tertentu dalam sehari. Selalunya, aduan sedemikian berakhir dengan sekumpulan permintaan, yang mencetuskan lawatan ke tapak oleh salah seorang pekerja dengan komputer riba yang berfungsi, di mana semua ukuran diambil. Dan, selalunya, ternyata semuanya baik-baik saja dengan kelajuan. Dan kelajuan rendah sebenarnya pada telefon bimbit, melalui wi-fi, di balkoni. Nah, atau sesuatu yang serupa.
Malangnya, tidak mungkin untuk pergi ke pelanggan, contohnya, pada 21:37, apabila dia mempunyai kelajuan paling rendah. Lagipun, waktu kerja pekerja adalah terhad. Menggantikan penghala tidak mempunyai kesan, kerana... Julat frekuensi untuk wi-fi di negara kita sangat berantakan.
Untuk rekod — pembekal negeri di Republik Belarus secara paksa menghidupkan wi-fi pada semua peranti yang disediakan untuk digunakan dan menyiarkan ByFly SSID dari setiap peranti. Walaupun pelanggan tidak mempunyai perkhidmatan Internet, tetapi hanya telefon rumah. Ini dilakukan untuk jualan tambahan. Anda boleh membeli kad daripada operator ini di kiosk, menyambung ke mana-mana titik bernama ByFly dan, dengan memasukkan data daripada kad, menerima perkhidmatan Internet. Memandangkan hampir 100% liputan bandar dan liputan ketara sektor swasta dan kawasan luar bandar, mencari titik sambungan tidak menjadi masalah.
Pemerhatian saluran komunikasi luaran kami menunjukkan bahawa terdapat rizab lebar jalur yang diberikan. Dan pelanggan tidak menggunakan saluran yang tersedia secara keseluruhan, walaupun pada waktu sibuk. Kami sangat serius mengenai perkara ini. Penggunaan perkhidmatan yang berbeza dan pelayan pengukuran kelajuan yang berbeza membawa kepada hasil yang menarik. Ternyata tidak semua perkhidmatan sama berguna... Lebih-lebih lagi pada waktu petang. Dan anda tidak sepatutnya mempercayai mereka. Banyak pengendali rangkaian Ookla yang sama tidak mempunyai saluran komunikasi yang luas, atau bekerja secara bersambungan. Ini bermakna bahawa pada waktu petang selalunya hampir mustahil untuk mendapatkan hasil yang jujur. Ya, dan lebuh raya itu ternyata berdosa. Sebagai contoh, percubaan untuk mengukur kelajuan di Jepun menunjukkan hasil yang sangat buruk...
Keputusan utama
Foto adalah untuk tujuan ilustrasi sahaja.
Dua pelayan kawalan kelajuan telah digunakan. Yang pertama ialah , kedua - . Prestasi kedua-dua perkhidmatan telah dibandingkan. Lagipun, kami memutuskan untuk singgah di Ookla kerana... sehingga 90% pelanggan menggunakan perkhidmatan ini.
Seterusnya, arahan telah ditulis untuk pengguna dan pekerja tentang cara mengukur kelajuan di dalam dan di luar rangkaian. Itu. Apabila ujian bermula, secara lalai kelajuan dalam rangkaian diukur. Pelayan terletak di bahagian kepala kami, dan penyelesaian Ookla secara lalai memilih pelayan yang paling hampir dengan pelanggan. Dengan cara ini kami menyemak operasi rangkaian penghantaran data kami sendiri.
Untuk mengukur kelajuan dalam negara (kami mempunyai rangkaian berasingan untuk pengendali telekomunikasi, yang menyatukan semua pengendali dan pusat data utama dalam negara), anda perlu memilih pembekal dalam negara dan mengambil ukuran kedua. Kami telah mengenal pasti secara empirik beberapa pelayan yang memberikan hasil yang lebih atau kurang stabil pada bila-bila masa sepanjang hari dan telah menyenaraikannya seperti yang disyorkan dalam arahan.
Nah, tindakan serupa untuk saluran komunikasi luaran. Kami menemui pengendali besar dengan saluran besar pada pelayan terpantas dan menulisnya dalam cadangan (maaf "Moskva - Rostelecom" dan "Riga - Baltcom", tetapi saya akan mengesyorkan nod ini untuk mendapatkan nombor yang mencukupi. Secara peribadi, saya menerima sehingga ~870 megabit daripada pelayan ini pada waktu puncak).
Mengapa, anda bertanya, kesukaran sedemikian? Semuanya sangat mudah. Kami telah menerima alat yang agak mudah yang, di tangan yang berkebolehan, membolehkan kami menentukan sama ada terdapat masalah dalam rangkaian kami, sama ada terdapat masalah dalam rangkaian republik, atau sama ada terdapat masalah dengan tulang belakang. Jika seseorang mengadu tentang kelajuan muat turun yang rendah daripada sesetengah perkhidmatan, kami boleh mengukur kelajuan saluran pelanggan dan kemudian membandingkannya dengan apa yang dia terima daripada perkhidmatan tersebut. Dan adalah munasabah untuk menunjukkan bahawa kami secara jujur memperuntukkan saluran yang dinyatakan dalam kontrak. Kami juga boleh menerangkan sebab yang mungkin untuk perbezaan kelajuan sedemikian.
Penyelesaian sekunder
Persoalan penurunan kelajuan pada waktu petang/siang hari masih terbuka. Bagaimana untuk melakukan perkara yang sama tanpa berada di rumah pelanggan? Ambil kad papan tunggal yang murah dengan rangkaian gigabit dan buat apa yang dipanggil siasatan daripadanya. Peranti mesti mengambil ukuran kelajuan di sepanjang kabel pada selang masa tertentu. Penyelesaiannya hendaklah sumber terbuka, sebersahaja mungkin, dengan panel pentadbir yang mudah untuk melihat hasil pengukuran. Peranti haruslah semurah mungkin supaya ia boleh diganti dengan mudah dan ditinggalkan dengan pelanggan selama n hari tanpa rasa takut.
Реализация
BananaPI (model M1) diambil sebagai asas. Sebenarnya terdapat dua sebab untuk pilihan ini.
- Port gigabit.
- Ia hanya berbaring di atas meja malam.
Seterusnya, ia telah memutuskan untuk menggunakan klien python untuk perkhidmatan Speedtest by Ookla sebagai backend untuk mengukur kelajuan. perpustakaan untuk mengukur kelajuan ping. Nah, dan php untuk panel pentadbir. Untuk memudahkan persepsi saya gunakan .
Disebabkan oleh fakta bahawa sumber Raspberry tidak fleksibel, gabungan nginx+php-fpm+sqlite3 telah digunakan. Saya mahu melepaskan MySQL kerana berat dan redundansinya. Saya menjangkakan soalan mengenai Iperf. Ia terpaksa ditinggalkan kerana kemustahilan menggunakannya ke arah selain dari arah tempatan.
Pada mulanya saya mengikuti laluan ramai di laman web ini. Mengubah suai klien speedtest-cli. Tetapi kemudian, selepas berfikir sedikit, dia meninggalkan idea ini. Saya menulis pekerja saya sendiri yang menggunakan keupayaan pelanggan asal.
Untuk menganalisis ping, saya hanya menulis pengendali yang berasingan. Kami mengambil nilai purata daripada pengukuran. Alat ping boleh mengendalikan kedua-dua alamat IP dan nama domain.
Saya tidak mencapai kerja tak segerak. Ia tidak diperlukan terutamanya dalam kes ini.
Panel pentadbir untuk menilai keputusan ternyata agak minimalis.
Rajah Tetingkap pentadbir utama dengan keputusan ujian
Rajah Tetapan ujian
Rajah Kemas kini senarai pelayan Speedtest
Itu sahaja. Idea itu dilaksanakan di atas lutut saya, pada masa lapang saya. Ujian lapangan masih belum bermula. Tetapi kami merancang untuk melancarkan prototaip dalam masa terdekat. Ia boleh digunakan oleh pembekal di sana dan oleh pelanggan pembekal. Tiada siapa yang mengganggu anda untuk mengambil ukuran di rumah sepanjang masa. Satu-satunya perkara yang perlu anda ingat ialah jika anda secara aktif melayari Internet atau memuat turun sesuatu, maka ukurannya akan lebih rendah daripada yang sebenar. Jadi, idealnya, anda perlu meninggalkan siasatan pada rangkaian sebagai satu-satunya pengguna trafik.
PS: tolong jangan kecam saya kerana kualiti kod. Saya belajar sendiri tanpa pengalaman. Kod sumber untuk . Kritikan diterima.
Sumber: www.habr.com