【译文】MQTT会话过期时间和消息过期时间


原文:https://link.juejin.cn/?target=https%3A%2F%2Fwww.hivemq.com%2Fblog%2Fmqtt5-essentials-part4-session-and-message-expiry%2F

作者: Florian Raschbichler
发布时间: 2019年10月16日
更新于: 2023年6月29日

会话过期间隔和消息过期间隔在MQTT 5是如何运作的?

让我们分别拆解和分析这两个整数类型的过期时间特性。

会话过期时间

会话过期时间是一个以秒为单位的参数,由客户端在CONNECT阶段设置完成。其表示代理服务器保留客户端会话信息的时长。如果间隔设置为0,或者在CONNECT阶段没有设置过期值,那么客户端网络通信一旦终止,代理服务器会立即删除会话数据。 注意,最大会话过期时间值是 UINT_MAX (4,294,967,295), 这使得离线会话在客户端断开连接后能够维持持久化超过136年的时间。

会话过期时间是定义在CONNECT数据包中的

消息过期时间

使用MQTT 5, 客户端可以对每条PUBLISH数据包设置一个以秒为单位的消息过期时间。此间隔时间代表着非离线状态下,代理服务器维护PUBLISH数据包的时长。如果没有定义消息过期时间,代理服务器会为所有的已匹配主题的订阅者无限期的保留信息,甚至已处于断开状态的订阅者也是如此。而且,如果在发送PUBLISH数据时,选择了‘retained=true’, 消息过期时间还能决定在特定主题上保留消息的时间长度。

Message Expiry Interval in PUBLISH packet

为什么引入过期时间呢?

不仅要理解“过期时间”功能,也要探索这些特性纳入MQTT 5规范的原因以及它们实际应用程序中的使用。

介绍MQTT 5协议文章中, 我们领会了OASIS委员会审议过程的精神,最终在2019年3月将MQTT 5确立为标准。作为这个委员会的成员之一,HiveMQ感到非常骄傲,HiveMQ积极收集用户反馈,了解MQTT 3.1和3.1.1版本用户的长期需求,并决定如何最好地发展协议。主要的推动力是引入了一些特性,这些特性扩大了用户的使用场景,增强了用户使用协议的简单性。

会话过期时间

MQTT 5中的会话过期时间巧妙地实现了两个重要需求。MQTT的早期版本为了删除持久性会话仅提供了一个单一路径: 当客户端需要丢弃一个会话时,客户端不得不使用cleanSession=true标志来重新连接一次代理服务器。

由于停用,破坏,或者负载测试后的不充分清理会话,导致IoT设备绝不会重新连接,这些剩余会话可能会对代理服务器的持久性造成不必要的负担。像HiveMQ这样的企业级MQTT代理服务器配备了复杂的管理工具,如HiveMQ 控制中心,以便于管理空闲会话。尽管如此,辨别哪些会话可以有效地删除仍然是至关重要的。

MQTT 5加入的会话过期时间特性,直观的允许用户指定一个合理的持续时间,之后代理服务器会自动清除空闲会话,从而释放有价值的资源。

除了这种自动清理功能之外,会话过期时间还极大地简化了会话状态管理。Ian Craggs 慷慨地提供了两个图表来说明状态转换中复杂性的降低。这种可视化强调了这个新特性如何有助于简化状态转换和提高用户效率。

De-cluttering of state transition in MQTT 3.1.1 and MQTT 5 (courtesy of Ian Craggs)

消息过期时间

与MQTT 5协议起草类似,“会话过期时间”的起因是为了一个自动化维护机制需求而被推动的。想想无数的IoT设备,如:为了抵御长时间的网络断开而设计的互联网汽车。MQTT为这些具有持久会话和消息排队的场景提供了基础保障。

为离线设备精心准备的消息会存储在代理服务器上,等待设备恢复连接以进行传递。在大规模部署中,连接设备的数量升级到数千甚至数百万,因此必须单独约束每个客户端的离线消息队列。

与IoT设备相关的信息有效期可能会出现显著的波动。以互联网汽车为例: 交通更新只能短暂地保持其相关性。然而,当我们考虑无线固件升级时,即使汽车长时间处于离线状态,延长到几个星期,也需要执行这些升级。

MQTT 5中的消息过期时间是管理这些不同时间框架的完美工具,增加了协议的通用性

Connected car example

例如: 交通堵塞警报通常在1-2小时后就会过时,但是固件更新应该可以持续好几周。消息过期是定义这些不同时间段的完美特性。

为需要有时间有效期的消息分配一个最佳消息过期时间,同时保留没有任何无有效期限制的相关消息, 对于长时间离线的客户端来讲,我们能确保高效的利用代理服务器资源。这种策略还避免了客户端在重新连接时被不相关的消息淹没。

对于保留消息,消息过期时间操作类似,保证这些消息只在指定的时间段内发送给新订阅方。

但是,需要注意的一个重要方面是,当客户端的会话过期时,该客户端的所有排队消息也会与会话同步过期,而不管它们各自的消息过期状态如何。这个“陷阱”是对MQTT协议中会话及其排队消息的相互联系的重要提醒。

关于使用MQTT 5会话过期时间和消息过期时间的重要提示

一些重要信息:

  • 会话过期时间和消息过期时间都有助于完善MQTT代理服务器上的资源管理
  • 回顾过去,许多MQTT 3用户表示需要有效期特性。HiveMQ通过在我们的MQTT平台中引入了会话和消息过期时间作为补充特性来响应这一需求,这早于它们在MQTT 5中的标准化
  • 在MQTT 3的CONNECT 数据包中,cleanSession=true 等价于 sessionExpury = 0(或不存在) ,而在 MQTT 5中则是cleanStart = true。
  • 同样,MQTT 3的CONNECT数据包中“cleanSession=false” 会在MQTT 5中找到其对应的 sessionExpire值,该值大于零,并通过“cleanStart=false”表示
  • MQTT代理服务器(例如 HiveMQ)提供了在服务器端为这些过期时间配置最大值的能力。这个特性在多供应商项目中非常方便,特别是当代理服务器操作员可能缺乏对MQTT客户端设置权限时。

MQTT 5的出现引入了一系列旨在增强协议的可用性、灵活性和效率的新特性。会话过期时间和消息过期时间是这方面的主要例子,它们在资源管理和确保MQTT代理服务器的顺利运行方面,起到了非常有价值的工具的作用。这两个特性都真正体现了MQTT标准以用户为中心的演变,展示了它对用户需求和挑战的响应能力。


文章作者: 冬瓜冬瓜排骨汤
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 冬瓜冬瓜排骨汤 !
  目录