VPN-протоколы в цифрах: скорость и задержка WireGuard, OpenVPN и IKEv2

Он не обещает такую же разницу в коммерческом VPN: в другой сети, с другим сервером и оборудованием абсолютные значения могут быть совсем иными.

Это видно и по другим замерам. На виртуальном стенде с Ubuntu 24.04 WireGuard показал 22,9 Мбит/с, IKEv2/IPsec с PSK — 16,8, OpenVPN UDP — 11,2, OpenVPN TCP/443 — 8,7. В лаборатории Университета Амстердама WireGuard-C достиг 901 Мбит/с TCP goodput на физическом канале 1 Гбит/с. Цифры различаются примерно на два порядка, потому что измерялись в разных условиях и по разным метрикам. Сопоставлять их напрямую нельзя.

Главное по теме

Если смотреть только на скорость передачи данных, в приведённых тестах WireGuard опережает остальные протоколы. OpenVPN TCP оказывается медленнее OpenVPN UDP, а IKEv2/IPsec занимает промежуточное положение на виртуальном стенде. Но этот порядок описывает конкретные замеры, а не универсальный рейтинг для любого VPN-сервиса.

С задержкой картина менее однозначна. На виртуальном стенде наименьший средний ping у WireGuard. На пользовательском маршруте RTINGS наименьший idle ping оказался у OpenVPN UDP. При активной загрузке канала значения latency под нагрузкой меняются снова. Здесь важно сначала понять, что именно измерялось, и только потом сравнивать результаты.

Цифра скорости без сведений о стенде, маршруте и метрике выглядит точной, но мало что говорит о работе протокола в другой сети.

Как это работает: что именно измеряют

Пропускная способность, goodput, скорость в speed test и задержка отвечают на разные вопросы. Пропускная способность показывает скорость передачи данных в рамках выбранного измерения. Goodput учитывает полезные данные, дошедшие до приложения. Speed test отражает результат конкретного тестового соединения и его методики. Ping измеряет время прохождения пакета в простое сети, а latency под нагрузкой показывает, как задержка ведёт себя во время передачи данных.

Поэтому показатели из разных тестов нельзя просто поставить в одну таблицу и назвать победителя. Даже одинаковая единица измерения не делает замеры сопоставимыми: значение зависит от оборудования, маршрута, канала, настроек и способа подсчёта.

В этом материале используются три набора результатов:

• RTINGS: 19 тестов на каждый протокол, кроме OpenVPN UDP. В этой конфигурации десять запусков OpenVPN UDP завершились ошибкой, поэтому в итоговое среднее вошли девять результатов. Измерялись загрузка, выгрузка, idle ping и download latency под нагрузкой по IQM.
• Виртуальный стенд на Ubuntu 24.04 в VirtualBox: по десять 30-секундных запусков на конфигурацию, по 100 ping-пакетов на измерение задержки. В набор входят средняя пропускная способность, средний ping и средний джиттер.
• Лаборатория Университета Амстердама: физический стенд с каналом 1 Гбит/с и максимальным размером пакета. Измерялись TCP/UDP goodput и медианная задержка ICMP в чистом окружении.

Это разные срезы производительности. RTINGS показывает результаты на пользовательском маршруте с его задержкой и особенностями передачи. Виртуальный стенд позволяет сравнить реализации в одной виртуальной среде, но сам по себе не моделирует коммерческий VPN-сервис. Амстердамский тест показывает результат в лабораторной конфигурации и не описывает типичное соединение пользователя с удалённым сервером.

Скорость VPN при разных протоколах

На виртуальном стенде и в тестах RTINGS WireGuard показал самую высокую скорость среди вариантов, для которых есть результаты. OpenVPN TCP оказался самым медленным. IKEv2/IPsec измерялся только на виртуальном стенде, поэтому его место в этой таблице ограничено одной конфигурацией.

На виртуальном стенде WireGuard показал примерно вдвое больше пропускной способности, чем OpenVPN UDP. В тесте RTINGS разрыв по загрузке составил около 2,4 раза, по выгрузке — около 2,9. Это соотношение относится к каждому из этих замеров, а не к протоколам при любых условиях.

Виртуальный стенд даёт более низкие абсолютные значения, чем RTINGS. Они не позволяют заключить, что один источник «правильнее» другого: различаются среда и методика. VirtualBox вносит собственные накладные расходы, а средняя пропускная способность за 30-секундный интервал не равна пиковому результату speed test на пользовательском маршруте.

Лабораторный результат из Амстердама отвечает на отдельный вопрос. WireGuard-C показал 901 Мбит/с TCP goodput и 917 Мбит/с UDP goodput на канале 1 Гбит/с при максимальном размере пакета. Goodput нельзя напрямую сравнивать со скоростью загрузки RTINGS: это разные показатели, измеренные на разных стендах. Лабораторная цифра не обещает, что пользователь увидит сопоставимую скорость через VPN-сервис.

Задержка: idle ping и нагрузка

Idle ping и latency под нагрузкой нельзя сводить в одну колонку с общим названием «задержка». Первый показатель описывает прохождение пакетов, когда канал не занят активной передачей данных. Второй показывает задержку во время загрузки. Для интерактивных задач, которые идут одновременно с передачей больших файлов, разница между этими сценариями принципиальна.

На виртуальном стенде у WireGuard были наименьшие средние ping и джиттер: 4,7 и 0,8 мс. У OpenVPN TCP в той же конфигурации — 14,3 и 3,8 мс. IKEv2/IPsec оказался между ними с показателями 8,2 и 1,7 мс. Это ранжирование относится к виртуальному стенду и его условиям.

В RTINGS у OpenVPN UDP зафиксирован меньший idle ping, чем у WireGuard: 84,0 против 90,1 мс. Разница составляет 6,1 мс. В опубликованных здесь данных нет сведений о разбросе, которые позволили бы оценить статистическую значимость этой разницы. Поэтому корректно говорить только о зафиксированных средних значениях конкретного теста. На результат могли влиять маршрут и расстояние до сервера, а не только выбор протокола.

При загрузке порядок другой: download latency IQM у WireGuard составила 611,6 мс, у OpenVPN UDP — 323,4 мс, у OpenVPN TCP — 360,5 мс. RTINGS отмечает возможное влияние буферизации и маршрутизации к трансатлантическому серверу. Этот результат описывает данный тестовый маршрут; считать его типичным для любого VPN-подключения нельзя.

Джиттер тоже стоит читать отдельно от среднего ping. Он показывает колебания времени доставки пакетов. Виртуальный стенд дал 0,8 мс для WireGuard и 3,8 мс для OpenVPN TCP. Для голосовых звонков и видеоконференций стабильность доставки может быть важна наряду с общей задержкой: среднее значение не показывает, насколько сильно меняется интервал между пакетами. При этом приводить показатели одного стенда как прогноз для другого не следует.

Для интерактивных задач важен не один средний ping. Смотрите, как меняется задержка под нагрузкой и насколько стабильно приходят пакеты.

Практические детали: режимы OpenVPN

OpenVPN можно использовать с UDP или TCP. В документации OpenVPN UDP рассматривается как предпочтительный вариант для производительности, а TCP может пригодиться для совместимости с некоторыми ограничительными сетями. Это не означает, что любая сеть с фильтрацией обязательно переведёт соединение на TCP.

В приведённых тестах UDP был быстрее TCP в обоих наборах результатов. На RTINGS загрузка составила 149,1 Мбит/с для OpenVPN UDP и 44,1 Мбит/с для OpenVPN TCP. На виртуальном стенде результаты равны 11,2 и 8,7 Мбит/с. Разрыв зависит от конкретного теста: соотношение из одного набора нельзя автоматически переносить на другой.

TCP/443 может помочь пройти через некоторые межсетевые экраны, потому что этот порт часто доступен для обычного веб-трафика. Это вариант совместимости, а не универсальный способ обойти любые ограничения. Если сеть распознаёт или блокирует VPN-трафик другими средствами, одного выбора порта может быть недостаточно.

Практический вывод для сравнения OpenVPN простой: всегда уточняйте транспортный режим. Формулировка «скорость OpenVPN» скрывает важное различие. При этом не стоит описывать результаты RTINGS как контролируемую смену только одного параметра, если методика не подтверждает, что сервер, сервис, клиент и остальные условия были одинаковыми. Данные показывают значения для разных режимов в тесте, но не дают основания считать, что единственной причиной разницы стала смена UDP на TCP.

Производительность IKEv2 и WireGuard

Для IKEv2/IPsec с PSK есть результаты виртуального стенда: 16,8 Мбит/с средней пропускной способности, 8,2 мс ping и 1,7 мс джиттера. В этой конфигурации все три значения уступают WireGuard, но превосходят OpenVPN TCP. Это ограниченный вывод по одному стенду, не общий рейтинг протоколов.

В собранных для материала источниках нет пользовательского набора RTINGS для IKEv2 с детализацией по маршрутам. Сопоставимых с RTINGS замеров idle ping и latency под нагрузкой для этого протокола среди рассмотренных материалов также не найдено. Это означает, что для прямого сравнения данных недостаточно, а не то, что таких измерений не существует вообще.

У IKEv2 есть и другая сторона применения. Он встроен в iOS и Windows, поэтому в поддерживаемых конфигурациях можно обойтись без отдельного VPN-клиента. MOBIKE поддерживает переход между сетями, например с Wi‑Fi на мобильную сеть. Это аргумент в пользу удобства и совместимости, но не доказательство более высокой скорости или меньшей задержки.

Поэтому производительность IKEv2 и WireGuard в имеющихся цифрах можно сравнить только на виртуальном стенде. За его пределами уверенное ранжирование потребовало бы дополнительных замеров на сопоставимых маршрутах и оборудовании.

Лабораторный потолок и пределы выводов

Лабораторный тест Университета Амстердама показывает высокие значения goodput WireGuard-C: 901 Мбит/с по TCP и 917 Мбит/с по UDP на канале 1 Гбит/с при максимальном размере пакета. В том же источнике медианная ICMP-задержка составила 0,42 мс для WireGuard-C и 0,39 мс для OpenVPN AES-GCM.

Эти 0,03 мс описывают разницу в конкретном лабораторном измерении. По ним нельзя заключить, что задержка двух протоколов будет такой же на пользовательском маршруте. Нельзя и выводить из близких значений ICMP, почему на других стендах отличаются скорости: лабораторные результаты не устанавливают причин разницы между тестами RTINGS и виртуальной машиной.

Важно также не приписывать результаты RTINGS конкретному шифру OpenVPN. В приведённых данных этот тест не указывает, что использовался именно AES-GCM. AES-GCM фигурирует в лабораторном сравнении Университета Амстердама, где его медианная ICMP-задержка сопоставлялась с WireGuard-C.

Такой разбор очерчивает границу между измерением и объяснением. Можно сказать, что в одном тесте WireGuard быстрее OpenVPN TCP, а в лабораторном сравнении медианные значения ICMP близки. Нельзя на основании этого набора уверенно объяснить разницу через управление сессиями, буферизацию, состояние TCP-соединения или обмен ключами при реконнекте: представленные замеры не проверяют эти причины.

На что обратить внимание в чужих бенчмарках

Когда сравнивают скорость VPN-протоколов WireGuard, OpenVPN и IKEv2, полезно сначала выяснить, что именно стояло за цифрой. Несколько вопросов помогают не смешивать несопоставимые результаты:

• Какая метрика использовалась? Goodput, пропускная способность и результат speed test не одно и то же. Ping и задержка под нагрузкой описывают разные состояния канала.
• Какой режим OpenVPN тестировали? UDP и TCP дают разные результаты. Без указания режима цифра для OpenVPN неполная.
• Как устроен стенд? Виртуальная машина, физический канал и пользовательское соединение не заменяют друг друга. Разницу между 22,9 и 353,6 Мбит/с нельзя объяснять только протоколом, если речь о разных окружениях.
• Какой маршрут использовался? Удалённость сервера и маршрутизация могут влиять на ping и задержку под нагрузкой. Результаты трансатлантического подключения не описывают короткий локальный маршрут.
• Сколько было запусков и какие вошли в итог? У RTINGS для OpenVPN UDP в среднее попали девять результатов, поскольку десять запусков завершились ошибкой. Это существенная деталь при чтении набора.
• Какие параметры конфигурации известны? Например, IKEv2/IPsec на виртуальном стенде тестировался с PSK. Для лабораторного OpenVPN указан AES-GCM, но этот параметр нельзя переносить на другой тест без подтверждения.

При сравнении сервисов важна не только запись «WireGuard» или «OpenVPN» в настройках. На результат влияют конкретная реализация, сервер, маршрут и конфигурация. Без этих сведений цифра остаётся ориентиром для того теста, в котором её получили.

Итоги

В приведённых замерах WireGuard лидирует по пропускной способности на виртуальном стенде и в RTINGS. OpenVPN UDP быстрее OpenVPN TCP в обоих наборах. На виртуальном стенде IKEv2/IPsec занимает промежуточное положение, но независимых пользовательских данных для сравнения с WireGuard и OpenVPN здесь недостаточно.

С задержкой единого победителя нет: виртуальный стенд и пользовательский маршрут дают разный порядок результатов. Для оценки звонков и видеосвязи одного ping мало, а для соединения под активной загрузкой полезно смотреть на latency под нагрузкой. Наконец, лабораторные цифры показывают возможности конкретного стенда, но не обещают такую же скорость в повседневном подключении.

Вопрос «какой протокол быстрее» имеет смысл только вместе с уточнением: где, по какой метрике, в каком режиме и на каком маршруте. Без этого сравнение превращается в соревнование чисел, которые измеряют разное.