Разработка zond-а для замера скорости интернета +15




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

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

Предыстория


Тружусь я в компании, предоставляющей услуги кабельного телевидения и доступа в интернет. И, как это бывает в подобных компаниях, периодически слышу жалобы о несоответствии тарифного плана заявленному в договоре. То пользователь жалуется на низкую скорость «по кабелю», то на высокие пинги определенных сервисов, иногда на полное отсутствие интернета в определенное время суток. Зачастую, такие жалобы попадают в пул заявок, по которым происходит выезд «на место» одного из сотрудников с рабочим ноутбуком, на котором и производятся все замеры. И, зачастую, выясняется, что со скоростью все в порядке. А низкая скорость на самом деле на мобильном телефоне, через 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. Критика принимается.




Комментарии (32):

  1. grayich
    /#21836088

    А цель то какова? Создать карту «яндекс пробки» для сети?

    • staticmain
      /#21836204 / +1

      Доказать абоненту, что линия в порядке и проблема в том, что у него телефон «не той модели.»

      • gecube
        /#21836252

        Доказать абоненту, что линия в порядке и проблема в том, что у него телефон «не той модели.»

        из статьи не понял — сам абонент должен на зонд заходить? Или достаточно проверки им "качества связи при помощи ookla по вашей инструкции"?

        • EmmGold
          /#21836642 / +1

          Как я понял, если клиент жалуется на связь, то ему втыкают сей девайс на сутки и мониторят.

  2. gecube
    /#21836248

    Интересная идея. Спасибо. Можно пойти дальше — роутеры Вы ведь клиентам сами поставляете? Можно попросту на роутер ставить такого "клиента" и оттуда удаленно тащить метрики по каналу. В любом случае, любой роутер от провайдера — это по сути бекдор. А если развить идею, то прямо на нем можно настраивать блокировки и все такое (привет, РКН!).

    • Revertis
      /#21836974

      В роутерах слабые процессоры, они не смогут нормально тестировать гигабит.

      • gecube
        /#21837058

        как будто в банане мощный процессор

        • Revertis
          /#21837076

          Я насчёт неё тоже сомневаюсь, но там хоть ARM, не MIPS.

          • gnomeby
            /#21837344 / +1

            MIPS MIPS`у рознь, как и ARM ARM`у. Есть суперкомпьютеры и с теми и с другими.

    • pangolin
      /#21839038

      Абонентские роутеры в маленьких провайдерах обычно берутся максимально дешёвые (вроде китайских Tenda), а на софт и оборудование для TR-069 как всегда не хватает ни денег, ни квалификации персонала.

    • /#21839052

      На самом деле проблема не в процессорах, а в самих роутерах. Внедрить сбор метрик напрямую с роутера не выйдет. Большинство роутеров, ввиду трендов по взломам, снаружи закрыты. Вплоть до пингов. TP-Link/D-Link/Netis/Tenda теперь даже не пингуются по WAN порту. Вторая проблема — внедрение нужного функционала в прошивку роутера. Задача на самом деле не тривиальная. Была попытка установки OpenWRT на подобные девайсы. Там проблема в отсутствии места ПЗУ. Оперативы хватает, а вот места на флэшке нет.

      • gecube
        /#21839186

        Закрыты снаружи, только тем не менее как-то удается их взламывать. В частности, меня просто добила атака, когда злоумышленник подменяет днс, делает фейковую страницу и получает доступ к роутеру из внутренней сети с устройства самого клиента, где, получается, запускается вредоносный js.


        Ещё не менее занятная история с этими gpon'ами от Ростелекома и мгтса и приставками iptv. Служба поддержки 100% может их как-то перенастраивать снаружи — это же удобно (!). Я уж не говорю о том, что провайдеры вмешиваются в клиентский трафик. Поэтому в "безопасность" в принципе не верю


        Поэтому не могу согласиться — безопасность безопасностью, а удаленку можно сделать.


        С зондом такая же история — устройство, как я понял, по сути ставится в периметр клиента, и на нем в теории может быть что угодно от сканирования устройств клиента на уязвимости вплоть до ВПН туннелей и обратного ssh для удаленки.


        Вплоть до пингов. TP-Link/D-Link/Netis/Tenda теперь даже не пингуются по WAN порту.

        Ок, поверю, принято.

        • /#21842132

          Взламывать удается когда админы открывают управление на wan-е. Для удобства администрирования из-дому. Мы все наши роутеры тестим на этот счет. Снаружи 22/23/80 порты по умолчанию закрыты. Я даже периодически сканер в абонентской сети запускаю. Посмотреть не нашелся ли кто-то «рисковый». Наказать как бы не могу, но вот дать совет — вполне реально.
          По доп функционалу — почти все вендоры предлагают кастомные прошивки, «под оператора», в которые, за определенную денюжку, можно, что угодно встроить. Мы пока не столь крутой оператор, что-бы кастомные прошивки заказывать.
          Вмешиваться же в пользовательский трафик я не имею права. Ни по закону ни по совести. Ну не занимаемся мы таким и, надеюсь, никогда не начнем.
          Историю про МГТС читал. Много думал. В нешифрованном трафике можно внедрять код. В шифрованном — никакой DPI не поможет. Там нагрузки колоссальные. И чем больше трафика тем проблемнее это делать. Могу напомнить историю поиска решения для DPI Российским правительством. В требованиях был анализ ssl/tls в реальном времени. И, на сколько помню, так и не нашли. Но это не точно. Не следил за историей.

          • gecube
            /#21842244

            Ну, казахи сделали просто — тупо госсертификат каждому гражданину и официальный MitM.

  3. GennPen
    /#21836352 / +1

    Если это ставится как зонд на последней миле, то не совсем понятно. Пинговать можно любой маршрутизатор до клиента. А забивать каждую минуту весь канал тестом скорости — мне кажется это не правильно. В целях диагностики должна же быть статистика (потери и т.п.) на портах маршрутизатора.

    • gecube
      /#21836368 / +1

      Я думаю, что Вы все верно говорите. Но рассмотрите такой кейс. Маршрутизатор у провайдера покажет, что утилизация канала 10%. И не больше. Как это можно интерпретировать? То ли клиент не жмёт больше (просто потому что вторая сторона, откуда клиент качает данные больше не может), то ли что-то сломано ещё. А клиент заплатил, скажем, за 100мбит по тарифу. Значит, нам на стороне клиента нужна штуковина, которая сможет и генерировать, и забирать трафик с этой скоростью. Другой вопрос, который у менЯ и возник, почему этот "зонд" не может быть интегрирован в маршрутизатор/роутер клиента

      • Busla
        /#21836872

        утилизация канала 10%. И не больше. Как это можно интерпретировать?
        Вам надо посмотреть в толковом словаре слово «утилизация», и станет понятно: как интерпретировать это выражение ;-)

      • Fodin
        /#21836940

        Да просто не подумали об этом, возможно. Или модели роутеров используются такие, куда особо не наинтегрируешь. Однако, сейчас можно взять такой роутер, который может, интегрировать в прошивку управляемый удаленно спидтест и при нужде просто менять у клиента роутер, возможно, навсегда.

  4. vrangel
    /#21836406 / +1

    Если есть деньги — внедряйте сбор так называемых параметров QoE. Я так понимаю, определенных стандартов нет, но, обычно, хватает элементарных: Количество потребителей во внутренней сети клиента, задержки, всякие tcp метрики. Удобно вылавливать проблемы, клиенты будут благодарны. Плюсы — не зависит от типа CPE.
    Если CPE однотипные, можно разработать сбор статистики wifi с CPE. Средние сигналы устройств, количество клиентов, ретрансмиты, etc.
    От измерения скорости мы ушли. Оно, как оказалось, вообще никак не кореллирует с жалобами на сервис.

  5. mig126
    /#21836746 / -3

    Давно заметил что Speedtest брешет, т.к. даже популярный торрент порой не может выдать и половину измеренной скорости. Или ютуб показывает 2-3мб/с(и соотв. не тянет 1080р), а Speedtest 20-30мб/с. Но ТП требует скринов именно из него и игнорирует альтернативные способы измерения.

    • andreishe
      /#21838310

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

      • mig126
        /#21838384 / +1

        Что ютуб, что торрент(и все другие варианты где можно максимально нагрузить канал и измерить скорость) проседают вечером в час пик, каждый день, показывая примерно одинаковую скорость. В остальное время используются вся ширина канала. Но спидтест(который .net) вечером показывает что с последней милей всё в порядке, замер в другие города показывает аналогично красивую, но бесполезную картинку.
        Количество соединений в торрент клиенте у меня ограничено, проседают даже поставленные днём на паузу закачки с тех же ip.
        Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке. Это как электрики, которым жалуешься на пониженное вечером напряжение, но они приезжают измерять его днём, когда всё в порядке.
        Пока сидел через РТ такого не было, не смотря на скорость в десять раз большую.

        • GennPen
          /#21838488

          Но спидтест(который .net) вечером показывает что с последней милей всё в порядке, замер в другие города показывает аналогично красивую, но бесполезную картинку.
          Т.е. на лицо перегруженная последняя миля, но speedtest.net говорит что всё в порядке.
          А дальше страны вы пробовали измерять? Если мне не изменяет память, власти в России запретили кеширующие сервера Гугла, поэтому весь Ютуб тянется из соседних стран. Ну а торренты и так с любой точки могут грузиться, не обязательно из соседних городов.

          • mig126
            /#21839504

            Когда Сидел на РТ Gpon(а это было всего несколько месяцев назад), скорость соединения с ютубом меньше 50мб/с не показывало, даже вечером(торренты все доступные 300мб/с использовали, а если были локальные пиры, то до 1гб/с скорость могла подниматься). Ранее сидел на ADSL и там всегда показывало максимальную скорость канала 6-9мб/с.
            А у Йоты ютуб вечером может проседать даже до 500-700кб/с. Аналогично с ним проседают и другие соединения, но там это не так критично. Т.е. проблема с последней милей есть, но её как то маскируют.

            • /#21842162

              У операторов, зачастую, несколько аплинков. Например, у кого-то имеется google cache сервер. И он его внаглую продает. Операторы подключаются к такому «владельцу» и покупают у него канал. Через какое-то время весь трафик на гугл начинает литься по данному линку а не по внешке. И оператору это очень выгодно.
              Есть более комплексные решения. Data-IX, если не ошибаюсь. Они предлагают кэш vk/facebook/google/twitter/tiktok. И все в одном флаконе.
              Вот отсюда и появляется перекос скоростей. Когда внешка у вас быстрая, а ютуб медленный. Оператор просто не рассчитал нагрузку и кэш слишком сильно загружен. Если оператора пнуть — есть вариант, что кэш расширят. И тогда ситуация выравняется.

              • mig126
                /#21842220

                Ну так тормозит то не только ютуб. Торрент, клиенты онлайн игр, стим, онлайн кинотеатры.

  6. lain8dono
    /#21836804 / -1

    В тёмное время суток на КДПВ видна пасхалка.

  7. /#21837020 / +1

    Использованный Вами (и широко используемый большинством) опенсорсный speedtest-cli на Python работает по устаревшему механизму и выдает замеры скорости достаточно сильно расходящиеся с реальным speedtest.net. Замеры ping у этого клиента вообще не адекватны. Сам автор на GitHub делает оговорку о зависимости замеров от версии Python, CPU, Memory, etc.
    Поэтому рекомендую попробовать использовать Speedtest CLI от самой Ookla, который был опубликован в октябре 2019.
    Если будете делать контейнер, то нужно использовать опции --accept-license --accept-gdpr для принятия лицензионного соглашения в не интерактивном режиме.

  8. Sha644
    /#21839880

    А чем вас pefsonar не устроил? Даже коробки выдают.

    • /#21842190 / +1

      Потому, что я о нем от вас узнал. Большое спасибо, «буду посмотреть». Беглый гугл ранее мне выдавал только коммерческие решения. За много тысяч килобакосв. А это я больше «по-фану» писал. Накатывает иногда, что-то для души сделать. По-своему. Пусть и через грабли.

  9. ValdikSS
    /#21851068 / +1

    Если хотите отслеживать что-то большее, чем просто скорость и пинг в отдельности, то воспользуйтесь профессиональной утилитой flent
    https://flent.org/