И почему объективное измерение скорости мобильного интернета - это непростая инженерная задача
Для инженеров мобильного оператора контроль качества сети (QoS) и пользовательского опыта (QoE) является критически важной задачей. В условиях высокой конкуренции и растущих требований к трафику недостаточно просто знать, что «интернет работает». Необходимо иметь точные и объективные инструменты, способные не только зафиксировать пиковую пропускную способность канала, но и провести глубокую диагностику, определив, где именно возникла проблема: в радиоинтерфейсе (RAN), в транспортной сети, на сервере провайдера контента или в самом устройстве абонента.
На первый взгляд, казалось бы, задача проста: скачать файл известного объема, замерить время и вычислить скорость. Однако на практике эта «простая» задача превращается в сложный инженерный вызов. Мобильная сеть - это динамическая среда с нестабильными параметрами: задержка (RTT) может скакать от 15 до 100 мс, вероятность потери пакетов варьируется в зависимости от загрузки соты и хендоверов (переходов из одной соты в другую), а каналы загрузки (DL) и выгрузки (UL) часто асимметричны.
Именно поэтому стандартные методы тестирования, основанные на простом скачивании файла, часто дают искаженную картину. Разные приложения могут показывать результаты, отличающиеся в разы, даже при измерении в одной и той же точке сети.
В этой статье мы разберем почему измерение скорости мобильного интернета вызывает массу сложностей, как протокольные особенности влияют на результаты тестов и почему выбор правильного инструмента критичен для объективной оценки производительности сети.
Часть 1. Скорость передачи данных
Начнём с азов, которые вызывают проблемы скорости. Представим, что мы разработчики архитектуры приложения по измерению скорости. С какими очевидными и не очень проблемами мы столкнёмся?
Для тестов мы хотим передать некие данные. И тут уже возникает дилемма. Транспортный уровень модели OSI нам предлагает выбор протокола TCP или UDP. Выбор этот зависит от того, какую ситуацию мы хотим проверить. Если мы хотим проверить как, например, будут работать HTTPS сервисы, то очевидный выбор TCP, но если нам важно проверить реальную ширину интернет канала как в Downlink (DL), так и в Uplink (UL) или же тестом мы хотим сымитировать популярный в настоящее время для стриминговых сервисов протокол QUIC, то тогда нам более релевантен будет UDP.
А разве при выборе TCP/UDP будет отличаться скорость? Да, и зачастую очень сильно.
TCP- это протокол с подтверждением доставки. Одним из ключевых факторов является RTT(Round-Trip-Time) или, проще говоря, время за которое пакет может дойти от сервера к клиенту и вернутся обратно.
Классической формулой, определяющей придельную скорость передачи TCP, является формула Мэтиса
В знаменателе формулы мы видим, что в случае TCP рост RTT влияет даже сильнее, чем кратный ему рост потерь пакетов! Почему нам это важно? Потому что в случае, если мы планируем измерять скорость мобильного интернета, то должны учитывать, что в мобильной сети RTT не является стабильным параметром и легко может плавать от 15 до 100 мс и больше. Влияет на RTT в мобильных сетях несбалансированность каналов UL и DL (ёмкость канала DL в несколько раз выше), загрузка сотовой сети и вызванные этим очереди пакетов в буфере базовой станции, а также хендоверы от одной базовой станции к другой, когда для IP пакетов динамически перестраиваются маршруты между БС. У протокола UDP нет зависимости от RTT, данные идут заранее заданным тестировщиком сплошным потоком, что позволяет измерить максимальную пропускную способность на канальном/физическом уровне. Кроме этого, протокол UDP даёт возможность измерить джиттер, это важно для real-time сервисов.
Получается использовать TCP для измерения скорости мобильной сети нельзя раз так всё плохо?
Без понимания работы протокола TCP скорее всего наше приложение будет показывать скорости существенно ниже реальной пропускной способности. Но при должной настройке TCP вполне пригоден для измерения скорости. Забегая вперёд, скажу, что большинство сервисов по измерению скорости используют именно TCP с разной степенью оптимизации проблем данного протокола.
Как сервер влияет на скорость передачи данных?
Самое очевидное — это пропускная способность нашего сервера. Для стабильной работы при множестве единовременных измерений нужен сервер с сетевым интерфейсом как минимум 10G портом. И самое простое, приходящее на ум решение - арендовать VPS-ку, таит в себе ряд подводных камней.
Провайдер VPS должен иметь «жирные» сетевые стыки с основными телеком провайдерами и честно делить ресурс физического канала согласно тарифу. А также следить за нагрузкой, контролировать, чтобы не возникало задержек, вносимых гипервизором на обработке трафика в виртуальном коммутаторе. В современных облачных средах эта проблема может решаться через технологии аппаратной виртуализации ввода-вывода, таких как SR-IOV. Но в любом случае, параметры VPS сервера необходимо детально уточнить.
И даже если подходящий сервер будет найден, то другая проблема заключается в том, что сервер должен быть не один. Физическое расстояние между сервером и клиентом само по себе вносит задержку в распространение сигнала. Очевидно, что если сервер в Москве, а клиент во Владивостоке, то даже при самом хорошем сервере скорость будет снижаться из-за задержки.
В идеале, тестовый сервер должен находится в каждом крупном городе.
Как TCP влияет на скорость передачи?
Выше мы уже разобрали, что ключевыми факторами, влияющими на скорость TCP является задержка и потери пакетов. Первое и самое простое решение, чтобы улучшить работу TCP — использовать многопоточную передачу данных. Если параллельно запустить десяток TCP сессий, то такое соединение будет меньше подвержено эффекту «медленного старта», когда скорость передачи, зачастую, не успевает разогнаться до максимума за короткое время теста. Кроме того, многопоточность позволяет снизить влияние потери пакетов в отдельных сессиях на суммарную пропускную способность. Также многопоточность уменьшает влияние на скорость от нарушения порядка принимаемых IP пакетов. Но обратная сторона большого числа сессий - это рост overhead-ов, большая нагрузка UL канала ACK сообщениями, что может быть критично в случае несимметричного DL/UL канала, а также нагрузка на «железо» смартфона, связного с обработкой большого числа сессий. Оптимальное количество TCP сессий обычно лежит в диапазоне 5-10 сессий и зависит от используемого на сервере механизма TCP Congestion Control.
Собственно алгоритм TCP Congestion Control является вторым важным механизмом адаптации TCP. Современные алгоритмы Congestion Control способны значительно модернизировать формулу Мэтиса, указанную выше, и снизить зависимость скорости TCP от задержек. Оптимальный же метод TCP Congestion Control будет зависеть от архитектуры и логики нашего приложения. Отдельно останавливаться на алгоритмах не буду, на Хабре есть хорошие статьи на эту тему. Скажу лишь, что скорее всего оптимальным выбором для speedtest сервера (с прицелом на тесты мобильного интернета) будет алгоритм BBR. Подробности его работы прекрасно описаны в блоге Яндекса.
Подводя итоги:
Нам нужно много качественно настроенных серверов с высокой пропускной способностью. Также хорошо, если наше приложение будет измерять не только TCP, но и UDP.
Часть 2. Средства измерения скорости
Перейдём ко второй части: посмотрим какие варианты для измерения скорости сети есть сейчас, после запрета в РФ самого популярного сервиса Ookla Speedtest. Из предыдущей части мы поняли, что сервис качественного измерения скорости — это не простой технически и довольно затратный финансово проект. Я выделил 6 наиболее релевантных сервисов измерения скорости, имеющих несколько серверов в России.
Какие на данный момент есть аналоги для измерения скорости?
Яндекс.Интернетометр, Мегабитус, nPerf, Merilo, ПроСеть, Госуслуги.
Краткое описание сервисов:
Сервис | Описание |
Яндекс Интерентометр | Сервис от Яндекса с широкой географией серверов, поддержкой IPv6 и шифрованием TLS 1.3. Есть как WEB версия, так и мобильное приложение, дублирующее функционал WEB. |
Мегабитус | Отечественный сервис от ИА Telecom Daily, размещенный на серверах Яндекса и операторов связи; отображает карту измерений других пользователей и доступен в мобильных магазинах приложений. |
NPerf | Популярный французский сервис с ограниченным количеством серверов в РФ; позволяет вручную выбирать сервер, измеряет скорость открытия сайтов, качество стриминга YouTube и показывает статистику по операторам за последние 14 дней. |
Merilo | Сервис от платформы VIGO с несколькими серверами в крупных городах России; измеряет время старта видео при разных битрейтах, проверяет доступность пользовательских URL и пинг; доступен в AppStore и Play Market. |
ПроСеть | Сервис от ЦМУ Роскомнадзора, доступный только в RuStore; шифрование TLS 1.3; предоставляет функции проверки доступности ресурсов, трассировки маршрута и, неожиданная функция для приложения измерения скорости: приложение позволяет подать жалобу в РКН! |
Госуслуги | Встроенный в мобильное приложение сервис проверки скорости, имеет широкую географию серверов, шифрование TLS 1.3 По информации СМИ, в качестве базы (вероятно SDK) используется сервис Мегабитус. |
На примере Госуслуг и Яндекса посмотрим, как работает измерение скорости в данных приложениях.
Госуслуги
Посмотрим с использованием Wireshark, что на протокольном уровне использует приложение.
По RIPE IP мы видим, что сервер развёрнут на виртуалке Yandex Cloud. Используется TCP, в 7 потоков.
Яндекс Интернетометр
Также при помощи Wireshark посмотрим как реализовано измерение скорости на уровне IP.
Используется TLS 1.3. Закачка у Яндекса идёт в 3 потока. Но интересно то, что у Яндекса разделение потоков идёт не «классически» по портам, а по IP адресам. Все 3 адреса принадлежат одной ASN, но разным хостам:
cloudcdn-mar-63.cdn.yandex.net
cloudcdn-m9-4.cdn.yandex.net
cloudcdn-std-10.cdn.yandex.net
Это интересное решение, которое, по всей видимости, позволяет Яндексу балансировать нагрузку между различными CDN, которые, вероятно, географически разнесены и имеют разную транспортную маршрутизацию. Если так, то такое решение заметно повышает стабильность соединения.
TCP поток, как видно, близок к идеальному — быстрый старт, ровная «полка» скорости.
К сожалению, ни Яндекс, ни Госуслуги не дают возможности выбора сервера, что может быть важно, например, в сравнении разных операторов. При случайном выборе серверов нельзя быть уверенным, что измерения проходят в одинаковых условиях.
Ряд сервисов, таких как Merilo, NPerf дают вручную выбирать тестовый сервер, что является плюсом.
А что, если хочется довольно точно измерить скорость до своего собственного сервера?
Даже, возможно, до домашнего роутера? Можно, конечно, просто скачивать тестовый файл, но из-за описанных выше ограничений это часто не даст объективной картины.
Наиболее точно измерить скорость позволит тул iPerf3 — это бесплатная кроссплатформенная консольная утилита для тестирования пропускной способности сети. Сайт проекта: https://iperf.fr/
iPerf3 позволяет менять протоколы UDP/TCP, изменять количество потоков, менять характеристики TCP. Плюсом для «домашнего» тестирования является то, что iPerf3 сервер и клиент можно запустить даже на многих популярный роутерах, таких как Keenetic, MikroTik и др.
Пример теста iPerf через мобильный клиент (Android)
Что используем мы в МегаФон?
Всё зависит от задачи. Когда необходимо проверить пользовательский сервис, то приоритетом является измерение скорости до серверов контент-провайдера, например Яндекс.
Если же нам необходимо проверить скорость непосредственно внутри контура компании, например, чтобы определить, как отрабатывает радиосеть (RAN), то используем iPerf тестирование до собственных серверов.
Какой ещё аспект тестирования стоит раскрыть подробнее?
Валентин Кузьмин
Главный эксперт по сквозной оптимизации в компании «МегаФон»
