IoT协议

📡 CoAP 受限应用协议：报文格式、通信模型与物联网实战全解析 从一个智能灯控场景说起 假设你正在开发一套智能路灯系统。每个路灯上有一颗低功耗 MCU（微控制器），通过 NB-IoT（窄带物联网）蜂窝网络上报状态、接收开关指令。MCU 的 RAM 只有 64KB，Flash 只有 256KB，网络带宽不到 100kbps，每月流量限额 30MB。 你能在这颗 MCU 上跑 HTTP 吗？ 不能。 原因有三： HTTP 基于 TCP，TCP 三次握手 + TLS 握手需要至少 5 ~ 7 个往返（RTT），在 100kbps 窄带网络上耗时数秒 HTTP 头部是纯文本，一个 GET /status HTTP/1.1\r\nHost: ... 请求头轻松超过 200 字节，而传感器上报的有效数据可能只有 4 字节（一个温度值） TCP 连接要保持状态，MCU 内存不足以维护大量连接 CoAP （Constrained Application Protocol，受限应用协议）就是为这种场景设计的。它用 UDP 替代 TCP、用 4 字节定长二进制头部替代 HTTP 的文本头、用简单的重传机制替代 TCP 的复杂拥塞控制，让一颗 64KB RAM 的 MCU 也能参与到互联网架构中。 下面先用一段概念性代码感受 CoAP 的编程模型： ...

📡 MQTT 协议：角色体系、Broker 原理与 QoS 分级机制全解析 问题切入：一个智能家居的消息困境 假设你要开发一个智能家居系统，包含以下设备： 10 个温湿度传感器，每 5 秒上报一次数据 5 个智能插座，需要接收开关指令并上报当前功率 1 个手机 App，需要实时看到所有设备的状态，并能下发控制指令 你的第一反应可能是用 HTTP：传感器 POST 数据到服务端，App 轮询拉取最新状态。但很快问题就来了： 传感器数量 × 上报频率 = 10 × (1 / 5s) = 2 QPS 的上报请求 App 轮询最新状态 = 1 × (1 / 2s) = 0.5 QPS 的查询请求 设备控制指令 = App POST 到服务端，服务端再推给设备... HTTP 是请求-响应模式，服务端无法主动向设备推送指令。如果让设备轮询指令，延迟高且浪费带宽。而且温湿度传感器是低功耗设备（电池供电的 ESP8266），HTTP 的 TCP 三次握手 + Header 开销太大。 这就是 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）解决的问题：它是一个 发布-订阅模式 的轻量级消息协议，专为低带宽、高延迟、不可靠网络下的物联网设备通信而设计。 MQTT 的角色体系 MQTT 协议定义了三种角色。大部分文章对它们的介绍含糊其词，这里逐个讲清楚。 ...