UDP er ikke alltid raskere: å velge OpenVPN-transport

Hver guide sier at UDP slår TCP for OpenVPN, og rådet er et standardvalg, ikke en måling. Transporten endrer hvordan pakker leveres og hva som skjer når veien slipper dem, ikke hvordan tunnelen krypteres. Bak en captive portal eller en proxy som bare tillater port 443, er det langsommere alternativet det som i det hele tatt kobler til. Det følgende skiller hva protokollen gjør fra hva aksessnettet ditt tillater.

Hva transporten faktisk endrer

TCP leverer en pålitelig, ordnet bytestrøm og sender på nytt alt som går tapt, slik RFC 9293 fastsetter. UDP overleverer datagrammer til nettet, og OpenVPN kjører sitt eget pålitelighetslag oppå den socketen. Innkapsling av TCP i TCP stabler to gjenopprettingsløkker, så ett tapt segment kan holde igjen den indre strømmen til den ytre omsendingen ankommer. Det samspillet er det egentlige argumentet for UDP, og det viser seg som forsinkelse snarere enn som gjennomstrømning.

Effekten øker med tap og rundtur-tid. På en ren lokal vei føles begge transportene identiske, og derfor gjengir en laboratorietest sjelden klagen. På en overbelastet mobillenke vises forskjellen i interaktive økter lenge før en stor overføring merker noe.

Ingenting av dette berører konfidensialitet eller integritet. TLS-håndtrykket og datakanalchifferen er de samme for begge transporter, så et bytte kan ikke redde en svak chifferpakke.

Hvor TCP fortjener plassen sin

Aksessnett er den vanlige grunnen til å velge TCP. Et hotell, en flyplass eller et gjestenett tillater kanskje utgående 443 og slipper alt annet, og en TCP-lytter på den porten er den eneste profilen som virker. Det er tilgjengelighet, ikke ytelse, og det er god nok grunn i seg selv.

TCP hjelper også når veien er stabil, men mellomleddene er fiendtlige. Noen nett nullstiller langvarige UDP-strømmer mens de tolererer TCP-økter som ligner vanlig webtrafikk. Om den likheten lykkes er en egenskap ved det konkrete nettet, og ingen guide kan love det for alle. Test inne i nettet som feiler før du klandrer protokollen.

En avvist pålogging er ikke et transportproblem. Å slå av sertifikatverifisering for å tvinge gjennom en tilkobling er en annen endring med et mye verre utfall.

Å ha en TCP-profil klar er det praktiske kompromisset. De fleste klienter lagrer begge og lar deg bytte når et nett avviser UDP-veien, noe som ikke koster noe før du trenger det. Det du ikke bør gjøre, er å levere to profiler som peker på forskjellige endepunkter, for da måler sammenligningen serverne.

Kontroller hvilken lytter du faktisk har

Før du sammenligner ytelse, bekreft at begge ender er enige om transport og port. Å endre proto udp til proto tcp i en klientfil oppretter ikke en serverlytter. Serveren må være konfigurert for den protokollen, og profilen må passe til den.

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

grep skriver ut hva serveren fikk beskjed om å bruke, mens de to socket-listene viser hva den er bundet til. En UDP-lytter vises bare i den første listen og en TCP-lytter bare i den andre, så en manglende linje er den raskeste måten å finne en profil som aldri ble brukt. Sammenlign porten også, for en TCP-profil på 1194 oppfører seg annerledes enn en på 443 i de fleste aksessnett. Start tjenesten på nytt etter endringen og les logglinjen som rapporterer bindingen.

Bekreftelse på klientsiden er billig: kjør tilkoblingen med --verb 4 og les transportlinjen i loggen. Hvis klienten sier UDP mens serveren lytter på TCP, starter håndtrykket aldri, og ingen justering hjelper.

Sammenlign arbeidsbelastningen, ikke transportetiketten

En rettferdig sammenligning holder alt konstant unntatt transporten. Samme enhet, samme aksessnett, samme destinasjonsvert, samme applikasjon og ideelt samme server. Hvis de to profilene peker på forskjellige verter, måler du også de vertene.

Registrer tre utfall for hver kjøring: om tunnelen etableres, om den holder seg oppe, og om oppgaven fullføres. Små forespørsler som virker mens store overføringer stopper, peker på pakkestørrelse og MTU, ikke på transporten. Gjentatte gjenoppkoblinger peker på veien eller på en tidsavbrudd i et mellomledd.

Behold profilen som virker under forholdene du faktisk møter, og lagre den andre. Valget tilhører nettet, ikke personen, og derfor er ethvert enkelt standardssvar feil et sted.