4、OPC UA通信机制：二进制协议与UA TCP、HTTPS与WebSocket、安全信道与会话管理
好，咱们今天聊点硬核的。OPC UA 的通信机制，说白了就是它怎么把数据从设备里掏出来，再安全地送到你手里。我刚开始接触 OPC UA 时，也被这一堆协议搞晕过——又是二进制又是 HTTPS，还有 WebSocket 和什么安全信道。其实捋清楚了，就那么几件事。
4.1 二进制协议与UA TCP：这才是OPC UA的老本行
OPC UA 最早设计的通信方式，就是它自己的二进制协议，跑在 UA TCP 之上。你想想看，工业现场什么最重要？实时性、效率、低开销。XML 那种东西虽然人类可读，但太啰嗦了，一个数据包可能 90% 都是标签，真正有用的数据没多少。
二进制协议就不一样了。它把数据编码成紧凑的字节流，解析起来快得多。我在一个汽车焊装车间项目里遇到过，现场有 2000 多个变量要实时采集，如果用 XML 编码，带宽根本扛不住。换成二进制协议后，网络负载直接降了 70%。
UA TCP 是 OPC UA 自定义的传输层协议，默认端口 4840。它不像 HTTP 那样有那么多头信息，而是精简到极致。结构大概是这样的：
消息头（4字节）| 安全头（可变）| 序列号（4字节）| 请求ID（4字节）| 消息体（可变）嗯，这里要注意，UA TCP 不是标准 TCP，它是在 TCP 之上又封装了一层。我见过有人直接用 Socket 去连 OPC UA 服务器的 4840 端口，结果收到的全是乱码——因为你得按 UA TCP 的格式去组包和解包。
核心要点：二进制协议 + UA TCP 是 OPC UA 的默认通信方式，适合高实时、低延迟的工业场景。数据包小、解析快、开销低。
4.2 HTTPS与WebSocket：让OPC UA走出车间
但是问题来了——如果我想从云端或者手机 App 去访问 OPC UA 服务器呢？车间里的防火墙通常只开 80 和 443 端口，UA TCP 的 4840 端口根本出不去。这时候就需要 HTTPS 和 WebSocket 上场了。
HTTPS 方式说白了就是把 OPC UA 的二进制数据包，封装到 HTTP 的请求体里，走标准的 443 端口。防火墙一看是 HTTPS，直接就放行了。代价呢？性能会下降一些，毕竟多了 HTTP 的头开销。我个人习惯是：车间内部用 UA TCP，跨网络或上云时用 HTTPS。
WebSocket 则是另一种思路。它先通过 HTTP 握手建立连接，然后升级到 WebSocket 协议，之后就可以全双工地收发数据了。我去年做一个设备远程运维项目时，就用了 WebSocket 方式。客户要求从手机端实时查看设备状态，WebSocket 的推送能力比轮询强太多了。
| 通信方式 | 端口 | 适用场景 | 性能 |
|---|---|---|---|
| UA TCP（二进制） | 4840 | 车间内部、实时控制 | 最高 |
| HTTPS | 443 | 跨网络、云端访问 | 中等 |
| WebSocket | 443/80 | 实时推送、Web应用 | 较高 |
我的建议：别一上来就选 HTTPS。如果设备在同一个局域网内，用 UA TCP 最省事。只有当你需要穿越防火墙或者做 Web 应用时，才考虑 HTTPS 或 WebSocket。
4.3 安全信道：数据在线上是加密的
说到安全，OPC UA 的安全信道机制是我见过最严谨的之一。它不像有些协议那样，数据在线上是明文传输的——你抓个包就能看到所有数据。OPC UA 的安全信道，说白了就是客户端和服务器之间建立一条加密的隧道。
建立过程大致分三步：
- 打开安全信道：客户端发送一个 OpenSecureChannel 请求，里面包含自己支持的加密算法列表。
- 协商安全策略：服务器从列表里选一个双方都支持的算法，然后生成一个安全令牌（Security Token）。
- 加密通信：之后所有的数据都用这个令牌加密传输。令牌有过期时间，到期后需要重新协商。
我曾经在一个项目中踩过坑——安全令牌的过期时间设得太短了，结果客户端每隔几分钟就要重新协商一次，导致数据采集出现短暂中断。后来我把过期时间从 5 分钟改成了 1 小时，问题就解决了。嗯，这里要注意，过期时间不是越长越好，太长了会有安全风险，一般建议 30 分钟到 1 小时。
避坑指南：我曾经遇到过安全策略不匹配的问题。客户端只支持 Basic256Sha256，但服务器只配置了 Basic128Rsa15，结果连接一直失败。排查了半天才发现是安全策略没对上。所以配置时一定要确认两端的安全策略一致。
4.4 会话管理：谁在连、连多久、干什么
安全信道管的是「数据怎么加密传输」，而会话管理管的是「谁在连接、能干什么」。每个客户端在连接 OPC UA 服务器时，都需要创建一个会话（Session）。
会话里包含的信息有：
- 客户端身份信息（证书、用户名密码等）
- 会话超时时间（默认一般是 60 秒到 30 分钟）
- 已订阅的变量列表
- 当前的活动请求
你想想看，如果客户端突然断网了，服务器怎么知道这个会话还有没有用？靠的就是超时机制。如果超过超时时间没有收到客户端的任何消息，服务器就会自动关闭这个会话，释放资源。
我建议在生产环境中，把会话超时时间设得稍微长一点，比如 5 分钟。太短的话，网络稍微抖动一下就要重新创建会话，太频繁了。但也不能太长，否则僵尸会话会占着服务器资源不放。
还有一个细节——会话和安全信道是独立的。一个会话可以对应多个安全信道，一个安全信道也可以被多个会话复用。这就像是你去银行办事：安全信道是那条防弹玻璃后的通道，会话是你和柜员之间的业务关系。通道可以换，但业务关系还在。
总结一下：OPC UA 的通信机制，核心就是三件事——用什么协议传（二进制/HTTPS/WebSocket）、怎么加密传（安全信道）、谁来传以及传多久（会话管理）。搞懂了这三层，OPC UA 的通信你就拿下了大半。
好了，这一章的内容就到这儿。下一章咱们聊聊 OPC UA 的信息模型——说白了就是数据在服务器里是怎么组织的，怎么让机器和人都能看懂。