Hvorfor Tor føles tregere enn en VPN: klikk kontra nedlastinger

Sider som føles klebrige mens nedlastinger går med normal hastighet, beskriver rundturer, ikke båndbredde. En VPN legger til ett kryptert hopp, og en Tor-krets legger til flere, og hvert ekstra hopp koster et håndtrykk før en eneste nyttig byte beveger seg. Den kostnaden viser seg på en side som åpner mange korte forbindelser, og forsvinner stort sett ved én stor overføring. Når mønsteret først er synlig, handler diskusjonen ikke lenger om hvilket verktøy som er raskest.

Symptomet peker på oppsettkostnad, ikke kapasitet

En sideinnlasting er en kjede av avhengige utvekslinger: et navneoppslag, et transporthåndtrykk, et TLS-håndtrykk, deretter den første forespørselen. Hvert hopp på veien setter sin egen rundtur inn i den kjeden før noe tegnes. En stor nedlasting betaler den samme oppsettkostnaden én gang og strømmer deretter, og det er nettopp derfor de to arbeidsbelastningene er uenige.

Les i nettverkspanelet tiden som brukes på å vente før den første byten, ikke totalen. Lang venting med en kort innholdsnedlasting peker på rundturer, mens en lang innholdsnedlasting med kort venting peker på gjennomstrømning. Gjenta mot en annen destinasjon, fordi én vert bak et travelt relé ikke beviser noe. Når overføringen er fin og klikket er tregt, mistenker du oppsettkostnaden lenge før båndbredden.

Forsinkelse og kapasitet feiler på ulike måter

Ta to avlesninger, og det meste av forvirringen løser seg selv. Latens er en fast kostnad per utveksling, og kapasitet er en hastighet over tid, så én vei kan være god på det første og dårlig på det andre. Et fjernt endepunkt med ledig prosessor svarer raskt på en liten forespørsel og begrenser likevel en vedvarende overføring til det opplinken tillater. Brukere opplever den splittelsen som et kjapt klikk etterfulgt av en fremdriftslinje som så vidt beveger seg.

Test kapasitet med en vedvarende overføring og se om hastigheten holder seg stabil eller sager. Test latens med en liten forespørsel gjentatt mange ganger, og les spredningen i stedet for den beste prøven, fordi en bred spredning føles verre enn gjennomsnittet antyder. Noter begge tallene før og etter hver endring, ellers gir du senere den gale variabelen æren.

Å behandle de to som ett tall gir rettelser som aldri flytter målingen du bryr deg om. Det er den vanligste måten en klage på latens besvares med en båndbreddeoppgradering.

Løkruting legger til hopp du ikke valgte

En Tor-krets bruker vanligvis tre reléer — en vakt, en midtnode og en utgang — og klienten velger dem fra en konsensus, ikke fra et kart. Veien kan derfor være mye lengre enn den direkte linjen til destinasjonen. Hvert relé bærer også andres trafikk, så strømmen din deler den kapasiteten reléet har igjen.

Gjenbruk av kretsen myker opp kostnaden, fordi en ny strøm kan ri på en eksisterende krets i stedet for å betale for nok en bygging. En klient som bygger en fersk krets per forespørsel, betaler oppsettet igjen og igjen og føles mye verre enn en som gjenbruker. Valget av utgang betyr også noe, fordi noen utganger bærer tyngre last, og ingenting i grensesnittet forteller deg hvilken du landet på. Den delingen er poenget med designet og grunnen til at latens ikke kan tunes til en fast verdi, så én treg utgang er en dårlig grunn til å forlate ordningen.

Å endre rekkefølgen i kjeden endrer eksperimentet

VPN først og Tor deretter er et annet eksperiment enn Tor først og VPN deretter. I den første ordningen bærer VPN-endepunktet hele kretsen, så tilgangsnettet ditt lærer bare VPN-adressen. I den andre bæres VPN-forbindelsen selv inne i løkveien, og utgangen ser VPN-trafikk. Begge er legitime design, og å sammenligne en av dem med en bar VPN måler noe annet, som er grunnen til at Tor-prosjektets side om å kombinere de to rammer det inn som et spørsmål om hva du prøver å skjule, før det er et spørsmål om timing.

Hold enheten, tilgangsnettet og destinasjonen fast, og endre nøyaktig ett element mellom kjøringene. Å flytte servere, kretser og testverter samtidig skaper en forskjell ingen kan tilskrive. Skriv ned hva hver ordning skjuler for hvem før du optimaliserer den, fordi en rask kjede som avdekker det du ville skjule, ikke er en forbedring.

En sammenligning som overlever en andre kjøring

Velg to eller tre destinasjoner du faktisk bruker, og ta tiden på den samme interaksjonen på hver, inkludert en side som drar mange små ressurser og én stor overføring. Gjenta hele settet på et annet tidspunkt av dagen.

Rapporter median og verste tilfelle i stedet for den raskeste prøven, fordi interaktivt arbeid vurderes etter sine dårlige øyeblikk. Noter klienten, endepunktet eller utgangen, og om kretsen eller tunnelen ble gjenbrukt for den kjøringen. Hvis en endring forbedrer medianen men forverrer halen, er det en byttehandel og ikke en seier, og å avgjøre om brukerne vil merke det, er den egentlige beslutningen.