4、设备接入协议：MQTT协议详解、CoAP协议、HTTP/HTTPS、Modbus TCP、OPC UA
设备接入，说白了就是让设备跟平台“对上话”。
我做了这么多年运维，见过太多项目死在协议选型上。选对了，事半功倍；选错了，后面全是坑。今天咱们就把这五个主流协议掰开揉碎了讲清楚。
4.1 MQTT协议详解
MQTT，全称Message Queuing Telemetry Transport，消息队列遥测传输。这玩意儿是IBM在1999年搞出来的，初衷是为了连接石油管道上的传感器。你想想看，那个年代的网络条件有多差，所以MQTT天生就是为“低带宽、高延迟、不可靠网络”设计的。
核心机制：发布/订阅模式
MQTT不是传统的客户端-服务器直连，而是引入了“代理”（Broker）的概念。设备（发布者）把数据扔给Broker，其他设备（订阅者）从Broker拿数据。发布者和订阅者完全解耦，谁都不认识谁。
为什么这很重要？
举个例子：你有一万个温度传感器，每个传感器都要把数据发给三个不同的监控系统。如果用传统HTTP，每个传感器得跟三个系统分别建连接，一万个传感器就是三万条连接。用MQTT，传感器只连Broker一次，Broker负责分发。网络开销直接降了一个数量级。
三个服务质量等级（QoS）
MQTT定义了三个等级，我建议你根据业务场景选：
| 等级 | 含义 | 适用场景 |
|---|---|---|
| QoS 0 | 最多发一次，丢了不管 | 环境温度、湿度等非关键数据 |
| QoS 1 | 至少发一次，可能重复 | 设备状态上报，允许少量重复 |
| QoS 2 | 恰好发一次，保证不丢不重 | 报警信号、控制指令 |
我的经验：别一上来就用QoS 2。QoS 2的握手开销是QoS 0的4倍以上。我见过有人把十万个传感器全设成QoS 2，结果Broker直接被打挂。一般场景QoS 1就够了，只有真正的关键指令才用QoS 2。
保留消息与遗嘱消息
这两个特性很实用。保留消息让新订阅者一上来就能拿到最新数据，不用等下一轮发布。遗嘱消息则是设备突然掉线时，Broker替它发一条“我挂了”的消息。嗯，这里要注意：遗嘱消息一定要设，否则设备死透了你还蒙在鼓里。
// MQTT连接示例（伪代码）
client = MQTT.connect("tcp://broker.example.com:1883", {
clientId: "sensor_001",
username: "device_user",
password: "secure_pass",
will: {
topic: "device/sensor_001/status",
payload: "offline",
qos: 1,
retain: true
}
});
client.subscribe("device/sensor_001/control", { qos: 1 });
client.publish("device/sensor_001/data", JSON.stringify(data), { qos: 1 });4.2 CoAP协议
CoAP，受限应用协议。说白了就是给那些“弱鸡”设备用的——内存只有几十KB，CPU跑不了TCP/IP协议栈。CoAP基于UDP，比MQTT更轻量。
CoAP vs MQTT
很多人问我：“到底选CoAP还是MQTT？”我的回答是：看设备能力。
- 设备资源充足（有操作系统、有TCP栈）：选MQTT，功能更丰富
- 设备极度受限（裸机、8位MCU）：选CoAP，它连TCP都省了
CoAP使用RESTful风格，跟HTTP很像，但走的是UDP。它有四种方法：GET、POST、PUT、DELETE。嗯，如果你懂HTTP，上手CoAP基本没难度。
注意：CoAP基于UDP，所以它自己实现了可靠传输机制——确认报文（ACK）和重传。但UDP天生不支持大包，CoAP报文最大也就1KB左右。如果你要传大文件，别用CoAP。
4.3 HTTP/HTTPS
HTTP，互联网的基石。在设备接入领域，HTTP的地位有点尴尬——它太重了。
为什么说HTTP重？
你想想看，一个HTTP请求头动不动就几百字节，而很多物联网设备一次上报的数据可能就几十字节。头比身子还大，这合理吗？
但HTTP也有不可替代的优势：
- 生态成熟：任何语言都有HTTP库，调试工具遍地都是
- 防火墙友好：80和443端口基本不会被封
- 安全：HTTPS的TLS加密是现成的
我个人习惯：对于非实时、低频次的数据上报，比如每天一次的日报数据，用HTTP完全没问题。但对于秒级甚至毫秒级的实时数据，别用HTTP，用MQTT。
避坑指南：我曾经见过一个项目，用HTTP做设备控制。设备每5秒轮询一次服务器，看有没有新指令。结果一万台设备上线后，服务器直接被轮询请求打爆。后来改成MQTT推送，服务器负载从90%降到了5%。
4.4 Modbus TCP
Modbus，工业界的“普通话”。1979年由Modicon公司发明，到现在还在广泛使用。Modbus TCP是Modbus的以太网版本，走TCP 502端口。
Modbus的通信模型
Modbus是主从架构。主站（通常是PLC或上位机）发起请求，从站（传感器、执行器）响应。一个主站可以带多个从站，从站地址范围1-247。
常用功能码
| 功能码 | 含义 | 操作 |
|---|---|---|
| 01 | 读取线圈状态 | 读DO |
| 02 | 读取离散输入 | 读DI |
| 03 | 读取保持寄存器 | 读AO |
| 04 | 读取输入寄存器 | 读AI |
| 05 | 写单个线圈 | 写DO |
| 06 | 写单个寄存器 | 写AO |
我的经验：Modbus TCP有个坑——它没有安全机制。数据是明文传输的，也没有身份认证。如果你把Modbus设备直接暴露在公网上，基本等于裸奔。我建议：Modbus设备只在内网使用，或者通过网关做协议转换和访问控制。
4.5 OPC UA
OPC UA，统一架构。这玩意儿是OPC基金会搞的，目标是取代老旧的OPC DA（基于COM/DCOM）。OPC UA不是简单的协议，它是一个完整的通信框架。
OPC UA的核心特性
- 面向服务架构：不是简单的读写，而是定义了发现、浏览、订阅、调用等一系列服务
- 信息模型：可以描述数据的语义，比如“这个温度值是摄氏度还是华氏度”
- 安全：内置了认证、加密、签名，比Modbus安全得多
- 跨平台：不依赖Windows，Linux也能跑
OPC UA vs Modbus TCP
很多人纠结这两个。我的看法是：
- 简单设备、低成本场景：用Modbus TCP，简单粗暴
- 复杂系统、需要语义互操作：用OPC UA，虽然重但功能强大
注意：OPC UA的学习曲线比Modbus陡得多。我刚开始接触时，光理解“地址空间”这个概念就花了两天。但一旦搞懂了，你会发现它真的很强大——尤其是当你需要把不同厂商的设备集成到一起时。
4.6 协议选型决策树
说了这么多，到底怎么选？我画了一张图，帮你理清思路：
这张图的核心逻辑很简单：先看设备类型，再看设备能力，最后看业务需求。没有最好的协议，只有最合适的协议。
最后说一句：协议选型不是一锤子买卖。我见过很多项目，一开始用Modbus TCP，后来系统复杂了，慢慢过渡到OPC UA。也见过先用HTTP快速上线，后期再切MQTT的。关键是——先跑起来，再优化。