Оптимизация Wi-Fi: пошаговая диагностика, MIMO, каналы и контроль результата

Оптимизация начинается с локального измерения, а не с переключения AP на максимальную мощность. В этой инструкции мы отделим WLAN от проводной сети, соберём радио-счётчики, изменим один параметр и повторим одинаковый тест. Отдельно разберём MIMO, STBC, beamforming и их реальные ограничения. Учебный стенд: поддерживаемая точка с проводным uplink, Linux/Windows-клиент и iperf3-сервер 10.50.0.10 в разрешённой тестовой сети. Адрес замените фактическим; доступ к тестовому TCP/UDP 5201 ограничьте участниками стенда.

До изменений экспортируйте конфигурацию controller/AP и запишите SSID, security, channel, width, power, minimum rates, roaming options и VLAN. Не выполняйте тесты максимальной нагрузки во время критичных звонков или работы касс. Для удалённого сопровождения оставьте проводной канал управления и понятный способ вернуть предыдущие параметры.

1. Определить проблему и критерий успеха

Формулировка «улучшить Wi-Fi» не проверяется. Нужны помещение, устройство, приложение, время и симптом: например, потеря звонка при переходе между комнатами, низкий uplink у окна или высокая задержка при общем копировании. Согласуйте критерии с требованиями приложения. Порог -67 dBm может быть ориентиром для отдельных сценариев, но не универсальным законом качества.

Запишите baseline: throughput вверх/вниз, RTT, потери, retries, BSSID, band, channel width и PHY. Для roaming дополнительно время прерывания и результат реального звонка. Сохраните исходные настройки, чтобы ошибка измерения не стала причиной необратимого «тюнинга» всей сети.

2. Исключить проводной uplink, сервер и WAN

На switch проверьте согласованную скорость порта AP, errors/discards, PoE budget и VLAN. Скорость 100 Мбит/с на кабеле ограничит WLAN даже при высоком PHY. На сервере проверьте CPU, NIC и диск, если тестируетесь копированием файла. Для радио лучше iperf3: он не включает производительность файловой системы.

# На проводном тестовом сервере
iperf3 -s
# На проводном контрольном клиенте
iperf3 -c 10.50.0.10 -t 30 -P 1 -J > wired-up.json
iperf3 -c 10.50.0.10 -t 30 -P 1 -R -J > wired-down.json

Сначала убедитесь, что wired baseline стабилен. Если он плох, не меняйте радионастройки: исправьте проводной путь или сам сервер. Не выставляйте firewall разрешение 5201 «для всех» и не оставляйте тестовый listener на публичном интерфейсе. Руководство iperf3.

3. Снять состояние клиента и AP

ip -br address
iw dev
iw dev wlan0 link
iw dev wlan0 station dump
iw reg get

В Windows выполните:

netsh wlan show interfaces
netsh wlan show drivers
Get-NetAdapter | Select-Object Name,Status,LinkSpeed

Замените wlan0 реальным интерфейсом. Запишите модель и драйвер клиента, power-save, RSSI, NSS/MCS, tx/rx bitrate и BSSID. На AP соберите client uplink RSSI, retries, channel utilization и wired uplink. Сильный downlink при слабом uplink может означать асимметрию мощности; смена драйвера или положения клиента иногда важнее настройки AP. Официальная документация iw.

4. Измерить TCP в двух направлениях и повторить

Один результат — снимок, а не устойчивое качество. Выполните три теста по 30 секунд в каждом направлении в одном месте, затем повторите в проблемных точках. Между сериями оставьте время для нормализации нагрузки; не запускайте параллельно сканирование каналов.

for n in 1 2 3; do
  iperf3 -c 10.50.0.10 -t 30 -P 1 -J > "wifi-up-$n.json"
  iperf3 -c 10.50.0.10 -t 30 -P 1 -R -J > "wifi-down-$n.json"
done
ping -c 50 10.50.0.10 > wifi-rtt.txt

-P 1 соответствует одному TCP-потоку; многопоточный тест показывает другую нагрузку и может скрывать ограничения одного соединения. Смотрите retransmits, колебания interval throughput и направление. Большой разброс при одинаковых условиях требует изучения airtime, background clients и driver power policy, а не выбора самого красивого результата.

Для контроля RTT под нагрузкой выполняйте ping во время отдельного iperf-теста и помечайте это в отчёте. Сравнение idle ping с loaded ping помогает увидеть очереди, но ICMP может обрабатываться иначе, чем приложение.

5. Проверить ограниченный UDP и качество приложения

UDP-тест должен иметь заданную умеренную скорость, подходящую услуге. Попытка залить максимум создаст потери даже в исправной сети. Ниже — пример 5 Мбит/с, а не норматив голоса. Размер UDP payload 1200 уменьшает риск IP fragmentation на типовом пути, но MTU и инкапсуляцию всё равно проверяйте.

iperf3 -c 10.50.0.10 -u -b 5M -l 1200 -t 30 -J > wifi-udp-up.json
iperf3 -c 10.50.0.10 -u -b 5M -l 1200 -t 30 -R -J > wifi-udp-down.json

Оцените receiver loss и jitter, а не только скорость отправителя. Сервер должен разрешать UDP 5201 и TCP control connection. Если UDP полностью не проходит, сначала проверьте firewall; это не автоматически ошибка радио. После сетевых тестов воспроизведите реальное приложение: звонок, терминал, сканер, видеопоток. Нулевые потери в коротком тесте не подтверждают бесшовный roaming под нагрузкой.

6. Выбрать канал и ширину по измерениям

Сначала survey и план соседних AP. На 2,4 ГГц для плотной сети начните с 20 МГц; на 5 ГГц сравните 20/40/80 в реальных условиях. Больше ширина — больше потенциальный PHY и меньше независимых каналов. Не заставляйте все точки использовать один «самый быстрый» канал.

В UniFi параметры находятся в Radios/настройках радиомодуля; используйте текущий интерфейс установленной версии. Автоматический Channel AI выбирает каналы, но не подтверждает оптимальность width и power для задачи. Документация Channel AI. После изменения повторите baseline на том же клиенте и в тех же местах.

Соблюдайте country/regulatory profile и ограничения DFS. Не меняйте страну, чтобы получить запрещённую мощность. Для Wi-Fi 6E/7 проверьте поддержку клиента, сертификацию и разрешённый диапазон эксплуатации; наличие 6 GHz в hardware specs не является разрешением использовать его в любом месте.

7. Оценить MIMO, STBC и beamforming без маркетинговых ожиданий

Количество потоков согласуется обеими сторонами: AP 4×4 не превращает клиент 1×1 в 4×4. Spatial multiplexing даёт пользу при подходящем канале, а STBC направлен на устойчивость за счёт избыточности. Beamforming может улучшать downlink при совместимости, но не устраняет перегруженный uplink или слабый передатчик клиента. MU-MIMO/OFDMA работают по возможностям AP, клиентов и scheduler, а не по одному включённому слову в меню.

Проверьте фактический NSS/MCS из telemetry. При неожиданном одном потоке сравните драйвер, питание, antenna configuration и другой контрольный клиент. Не включайте/выключайте proprietary beamforming на всей сети без пилота: старые устройства могут реагировать иначе. Для клиента, который не поддерживает нужный режим, правильный результат настройки — стабильность в его пределах, а не максимальное число из паспорта AP.

8. Настроить мощность, размещение и roaming

Согласуйте размеры сот: большая мощность может удерживать клиента за дальней AP и увеличивать взаимные помехи. Двусторонний сигнал важнее одного client RSSI. Для проблемного места сначала проверьте расположение и ориентацию AP, препятствия и wired возможности установки дополнительной точки.

При roaming проверьте одинаковую модель безопасности SSID, VLAN, DHCP и reachable gateway на всех AP. 802.11k/v/r включайте после проверки совместимости критичных клиентов. Minimum RSSI не лечит отсутствие покрытия: он может просто отключить устройство. Разбор Wi-Fi connectivity.

# Контрольный маршрут; сервер должен отвечать на ICMP
ping -i 0.2 -c 300 10.50.0.10
# В другом терминале смотреть фактический BSSID
watch -n 1 'iw dev wlan0 link'

Сопоставьте потери с временем перехода и событиями authentication в контроллере. Если связь рвётся без смены BSSID, причина может быть помехой, DFS или uplink, а не roaming. Повторите с реальным приложением.

9. Принять изменение по измеримому результату

Меняйте один параметр за серию: width, channel, power или roaming option. Записывайте before/after и время. Если одновременно поменять шесть настроек, невозможно объяснить, какая помогла и какая создала регрессию. Приёмка включает контрольный и проблемные участки, разные модели клиентов и многоклиентскую нагрузку.

Для обработки iperf3 JSON можно использовать небольшой скрипт:

import json
from pathlib import Path
for path in sorted(Path('.').glob('wifi-*-*.json')):
    try:
        data = json.loads(path.read_text(encoding='utf-8'))
    except (OSError, json.JSONDecodeError) as exc:
        print(path.name, 'ERROR', str(exc))
        continue
    if 'error' in data:
        print(path.name, 'ERROR', data['error'])
        continue
    end = data.get('end', {})
    metric = end.get('sum_received') or end.get('sum')
    if not metric or 'bits_per_second' not in metric:
        print(path.name, 'NO_METRIC')
        continue
    print(path.name, round(metric['bits_per_second'] / 1_000_000, 2), 'Mbit/s')

Это summary throughput; для jitter/loss и отдельных intervals откройте соответствующие поля исходного файла. Скрипт не скрывает error и missing metric как «0 Мбит/с». Выберите изменение, которое улучшает задачу и не ухудшает критичные клиенты, а не вариант с максимальной разовой скоростью.

10. Вернуть исходные параметры и передать сеть в мониторинг

Возврат выполняют по сохранённому AP/controller config с проверкой каналов управления, а не reset устройства в заводское состояние. Если изменялись только width/power, возвращайте именно их, сохраняя последующие легитимные изменения других администраторов. После rollback повторите baseline и проверьте critical SSID.

Уберите временные разрешения 5201, остановите iperf3 server и сохраните отчёт: схема, firmware, клиенты, точки измерения, raw JSON, радио-счётчики и решение. В постоянном мониторинге нужны wired uplink, radio utilization/retries, DHCP/DNS, authentication errors и доступность AP. Обновление драйверов и firmware сначала проходит пилот. Подробная механика канала, hidden nodes и PHY разобрана в статье о нюансах Wi-Fi: она помогает объяснить результат, а не только повторить настройку.