Onion-Service-Performance entsteht auf der Serverseite: Wo die Millisekunden bleiben und was Betreiber wirklich einstellen können
Wenn eine Onion-Seite langsam wirkt, lautet der Reflex: Schuld ist das Tor-Netzwerk. Das stimmt nur bis zu einem Punkt. Ein Hidden Service spricht nie direkt mit Besuchern, und jede Verbindung wird aus Relays zusammengesetzt, die beide Seiten wählen - aber ein echter Teil der Wartezeit entsteht auf dem eigenen Server, in der Art, wie Tor die Leitungen vor dem Web-Backend verwaltet. Zu wissen, welche Hälfte welche ist, entscheidet, ob Tuning etwas bringt oder nur die Schuld verschiebt.
Wo die Millisekunden bleiben
Die Protokollübersicht des Tor Project zählt eine vollständige Onion-Verbindung mit sechs Relays: drei vom Client gewählt, drei vom Dienst, verbunden an einem Rendezvous-Punkt, der danach lediglich „end-to-end verschlüsselte Nachrichten vom Client zum Dienst und zurück weiterleitet“ (Tor Project, Onion-Service-Protokoll). Bevor dieser Schaltkreis existiert, sind bereits mehrere Rundreisen verbraucht: Der Client lädt den signierten Descriptor aus einer verteilten Hashtabelle, baut einen Pfad zu einem der Introduction-Punkte und verhandelt das Rendezvous. Das alles ist keine Backend-Zeit, landet aber vollständig auf der Stoppuhr des Besuchers. Die Serverseite trägt zudem eine Grundkosten, die kein Client zahlt. Introduction-Punkte halten langfristige, anonymisierte Schaltkreise vom Dienst offen, und das Tor-Handbuch setzt den Standard-Pool auf drei Introduction-Punkte, erweiterbar auf zwanzig bei einem v3-Dienst. Weil diese Relays die einzige Adresse des Dienstes sind, dürfen sie nicht still verschwinden - fällt einer aus, muss der Dienst einen neuen Drei-Hop-Schaltkreis aufbauen und seinen signierten Descriptor neu veröffentlichen; Arbeit, die als kältere, langsamere erste Aufrufe sichtbar wird.Was ein Betreiber wirklich steuern kann
Tor hält eine kurze Liste von Stellschrauben bereit - schmaler, als manches Performance-Gerücht behauptet:- Krypto-Reserven. Die Handshakes, die Introductions und Rendezvous erzeugen, werden von einem Pool aus Krypto-Workern entschlüsselt; das Handbuch beschreibt NumCPUs als „wie viele Prozesse gleichzeitig zum Entschlüsseln von Onionskins und anderen parallelisierbaren Vorgängen verwendet werden“. Ein CPU-hungriger Dienst fühlt sich genau dort langsam an, wo ein Betreiber etwas reparieren kann.
- Größe des Introduction-Pools. HiddenServiceNumIntroductionPoints steht standardmäßig auf drei; mehr Intro-Punkte verteilen Introductions auf mehr Relays zum Preis zusätzlicher Dauerschaltkreise.
- Schaltkreis-Frische. MaxCircuitDirtiness liegt standardmäßig bei zehn Minuten, und das Handbuch vermerkt, dass bei Hidden Services das Alter ab der letzten Nutzung eines Schaltkreises zählt. Höher ansetzen verringert den Neuaufbau-Aufwand; niedriger bedeutet mehr Aufbauten für frischere Pfade.
- Software-Stand. Congestion Control kam 2022 mit Tor 0.4.7, und das Tor Project stellte unmissverständlich klar: „Nutzer von Tor-Versionen 0.4.7 und höher erleben schnellere Leistung, wenn sie Exits oder Onion Services nutzen, die auf 0.4.7 aktualisiert wurden“ - ein Onion-Dienst auf älterem Stand sperrt jeden Besucher in der alten Flow Control (Tor Project Blog).
Die Single-Hop-Versuchung
Die älteste Performance-Debatte in dieser Ecke von Tor dreht sich darum, ob der Dienst überhaupt drei Hops Schutz braucht. Proposal 260, 2015 von einer Gruppe um Roger Dingledine und Paul Syverson entworfen und in Tor 0.2.9.3-alpha umgesetzt, beschreibt „Rendezvous Single Onion Services“, die „standortbezogene Privatsphäre auf der Serverseite für verbesserte Leistung, Zuverlässigkeit und Skalierbarkeit eintauschen“, mit Ein-Hop-Schaltkreisen zu Introduction- und Rendezvous-Punkten und einem auf „4 statt 6“ Relays verkürzten Pfad. Der Schalter existiert bis heute: HiddenServiceSingleHopMode gilt als experimentell und nicht-anonym; er macht den Server „leicht auffindbar“, während „Clients anonym bleiben“. Der Tausch ist unversöhnlich klar. Ein Single Onion behält seine .onion-Adresse und die Anonymität seiner Besucher, gibt aber die Standortverschleierung des Betreibers auf - und die Autoren des Proposals warnten, dass jede zusätzliche Variante von Onion-Diensten „die Anonymitätsmenge spaltet“. Deshalb überlebt der Standardentwurf: Single-Hop bleibt ein Opt-in-Werkzeug für Betreiber, die Exposition akzeptieren können - eine Abwägung, die Tor bewusst außerhalb des Protokolls lässt.Warum große Anbieter getunte Backends fahren
Langlebige Onion-Angebote - Suchmaschinen, Mirror, Verzeichnisse - konvergieren auf dieselbe Form: dünne Tor-Frontends, bewusst statische oder gecachte Backends und verteilte Last über mehrere Instanzen. Proposal 260 vermerkt sogar, ein Rendezvous-Single-Onion-Dienst „kann über mehrere Rendezvous-Backends lastverteilen“. Nichts davon verkürzt den Pfad; es minimiert das eine Segment, das der Betreiber besitzt, sodass die Sechs-Relay-Route die einzige nennenswerte Wartezeit bleibt. Tor Metrics misst Onion-Traffic, indem es aus Statistiken von Relays extrapoliert, die als Rendezvous-Punkte agieren - genau diese Schicht trägt die sichtbare Last (Tor Metrics).Was reparierbar ist - und was nicht
„Weil Onion-Service-Pfade mehr als doppelt so lang sind wie Exit-Pfade (und damit mehr als doppelt so hohe Schaltkreis-Latenz haben), wird der Onion-Service-Durchsatz immer weniger als die Hälfte des Exit-Durchsatzes betragen.“ (Proposal 324)Betreiber können Krypto-Reserven, Pool-Größe, Software-Stand und Backend-Gewicht reparieren. Pfadlänge, die Schaltkreis-Bauzeiten des Tages, Relay-Überlastung oder die Guard-Rotation des Clients nicht. Die ehrliche Lesart: Ein erster, ungecachter Seitenaufruf, der Sekunden braucht, ist keine kaputte Seite - er bezahlt Descriptor-Lookup, Introduction und Rendezvous in voller Höhe - während stetige Anfragen auf einem warmen Schaltkreis nahe an der Eigenantwortzeit des Backends plus Transit bleiben sollten. Bleibt ein Dienst auch nach der ersten Seite langsam, hat der Betreiber vermutlich Spielraum. Wirkt er nur zu Mitternachtsspitzen langsam, hat das Netzwerk Schicht, nicht das Backend - das Muster ist in unseren früheren Feldnotizen zur Onion-Latenz-Varianz dokumentiert. Serverseitig sind die Gewinne real, aber begrenzt: tunen, was die torrc besitzt, das Origin leicht halten und nicht erwarten, dass der Pfad kürzer wird, als das Protokoll ihn macht.