UDP не винаги е по-бърз: как да изберете транспорта на OpenVPN

Всяко ръководство казва, че UDP е по-добър от TCP за OpenVPN, но този съвет е настройка по подразбиране, а не измерване. Транспортът променя как се доставят пакетите и какво се случва, когато пътят ги изгуби, а не как тунелът се криптира. Зад портал с ограничен достъп или прокси, което разрешава само порт 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, а не към транспорта. Повтарящите се повторни свързвания сочат към пътя или към изтичане на времето на междинно устройство.

Пазете профила, който работи при условията, които действително срещате, и запазете другия. Изборът принадлежи на мрежата, а не на човека, затова всеки един отговор по подразбиране е някъде грешен.