2. 物联网基础
2.1 物联网的核心概念与本质
物联网（Internet of Things，IoT）并非一个单一技术，而是将物理世界中的“物”接入数字网络，使其具备感知、通信与可控能力的技术体系。理解物联网需要抓住三个关键词：感知（采集温度、湿度、位置、运动等物理量）、传输（将数据通过有线或无线方式送达服务器）、处理与反馈（云端或边缘侧分析数据，并下发指令控制执行器）。
以ESP8266为例，它本身是一个Wi-Fi单片机，当它连接DHT11温湿度传感器时，就构成了一个典型的物联网终端节点——传感器负责“感知”，ESP8266负责“传输”，而MQTT服务器则承担“处理与转发”的桥梁角色。这种“端-管-云”的协作模式，正是物联网区别于传统互联网（人与人的连接）的核心特征。
2.2 物联网四层架构与数据流向
业界普遍将物联网划分为四层架构，每一层职责清晰、相互依赖。理解架构是后续选择通信协议的基础。
| 层级 | 核心职责 | 典型设备/技术 | 数据特点 |
|---|---|---|---|
| 感知层 | 物理量采集与执行 | 传感器、执行器、RFID | 数据量小、频率低 |
| 网络层 | 可靠传输与路由 | Wi-Fi、LoRa、MQTT | 需保证实时性与可靠性 |
| 平台层 | 数据存储、设备管理 | 云服务器、MQTT Broker | 海量汇聚、并发处理 |
| 应用层 | 业务逻辑与用户交互 | Web仪表盘、手机App | 结构化、可视化 |
在ESP8266项目中，我们通常将感知层与网络层融合在单片机上：ESP8266直接读取传感器数据，再通过Wi-Fi发送至MQTT Broker。这种“瘦终端+胖云端”的模式，降低了终端硬件成本，但要求通信协议必须轻量、省电、容错性强——这正是MQTT被广泛采用的原因。
2.3 主流物联网通信协议横向对比
物联网通信协议的选择直接影响功耗、实时性、开发复杂度与服务器压力。目前最常见的三种应用层协议是MQTT、CoAP和HTTP，它们各有适用场景。
- MQTT（消息队列遥测传输）：基于发布/订阅模式，使用TCP长连接，支持QoS分级与遗嘱消息。适合低带宽、高延迟或不稳定网络下的设备状态上报与控制指令下发。
- CoAP（受限应用协议）：基于UDP，类似HTTP的REST风格，但头部压缩更激进。适合资源极度受限（如RAM<10KB）的节点，但可靠性需应用层自行保障。
- HTTP/HTTPS：请求/响应模式，无状态、头部冗余大。适合设备主动上报且频率较低的场景，但服务器无法主动推送指令，需设备频繁轮询。
2.4 MQTT在物联网中的核心地位
MQTT之所以成为物联网事实标准（OASIS标准），并非因为它功能最丰富，而是因为它精准解决了物联网场景的三大痛点：
- 网络不可靠：MQTT基于TCP，但通过QoS机制（最多一次、至少一次、恰好一次）让应用层可以容忍网络抖动，且断线自动重连。
- 设备数量庞大：发布/订阅模式将设备与服务器解耦，新增设备无需修改服务器代码，Broker可水平扩展。
- 指令需要实时推送：服务器通过订阅设备主题，可即时将控制指令推送给设备，无需设备反复轮询。
以一个智能温控器为例：温度传感器每5秒通过MQTT发布一次当前温度到 sensor/room1/temp 主题；云端服务订阅该主题，当温度超过28℃时，向 actuator/room1/ac 主题发布“开启空调”指令。整个过程设备与服务器之间保持一条轻量的TCP长连接，报文头部仅2字节，远小于HTTP动辄数百字节的头部开销。
# MQTT报文结构示意（固定头仅2字节）
| 控制报文类型(4bit) | 标志位(4bit) | 剩余长度(1-4字节) |
| 0x30 (PUBLISH) | 0x02 (QoS1) | 0x0A (10字节) |
# 实际发布内容（主题+负载）
Topic: sensor/room1/temp
Payload: {"temp": 26.5, "hum": 60}2.5 案例复盘：HTTP轮询为何失败
某初创团队最初使用HTTP协议实现智能花盆的远程浇水控制。设备每10秒向服务器发送一次GET请求，查询是否有浇水指令。初期设备量少（50台）时运行正常，但当设备增至500台后，服务器频繁收到无意义的轮询请求，响应延迟从200ms恶化到3秒，且设备无法感知服务器崩溃状态。
改用MQTT后，架构发生根本变化：
- 设备与Broker建立长连接，服务器通过
cmd/flower/001主题主动推送浇水指令，延迟降至毫秒级。 - 利用MQTT的遗嘱消息（LWT），设备异常掉线时Broker自动广播离线状态，运维人员可实时发现故障。
- 服务器负载降低80%，因为不再需要处理海量无效轮询请求。