MQTT-会话
MQTT会话
为什么需要会话
? 假如有以下场景,客户端A发送消息到服务端,服务端转发给客户端B，如果这个时候服务端和客户端B的网络连接断开,那么就无法保证消息到达,并且客户端A不知道B连接断开,还会继续发送消息,消息到达服务端之后会因为没有订阅者被丢弃，后面如果客户端B和服务端重新进行连接,但是还需要重新订阅进行正常通信
? 根据以上的场景,问题的关键在于服务端和客户端中已经发送但是没有完全确认的消息和等待发送的消息以及客户端订阅信息等，这些重要的信息不应该随着断开而消息,我们应该把这些重要信息存储下来,并独立于连接存在,以此引出了会话的作用和意义
什么是会话
? 会话是MQTT通信的基础,当客户端和服务端建立MQTT连接，他们就创建了一个有状态的会话,后续消息的收发都会在这个会话上进行,消息的发送进度,待发送的消息列表，都属于会话状态的一部分
会话的生命周期
会话的生命周期根据连接和断开分为以下几种
- 会话生命周期与网络连接相同
我们可以让会话仅持续和网络连接一样长的时间,这表示会话状态将在网络断开的时候被丢弃,下次连接时,必须创建一个新的会话
- 会话生命周期长于网络连接
可以使会话跨越多个网络连接存在,这就要去客户端和服务端断开连接的时候,必须保存各自的会话状态,比如发送没有完全确认的消息等,以便下次连接时通过会话状态恢复通信,我们把这个会话称为持久会话
恢复会话
为了确保双方能够从正确的会话中恢复通信,服务端和和客户端需要把Client ID 唯一标志进行关联
MQTT为服务端和客户端分别定义了他们需要存储的会话状态
服务端存储的会话状态:
-
客户端的订阅信息:客户端只要在会话过期前重连，就不用再重新订阅,因为订阅仍然存在,即便客户端离线状态,服务端也可以给客户端缓存后续到达的消息
-
已发送但还未完成确认的 QoS 1和QoS 2的消息以及等待发送的QoS 0、1、2的消息:既包含了上一次连接没来得及下发的消息，也包含了离线期间新到达的消息, QoS 0 的消息,协议没有强制要求,可以存储也可以补存储，可以提供选项自定义是否需要存储
-
从客户端收到的还没有完成确认的QoS 2 消息:以便重新连接后QoS2的传输流程能够正常恢复
-
遗嘱消息和遗嘱延迟间隔:这里是协议mqtt3.1.1和5.0版本的不同，如果是3.1.1中断开连接遗嘱消息会立即下发,则不需要服务端存储
-
会话是否存在:如果断开连接的时间太长,会话可能过期,也可能因为其他故障导致的会话丢失,所以需要服务端保存会话是否存在的信息,客户端连接服务端时，服务端会使用连接报文中的 Client ID 来寻找对应的会话状态,然后通过响应报文中的 Session Persent字段来告诉客户端是否复用了之前的会话,以便两端在一个正确的基础上进行通信
客户端需要存储的会话状态:
- 所有发送给服务端但是还没有完成确认的QoS1和2消息以及从服务端收到的没有确认的QoS2的消息,原理和服务端状基本类似，不再赘述
不同协议版本中的会话字段
MQTT 5.0会话字段
Clean Start字段
用于表示是否在连接时复用已经存在的会话
- Clean Start = 0 ，表示尝试从已存在的会话中恢复通信,客户端连接时，如果服务端中存在与指定client id关联的会话，服务端就必须基于这个会话来恢复通信，如果不存在对应的会话，服务端必须创建一个全新的会话
- Clean Start = 1，不从会话中恢复通信,即便客户端和服务端连接时存在相应的会话,服务端也必须丢弃会话创建一个全新的会话
Session Expiry Interval字段
指定会话在连接断开后能够保留的最长时间,如果过,期时间内客户端没有重新连接,服务端则会丢弃对应的会话状态
- Session Expiry Interval = 0，生命周期与网络连接相同，会话将在网络连接断开的时候立即结束
- Session Expiry Interval > 0,如果值大于0,则表示会话将在连接断开后多少秒后过期
- Session Expiry Interval = 0xFFFFFFFF,表示会话永不过期
每个客户端都可以独立设置自己的Session Expiry Interval ,MQTT允许客户端在断开连接(DISCONNECT)的时候 重新设置过期时间，比如延长会话时间或者直接为0取消持久会话等等
MQTT3.1.1 会话字段
3.1.1协议中只有一个Clean Session字段
Clean Session字段
- Clean Session = 0，等同于5.0中 Clean Start = 0 、Session Expiry Interval = 0xFFFFFFFF
- Clean Session = 1，等同于5.0中 Clean Start = 1 、Session Expiry Interval = 0
3.1.1协议的的灵活性不如5.0,在3.1.1协议中,不能为每个客户端设置单独的会话时间 也不能断开时重新设置过期时间，导致不需要会话保留很久的客户端，会话信息也回被服务端长时间存储，也造成一定程度上服务端资源的浪费
如何选择会话的生命周期
选择持久会话的场景
- 不希望错误离线期间的消息
- 不希望QoS 1 和QoS 2消息丢失
- 不希望每次连接都重新建立订阅
- 设备定期休眠,不希望长时间维护连接
选择非持久会话的场景
- 只对外发布 QoS 0的消息,不会接收任何消息
- 只订阅QoS 0 的消息,不关心离线期间的消息