Почему рейтинг Wi-Fi роутера не предсказывает пропускную способность VPN
Заявленная скорость Wi-Fi и измеренная скорость VPN описывают разные уровни. Пройдите эту упорядоченную проверку, прежде чем покупать более быстрый роутер.
Роутер с наклейкой Wi-Fi 3,000 Mbps всё равно может передавать зашифрованный трафик со скоростью лишь малой доли этого числа, и ни одно из этих чисел не лжёт. Рейтинг радио описывает наилучшую возможную модуляцию беспроводного канала, которую поддерживает чипсет; число VPN описывает, как быстро одно устройство может протолкнуть зашифрованные пакеты через процессор роутера и наружу из вашей линии доступа. Это разные уровни, разные размеры пакетов и разные методы измерения. Считайте число на коробке потолком, до которого никто не добирается, а не прогнозом скорости вашего туннеля.
Шаг 1: Нанесите на карту четыре уровня, которые ограничивают число
Почти каждая жалоба на медленный роутер, с которой я работал, попадает в один из четырёх уровней: беспроводной канал, скорость доступа WAN, путь пересылки (NAT, межсетевой экран, отслеживание соединений) или криптографический путь VPN. Они складываются, и самый медленный уровень задаёт результат. Заявленная скорость Wi-Fi говорит только о первом уровне, и говорит о нём щедро.
Это число получается из числа потоков, умноженного на ширину канала и на самую высокую модуляцию, которую чипсет может согласовать. Радио 2x2 на 5 GHz при 80 MHz с 1024-QAM заявляется близко к 1,200 Mbps, но Wi-Fi — это разделяемая полудуплексная среда: клиенты по очереди, повторы и управляющий трафик сжигают эфирное время, а TCP добавляет свои накладные расходы. Клиент, который в идеальных условиях согласовал максимальную скорость, обычно измеряет заметно ниже половины, и ещё меньше, когда появляются соседние сети.
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
Если таблица указывает на радио, сначала исправьте беспроводную сторону: диапазон, ширину канала, расстояние. Если она указывает ниже радио, важны следующие четыре шага, и никакая покупка антенн этого не изменит.
Шаг 2: Снимите проводную базовую линию, прежде чем трогать радио
Поставьте ноутбук на Ethernet и сначала измерьте путь без туннеля, потому что это даёт вам знаменатель. Запустите инструмент пропускной способности на той стороне, на VPS или домашнем сервере, который завершает VPN, и направьте клиента на его публичный адрес, чтобы трафик прошёл через ваш роутер и линию доступа.
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
Два числа из этого блока отвечают на разные вопросы. Один поток показывает потолок на соединение, включая поведение окна TCP и любое формирование по потоку на пути. Четыре потока показывают, есть ли у канала неиспользуемая ёмкость, потому что параллельные потоки могут заполнить трубу, которую один поток не заполняет.
Сохраняйте честность: тот же хост, время суток и длительность, и ничего другого не стримит в доме. Массовая передача на тридцать секунд — правильная единица здесь, и RFC 6349, рамки тестирования пропускной способности TCP, построены именно на этом рассуждении, потому что короткие всплески и мелкие запросы льстят каналу. Запишите базовую линию до того, как что-то измените.
Шаг 3: Запустите тот же тест через туннель
Теперь повторите его к адресу туннеля удалённой конечной точки, с тем же клиентом, длительностью и числом потоков, при поднятом туннеле и без другого трафика. Отношение двух результатов говорит, сколько стоят шифрование и инкапсуляция на этом оборудовании; абсолютное число говорит, достаточно ли этого для задачи.
Следите за счётчиками во время передачи. На WireGuard wg show сообщает переданные байты на партнёра; на OpenVPN файл состояния, записываемый с интервалом, даёт ту же картину.
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
Если число туннеля близко к проводной базовой линии, VPN не является узким местом, и можно перестать его винить. Если это лишь доля базовой линии, потеря произошла внутри криптографического и пересылочного пути роутера, и следующий шаг скажет, в какой части.
Одно предупреждение: как только меняется исходящий IP, некоторые сервисы тестирования скорости тихо выбирают другой измерительный сервер, и вы в итоге сравниваете две разные цели. Закрепите адрес сервера сами.
Шаг 4: Читайте процессор как путь, а не как среднее
Роутер, показывающий 30 процентов общей загрузки процессора, всё ещё может быть насыщен: работа одного туннеля обычно попадает на одно ядро, одну очередь прерываний или один поток ядра, поэтому среднее скрывает потолок. Смотрите на цифры по ядрам и softirq вместо индикатора на панели.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoВ этом выводе важны три вещи. Одно ядро, закреплённое около 100 процентов, пока остальные простаивают, указывает на предел на соединение. Высокий %soft или занятый ksoftirqd на одном процессоре указывает на обработку пакетов на стороне приёма, которая не распределяется по очередям. А отсутствующий флаг aes означает, что у процессора нет инструкций AES, поэтому симметричное шифрование работает в программном обеспечении и стоит гораздо дороже на пакет.
Реализация тоже важна. Традиционный экземпляр OpenVPN в пользовательском пространстве обрабатывает пакеты одного туннеля в основном в одном месте, поэтому быстрый многоядерный аппарат для этого туннеля может вести себя как одноядерный. WireGuard в ядре распределяет работу по процессорам, а разгрузка канала данных OpenVPN тоже переносит обработку пакетов в ядро, но только в сборках и на платформах, которые это поддерживают. Утверждение об аппаратном ускорении на маркетинговой странице не является доказательством того, что ваш путь кода его использует.
Шаг 5: Решите, что менять, именно в этом порядке
Идите по списку вниз и остановитесь на первой верной строке, потому что изменение чего-либо ниже неё число не сдвинет.
1. Проводная прямая пропускная способность ниже того, за что вы платите: поговорите с провайдером, потому что туннель не может создать ёмкость, которую не даёт линия доступа. 2. По кабелю напрямую всё хорошо, но одно ядро закрепляется во время теста туннеля: криптографический путь роутера — это предел. 3. Процессор простаивает, но туннель медленный: проверьте MTU и фрагментацию, затем собственную ёмкость удалённой конечной точки. 4. Медленны только клиенты Wi-Fi: смените диапазон или ширину канала и примите, что заявленная скорость никогда не была числом VPN.
Когда роутер действительно является пределом, честные варианты — устройство с инструкциями AES и более быстрым путём пересылки, туннель на стороне ядра, такой как WireGuard, вместо туннеля в пользовательском пространстве, или перенос клиента на само устройство, чтобы роутер перестал шифровать. Отключение аутентифицированного шифрования ради победы в эталонном тесте не входит в их число; это меняет свойство безопасности на число, которое всё равно не совпадёт с коробкой.
Прежде чем что-либо покупать, снова прогоните шаги 2 и 3 на новом устройстве с тем же сервером и длительностью, а затем сравнивайте отношения, а не пики.