UDP ne ĉiam estas pli rapida: elekti la transporton de OpenVPN

Ĉiu gvidilo diras, ke UDP superas TCP por OpenVPN, kaj tiu konsilo estas antaŭagordo, ne mezuro. La transporto ŝanĝas kiel pakaĵoj estas liverataj kaj kio okazas kiam la vojo ilin perdas, ne kiel la tunelo estas ĉifrata. Malantaŭ kaptita portalo aŭ prokura servilo, kiu permesas nur pordon 443, la pli malrapida opcio estas tiu, kiu entute konektiĝas. La sekvanta apartigas tion, kion faras la protokolo, de tio, kion permesas via alira reto.

Kion la transporto efektive ŝanĝas

TCP liveras fidindan, ordigitan bajtan fluon kaj resendas ĉion perditan, kiel RFC 9293 specifas. UDP transdonas datagramojn al la reto, kaj OpenVPN funkciigas sian propran fidindecon-tavolon super tiu ingo. Encapsuligi TCP en TCP stokas du reakirajn buklojn, do unu perdita segmento povas haltigi la internan fluon ĝis la ekstera resendo alvenas. Tiu interagado estas la vera argumento por UDP, kaj ĝi aperas kiel latento anstataŭ kiel trafluo.

La efiko kreskas kun perdoj kaj rondira tempo. Sur pura loka vojo ambaŭ transportoj sentiĝas identaj, kial laboratoria provo malofte reproduktas la plendon. Sur kongestita poŝtelefona ligilo la diferenco montriĝas en interagaj sesioj longe antaŭ ol granda transigo rimarkas ion.

Nenio el tio tuŝas konfidencon aŭ integrecon. La TLS-manpremo kaj la ĉifro de la datkanalo estas la samaj por ambaŭ transportoj, do ŝanĝo ne povas savi malfortan ĉifraron.

Kie TCP meritą sian lokon

Alirretoj estas la kutima kialo elekti TCP. Hotelo, flughaveno aŭ gastreta reto eble permesas elirantan 443 kaj forĵetas ĉion alian, kaj TCP-aŭskultanto sur tiu pordo estas la sola profilo, kiu funkcias. Tio estas atingeblo, ne rendimento, kaj ĝi estas sufiĉe bona kialo per si mem.

TCP ankaŭ helpas kiam la vojo estas stabila sed la mezaj aparatoj estas malamikaj. Iuj retoj restarigas longdaŭrajn UDP-fluojn dum ili toleras TCP-sesiojn, kiuj similas ordinaran retan trafikon. Ĉu tiu simileco sukcesas, estas eco de la konkreta reto, kaj neniu gvidilo povas promesi ĝin por ĉiuj. Testu ene de la reto, kiu fiaskas, antaŭ ol kulpigi la protokolon.

Rifuzita ensaluto ne estas transporta problemo. Malŝalti la atestilan kontroladon por trudi konekton estas alia ŝanĝo kun multe pli malbona rezulto.

Teni TCP-profilon preta estas la praktika kompromiso. Plej multaj klientoj konservas ambaŭ kaj lasas vin ŝanĝi kiam reto rifuzas la UDP-vojon, kio kostas nenion ĝis vi bezonas ĝin. Tion, kion vi ne devus fari, estas liveri du profilojn montrantajn al malsamaj finpunktoj, ĉar tiam via komparo mezuras la servilojn.

Kontrolu, kiun aŭskultanton vi vere havas

Antaŭ ol kompari rendimenton, konfirmu, ke ambaŭ finoj konsentas pri la transporto kaj la pordo. Ŝanĝi proto udp al proto tcp en klienta dosiero ne kreas servilan aŭskultanton. La servilo devas esti agordita por tiu protokolo, kaj la profilo devas kongrui kun ĝi.

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

grep presas tion, kion oni diris al la servilo uzi, dum la du ingaj listoj montras, al kio ĝi estas ligita. UDP-aŭskultanto aperas nur en la unua listo kaj TCP-aŭskultanto nur en la dua, do mankanta linio estas la plej rapida vojo trovi profilon, kiu neniam estis aplikita. Komparu ankaŭ la pordon, ĉar TCP-profilo sur 1194 kondutas alie ol unu sur 443 en plej multaj alirretoj. Restartigu la servon post la ŝanĝo kaj legu la protokolan linion, kiu raportas la ligon.

Konfirmo ĉe la klienta flanko estas malmultekosta: rulu la konekton kun --verb 4 kaj legu la transportan linion en la protokolo. Se la kliento diras UDP dum la servilo aŭskultas sur TCP, la manpremo neniam komenciĝas kaj nenia agordo helpos.

Komparu la laborŝarĝon, ne la etikedon de la transporto

Justa komparo tenas ĉion krom la transporto konstanta. Sama aparato, sama alirreto, sama celloka gastiganto, sama aplikaĵo kaj ideale sama servilo. Se la du profiloj montras al malsamaj gastigantoj, vi ankaŭ mezuras tiujn gastigantojn.

Notu tri rezultojn por ĉiu rulo: ĉu la tunelo establiĝas, ĉu ĝi restas funkcia kaj ĉu la tasko finiĝas. Malgrandaj petoj, kiuj funkcias dum grandaj transigoj haltas, indikas pakaĵan grandecon kaj MTU, ne la transporton. Ripetaj rekonektoj indikas la vojon aŭ tempolimon de meza aparato.

Konservu la profilon, kiu funkcias sub la kondiĉoj, kiujn vi efektive renkontas, kaj konservu la alian. La elekto apartenas al la reto, ne al la persono, kaj tial ĉiu unu antaŭagorda respondo estas ie malĝusta.