MQTT连接建立全流程解析

本文详细解析了MQTT协议连接建立的全过程。首先通过TCP/TLS建立底层连接，然后客户端发送包含ClientID、认证信息等参数的CONNECT报文。代理验证后返回CONNACK报文，其中返回码决定连接是否成功。文章还介绍了Keep Alive机制、Clean Session选项和遗嘱消息等关键特性，并通过Mermaid流程图直观展示了连接流程。整个连接过程涉及网络层建立、协议握手、身份验证等多

奋斗者1号

685人浏览 · 2026-01-06 17:13:39

奋斗者1号 · 2026-01-06 17:13:39 发布

wireshark 抓取的数据包

在这里插入图片描述

1. 连接建立概览流程图

2. 核心步骤详解

第一步：建立底层连接 (TCP/TLS)

在发送任何 MQTT 报文之前，客户端必须先与代理服务器建立 TCP 连接。

端口：默认端口为 1883 (非加密) 或 8883 (TLS 加密)。
操作：MQTT 是基于 TCP 的长连接协议。如果需要安全性，会在 TCP 握手后进行 TLS/SSL 握手。

第二步：客户端发送 CONNECT 报文

客户端构造并发送 CONNECT 报文。这是 MQTT 连接的第一个报文，用于声明自己的身份和连接参数。
CONNECT 报文主要载荷包含：

字段名	说明
Client ID	客户端的唯一标识符。必须为 1-23 字节。如果为空，需由代理分配唯一 ID（需 Clean Session = true）。
Clean Session (v3.1.1) / Clean Start (v5.0)	为 `true` 时，表示连接断开后不保留之前的会话状态（订阅、QoS 1/2 消息）。
Keep Alive	保活时间（秒）。在此时间内如果没有数据交互，客户端需发送 PINGREQ 保持连接。
User Name / Password	用于连接认证的用户名和密码。
Will Message (遗嘱)	如果客户端异常断开，代理将自动发布的消息（包含 Will Topic 和 Will Payload）。
协议级别	客户端支持的 MQTT 版本号（如 4 代表 3.1.1，5 代表 5.0）。

第三步：代理验证 CONNECT

代理收到 CONNECT 报文后，会对报文内容进行校验。校验内容通常包括：

协议版本匹配：代理是否支持客户端请求的 MQTT 版本。
Client ID 合法性：是否符合长度限制，是否已被允许重复连接。
认证鉴权：用户名和密码是否正确（或通过扩展插件/服务认证）。
权限检查：是否有权限连接、是否允许设置遗嘱等。

第四步：代理返回 CONNACK 报文

无论验证成功与否，代理都必须回复 CONNACK 报文。
CONNACK 报文核心内容：

会话呈现标志：
- 0：服务端已恢复与客户端之前的会话状态。
- 1：服务端没有已存储的会话状态（这是一个全新的会话）。
连接返回码：最关键的字段，决定连接是否成功。

返回码 (十进制)	含义	描述
0	已连接	连接成功，可以开始通信。
1	连接不可接受 (协议错误)	协议版本不匹配。
2	标识符拒绝	Client ID 格式错误。
3	服务器不可用	服务端当前无法处理请求。
4	用户名或密码错误	认证失败。
5	未经授权	客户端未被授权连接。
结果判定：

如果 Return Code = 0：连接正式建立，TCP 通道保持打开，可以开始发送 SUBSCRIBE 或 PUBLISH 报文。
如果 Return Code ≠ 0：表示连接被拒绝。代理发送完 CONNACK 后，会主动断开 TCP 连接。

3. 关键注意事项

Keep Alive 机制：连接建立后，如果 Keep Alive 时间设置为 60秒，那么在 60秒内如果没有其他报文流动，客户端必须发送 PINGREQ，代理回复 PINGRESP。如果超过 1.5 倍 Keep Alive 时间没有收到任何报文，代理会认为客户端已断开。
Clean Session vs 持久会话：
- Clean Session = true：适合在线采集设备，断线即重置，不关心离线消息。
- Clean Session = false：适合需要高可靠性的场景。客户端断线后，代理会为其保留未确认的 QoS 1/2 消息和订阅关系，待客户端重连后（ClientID 一致）立即推送。
遗嘱机制：主要用于检测设备异常掉线（如断电）。如果是正常发送 DISCONNECT 报文断开，代理将不会发送遗嘱消息。