2、OPC UA通信架构：客户端/服务器模型、发布/订阅模型、OPC UA协议栈（二进制、HTTPS、MQTT）、安全模型（加密、签名、认证）
好，咱们正式开始聊OPC UA的通信架构。说实话，很多初学者一上来就被各种模型和协议搞晕了。我当年刚接触OPC UA时，也花了很长时间才理清这些概念之间的关系。今天我就用最直白的方式，把这些东西给你拆开揉碎了讲清楚。
2.1 客户端/服务器模型：最经典的通信方式
客户端/服务器模型，说白了就是「请求-响应」模式。客户端主动发请求，服务器被动响应。这和我们平时上网浏览网页的逻辑一模一样。
在OPC UA里，客户端通常是SCADA系统、MES系统或者上位机软件。服务器则是PLC、传感器、机器人这些现场设备。客户端发起连接，然后读取数据、写入参数、订阅变量变化。
核心特点：
- 客户端主动发起连接，服务器被动等待
- 通信是双向的，但请求必须由客户端发起
- 适合数据采集、参数配置、报警确认等场景
- 每个客户端需要维护一个独立的会话
我在项目中遇到过一个问题：当现场有上百个客户端同时连接一台OPC UA服务器时，服务器内存飙升得厉害。后来排查发现，每个会话都会占用独立的资源池。所以我的建议是——如果客户端数量超过50个，一定要考虑使用聚合网关或者发布/订阅模式来分担压力。
2.2 发布/订阅模型：更适合大规模数据分发
你想想看，如果现场有1000个传感器，每个传感器每秒产生10个数据点，用客户端/服务器模型会怎样？每个客户端都要轮询所有传感器，网络带宽和服务器CPU瞬间爆炸。
发布/订阅模型就是来解决这个问题的。发布者（通常是服务器）只管把数据扔到消息总线上，订阅者（客户端）按需取用。发布者和订阅者之间没有直接耦合，谁都不需要知道对方的存在。
| 对比项 | 客户端/服务器 | 发布/订阅 |
|---|---|---|
| 通信模式 | 请求-响应 | 事件驱动 |
| 耦合度 | 高耦合 | 低耦合 |
| 适用场景 | 小规模、实时交互 | 大规模、数据分发 |
| 网络开销 | 较高（轮询） | 较低（推送） |
| 扩展性 | 较差 | 优秀 |
嗯，这里要注意：OPC UA的发布/订阅模型并不是替代客户端/服务器，而是互补。我个人的习惯是——实时控制用客户端/服务器，数据采集和监控用发布/订阅。两者配合使用，效果最好。
2.3 OPC UA协议栈：三种传输方式
OPC UA支持三种底层传输协议，每种都有自己的脾气。我一个个说。
2.3.1 二进制协议（UA Binary）
这是OPC UA的「亲儿子」协议。效率最高、延迟最低、带宽占用最小。数据以二进制格式编码，解析速度极快。
我的经验：在工业现场，90%以上的场景我都推荐用二进制协议。尤其是PLC和控制器之间的通信，延迟可以控制在1ms以内。我曾经在一条汽车焊装线上做过测试，二进制协议比HTTPS快了将近10倍。
二进制协议的缺点也很明显——它需要特定的端口（默认4840），而且防火墙配置比较麻烦。很多IT部门的同事看到非标准端口就头疼。
2.3.2 HTTPS协议（UA HTTPS）
说白了就是把OPC UA的数据包封装在HTTPS里传输。这样做的好处是——防火墙友好、支持Web浏览器访问、可以利用现有的IT基础设施。
但代价也很明显：性能下降。HTTPS的握手开销、加密开销、HTTP头部开销，加起来让效率大打折扣。我建议只在跨网络、跨企业边界时使用HTTPS，比如工厂和云平台之间的通信。
2.3.3 MQTT协议（UA MQTT）
MQTT是物联网领域的老大哥了。OPC UA把MQTT作为发布/订阅模型的底层传输，简直是天作之合。
MQTT的优势在于：轻量级、支持QoS（服务质量等级）、支持遗嘱消息、支持保留消息。特别适合带宽有限、网络不稳定的场景。
避坑指南：我曾经在一个项目中，把OPC UA over MQTT用在了WiFi环境下的AGV小车上。结果发现，当AGV在AP之间切换时，MQTT连接会断开，而OPC UA的会话状态没有及时恢复，导致数据丢失。后来我加上了会话重建机制才解决。所以，用MQTT时一定要处理好断线重连和会话恢复的逻辑。
2.4 安全模型：加密、签名、认证
工业系统的安全，再怎么强调都不为过。OPC UA的安全模型设计得非常完善，我把它总结为「三层防护」。
2.4.1 第一层：认证（你是谁？）
认证就是验证通信双方的身份。OPC UA支持多种认证方式：
- 匿名认证：最简单，但最不安全。只建议在封闭的、可信的网络中使用。
- 用户名/密码认证：基础的安全措施。注意密码要定期更换，不要用默认密码。
- 证书认证：最推荐的方式。每个客户端和服务器都有自己的X.509证书，通过证书链验证身份。
我个人强烈建议在生产环境中使用证书认证。虽然配置起来麻烦一点，但安全性提升了好几个量级。
2.4.2 第二层：签名（数据是谁发的？）
签名保证数据在传输过程中没有被篡改。发送方用私钥对数据签名，接收方用公钥验证签名。
签名模式分为两种：
- Sign（仅签名）：数据以明文传输，但附带签名。适合对性能要求高、但需要防篡改的场景。
- SignAndEncrypt（签名并加密）：数据先签名再加密，既防篡改又防窃听。这是最安全的模式。
我的建议：除非你的网络环境绝对安全（比如同一台机柜内的设备通信），否则一律使用SignAndEncrypt模式。性能损失其实很小，现代CPU处理AES-256加密几乎感觉不到延迟。
2.4.3 第三层：加密（数据别人能看到吗？）
加密保证数据的机密性。OPC UA使用对称加密（AES）来加密数据，用非对称加密（RSA或ECC）来交换密钥。
加密算法的选择也很重要：
- AES-128：够用，性能好
- AES-256：更安全，但性能略低
- RSA-2048：目前的主流选择
- ECC P-256：更高效，但兼容性稍差
嗯，这里要提醒一下：加密算法不是越强越好。我曾经见过一个项目，为了追求「绝对安全」，用了AES-512（其实标准里没有这个），结果导致PLC的CPU负载飙升到90%，控制周期都乱了。选择合适的算法，平衡安全性和性能，才是正道。
2.5 三种安全模式的对比
| 安全模式 | 认证 | 签名 | 加密 | 性能影响 | 推荐场景 |
|---|---|---|---|---|---|
| None | 无 | 无 | 无 | 无 | 测试环境、封闭网络 |
| Sign | 有 | 有 | 无 | 低 | 内部网络、防篡改需求 |
| SignAndEncrypt | 有 | 有 | 有 | 中 | 生产环境、跨网络通信 |
最后总结一下：OPC UA的通信架构其实不复杂。客户端/服务器模型适合点对点的实时交互，发布/订阅模型适合大规模数据分发。协议栈方面，二进制协议是首选，HTTPS用于跨网络，MQTT用于物联网场景。安全方面，记住「认证、签名、加密」三层防护，生产环境至少用Sign模式。
下一章我会带大家动手搭建一个OPC UA客户端，从零开始连接服务器。到时候咱们再细聊代码层面的实现细节。