📚 课程目录第4章协议转换的边界与约束

4. 协议转换的边界与约束

CoAP 与 MQTT 的协议转换并不是把一种报文格式“翻译”成另一种格式那么简单。两者在设计目标、传输承载、交互模型和安全机制上存在根本差异，这些差异决定了转换网关的能力边界。理解这些边界，才能判断哪些场景可以无损转换、哪些场景必须降级处理、哪些场景根本不应该尝试转换。

传输层差异：UDP 与 TCP 的本质分歧

CoAP 默认运行在 UDP 之上，报文最大约 1152 字节（受 IPv6 最小 MTU 约束），采用“请求—响应”模型，通过 CON/NON 消息类型和 Message ID 实现轻量级可靠传输。MQTT 则运行在 TCP 之上，由 TCP 保证字节流的可靠有序交付，协议层只关心 QoS 语义。这一差异带来三个直接约束：

分片与重组：CoAP 大报文需通过 Block1/Block2 选项分块传输，而 MQTT 报文长度可达 256 MB，转换网关必须处理“多块 CoAP 请求 → 单条 MQTT 消息”的聚合，或反向的拆分。
连接模型：CoAP 无连接，客户端与服务器之间没有持久会话；MQTT 依赖长连接和 Keep Alive 心跳。网关需要为每个 CoAP 端点维护到 Broker 的 MQTT 会话，并在 CoAP 侧无状态与 MQTT 侧有状态之间做映射。
重传语义：CoAP CON 消息在超时后重传，可能造成重复投递；MQTT QoS 1 也可能重复。两者叠加时，网关必须实现幂等去重，否则会出现“一次请求、多次执行”的问题。

消息语义映射难点

CoAP 的方法语义（GET/POST/PUT/DELETE）与 MQTT 的发布/订阅模型并不一一对应。CoAP 的 GET 是“读取资源当前状态”，而 MQTT 的订阅是“持续接收未来消息”。转换时常见的做法是：将 CoAP GET 映射为 MQTT 的“订阅 + 等待一条 retained 消息或下一条 publish”，但这会引入语义偏差——CoAP 客户端期望立即得到当前值，而 MQTT 订阅可能等到的是未来值。

更棘手的是响应码映射。CoAP 使用 2.05 Content、4.04 Not Found、5.03 Service Unavailable 等细粒度响应码；MQTT 没有请求—响应语义，只有 PUBACK/PUBREC 等确认。网关必须自行定义一套“响应码 ↔ 错误主题”的映射规则，例如将 CoAP 4.04 映射为 MQTT 主题 errors/not_found 下的消息，或通过请求/响应主题对（如 req/+/resp）来模拟。

状态管理：无状态与有状态的桥接

CoAP 本身是无状态协议，每个请求独立；MQTT 则依赖会话状态（Clean Session、Session Expiry、遗嘱消息等）。转换网关必须决定：是否为每个 CoAP 客户端维护一个 MQTT 会话？如果维护，会话过期时间如何设置？如果不维护，如何保证订阅关系不丢失？

一个实用的折中方案是：网关以“共享会话”模式连接 Broker，所有 CoAP 客户端共用一条 MQTT 连接，通过 Topic 前缀区分不同设备。这样网关只需维护一份连接状态，但代价是失去了 MQTT 会话级别的隔离和遗嘱消息的精确性。另一种方案是为每个 CoAP 端点建立独立 MQTT 会话，状态隔离好，但连接数和内存开销随设备数线性增长。

安全模型与服务质量对齐

CoAP 使用 DTLS 1.2 或 OSCORE 实现端到端安全，安全上下文绑定在 CoAP 端点之间；MQTT 使用 TLS 保护客户端到 Broker 的链路，Broker 可以看到明文载荷。当 CoAP 设备通过网关接入 MQTT 时，端到端安全被打破——网关成为解密点。如果业务要求端到端加密，则必须在应用层额外加密载荷，网关只做透传，但这又牺牲了基于 Topic 的路由能力。

QoS 对齐同样需要明确策略。CoAP 的 CON 消息要求确认，NON 不要求；MQTT QoS 0 最多一次、QoS 1 至少一次、QoS 2 恰好一次。常见的映射是：CON → QoS 1，NON → QoS 0。但 QoS 1 的重复投递与 CoAP CON 的重传叠加，可能导致重复执行。因此网关必须为每个请求维护一个去重窗口，通常以 Message ID + 端点地址为键，窗口大小建议覆盖 CoAP 最大重传周期（默认 ACK_TIMEOUT 2 秒、MAX_RETRANSMIT 4 次，总窗口约 45 秒）。

边界判断原则：当转换涉及端到端加密、恰好一次语义、或大报文分块时，应优先评估是否真的需要协议转换。如果两端设备都支持 MQTT，直接使用 MQTT 比经过网关转换更可靠。协议转换适合“一端是资源受限 CoAP 设备、另一端是 MQTT 云平台”的异构场景，且业务能接受至少一次语义和网关解密。

可执行的映射配置示例

以下是一份网关映射规则的配置片段，用于将 CoAP 资源路径映射到 MQTT 主题，并指定 QoS 与去重策略：

{
  "mappings": [
    {
      "coap_path": "/sensors/temp",
      "coap_method": "GET",
      "mqtt_topic": "device/{deviceId}/sensor/temp",
      "qos": 1,
      "retain": true,
      "dedup_window_sec": 45,
      "response_mode": "retained_or_next"
    },
    {
      "coap_path": "/actuators/led",
      "coap_method": "PUT",
      "mqtt_topic": "device/{deviceId}/cmd/led",
      "qos": 1,
      "retain": false,
      "dedup_window_sec": 45,
      "response_mode": "ack_only"
    }
  ],
  "session": {
    "mode": "shared",
    "client_id": "coap-gw-01",
    "keep_alive_sec": 60,
    "clean_session": false
  }
}

该配置中，dedup_window_sec 设为 45 秒，覆盖 CoAP 默认重传窗口；response_mode 为 retained_or_next 时，网关先检查 Broker 上是否有 retained 消息，有则立即返回，无则等待下一条 publish 并设置超时（建议 5 秒），超时后向 CoAP 客户端返回 5.04 Gateway Timeout。这样既避免了无限等待，也给出了明确的失败信号。

理解这些边界与约束后，在实际工程中就能做出合理判断：哪些转换可以自动完成，哪些需要人工定义映射规则，哪些场景应当放弃转换而改用其他集成方式。协议转换的价值不在于“万能”，而在于在明确的约束下提供可预测的行为。