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, а не на транспорт. Повторні перепідключення вказують на шлях або на тайм-аут проміжного пристрою.

Залиште профіль, який працює в умовах, з якими ви справді стикаєтеся, а другий збережіть. Вибір належить мережі, а не людині, тому будь-яка єдина відповідь за замовчуванням десь неправильна.