UDP nu este mereu mai rapid: alegerea transportului OpenVPN

Fiecare ghid spune că UDP bate TCP pentru OpenVPN, iar sfatul este o valoare implicită, nu o măsurătoare. Transportul schimbă modul în care sunt livrate pachetele și ce se întâmplă când calea le aruncă, nu modul în care tunelul este criptat. În spatele unui portal captiv sau al unui proxy care permite doar portul 443, opțiunea mai lentă este cea care se conectează măcar. Ce urmează separă ce face protocolul de ce permite rețeaua dumneavoastră de acces.

Ce schimbă de fapt transportul

TCP livrează un flux de octeți fiabil și ordonat și retransmite tot ce se pierde, cum specifică RFC 9293. UDP predă datagramele rețelei, iar OpenVPN rulează propriul strat de fiabilitate peste acel socket. Încapsularea TCP în TCP stivuește două bucle de recuperare, așa că un singur segment pierdut poate ține pe loc fluxul interior până când sosește retransmisia exterioară. Această interacțiune este argumentul real pentru UDP și se manifestă ca latență, nu ca debit.

Efectul crește cu pierderile și cu timpul dus-întors. Pe o cale locală curată ambele transporturi par identice, de aceea un test de laborator reproduce rar reclamația. Pe o legătură mobilă aglomerată diferența apare în sesiunile interactive mult înainte ca un transfer mare să observe ceva.

Nimic din toate acestea nu atinge confidențialitatea sau integritatea. Handshake-ul TLS și cifrul canalului de date sunt aceleași pentru ambele transporturi, așa că schimbarea nu poate salva un set de cifruri slab.

Unde TCP își merită locul

Rețelele de acces sunt motivul obișnuit pentru a alege TCP. Un hotel, un aeroport sau o rețea de oaspeți poate permite 443 de ieșire și poate arunca tot restul, iar un ascultător TCP pe acel port este singurul profil care funcționează. Aceasta este accesibilitate, nu performanță, și este un motiv suficient de bun în sine.

TCP ajută și când calea este stabilă, dar echipamentele intermediare sunt ostile. Unele rețele resetează fluxurile UDP de lungă durată, tolerând în schimb sesiuni TCP care seamănă cu trafic web obișnuit. Dacă acea asemănare reușește este o proprietate a rețelei concrete, și niciun ghid nu o poate promite pentru toate. Testați în interiorul rețelei care eșuează înainte de a da vina pe protocol.

O autentificare respinsă nu este o problemă de transport. Dezactivarea verificării certificatului pentru a forța o conexiune este o altă modificare, cu un rezultat mult mai prost.

Păstrarea unui profil TCP pregătit este compromisul practic. Majoritatea clienților le stochează pe amândouă și vă lasă să comutați când o rețea refuză calea UDP, ceea ce nu costă nimic până când aveți nevoie. Ce nu ar trebui să faceți este să livrați două profiluri care indică puncte finale diferite, pentru că atunci comparația dumneavoastră măsoară serverele.

Verificați ce ascultător aveți de fapt

Înainte de a compara performanța, confirmați că ambele capete sunt de acord asupra transportului și a portului. Schimbarea proto udp în proto tcp într-un fișier client nu creează un ascultător pe server. Serverul trebuie configurat pentru acel protocol, iar profilul trebuie să corespundă.

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

grep afișează ce i s-a spus serverului să folosească, în timp ce cele două liste de socket-uri arată la ce este legat. Un ascultător UDP apare doar în prima listă, iar un ascultător TCP doar în a doua, așa că o linie lipsă este cea mai rapidă cale de a găsi un profil care nu a fost niciodată aplicat. Comparați și portul, pentru că un profil TCP pe 1194 se comportă diferit de unul pe 443 în majoritatea rețelelor de acces. Reporniți serviciul după modificare și citiți linia de jurnal care raportează legarea.

Confirmarea pe partea clientului este ieftină: rulați conexiunea cu --verb 4 și citiți linia de transport din jurnal. Dacă clientul spune UDP în timp ce serverul ascultă pe TCP, handshake-ul nu începe niciodată și nicio reglare nu ajută.

Comparați volumul de lucru, nu eticheta transportului

O comparație corectă menține totul constant în afară de transport. Același dispozitiv, aceeași rețea de acces, același gazdă de destinație, aceeași aplicație și, ideal, același server. Dacă cele două profiluri indică gazde diferite, măsurați și acele gazde.

Înregistrați trei rezultate pentru fiecare rulare: dacă tunelul se stabilește, dacă rămâne activ și dacă sarcina se finalizează. Cererile mici care funcționează în timp ce transferurile mari se blochează indică dimensiunea pachetului și MTU, nu transportul. Reconectările repetate indică calea sau un timeout al unui echipament intermediar.

Păstrați profilul care funcționează în condițiile pe care le întâlniți efectiv și salvați-l pe celălalt. Alegerea aparține rețelei, nu persoanei, de aceea orice răspuns implicit unic este greșit undeva.