1、课程导论：为什么物联网需要专用协议？MQTT、CoAP、HTTP的诞生背景与核心定位
1.1 一个老工程师的困惑：HTTP 不够用吗？
我记得十年前刚接触物联网项目时，客户问我：“为什么不能用 HTTP？网页都能跑，传感器数据为什么不行？”
这个问题，其实问到了点子上。HTTP 确实强大，它撑起了整个互联网。但物联网场景，说白了，和“人上网”完全是两码事。
你想想看，一个温度传感器，每隔 10 秒上报一次 25.3℃。用 HTTP 的话，每次都要建立 TCP 连接、发送请求头、等待响应、再断开连接。光握手开销就占了数据包的 80% 以上。这在 PC 端无所谓，但在物联网设备上——嗯，这里要注意——电池电量、带宽、内存，样样都是命根子。
我在项目中遇到过最典型的例子：一批智能水表，用 HTTP 上报数据，结果电池寿命从设计的 5 年直接掉到 8 个月。后来换成 MQTT，同样的硬件，电池撑了 4 年半。这就是专用协议的价值。
1.2 物联网的“三座大山”：为什么通用协议扛不住
物联网设备面临的挑战，我总结为三个核心矛盾：
- 资源受限：很多设备只有几十 KB 内存、几 MHz 主频。跑个完整的 HTTP 服务器？想都别想。
- 网络不稳定：设备可能在地下室、在移动的车辆上、在信号盲区。断线重连是常态，不是异常。
- 海量连接：一个平台可能要同时管理几十万甚至上百万个设备。每个设备都维持长连接？传统架构直接崩溃。
HTTP 是为“人机交互”设计的。人发一个请求，服务器返回一个页面，然后连接就结束了。但物联网是“机机交互”——设备要持续上报数据，服务器要随时下发指令。这种模式，HTTP 从根上就不匹配。
核心观点：物联网需要的不是“更强的协议”，而是“更轻、更省、更适应机器对话”的协议。
3.3 三剑客的诞生背景：各怀绝技
那么，MQTT、CoAP、HTTP 这三兄弟，到底是怎么来的？
MQTT：为“带宽饥渴”而生
MQTT 诞生于 1999 年，最初是 IBM 用来监控石油管道的。你想，沙漠里的管道，卫星通信，带宽按比特算钱。所以 MQTT 的设计哲学就是：能省则省。
它的最小报文只有 2 个字节。对，你没看错，2 个字节就能完成一次数据发布。而且它采用“发布/订阅”模式，设备只管发数据，不用关心谁在收。这种解耦，在海量设备场景下简直是救命稻草。
我个人习惯把 MQTT 比作“物联网的微信群”——你发一条消息，所有订阅的人都能收到，而且你不需要知道他们是谁。
CoAP：UDP 世界的“轻量级 HTTP”
CoAP 是 IETF 在 2010 年左右推出的。它的定位很明确：在 UDP 上实现类似 HTTP 的 RESTful 交互。
为什么不用 TCP？因为很多物联网设备（比如基于 6LoWPAN 的传感器网络）根本跑不动 TCP 的拥塞控制和重传机制。UDP 虽然不可靠，但轻啊。CoAP 在应用层自己实现了可靠传输——通过“确认报文”和“重传”机制，既保留了 UDP 的轻量，又保证了可靠性。
我曾经在一个智能照明项目里用过 CoAP。每个灯泡就是一个 CoAP 服务器，手机 App 直接通过 CoAP 的 GET/PUT 方法控制灯泡开关。整个过程没有中间代理，延迟在 10 毫秒以内。如果用 HTTP，光 TLS 握手就要几百毫秒。
避坑指南：我曾经在 CoAP 项目里踩过一个坑——NAT 穿透。CoAP 默认用 UDP，很多企业防火墙会拦截 UDP 流量。后来我们加了 DTLS 和 NAT 穿透方案才解决。所以选 CoAP 前，一定要确认网络环境对 UDP 的支持情况。
HTTP：老大哥的“降维打击”
HTTP 诞生于 1991 年，最初是为了传输超文本文档。它太成功了，以至于后来什么都要往上靠。物联网早期，很多开发者直接用 HTTP RESTful API 来对接设备。
HTTP 的优势很明显：生态成熟、工具丰富、调试方便。你用 Postman 就能测试设备接口，用 curl 就能模拟请求。对于原型验证阶段，HTTP 绝对是效率最高的选择。
但它的劣势同样致命：报文臃肿、连接开销大、不支持推送。HTTP 1.1 虽然支持长连接，但本质上还是“请求-响应”模式。服务器想主动给设备发消息？要么设备轮询，要么用 WebSocket——但 WebSocket 又增加了复杂度。
所以我的建议是：原型阶段用 HTTP，量产阶段换 MQTT 或 CoAP。别在原型上花太多时间优化协议，先把业务跑通再说。
1.4 核心定位对比：一张表说清楚
| 维度 | MQTT | CoAP | HTTP |
|---|---|---|---|
| 传输层 | TCP | UDP | TCP |
| 通信模式 | 发布/订阅 | 请求/响应 + 观察 | 请求/响应 |
| 报文开销 | 极小（2字节起） | 小（4字节头） | 大（数百字节） |
| 适用场景 | 传感器数据上报、远程控制 | 资源受限设备、局域网控制 | 原型验证、管理接口 |
| 典型设备 | 智能电表、车联网终端 | 智能灯泡、传感器节点 | 网关、服务器 |
| QoS 支持 | 3 级（0/1/2） | 1 级（确认/非确认） | 无原生 QoS |
1.5 我的选型建议：别迷信，看场景
经常有年轻工程师问我：“哪个协议最好？”
我的回答永远是：没有最好的协议，只有最合适的协议。
如果你做的是智能家居，设备在同一个局域网内，控制延迟要求高——CoAP 是首选。
如果你做的是工业物联网，设备分布在全国各地，需要稳定可靠的数据上报——MQTT 是标配。
如果你只是做个 Demo，或者设备本身是 Linux 网关，资源充裕——HTTP 完全够用。
我见过最离谱的项目，是在一个 8 位单片机上跑 HTTP 服务器。结果呢？内存溢出，三天两头死机。后来换成 CoAP，稳如老狗。所以，选协议之前，先搞清楚你的硬件是什么水平。
重要提醒：不要为了“技术时髦”而选协议。MQTT 很火，但如果你只有几十个设备，而且都在内网，用 HTTP 反而更简单。技术选型的第一原则是：用最少的成本解决问题。
1.6 本章小结
这一章，我们聊了三个核心问题：
- 为什么 HTTP 在物联网场景下“水土不服”？——因为资源开销大、模式不匹配。
- MQTT、CoAP、HTTP 各自是怎么诞生的？——MQTT 为低带宽而生，CoAP 为 UDP 而生，HTTP 为互联网而生。
- 它们的核心定位是什么？——MQTT 适合海量设备数据上报，CoAP 适合资源受限设备控制，HTTP 适合原型和管理。
下一章，我们会深入 MQTT 的协议细节，看看那个 2 字节的报文到底是怎么设计的。到时候我会分享一个我在车联网项目里用 MQTT 踩过的坑——嗯，那个坑让我加了一周的班。
我们下章见。