一、物联网概述：从概念到落地
大家好，我是你们的老朋友。今天咱们正式开始《MQTT物联网从零到项目落地》的第一课。
说实话，每次开课讲物联网概述，我都挺感慨的。十年前我刚入行那会儿，物联网还是个新鲜词，很多人觉得就是「给设备连个网」。现在呢？智能家居、工业4.0、车联网...到处都是物联网的影子。
但不管怎么变，核心的东西没变。今天我就带大家把物联网的底裤扒开，看看它到底是个啥。
1.1 什么是物联网？
物联网，英文叫Internet of Things，简称IoT。说白了，就是把物理世界的东西（传感器、设备、家电）连到互联网上，让它们能说话、能干活。
我经常跟学员打比方：互联网是「人与人」的连接，物联网是「物与物」、「物与人」的连接。你想想看，你家的空调能根据室外温度自动调节，这就是物联网。
核心定义：物联网是通过信息传感设备，按约定协议，把任何物品与互联网连接起来，进行信息交换和通信，以实现智能化识别、定位、跟踪、监控和管理的一种网络。
嗯，这里要注意一点：物联网不是简单的「设备+网络」。它背后有一套完整的体系。我在做第一个物联网项目时，就犯过这个错——以为买个WiFi模块焊上去就完事了。结果呢？数据传上去了，但没法管理，设备掉线了也不知道。后来才明白，物联网是个系统工程。
1.2 物联网四层架构
物联网架构，我习惯把它分成四层。这四层就像盖房子，缺一层都不行。
| 层级 | 名称 | 核心作用 | 典型设备/技术 |
|---|---|---|---|
| 第1层 | 感知层 | 采集数据、执行指令 | 传感器、执行器、RFID、摄像头 |
| 第2层 | 网络层 | 传输数据 | WiFi、4G/5G、LoRa、NB-IoT |
| 第3层 | 平台层 | 存储、处理、管理 | 云服务器、MQTT Broker、数据库 |
| 第4层 | 应用层 | 呈现数据、业务逻辑 | 手机APP、Web界面、大屏 |
感知层：物联网的「五官」
这一层负责跟物理世界打交道。温度传感器、湿度传感器、烟雾报警器、电机...都属于感知层。
我记得有一次做冷链物流项目，客户要求监控冷藏车的温度。我们选了个DS18B20温度传感器，精度0.5°C，够用了。但安装时发现一个问题：传感器离货物太远，测的是车厢空气温度，不是货物温度。后来把传感器直接贴在货物包装上才解决。
避坑指南：感知层最容易出问题的是「数据不准」。我曾经遇到过传感器被太阳直射，温度读数比实际高了10°C。所以安装位置、防护措施，都得提前想好。
网络层：物联网的「神经」
数据采集上来，怎么传出去？这就是网络层的事。
网络层选择很多：
- 近距离：WiFi、蓝牙、Zigbee
- 远距离：4G/5G、LoRa、NB-IoT
- 有线：以太网、RS485
选哪种？看场景。我个人的习惯是：室内固定设备用WiFi，室外移动设备用4G，低功耗远距离用LoRa。没有万能方案，只有最合适的方案。
平台层：物联网的「大脑」
数据到了云端，谁来接？谁来存？谁来管？这就是平台层的工作。
平台层包括：
- MQTT Broker：负责消息的收发（比如EMQX、Mosquitto）
- 数据库：存历史数据（InfluxDB、MySQL）
- 规则引擎：处理业务逻辑（比如温度超限报警）
- 设备管理：管理设备注册、状态、OTA升级
这里我多说一句：很多人觉得平台层就是买个云服务器就完事了。其实不然。平台层的设计决定了你的系统能支撑多少设备、数据延迟多高、运维成本多大。我见过一个项目，设备量从1000涨到10000，平台直接崩了，就是因为当初没考虑扩展性。
应用层：物联网的「脸面」
最后，数据要呈现给用户。手机APP、Web后台、大屏展示，都属于应用层。
应用层要解决的是「用户体验」。数据再准，界面难用，用户照样不买账。我建议做应用层时，多想想用户真正关心什么。比如一个温度监控系统，用户最关心的是「现在温度多少」「有没有异常」，而不是「数据是怎么传输的」。
1.3 常见通信协议对比
物联网通信协议，市面上少说有几十种。但真正用得多的，就三个：MQTT、CoAP、HTTP。
咱们来对比一下：
| 特性 | MQTT | CoAP | HTTP |
|---|---|---|---|
| 传输协议 | TCP | UDP | TCP |
| 消息模型 | 发布/订阅 | 请求/响应 | 请求/响应 |
| 开销 | 低（2字节最小头） | 极低（4字节） | 高（请求头大） |
| 可靠性 | 3个QoS等级 | 确认/重传 | 依赖TCP |
| 适用场景 | 传感器、控制、实时 | 资源受限设备 | Web、API |
| 典型端口 | 1883/8883 | 5683/5684 | 80/443 |
MQTT：物联网的「老大哥」
MQTT是我最常用的协议。为什么？因为它专为物联网而生。
MQTT的特点：
- 发布/订阅模式：一个设备发消息，多个设备能同时收到。这在控制场景特别有用。
- QoS机制：你可以选择消息要不要确认、要不要保证到达。省电还是可靠，你说了算。
- 心跳保活：设备断线了，Broker能知道，自动清理。
- 遗嘱消息：设备突然掉线，可以发一条「我挂了」的消息。
我做过一个项目，用MQTT控制工厂里的2000多个阀门。每个阀门每5秒上报一次状态，控制指令延迟不超过200ms。MQTT的QoS 1配合心跳机制，完美解决了「设备掉线不知道」的问题。
我的建议：如果你刚开始做物联网，选MQTT准没错。它生态成熟、资料多、坑少。等你有经验了，再根据场景选别的协议。
CoAP：轻量级选手
CoAP基于UDP，开销比MQTT还小。它适合那些资源极度受限的设备——比如电池供电、内存只有几十KB的传感器。
CoAP的特点：
- 基于UDP，没有TCP的三次握手，省电
- 支持观察模式（类似订阅）
- 支持RESTful风格，跟HTTP类似
但CoAP也有缺点：它不太适合控制场景。因为UDP不可靠，虽然CoAP有确认机制，但延迟和丢包率比TCP高。我在项目中很少用CoAP，除非客户明确要求低功耗到极致。
HTTP：老牌选手
HTTP大家都熟。但它真的不适合物联网。
为什么？
- 开销大：一个HTTP请求头可能几百字节，传感器传个温度值才4字节，浪费
- 请求/响应模式：服务器不能主动推数据，只能设备轮询。设备多了，服务器扛不住
- 无状态：每次请求都要重新建立连接，不适合长连接场景
不过HTTP也不是一无是处。在设备配置页面、固件下载、API接口这些场景，HTTP还是很好用的。我一般把HTTP用在「人机交互」环节，把MQTT用在「设备通信」环节。
1.4 怎么选？
说了这么多，到底怎么选？我给大家一个简单的判断标准：
- 设备资源充足、需要实时控制：选MQTT
- 设备资源极度受限、只上报数据：选CoAP
- 需要Web API、配置页面：选HTTP
- 混合场景：MQTT + HTTP组合使用
我个人习惯是：80%的场景用MQTT，15%用HTTP，5%用CoAP。这个比例供你参考。
警告：不要为了「技术炫酷」选协议。我见过有人用CoAP做智能家居控制，结果设备经常收不到指令，用户投诉不断。选协议，先看场景，再看资源，最后看团队熟悉程度。
1.5 小结
今天咱们聊了物联网的定义、四层架构、三大协议。这些都是基础中的基础，但也是最重要的。
物联网不是简单的「设备+云」，它是一个系统工程。感知层负责采集，网络层负责传输，平台层负责处理，应用层负责呈现。每一层都有坑，每一层都需要认真设计。
下一章，咱们会深入MQTT协议，从报文结构到会话机制，手把手带你吃透它。到时候我会分享一些我在项目中踩过的坑，保证让你少走弯路。
好了，今天就到这儿。有什么问题，欢迎在评论区留言。咱们下章见！
公众号：蓝海资料掘金营，微信 deep3321