Kial du VPN-rapidecaj testoj en la sama tunelo malkonsentas

Du ruloj, unu tunelo, kaj la nombroj diferenciĝas per faktoro tri. La tunelo ne ŝanĝiĝis inter ili. Tio, kio ŝanĝiĝis, estas la mezurado: testa retejo, kiu elektas servilon laŭ via ŝajna loko, nombro de fluoj, kiu decidas ĉu unu malrapida komenco aŭ ses plenigas la tubon, kaj daŭro sufiĉe mallonga por finiĝi antaŭ ol la vojo eĉ komencas esti ĝuste uzata. Rapidecaj testoj ne malĝustas, sed ili respondas pli mallarĝan demandon ol tiu, kiun homoj al ili starigas.

Nova elira adreso ŝanĝas la testan celon

Plej multaj testaj retejoj elektas mezuran servilon aŭtomate, kaj ili elektas ĝin parte rigardante, de kie via konekto ŝajne venas. Ŝaltu la tunelon kaj via ŝajna lando ŝanĝiĝas, do la elektita servilo ŝanĝiĝas, kaj la komparo nun ampleksas du malsamajn vojojn al du malsamaj gastigantoj.

La rezulto tute ne estas VPN-mezurado. Ĝi estas mezurado de via vojo al servilo, kiun vi ne elektis, kaj la diferencon inter la du ruloj povas regi la peerado de tiu servilo anstataŭ io, kion la tunelo faris.

Fiksu la celon antaŭ ol ŝanĝi ion ajn alian. Ĉiu fidinda ilo permesas al vi eksplicite elekti servilon, kaj kiam ĝi ne faras, la rezulta paĝo kutime nomas la uzitan, kio sufiĉas por rimarki, ke la du ruloj ne estas kompareblaj. Konfirmu, kion la retejo vidis, antaŭ ol fidi ĝian elekton:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Se la lando ŝanĝiĝis inter la ruloj, ĉio, kion la testo elektis poste, ankaŭ ŝanĝiĝis. Skribu la observitan eliron apud ĉiu rezulto kaj la konfuzo plejparte malaperas.

Malrapida komenco finiĝas post la fino de plej multaj mallongaj testoj

TCP-konekto ne komenciĝas je la ligila rapideco. Ĝi komenciĝas per malgranda kongesta fenestro, duobligas ĝin proksimume ĉiun rondiron, kaj atingas la kapaciton de la vojo nur post pluraj rondiroj. Dek-sekunda testo sur vojo kun alta latenteco povas pasigi signifan parton de sia vivo en tiu supreniro.

Tial tunelo kun pli alta latenteco rezultas pli malbone en mallonga testo ol ĝi meritas, kaj tial pli longa rulo ofte raportas pli altan nombron sen ia ajn ŝanĝo de agordo. La trakvanta kadro RFC 6349 traktas tion eksplicite, kaj tial seriozaj mezuradoj daŭras sufiĉe longe por atingi stabilan staton. Kvin-sekunda rulo sur satelita vojo mezuras la akcelilon, ne la vojon.

Rigardu la fazojn de la konekto anstataŭ fidi unu solan nombron. Curl raportas ĉiun etapon aparte, do vi povas vidi, ĉu tempo iras en la manpremon, la supreniron aŭ la transigon:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Rulu ĝin dufoje sinsekve al la sama celo. Se la dua rulo estas multe pli rapida, vi mezuris la supreniron, ne la vojon, kaj ĉiu komparo, kiu uzis nur la unuan rulon, estas suspektinda.

Unu fluo kaj ses fluoj mezuras malsamajn aferojn

Unuopa TCP-fluo estas limigita de la fenestro, kiun ĝi povas teni en flugo, kio estas proksimume la rondira tempo multiplikita per la rapideco. Sur longa vojo tiu produkto superas tion, kion unu fluo uzos, do unu elŝuto subraportas la ekzistantan kapaciton. Ses paralelaj fluoj plenigas la breĉon kaj produktas pli grandan nombron.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Ambaŭ nombroj veras. La nombro de unu fluo diras, kion faros unu elŝuto, kion kutime ricevas langeto de retumilo. La paralela nombro diras, kion la vojo povas porti entute, kion povas uzi torento aŭ multparta elŝuto. Citi unu kvazaŭ ĝi estus la alia estas la maniero, per kiu sana tunelo anstataŭiĝas sen kaŭzo.

Kompari paralelan rezulton kun rezulto de unu fluo estas la plej ordinara maniero, per kiu homoj konkludas, ke VPN duonigis ilian rapidon. Egaligu la metodon, poste komparu. La spuro en la tria komando aldonas la mankan kuntekston: vojo kun alta ĵitero produktos nekonsekvencajn rezultojn en ambaŭ reĝimoj, kaj neniu nombro de fluoj tion riparas.

Ĉifrado kostas procesoran tempon, enkapsuligo kostas bajtojn

Du mekanismoj funkcias sur ĉiu paketo sendepende de tio, kiom rapida estas la ligilo. Ĉifrado konsumas procesoron po bajto, kaj enkapsuligo aldonas kapliniojn, kiujn la ligilo ankoraŭ devas porti. Ambaŭ montriĝas kiel plafono, kaj ili havas malsamajn simptomojn.

La procesora plafono aperas kiel altebenaĵo: la trakvanto ĉesas kreski, kiom ajn da fluoj vi aldonas, kaj la procesoro de la maŝino estas okupata dum la ligilo ne estas. Sur malgranda enkursigilo aŭ telefono tio ofte estas la reala limo, kaj tial rapida linio ankoraŭ povas doni modestan tunelon.

La baja kosto estas pli malgranda sed konstanta. Pliaj kaplinioj signifas malpli da utila ŝarĝo po paketo, kaj sur vojo kun fiksa maksimuma transsendunuo ili ankaŭ povas kaŭzi fragmentadon aŭ nigran truon, kiu montriĝas kiel halto ĉe grandaj transigoj anstataŭ kiel malrapida mezumo.

Ĉi tiuj tri ofte konfuziĝas ĉar uzantoj priskribas ilin ĉiujn kiel «la VPN estas malrapida». Nur la unua reagas al pli granda maŝino, nur la dua reagas al pli malgranda MTU, kaj nur la tria reagas al administrado de atendovicoj.

Metu la metodon en la rikordon

Rezulto inda je konservado nomas la aparaton, la alirreton, la eliron, la mezuran servilon, la direkton, la nombron de fluoj kaj la daŭron. Sen tiuj, du nombroj ne kompareblas, kaj bileto kun unu nombro estas fakte humoro.

Konservu ankaŭ la malbonajn rulojn. Serio, kie unu eliro ĉiufoje kaŭzas halton, estas multe pli informa ol mezumo, kaj la haltoj estas ĝuste tio, kion mezumoj kaŝas.

Poste testu tion, kio vere gravas al vi. Se granda elŝuto estas la celo, elŝutu la dosieron. Se alvoko estas la celo, mezuru latentecon sub ŝarĝo anstataŭ senokupan trakvanton, ĉar tunelo povas bone poenti en rapideca testo kaj tamen igi ĉiun kunvenon neaŭdebla.