Le prestazioni di un onion service si decidono lato server: dove finiscono i millisecondi e cosa può regolare davvero un operatore
Quando un sito onion sembra lento, il riflesso è dare la colpa alla rete Tor. È giusto solo fino a un certo punto. Un servizio nascosto non parla mai direttamente con i visitatori, e ogni connessione è assemblata con relè scelti da entrambe le parti; ma una fetta reale dell'attesa si produce sulla macchina del servizio, nel modo in cui Tor gestisce le tubature davanti al backend web. Sapere quale metà fa cosa decide se la regolazione aiuta o si limita a spostare la colpa.
Dove finiscono i millisecondi
La panoramica del protocollo del Tor Project conta una connessione onion completa in sei relè: tre scelti dal client, tre dal servizio, uniti in un punto di rendezvous che poi "semplicemente inoltra i messaggi cifrati end-to-end dal client al servizio e viceversa" (Tor Project, protocollo dei servizi onion). Prima che quel circuito esista, diversi viaggi di andata e ritorno sono già spesi: il client scarica il descrittore firmato del servizio da una tabella hash distribuita, costruisce un percorso verso uno dei suoi punti di introduzione e negozia il rendezvous. Nulla di ciò è tempo di backend, eppure tutto finisce sul cronometro del visitatore. Il lato servizio porta anche un costo permanente che nessun client paga. I punti di introduzione mantengono circuiti anonimizzati di lunga durata dal servizio, e il manuale Tor fissa il pool predefinito a tre punti di introduzione, estendibile a venti per un servizio v3. Poiché quei relè sono l'unico indirizzo del servizio, non possono sparire in silenzio: se uno cade, il servizio deve costruire un altro circuito a tre hop e ripubblicare il suo descrittore firmato - lavoro che si vede in prime visite più fredde e lente.Cosa controlla davvero un operatore
Tor espone una lista corta di manopole, più stretta di quanto il folklore sulle prestazioni ammetta:- Margine crittografico. Gli handshake generati da introduzioni e rendezvous vengono decifrati da un pool di worker crittografici; il manuale descrive NumCPUs come "quanti processi usare contemporaneamente per decifrare onionskins e altre operazioni parallelizzabili". Un servizio affamato di CPU risulta lento esattamente dove un operatore può intervenire.
- Dimensione del pool di introduzione. HiddenServiceNumIntroductionPoints è su tre per impostazione predefinita; più punti di introduzione distribuiscono le introduzioni su più relè, al prezzo di più circuiti permanenti.
- Freschezza dei circuiti. MaxCircuitDirtiness è a dieci minuti di default, e il manuale nota che nei servizi nascosti l'età si conta dall'ultima volta che il circuito ha portato traffico. Alzarla riduce le ricostruzioni; abbassarla scambia più build per percorsi più freschi.
- Software aggiornato. Il controllo della congestione è arrivato con Tor 0.4.7 nel 2022, e il Tor Project è stato netto: "gli utenti di Tor 0.4.7 e successive vedranno prestazioni migliori usando exit o onion service aggiornati a 0.4.7" - un servizio su una versione più vecchia chiude tutti i visitatori nel controllo di flusso legacy (blog del Tor Project).
La tentazione del salto unico
Il dibattito sulle prestazioni più antico di questo angolo di Tor è se il servizio abbia davvero bisogno di tre hop di protezione. La Proposal 260, redatta nel 2015 da un gruppo che include Roger Dingledine e Paul Syverson e implementata in Tor 0.2.9.3-alpha, descrive "rendezvous single onion services" che "scambiano la privacy di posizione lato servizio con prestazioni, affidabilità e scalabilità migliori", con circuiti a un hop verso i punti di introduzione e di rendezvous e un percorso accorciato a "4 anziché 6" relè. L'interruttore esiste ancora: HiddenServiceSingleHopMode è documentato come sperimentale e non anonimo; rende il server "facilmente localizzabile" mentre "i client restano anonimi". Lo scambio è senza sconti. Un single onion conserva l'indirizzo .onion e l'anonimato dei visitatori ma rinuncia a nascondere la posizione dell'operatore - e gli autori della proposal avvertivano che ogni sapore aggiuntivo di onion service "divide l'insieme di anonimato". Per questo il design predefinito sopravvive: il salto unico resta uno strumento opt-in per operatori che accettano l'esposizione, un giudizio che Tor lascia deliberatamente fuori dal protocollo.Perché le grandi proprietà usano backend tarati
Le proprietà onion di lunga vita - motori di ricerca, mirror, directory - convergono sulla stessa forma: frontend Tor sottili, backend volutamente statici o in cache, carico distribuito tra istanze. La Proposal 260 nota perfino che un rendezvous single onion service "può bilanciare il carico su più rendezvous backend". Nulla di questo accorcia la rotta; minimizza l'unico segmento di proprietà dell'operatore, cosicché il viaggio a sei relè resti l'unica attesa rilevante. Tor Metrics misura il traffico onion estrapolando da statistiche dei relè che agiscono da punti di rendezvous - quel livello è letteralmente dove vive il carico visibile (Tor Metrics).Cosa si può riparare e cosa no
"Poiché i percorsi dei servizi onion sono più del doppio della lunghezza dei percorsi exit (e quindi più del doppio della latenza di circuito), la capacità di un onion service sarà sempre inferiore alla metà di quella di un exit" (Proposal 324).Un operatore può riparare margine crittografico, dimensione del pool, versione del software e peso del backend. Non può riparare la lunghezza della rotta, i tempi di costruzione del circuito del giorno, la congestione dei relé né la rotazione dei guard del client. Lettura onesta: un primo caricamento senza cache che richiede secondi non è un sito rotto - è descrittore, introduzione e rendezvous pagati per intero - mentre le richieste su un circuito caldo devono stare vicine al tempo di risposta del backend più il transito. Se un servizio resta lento dopo la prima pagina, l'operatore probabilmente ha margine per agire. Se sembra lento solo nei picchi di mezzanotte, il turno è della rete, non del backend - il pattern documentato nelle nostre note sul campo sulla varianza di latenza onion. Lato server i guadagni sono reali ma limitati: regolate ciò che possiede il torrc, tenete l'origine leggera e smettete di aspettarvi una rotta più corta di quella che il protocollo impone.