UDP не всегда быстрее: как выбрать транспорт OpenVPN

Каждое руководство говорит, что UDP лучше TCP для OpenVPN, и этот совет — значение по умолчанию, а не измерение. Транспорт меняет то, как доставляются пакеты и что происходит, когда путь их теряет, а не то, как шифруется туннель. За captive-порталом или прокси, разрешающим только порт 443, более медленный вариант — единственный, который вообще подключается. Далее отделяется то, что делает протокол, от того, что разрешает ваша сеть доступа.

Что на самом деле меняет транспорт

TCP обеспечивает надёжный упорядоченный поток байтов и повторно отправляет всё потерянное, как определяет RFC 9293. UDP передаёт датаграммы сети, а OpenVPN запускает собственный уровень надёжности поверх этого сокета. Инкапсуляция TCP в TCP складывает два цикла восстановления, поэтому один потерянный сегмент может задержать внутренний поток, пока не придёт внешняя повторная передача. Именно это взаимодействие — настоящий аргумент за UDP, и оно проявляется как задержка, а не как пропускная способность.

Эффект растёт с потерями и временем кругового обхода. На чистом локальном пути оба транспорта ощущаются одинаково, поэтому лабораторный тест редко воспроизводит жалобу. На перегруженном мобильном канале разница видна в интерактивных сеансах задолго до того, как большая передача что-то заметит.

Ничто из этого не касается конфиденциальности или целостности. Рукопожатие TLS и шифр канала данных одинаковы для обоих транспортов, так что переключение не спасёт слабый набор шифров.

Где TCP заслуживает своё место

Сети доступа — обычная причина выбрать TCP. Отель, аэропорт или гостевая сеть могут разрешать исходящий 443 и отбрасывать всё остальное, и TCP-слушатель на этом порту — единственный работающий профиль. Это доступность, а не производительность, и этого самого по себе достаточно.

TCP помогает и тогда, когда путь стабилен, но промежуточные устройства враждебны. Некоторые сети сбрасывают длительные UDP-потоки, терпя при этом TCP-сеансы, похожие на обычный веб-трафик. Удастся ли это сходство — свойство конкретной сети, и ни одно руководство не может обещать его для всех. Тестируйте внутри сети, которая даёт сбой, прежде чем винить протокол.

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

Держать готовый TCP-профиль — практичный компромисс. Большинство клиентов хранят оба и позволяют переключиться, когда сеть отвергает путь UDP, что ничего не стоит, пока не понадобится. Чего делать не следует — выпускать два профиля, указывающие на разные конечные точки, потому что тогда ваше сравнение измеряет серверы.

Проверьте, какой слушатель у вас на самом деле

Перед сравнением производительности убедитесь, что обе стороны согласны насчёт транспорта и порта. Замена proto udp на proto tcp в клиентском файле не создаёт слушателя на сервере. Сервер должен быть настроен на этот протокол, и профиль должен ему соответствовать.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep печатает, что серверу велено использовать, а два списка сокетов показывают, к чему он привязан. UDP-слушатель появляется только в первом списке, а TCP-слушатель только во втором, поэтому отсутствующая строка — самый быстрый способ найти профиль, который никогда не применялся. Сравните и порт, потому что TCP-профиль на 1194 в большинстве сетей доступа ведёт себя иначе, чем на 443. После изменения перезапустите службу и прочитайте строку журнала, сообщающую о привязке.

Подтверждение на стороне клиента дёшево: запустите соединение с --verb 4 и прочитайте строку транспорта в журнале. Если клиент говорит UDP, а сервер слушает TCP, рукопожатие вообще не начинается, и никакая настройка не поможет.

Сравнивайте рабочую нагрузку, а не ярлык транспорта

Честное сравнение держит всё постоянным, кроме транспорта. То же устройство, та же сеть доступа, тот же конечный хост, то же приложение и в идеале тот же сервер. Если два профиля указывают на разные хосты, вы измеряете и эти хосты.

Записывайте три результата для каждого запуска: устанавливается ли туннель, держится ли он и завершается ли задача. Мелкие запросы, которые работают, пока большие передачи застревают, указывают на размер пакета и MTU, а не на транспорт. Повторные переподключения указывают на путь или на тайм-аут промежуточного устройства.

Оставьте профиль, который работает в условиях, с которыми вы действительно сталкиваетесь, а второй сохраните. Выбор принадлежит сети, а не человеку, поэтому любой единственный ответ по умолчанию где-то неверен.