Kvifor Tor kjennest tregare enn ein VPN: klikk mot nedlastingar

Sider som kjennest klebrige medan nedlastingar går med normal fart, skildrar rundturar, ikkje bandbreidd. Ein VPN legg til eitt kryptert hopp, og ein Tor-krins legg til fleire, og kvart ekstra hopp kostar eit handslag før ein einaste nyttig byte flyttar seg. Den kostnaden syner seg på ei side som opnar mange korte samband, og forsvinn stort sett ved éi stor overføring. Når mønsteret først er synleg, handlar diskusjonen ikkje lenger om kva verktøy som er raskast.

Symptomet peikar på oppsettkostnad, ikkje kapasitet

Ei sideinnlasting er ei kjede av avhengige utvekslingar: eit namneoppslag, eit transportshandslag, eit TLS-handsla, deretter den første førespurnaden. Kvart hopp på vegen set sin eigen rundtur inn i den kjeda før noko blir teikna. Ei stor nedlasting betaler den same oppsettkostnaden éin gong og straumar deretter, og det er nettopp derfor dei to arbeidslastene er usamde.

Les i nettverkspanelet tida som blir brukt på å vente før den første byten, ikkje totalen. Lang venting med ei kort innhaldsnedlasting peikar på rundturar, medan ei lang innhaldsnedlasting med kort venting peikar på gjennomstrøyming. Gjenta mot ein annan destinasjon, fordi éin vert bak eit travelt relé ikkje beviser noko. Når overføringa er fin og klikket er tregt, mistenk oppsettkostnaden lenge før bandbreidda.

Forsinking og kapasitet feilar på ulike måtar

Ta to avlesingar, og det meste av forvirringa løyser seg sjølv. Latens er ein fast kostnad per utveksling, og kapasitet er ein fart over tid, så ein veg kan vere god på det første og dårleg på det andre. Eit fjernt endepunkt med ledig prosessor svarar raskt på ein liten førespurnad og avgrensar likevel ei vedvarande overføring til det opplenkja tillèt. Brukarar opplever den splittinga som eit kjapt klikk etterfølgt av ei framdriftslinje som så vidt rører seg.

Test kapasitet med ei vedvarande overføring og sjå om farten held seg stabil eller sagar. Test latens med ein liten førespurnad gjenteken mange gonger, og les spreiinga i staden for den beste prøva, fordi ei brei spreiing kjennest verre enn gjennomsnittet tyder på. Noter båe tala før og etter kvar endring, elles gir du seinare den gale variabelen æra.

Å handsame dei to som eitt tal gir rettingar som aldri flyttar målinga du bryr deg om. Det er den vanlegaste måten ei klage på latens blir svara med ei bandbreidda-oppgradering.

Løkruting legg til hopp du ikkje valde

Ein Tor-krins brukar vanlegvis tre relé — ein vakt, ein midtknute og ein utgang — og klienten vel dei frå ein konsensus, ikkje frå eit kart. Vegen kan derfor vere mykje lengre enn den direkte linja til destinasjonen. Kvart relé ber òg trafikken til andre, så straumen din deler den kapasiteten reléet har att.

Gjenbruk av krinsen mjukar opp kostnaden, fordi ein ny straum kan ri på ein eksisterande krins i staden for å betale for nok ein bygg. Ein klient som byggjer ein fersk krins per førespurnad, betaler oppsettet om og om att og kjennest mykje verre enn ein som gjenbrukar. Valet av utgang tel òg, fordi nokre utgangar ber tyngre last, og ingenting i grensesnittet fortel deg kva ein du landa på. Den delinga er poenget med designet og grunnen til at latens ikkje kan stillast til ein fast verdi, så éin treg utgang er ein dårleg grunn til å forlate ordninga.

Å endre rekkjefølgja i kjeda endrar eksperimentet

VPN først og Tor deretter er eit anna eksperiment enn Tor først og VPN deretter. I den første ordninga ber VPN-endepunktet heile krinsen, så tilgangsnettet ditt lærer berre VPN-adressa. I den andre blir VPN-sambandet sjølv bore inne i løkvegen, og utgangen ser VPN-trafikk. Båe er legitime design, og å samanlikne ein av dei med ein bar VPN måler noko anna, som er grunnen til at sida til Tor-prosjektet om å kombinere dei to rammar det inn som eit spørsmål om kva du prøver å skjule, før det er eit spørsmål om timing.

Hald eininga, tilgangsnettet og destinasjonen fast, og endre nøyaktig eitt element mellom køyringane. Å flytte tenarar, krinsar og testvertar samstundes skaper ein skilnad ingen kan tilskrive. Skriv ned kva kvar ordning skjuler for kven før du optimaliserer henne, fordi ei rask kjede som avdekkjer det du ville skjule, ikkje er ei betring.

Ei samanlikning som overlever ei andre køyring

Vel to eller tre destinasjonar du faktisk brukar, og ta tida på den same interaksjonen på kvar, inkludert ei side som dreg mange små ressursar og éi stor overføring. Gjenta heile settet på eit anna tidspunkt av dagen.

Rapporter median og verste tilfelle i staden for den raskaste prøva, fordi interaktivt arbeid blir vurdert etter sine dårlege augneblinkar. Noter klienten, endepunktet eller utgangen, og om krinsen eller tunnelen vart gjenbrukt for den køyringa. Viss ei endring betrar medianen men forverrar halen, er det ein byttehandel og ikkje ein siger, og å avgjere om brukarane vil merke det, er den eigentlege avgjerda.