Производительность 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 лёгким и не ждите, что маршрут окажется короче, чем его делает протокол.