2. 主流协议解析：从Modbus到OPC UA

各位同学，今天我们来啃硬骨头——工业通信协议。说实话，这四种协议我几乎每天都在打交道。Modbus、MQTT、HTTP/HTTPS、OPC UA，它们各有各的脾气。你想想看，一个老旧的PLC可能只认Modbus RTU，而云端平台却只吃MQTT。怎么让它们对话？这就是我们要解决的问题。

2.1 Modbus协议详解（RTU/TCP）

Modbus，工业界的"普通话"。1979年由Modicon公司提出，到现在还在大量使用。为什么？因为它简单、可靠、成本低。我在一个水处理项目中见过，一套系统跑了15年，Modbus通信从来没出过问题。

2.1.1 Modbus RTU vs Modbus TCP

特性	Modbus RTU	Modbus TCP
物理层	RS-232/RS-485	以太网
传输方式	串行，半双工	TCP/IP，全双工
报文格式	地址+功能码+数据+CRC	MBAP头+功能码+数据
最大节点数	32（RS-485）	理论无限制
典型距离	1200米	100米（交换机级联可扩展）
应用场景	现场设备、传感器	上位机、SCADA

我个人习惯，现场总线用RTU，上位机通信用TCP。为什么？RTU在强电磁干扰环境下更稳定，而TCP方便集成到现有网络。

2.1.2 Modbus报文结构

Modbus RTU的报文，说白了就是"谁找我、找我干啥、数据是啥、对不对"。看个例子：

// 读取保持寄存器（功能码0x03）
// 请求：从站地址1，读取地址0x0000开始的2个寄存器
请求报文：01 03 00 00 00 02 C4 0B
// 01 - 从站地址
// 03 - 功能码（读保持寄存器）
// 00 00 - 起始地址
// 00 02 - 寄存器数量
// C4 0B - CRC校验

// 响应报文：01 03 04 00 0A 00 14 7A 1E
// 01 - 从站地址
// 03 - 功能码
// 04 - 数据字节数（2个寄存器=4字节）
// 00 0A - 寄存器1的值（10）
// 00 14 - 寄存器2的值（20）
// 7A 1E - CRC校验

2.1.3 Modbus TCP的MBAP头

Modbus TCP去掉了CRC，加了个MBAP头。为什么？因为TCP/IP协议栈已经保证了数据完整性。MBAP头包含事务标识符、协议标识符、长度和单元标识符。

// Modbus TCP报文结构
// MBAP头（7字节）+ 功能码 + 数据
// 事务标识符（2字节）：用于匹配请求和响应
// 协议标识符（2字节）：固定为0x0000
// 长度（2字节）：后续字节数
// 单元标识符（1字节）：类似RTU的从站地址

// 示例：读取保持寄存器
请求：00 01 00 00 00 06 01 03 00 00 00 02
// 00 01 - 事务标识符
// 00 00 - 协议标识符
// 00 06 - 长度（后续6字节）
// 01 - 单元标识符
// 03 - 功能码
// 00 00 - 起始地址
// 00 02 - 寄存器数量

2.2 MQTT协议详解（发布/订阅模型）

MQTT，物联网的"信使"。它不像Modbus那样一问一答，而是采用发布/订阅模型。你想想看，如果1000个传感器同时问服务器"有没有新数据"，服务器不得累死？MQTT的做法是：传感器只管发，谁感兴趣谁订阅。

2.2.1 发布/订阅模型

MQTT有三个角色：发布者、订阅者、代理（Broker）。发布者把消息发到某个主题，订阅者订阅这个主题，代理负责转发。我在一个智慧工厂项目中，用MQTT连接了2000多个传感器，Broker跑在一台树莓派上，稳得很。

2.2.2 MQTT的QoS等级

MQTT有三个服务质量等级。嗯，这里要注意，不是所有场景都需要最高等级。我见过有人把所有消息都设成QoS 2，结果网络拥堵得一塌糊涂。

QoS等级	含义	适用场景
0	最多发一次，不确认	温度传感器（丢一帧无所谓）
1	至少发一次，有确认	状态告警（允许重复）
2	恰好发一次，四次握手	控制指令（不能重复执行）

2.2.3 MQTT报文示例

// 发布消息到主题 "sensor/temperature"
// 主题：sensor/temperature
// 消息：{"value": 25.6, "unit": "celsius"}
// QoS：1

// 报文结构（简化）：
// 固定头：0x32 (发布+QoS1)
// 可变头：主题长度+主题+报文标识符
// 载荷：JSON数据

// 订阅主题 "sensor/#"
// 固定头：0x82 (订阅)
// 可变头：报文标识符
// 载荷：主题过滤器+QoS

2.3 HTTP/HTTPS协议基础

HTTP，互联网的基石。你可能每天都在用，但真的理解它吗？说白了，HTTP就是客户端和服务端之间的一种"对话规则"。你问一句，它答一句。HTTPS就是在外面套了一层TLS加密。

2.3.1 HTTP请求方法

方法	含义	幂等性
GET	获取资源	是
POST	创建资源	否
PUT	更新资源（全量）	是
PATCH	更新资源（部分）	否
DELETE	删除资源	是

我个人习惯，查询用GET，新增用POST，更新用PUT。但要注意，GET请求的参数会暴露在URL里，敏感信息必须用POST。

2.3.2 HTTPS的握手过程

HTTPS的TLS握手，我刚开始学的时候觉得特别复杂。后来总结成三步：打招呼、验身份、商量密钥。看个简化版：

// TLS 1.3 简化握手
// 1. Client Hello：客户端打招呼，说"我支持这些加密套件"
// 2. Server Hello：服务端回应，说"我们用这个套件"
// 3. 证书交换：服务端发证书，客户端验证
// 4. 密钥交换：双方用ECDHE协商会话密钥
// 5. 加密通信：之后所有数据都用会话密钥加密

2.4 OPC UA协议简介

OPC UA，工业4.0的"通用翻译器"。它不像Modbus那样只传原始数据，而是把数据、类型、方法、历史信息都封装在一起。说白了，OPC UA不只是协议，更是一个信息模型。

2.4.1 OPC UA的核心概念

• 地址空间：所有数据都组织成节点，形成树状结构
• 对象：代表现实世界的设备或系统
• 变量：代表对象的属性（如温度值）
• 方法：代表对象可执行的操作（如启动设备）
• 订阅：客户端可以订阅数据变化，不用轮询

2.4.2 OPC UA vs Modbus

特性	OPC UA	Modbus
数据模型	面向对象，丰富语义	寄存器/线圈，无语义
安全性	内置加密、认证、审计	无安全机制
传输方式	TCP/HTTPS/UA Binary	RTU/TCP
复杂度	高，学习曲线陡	低，上手快
适用场景	企业级集成、MES/ERP	现场设备、传感器

2.4.3 OPC UA的通信模式

OPC UA支持两种通信模式：客户端-服务器和发布-订阅。客户端-服务器模式适合点对点通信，发布-订阅模式适合一对多场景。嗯，这个设计思路和MQTT有点像，但OPC UA的发布-订阅是基于UDP的，延迟更低。

// OPC UA客户端连接示例（伪代码）
// 1. 创建客户端
Client client = new Client();
client.setEndpoint("opc.tcp://192.168.1.100:4840");

// 2. 建立安全通道
client.connect();
client.authenticate("username", "password");

// 3. 浏览地址空间
Node root = client.browse("Objects");
Node motor = root.getChild("Motor1");
Variable temperature = motor.getVariable("Temperature");

// 4. 读取数据
double value = temperature.readValue();
System.out.println("Motor1温度: " + value);

// 5. 订阅变化
temperature.subscribe(1000, (v) -> {
    System.out.println("温度变化: " + v);
});