VPN 连接上限：实时状态与保留历史

三个同时连接是一个准入决定，而要回答它，需要知道哪些槽位此刻被占用，而不是上个月发生了什么。服务可以仅凭一张小小的活动记录表拒绝第四个会话，而完全不建立时间线。这是关于机制的陈述，不是关于运营商的，而当你阅读隐私政策时，这一区别很重要。下面的模型展示了该决定需要什么、又可以丢弃什么。

机制：一张槽位表，而不是日志

最简单的实现把订阅与最多三条活动会话记录关联起来。每个被接纳的会话占用一个槽位，当服务判定该会话结束时，槽位即被释放。记录需要一个足够具体的身份，使释放一个连接不会释放另一个连接的槽位；这就是会话标识符比账户名更重要的原因。

占用与历史是不同的数据结构。占用回答的是关于当下的“是或否”问题，可以在会话结束的那一刻丢弃。历史是只能追加的事件流，它之所以留存，是因为有人选择保留它。服务可以拥有其一、两者，或都不拥有。

这种区别从外部看不出来。一个可见的连接上限，与内存中的微型计数器、共享数据库表，以及带仪表盘的完整事件归档都相容。上限本身无法告诉你正在运行的是哪一种。

为什么实时模型仍然需要协调

丢失的连接可能不会立刻被识别为已结束。网关会等待超时、keepalive 失败或计费停止，而在其中任一到来之前，槽位一直保持占用。在这段窗口内重连的用户会看到一个与第四台设备毫无关系的拒绝。

重启的服务器必须对账自身状态，而多个服务同一账户的网关需要共同的决定。否则，账户可能通过连接不同地点而超出配额。共享或可恢复的状态解决了这一点，而共享状态是设计要求，不是监控的证据。

这种协调完全不需要浏览历史。转发数据包的网关不需要知道会话访问过哪些网站就能统计会话，而这两条数据流通常由完全不同的组件处理。

把计数保存在内存中也不会让相关事实变得匿名。在服务运行期间，与订阅相关的记录会显示某个账户有活动连接，而对该状态的访问及其生命周期都值得追问。

该状态之后去向何处

隐私问题不是服务器能否计数。要问的是，已结束的会话会怎样：记录是被删除，还是变成监控序列中的一个事件？然后问，还有哪些组件看到了同一事件，因为认证日志、计费记录和备份都可能各自保留一份执行路径所丢弃的副本。

RADIUS 计费是最清楚的例子。Start 与 Stop 成对存在，用于支持计费和会话控制，它无论是否有人将其作为历史查询，都会创建一条连接记录。因此，通过计费来执行上限的服务，从结构上保留的就多于一张槽位表。

删除也有形状。从实时表中移除的记录，可能仍存在于一小时前所做的备份中，而该备份的保留期限本身就是一项政策声明。只读取主存储会得到不完整的答案。

用字段来提问

RFC 6973 的数据最小化指南 将收集和存储的数据与所服务的目的绑定。应用到此处，有用的问题是：并发准入任务实际需要哪些字段，以及在任务结束后保留每一个字段的目的何在。

精确的服务声明会把用于执行配额的活动连接状态，与终止后保留的任何记录区分开来，并指出承诺范围内的其他系统。仅仅声明执行三连接上限的句子，既不能证明存在归档，也不能证明不存在。

当生命周期不明确时，应把它记为未回答的保留问题，而不是结论。上限的存在不是隐藏历史的证据，而一个看似合理的实时状态解释也不是对提供商的审计。