MQTT 的四次握手特指QoS 2Exactly Once恰好一次消息传递机制。它是 MQTT 协议中可靠性最高、但也最复杂的交付保障核心目标是确保消息既不丢失也不重复。这四次握手并非建立连接而是针对单条消息的端到端确认流程。 四次握手详细流程整个过程涉及四种控制报文通过两个阶段的确认来保证消息的唯一性PUBLISH (QoS 2)发送方客户端或 Broker发出消息并携带唯一的 Packet ID。发送方会将此消息持久化存储直到收到最终确认12。PUBREC (Publish Received)接收方收到 PUBLISH 报文后不会立即将消息投递给应用层而是先回复 PUBREC 报文告知发送方“我已安全收到请进入第二阶段”。同时接收方会记录下这个 Packet ID防止后续重复处理。PUBREL (Publish Release)发送方收到 PUBREC 后确认接收方已安全接收于是可以丢弃原始的 PUBLISH 消息。随后发送 PUBREL 报文通知接收方“你可以安全地处理这条消息了”。PUBCOMP (Publish Complete)接收方收到 PUBREL 后确认不会再收到重传的 PUBLISH 报文于是将消息正式投递给应用层并回复 PUBCOMP 报文。发送方收到 PUBCOMP 后丢弃 PUBREL 报文整个消息传递流程才算真正完成。️ 为什么需要四次如何防止重复QoS 1 只需要两次握手PUBLISH PUBACK但存在一个致命缺陷如果接收方处理完消息并发送了 PUBACK但 PUBACK 在网络中丢失发送方超时后会重传 PUBLISH导致接收方重复处理消息12。QoS 2 的四次握手通过状态机 Packet ID完美解决了这个问题第一阶段 (PUBLISH → PUBREC)确保消息被安全接收。即使 PUBREC 丢失导致发送方重传 PUBLISH接收方通过 Packet ID 识别出这是重复消息只会再次回复 PUBREC而不会重新处理消息。第二阶段 (PUBREL → PUBCOMP)确保消息被安全投递。只有收到 PUBREL接收方才确认“不会再有重传”此时才将消息交给应用层。即使 PUBCOMP 丢失发送方重传 PUBREL接收方也能通过状态机识别出该消息已处理完毕直接回复 PUBCOMP避免重复投递。⚠️ 关键注意事项会话内有效QoS 2 的“恰好一次”保证仅在单个会话Session内有效。如果客户端断开重连且Clean Session true历史状态丢失无法跨会话保证唯一性。性能开销最大四次握手意味着每条消息至少需要 4 次网络往返带宽和延迟开销远高于 QoS 0 和 QoS 1。不要滥用除非是计费、金融交易、关键控制指令等绝对不能丢失或重复的场景否则不建议使用 QoS 223。对于高频传感器数据或普通告警QoS 1 配合应用层幂等处理是更优选择13。应用层仍需幂等尽管 QoS 2 在协议层保证了“恰好一次”但在分布式系统或客户端异常重启等极端情况下应用层实现幂等处理依然是最佳实践1。 QoS 级别对比速查QoS 级别语义握手次数可靠性适用场景QoS 0至多一次 (At most once)1 次最低可能丢失高频传感器数据、日志上报QoS 1至少一次 (At least once)2 次中等保证送达但可能重复告警通知、设备状态同步QoS 2恰好一次 (Exactly once)4 次最高不丢不重计费、金融交易、关键控制指令核心总结MQTT 四次握手是 QoS 2 的实现机制通过两阶段确认和状态机设计在协议层面解决了 QoS 1 的重复投递问题。但它以性能为代价仅适用于对消息一致性要求极高的关键场景12。