[DARFT] Привязка сессии для повторного использования KV-cache

Резюме

Вывод направляется на псевдослучайный обслуживающий узел при каждом вызове, что справедливо для справедливости, но выбрасывает кэш KV/префиксов — для многоповоротного чата перерасчет общего префикса является доминирующей задержкой. Этот PR добавляет ограниченную, добровольную привязку сеансов для обоих участков маршрутизации, а также явную область совместного использования кэшированных блоков, поскольку концентрация трафика одного клиента на одном графическом процессоре без такового расширит существующий боковой канал синхронизации, а не закроет его.

• Управляли двумя прыжками, а не одним. Сеанс возвращается к тому же участнику (шлюзу) и тому же узлу внутри него (брокеру-участнику). При управлении только переходом 1 кэш остается холодным всякий раз, когда участник выбирает другой графический процессор.

• Пространство имен кэша, привязанное к аутентифицированному удостоверению. Идентификатор сеанса связи — HMAC (секрет процесса, строка условного депонирования учетных данных клиента) — фиксированный 64-шестнадцатеричный дайджест. Собственная строка клиента никогда не покидает шлюз, и угадывание строки другого клиента больше не достигает его кэшированных блоков.

• Предпочтение, а не бронирование. Средство выбора учитывает закрепленность только в том случае, если предпочтительный участник может обслуживать сейчас и запрос не устарел более 200 мс. Ноль одноразовых номеров не сжигается, и ни один запрос не ожидает от закрытого, регулируемого или простаивающего участника.

• Prompt_cache_key действительно работает. Документированный первичный ключ удалялся до того, как affinity прочитал его, поэтому активным был только пользователь — одно значение для всего клиента.

• Ограничено дважды. Обе карты привязки ограничены 50 000 записями с вытеснением, а оба поля-кандидата проверяются по типу и ограничиваются 512 байтами на границе шлюза.

• 66 новых тестов, каждый из которых проверен на наличие мутаций. Два независимых рецензента повторно сломали 21 и 12 охраняемых строк соответственно; всех поймали.

По умолчанию на обоих концах выключено — коммутатор шлюза и коммутатор каждого участника независимы, а при выключенном переключателе шлюза идентификатор сеанса вообще не определяется. ---

Проблема → Решение

1. Теплый тайник сбрасывается на каждом ходу.

Раньше. Шлюз привязывает каждый nonce к участнику как nonce mod group_size, а брокер участника передает каждый вывод его наименее загруженному узлу. Ни один из переходов не знает о сеансах, а кэш KV предназначен для каждого графического процессора, поэтому ход *n+1* диалога почти всегда повторно заполняет весь префикс из холодного состояния. После. Ключ сеанса, считанный из тела запроса (prompt_cache_key, резервный пользователь), направляет сеанс обратно к его последнему использовавшемуся участнику и, внутри этого участника, к его последнему использовавшемуся узлу mlnode для ограниченного окна.

2. Пространство имен кэша было получено из угадываемой строки.

Раньше. Пространство имен получено из собственного пользовательского значения клиента. Угадайте пользователя другого арендатора, и вы попадете в пространство имен его кэша, где сообщенное количество кэшированных токенов подскажет вам, какие префиксы являются резидентными — опубликованная атака по времени с использованием кэша подсказок (https://arxiv.org/abs/2502.07776) передала ключ. После. Шлюз получает идентификатор проводного сеанса в виде HMAC через условное депонирование, учетные данные носителя вызывающего абонента и строку клиента под секретом, полученным из crypto/rand при запуске и никогда не сохраняемым. Обслуживающий узел вычисляет пространство имен на основе своего собственного идентификатора условного депонирования и идентификатора этого сеанса, поэтому шлюз не может объединить два пространства имен условного депонирования. Эскроу разделяет арендаторов разных эскроу; учетные данные разделяют аутентифицированных клиентов внутри одного.

3. Прилипчивость сжигала одноразовые номера и ограничивала запросы

Раньше. Сходство было реализовано путем инвертирования набора исключений средства выбора — исключения каждого участника, кроме прикрепленного, — плюс тайм-аута удержания. Зафиксированный nonce, запрос которого отказался переместить, — это сжигание, а сжигание — это деньги, потраченные на условное депонирование, ни на что. После. Предпочтение попадает в сборщик как предпочтение. Три прохода: липкий удар, затем несвязанный, затем любой совместимый. Новый закрепленный запрос никогда не обгоняет несвязанный запрос, ожидавший превышения порога устаревания, а более узкая повторная попытка вообще никогда не обгоняется. Оба направления голодания покрываются тестами, которые терпят неудачу в коде префикса.

4. Документированный первичный ключ был мертв.

Раньше. Prompt_cache_key удаляется при предварительной проверке, а affinity считывает нормализованное тело — поэтому поле никогда не будет видно в рабочей среде. Работал только пользователь, что для приложения является одним значением для всего его трафика: липкость привязывала бы к одному хосту целый тенант. Юнит-тест пройден, потому что он тестировал экстрактор изолированно, а не путь поставки. После. Ключ извлекается из уже проанализированного документа *до* полосы — один поиск по карте, а не второй анализ тела, которое может занимать 10 МБ. Поле продолжает сниматься с тела провода, поскольку обслуживающий механизм его не учитывает. Регрессионный тест теперь управляет реальным конвейером нормализации.

5. Один переключатель не закрыл функцию, другой закрыл слишком сильно

Раньше. Коммутатор участника обнулил идентификатор сеанса *до* отметки пространства имен, и по умолчанию он отключен. В наиболее вероятной конфигурации поля (оператор условного депонирования включает сходство, участники запускают стандартную конфигурацию) привязка работала, хотя пространство имен ничего не было, оставляя оракул в рабочем состоянии, оставляя злоумышленнику только дополнительный шаг. После. Штамп пространства имен используется с любым непустым идентификатором сеанса; Переключение участника управляет только привязкой к множественному узлу, поскольку привязка изменяет собственное планирование графического процессора этого оператора, в то время как изоляция защищает клиента, который не участвует в выборе. Коммутатор шлюза остается настоящим мастером: если он выключен, идентификатор сеанса не выводится, поэтому нет ни перехода, ни штампа.

6. Пути повторной попытки прервали сеанс

Раньше. Путь получения-вызова и обе полезные нагрузки тайм-аута шлюза создавали полезную нагрузку своего хоста без идентификатора сеанса, поэтому при любом повторном выполнении приглашение жертвы попадало в общее пространство имен, возвращая в точности ту изоляцию, которую удалось получить при первой попытке. После. Каждый путь, который повторно отправляет приглашение, содержит это поле, и два литерала тайм-аута были свернуты в один конструктор, чтобы они не могли снова разойтись.

7. Ничего не наблюдалось

Раньше. Ни метрики, ни журнала. Оператор, включивший эту функцию, не смог ответить, делает ли она что-нибудь. После. Счетчики попаданий/выходов/промахов на обоих прыжках плюс индикатор карты привязки. О переходе 2 сообщается отдельно, поскольку переход 1 может работать идеально, пока участник запускает сеанс на другом графическом процессоре, а кеш в любом случае остается холодным. ---

Дизайн

session_id = hex(HMAC-SHA256(секрет процесса, escrow_id ‖ 0x00 ‖ учетные данные носителя ‖ 0x00 ‖ строка клиента))
namespace = sha256(escrow_id ‖ 0x00 ‖ session_id) // вычисляется обслуживающим узлом на основе его собственного идентификатора условного депонирования

Соединение 0x00 однозначно. Идентификаторы условного депонирования назначаются по цепочке и не содержат NUL, HTTP-сервер Go отклоняет NUL в значении заголовка, поэтому учетные данные не могут его содержать, а единственное поле, поддерживающее NUL, является последним — никакая граница не может смещаться. Секрет заключается в каждом процессе, а не сохраняется. Его нет в репозитории, образе или среде, поэтому токен не может быть повторно вычислен вне коробки; без этого HMAC был бы автономным оракулом для подбора ключей API. Цена состоит в том, что перезапуск шлюза делает каждую привязку недействительной, и следующий раунд становится холодным. Привязка запроса была получена, а не угадана. Доля «горячего удара» внутри привязки равна (N-1)/N, поэтому 32 покупает 97% против 90% при 10. Это не параметр безопасности: выборка проверки основывается на идентификаторе вывода и долях слотов, при этом исполнитель удаляется из знаменателя, удерживая ожидаемые проверки на вывод по ставке условного депонирования (10 % по умолчанию) независимо от того, кто выполнил. Концентрация тоже ничего не приносит — покупатель платит собственные средства за выполненную работу, а вес зависит от PoC, а не от объема вывода. Что ограничивает N, так это степень детализации ключа: при использовании Prompt_cache_key ключ — это один разговор, а высокая граница только увеличивает дисперсию, но для пользователя один арендатор — это один ключ. Для второго случая выбрано 32. Оба срока жизни привязки являются круглыми числами, и об этом говорится в PR. Привязка полезна только до тех пор, пока обслуживающий механизм все еще удерживает блоки, что зависит от емкости кэша при поступлении токена на этот графический процессор — неизвестно заранее. В предложении документируется измерение, которое решает проблему: воспроизвести один префикс с растущим интервалом простоя и найти, где сообщаемое количество кэшированных токенов падает до нуля. ---

Валидация

Методология

• Каждый новый тест проверялся на мутацию его автором: разрывайте точную защищенную строку, подтверждайте неудачу, возвращайтесь.

• Два независимых рецензента проверили всю ветку на предмет статического дифференциала и не приняли на веру заявления о покрытии — они повторно взломали 21 и 12 защищенных строк соответственно. Все 33 человека были пойманы в ходе запланированного теста с предполагаемым сообщением.

• Проверка мертвого кода сравнила неиспользованные результаты с базовым коммитом в отдельном рабочем дереве: наборы идентичны, поэтому ветка не добавила ни одного. ineffassign/unparam также не дает новых результатов.

Что было проверено

| Недвижимость | Как | |---|---| | Подписанная полезная нагрузка без изменений | Штамп пространства имен, применяемый после проверки полезных данных, внутри закрытия выполнения; сохраненное и канонизированное приглашение является оригинальным | | Валидатор воспроизводит без пространства имен | Специальный тест; мутация, добавляющая одну, не получается | | Пространство имен не может пересекать условное депонирование | Обслуживающий узел использует свой собственный идентификатор условного депонирования, а не идентификатор перевода; удаление мутации провалило два теста | | В журналах, метках метрик, заголовках или ответах нет клиентской строки или токена | Grep каждого нетестового использования плюс проверка рецензента; метки — только devshard_id/decision/model | | Клиент не может внедрить собственное пространство имен | Неизвестные поля верхнего уровня отклоняются на шлюзе | | Оба направления голодания | Воспроизведен префикс (0 подан против 1731 за 2 с), затем закрыт | | Никаких новых рас | -гонка зеленого цвета на путях отслеживания, выбора и брокера |

Что не было измерено

Никаких показателей попаданий в кеш или задержек. По умолчанию эта функция отключена и не работает при рабочем трафике; утверждать, что здесь есть ускорение, значит изобретать его. Наблюдаемость, добавленная в этот PR, является тем, что решает проблему, и в предложении указаны конкретные измерения для значений по умолчанию за весь срок службы. ---

Конфигурация

| Параметр | По умолчанию | Ручка, если хотите… | |---|---|---| | DEVSHARD_AFFINITY_ENABLED | выключен | включите всю функцию для этого шлюза; если он отключен, идентификатор сеанса вообще не выводится | | DEVSHARD_AFFINITY_MAX_REQUESTS | 32 | торговля «горячей» долей в зависимости от того, как долго один ключ может занимать хост | | DEVSHARD_AFFINITY_TTL_MS | 120000 | сопоставить измеренную резидентность кэша на ваших графических процессорах | | DEVSHARD_AFFINITY_MAX_ENTRIES | 50000 | ограничить карту привязки (~ 14 МБ на каждое условное депонирование при заполнении) | | DAPI_MLNODE_AFFINITY_ENABLED | выключен | пусть этот участник снова направляет сеансы на тот же графический процессор; штамп пространства имен от этого не зависит | | DAPI_MLNODE_AFFINITY_MAX_REQUESTS | 64 | как указано выше, переход 2 | | DAPI_MLNODE_AFFINITY_TTL_MS | 600000 | как указано выше, переход 2 | | DAPI_MLNODE_AFFINITY_MAX_ENTRIES | 50000 | как указано выше, переход 2 | DAPI_MLNODE_AFFINITY_ENABLED читается двумя процессами на стороне участника — devshardd и брокером — и оба должны быть установлены для того, чтобы произошла липкость hop-2. Все три переключателя теперь анализируются одинаково, поэтому значение, содержащее пробелы из файла компоновки, больше не включает одну половину, а не другую. ---

Наблюдаемость

• devshard_gateway_affinity_decision_total{devshard_id,decision} — попадание, когда основной объект приземлился на прикрепленном участнике, сдача, когда предпочтение существовало, но сборщик обслуживал кого-то другого, промах, когда предпочтений не было. Тихий, когда функция выключена.

• devshard_gateway_affinity_bindings{devshard_id} — датчик карты привязки hop-1, для наблюдения за давлением ограничения.

• decentrized_api_mlnode_affinity_decision_total{decision,model} — эквивалент прыжка-2.

• Никакие значения «без ограничений условного депонирования», «сеанса» или «nonce» не отображаются ни в одной метке.

• Два пути, закрывающихся при сбое, которые молчали, теперь регистрируются один раз для каждого процесса: идентификатор сеанса, выходящий за границу участника, и токен, который перерос формат проводной связи.

---

Внедрение

По умолчанию без изменений. Оба переключателя поставляются выключенными. Без ключа клиента ничего нигде не происходит — ни идентификатора сеанса, ни закрепления, ни отметки пространства имен — что является сегодняшним поведением побайтно. Две независимые подписки. Оператор шлюза включает переход 1; каждый участник включает переход 2 для своих собственных графических процессоров. Включение только шлюза по-прежнему обеспечивает кэширование пространства имен и липкость hop-1; включение только участника ничего не дает, поскольку идентификатор сеанса не поступает. Однострочный откат. Снимите настройку DEVSHARD_AFFINITY_ENABLED и перезапустите шлюз. Привязки участников устаревают самостоятельно в течение 10 минут; ни одно государство нигде не сохраняется. Одно изменение, видимое клиенту, даже когда оно выключено: нестроковый запрос Prompt_cache_key размером более 512 байт теперь возвращает 400 вместо того, чтобы автоматически удаляться — то же самое, что пользователь уже получает. ---

Известные пределы, указанные в предложении

• Режим открытого доступа не может изолировать клиентов одного эскроу. Без каких-либо учетных данных два анонимных вызывающих абонента, отправляющих одну и ту же строку, являются одним и тем же клиентом шлюза. Для изоляции требуется доступ к api_key с одним ключом для каждого клиента.

• Повторы проверки не имеют пространства имен, поэтому префикс выборочного вывода попадает в общее пространство имен на графическом процессоре валидатора. Изоляция является вероятностной с частотой выборки для проверки. Пространство имен по этому пути поместило бы поле, зависящее от версии обслуживающего механизма, в путь консенсуса для условного депонирования, которые никогда не давали согласия.

• Идентификатор сеанса стабилен в течение всего времени существования процесса шлюза и идентичен для каждого участника, который видит запрос, поэтому участник может связывать запросы одного конечного пользователя между моделями. Чтобы удалить это, потребуется деривация для каждого пункта назначения, которую в настоящее время блокирует путь тайм-аута широковещательной передачи.

---

План испытаний

[x] go build ./... зеленый в обоих модулях

• [x] go test -count=1 зеленый: devshard/{cmd/devshardctl,cmd/devshardd/...,host,user}, decentrized-api/{broker,nodemanager,observability}

• [x] перейдите к тестированию - гонка зеленого цвета на путях отслеживания сходства, средства выбора сеанса и брокера.

[x] 66 новых тестов, каждый из которых проверен на мутации; 33 повторно проверено независимо двумя рецензентами

[x] unused/ineffassign/unparam отличаются от базового коммита — новых результатов нет

[x] gofmt очищает каждый файл, которого касается эта ветка

• [ ] bufgenerate — здесь не запускать: этот PR редактирует комментарий в nodemanager.proto и не содержит номеров полей, а сгенерированный файл сопоставляется вручную. Перед слиянием требуется настоящая регенерация.

[ ] /run-интеграция

+1 PR-поддержка и крутые сессии. Предложение:

Хэш HMAC-sha256 слишком медленный/тяжелый/ограниченный (без аппаратного ускорения)

предложение заменить его более быстрым хешем blake3 - дает ускорение в 5-15 раз, blake2b - в 3-8 раз github.com/zeebo/blake3 или lukechampine.com/blake3 - код go. или siphash (hash/mapsah) также хорошо ускоряет сеансы в 10-20 раз. тот же хороший математический разброс, <ins> более быстрый хеш, что важно для быстрой обработки сеансов </ins>.

улучшение2

session_id = hex(HMAC-SHA256(secret, escrow ‖ 0x00 ‖ cred ‖ 0x00 ‖ client)) замените на session_id = hex(BLAKE3.KeyedHash(secret[:32], escrow ‖ 0x00 ‖ cred ‖ 0x00 ‖ client)) .

• Ключ BLAKE3 — это именно PRF/MAC, оболочка HMAC не требуется.

• Секрет по-прежнему составляет 32 байта (как и сейчас).

• Выходные данные можно оставить размером 32 байта (64 шестнадцатеричных) или сократить до 16–24 байт, если размер провода имеет решающее значение.

• Производительность на коротких входах обычно в несколько раз выше, чем у SHA-256.

• Улучшение3.

Это следующий логический уровень: мягкая привязка с учетом географического положения и задержки + группы близких узлов + (потенциально) общий пул KV внутри участника. Его можно наложить поверх текущего дизайна, не нарушая его.

• Вместо чистой классической модели закрепленных сеансов с привязкой по последнему использованному сеансу расширьте эту идею, включив <ins>маршрутизацию на основе географической/сетевой близости/задержки </ins>, назначение узлов группам и учет их рабочей нагрузки/скорости ответа. (Это предполагает добавление маркировки и группировки узлов на основе оборудования.)

Предложение по улучшению: ввести концепцию «группы соответствия» — набора участников, между которыми физически не используется общий кэш KV, но чья задержка для клиента сопоставима (это можно сделать топологически по региону/AZ или измеренному RTT). Часть прохода уже существует (закрепленное попадание → несвязанный → любой совместимый) — добавьте промежуточный проход «любой член группы сродства предпочтительного узла» перед «любым совместимым». Тогда, если конкретный узел недоступен, вы не летите в случайную точку сети, а остаетесь рядом. Это меняет только сборщик (брокер) и не требует изменения логики HMAC/пространства имен — они остаются для каждого узла, что уже правильно с точки зрения модели безопасности PR.