1. 课程导入与协议转换工程概览

在物联网系统中，设备侧与平台侧往往使用不同的应用层协议。设备侧常见 CoAP（Constrained Application Protocol），平台侧常见 MQTT（Message Queuing Telemetry Transport）。当现场设备已经按 CoAP 接入，而云端、数据中台或第三方系统只接受 MQTT 时，就需要一个协议转换工程把两侧“接起来”。本课程讨论的正是这类转换：不是简单改一个端口，而是围绕报文语义、交互模型、会话状态与安全边界做系统化映射。

一、CoAP 与 MQTT 的核心差异

CoAP 基于 UDP，采用请求/响应模型，报文小、开销低，适合电池供电、网络不稳定的受限设备。它使用 URI 标识资源，例如 coap://[fd00::1]:5683/sensors/temp，方法包括 GET、POST、PUT、DELETE，并支持 Observe 机制实现资源状态推送。MQTT 基于 TCP，采用发布/订阅模型，通过 Broker 解耦生产者与消费者，主题形如 factory/line1/temp，服务质量分为 QoS 0、1、2，并支持遗嘱消息与保留消息。

两者最本质的差异在于交互范式：CoAP 是“客户端主动问资源”，MQTT 是“发布者写主题、订阅者收消息”。因此转换器必须完成三件事：把 CoAP 请求映射为 MQTT 发布或订阅，把 MQTT 消息还原为 CoAP 响应或 Observe 通知，并维护两者之间的会话与状态。下表给出关键对比。

二、转换需求从哪里来

转换需求通常来自四类现实约束。第一，设备侧已经量产，固件只支持 CoAP，改造成本高；第二，平台侧统一采用 MQTT 接入，要求所有数据进入同一套 Broker 与规则引擎；第三，现场网络是 NB-IoT、LoRa 或 6LoWPAN，UDP 更省电、更省带宽；第四，业务需要 MQTT 的订阅分发能力，把同一份数据同时送给监控、存储和告警系统。转换器因此成为“协议边界上的适配层”，它既要理解 CoAP 的资源语义，也要理解 MQTT 的主题语义。

三、典型应用场景

场景一：智慧楼宇。温湿度传感器通过 CoAP 上报到楼层网关，网关转换为 MQTT 后发布到 building/floor3/env，楼宇平台订阅后驱动空调策略。场景二：工业设备远程运维。PLC 边缘盒以 CoAP 暴露寄存器资源，转换器把 /plc/line2/status 映射为 plc/line2/status，运维平台通过 MQTT 订阅并写入时序数据库。场景三：车联网与共享设备。车载终端用 CoAP 上报位置，转换器按 QoS 1 发布到 MQTT，保证关键轨迹不丢。场景四：能源抄表。电表通过 CoAP 响应抄读请求，转换器把抄读结果发布到 MQTT，供计费系统消费。

四、整体学习路线

本课程按“先看清差异，再动手转换，最后保障可靠与安全”的顺序展开。前期建立 CoAP 与 MQTT 的报文与交互模型；中期实现请求/响应到发布/订阅的映射、主题与 URI 的对应、QoS 与 CON 的可靠性对齐；后期处理 Observe 与保留消息、遗嘱消息、DTLS/TLS 安全边界、异常重连与幂等。学习过程中会反复使用一个可运行的转换器示例，参数均为教学假设值，便于复现和观察。

上图把设备侧、转换器与平台侧放在同一条链路上：左侧 CoAP 的请求与响应，经过转换器的解析、映射、状态管理和 MQTT 客户端，变成右侧 Broker 上的发布与订阅。图中同时标出安全边界与可靠性对齐点，后续章节会逐一展开。理解这张图，就理解了本课程要解决的核心问题：在两种协议之间建立一条语义一致、状态可控、安全可验证的通道。

五、一个最小转换示例

假设设备以 CoAP GET 请求 coap://[fd00::1]:5683/sensors/temp 读取温度，转换器收到后按映射规则生成 MQTT 主题 sensors/temp，并以 QoS 1 发布载荷 {"value":23.5,"unit":"C"}。若平台需要反向控制，则订阅 cmd/sensors/temp，转换器收到 MQTT 消息后，向设备发起 CoAP POST 到 /actuator/temp/set，并把设备返回的 2.04 Changed 转换为 MQTT 的确认消息。这个例子说明：转换器不是单向搬运，而是双向语义适配。