4. MQTT连接与断开：CONNECT报文详解、CONNACK响应码、DISCONNECT报文的优雅断开机制
好，咱们今天聊点实在的。MQTT的整个生命周期，说白了就是「连上去，发消息，断开来」这三件事。而连接和断开，是所有通信的起点和终点。我见过太多新手在CONNECT报文上栽跟头，也见过生产环境因为DISCONNECT没处理好导致资源泄漏。嗯，这一节咱们就把这两个报文彻底吃透。
4.1 CONNECT报文：一切从这里开始
客户端想要跟Broker说话，第一步就是发一个CONNECT报文。这个报文不是随便发的，它里面携带了客户端的身份信息、认证凭据、以及一些关键的协商参数。
我个人习惯把CONNECT报文拆成三块来看：固定头、可变头、有效载荷。咱们一个一个说。
4.1.1 固定头
固定头就一个字节，报文类型是0x10。没错，你抓包看到第一个字节是0x10，那就是CONNECT报文。剩下的4位是剩余长度，表示可变头+有效载荷的总字节数。
关键点：CONNECT报文的固定头永远是0x10开头。如果看到0x10后面跟着一个很大的长度值，那说明这个报文携带了很长的Client ID或者Will Message。
4.1.2 可变头：协议名、协议级别、连接标志、Keep Alive
可变头里有四个字段，我按顺序讲。
| 字段 | 长度 | 说明 |
|---|---|---|
| 协议名 | 2+4字节 | 固定为"MQTT"（长度+字符串） |
| 协议级别 | 1字节 | MQTT 3.1.1用0x04，MQTT 5.0用0x05 |
| 连接标志 | 1字节 | 8个标志位，控制各种行为 |
| Keep Alive | 2字节 | 单位秒，建议值60-300 |
这里我要重点说一下连接标志这个字节。它由8个bit组成，从高位到低位分别是：
- Bit 7：Clean Session（清理会话）
- Bit 6：Will Flag（遗嘱标志）
- Bit 5：Will QoS（遗嘱QoS，2位）
- Bit 3：Will Retain（遗嘱保留）
- Bit 2：Password Flag（密码标志）
- Bit 1：Username Flag（用户名标志）
- Bit 0：保留位，必须为0
我曾经在项目中遇到过一个问题：客户端把保留位设成了1，结果Broker直接拒绝连接。你想想看，一个bit不对，整个连接就断了。所以写代码的时候一定要小心这个保留位。
4.1.3 有效载荷：Client ID、用户名、密码、遗嘱
有效载荷的内容取决于连接标志。如果Clean Session为1，Broker会清除该客户端之前的会话状态。如果Will Flag为1，那么有效载荷里必须包含遗嘱主题和遗嘱消息。
我建议你在生产环境中，Client ID一定要唯一。如果两个客户端用相同的Client ID连接，Broker会踢掉前一个。嗯，这其实是一种简单的「单点登录」机制，但有时候也会带来麻烦。
小技巧：如果你用MQTT 5.0，可以在CONNECT报文里带上Session Expiry Interval。这样即使客户端断开了，会话还能保留一段时间。我一般在设备频繁重连的场景下用这个，效果很好。
4.2 CONNACK报文：Broker的回应
Broker收到CONNECT后，会回复一个CONNACK报文。这个报文很简单，固定头是0x20，可变头里有两个字节：连接确认标志和连接返回码。
连接返回码（Connect Return Code）是大家最关心的。它告诉你连接是否成功，如果失败，原因是什么。
| 返回码 | 含义 | 常见原因 |
|---|---|---|
| 0x00 | 连接成功 | 一切正常 |
| 0x01 | 协议版本错误 | Broker不支持客户端使用的MQTT版本 |
| 0x02 | Client ID被拒绝 | Client ID为空或格式不对 |
| 0x03 | 服务器不可用 | Broker过载或维护中 |
| 0x04 | 用户名或密码错误 | 认证失败 |
| 0x05 | 未授权 | 没有权限连接 |
我记得有一次调试一个IoT项目，客户端一直返回0x04。我查了半天，发现是密码里有个不可见字符。你想想看，这种问题用抓包工具一看就明白了，但光看代码死活找不到。
注意：MQTT 5.0的CONNACK报文结构有变化，返回码变成了原因码（Reason Code），而且可变头里多了属性字段。如果你在抓包时看到0x20后面跟着一大串数据，那多半是MQTT 5.0的报文。
4.3 DISCONNECT报文：优雅地断开
很多初学者觉得断开连接就是直接关掉TCP连接。其实不对。MQTT协议定义了一个DISCONNECT报文，用来让客户端主动告诉Broker：「我要走了，你清理一下吧。」
DISCONNECT报文的结构非常简单：固定头是0xE0，剩余长度是0。也就是说，一个完整的DISCONNECT报文就是两个字节：0xE0 0x00。
为什么要发这个报文？说白了，就是让Broker知道客户端是主动断开的，而不是因为网络故障。这样Broker可以：
- 清理该客户端的会话状态（如果Clean Session为1）
- 发送遗嘱消息（如果有）
- 释放资源
我曾经在项目中遇到过一个问题：客户端直接关闭TCP连接，不发DISCONNECT。结果Broker那边一直保留着这个客户端的会话，直到Keep Alive超时。如果客户端频繁重连，就会产生大量的僵尸会话。嗯，后来我强制要求所有客户端在断开前必须发DISCONNECT，问题就解决了。
建议：在MQTT 5.0中，DISCONNECT报文可以带一个原因码。比如0x00表示正常断开，0x04表示客户端正在关闭。这样Broker可以更精确地知道断开的原因。我个人习惯在代码里加上这个原因码，方便排查问题。
4.4 抓包实战：看看CONNECT和CONNACK长什么样
咱们用Wireshark抓一个实际的MQTT连接过程。假设客户端用Client ID "device001"连接Broker，没有用户名密码，Keep Alive设为60秒。
抓到的CONNECT报文大概是这样的：
10 1E 00 04 4D 51 54 54 04 02 00 3C 00 09 64 65 76 69 63 65 30 30 31我来拆解一下：
- 10：固定头，CONNECT报文
- 1E：剩余长度，30字节
- 00 04：协议名长度，4字节
- 4D 51 54 54：协议名"MQTT"
- 04：协议级别，MQTT 3.1.1
- 02：连接标志，Clean Session为1，没有用户名密码
- 00 3C：Keep Alive，60秒
- 00 09：Client ID长度，9字节
- 64 65 76 69 63 65 30 30 31：Client ID "device001"
Broker回复的CONNACK报文：
20 02 00 00- 20：固定头，CONNACK报文
- 02：剩余长度，2字节
- 00：连接确认标志，Session Present为0
- 00：返回码，连接成功
你看，整个过程就这么简单。但就是这几个字节，决定了你的设备能不能跟云端通信。我建议你每次调试MQTT连接时，都先抓个包看看CONNECT和CONNACK。很多问题，看一眼报文就明白了。
4.5 避坑指南
最后，我总结几个我在项目中踩过的坑：
- Client ID为空：有些Broker允许空Client ID，但大部分不允许。我建议你永远不要用空Client ID。
- Keep Alive设得太短：设成10秒的话，客户端每10秒就要发一次PINGREQ，浪费带宽。我一般设成60-120秒。
- 忘记发DISCONNECT：直接关TCP连接会导致Broker等待Keep Alive超时。记得在代码里加上disconnect()调用。
- 用户名密码里有特殊字符：MQTT的UTF-8编码对某些字符敏感。我建议你只用ASCII字符。
好了，这一节的内容就到这里。CONNECT和DISCONNECT是MQTT通信的基石，搞懂了它们，后面的PUBLISH和SUBSCRIBE就水到渠成了。下一节咱们聊聊消息的发布与订阅，到时候我会分享一些我在消息路由方面的经验。