Доброго дня всім хабра-користувачам.
Постійно читаю на хабрі статті про розробки того чи іншого функціоналу на «малинці». Вирішив ось поділитися своїм доробком.
Передісторія
Труджуся я в компанії, що надає послуги кабельного телебачення та доступу до інтернету. І, як це буває у подібних компаніях, періодично чую скарги про невідповідність тарифного плану, заявленому в договорі. То користувач скаржиться на низьку швидкість по кабелю, то на високі пінги певних сервісів, іноді на повну відсутність інтернету в певний час доби. Найчастіше, такі скарги потрапляють у пул заявок, за якими відбувається виїзд «на місце» одного із співробітників із робочим ноутбуком, на якому й виробляються всі виміри. І найчастіше з'ясовується, що зі швидкістю все гаразд. А низька швидкість насправді на мобільному телефоні через wi-fi на балконі. Ну, чи щось подібне.
На жаль, виїжджати до абонента, наприклад, о 21:37, коли у нього найнижчі швидкості, не виходить. Все ж таки робочий день співробітників обмежений. Заміна роутера ефекту це не дає, т.к. діапазон частот для wi-fi в нашій країні плачевно захаращений.
Для довідки — державний провайдер в РБ примусово включає всіх пристроях wi-fi, що надаються в користування, і мовить SSID ByFly з кожного пристрою. Навіть якщо абонент не має послуги інтернету, а лише домашній телефон. Зроблено це для додаткового продажу. Можна в кіоску купити картку даного оператора, підключитися до будь-якої точки з ім'ям ByFly і, ввівши дані з картки, отримувати послуги інтернету. З урахуванням майже 100% покриття міст та значним покриттям приватного сектору та сільських населених пунктів — знайти точку підключення не становить проблем.
Спостереження за зовнішніми каналами зв'язку показують, що є заданий запас смуги пропускання. І абоненти сумарно не споживають наявні канали навіть у годину-пік. Із цим у нас все дуже серйозно. Використання різних сервісів та різних серверів вимірювання швидкості привело до цікавих результатів. Виявляється не всі послуги однаково корисні ... Особливо по-вечорам. І не варто однозначно їм довіряти. Багато операторів тієї ж мережі Ookla не мають широких каналів зв'язку, або працюють впритул. А це означає, що увечері отримати чесний результат часто практично неможливо. Та й магістрали виявляється грішать. Для прикладу — спроби виміру швидкості до японії показують вкрай плачевні результати…
Первинне рішення
Фото має ілюстраційний характер
Було розгорнуто два сервери контролю швидкості. Перший - це , другий - . Порівнювалися показники обох сервісів. Зупинитися вирішили на Ookla т.к. до 90% абонентів користуються саме цим сервісом.
Далі були написані інструкції для користувачів та співробітників про те, як проводити вимірювання швидкості всередині мережі та назовні. Тобто. при запуску тесту за замовчуванням відбувається вимірювання швидкості всередині мережі. Сервер розташований у нас на головній станції, а рішення Ookla за замовчуванням вибирає найближчий сервер до абонента. Таким чином, ми перевіряємо роботу власної мережі передачі даних.
Для виміру швидкості всередині країни (є окрема мережа для операторів зв'язку, яка об'єднує всіх операторів і основні дата-центри всередині країни) потрібно вибрати провайдера всередині країни і зробити повторний вимір. Ми досвідченим шляхом виділили кілька серверів, які дають більш-менш стабільний результат у будь-який час доби і прописали їх рекомендованими в інструкції.
Та й аналогічні дії для зовнішніх каналів зв'язку. Знайшли великих операторів з великими каналами на speedtest серверах і написали їх у рекомендаціях (вибачте вже «Moskva — Rostelecom» і «Riga — Baltcom», але саме дані вузли рекомендуватиму для отримання адекватних цифр. Особисто я отримував до ~870 мегабіт з даних серверів в години-пік).
Навіщо, спитаєте ви, такі складнощі? Все дуже просто. Ми отримали досить зручний інструмент, який в умілих руках дозволяє визначити: чи немає проблем у наших мережах, чи проблем у республіканській мережі, чи проблем у магістрала. Якщо людина скаржиться на низьку швидкість завантаження з якогось сервісу — ми можемо зробити вимірювання швидкості каналу абонента і потім порівняти з тим, що він отримує від сервісу. І аргументовано показати, що ми чесно виокремлюємо канал, прописаний у договорі. А також можемо пояснити можливі причини такої різниці у швидкостях.
Вторинне рішення
Залишається відкритим питання падіння швидкості по-вечерам/протягом доби. Як зробити все те саме не перебуваючи у абонента вдома? Взяти дешевий одноплатник із гігабітною мережею і зробити з нього так званий зонд. Пристрій повинен із заданим інтервалом часу робити виміри швидкості кабелю. Рішення має бути опенсорсним, максимально невибагливим, із зручною адмінкою для перегляду результатів вимірів. Пристрій повинен бути максимально дешевим, щоб можна було легко замінити і без побоювань залишати у абонента на n добу.
Реалізація
За основу було взято BananaPI (модель M1). Причин вибору насправді дві.
- Гігабітний порт.
- Він просто валявся у тумбочці.
Далі було прийнято рішення використати python клієнта для сервісу Speedtest by Ookla як бекенд для виміру швидкості. Бібліотеку для вимірювання швидкості пінгу. Ну, і PHP для адмінки. Для приємності сприйняття застосував .
Зважаючи на те, що ресурси малинки не гумові була використана зв'язка nginx+php-fpm+sqlite3. Від MySQL хотілося відмовитися через її тяжкість та надмірність. Передбачаю питання щодо Iperf. Від нього довелося відмовитися через неможливість його використання на напрямках, відмінних від локальних.
Спочатку пішов шляхом багатьох на цьому сайті. Модифікував клієнт speedtest-cli. Але потім, трохи подумавши, відмовився від цієї витівки. Написав свій воркер, котрий використовує можливості оригінального клієнта.
Для аналізу пінг просто написав окремий обробник. Беремо середнє значення за виміром. Пінговалка вміє як IP адресу так і доменне ім'я.
Асинхронність роботи не домагався. Вона в цьому випадку не особливо потрібна.
Адмінка для оцінки результатів вийшла досить мінімалістичною.
Рис. Основне вікно адмінки з результатами тестування
Рис. Налаштування тестування
Рис. Оновлення списку серверів Speedtest
Ось, власне, і все. Ідея реалізована на коліні, у вільний від роботи час. До польових випробувань поки не розпочали. Але плануємо найближчим часом запустити у роботу дослідні зразки. Використовувати можна як провайдерам там, так і клієнтам провайдерів. Ніхто не заважає поставити заміри будинку цілодобово. Єдине, слід пам'ятати, що якщо ви активно серфіте в мережі або щось гойдаєте, то й замір вийде нижче реального. Тож в ідеалі — потрібно зонд залишати у мережі єдиним споживачем трафіку.
PS: за якість коду прошу не штовхати. Я самоучка без досвіду. Вихідний код на . Критика приймається.
Джерело: habr.com