第三章 通信协议栈：OPC UA二进制协议、OPC UA UA-TCP协议、HTTPS协议、协议选择策略
各位工程师，咱们今天聊聊OPC UA的通信协议栈。说实话，这可能是整个课程里最容易被忽视、但坑最多的地方。我见过太多项目，选错了协议，最后性能死活上不去，还找不到原因。
OPC UA的协议栈，说白了就是数据怎么打包、怎么传输。它不像HTTP那样只有一种玩法。OPC UA给了你三种选择：二进制协议、UA-TCP协议、HTTPS协议。每种都有自己的脾气。
3.1 OPC UA二进制协议
这是我最常用的协议，也是性能最好的。为什么？因为它紧凑。
二进制协议把数据直接编码成字节流。没有多余的标签，没有冗余的头部。你想想看，一个温度值32.5，用二进制协议可能只占4个字节。换成JSON呢？至少得十几个字节。
核心特点：
- 编码效率极高，带宽利用率可达90%以上
- CPU开销小，解析速度快
- 支持所有OPC UA数据类型
- 适合实时控制场景
我记得有一次给一个钢铁厂做项目，现场有2000多个数据点，每秒要采集10次。一开始他们用的HTTPS，结果服务器CPU直接飙到80%。换成二进制协议后，CPU降到15%。差距就这么大。
我的建议：如果你的网络带宽有限，或者对实时性要求高，优先选二进制协议。特别是PLC到上位机这种场景，二进制协议几乎是唯一选择。
3.2 OPC UA UA-TCP协议
UA-TCP协议，很多人搞不清楚它和二进制协议的关系。其实很简单：UA-TCP是传输层协议，二进制协议是应用层编码方式。两者是搭档关系。
UA-TCP协议在TCP基础上加了一层自己的头部。这个头部包含了安全信息、序列号、确认机制等。说白了，它让OPC UA的通信更可靠、更安全。
| 特性 | UA-TCP | 原生TCP |
|---|---|---|
| 连接管理 | 支持会话恢复 | 不支持 |
| 安全机制 | 内置加密和认证 | 无 |
| 消息分片 | 自动处理大消息 | 需手动处理 |
| 心跳检测 | 支持 | 需额外实现 |
嗯，这里要注意一点：UA-TCP协议虽然功能强大，但头部开销比原生TCP大。每个消息会多出几十个字节。对于小数据包来说，这个开销占比不小。
避坑指南：我曾经遇到过一个项目，现场网络延迟很大，他们用了UA-TCP的默认配置，结果频繁超时重连。后来我把超时时间从5秒调到了15秒，问题就解决了。记住，UA-TCP的参数要根据实际网络环境调整。
3.3 HTTPS协议
HTTPS协议，说白了就是把OPC UA数据包塞进HTTP的body里，再用TLS加密。这样做的好处是兼容性好，能穿透大部分防火墙。
但代价也很明显——性能差。HTTP头部本身就大，再加上TLS握手，一个请求的延迟可能比二进制协议高10倍以上。
我个人习惯，只在两种情况下用HTTPS：
- 需要穿越企业防火墙，且IT部门不允许开其他端口
- 客户端是浏览器或移动设备，只能用HTTP
其他场景，我建议你慎重。特别是实时控制，HTTPS基本不靠谱。
性能对比（实测数据）：
- 二进制协议：延迟约0.5ms，吞吐量10000 msg/s
- UA-TCP：延迟约1ms，吞吐量8000 msg/s
- HTTPS：延迟约10ms，吞吐量2000 msg/s
数据来自我去年做的一个汽车生产线项目，仅供参考。
3.4 协议选择策略
讲了这么多，到底怎么选？我总结了一个简单的决策流程：
- 先看网络环境：内网还是外网？延迟多少？带宽多少？
- 再看实时性要求：是毫秒级还是秒级？
- 最后看客户端类型：是PLC、上位机，还是手机浏览器？
举个例子：
- PLC到上位机（内网，毫秒级）：二进制协议 + UA-TCP
- 上位机到云平台（外网，秒级）：HTTPS
- 移动端监控（外网，秒级）：HTTPS
- 边缘计算节点（内网，毫秒级）：二进制协议 + UA-TCP
我的经验：别在一棵树上吊死。很多项目其实是混合使用的。比如现场设备用二进制协议，网关转成HTTPS上云。这样既保证了实时性，又解决了穿透问题。
最后说一句，协议选择没有银弹。你想想看，每个项目都有自己的特点。我建议你在选型前，先做个简单的性能测试。花半天时间，跑几个场景，数据会告诉你答案。
好了，这一章就到这里。下一章咱们聊聊OPC UA的安全配置，那也是个容易踩坑的地方。