一、物联网与MQTT协议概述
1.1 物联网基础概念
物联网，说白了就是让物理世界里的设备能上网、能说话。我刚开始接触这个领域时，觉得它就是个「传感器+网络」的简单组合。后来踩过不少坑才明白——真正的难点在于设备之间的通信。
一个典型的物联网系统，通常包含这几层：
- 感知层：传感器、执行器，负责采集数据或执行动作
- 网络层：Wi-Fi、NB-IoT、LoRa、4G/5G，负责数据传输
- 平台层：云平台或边缘服务器，负责数据处理和存储
- 应用层：手机App、Web界面，负责展示和控制
你想想看，一个温度传感器每隔几秒上报一次数据，如果每次都走HTTP请求，那网络开销得多大？这就是MQTT诞生的原因之一。
核心观点：物联网的本质不是「连上网」，而是「低成本、低功耗、高可靠地连上网」。
1.2 MQTT协议诞生背景
MQTT全称是Message Queuing Telemetry Transport，消息队列遥测传输。1999年由IBM的Andy Stanford-Clark和Arcom的Arlen Nipper共同发明。
我记得当时他们面临一个实际问题：如何用极低的带宽，把石油管道的传感器数据传回控制中心？那时候网络条件很差，带宽可能只有几十kbps，而且经常断线。传统的HTTP协议在这种环境下根本跑不动。
所以MQTT的设计目标很明确：
- 轻量级：最小报文只有2个字节
- 低带宽：适合窄带网络
- 支持不可靠网络：断线重连、消息持久化
- 一对多通信：发布/订阅模式
说白了，MQTT就是为「资源受限、网络不稳定」的场景量身定做的。我在做智能水表项目时，设备用2G网络上报数据，一个月流量费才几毛钱，用的就是MQTT。
1.3 MQTT vs HTTP / CoAP
很多初学者会问：为什么不用HTTP？我直接说结论——HTTP太重了。
| 对比项 | MQTT | HTTP | CoAP |
|---|---|---|---|
| 协议模型 | 发布/订阅 | 请求/响应 | 请求/响应 |
| 报文开销 | 2字节起 | 几百字节起 | 4字节起 |
| 传输层 | TCP | TCP | UDP |
| 实时性 | 高（推送） | 低（轮询） | 中 |
| 适用场景 | 传感器、控制 | Web、API | 低功耗设备 |
举个例子：一个温度传感器每10秒上报一次数据。用HTTP的话，每次都要建立TCP连接、发送请求头、等待响应。而MQTT只需要建立一次连接，后续数据直接推送。我做过实测，同样1000条数据，MQTT的流量只有HTTP的1/10左右。
至于CoAP，它基于UDP，比MQTT更轻量，但可靠性差一些。我个人习惯是：如果设备资源极度受限（比如8位单片机），选CoAP；如果设备有TCP协议栈，优先选MQTT。
避坑指南：我曾经在一个项目中用HTTP做设备数据上报，结果设备数量一多，服务器压力巨大，而且设备端功耗也高。后来换成MQTT，问题迎刃而解。所以选协议时，一定要考虑规模化后的成本。
1.4 MQTT 5.0新特性简介
MQTT 3.1.1用了很多年，直到2019年才推出5.0版本。嗯，这里要注意，5.0不是简单的升级，而是对很多痛点做了改进。
我挑几个最实用的新特性说说：
- 会话过期：可以设置会话的存活时间，避免僵尸会话占用服务器资源。以前做项目时，设备断线后会话一直保留，服务器内存越涨越高，现在终于有解了。
- 用户属性：可以在报文中携带自定义键值对，比如设备版本号、固件信息。以前这些信息得放在Topic里，又长又乱。
- 原因码：连接失败或订阅失败时，服务器会返回具体原因。比如「用户名密码错误」还是「权限不足」，调试起来方便多了。
- 共享订阅：多个订阅者可以共享同一个Topic，实现负载均衡。这在微服务架构中特别有用。
- 消息过期：可以设置消息的有效期，过期自动丢弃。比如传感器数据，5秒前的温度值已经没有意义了。
我的建议：如果你现在开始做新项目，直接上MQTT 5.0。虽然有些老Broker不支持，但主流平台（如EMQX、Mosquitto 2.0+）都已经兼容了。向后兼容性做得不错，不用担心。
1.5 小结
这一章我们聊了物联网的基本架构，MQTT的诞生背景，以及它和HTTP、CoAP的对比。最后简单介绍了MQTT 5.0的几个新特性。
说白了，MQTT就是物联网时代的「通用语言」。你想想看，从几块钱的传感器到几十万的工业设备，都能用同一套协议通信，这就是它的价值所在。
下一章，我们会深入MQTT的协议细节，包括报文结构、QoS等级、Topic设计等。到时候我会结合自己踩过的坑，给你一些实战建议。
注意：MQTT虽然简单，但坑也不少。比如Topic设计不合理、QoS选择错误、遗嘱消息没用好，都可能导致线上事故。后面几章我会逐一拆解。