La performance d'un onion service se joue côté serveur : où passent les millisecondes et ce que l'opérateur peut vraiment régler
Quand un site onion paraît lent, le réflexe est d'accuser le réseau Tor. Ce n'est vrai qu'en partie. Un service caché ne parle jamais directement aux visiteurs, et chaque connexion est assemblée avec des relais choisis par les deux parties ; mais une part réelle de l'attente se fabrique sur la machine du service elle-même, dans la façon dont Tor entretient la tuyauterie devant le backend web. Savoir quelle moitié fait quoi décide si le réglage aide ou se contente de déplacer la faute.
Où passent les millisecondes
La présentation du protocole du Projet Tor compte une connexion onion complète en six relais : trois choisis par le client, trois par le service, épissurés en un point de rendez-vous qui « relaie simplement les messages chiffrés de bout en bout du client vers le service et inversement » (Projet Tor, protocole des services onion). Avant que ce circuit existe, plusieurs allers-retours sont déjà dépensés : le client récupère le descripteur signé du service dans une table de hachage distribuée, construit une route vers l'un de ses points d'introduction et négocie le rendez-vous. Rien de tout cela n'est du temps de backend, mais tout atterrit sur le chronomètre du visiteur. Le côté service supporte en plus un coût permanent qu'aucun client ne paie. Les points d'introduction conservent des circuits anonymisés de longue durée depuis le service, et le manuel Tor fixe le pool par défaut à trois points d'introduction, extensible à vingt pour un service v3. Comme ces relais constituent la seule adresse du service, ils ne peuvent pas disparaître en silence : si l'un tombe, le service doit construire un autre circuit à trois sauts et republier son descripteur signé, un travail qui se voit dans des premières visites plus froides et plus lentes.Ce qu'un opérateur contrôle vraiment
Tor expose une courte liste de réglages, plus étroite que ne le laisse croire le folklore de la performance :- La marge cryptographique. Les handshakes générés par les introductions et le rendez-vous sont déchiffrés par un pool de workers crypto ; le manuel décrit NumCPUs comme « le nombre de processus utilisés simultanément pour déchiffrer les onionskins et autres opérations parallélisables ». Un service affamé de CPU paraît lent exactement là où l'opérateur peut agir.
- La taille du pool d'introduction. HiddenServiceNumIntroductionPoints vaut trois par défaut ; davantage de points d'introduction répartissent les introductions sur plus de relais, au prix de circuits permanents supplémentaires.
- La fraîcheur des circuits. MaxCircuitDirtiness vaut dix minutes par défaut, et le manuel précise que pour les services cachés, l'âge se compte depuis la dernière utilisation du circuit. L'augmenter réduit les reconstructions ; la baisser échange plus de constructions contre des routes plus fraîches.
- La fraîcheur logicielle. Le contrôle de congestion est arrivé avec Tor 0.4.7 en 2022, et le Projet Tor a été cash : « les utilisateurs de Tor 0.4.7 et plus constateront de meilleures performances en utilisant des sorties ou des onion services passés à 0.4.7 » - un service sur une version plus ancienne bride tous ses visiteurs au contrôle de flux hérité (blog du Projet Tor).
La tentation du saut unique
Le plus vieux débat de performance de ce coin de Tor : le service a-t-il vraiment besoin de trois sauts de protection ? La Proposition 260, rédigée en 2015 par un groupe incluant Roger Dingledine et Paul Syverson et implémentée dans Tor 0.2.9.3-alpha, décrit des « rendezvous single onion services » qui « échangent la confidentialité de localisation côté service contre de meilleures performances, fiabilité et évolutivité », avec des circuits à un saut vers les points d'introduction et de rendez-vous et une route raccourcie à « 4 plutôt que 6 » relais. L'interrupteur existe toujours : HiddenServiceSingleHopMode est documenté comme expérimental et non anonyme ; il rend le serveur « facilement localisable » tandis que « les clients restent anonymes ». L'échange est sans fards. Un single onion garde son adresse .onion et l'anonymat de ses visiteurs mais renonce à masquer la localisation de l'opérateur - et les auteurs de la proposition ont averti que chaque saveur supplémentaire d'onion service « scinde l'ensemble d'anonymat ». Le design par défaut survit donc : le saut unique reste un outil optionnel pour les opérateurs qui acceptent l'exposition, un jugement que Tor laisse délibérément hors du protocole.Pourquoi les gros sites règlent leurs backends
Les propriétés onion qui durent - moteurs de recherche, miroirs, annuaires - convergent vers la même forme : des frontaux Tor fins, des backends volontairement statiques ou cachés, et une charge répartie entre instances. La Proposition 260 note même qu'un rendezvous single onion service « peut répartir la charge sur plusieurs rendezvous backends ». Rien de tout cela ne raccourcit la route ; cela réduit l'unique segment que possède l'opérateur, pour que le trajet à six relais reste la seule attente notable. Tor Metrics mesure le trafic onion en extrapolant depuis des statistiques de relais agissant comme points de rendez-vous - cette couche porte littéralement la charge visible (Tor Metrics).Ce qui est réparable et ce qui ne l'est pas
« Comme les chemins des services onion sont plus de deux fois plus longs que les chemins de sortie (et donc plus de deux fois la latence de circuit), le débit d'un onion service sera toujours inférieur à la moitié du débit de sortie. » (Proposition 324)Un opérateur peut réparer la marge cryptographique, la taille du pool, la version logicielle et le poids du backend. Il ne peut pas réparer la longueur de la route, les temps de construction du jour, la congestion des relais ni la rotation de guards du client. Lecture honnête : une première page non cachée qui prend des secondes n'est pas un site cassé - c'est le descripteur, l'introduction et le rendez-vous payés en entier - tandis que les requêtes sur un circuit chaud devraient rester proches du temps de réponse du backend plus le transit. Si un service reste lent après la première page, l'opérateur a probablement de la marge. S'il n'est lent qu'aux pics de minuit, c'est le tour du réseau, pas du backend - le motif documenté dans nos notes de terrain sur la variance de latence onion. Côté serveur, les gains sont réels mais bornés : réglez ce que torrc possède, gardez l'origine légère, et n'attendez pas une route plus courte que celle que le protocole impose.