Hvorfor Tor føles langsommere end en VPN: klik mod downloads

Sider, der føles klæbrige, mens downloads kører med normal hastighed, beskriver rundture, ikke båndbredde. En VPN tilføjer et krypteret spring, og et Tor-kredsløb tilføjer flere, og hvert ekstra spring koster et håndtryk, før en enkelt nyttig byte flytter sig. Den omkostning viser sig på en side, der åbner mange korte forbindelser, og forsvinder stort set ved én stor overførsel. Når mønstret først er synligt, handler diskussionen ikke længere om, hvilket værktøj der er hurtigst.

Symptomet peger på opsætningsomkostninger, ikke kapacitet

Indlæsning af en side er en kæde af afhængige udvekslinger: et navneopslag, et transporthåndtryk, et TLS-håndtryk og derefter den første anmodning. Hvert spring på vejen indsætter sin egen rundtur i den kæde, før noget tegnes. En stor download betaler den samme opsætningsomkostning én gang og streamer derefter, og det er netop derfor, de to arbejdsbelastninger er uenige.

Læs i netværkspanelet den tid, der bruges på at vente før den første byte, ikke totalen. Lang ventetid med en kort indholdsdownload peger på rundture, mens en lang indholdsdownload med kort ventetid peger på gennemstrømning. Gentag mod en anden destination, fordi én vært bag et travlt relæ ikke beviser noget. Når overførslen er fin, og klikket er langsomt, skal du mistænke opsætningsomkostninger længe før båndbredde.

Forsinkelse og kapacitet fejler på forskellige måder

Tag to aflæsninger, og det meste af forvirringen løser sig selv. Latenstid er en fast omkostning per udveksling, og kapacitet er en hastighed over tid, så én vej kan være god i det første og dårlig i det andet. Et fjernt endepunkt med en ledig processor besvarer en lille anmodning hurtigt og begrænser stadig en vedvarende overførsel til det, dets uplink tillader. Brugere oplever den opdeling som et kvikt klik efterfulgt af en statuslinje, der næsten ikke rykker sig.

Test kapacitet med en vedvarende overførsel, og se, om hastigheden holder sig stabil eller savtand. Test latenstid med en lille anmodning gentaget mange gange, og læs spredningen i stedet for den bedste prøve, fordi en bred spredning føles værre, end gennemsnittet antyder. Notér begge tal før og efter hver ændring, ellers giver du senere den forkerte variabel æren.

At behandle de to som ét tal giver rettelser, der aldrig flytter den måling, du bekymrer dig om. Det er den mest almindelige måde, hvorpå en klage over latenstid besvares med en båndbreddeopgradering.

Løgrouting tilføjer spring, du ikke valgte

Et Tor-kredsløb bruger normalt tre relæer — en vagt, en midterknude og en udgang — og klienten vælger dem ud fra en konsensus, ikke ud fra et kort. Vejen kan derfor være langt længere end den direkte linje til destinationen. Hvert relæ bærer også andres trafik, så din strøm deler den kapacitet, relæet har tilbage.

Genbrug af kredsløb bløder omkostningen op, fordi en ny strøm kan køre på et eksisterende kredsløb i stedet for at betale for endnu en opbygning. En klient, der bygger et frisk kredsløb per anmodning, betaler opsætning igen og igen og føles langt værre end en, der genbruger. Valget af udgang betyder også noget, fordi nogle udgange bærer tungere last, og intet i grænsefladen fortæller dig, hvilken du landede på. Den deling er pointen med designet og grunden til, at latenstid ikke kan tunes til en fast værdi, så én langsom udgang er en dårlig grund til at opgive ordningen.

At ændre kædens rækkefølge ændrer eksperimentet

VPN først og Tor derefter er et andet eksperiment end Tor først og VPN derefter. I den første ordning bærer VPN-endepunktet hele kredsløbet, så dit adgangsnetværk lærer kun VPN-adressen at kende. I den anden bæres VPN-forbindelsen selv inde i løgvejen, og udgangen ser VPN-trafik. Begge er legitime designs, og at sammenligne en af dem med en bar VPN måler noget andet, hvilket er grunden til, at Tor-projektets side om at kombinere de to rammer det som et spørgsmål om, hvad du prøver at skjule, før det er et spørgsmål om timing.

Hold enheden, adgangsnetværket og destinationen fast, og skift præcis ét element mellem kørslerne. At flytte servere, kredsløb og testværter sammen skaber en forskel, som ingen kan tilskrive. Skriv ned, hvad hver ordning skjuler for hvem, før du optimerer den, fordi en hurtig kæde, der afslører det, du ville skjule, ikke er en forbedring.

En sammenligning, der overlever en anden kørsel

Vælg to eller tre destinationer, du faktisk bruger, og tag tid på den samme interaktion på hver, inklusive en side, der trækker mange små ressourcer, og én stor overførsel. Gentag hele sættet på et andet tidspunkt af dagen.

Rapportér median og værste tilfælde i stedet for den hurtigste prøve, fordi interaktivt arbejde vurderes på sine dårlige øjeblikke. Notér klienten, endepunktet eller udgangen, og om kredsløbet eller tunnelen blev genbrugt til den kørsel. Hvis en ændring forbedrer medianen, men forværrer halen, er det en handel snarere end en sejr, og at afgøre, om brugerne vil bemærke det, er den egentlige beslutning.