Бенчмарк протоколов VPN: методика измерения

MAATRIX

Сравнить WireGuard и OpenVPN «на глаз» — переключиться между двумя клиентами и посмотреть на спидометр в приложении — способ получить случайное число, а не ответ на вопрос, какой протокол быстрее. Между двумя такими замерами меняется добрый десяток переменных одновременно: загрузка CPU в моменте, время суток, число TCP-потоков, MTU, настройки шифра — и ни один спидометр их не показывает по отдельности. Ниже — методика, которая фиксирует все переменные, кроме одной (собственно протокола), и даёт цифры, которые действительно можно класть рядом друг с другом.

Почему обычное сравнение врёт

Прежде чем говорить о методике, стоит перечислить, что именно портит «честность» большинства любительских сравнений протоколов:

• Разные серверы или разные локации. Сравнение WireGuard на одном VPS и OpenVPN на другом ничего не говорит о протоколах — вы сравниваете два разных канала, двух разных соседей по гипервизору и два разных маршрута до клиента.
• Разное время замера. Полоса на арендованном канале плавает в течение суток из-за загрузки соседей и пиковых часов у аплинка. Прогон WireGuard в 10:00 и OpenVPN в 23:00 — это сравнение времени суток, а не протоколов.
• Один прогон вместо серии. Разброс между отдельными запусками iperf3 на реальном канале в 10-15% — это норма, а не сигнал. Один «удачный» результат ничего не доказывает.
• Разные тестовые инструменты. Спидтест в браузере, встроенный счётчик клиента и iperf3 меряют разные вещи и дают разные числа даже на одном и том же туннеле в одну и ту же секунду.
• Скрытая асимметрия в настройке. Если один протокол настроен с MTU по умолчанию, а второй — с подобранным вручную, вы меряете качество настройки, а не протокол как таковой.

Задача методики ниже — убрать все эти источники шума, оставив разницу, которая объясняется именно протоколом.

Один сервер, одна виртуалка — почему это принципиально

Самая частая ошибка — тестировать протоколы на разных VPS, пусть даже «одинаковых по тарифу». Разные VPS почти никогда не идентичны: разные физические хосты, разная загрузка соседей по CPU, иногда разный аплинк дата-центра даже в пределах одной локации провайдера.

Правильная база для сравнения — один и тот же сервер с несколькими протоколами, поднятыми параллельно на разных портах:

# на одном VPS одновременно
wg0        — WireGuard, порт 51820/udp
openvpn0   — OpenVPN, порт 1194/udp
xray0      — Xray/VLESS, порт 443/tcp

Это не «боевая» конфигурация — держать три VPN на одной машине постоянно смысла нет, — а тестовый стенд на время бенчмарка. Установка каждого протокола отдельно разобрана в соответствующих гайдах; если ещё не определились, с чего начинать список кандидатов на тест, полезно сначала свериться с гидом по выбору протокола под сценарий — так вы не тратите время на протоколы, которые заведомо не подходят под вашу задачу.

Клиент тоже должен быть один и тот же — физически одна машина, один сетевой интерфейс, один провайдер до неё. Переключение между протоколами клиент делает поочерёдно, не параллельно: параллельные туннели с одного клиента конкурируют за одну и ту же физическую полосу и искажают оба результата.

Фиксируем сеть: трасса, время суток, повторы

Даже на одном сервере и одном клиенте сеть между ними не статична. Перед тем как считать числа сопоставимыми, зафиксируйте:

• Трассу. Снимите mtr или traceroute до сервера перед каждой серией замеров и убедитесь, что маршрут не меняется между прогонами разных протоколов — провайдер может перекинуть трафик на другой аплинк, и тогда вы снова сравниваете не протоколы, а маршруты.

mtr -rw -c 20 203.0.113.10

• Время суток. Тестируйте каждый протокол в нескольких временных окнах — например, утро/день/вечер, — а не весь список протоколов подряд в одном окне и следующий список в другом. Лучше чередовать: WireGuard в 10:00, OpenVPN в 10:15, снова WireGuard в 14:00, снова OpenVPN в 14:15 — так суточные колебания канала «размазываются» поровну между протоколами, а не достаются одному из них.
• Число повторов. Минимум 5 прогонов на протокол на временное окно, лучше 8-10. Берите медиану, а не среднее — среднее сильно тянет один выброс (например, случайный всплеск нагрузки на хостинге в момент теста).
• Длительность каждого прогона. Короткий тест (5-10 секунд) в основном меряет slow start TCP и мало говорит об установившейся скорости. Для сравнения протоколов берите не меньше 20-30 секунд на прогон — детали по самому инструменту и его флагам разобраны в статье про измерение скорости VPN через iperf3.

Приводим протоколы к одному знаменателю

Это самый нарушаемый пункт методики: сравнивать протоколы «как есть из коробки» — это на самом деле сравнивать не протоколы, а качество настройки по умолчанию. Часть асимметрии убрать можно и нужно, часть — принципиально нельзя, и её стоит явно зафиксировать как известное ограничение, а не прятать.

Что выравниваем:

Что выровнять нельзя — и это нормально: WireGuard работает в ядре Linux (или как высокопроизводительный userspace-процесс на других системах) и почти всегда однопоточнее по накладным расходам, чем классический OpenVPN, который по умолчанию однопоточен и на слабом vCPU может упираться в производительность ядра шифрования раньше, чем в канал. Это не баг методики — это реальное архитектурное различие протоколов, и его стоит зафиксировать в отчёте отдельной строкой, а не пытаться «исправить» настройками. Подробнее о таких структурных различиях и о том, что переносится, а что нет при смене протокола, — в статье про миграцию между VPN-протоколами без даунтайма.

Перед тестом полезно проверить, не упирается ли шифрование в CPU само по себе, вне зависимости от сети:

openssl speed -evp aes-256-gcm
openssl speed -evp chacha20-poly1305

Если один из протоколов на вашем сервере вынужден использовать более медленный по факту алгоритм (например, из-за отсутствия AES-NI на конкретном тарифе), это тоже часть честного отчёта — просто не выдавайте разницу, вызванную CPU, за разницу протоколов.

Что и как измерять

Пропускная способность — не единственная и часто не главная метрика. Полный набор для сравнения:

1. Throughput TCP, один и несколько потоков

iperf3 -c 10.66.0.1 -t 30 -P 1
iperf3 -c 10.66.0.1 -t 30 -P 4

Разница между -P 1 и -P 4 показывает, насколько протокол (точнее, TCP поверх него) упирается в размер окна на канале с задержкой — это важно фиксировать отдельно от «сырой» пропускной способности.

2. Throughput UDP и потери

iperf3 -c 10.66.0.1 -u -b 200M -t 30

Смотрите на Lost/Total Datagrams — высокий bitrate при заметных потерях не победа, а признак того, что канал (или сам туннель под нагрузкой) не тянет такую скорость без деградации.

3. Задержка и джиттер поверх туннеля

ping -c 100 10.66.0.1

Сравнивайте не только среднюю задержку, но и разброс (mdev в выводе ping) — протоколы с более тяжёлой инкапсуляцией иногда дают сопоставимую среднюю задержку, но заметно больший джиттер, что критично для голоса и игр даже при неплохом throughput.

4. Нагрузка на CPU во время теста

mpstat -P ALL 1 30

Снимайте на обеих сторонах — клиенте и сервере — параллельно с iperf3. Если один протокол даёт похожий throughput ценой заметно большей загрузки CPU, это тоже релевантная метрика, особенно если сервер потом будет обслуживать не одного клиента, а десятки.

5. Время установления соединения

Разница между «уже готовым» туннелем (WireGuard, где соединение по сути stateless до первого пакета) и протоколом с полноценным TLS-хендшейком (OpenVPN, Xray с TLS) может быть заметна для сценариев с частым переподключением — роуминг между Wi-Fi и мобильной сетью, засыпание устройства. Замерить просто:

time (wg-quick up wg0 && ping -c1 -W2 10.66.0.1 >/dev/null && echo OK)

Для OpenVPN и Xray аналогично — время от старта клиента до первого успешного пинга через туннель, по логам с таймстампами.

6. Поведение под искусственно ухудшенным каналом

Реальный интерес — не только «идеальные» условия, но и то, как протокол ведёт себя при потерях и задержке. На сервере (или на промежуточном роутере) можно эмулировать деградацию канала через tc netem:

tc qdisc add dev eth0 root netem delay 100ms loss 1%
# тест
tc qdisc del dev eth0 root netem

Протоколы с разным congestion control и разной реакцией на потери UDP-инкапсуляции (WireGuard, будучи тоньше, обычно быстрее отдаёт деградацию наверх, TCP-стеку клиента, тогда как некоторые реализации OpenVPN добавляют собственную буферизацию) могут показать разное поведение именно здесь, а не в идеальных условиях без потерь.

Таблица прогонов и как читать результат

Собирайте результаты в единую таблицу — это дисциплинирует и сразу показывает пробелы в замерах:

Заполняйте медианой из 5-10 прогонов на протокол на каждое временное окно, а не первым попавшимся числом. Сохраняйте сырые данные (вывод iperf3 -J в JSON) — это позволяет пересчитать медиану и разброс позже, а не только записать финальную цифру.

Практический ориентир при чтении результатов: разница в пределах 10-15% между протоколами на одном канале обычно находится в зоне обычного шума измерений и не повод менять протокол в проде. Разница в разы — почти всегда объясняется не самим протоколом, а асимметрией в настройке (MTU, число потоков, упор в CPU) — прежде чем делать вывод, стоит перепроверить именно эти пункты. Если после выравнивания всех переменных цифры всё равно расходятся, а туннель на проде «просто медленный» без явного сравнения протоколов — пошаговая диагностика разобрана отдельно в статье про то, что делать, если VPN медленно работает.

Частые вопросы