4. 设备端注册协议：基于MQTT/CoAP的注册请求

设备注册，说白了就是设备跟服务器说一声「我来了，这是我的身份证」。那这个「说一声」到底怎么说的？用的是什么协议？报文长什么样？

我个人习惯把设备端注册协议分成两大类：MQTT 和 CoAP。为什么是这两个？因为物联网设备大多资源受限，HTTP 太重了。你想想看，一个只有几十 KB RAM 的传感器，跑个 HTTP 栈都费劲，更别提 TLS 握手了。

我在项目中遇到过不少团队，一上来就选 HTTP，结果设备端内存爆了，最后乖乖换回 MQTT 或 CoAP。嗯，这里要注意，协议选型直接决定了注册流程的成败。

4.1 MQTT 注册协议

MQTT 是基于发布/订阅模式的轻量级协议。设备注册时，设备作为 Publisher，把注册请求发到某个特定 Topic 上。服务器作为 Subscriber，收到后处理并回复。

我建议把注册 Topic 设计成这样的结构：

设备注册请求 Topic：/v1/devices/{productKey}/{deviceName}/register
设备注册响应 Topic：/v1/devices/{productKey}/{deviceName}/register/reply

为什么分两个 Topic？因为 MQTT 的 QoS 机制。请求用 QoS 1，确保至少送达一次；响应用 QoS 0，丢了就丢了，设备可以超时重发。我在项目中踩过这个坑——请求和响应用同一个 Topic，结果设备自己收到了自己发的消息，死循环了。

4.1.1 MQTT 注册请求报文格式

MQTT 的报文本身是二进制格式，但 Payload 部分我们一般用 JSON。我个人习惯的请求报文结构如下：

{
  "method": "register",
  "version": "1.0",
  "timestamp": 1712345678,
  "clientId": "device_001",
  "params": {
    "productKey": "a1B2c3D4e5",
    "deviceName": "sensor_temp_01",
    "deviceSecret": "6f8c9b3a2e1d4f7a",
    "firmwareVersion": "2.1.0",
    "hardwareVersion": "1.0.0",
    "mac": "AA:BB:CC:DD:EE:FF",
    "signMethod": "hmacsha256",
    "sign": "a1b2c3d4e5f6..."
  }
}

这里有个关键点：sign 字段。设备需要用预置的 deviceSecret 对某些参数做签名，防止伪造注册请求。我曾经见过一个项目，签名算法写错了，结果所有设备注册都被服务器拒绝，排查了整整两天。

4.1.2 MQTT 注册响应报文格式

服务器处理完注册请求后，会向响应 Topic 发送一条消息：

{
  "method": "register_reply",
  "version": "1.0",
  "timestamp": 1712345679,
  "clientId": "device_001",
  "code": 200,
  "message": "success",
  "data": {
    "deviceToken": "tk_a1b2c3d4e5f6",
    "expireTime": 1712432078,
    "serverUrl": "mqtt://iot.example.com:1883",
    "config": {
      "heartbeatInterval": 60,
      "dataUploadInterval": 300
    }
  }
}

注意 deviceToken，这是服务器下发的临时凭证。设备后续的所有通信都要带上这个 Token。我建议 Token 有效期不要太长，24 小时比较合理。太长了不安全，太短了设备频繁重新注册，浪费电。

4.2 CoAP 注册协议

CoAP 是类 HTTP 的协议，但跑在 UDP 上。它比 MQTT 更轻量，适合资源极度受限的设备——比如那些只有 16KB Flash 的 MCU。

CoAP 的注册流程跟 RESTful API 很像。我个人习惯用 POST 方法，资源路径设计如下：

POST coap://iot.example.com/v1/devices/register

4.2.1 CoAP 注册请求报文格式

CoAP 的报文头是二进制，但 Payload 同样推荐 JSON。请求报文结构：

{
  "productKey": "a1B2c3D4e5",
  "deviceName": "sensor_temp_01",
  "deviceSecret": "6f8c9b3a2e1d4f7a",
  "firmwareVersion": "2.1.0",
  "hardwareVersion": "1.0.0",
  "mac": "AA:BB:CC:DD:EE:FF",
  "signMethod": "hmacsha256",
  "sign": "a1b2c3d4e5f6..."
}

跟 MQTT 版本比，少了 method 和 version 字段。为什么？因为 CoAP 的 Method 已经在报文头里了（POST），不需要在 Payload 里重复。version 字段在 CoAP 场景下通常用 CoAP 协议版本号代替，不需要额外传。

4.2.2 CoAP 注册响应报文格式

CoAP 响应使用 2.01 Created 状态码，表示资源创建成功：

{
  "code": "2.01",
  "deviceToken": "tk_a1b2c3d4e5f6",
  "expireTime": 1712432078,
  "serverUrl": "coap://iot.example.com:5683",
  "config": {
    "heartbeatInterval": 60,
    "dataUploadInterval": 300
  }
}

CoAP 的响应码跟 HTTP 类似，但更精简。2.01 相当于 HTTP 的 201 Created。4.00 相当于 400 Bad Request。4.03 相当于 403 Forbidden。

4.3 MQTT vs CoAP 注册对比

很多初学者会问：到底选 MQTT 还是 CoAP？我一般这样回答：

对比维度	MQTT	CoAP
传输层	TCP（需长连接）	UDP（无连接）
报文开销	最小 2 字节头	最小 4 字节头
可靠性	QoS 0/1/2 保证	CON/NON 确认模式
适用场景	网络稳定、需双向通信	网络差、设备极低功耗
注册流程复杂度	中等（需维护 Topic）	简单（类 REST）
我的推荐	WiFi/以太网设备	NB-IoT/LoRa 设备

你想想看，如果你的设备是插着网线的网关，选 MQTT 准没错。如果是电池供电的温湿度传感器，一年才换一次电池，那 CoAP 更合适。

4.4 注册协议核心流程

下面这张图是我自己画的注册协议核心流程，涵盖了 MQTT 和 CoAP 两种方式：

4.5 避坑指南

做设备注册协议，有几个坑我踩过，分享给你：

4.6 小结

设备端注册协议，说白了就是设备跟服务器之间的一次「握手」。MQTT 适合网络稳定的场景，CoAP 适合资源受限的场景。报文格式上，JSON 是主流，签名是必须的，Token 是核心。

我个人建议，如果你的团队刚开始做设备注册，先从 MQTT 入手，因为生态成熟，调试工具多。等流程跑通了，再考虑要不要换成 CoAP 来省电省流量。