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字段来告诉客户端是否复用了之前的会话,以便两端在一个正确的基础上进行通信

客户端需要存储的会话状态:

Clean Start字段

用于表示是否在连接时复用已经存在的会话

Clean Start = 0 ，表示尝试从已存在的会话中恢复通信,客户端连接时，如果服务端中存在与指定client id关联的会话，服务端就必须基于这个会话来恢复通信，如果不存在对应的会话，服务端必须创建一个全新的会话
Clean Start = 1，不从会话中恢复通信,即便客户端和服务端连接时存在相应的会话,服务端也必须丢弃会话创建一个全新的会话

Session Expiry Interval字段

指定会话在连接断开后能够保留的最长时间,如果过,期时间内客户端没有重新连接,服务端则会丢弃对应的会话状态

每个客户端都可以独立设置自己的Session Expiry Interval ,MQTT允许客户端在断开连接(DISCONNECT)的时候重新设置过期时间，比如延长会话时间或者直接为0取消持久会话等等

3.1.1协议中只有一个Clean Session字段

Clean Session字段

3.1.1协议的的灵活性不如5.0,在3.1.1协议中,不能为每个客户端设置单独的会话时间也不能断开时重新设置过期时间，导致不需要会话保留很久的客户端，会话信息也回被服务端长时间存储，也造成一定程度上服务端资源的浪费