3.1 协议栈与传输
3.1 协议栈与传输
本节摘要：OPC UA 不是单一协议而是一叠分层——编码、安全、传输绑定各自可换。理解这套分层结构，你就能看懂为什么同一台服务器既能跑在工控机的专用端口上又能钻进消息队列，也能判断自己的项目该选哪种形态。
为什么传个数据要叠这么多层
Modbus 一帧报文八个字节就把事办了，OPC UA 读一个值却要经过编码、加密、会话好几道工序，有人因此断言它"重得没法用"。这个判断错在哪？错在把两套协议当成了同类竞争品。Modbus 的八字节之所以够用，是因为它把"谁在说话、说的是什么意思、谁有权说话"全都甩给了链路环境和点表文档；OPC UA 的每一道工序都在回答其中一个问题：编码层管"字节怎么排布"，安全层管"你是谁、窃听者看得到什么"，会话层管"这个连接属于哪个客户、状态保持多久"。层次多不是冗余，是把原本甩给外部的责任收编进协议。本节就把这叠层次拆开看。
学习目标
阅读完本节，你应当能够：
- 说出 OPC UA 协议栈各层的职责与可替换性；
- 区分二进制、Web 服务、消息队列三类传输绑定的适用场景；
- 为给定部署环境选择合适的形态并说明理由；
- 解释反向连接与证书交换在部署里解决什么问题。
一、自下而上过一遍分层
传输绑定层回答"字节用什么方式搬"。最经典的是二进制流绑定，客户端与服务器建立长连接，帧短、效率高，适合厂内稳定网络；Web 服务绑定用通用 Web 技术承载，兼容性好但开销大，如今多用于偶尔访问的管理场景；消息队列绑定则把数据变成发布出去的消息，服务器不关心谁在听，适合一对多的广播与弱网环境。三个绑定承载的服务集不同：前两者支持完整服务，发布订阅绑定只覆盖数据类服务——这是部署时最常见的认知差。
安全策略层回答"通道怎么保护"。它定义了证书怎么验证、报文是否加密、完整性用什么算法保证。策略是可协商的：厂内可信网络可以选不加密的快速策略，跨网段与跨组织则必须选带证书与加密的完整策略。第 5 章的安全机制讨论就建立在这一层之上，本节只需记住"安全是层，不是开关"。
编码层回答"数据结构怎么变成字节"。同一棵地址空间可以用紧凑的二进制编码，也可以用文本编码——前者快，后者便于调试观察。编码选择与传输绑定有对应关系，二进制流绑定天然搭配二进制编码。
会话与服务层在最上面，回答"业务怎么做"。建立会话、浏览地址空间、读写、订阅、调用方法，全部定义在这一层。会话与底层连接是解耦的：网络闪断后连接重建，会话可以激活恢复，客户端无感知地继续用——这个特性对长时运行的监控系统价值极大，也是 1.2 反例里"广域链路上会话重建成为负担"的另一面：能力在，代价也在。
图10 OPC UA 协议栈分层与两条典型通道
二、部署形态怎么选
给部署决策三个典型情形。**情形一，厂内 SCADA 采集。**二进制长连接是默认答案：链路稳、频率高、延迟敏感，长连接摊薄了握手成本。证书策略按厂内安全规范定，至少上签名。**情形二，数据上云。**云端消费者多且网络路径不可控，消息队列绑定更合适：服务器把数据发布到消息中间件，云端各应用各自订阅，断网恢复后从断点续传策略里找补。**情形三，跨组织点对点集成。**两家企业的系统直接对接，用带完整证书链的二进制或 Web 绑定，安全策略必须全套——对方网络的任何一段都不在你掌控之内。
三个情形之外的混合形态越来越常见：一台边缘网关对下用二进制长连接服务厂内 SCADA，对上用消息队列发布到云，这正是第 4 章网关架构的通信基础。
三、连接建立的完整序列
把一次二进制长连接的建立过程走一遍，你会对"分层"有具体的手感。客户端先与服务器完成传输层握手，交换各自支持的协议版本与端点配置；接着进入安全握手——交换证书、验证对方身份、协商出会话密钥，此后所有报文加密封装；然后客户端申请创建会话，服务器返回会话标识与超时参数，客户端再激活会话完成绑定。三步之后才有第一笔业务读写。
这个序列解释了两个现场现象。其一，首次连接慢是正常的：证书验证与密钥协商的开销集中在建连阶段，之后的长连接享受成果，所以监控系统启动时那几十秒的"连接中"不是卡死。其二，时钟不同步会握手失败：证书有效期校验依赖双方系统时间，时间差得离谱时，服务器会以"证书尚未生效"拒绝连接——现场偶发的"服务器明明开着却连不上"，查一下 NTP 往往就结案了。
⚠️ 常见坑：把服务器的网络端口当成"开个防火墙就行"。安全策略选择、证书信任链、应用 URI 匹配，任何一环不配套，端口通了连接照样被拒。部署问题按分层逐层排查，比在防火墙上一条条加规则高效得多。
四、性能账与两类常见误配
部署形态定了，性能预期要算清。二进制长连接的单次往返在厂内网络典型为毫秒级，其中真正的协议处理占比很小，大头在网络转发与加密运算——启用加密后往返耗时上浮三到五成是正常账，把这笔账算进采集周期预算，而不是等上线后再懊恼。订阅推送的每包开销同样要算：发布间隔压到百毫秒以下时，报文数量与加密运算量按比例上涨，低配网关的 CPU 很容易被打满——3.3 的参数分级在这里找到了性能层面的根据。
两类常见误配值得点名。其一，加密策略两端不一致的"半吊子配置"：服务器只启用加密策略，客户端按文档示例配了不加密策略，连接永远失败还报不出像样的错误——按 3.1 末尾的分层诊断走，这类问题五分钟可解，但不知分层的人能耗一整天。其二，把消息队列绑定当普通连接用：有的团队图省事，让所有客户端都从消息中间件拿数据，包括那些需要写控制命令的——发布订阅绑定不承载全部服务，写命令走不了这条路，设计时要把"读走消息、写走直连"的双通道结构明确画进架构图。
性能与误配两类问题合起来的提醒是：**部署形态不是"装上就完"的选择题，而是一笔要算的账加一张要守的图。**账算在上线前，图画在评审时。
五、排障视角：分层就是逐层举证
分层不只是设计图，更是排障时的举证顺序。链路不通，自下而上问：物理层链路灯亮吗？传输层握手完成了吗？会话层建立了吗？安全层放行了吗？每层拿到"通过"的证据再往上走，禁止跳层猜测——"先重装试试"之所以是坏习惯，就是它同时抹掉了所有层的证据。性能问题则反过来自上而下问：服务层等待（超时配错）、传输层拥塞（缓冲配小）、物理层重传（线缆老化），同一套分层两个方向各有一套举证清单。
把这套顺序与 2.4 的抓包功夫衔接：字节级证据在每一层都有对应形态，逐层取证、逐层排除，结论才立得住。顺带一提，分层举证也解释了为什么日志要带层标签——没有层字段的日志，举证时得靠人肉重建层次，效率差一个量级。6.3 的多条症状，最后都要回到这里取证据。
本节要点回顾
- 分层是责任收编：编码管排布、安全管信任、绑定管搬运、会话管状态，各层可独立替换；
- 三种绑定三种场景：厂内长连接、跨组织点对点、上云广播，形态由网络与消费方决定；
- 建连三步：传输握手、安全握手、会话激活，首次连接的耗时集中在证书与密钥环节；
- 时钟影响握手：证书有效期校验依赖系统时间，"连不上"清单里要有对时这一条。
通道铺好了，下一节看通道里跑的是什么：一棵会自己介绍自己的地址空间树。