Keep Alive 特性用于确保客户端在即使一段时间内无消息交换时，仍保持与broker的连接和活跃会话。 可将其视为心跳，向broker表明客户端仍然在线且正常工作。
Keep Alive间隔以秒为单位，范围从0（Keep Alive机制关闭）到最大65535秒（18小时12分15秒）。
若在 Keep Alive时间的一倍半 内未收到客户端发出的任何MQTT控制报文，broker将关闭连接。
MQTT中的半开TCP连接
包括MQTT在内的网络系统中，一个常见问题是半开TCP连接的出现。 当客户端与broker之间的网络连接中断（如网络故障）时，一方（通常是broker）不知道连接已断开， 就会出现半开状态：客户端可能已断开，但broker仍认为连接活跃。
Keep Alive机制有助于缓解半开TCP连接问题。 通过强制客户端与broker之间进行周期性通信，即使无数据消息发送， 也可不断检查连接状态。 若broker在预期间隔内未收到keep-alive信号（如PINGREQ）， 可正确判断客户端已不可达，避免连接无限期处于半开状态。
Keep Alive工作原理
Keep Alive间隔在客户端通过 CONNECT 报文连接broker时设置。
若Keep Alive间隔设置为60秒，客户端必须在90秒（60 * 1.5）内发送任何MQTT控制报文（如PINGREQ、PUBLISH、SUBSCRIBE等）以告知broker其仍处于连接状态。
若客户端未能做到这一点，broker会认为客户端已断开连接，并将终止连接，同时触发遗嘱消息（如已设置）以通知意外断开。
通常，当客户端发送PINGREQ以维持连接时，broker会回复PINGRESP，确认连接仍然存活且客户端正常运行。
这种交换确保即使没有数据传输，连接仍然保持健康。
在TBMQ中，MQTT_KEEP_ALIVE_MONITORING_DELAY_MS环境变量定义了broker检查不活跃客户端连接的间隔。
默认情况下，此检查每秒执行一次。如果检测到死连接，broker将终止连接，并以”KEEP_ALIVE_TIMEOUT”作为原因。
何时关闭Keep Alive
将Keep Alive间隔设置为0意味着该功能不工作，连接没有Keep Alive超时。
基本上，客户端告诉broker它不会发送PINGREQ报文，也不期望broker监控连接的不活跃状态。
例如，始终以固定速率发送数据的IoT设备可能不需要Keep Alive检查，因为频繁的数据传输自然保持连接活跃。
禁用Keep Alive的关键影响：
- 无周期性ping。客户端不会发送任何周期性
PINGREQ报文，broker也不会期望收到。除非明确断开，否则连接被视为始终活跃。 - 未检测断连的风险。由于broker不监控客户端活动，若客户端意外断开（如网络故障或其他原因），broker在尝试向客户端发送消息前无法发现。
我们一般建议保持Keep Alive机制开启。仅在确实必要且完全理解其影响时才考虑关闭。
何时使用Keep Alive
Keep Alive功能类似于签到系统，一方定期确认其存在，以防止另一方认为出了问题。 若客户端未能在预期间隔内发送这些保活信号，broker会认为其已断开连接，并可能触发终止连接或发布遗嘱消息。
在IoT中，Keep Alive间隔对于维护可靠且一致的连接至关重要，尤其是在网络稳定性令人担忧或设备可能并非始终在主动传输数据的情况下。 例如：
- 智能家居。恒温器或智能灯等设备可能不会持续发送数据。但通过使用Keep Alive功能，它们可以定期向broker发送信号以确认其仍然连接，即使在空闲时段也是如此。
- 智能农业。监测天气条件的传感器可能不会持续传输数据，但仍会定期发送保活ping以确认其仍在运行。如果传感器未能做到这一点，broker可能会提醒农户，以便在重要数据丢失之前及时干预。
MQTT中的客户端接管
客户端接管指两个使用相同 clientId 的客户端尝试同时连接broker的场景。 根据MQTT协议，broker每个 clientId 仅支持一个活动连接。 若新客户端使用与现有会话相同的 clientId 连接，broker将终止旧客户端连接并允许新客户端接管会话。 该机制保证任意时刻仅有一个客户端实例活跃，有助于避免会话冲突或重复消息。
该接管过程还用于维护会话连续性及处理设备在网络故障后重连的情况。 若原客户端已断开而broker未知（如因半开TCP连接）， 新连接将强制关闭过时会话并建立新会话。