Varför Tor känns långsammare än en VPN: klick kontra nedladdningar

Sidor som känns tröga medan nedladdningar går i normal takt beskriver rundturer, inte bandbredd. En VPN lägger till ett krypterat hopp och en Tor-krets lägger till flera, och varje extra hopp kostar ett handskak innan en enda nyttig byte rör sig. Den kostnaden syns på en sida som öppnar många korta anslutningar och försvinner nästan helt vid en enda stor överföring. När mönstret väl är synligt handlar diskussionen inte längre om vilket verktyg som är snabbast.

Symtomet pekar på installationskostnad, inte kapacitet

En sidladdning är en kedja av beroende utbyten: en namnsökning, ett transporthandskak, ett TLS-handskak och sedan den första begäran. Varje hopp på vägen sätter in sin egen rundtur i den kedjan innan något ritas. En stor nedladdning betalar samma installationskostnad en gång och strömmar sedan, och det är just därför de två arbetsbelastningarna inte är överens.

Läs i nätverkspanelen tiden som spenderas på att vänta före den första byten, inte totalen. Lång väntan med en kort innehållsnedladdning pekar på rundturer, medan en lång innehållsnedladdning med kort väntan pekar på genomströmning. Upprepa mot en andra destination, eftersom en enda värd bakom en upptagen relä inte bevisar något. När överföringen är bra och klicket långsamt, misstänk installationskostnaden långt före bandbredden.

Fördröjning och kapacitet misslyckas på olika sätt

Ta två avläsningar och det mesta av förvirringen löser sig själv. Latens är en fast kostnad per utbyte och kapacitet är en hastighet över tid, så en väg kan vara bra på det första och dålig på det andra. En avlägsen slutpunkt med ledig processor svarar snabbt på en liten begäran och begränsar ändå en varaktig överföring till vad dess upplänk tillåter. Användare upplever den uppdelningen som ett snabbt klick följt av en förloppsindikator som knappt rör sig.

Testa kapacitet med en varaktig överföring och se om hastigheten håller sig stabil eller sågar. Testa latens med en liten begäran som upprepas många gånger och läs spridningen i stället för det bästa provet, eftersom en bred spridning känns sämre än genomsnittet antyder. Anteckna båda talen före och efter varje ändring, annars ger du senare den felaktiga variabeln äran.

Att behandla de två som ett enda tal ger korrigeringar som aldrig flyttar mätningen du bryr dig om. Det är det vanligaste sättet som ett klagomål på latens besvaras med en bandbreddsuppgradering.

Lökdirigering lägger till hopp du inte valde

En Tor-krets använder normalt tre reläer — en vakt, en mittnod och en utgång — och klienten väljer dem från en konsensus, inte från en karta. Vägen kan därför vara mycket längre än den raka linjen till destinationen. Varje relä bär också andras trafik, så din ström delar den kapacitet som reläet har kvar.

Återanvändning av kretsen mjukar upp kostnaden, eftersom en ny ström kan rida på en befintlig krets i stället för att betala för ännu en uppbyggnad. En klient som bygger en färsk krets per begäran betalar installationen om och om igen och känns mycket sämre än en som återanvänder. Valet av utgång spelar också roll, eftersom vissa utgångar bär tyngre last och ingenting i gränssnittet säger vilken du landade på. Den delningen är poängen med designen och skälet till att latens inte kan ställas in på ett fast värde, så en långsam utgång är ett dåligt skäl att överge upplägget.

Att ändra kedjans ordning ändrar experimentet

VPN först och Tor sedan är ett annat experiment än Tor först och VPN sedan. I det första upplägget bär VPN-slutpunkten hela kretsen, så ditt åtkomstnät lär sig bara VPN-adressen. I det andra bärs VPN-anslutningen själv inne i lökvägen, och utgången ser VPN-trafik. Båda är legitima designer, och att jämföra någon av dem med en bar VPN mäter något annat, vilket är skälet till att Tor-projektets sida om att kombinera de två ramar in det som en fråga om vad du försöker dölja innan det är en fråga om timing.

Håll enheten, åtkomstnätet och destinationen fasta och ändra exakt ett element mellan körningarna. Att flytta servrar, kretsar och testvärdar tillsammans skapar en skillnad som ingen kan tillskriva. Skriv ned vad varje upplägg döljer för vem innan du optimerar det, eftersom en snabb kedja som avslöjar det du ville dölja inte är en förbättring.

En jämförelse som överlever en andra körning

Välj två eller tre destinationer du faktiskt använder och ta tid på samma interaktion på varje, inklusive en sida som drar många små resurser och en stor överföring. Upprepa hela uppsättningen vid en annan timme på dagen.

Rapportera median och värsta fall i stället för det snabbaste provet, eftersom interaktivt arbete bedöms efter sina dåliga ögonblick. Anteckna klienten, slutpunkten eller utgången och om kretsen eller tunneln återanvändes för den körningen. Om en ändring förbättrar medianen men försämrar svansen är det ett byte och inte en seger, och att avgöra om användarna kommer att märka det är det egentliga beslutet.