物联网基础：概念、架构与通信协议概述

在进入 MQTT 与 NodeMCU 实战之前，必须先厘清物联网（Internet of Things, IoT）的整体轮廓。许多初学者直接上手代码，却对“设备如何上云”“数据走什么路径”“为什么选 MQTT 而不是 HTTP”缺乏系统认知，导致后续排障困难。本节从概念、架构、协议三个维度建立全局视图，为后续章节的硬件连接与消息收发打下根基。

一、物联网的核心概念与本质特征

物联网并非“把物体连上网”这么简单。其本质是物理世界与数字世界的融合：通过感知设备采集物理量（温度、湿度、位置、位移、图像等），经由网络传输至计算平台，再通过分析决策反向控制执行器。一个典型的物联网系统必然包含四个能力：感知、传输、处理、控制。

物联网设备通常具有三个显著特征：资源受限（CPU 主频低、内存小、电池供电）、网络不稳定（无线信号波动、移动场景断连）、数量庞大（单网关下可能挂载数百节点）。这些特征直接决定了通信协议的选择——不能简单套用 PC 互联网的 HTTP 协议。

二、物联网四层架构与数据流转路径

业界普遍采用四层架构来描述物联网系统，每一层职责清晰，数据自下而上流动，控制指令自上而下传递。理解该架构有助于定位故障发生在哪一层。

下图展示了从传感器到应用平台的完整数据链路，以及反向控制指令的路径。注意 MQTT Broker 在网络层与平台层之间扮演了“消息枢纽”的角色。

三、主流物联网通信协议对比与选型

物联网通信协议分为两大类：近距离通信（蓝牙、ZigBee、NFC）和远距离通信（Wi-Fi、4G/5G、LoRa）。在 TCP/IP 之上，应用层协议的选择尤为关键。下表对比了三种最常见的应用层协议：

本课程选用 MQTT 作为核心协议，原因有三：其一，NodeMCU 通过 Wi-Fi 接入网络，具备 TCP/IP 能力，MQTT 的发布/订阅模型天然适合多设备、多主题的物联网场景；其二，MQTT 支持 遗嘱消息（LWT） 和 保留消息（Retained），能有效处理设备异常掉线和状态同步问题；其三，MQTT 客户端库在 ESP8266 上成熟稳定（PubSubClient 库），代码量少且调试方便。

四、MQTT 协议核心机制速览

MQTT 协议运行在 TCP 之上，默认端口 1883（明文）或 8883（TLS）。其核心机制可概括为“一中心、两角色、三 QoS”：

• Broker（代理服务器）：所有消息的中转站，负责主题匹配与转发。
• Publisher（发布者）：向指定主题发送消息，无需关心谁在订阅。
• Subscriber（订阅者）：订阅感兴趣的主题，收到 Broker 推送的消息。
• QoS 0：最多一次，消息可能丢失，适合高频传感器数据。
• QoS 1：至少一次，可能重复，适合控制指令。
• QoS 2：恰好一次，开销最大，适合计费或关键告警。

// MQTT 连接报文关键参数（NodeMCU 端示例）
const char* mqtt_server = "192.168.1.100";
const int mqtt_port = 1883;
const char* client_id = "NodeMCU_01";
const char* topic_pub = "sensor/temperature";
const char* topic_sub = "device/led/control";
// 遗嘱消息：设备异常掉线时 Broker 自动发布
const char* will_topic = "device/status";
const char* will_msg = "offline";

五、常见误区与实战复盘

实战复盘案例：某学员在室内部署 5 个 NodeMCU 温湿度节点，最初使用 HTTP 每 5 秒向服务器 POST 数据。运行 2 小时后，路由器出现连接数耗尽，部分节点掉线。改用 MQTT 后，所有节点保持长连接，Broker 主动推送数据，CPU 占用率下降 40%，且通过遗嘱消息能实时发现掉线节点。这个案例说明：协议选型直接影响系统稳定性，而 MQTT 正是为这种“多对多、低功耗、实时性要求高”的场景设计的。