我们很高兴地宣布 TBMQ 的发布2.2.0！此版本带来了强大的新功能，使 TBMQ 更加安全、更有弹性，并且更易于大规模生产操作。
在 TBMQ 2.2 中，我们专注于以下关键领域：
- 安全性更强 - 新的可插入身份验证提供程序，包括对 JWT认证，以及在可疑客户端到达身份验证阶段之前将其阻止的能力。
- 负载下可靠性更高 - 先进的 背压处理 确保无法跟上的订阅者不再使经纪商面临风险，从而保护内存并保持稳定性。
- 运营灵活性 - 现在可以调整安全和流量控制策略 在飞行中，无需重新启动。
总之，这些改进使 TBMQ 2.2 成为迄今为止最安全、最具弹性的版本 - 准备好为物联网、消息传递和事件驱动系统中要求苛刻的 MQTT 工作负载提供支持。
MQTT 身份验证提供商
安全性一直是 TBMQ 的基石，在这个版本中，我们在身份验证的管理方式方面向前迈出了一大步。此前，TBMQ 支持 基本身份验证（客户端 ID/用户名/密码）, X.509证书链认证， 和SCRAM（MQTT 5.0）。虽然这些效果很好，但它们是通过 YAML 文件或环境变量专门配置的，这意味着每次更改都需要重新启动代理。
通过 TBMQ 2.2，身份验证提供程序已完全 移入数据库 现在可以直接通过用户界面或 API 即时配置，无需停机。这使得在动态环境中调整身份验证策略变得更加容易。
可插入的身份验证提供程序
TBMQ 现在支持身份验证提供程序的灵活、可插入模型。以下方法可用，并且可以独立启用、禁用或调整：
- 基本认证 — 使用 CONNECT 数据包中发送的 clientId、用户名和密码对客户端进行身份验证。
- X.509 证书链 — 在 TLS 握手期间使用客户端的 X.509 证书链进行身份验证。
- JWT 身份验证（新） — 使用 CONNECT 数据包的密码字段中传递的签名 JWT 对客户端进行身份验证。
- SCRAM（仅限 MQTT 5.0） — 使用散列凭据执行安全质询响应以进行身份验证，而无需发送实际密码。
每个提供程序都可以通过 TBMQ UI 中的“身份验证提供程序”页面进行控制。您可以切换提供商、调整其参数或深入了解提供商详细信息以微调您的安全模型。
执行指令
TBMQ 2.2 的另一个改进是 可配置的执行顺序 身份验证提供商。
从 MQTT 身份验证设置 页面中，您可以定义 TBMQ 在处理客户端连接时评估提供程序的顺序。例如，这使得可以根据您的部署需求优先考虑基于证书的身份验证而不是用户名/密码，反之亦然。
为什么它很重要
这一变化将身份验证管理从静态且操作繁重的过程转变为动态、UI 驱动的过程。您现在无需重新启动和手动更改环境变量，而是可以获得：
- 身份验证策略的零停机更改。
- 集中管理所有身份验证方法。
- 更灵活地组合不同的身份验证策略。
这为 TBMQ 2.2 中的其他安全改进（例如基于 JWT 的身份验证）铺平了道路。
智威汤逊认证
从版本 2.2 开始，TBMQ 引入了对 MQTT 客户端的 JWT（JSON Web 令牌）身份验证的支持。这实现了一种安全、灵活且可扩展的方式来使用签名令牌验证客户端身份，从而更容易与集中式身份系统集成并实施细粒度的访问控制。
它是如何运作的
当 MQTT 客户端连接时，它会放置一个 签名的 JWT 令牌 进入 password 的领域 CONNECT 包。然后TBMQ：
-
验证令牌的签名 使用支持的验证方法之一：
- HMAC 秘密 （HS256/384/512）
- PEM 格式的公钥 （RSA、EC、Ed25519）
- JWKS 端点 （通常与 Keycloak、AWS Cognito 或 Auth0 等提供商一起使用）
-
检查标准声明例如
exp（到期）和nbf（不是之前）以确保令牌及时有效。 -
（可选）验证自定义声明 （例如，确保令牌
sub匹配 clientId 或mqtt_user与用户名匹配）。 - 对客户类型进行分类 （设备或应用程序）基于令牌声明或默认。
-
应用授权规则 — 来自提供商设置的静态、基于正则表达式的规则或 直接从 JWT 声明中提取的动态规则 （例如，
pub_rules和sub_rules定义客户端可以发布或订阅哪些主题的声明）。
只有当所有这些步骤都成功时，客户端才被允许连接和交换数据。
为什么 JWT 对于 MQTT 很重要
JWT 为 TBMQ 用户带来了许多好处：
- 集中式身份集成 — 将您的经纪人连接到发行 JWT 的现代身份系统。
- 无静态凭证 — 消除在配置文件或客户端中管理密码的风险。
- 动态授权 — 授权规则可以直接注入到令牌中，使访问控制更加灵活和自适应。
- 可扩展性和安全性 — 非常适合物联网部署，其中成千上万的设备需要安全的、基于令牌的身份验证。
被阻止的客户
另一个主要的新增功能是“阻止客户端”功能，这是一种主动安全工具，可以让管理员更好地控制谁可以连接到代理。
通过阻止客户端，您可以根据以下标识符阻止不需要的或可疑的 MQTT 客户端建立连接：
- 客户ID
- 用户名
- IP地址
- 基于正则表达式的规则 更灵活的模式匹配
例如，如果您检测到像这样的客户端 attack-bot-23 如果尝试通过重复的连接尝试淹没代理，您可以立即通过客户端 ID 阻止它 — 在进行身份验证之前切断访问。
它是如何运作的
- 早期拒绝： 发生块检查 认证前，确保在不消耗系统资源的情况下阻止恶意流量。
- 集群范围的一致性： 使用 Kafka 在所有 TBMQ 节点之间同步块规则，确保分布式部署中的一致执行。
- 临时区块： 每个条目可以包含一个 过期时间，之后会自动清理。这对于临时隔离或限时限制很有用。
为什么它很重要
该功能不仅增强了安全性，还有助于 减少负载 通过在管道早期拒绝不需要的连接来在代理上进行操作。这提高了系统在攻击或大流量下的稳定性和响应能力。
最佳实践
- 使用 精确匹配 （客户端 ID、用户名、IP）只要有可能 - 正则表达式规则很强大，但更占用资源。
- 保持阻止列表精简以获得最佳性能。
- 将阻止与标准身份验证相结合以创建 多层防御策略.
简而言之，阻止的客户端增加了新的保护层，使管理员能够快速对可疑活动做出反应并维护安全、稳定的 MQTT 环境。
MQTT 背压
高吞吐量 MQTT 系统面临一个常见的挑战：如果订阅者无法跟上消息流会发生什么？如果没有保护措施，代理的缓冲区可能会不受控制地增长，导致内存使用过多甚至系统崩溃。
在 TBMQ 2.2 中，这个问题通过引入来解决 背压感知交付。 TBMQ 不会压倒缓慢的订阅者，而是根据每个客户端连接的运行状况智能地暂停和恢复消息传递。
它是如何运作的
TBMQ 持续监控客户端的连接是否可以接受新数据。当订阅者过载时：
- 消息传送暂时停止 一旦连接缓冲区达到配置的阈值。
- 自动恢复交付 一旦连接再次准备好。
- 这确保任何单个客户端都不会破坏代理的稳定性或消耗过多的资源。
处理不同的客户类型
TBMQ 根据 MQTT 客户端的类型应用定制策略：
- 非持久客户端：如果客户端跟不上，消息将被跳过。这可以防止内存累积，并符合 MQTT 期望，即短期会话的消息丢失是可以接受的。计数器跟踪为了可见性而丢弃的消息数量。
-
持久的客户： 消息不会丢失。相反，它们会被缓冲，直到连接恢复：
- 设备 → 消息在 Redis 中排队。
- 应用领域 → 消息在 Kafka 消费者级别暂停，直到客户端准备就绪。
这种设计保证了持久会话的持久性，同时保护资源免遭失控增长。
共享订阅
背压处理也扩展到共享订阅。如果组中的一个订阅者速度变慢，TBMQ 会尽可能将消息重新路由到其他订阅者。如果所有消息都过载，则消息将被安全缓冲（对于持久组）或删除（对于非持久组）。
为什么它很重要
通过使交付具有背压感知能力，TBMQ 2.2 可确保：
- 稳定的内存使用 即使在重负载下。
- 公平的资源分配 跨越快消费者和慢消费者。
- 无停机或崩溃 由于订户超载。
实际上，这意味着您的经纪人可以处理 海量吞吐量 同时保持弹性——可靠地将消息传递给能够跟上的订阅者，而不会被那些跟不上的订阅者拖累。
最后的话
TBMQ 2.2 在安全性、可靠性和性能方面提供了重要的进步 - 但这篇文章只触及了表面。我们鼓励您查看完整的 发行说明 探索此版本中包含的所有改进和修复。
如果您发现 TBMQ 有价值，请通过以下方式支持我们 主演的 TBMQ GitHub 存储库，分享您的反馈，并通过问题或拉取请求做出贡献。您的意见有助于我们在每个版本中改进 TBMQ。
