Качественный Wi-Fi — это сеть, в которой работают нужные приложения в нужных местах и при обычной нагрузке. Полная шкала сигнала и высокий результат одного speedtest этого не подтверждают. Видеозвонок может прерываться при хорошей скорости загрузки файла, а складской терминал — терять сессию только во время перехода между точками.
Проверять сеть нужно по нескольким независимым признакам: покрытию, полезной скорости, задержке, потерям и работе при перемещении. Ниже — последовательность обследования корпоративной сети с примерами для MikroTik, Windows и iperf3. Она помогает отделить проблему радиоканала от ограничений проводной сети, клиента, сервера и доступа в интернет.
Сначала определите, какую работу должна выдерживать сеть
Запишите, какие приложения критичны: видеосвязь, телефония, удалённый рабочий стол, файловый обмен, мобильная 1С или терминалы сбора данных. Затем укажите рабочие зоны, типичные клиентские устройства и ожидаемое число одновременно активных пользователей. Фраза «интернет должен быть быстрым» не задаёт проверяемый результат.
Для каждой задачи согласуйте критерии: где она должна выполняться, при какой нагрузке и какие прерывания допустимы. Для файлового обмена важны устойчивая полезная скорость и время передачи. Для разговора — задержка, вариация времени доставки и потери. Для мобильного терминала — сохранение сеанса на рабочем маршруте. Пороговые значения берите из требований приложения и условий бизнеса, а не из универсального списка для всех сетей.
До обследования сохраните конфигурации и составьте план точек, каналов и проводных подключений. Сам контроль качества не требует немедленно менять настройки: сначала нужно получить исходные измерения. План размещения и порядок монтажа разобраны в статье о точках доступа и юстировке антенн MikroTik.
Что именно показывают основные метрики
RSSI характеризует принимаемый сигнал. SNR показывает, насколько он превышает шум. Эти показатели помогают оценить радиосреду, но не описывают всю работу сети. При хорошем сигнале эфир может быть занят, а проводной порт точки — ограничивать передачу.
PHY rate, или скорость радиосоединения, — параметр физического уровня. Это не скорость копирования файла. Эфир расходуется также на служебные кадры, подтверждения и повторные передачи. Реальную полезную скорость приложения оценивайте отдельно и не обещайте пользователю число из поля Tx/Rx Rate.
RTT — время прохождения запроса к узлу и ответа обратно. Обычный ping измеряет именно такую двустороннюю задержку, а не задержку в одном направлении. Jitter характеризует изменчивость времени доставки; способ его вычисления зависит от инструмента и протокола. Разброс значений ping и jitter в отчёте UDP-теста — разные показатели, хотя оба помогают заметить нестабильность.
Потери могут наблюдаться на разных уровнях. Неполученный ответ ICMP, потерянный UDP-пакет и повторная передача радиокадра не равнозначны. TCP способен скрыть часть потерь повторной отправкой, заплатив временем и снижением скорости. Поэтому нулевая потеря ping сама по себе не означает отсутствия проблем в радиоэфире.
Подготовьте повторяемую схему измерений
Понадобятся беспроводной клиент и отдельный компьютер с проводным подключением. Между ними желательно оставить только исследуемую локальную инфраструктуру, без интернета и лишнего VPN. Укажите фактический путь трафика: клиент — точка — коммутатор — тестовый сервер. Если на пути есть маршрутизатор или firewall, учитывайте их влияние.
Проверьте скорость Ethernet-портов, загрузку тестовых компьютеров и отсутствие фоновых обновлений. До беспроводного теста выполните такой же тест по кабелю. Если уже проводной результат не соответствует задаче, сначала разберитесь с сервером, клиентом, линками и обработкой трафика.
Используйте совместимые версии iperf3 на обоих концах; iperf2 и iperf3 не являются взаимозаменяемыми протоколами. Различия инструментов описаны у разработчиков ESnet. Не запускайте генератор нагрузки на самой точке и не называйте результат чистой скоростью Wi-Fi: её процессор может ограничивать генерацию трафика.
Для сравнения сохраняйте условия: модель клиента, ОС и драйвер, положение устройства, питание, место и время. Каждый сценарий повторите несколько раз. Отмечайте не только лучший результат, но и разброс. Подход к изоляции беспроводного участка рассмотрен в руководстве Cisco по проверке пропускной способности Wi-Fi.
Обследуйте покрытие на реальных рабочих местах
Отметьте контрольные позиции на плане: рабочие столы, переговорные, помещения за сложными перегородками, углы склада и переходы между точками. Обходите один маршрут с одинаковым положением клиента. Для разных классов устройств выполняйте отдельные проходы: ноутбук с хорошими антеннами не заменяет телефон или промышленный терминал.
Пассивное обследование наблюдает за радиосредой без проверки полезной передачи вашего приложения. Активное включает подключение и передачу трафика. Расчётная карта покрытия помогает планировать, но после монтажа её проверяют измерениями. Эти виды обследований разделены в рекомендациях Cisco по site survey.
На MikroTik сначала определите драйвер. В новом WiFi используйте:
/system resource print
/system package print
/interface wifi print detail
/interface wifi registration-table print detailДля старого Wireless вместо нового меню:
/interface wireless registration-table print stats
/interface wireless monitor wlan1 oncewlan1 замените нужным интерфейсом. Команды нового WiFi сверены со справочником RouterOS 7.26. В его таблице регистраций signal показывает приём от клиента на точке; сигнал точки на клиенте измеряется отдельно. Доступные поля и их типы перечислены в WiFi registration-table.
В Windows посмотреть подключение можно командой:
netsh wlan show interfacesСохраните имя интерфейса, SSID, BSSID, канал и доступные сведения о соединении. Показанный процент сигнала не следует автоматически переводить в точное число dBm. Набор сведений зависит от версии ОС, драйвера и прав доступа к данным Wi-Fi. Команда описана в Microsoft Learn.
Заполняйте журнал по месту и времени. Цветная карта покрытия полезна только вместе с исходными точками измерений и условиями; красивый градиент не заменяет измерения в зоне жалобы. Для интерференции, отражений и экранирования используйте объяснения из статьи о сигнале и мощности MikroTik.
Измерьте TCP-скорость в обоих направлениях
В примерах 192.0.2.10 — условный адрес проводного сервера. Замените его реальным IP. Запустите iperf3 на сервере и разрешите доступ к тестовому порту только из нужного сегмента на время проверки. По умолчанию используется порт 5201:
# На проводном сервере
iperf3 -s
# На беспроводном клиенте: передача к серверу
iperf3 -c 192.0.2.10 -t 30 -i 1
# На том же клиенте: передача от сервера
iperf3 -c 192.0.2.10 -t 30 -i 1 -RТак вы отдельно увидите поведение двух направлений. Затем при поддержке установленной версией можно проверить одновременную передачу туда и обратно:
iperf3 -c 192.0.2.10 -t 30 --bidirРезультат одновременного обмена нельзя напрямую сравнивать с суммой отдельных максимумов: трафик разделяет ресурсы. Wi-Fi также не превращается в полнодуплексный Ethernet из-за запуска двунаправленного теста. Ключи -R и --bidir описаны в официальном справочнике iperf3.
Начните с одного потока. Несколько параллельных TCP-потоков могут дать другой результат, но это уже отдельный сценарий нагрузки. Записывайте число потоков и не выдавайте достигнутый таким способом максимум за скорость любой пользовательской операции. Сравнивайте одинаковые режимы до и после изменения сети.
Проверьте задержку без нагрузки и во время передачи
Запустите ping до проводного сервера или другого известного локального узла. Для Windows и Linux команды отличаются:
# Windows
ping -n 100 192.0.2.10
# Linux
ping -c 100 192.0.2.10Сначала измерьте простой, затем повторите проверку во время контролируемой передачи. Отмечайте рост задержки, провалы и потери. Не ограничивайтесь средним значением: короткие всплески могут мешать разговору, оставаясь незаметными в среднем. При наличии подробного журнала полезно сравнивать также высокие перцентили, сохраняя период наблюдения и метод расчёта.
Один узел может ограничивать ответы ICMP, поэтому сравните несколько понятных целей и проверьте приложение. Задержка до публичного сервера включает провайдера и внешний маршрут; она не является самостоятельным измерением качества локального радиоучастка.
Насыщение канала тестом может намеренно ухудшить работу остальных пользователей. Начинайте с согласованной умеренной нагрузки и повышайте её по сценарию. Если при свободной сети всё хорошо, а при передаче RTT резко растёт, исследуйте очереди, конкуренцию за эфир и ограничения пути. Это направление диагностики, а не доказательство единственной причины.
UDP, потери и jitter: как не перепутать тест с перегрузкой
Для проверки потерь и jitter можно выполнить UDP-тест с явно заданной нагрузкой. Следующий пример отправляет поток с целевой скоростью 10 Мбит/с и ограниченной длиной UDP-пакета:
iperf3 -c 192.0.2.10 -u -b 10M -l 1200 -t 30
iperf3 -c 192.0.2.10 -u -b 10M -l 1200 -t 30 -RЗначения приведены для демонстрации, а не как требования к вашей сети или модель любого телефонного звонка. На пути должны быть разрешены и управляющее TCP-соединение, и UDP-трафик теста. Параметры UDP и ограничения скорости перечислены в справочнике iperf3.
Смотрите отчёт принимающей стороны. Если предложенная нагрузка превышает доступную ёмкость, потери ожидаемы; это не доказывает неисправность оборудования. Повторите тест с меньшей нагрузкой и сопоставьте результат с реальным приложением. Выбранный размер пакета не гарантирует отсутствие фрагментации на любом маршруте — особенно если тест проходит через туннель.
Число jitter из iperf3 не равно задержке в одном направлении и не измеряет автоматически качество голоса. Для телефонии полезны статистика самого клиента и анализ соответствующего RTP-потока. Wireshark позволяет исследовать потери и jitter в RTP Stream Analysis. Захват должен содержать нужный поток; возможность анализа зависит от протокола и доступности данных. Отсутствующий в захвате пакет не всегда был потерян в сети: причиной может быть сам сбор трафика.
Роуминг: проверяйте смену точки и сохранение приложения
Одинаковый SSID не гарантирует незаметный переход. Клиент принимает решение о смене точки с учётом своих алгоритмов; сеть может предоставлять вспомогательные механизмы. Для нового WiFi поддержка 802.11r/k/v и условия fast transition зависят от конфигурации и клиентов. Проверяйте их по руководству MikroTik WiFi, не переносите настройки старого CAPsMAN автоматически.
Выберите реальный маршрут: рабочий стол — переговорная, проход между рядами склада, лестница между этажами. Запустите рабочий разговор или типовую сессию и пройдите маршрут в обе стороны с обычной скоростью. Повторите проход на каждом критичном типе устройств. Для каждого перехода отметьте исходный и конечный BSSID, место переключения и состояние приложения.
Обычный ping с интервалом порядка секунды может показать грубый провал, но не измеряет точно прерывание в десятки миллисекунд. Для такой точности нужны подходящие временные метки, журналы клиента или контроллера и при необходимости захват кадров. Синхронизируйте часы источников: иначе сопоставление событий будет ненадёжным.
Смена BSSID без разрыва приложения — полезный результат; отсутствие смены тоже не всегда ошибка, если текущая связь выполняет требования. Если клиент цепляется за дальнюю точку и приложение ухудшается, проверьте покрытие, перекрытие зон, каналы и поддержку функций клиентом. Принудительное отключение по слабому сигналу не заменяет наличие хорошей альтернативной точки.
Повторите проверку с типичной одновременной нагрузкой
Один ноутбук в пустом офисе описывает только этот сценарий. Повторите контроль в рабочее время или на согласованной модели нагрузки: несколько разговоров, обычный файловый обмен, активные терминалы. Десятки потоков с одного ноутбука не воспроизводят десятки независимых радиоклиентов, их расположение и конкуренцию за эфир.
Во время теста наблюдайте число подключённых устройств, проводной uplink и процессор точки. На MikroTik пригодятся команды:
/system resource print
/interface ethernet print stats
/interface ethernet monitor ether1 once
/log print where topics~"wifi|wireless"Замените ether1 действительным uplink-портом. Для накопительных счётчиков важен прирост за интервал, поэтому сохраните показания до и после. При анализе смены частоты сопоставьте время жалобы с DFS и другими событиями. Сканирование эфира на рабочем радио проводите отдельно, в окно обслуживания, чтобы не принять собственное отключение клиентов за дефект сети.
Как читать результат и организовать дальнейший контроль
Если по кабелю и Wi-Fi одинаково плохо, начните с общего участка пути. Если проблема только у одного клиента в одном месте, сравните его с другим устройством и проверьте драйвер, питание и ориентацию. Если RSSI хороший, но задержка растёт вместе с загрузкой, исследуйте эфирное время и очереди. Если провал возникает только при движении, восстановите последовательность BSSID и событий аутентификации.
Это примеры интерпретации признаков, а не результаты испытания конкретного объекта. В каждом случае подтвердите гипотезу повторным сравнением. Меняйте один существенный параметр за шаг и сохраняйте предыдущую конфигурацию. Одновременная смена положения точки, мощности, канала и драйвера клиента делает выводы ненадёжными.
Сохраните отчёты в файл, например для TCP-проверки:
iperf3 -c 192.0.2.10 -t 30 -J > wifi-tcp-upload.json
iperf3 -c 192.0.2.10 -t 30 -R -J > wifi-tcp-download.jsonХраните исходные результаты рядом с протоколом проверки Wi-Fi: места, время, версии, нагрузку, критерии и принятое решение. Не публикуйте внутренние адреса, MAC-адреса, имена сотрудников и содержимое рабочих пакетов вместе с открытой статьёй или отчётом для посторонних.
После приёмки повторяйте контроль после перестановки рабочих мест, изменения числа клиентов, замены точек, обновления драйверов и значимых изменений конфигурации. Для постоянного наблюдения пригодны сведения о доступности точек, uplink, повторяющихся разрывах и результатах синтетической проверки. Доступный контроллер и отвечающая на ping точка ещё не означают, что пользователь может подключиться, получить адрес и открыть нужный сервис.
По окончании испытаний остановите iperf3-сервер, уберите временные разрешения и отключите временный подробный сбор, если он использовался. Итог проверки — подтверждённая работа приложений на согласованных маршрутах и под согласованной нагрузкой, а не максимальное число мегабит в одном удачном прогоне.