Waarom Tor trager aanvoelt dan een VPN: klikken versus downloads

Pagina's die plakkerig aanvoelen terwijl downloads op normaal tempo lopen, beschrijven rondreizen, niet bandbreedte. Een VPN voegt één versleutelde sprong toe en een Tor-circuit meerdere, en elke extra sprong kost een handshake voordat er één nuttige byte beweegt. Die kosten zijn zichtbaar op een pagina die veel korte verbindingen opent en verdwijnen grotendeels bij één grote overdracht. Zodra het patroon zichtbaar is, gaat de discussie niet meer over welke tool sneller is.

Het symptoom wijst op opzetkosten, niet op capaciteit

Een paginalading is een keten van afhankelijke uitwisselingen: een naamopzoeking, een transporthandshake, een TLS-handshake en dan het eerste verzoek. Elke sprong in het pad voegt zijn eigen rondreis in die keten in voordat er iets wordt getekend. Een grote download betaalt dezelfde opzetkosten één keer en streamt daarna, en dat is precies waarom de twee werklasten het oneens zijn.

Lees in het netwerkpaneel de tijd die wordt gewacht vóór de eerste byte, niet het totaal. Lang wachten met een korte inhoudsdownload wijst op rondreizen, terwijl een lange inhoudsdownload met kort wachten op doorvoer wijst. Herhaal tegen een tweede bestemming, want één host achter een druk relay bewijst niets. Als de overdracht goed is en de klik traag, verdenk dan de opzetkosten veel eerder dan de bandbreedte.

Vertraging en capaciteit falen op verschillende manieren

Neem twee metingen en het meeste van de verwarring lost zichzelf op. Latentie is een vaste kost per uitwisseling en capaciteit is een snelheid over tijd, dus één pad kan goed zijn in het eerste en slecht in het tweede. Een ver verwijderd eindpunt met een luie processor antwoordt snel op een klein verzoek en begrenst toch een aanhoudende overdracht tot wat zijn uplink toelaat. Gebruikers ervaren die splitsing als een vlotte klik gevolgd door een voortgangsbalk die amper beweegt.

Test capaciteit met een aanhoudende overdracht en kijk of de snelheid stabiel blijft of zaagt. Test latentie met een klein verzoek dat vele malen wordt herhaald en lees de spreiding in plaats van het beste monster, want een brede spreiding voelt slechter dan het gemiddelde suggereert. Noteer beide getallen voor en na elke wijziging, anders schrijf je later de eer aan de verkeerde variabele toe.

De twee als één getal behandelen levert correcties op die nooit de meting verplaatsen die je belangrijk vindt. Dat is de meest voorkomende manier waarop een klacht over latentie wordt beantwoord met een bandbreedte-upgrade.

Ui-routing voegt sprongen toe die je niet hebt gekozen

Een Tor-circuit gebruikt meestal drie relays — een wachter, een middenknoop en een uitgang — en de client kiest ze uit een consensus, niet van een kaart. Het pad kan daardoor veel langer zijn dan de directe lijn naar de bestemming. Elk relay draagt ook andermans verkeer, dus je stream deelt de capaciteit die dat relay nog over heeft.

Hergebruik van het circuit verzacht de kosten, omdat een nieuwe stream op een bestaand circuit kan rijden in plaats van voor nog een opbouw te betalen. Een client die per verzoek een vers circuit bouwt, betaalt de opzet steeds opnieuw en voelt veel slechter dan een die hergebruikt. De keuze van de uitgang telt ook, want sommige uitgangen dragen zwaardere last en niets in de interface zegt je op welke je bent beland. Die deling is het punt van het ontwerp en de reden dat latentie niet op een vaste waarde kan worden afgestemd, dus één trage uitgang is een slechte reden om de opstelling op te geven.

De volgorde van de keten veranderen verandert het experiment

Eerst VPN en dan Tor is een ander experiment dan eerst Tor en dan VPN. In de eerste opstelling draagt het VPN-eindpunt het hele circuit, dus je toegangsnetwerk leert alleen het VPN-adres. In de tweede wordt de VPN-verbinding zelf in het uienpad gedragen, en de uitgang ziet VPN-verkeer. Beide zijn legitieme ontwerpen, en een van beide met een kale VPN vergelijken meet iets anders, daarom de pagina van het Tor Project over het combineren van de twee het kadert als een vraag over wat je probeert te verbergen voordat het een vraag over timing is.

Houd het apparaat, het toegangsnetwerk en de bestemming vast, en verander tussen runs precies één element. servers, circuits en testhosts samen verplaatsen levert een verschil op dat niemand kan toeschrijven. Schrijf op wat elke opstelling voor wie verbergt voordat je hem optimaliseert, want een snelle keten die onthult wat je wilde verbergen is geen verbetering.

Een vergelijking die een tweede run overleeft

Kies twee of drie bestemmingen die je echt gebruikt en meet dezelfde interactie op elk, inclusief een pagina die veel kleine bronnen trekt en één grote overdracht. Herhaal de hele set op een ander uur van de dag.

Rapporteer de mediaan en het slechtste geval in plaats van het snelste monster, want interactief werk wordt beoordeeld op zijn slechte momenten. Noteer de client, het eindpunt of de uitgang, en of het circuit of de tunnel voor die run is hergebruikt. Als een wijziging de mediaan verbetert maar de staart verslechtert, is dat een ruil en geen overwinning, en beslissen of gebruikers het zullen merken is de echte beslissing.