UDP nie zawsze jest szybszy: wybór transportu OpenVPN

Każdy poradnik mówi, że UDP bije TCP w OpenVPN, a ta rada jest ustawieniem domyślnym, nie pomiarem. Transport zmienia sposób dostarczania pakietów i to, co się dzieje, gdy ścieżka je gubi, a nie sposób szyfrowania tunelu. Za portalem przechwytującym lub proxy dopuszczającym tylko port 443 wolniejsza opcja jest tą, która w ogóle się łączy. Poniżej oddzielono to, co robi protokół, od tego, na co pozwala twoja sieć dostępowa.

Co transport naprawdę zmienia

TCP dostarcza niezawodny, uporządkowany strumień bajtów i ponawia wszystko, co zginie, jak określa RFC 9293. UDP przekazuje datagramy sieci, a OpenVPN prowadzi nad tym gniazdem własną warstwę niezawodności. Kapsułkowanie TCP w TCP piętrzy dwie pętle odzyskiwania, więc jeden utracony segment może wstrzymać wewnętrzny strumień, dopóki nie dotrze zewnętrzna retransmisja. Ta interakcja jest prawdziwym argumentem za UDP i objawia się jako opóźnienie, a nie jako przepustowość.

Efekt rośnie wraz z utratą pakietów i czasem rundy. Na czystej ścieżce lokalnej oba transporty wydają się identyczne, dlatego test laboratoryjny rzadko odtwarza skargę. W zatłoczonym łączu mobilnym różnica pojawia się w sesjach interaktywnych długo, zanim duży transfer cokolwiek zauważy.

Nic z tego nie dotyczy poufności ani integralności. Uścisk dłoni TLS i szyfr kanału danych są takie same dla obu transportów, więc przełączenie nie uratuje słabego zestawu szyfrów.

Gdzie TCP zasługuje na swoje miejsce

Sieci dostępowe to zwykły powód wyboru TCP. Hotel, lotnisko lub sieć gościnna mogą zezwalać na wychodzący 443 i odrzucać wszystko inne, a nasłuch TCP na tym porcie to jedyny działający profil. To osiągalność, nie wydajność, i to wystarczająco dobry powód sam w sobie.

TCP pomaga też, gdy ścieżka jest stabilna, ale urządzenia pośredniczące są wrogie. Niektóre sieci resetują długotrwałe strumienie UDP, tolerując sesje TCP przypominające zwykły ruch webowy. Czy to podobieństwo się udaje, jest cechą konkretnej sieci, i żaden poradnik nie może tego obiecać za wszystkie. Testuj wewnątrz sieci, która zawodzi, zanim obwinisz protokół.

Odrzucone logowanie nie jest problemem transportu. Wyłączenie weryfikacji certyfikatu, by przepchnąć połączenie, to inna zmiana o znacznie gorszym wyniku.

Trzymanie gotowego profilu TCP to praktyczny kompromis. Większość klientów przechowuje oba i pozwala przełączyć, gdy sieć odmawia ścieżki UDP, co nic nie kosztuje, dopóki nie jest potrzebne. Czego nie powinieneś robić, to dostarczać dwóch profili wskazujących na różne punkty końcowe, bo wtedy porównanie mierzy serwery.

Sprawdź, który nasłuch naprawdę masz

Przed porównaniem wydajności potwierdź, że obie strony zgadzają się co do transportu i portu. Zmiana proto udp na proto tcp w pliku klienta nie tworzy nasłuchu serwera. Serwer musi być skonfigurowany dla tego protokołu, a profil musi do niego pasować.

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

grep wypisuje, co polecono serwerowi używać, a dwie listy gniazd pokazują, do czego jest przypisany. Nasłuch UDP pojawia się tylko na pierwszej liście, a nasłuch TCP tylko na drugiej, więc brakująca linia to najszybszy sposób znalezienia profilu, którego nigdy nie zastosowano. Porównaj też port, bo profil TCP na 1194 zachowuje się inaczej niż ten na 443 w większości sieci dostępowych. Zrestartuj usługę po zmianie i przeczytaj linię logu informującą o powiązaniu.

Potwierdzenie po stronie klienta jest tanie: uruchom połączenie z --verb 4 i przeczytaj linię transportu w logu. Jeśli klient mówi UDP, a serwer nasłuchuje na TCP, uścisk dłoni nigdy się nie zaczyna i żadne strojenie nie pomoże.

Porównuj obciążenie, nie etykietę transportu

Uczciwe porównanie utrzymuje wszystko poza transportem na stałym poziomie. To samo urządzenie, ta sama sieć dostępowa, ten sam host docelowy, ta sama aplikacja i najlepiej ten sam serwer. Jeśli dwa profile wskazują różne hosty, mierzysz także te hosty.

Zapisuj trzy wyniki każdego uruchomienia: czy tunel się nawiązuje, czy się utrzymuje i czy zadanie się kończy. Małe żądania, które działają, gdy duże transfery się zacinają, wskazują na rozmiar pakietu i MTU, a nie na transport. Powtarzające się ponowne połączenia wskazują na ścieżkę lub limit czasu urządzenia pośredniczącego.

Zachowaj profil, który działa w warunkach, które naprawdę spotykasz, a drugi zapisz. Wybór należy do sieci, nie do osoby, dlatego każda pojedyncza domyślna odpowiedź jest gdzieś błędna.