https://habr.com/ru/post/510578/

• Python
• *nix
• Разработка под Linux
• Разработка на Raspberry Pi

Добрый день всем хабра-пользователям.

Постоянно читаю на хабре статьи о разработках того или иного функционала на «малинке». Решил вот поделиться своей наработкой.

Предыстория

Тружусь я в компании, предоставляющей услуги кабельного телевидения и доступа в интернет. И, как это бывает в подобных компаниях, периодически слышу жалобы о несоответствии тарифного плана заявленному в договоре. То пользователь жалуется на низкую скорость «по кабелю», то на высокие пинги определенных сервисов, иногда на полное отсутствие интернета в определенное время суток. Зачастую, такие жалобы попадают в пулл заявок, по которым происходит выезд «на место» одного из сотрудников с рабочим ноутбуком, на котором и производятся все замеры. И, зачастую, выясняется, что со скоростью все в порядке. А низкая скорость на самом деле на мобильном телефоне, через wi-fi, на балконе. Ну или нечто подобное.

К сожалению, выезжать к абоненту например в 21:37, когда у него наиболее низкие скорости не получается. Все-таки рабочий день сотрудников ограничен. Замена роутера эффекта не дает, т.к. диапазон частот для wi-fi в нашей стране плачевно захламлен.

Для справки — государственный провайдер в РБ принудительно включает на всех предоставляемых в пользование устройствах wi-fi и вещает SSID ByFly с каждого устройства. Даже если у абонента нет услуги интернета, а только домашний телефон. Сделано это для дополнительных продаж. Можно в ларьке купить карту данного оператора, подключиться к любой точке с именем ByFly и, введя данные с карты, получать услуги интернета. С учетом почти 100% покрытия городов и значительным покрытием частного сектора и сельских населенных пунктов — найти точку подключения не составляет проблем.

Наблюдение за нашим внешними каналами связи показывают, что имеется заданный запас полосы пропускания. И абоненты суммарно не потребляют имеющиеся каналы даже в час-пик. С этим у нас все очень серьезно. Использование разных сервисов и разных серверов замера скорости привел к интересным результатам. Оказывается не все сервисы одинаково полезны… Особенно по-вечерам. И не стоит однозначно им доверять. Множество операторов той же сети Ookla не имеют широких каналов связи, либо работают впритык. А это значит, что в вечернее время получить честный результат часто практически невозможно. Да и магистралы оказывается грешат. Для примера — попытки замера скорости в японию показывают крайне плачевные результаты…

Первичное решение

Фото носит иллюстрационный характер

Были развернуты два сервера контроля скорости. Первый — это LibreSpeed, второй — Speedtest от OOKLA. Сравнивались показатели обоих сервисов. Остановиться решили все-таки на Ookla т.к. до 90% абонентов пользуются именно данным сервисом.

Далее были написаны инструкции для пользователей и сотрудников о том, как производить замеры скорости внутри сети и наружу. Т.е. при запуске теста по умолчанию происходит замер скорости внутри сети. Сервер-то расположен у нас на головной станции, а решение Ookla по умолчанию выбирает самый близкий сервер к абоненту. Таким образом мы проверяем работу собственной сети передачи данных.

Для замера скорости внутри страны (есть у нас отдельная сеть для операторов связи, которая объединяет всех операторов и основные дата-центры внутри страны) нужно выбрать провайдера внутри страны и сделать повторный замер. Мы опытным путем выделили несколько серверов дающих более-менее стабильный результат в любое время суток и прописали их рекомендованными в инструкции.

Ну и аналогичные действия для внешних каналов связи. Нашли больших операторов с большими каналами на speedtest серверах и написали их в рекомендациях (уж простите «Moskva — Rostelecom» и «Riga — Baltcom», но буду именно данные узлы рекомендовать для получения адекватных цифр. Лично я получал до ~870 мегабит с данных серверов в часы-пик).

Зачем, спросите вы, такие сложности? Все очень просто. Мы получили достаточно удобный инструмент, который в умелых руках позволяет определить: нет ли проблем в наших сетях, нет ли проблем в республиканской сети, нет ли проблем у магистрала. Если человек жалуется на низкую скорость скачивания с какого-то сервиса — мы можем сделать замер скорости канала абонента и затем сравнить с тем, что он получает от сервиса. И аргументировано показать, что мы честно выделяем канал, прописанный в договоре. А так же можем пояснить возможные причины такой разницы в скоростях.

Вторичное решение

Остается открытым вопрос падения скорости по-вечерам/в течении суток. Как сделать все то же самое не находясь у абонента дома? Взять дешевый одноплатник с гигабитной сетью и сделать из него так называемый зонд. Устройство должно с заданным интервалом времени делать замеры скорости по кабелю. Решение должно быть опенсорсное, максимально неприхотливое, с удобной админкой для просмотра результатов замеров. Устройство должно быть максимально дешевым, что бы можно было легко заменить и без опасений оставлять у абонента на n суток.

Реализация

За основу был взят BananaPI (модель M1). Причин выбора на самом деле две.

1. Гигабитный порт.
2. Он просто валялся в тумбочке.

Далее было принято решение использовать python клиента speedtest-cli для сервиса Speedtest by Ookla в качестве бэкэнда для замера скорости. Библиотеку Pythonping для замера скорости пинга. Ну и php для админки. Для приятности восприятия применил bootstrap.

Ввиду того, что ресурсы малинки не резиновые была использована связка nginx+php-fpm+sqlite3. От MySQL хотелось отказаться из-за ее тяжести и переизбыточности. Предугадываю вопрос относительно Iperf. От него пришлось отказаться ввиду невозможности его использования на направлениях отличных от локальных.

Изначально пошел по-пути многих на этом сайте. Модифицировал клиент speedtest-cli. Но затем, немного поразмыслив, отказался от данной затеи. Написал свой воркер, который использует возможности оригинального клиента.

Для анализа пингов просто написал отдельный обработчик. Берем среднее значение по замеру. Пинговалка умеет как ip адрес так и доменное имя.

Асинхронности работы не добивался. Она в данном случае не особо нужна.

Админка для оценки результатов получилась довольно минималистическая.

Рис. Основное окно админки с результатами тестирования

Рис. Настройки тестирования


Рис. Обновление списка серверов Speedtest

Вот собственно и все. Идея реализована на коленке, в свободное от работы время. К полевым испытаниям пока не приступили. Но планируем в ближайшее время запустить в работу опытные образцы. Использовать можно как провайдерам там и клиентам провайдеров. Никто не мешает поставить делать замеры дома круглосуточно. Единственное, следует помнить, что если вы активно серферите в сети или что-то качаете — то и замер получится ниже реального. Так что в идеале — нужно зонд оставлять в сети единственным потребителем трафика.

P.S.: за качество кода прошу не пинать. Я самоучка без опыта. Исходный код на GitHub. Критика принимается.