第2章：OPC UA 协议栈与架构

各位同学，咱们今天聊聊OPC UA的骨架——协议栈与架构。说实话，很多初学者一上来就被各种分层和协议搞懵了。我当年刚接触时也一样，觉得这东西怎么这么复杂？但干久了你会发现，这套设计其实非常巧妙。

2.1 通信架构：Client/Server 与 Pub/Sub

OPC UA支持两种通信模式，就像人有两条腿，缺一不可。

2.1.1 Client/Server 模式

这是最经典的模式。客户端发起请求，服务器响应。你想想看，就像你去餐厅点餐——你是客户端，厨师是服务器。

• 客户端：主动发起连接，读写数据，调用方法
• 服务器：等待连接，提供数据，执行命令

我在项目中遇到过这样一个坑：一个车间里同时有50个客户端轮询同一个服务器，结果服务器CPU直接飙到90%。后来我加了数据缓存和订阅机制，问题才解决。嗯，这里要注意——别让客户端太“贪婪”。

2.1.2 Pub/Sub 模式

Pub/Sub是后来加入的，说白了就是“广播模式”。发布者只管发消息，订阅者只管收消息，两者互不关心对方是谁。

我个人习惯把Pub/Sub用在数据量大的场景。比如一个工厂有上千个传感器，每个传感器每秒发一次数据。如果用Client/Server，服务器得累死。用Pub/Sub就轻松多了——传感器只管发，谁需要谁订阅。

2.2 协议栈分层

OPC UA的协议栈分四层。我刚开始学的时候，总觉得分层是多余的。直到有一次排查通信故障，才发现分层设计简直是救星。

层级	名称	主要职责
第4层	应用层	数据建模、服务接口
第3层	会话层	连接管理、安全协商
第2层	安全层	加密、签名、认证
第1层	传输层	数据收发、协议转换

2.2.1 传输层

这是最底层，负责把数据变成字节流发出去。OPC UA支持多种传输协议，我后面会细讲。

我记得有一次，客户说他们的OPC UA连不上。我排查了半天，发现是传输层的缓冲区设置太小。调大之后，问题立刻解决。所以啊，底层问题往往最隐蔽。

2.2.2 安全层

安全层负责加密和认证。说白了，就是防止别人偷看你的数据，或者冒充你的设备。

我曾经遇到一个客户，他们工厂的OPC UA服务器被黑客攻击了。原因很简单——没有启用安全层。从那以后，我建议所有项目至少启用签名和加密。

2.2.3 会话层

会话层管理连接的生命周期。建立连接、保持心跳、断开连接，都是它的活。

你想想看，如果设备突然断电了，会话层能检测到并释放资源。否则服务器上会留下一堆“僵尸连接”，慢慢把内存吃光。

2.2.4 应用层

应用层是离用户最近的一层。你写的代码、定义的数据模型，都在这一层。

我个人习惯把应用层想象成“翻译官”——它把业务逻辑翻译成OPC UA能理解的语言。比如你有一个温度传感器，应用层负责把“温度”这个变量映射成OPC UA的节点。

2.3 传输协议：UA TCP、HTTPS、MQTT

OPC UA支持三种传输协议。选哪个？看场景。

2.3.1 UA TCP

这是OPC UA的亲儿子，原生协议。性能最好，延迟最低。

• 优点：速度快，功能全，支持所有OPC UA特性
• 缺点：需要开放特定端口（4840），防火墙配置麻烦

我在项目中90%的情况都用UA TCP。特别是设备之间通信，延迟要求高，UA TCP是首选。

2.3.2 HTTPS

HTTPS就是HTTP加SSL。说白了，就是把OPC UA的数据包在HTTP里传。

为什么需要这个？因为很多企业的防火墙只开放80和443端口。UA TCP的4840端口被堵死了，怎么办？用HTTPS绕过去。

2.3.3 MQTT

MQTT是轻量级的发布/订阅协议。OPC UA Pub/Sub模式经常搭配MQTT使用。

我记得有个项目，客户要把数据传到云端。用UA TCP？不行，云平台不支持。用HTTPS？太慢了。最后选了MQTT，完美解决。

协议	适用场景	性能	防火墙友好
UA TCP	局域网、实时控制	高	差
HTTPS	跨网络、互联网	中	好
MQTT	云端、物联网	中高	好

嗯，总结一下。协议栈分层让你能快速定位问题，通信模式让你灵活选择架构，传输协议让你适应各种网络环境。这三者加在一起，就是OPC UA的骨架。

下一章，咱们聊聊数据建模——怎么把现实世界的设备变成OPC UA能理解的节点。到时候我会拿一个真实的PLC项目做例子，保证你一听就懂。