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

Механизм: таблица слотов, а не журнал

Самая простая реализация связывает подписку с не более чем тремя активными записями сессии. Каждая допущенная сессия занимает один слот, и слот освобождается, когда служба решает, что эта сессия завершена. Записи нужен достаточно конкретный идентификатор, чтобы освобождение одного подключения не освобождало слот другого; поэтому идентификатор сессии важнее имени учётной записи.

Занятость и история — разные структуры данных. Занятость отвечает на вопрос «да или нет» о настоящем, и её можно отбросить в тот момент, когда сессия заканчивается. История — это поток событий только на добавление, и он сохраняется потому, что кто-то решил его хранить. Служба может иметь одно, оба или ни одного.

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

What is storedWhy it exists
Active session slotsTo admit or refuse the next connection
Session event logTo investigate or bill later
Monitoring seriesTo watch capacity and error rates
Backup copiesTo restore any of the above

Почему живой модели всё равно нужна координация

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

Перезапущенный сервер должен согласовать своё состояние, а нескольким шлюзам, обслуживающим одну учётную запись, нужно общее решение. Иначе учётная запись может превысить квоту, подключаясь к разным точкам. Общее или восстановимое состояние решает это, и общее состояние — требование проектирования, а не доказательство слежки.

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

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

Куда состояние уходит потом

Вопрос конфиденциальности не в том, умеет ли сервер считать. Спросите, что происходит с завершённой сессией: запись удаляется или становится событием в серии мониторинга? Затем спросите, какие другие компоненты видели то же событие, потому что журналы аутентификации, записи учёта и резервные копии могут каждая хранить копию, которую путь исполнения отбросил.

Учёт RADIUS — самый ясный пример. Пара Start и Stop существует для поддержки биллинга и управления сессиями, и она создаёт запись о подключении независимо от того, запрашивает ли её кто-нибудь когда-нибудь как историю. Поэтому служба, которая обеспечивает лимиты через учёт, по построению хранит больше, чем таблица слотов.

У удаления тоже есть форма. Запись, удалённая из живой таблицы, может сохраниться в резервной копии, сделанной час назад, и срок хранения этой копии — отдельное заявление о политике. Чтение только основного хранилища даёт неполный ответ.

Задайте вопрос в терминах полей

Руководство RFC 6973 по минимизации данных связывает собираемые и хранимые данные с обслуживаемой целью. В применении здесь полезный вопрос: какие поля задаче одновременного допуска действительно нужны и какая цель оправдывает хранение каждого из них после завершения этой задачи.

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

Когда жизненный цикл неясен, фиксируйте это как неотвеченный вопрос хранения, а не как вердикт. Наличие лимита не является доказательством скрытой истории, а правдоподобное объяснение живого состояния не является аудитом провайдера.

Похожие статьи