De prestaties van een onion service worden op de server bepaald: waar de milliseconden heen gaan en wat een operator echt kan bijsturen
Als een onionsite traag aanvoelt, is de reflex om het Tor-netwerk de schuld te geven. Dat klopt maar tot op zekere hoogte. Een hidden service spreekt bezoekers nooit rechtstreeks, en elke verbinding wordt in elkaar gezet uit relays die beide kanten kiezen; maar een echt deel van de wachttijd wordt gefabriceerd op de eigen machine van de service, in hoe Tor de leidingen voor het webbackend beheert. Weten welke helft welke is, bepaalt of bijsturen helpt of alleen de schuld verplaatst.
Waar de milliseconden heen gaan
Het protocoloverzicht van het Tor Project rekent een complete onion-verbinding op zes relays: drie gekozen door de client, drie door de service, samengevoegd in een rendezvouspunt dat daarna "gewoon (end-to-end versleutelde) berichten van client naar service en terug doorgeeft" (Tor Project, onion-serviceprotocol). Voordat dat circuit bestaat, zijn er al rondes verbruikt: de client haalt de ondertekende descriptor van de service uit een gedistribueerde hashtabel, bouwt een route naar een van de introductiepunten en onderhandelt de rendezvous. Geen daarvan is backendtijd, maar alles landt op de stopwatch van de bezoeker. De servicekant draagt bovendien een vaste kost die geen client betaalt. Introductiepunten houden langdurige geanonimiseerde circuits van de service open, en de Tor-handleiding zet de standaardpool op drie introductiepunten, uitbreidbaar tot twintig bij een v3-service. Omdat die relays het enige adres van de service zijn, mogen ze niet geruisloos verdwijnen: valt er één uit, dan moet de service een nieuw circuit met drie hops bouwen en zijn ondertekende descriptor opnieuw publiceren - werk dat zichtbaar wordt als koudere, tragere eerste loads.Wat een operator werkelijk stuurt
Tor biedt een korte lijst knoppen, smaller dan het performance-volksverhaal doet vermoeden:- Cryptoruimte. De handshakes die introducties en rendezvous opleveren, worden ontsleuteld door een pool van cryptoworkers; de handleiding beschrijft NumCPUs als "hoeveel processen tegelijk te gebruiken voor het ontsleutelen van onionskins en andere paralleliseerbare bewerkingen". Een service met CPU-honger voelt traag aan precies waar een operator kan ingrijpen.
- Poolgrootte. HiddenServiceNumIntroductionPoints staat standaard op drie; meer introductiepunten verdelen introducties over meer relays, ten koste van meer permanente circuits.
- Circuitversheid. MaxCircuitDirtiness staat standaard op tien minuten, en de handleiding merkt op dat bij hidden services de leeftijd telt vanaf het laatste gebruik van het circuit. Verhogen vermindert herbouw; verlagen ruilt meer builds in voor nieuwere routes.
- Softwareversheid. Congestiecontrole kwam met Tor 0.4.7 in 2022, en het Tor Project was keihard: "gebruikers van Tor 0.4.7 en hoger merken betere prestaties bij exits of onion services die naar 0.4.7 zijn bijgewerkt" - een service op een oudere versie zet elke bezoeker vast in legacy flow control (blog van het Tor Project).
De single-hop-verleiding
Het oudste performancedebat in deze hoek van Tor is of de service drie hops bescherming nodig heeft. Proposal 260, in 2015 geschreven door een groep met Roger Dingledine en Paul Syverson en geïmplementeerd in Tor 0.2.9.3-alpha, beschrijft "rendezvous single onion services" die "locatieprivacy aan de servicekant inruilen voor betere prestaties, betrouwbaarheid en schaalbaarheid", met één-hop-circuits naar introductie- en rendezvouspunten en een route ingekort tot "4 in plaats van 6" relays. De schakelaar bestaat nog: HiddenServiceSingleHopMode staat te boek als experimenteel en niet-anoniem; het maakt de server "gemakkelijk lokaliseerbaar" terwijl "clients anoniem blijven". De ruil is zonder poedersuiker. Een single onion houdt zijn .onion-adres en de anonimiteit van zijn bezoekers, maar geeft de locatieverhulling van de operator prijs - en de auteurs van de proposal waarschuwden dat elke extra smaak onion service "de anonimiteitsset splitst". Daarom overleeft het standaardontwerp: single-hop blijft een opt-in gereedschap voor operators die blootstelling accepteren, een oordeel dat Tor bewust buiten het protocol laat.Waarom grote property's getunede backends draaien
Langlevende onion-property's - zoekmachines, mirrors, directories - komen op dezelfde vorm uit: dunne Tor-frontends, opzettelijk statische of gecachte backends en load verspreid over instanties. Proposal 260 merkt zelfs op dat een rendezvous single onion service "load kan balanceren over meerdere rendezvous backends". Niets daarvan verkort de route; het minimaliseert het enige segment dat de operator bezit, zodat de reis langs zes relays de enige noemenswaardige wachttijd blijft. Tor Metrics meet onion-verkeer door te extrapoleren uit statistieken van relays die als rendezvouspunten dienen - precies die laag draagt de zichtbare last (Tor Metrics).Wat te repareren valt - en wat niet
"Omdat onion-servicepaden meer dan twee keer zo lang zijn als exit-paden (en dus meer dan twee keer de circuitlatentie), zal de doorvoer van een onion service altijd minder dan de helft van de exit-doorvoer zijn" (Proposal 324).Een operator kan cryptoruimte, poolgrootte, softwareversie en backendgewicht repareren. Padlengte, de circuitbouwtijden van die dag, relaycongestie en de guardrotatie van de client niet. De eerlijke lezing: een eerste ongecachte paginalading die seconden duurt is geen kapotte site - het zijn descriptor, introductie en rendezvous die volledig worden betaald - terwijl verzoeken over een warm circuit dicht bij de eigen reactietijd van het backend plus transit moeten blijven. Blijft een service na de eerste pagina traag, dan heeft de operator vrijwel zeker ruimte om in te grijpen. Voelt hij alleen rond middernachtpieken traag aan, dan is de netwerkdienst aan zet, niet het backend - het patroon dat onze eerdere veldnotities over onion-latentievariatie beschrijven. Aan de servicekant zijn de winsten echt maar begrensd: stuur bij wat torrc bezit, houd de origin licht en verwacht geen route die korter is dan het protocol maakt.