Продуктивність onion-сервісу вирішується на боці сервера: куди зникають мілісекунди і що оператор справді може налаштувати
Коли onion-сайт гальмує, рефлекс - звинувачувати мережу Tor. Це справедливо лише частково. Прихований сервіс ніколи не спілкується з відвідувачами напряму, і кожне з'єднання збирається з вузлів, обраних обома сторонами; проте помітна частка очікування твориться на самій машині сервісу - в тому, як Tor доглядає комунікації перед веб-бекендом. Розуміння того, яка половина за що відповідає, вирішує, допоможе тюнінг чи лише перерозподілить провину.
Куди зникають мілісекунди
Огляд протоколу від Tor Project рахує завершене onion-з'єднання у шести вузлах: три обирає клієнт, три - сервіс, з'єднуючись у точці рандеву, яка далі «просто пересилає (наскрізно зашифровані) повідомлення від клієнта до сервісу і навпаки» (Tor Project, протокол onion-сервісів). Доки те коло не існує, кілька повних кіл уже витрачено: клієнт отримує підписаний дескриптор сервісу з розподіленої хеш-таблиці, будує маршрут до однієї з точок введення і домовляється про рандеву. Це не час бекенда, але повністю лягає на секундомір відвідувача. На боці сервісу є і постійні витрати, яких не має клієнт. Точки введення тримають довговічні анонімізовані кола від сервісу, а підручник Tor задає типовий пул із трьох точок введення з розширенням до двадцяти для v3. Ці вузли - єдина адреса сервісу, тож вони не можуть тихо зникати: коли один відмовляє, сервіс будує нове тристрибкове коло і заново публікує підписаний дескриптор - роботу, що видно у холодніших, повільніших перших завантаженнях.Чим оператор насправді керує
Tor відкриває короткий список налаштувань - вужчий, ніж обіцяє фольклор про продуктивність:- Запас криптографії. Гендшейки, які породжують введення та рандеву, розшифровує пул крипто-воркерів; підручник описує NumCPUs як «скільки процесів одночасно використовувати для розшифровки onionskins та інших паралелізованих операцій». Сервіс, що задихається за CPU, гальмує саме там, де оператор може полагодити.
- Розмір пулу точок введення. HiddenServiceNumIntroductionPoints типово дорівнює трьом; більше точок розподіляють введення між більшою кількістю вузлів ціною додаткових постійних кіл.
- Свіжість кіл. MaxCircuitDirtiness типово десять хвилин, і підручник уточнює: для прихованих сервісів вік рахується від останнього використання кола. Збільшення скорочує перебудови; зменшення міняє більше збірок на свіжіші маршрути.
- Актуальність програм. Керування перевантаженням прийшло з Tor 0.4.7 у 2022 році, і Tor Project сказав прямо: «користувачі Tor 0.4.7 і новіші побачать швидшу роботу з вихідними вузлами й onion-сервісами, оновленими до 0.4.7» - сервіс на старішій версії зачиняє кожного відвідувача в застарілому керуванні потоком (блог Tor Project).
Спокуса одного стрибка
Найдавніший спір про продуктивність у цьому закутку Tor - чи потрібні сервісу три стрибки захисту. Proposal 260, написаний 2015 року групою за участі Роджера Дінгледіна і Пола Сіверсона та втілений у Tor 0.2.9.3-alpha, описує «rendezvous single onion services», які «міняють прихованість розташування на боці сервісу на кращу продуктивність, надійність і масштабованість»: кола в один стрибок до точок введення і рандеву та маршрут, укорочений до «4 замість 6» вузлів. Перемикач живий досі: HiddenServiceSingleHopMode позначений як експериментальний і неанонімний - він робить сервер «легко віднайдуваним», тоді як «клієнти лишаються анонімними». Обмін без прикрас. Single onion зберігає адресу .onion і анонімність відвідувачів, але здає приховування розташування самого оператора - а автори proposal попереджали, що кожен додатковий «сорт» onion-сервісів «ділить множину анонімності». Тому базовий дизайн і вижив: один стрибок лишається опційним інструментом для операторів, готових прийняти викриття, - рішенням, яке Tor свідомо залишає поза протоколом.Чому великі проєкти тримають налаштовані бекенди
Довгоживучі onion-проєкти - пошуковики, дзеркала, каталоги - сходяться до однієї форми: тонкі фронтенди на Tor, навмисно статичні чи кешувальні бекенди, навантаження, розмазане по інстансах. Proposal 260 навіть відзначає, що rendezvous single onion service «може балансувати навантаження між кількома rendezvous-бекендами». Ніщо з цього не вкорочує маршрут; це мінімізує єдиний сегмент, яким володіє оператор, щоб подорож через шість вузлів лишилася єдиною помітною затримкою. Tor Metrics вимірює трафік onion, екстраполюючи з даних вузлів, що працюють точками рандеву, - саме цей шар несе видиме навантаження (Tor Metrics).Що можна полагодити, а що ні
«Оскільки шляхи onion-сервісів понад удвічі довші за вихідні шляхи (а отже, понад удвічі більша затримка кола), пропускна здатність onion-сервісу завжди буде меншою за половину пропускної здатності вихідного вузла» (Proposal 324).Оператор може полагодити запас криптографії, розмір пулу, версію програм і вагу бекенда. Не може - довжину маршруту, час побудови кіл у той конкретний день, перевантаження релеїв і зміну guard-вузлів у клієнта. Чесне прочитання: перше некешоване завантаження за кілька секунд - не зламаний сайт, це дескриптор, введення і рандеву, сплачені повністю, а запити по теплому колу мають триматися близько до власного часу відповіді бекенда плюс транзиту. Якщо сервіс повільний і після першої сторінки, у оператора, найімовірніше, є простір для дії. Якщо він гальмує лише в нічні піки - зміну несе мережа, а не бекенд; цей узор описано в наших польових нотатках про мінливість затримки на onion. На боці сервера виграші реальні, але обмежені: налаштовуйте те, чим володіє torrc, тримайте origin легким і не сподівайтеся, що маршрут буде коротшим, ніж його робить протокол.