UDP er ikke altid hurtigere: vælg OpenVPN-transport

Hver guide siger, at UDP slår TCP for OpenVPN, og det råd er et standardvalg, ikke en måling. Transporten ændrer, hvordan pakker leveres, og hvad der sker, når vejen taber dem, ikke hvordan tunnelen krypteres. Bag en captive portal eller en proxy, der kun tillader port 443, er den langsommere mulighed den, der overhovedet forbinder. Det følgende adskiller, hvad protokollen gør, fra hvad dit adgangsnetværk tillader.

Hvad transporten faktisk ændrer

TCP leverer en pålidelig, ordnet bytestrøm og gensender alt, hvad der går tabt, som RFC 9293 foreskriver. UDP afleverer datagrammer til netværket, og OpenVPN kører sit eget pålidelighedslag oven på den socket. Indkapsling af TCP i TCP stabler to genopretningsløjfer, så et enkelt tabt segment kan holde den indre strøm tilbage, indtil den ydre gensendelse ankommer. Den vekselvirkning er det egentlige argument for UDP, og den viser sig som latenstid frem for som gennemstrømning.

Effekten skalerer med tab og rundtur-stid. På en ren lokal vej føles begge transporter identiske, og derfor genskaber en laboratorietest sjældent klagen. På et overbelastet mobillink viser forskellen sig i interaktive sessioner længe før en stor overførsel bemærker noget.

Intet af dette rører fortrolighed eller integritet. TLS-håndtrykket og datakanalens cipher er de samme for begge transporter, så et skift kan ikke redde en svag cipher suite.

Hvor TCP fortjener sin plads

Adgangsnetværk er den sædvanlige grund til at vælge TCP. Et hotel, en lufthavn eller et gæstenetværk tillader måske udgående 443 og dropper alt andet, og en TCP-lytter på den port er den eneste profil, der virker. Det er tilgængelighed, ikke ydeevne, og det er grund nok i sig selv.

TCP hjælper også, når vejen er stabil, men mellemboksene er fjendtlige. Nogle netværk nulstiller langvarige UDP-strømme, mens de tolererer TCP-sessioner, der ligner almindelig webtrafik. Om den lighed lykkes, er en egenskab ved det konkrete netværk, og ingen guide kan love det for dem alle. Test inde i det netværk, der fejler, før du bebrejder protokollen.

Et afvist login er ikke et transportproblem. At slå certifikatverifikation fra for at tvinge en forbindelse igennem er en anden ændring med et meget værre udfald.

At have en TCP-profil klar er det praktiske kompromis. De fleste klienter gemmer begge og lader dig skifte, når et netværk afviser UDP-vejen, hvilket ikke koster noget, før du har brug for det. Det, du ikke bør gøre, er at levere to profiler, der peger på forskellige endepunkter, for så måler din sammenligning serverne.

Kontroller, hvilken lytter du faktisk har

Før du sammenligner ydeevne, skal du bekræfte, at begge ender er enige om transport og port. At ændre proto udp til proto tcp i en klientfil opretter ikke en serverlytter. Serveren skal være konfigureret til den protokol, og profilen skal passe til den.

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

grep udskriver, hvad serveren fik besked på at bruge, mens de to socket-lister viser, hvad den er bundet til. En UDP-lytter vises kun i den første liste og en TCP-lytter kun i den anden, så en manglende linje er den hurtigste måde at finde en profil, der aldrig blev anvendt. Sammenlign også porten, for en TCP-profil på 1194 opfører sig anderledes end en på 443 i de fleste adgangsnetværk. Genstart tjenesten efter ændringen, og læs loglinjen, der rapporterer bindingen.

Bekræftelse på klientsiden er billig: kør forbindelsen med --verb 4 og læs transportlinjen i loggen. Hvis klienten siger UDP, mens serveren lytter på TCP, begynder håndtrykket aldrig, og ingen mængde tuning hjælper.

Sammenlign arbejdsbelastningen, ikke transportens etiket

En fair sammenligning holder alt undtagen transporten konstant. Samme enhed, samme adgangsnetværk, samme destinationsvært, samme applikation og ideelt samme server. Hvis de to profiler peger på forskellige værter, måler du også de værter.

Registrér tre udfald for hver kørsel: om tunnelen etableres, om den bliver oppe, og om opgaven fuldføres. Små forespørgsler, der virker, mens store overførsler går i stå, peger på pakkestørrelse og MTU snarere end på transporten. Gentagne genopkoblinger peger på vejen eller på en timeout i en mellemboks.

Behold den profil, der virker under de forhold, du faktisk møder, og gem den anden. Valget tilhører netværket, ikke personen, og derfor er ethvert enkelt standardsvar forkert et eller andet sted.