Wydajność onion service rozstrzyga się po stronie serwera: dokąd uciekają milisekundy i co operator naprawdę może ustawić
Gdy onion-site chodzi wolno, odruch każe winić sieć Tor. To prawda tylko do pewnego stopnia. Ukryty serwis nigdy nie rozmawia z odwiedzającymi bezpośrednio, a każde połączenie składa się z węzłów wybranych przez obie strony; jednak realna część oczekiwania powstaje na samej maszynie serwisu - w tym, jak Tor pielęgnuje instalację przed backendem WWW. Wiedza o tym, która połowa za co odpowiada, decyduje, czy strojenie pomoże, czy tylko przeniesie winę.
Dokąd uciekają milisekundy
Przegląd protokołu od Tor Project liczy kompletne połączenie onion na sześć węzłów: trzy wybiera klient, trzy serwis, spinane w punkcie rendezvous, który potem "po prostu przekazuje (szyfrowane end-to-end) wiadomości od klienta do serwisu i odwrotnie" (Tor Project, protokół serwisów onion). Zanim ten obwód powstanie, kilka pełnych rund już się odbywa: klient pobiera podpisany deskryptor serwisu z rozproszonej tablicy mieszającej, buduje trasę do jednego z punktów introdukcji i uzgadnia rendezvous. To nie jest czas backendu, a ląduje w całości na stoperze odwiedzającego. Strona serwisu dźwiga też koszt stały, którego nie płaci żaden klient. Punkty introdukcji trzymają długoterminowe, zanonimizowane obwody od serwisu, a podręcznik Tora ustawia domyślną pulę na trzy punkty introdukcji, rozszerzalną do dwudziestu dla serwisu v3. Ponieważ te węzły są jedynym adresem serwisu, nie mogą po cichu znikać: gdy jeden pada, serwis musi zbudować kolejny obwód o trzech przeskokach i ponownie opublikować podpisany deskryptor - tę pracę widać w chłodniejszych, wolniejszych pierwszych wejściach.Co operator naprawdę steruje
Tor wystawia krótką listę pokręteł, węższą niż chce folklor wydajnościowy:- Zapas kryptografii. Handshake'y, które rodzą introdukcje i rendezvous, rozszyfrowuje pula robotów kryptograficznych; podręcznik opisuje NumCPUs jako "ile procesów naraz używać do rozszyfrowywania onionskins i innych operacji dających się zrównoleglić". Serwis głodny CPU wydaje się wolny dokładnie tam, gdzie operator może naprawić.
- Rozmiar puli introdukcji. HiddenServiceNumIntroductionPoints domyślnie trzyma trzy; więcej punktów rozkłada introdukcje na więcej węzłów kosztem większej liczby stałych obwodów.
- Świeżość obwodów. MaxCircuitDirtiness to domyślnie dziesięć minut, a podręcznik dopowiada, że w ukrytych serwisach wiek liczy się od ostatniego użycia obwodu. Podniesienie ogranicza przebudowy; obniżenie wymienia więcej budowań na świeższe trasy.
- Aktualność oprogramowania. Kontrola przeciążenia przyszła z Torem 0.4.7 w 2022 roku, a Tor Project mówił wprost: "użytkownicy Tora 0.4.7 i nowsi zobaczą szybsze działanie przy wyjściach i onion service'ach zaktualizowanych do 0.4.7" - serwis na starszej wersji zamyka każdego odwiedzającego w przestarzałej kontroli przepływu (blog Tor Project).
Pokusa pojedynczego przeskoku
Najstarszy spór wydajnościowy w tym kącie Tora brzmi: czy serwis potrzebuje w ogóle trzech przeskoków ochrony. Proposal 260, napisany w 2015 przez zespół z Rogerem Dingledinem i Paulem Syversonem, wdrożony w Torze 0.2.9.3-alpha, opisuje "rendezvous single onion services", które "wymieniają prywatność lokalizacji po stronie serwisu na lepszą wydajność, niezawodność i skalowalność": obwody o jednym przeskoku do punktów introdukcji i rendezvous oraz trasę skróconą do "4 zamiast 6" węzłów. Przełącznik żyje do dziś: HiddenServiceSingleHopMode jest udokumentowany jako eksperymentalny i nieanonimowy; czyni serwer "łatwo namierzalnym", podczas gdy "klienci pozostają anonimowi". Wymiana bez owijania. Single onion zachowuje adres .onion i anonimowość odwiedzających, ale oddaje ukrywanie lokalizacji operatora - a autorzy proposalu przestrzegali, że każdy dodatkowy "rodzaj" serwisu onion "rozbija zbiór anonimowości". Dlatego design domyślny przetrwał: pojedynczy przeskok zostaje narzędziem opt-in dla operatorów, którzy akceptują ekspozycję - osądem, który Tor świadomie zostawia poza protokołem.Dlaczego duże serwisy trzymają dostrojone backendy
Długowieczne serwisy onion - wyszukiwarki, mirrory, katalogi - zbiegają do tej samej formy: cienkie frontendy na Torze, celowo statyczne albo cache'ujące backendy, obciążenie rozsmarowane po instancjach. Proposal 260 wprost zaznacza, że rendezvous single onion service "może rozkładać obciążenie na wiele rendezvous backendów". Nic z tego nie skraca trasy; minimalizuje jedyny segment należący do operatora, by przeprawa przez sześć węzłów została jedyną zauważalną czekanką. Tor Metrics mierzy ruch onion, ekstrapolując ze statystyk węzłów działających jako punkty rendezvous - właśnie ta warstwa niesie widoczny ruch (Tor Metrics).Co da się naprawić, a co nie
"Ponieważ ścieżki serwisów onion są ponad dwukrotnie dłuższe niż ścieżki wyjściowe (a więc mają ponad dwukrotność opóźnienia obwodu), przepustowość onion service zawsze będzie mniejsza niż połowa przepustowości wyjścia" (Proposal 324).Operator może naprawić zapas kryptografii, rozmiar puli, wersję oprogramowania i ciężar backendu. Nie może naprawić długości trasy, czasów budowania obwodów danego dnia, przeciążenia przekaźników ani rotacji guardów u klienta. Uczciwa lektura: pierwsze, niebuforowane wejście trwające sekundy to nie zepsuty serwis - to deskryptor, introdukcja i rendezvous opłacone w całości - a zapytania po ciepłym obwodzie powinny siedzieć blisko własnego czasu odpowiedzi backendu plus tranzytu. Jeśli serwis pozostaje wolny i po pierwszej stronie, operator ma najpewniej pole do działania. Jeśli wydaje się wolny tylko przy nocnych pikach, dyżur pełni sieć, nie backend - wzorzec opisany w naszych wcześniejszych notatkach terenowych o zmienności opóźnień na onion. Po stronie serwera zyski są realne, lecz ograniczone: dostroj to, co ma torrc, trzymaj origin lekko i nie oczekuj trasy krótszej, niż robi ją protokół.