简介IEC 62439-3:2016 第3.0版英文原版标准全文面向工业通信、电力自动化、轨道交通等领域的网络设计与测试工程师及高校研究者重点解决高可靠网络中单点故障引发通信中断的问题。文档系统规定了平行冗余协议PRP与高可用性无缝冗余HSR的帧结构、冗余实体、网络拓扑、配置与诊断方法并给出与其他工业通信协议的集成要点及测试验证流程可用于设备选型、方案评审与标准符合性自查。压缩包内仅 1 个 PDF 文件约 6.65MB共 358 页含目录、图表与英法双语标题页便于按章节检索定位具体条款已有 393 人学习下载。读者可据此掌握 PRP 双路径零切换与 HSR 双环无缝转发的完整规范原文厘清 DANP、RedBox、SAN 等节点角色的定义与部署差异并借助标准中的诊断与测试条款搭建验证用例为产品研发和现场故障分析提供权威依据。1. 零切换的真实含义系统里根本没有“切换”这个动作工业现场对“恢复时间”的容忍度和办公网络不是一个量级。办公网断五十毫秒用户只觉得卡了一下一条运动控制指令晚到十毫秒机械臂可能已经撞上夹具。常规思路是把切换做快各类环网冗余机制都在压缩这个数字压到毫秒级已经是大量工程实践反复摸索出来的极限。PRP 和 HSR 在 IEC 62439-3 第三版里给出的却是另一个答案不做切换。同一份数据被复制成两份沿两条互不相干的路径同时出发接收端只把先到的那份交给上层另一份按重复帧丢掉。所谓零恢复时间其实是系统里压根没有“恢复”这个动作。这套机制值得深入研究的点在于它把可靠性问题从“协议收敛得快不快”换成了“带宽和布线愿不愿意付”本质上是一次彻底的成本置换。2. PRP 的机制两份数据同时上路接收端凭什么只交一份给应用PRP 最容易被误解的地方是很多人以为它做了一个“主备切换”的加速版。实际情况恰恰相反它压根没有主备的概念两条 LAN 从开机那一刻起就是平权的每一帧都同时在两条路上跑。标准第 4 章把这件事拆成了几个互相咬合的部件——节点结构、尾部控制信息、重复判定表、监管帧少一个都转不起来。2.1 DANP 的两个端口为什么共用一个 MACPRP 里的核心角色叫 DANP双连接节点。它有两个独立的以太网口分别接到 LAN A 和 LAN B但这两个口对外呈现的是同一个 MAC 地址。这一点经常让刚接触的人困惑同一个 MAC 出现在两个网段里不会冲突吗不会因为 PRP 有一条硬性前提——LAN A 和 LAN B 必须在物理上和逻辑上完全独立中间不允许有任何桥接路径。两条 LAN 是两个平行世界同一个 MAC 各在自己世界里活动互不知情。共用一个 MAC 是精心设计的结果不是偷懒。上层应用只看到一张网卡、一个 IP、一个协议栈收发包的代码一行都不用改。如果两个端口用不同 MAC应用层就要处理“我从哪个身份发出去”“对端看到的是哪个我”这类问题PRP 对上层透明这个最大卖点就没了。换句话说PRP 把冗余全部藏在链路层以下用“两个物理口伪装成一个逻辑口”的手法把复杂性关进了网卡和交换芯片里。代价也随之而来两个 LAN 的带宽必须各自按全流量规划。因为每一帧都要走两遍LAN A 上跑多少流量LAN B 上就得有多少余量。这条约束在后面选型时会反复出现。2.2 尾部 6 字节冗余信息为什么不能放在帧头PRP 给每个复制出来的帧追加 6 字节的冗余控制信息业内常叫 RCT。它固定挂在帧尾位置很关键。字段长度作用LSDU size2 字节原始负载长度接收端据此剥离尾部填充Sequence number2 字节同一源发出的帧递增计数重复判定的主键LAN ID / Path2 字节标识这一份是从哪条 LAN 发出的放帧尾而不是帧头是整个协议里最见功力的一处取舍。PRP 网络里不可能只有双连接设备一定还挂着一堆普通的单网口设备——PLC、仪表、老式交换机。这些设备不认识任何冗余信息它们只会按标准以太网规则转发。如果把冗余字段插在帧头普通交换机会把它当成负载的一部分或者因为解析错位直接把帧丢掉更糟的是改动了帧头结构某些设备的安全策略会判定为异常帧。挂在帧尾就完全不一样了。普通交换机看帧头目的 MAC、源 MAC、类型字段全都原封不动转发行为和一个普通数据帧没有任何区别RCT 只是“多出来的一点尾巴”跟着帧一起被搬到对面。只有真正的 DANP 收到帧之后才会去读最后 6 个字节判断这是不是重复帧然后剥掉尾巴把干净的负载交给上层。LSDU size 这个字段存在的理由也很实在。以太网有 64 字节最小帧的限制短帧必须填充到 64 字节接收端如果只看帧长根本分不清哪部分是业务数据、哪部分是填充。所以发送方在 RCT 里写死原始长度接收方按这个长度截断一行代码解决。这种“把元信息随帧携带”的做法在链路层协议里很常见好处是无状态——接收端不需要维护任何上下文就能正确解析。2.3 重复丢弃一张按源 MAC 索引的表怎么撑住全线速接收侧的逻辑用伪代码表达最清楚。下面这段不是标准原文是按第 4.1.10 节 Duplicate handling 的描述还原出来的实现骨架import struct RCT_LEN 6 LAN_A, LAN_B 0x0A, 0x0B ENTRY_FORGET_TIME 0.4 # 表项老化时间标准第 4.5 节给常量 def build_prp_frames(lsdu: bytes, seq: int): 发送侧一份负载复制成两份各自追加 6 字节 RCT 分别从两个端口发出LAN ID 用来标记这一份走了哪条路 out [] for lan_id in (LAN_A, LAN_B): rct struct.pack(HHH, len(lsdu), seq 0xFFFF, lan_id) out.append(lsdu rct) return out def prp_receive(frame: bytes, src_mac: str, table: dict, now: float): 接收侧先看尾巴再查表命中就丢弃未命中才上送 lsdu, rct frame[:-RCT_LEN], frame[-RCT_LEN:] size, seq, lan_id struct.unpack(HHH, rct) key (src_mac, seq) # 判重主键谁发的 第几帧 last table.get(key) if last is not None and now - last ENTRY_FORGET_TIME: return None # 另一条 LAN 上的同一帧丢弃 table[key] now # 首份到达登记后正常上送 return lsdu[:size] # 按 LSDU size 截掉以太网填充这段代码里有三个设计点值得展开。第一判重的主键是“源 MAC 序列号”不是序列号本身。多条业务流同时在跑序列号各自独立计数只看序列号必然误判。第二表项带时间戳并在超时后失效因为序列号是 16 位、会回绕不做老化的话几秒钟之后的老表项会把新帧当成重复丢掉这种故障在现场极难定位现象是“跑一段时间后偶发丢包”。第三必须先查表再上送顺序不能反否则重复帧已经进了协议栈再丢也没意义。标准里还定义了两种模式Duplicate Discard 是正常工作模式Duplicate Accept 只用于测试——它把重复帧也放行专门给现场排查用。有人看到抓包里有成对出现的相同帧就以为网络出了环路其实在 PRP 里这是设计产物正常得不能再正常。真正该警惕的是“该丢的没丢”那才是表容量或者老化参数出了问题。表满的时候怎么办标准没有替实现做决定常见的实现思路有两种一种是淘汰最老的表项保证新流量正常另一种是表满后不再做重复过滤退化成普通转发。前者的风险是极短时间内的老帧可能漏判后者的风险是重复帧全部涌进协议栈。选哪种取决于你的业务能不能容忍偶发重复这个决定必须写进设备规格里不能留给运气。2.4 监管帧与节点表链路断了一半系统怎么知道PRP 有个容易被忽视的隐患LAN A 断了业务一点感觉都没有因为 LAN B 扛住了全部流量。这时候系统看起来一切正常实际上冗余已经耗尽再来一次故障就是真停机。这种“静默降级”比直接宕机更危险因为没人会去修。标准第 4.3 节定义的监管帧就是解药。每个 DANP 和 RedBox 周期性往两条 LAN 上各发一个监管帧帧里带 TLV 结构的信息自己的 MAC、两个端口各自的连接状态、以及其他实现自定义的诊断字段。收端把这些信息汇总进节点表网管系统就能画出“谁在线、谁双连接、谁的哪条腿断了”这张图。节点表的价值不只是画图。它还能识别出一种很隐蔽的部署错误某台设备号称双连接实际上两个口都插在同一个交换机上。从协议角度看它确实收到两份帧、也确实在做重复丢弃但两条路径共享同一个故障域冗余形同虚设。监管帧里记录的端口状态配合拓扑发现才能把这种“假冗余”揪出来。RedBox 也会发监管帧这让它后面的单连接设备在节点表里有代理身份。这一层代理关系是 PRP 扩展到存量设备的关键下一节涉及到 HSR 的 RedBox 时还会再遇到同样的设计。3. HSR 的机制环上跑两圈靠什么让帧自己停下来HSR 要解决的问题和 PRP 一样但约束条件完全不同。PRP 假设你有两条独立 LAN 可布现实里很多场景——比如一条产线、一列车厢、一个风机塔筒——布线本身就是成本大头拉两条环是奢侈。HSR 的回答是把两条路径折叠进一个环里设备首尾相连成一个圈每个节点两个口帧从两个方向各发一份绕环相向而行。3.1 DANH 的发送与吸收帧怎么自己终止DANH 是 HSR 里的双连接节点两个端口 A、B 接在环上。发送时它做两件事复制一份帧给两份都打上 HSR 标签然后分别从 A 口和 B 口发出去。两份帧沿着环的两个方向传播途经的每个节点都要做判断——这是给谁的、我是不是已经见过。终止条件有两条缺一不可。第一条帧的源 MAC 是自己直接丢。这一条保证了帧绕完一整圈回到原点时不会无限循环是环网协议最基本的防环手段。第二条帧的目的 MAC 是自己收下并且不再往另一个口转发。这一条决定了单播帧到达目的节点后就从环上消失不会继续占带宽。广播和组播帧没法这样终止它们会被每个节点收下直到绕回源点才被丢弃——这也是为什么 HSR 环上的广播风暴特别致命。和 PRP 一样判重的主键还是“源 MAC 序列号”只不过这次的序列号藏在 HSR 标签里。区别在于 PRP 的两份帧走的是两条物理上不相通的路天然不会互相干扰HSR 的两份帧在同一个环上相向而行中途可能在任意节点擦肩而过所以每个中间节点都必须参与判重不能只有目的节点做。3.2 HSR 标签的 6 个字节花在哪HSR 标签插在源 MAC 之后、原来的以太类型字段之前长度也是 6 字节。这个位置和 PRP 的帧尾方案形成鲜明对比原因很直接HSR 帧要在环上被每一个节点读取和改写转发时可能要更新路径信息标签必须在帧头附近让硬件能在流水线的第一拍就取到。字段长度作用HSR EtherType2 字节固定值让接收端在 MAC 之后立刻识别出这是 HSR 帧Path / NetId LSDU size2 字节高位是路径或网络标识低位是含标签的负载长度Sequence number2 字节16 位递增计数判重主键解析这段头部在软件里长这样import struct HSR_ETHERTYPE 0x892F def parse_hsr(frame: bytes): HSR 标签紧跟在源 MAC 之后即偏移 12 字节处开始 共 6 字节解析失败返回 None 表示这是普通以太网帧 if len(frame) 18: return None tag frame[12:18] ethertype struct.unpack(H, tag[0:2])[0] if ethertype ! HSR_ETHERTYPE: return None # 不是 HSR 帧按普通帧处理 path_len struct.unpack(H, tag[2:4])[0] path path_len 12 # 高 4 位路径 / 网络标识 lsdu_size path_len 0x0FFF # 低 12 位含标签的负载长度 seq struct.unpack(H, tag[4:6])[0] return {path: path, size: lsdu_size, seq: seq}那个路径字段是 HSR 里最容易被忽略、但多环组网时最要命的字段。单个环里它没什么存在感一旦用 QuadBox 把两个环连起来它就变成了区分“这一帧属于哪个环”的唯一依据。没有它一个帧从环 1 转到环 2、又从环 2 绕回环 1判重表会把两边搞混出现跨环的重复帧。LSDU size 的作用和 PRP 里一样解决以太网最小帧填充的问题。但 HSR 多了一层这个长度是含标签的长度不是纯负载长度因为环上转发时标签一直在剥标签是最后一步才做的事。3.3 转发规则从哪个口进来往哪个口出去标准第 5.3.4 节把 DANH 的转发规则列成了一张判定表逻辑可以压缩成四条帧来自本地链路层也就是本机应用要发的打标签从 A、B 两个口各发一份。帧从 A 口进来源 MAC 不是自己目的不是自己从 B 口转发出去只走一个方向。帧从 A 口进来源 MAC 是自己这是自己发出去绕了一圈回来的丢弃。帧从 A 口进来目的 MAC 是自己收下交给上层同时不再转发环上这一份到此为止。这套规则的精妙之处在于它完全无状态。节点不需要记住“这个帧我是从哪个口发的”“它应该从哪个口出”只需要看源 MAC 和目的 MAC 就能决定动作所有判断都是常数时间。环网协议里凡是需要维护转发表、需要跑生成树收敛的方案都会在拓扑变化时产生一段不确定期而无状态转发把这个不确定期直接抹掉了。代价是带宽。环上任何一帧都要走两遍两个方向各一遍所以 HSR 环的有效带宽只有链路速率的一半左右。这个数字必须在前期的容量规划里算清楚后面避坑章节会讲到忽视这一点的后果。3.4 RedBox 与 QuadBox把单连接设备和非 HSR 世界缝进环里现实里不可能所有设备都支持 HSR总要有老设备接入。RedBox 就是干这个的它有三个口两个 HSR 口挂在环上一个 interlink 口接普通以太网后面可以挂一堆单连接设备。从 interlink 收到帧时RedBox 干的事和 DANH 发帧一样打标签、复制、两个方向发出去。从环上收到帧时它要多做一步判断目的地址在不在我 interlink 后面那一串设备里在的话剥掉标签送出去同时记住这一帧已经处理过等另一份从另一个口绕回来时直接丢掉不能再往 interlink 送一遍。这里就冒出了代理节点表的概念。RedBox 背后挂的设备本身不会发监管帧、不会维护序列号RedBox 必须替它们维护身份和状态把自己变成它们在环上的代言人。代理表的容量是硬限制挂在 RedBox 下面的设备数量一旦超过表的深度后来的设备就进不了表转发和判重开始出问题而且是间歇性的抓包都不一定抓得到。QuadBox 是 RedBox 的加倍版两个 RedBox 背靠背拼起来四个 HSR 口用来把两个环连成一个更大的环。它带来的麻烦是跨环判重——同一个帧从环 1 进来转到环 2可能又从环 2 的另一个方向绕回环 1路径字段和序列号必须配合起来才能正确识别。多环结构下的故障排查难度是单环的好几倍不是必须做环间冗余的话尽量不要主动引入。4. 避坑五个在现场反复出现的翻车点标准写得再细落地时踩的坑还是那几类。下面这五条都来自真实工程的共性每条按“看到什么现象、根子在哪儿、怎么收拾”的顺序讲。4.1 拓扑接错引发的三类故障第一条两条 LAN 被悄悄桥接了。现象很典型——网络里广播包突然暴涨交换机的灯疯狂闪抓包看到同一个帧在不同网段反复出现CPU 占用直接飙满。原因几乎都是部署时为了方便随手拿一根网线把两个交换机连起来了或者两台设备的双口插到了同一台交换机的两个口上。PRP 的全部正确性建立在“两条 LAN 完全独立”这个前提上一旦有桥接路径两份复制帧会互相串门判重表彻底失效而且环化之后广播会自己放大自己。解决方式只能是从物理上把两条 LAN 隔离做完之后用监管帧的节点表确认每台设备的两个口确实落在不同的网段里别信接线图信表。第二条HSR 环里串进了一台普通交换机。现象是环上某个方向断流或者下游设备收到的帧缺标签、应用层解析报错。普通交换机不认识那个固定的以太类型它会把标签当成负载的一部分原样转发看起来好像没事但它的转发逻辑是“从另一个口出去”而不是 HSR 要求的方向性规则一旦拓扑有冗余路径就会泛洪帧在环上乱窜。HSR 环上只能有两种设备DANH 和 RedBox中间不允许出现任何不理解标签的转发设备。这条没有妥协余地。第三条以为接上口就是双连接其实两条腿在同一个故障域。现象是平时跑得好好的某台交换机一断电整条链路直接断冗余完全没起作用。原因是设备确实有两个口、也确实在发两份帧但两个口接在同一台交换机的不同端口上或者两条 LAN 最终汇聚到同一个上游设备。冗余的有效性取决于两条路径的独立性不取决于端口数量。做验收的时候必须逐个故障域做拔线测试而不是数端口。4.2 参数与观测引发的两类故障第四条老化时间和序列号窗口对不上跑久了开始偶发丢包。现象是设备刚上电一切正常连续跑几小时之后开始出现零星丢帧重启就恢复非常有规律。根子在于判重表的表项老化时间设得太短短到和网络里的最大帧重排时间不匹配——两条路径的延迟不一样先发的帧晚到是完全可能的如果第一份到达后表项很快就过期了第二份就会被当成新帧放行重复帧涌进协议栈反过来老化时间设得太长、表容量又小表被老表项占满新帧无法登记判重直接失效。这两个参数是一对必须和实际网络的最坏延迟抖动一起调调完还要用长时间压测验证。第五条抓包看到的东西和想象的不一样。现象是打开抓包工具看到的帧结构错位协议解析全乱或者干脆认不出那个以太类型。原因是标签插在 MAC 之后、原以太类型之前普通网卡的解析逻辑是“MAC 后面就是类型字段”位置被占用之后整条解析链就偏了。排查的时候要么用支持这类标签解析的抓包配置要么自己按固定偏移手工拆。这个坑本身不致命但它会让人误判问题——很多人第一次看到成对出现的重复帧第一反应是“网络有环”实际上那是设计本来的样子。顺带说一句 RedBox 后面的设备数量。代理表满了之后的表现是间歇性通信异常不是彻底不通所以特别容易被归到“玄学”里。上线前把每个 RedBox 下挂的设备数盘一遍留出余量比事后抓包省事得多。5. 从 16 位序列号到硬件流水线实现层面的三个硬约束协议描述起来不复杂真正把它做进设备里难点集中在三个地方序列号会回绕、表容量和老化时间互相牵制、以及每一帧都要在极短时间内完成判断。5.1 回绕比较为什么不能直接用大于号序列号是 16 位的计到 65535 之后回到 0。如果代码里写if seq last_seq那么在回绕的那一瞬间所有判断都会反过来现象是每隔六万多帧出现一次成批的误判丢包周期长到很难和业务现象关联起来。正确的做法是用无符号差值判断“新不新”而不是比较绝对值SEQ_MOD 1 16 HALF SEQ_MOD 1 def seq_newer(a: int, b: int) - bool: 判断序列号 a 是否比 b 更新。 用模差值落在前半区判定为“更新” 这样 65535 - 0 的回绕会被当成正常递增而不是数值变小 diff (a - b) % SEQ_MOD return 0 diff HALF这个写法的依据是在任何一个合理的窗口内两个序列号的真实差值不可能超过 32767 帧。超过这个数说明中间丢了太多帧连接状态本来就不可信了判定为新帧反而更安全。同样的逻辑在 TCP 序列号比较里也是这么处理的属于链路层和传输层共用的一条经验。5.2 窗口、老化时间与表容量判重不一定非要记录每一个序列号更省资源的做法是给每个源维护一个滑动窗口记录“见过的最大序列号”加上一个位图位图里每一位代表最大序列号往前第 N 帧有没有见过。收到一帧时算出它相对最大值的偏移落在窗口内就查位图落在窗口外就整体滑动。这套结构决定了三个参数必须一起定窗口宽度决定能容忍多大的帧重排范围表项数量决定能同时跟踪多少个源老化时间决定一个源静默多久之后可以回收。三者是乘法关系直接对应硬件资源。窗口开大一倍位图内存翻倍表项加一倍片内存储加一倍。选型阶段这些数字是要拿去和芯片容量对账的不能等软件写完才发现放不下。还有一条容易被忽略表满时的行为必须明确定义。是淘汰最老的表项还是拒绝新源、退化成不过滤前者可能导致极端情况下老帧漏判后者会在设备数量超过设计值时集体失效。两种都不可怕可怕的是没定义行为随实现漂移。5.3 为什么最后都做进了硬件千兆线速下最小帧 64 字节对应每秒约一百四十多万帧。每一帧都要做三件事解析头部取出源 MAC 和序列号、查一张可能上万条目的表、写回时间戳。这三步在软件里走一遍哪怕每步只要几百纳秒加起来也早就超过每帧 0.7 微秒的预算了更别说还要留给协议栈本身。所以这类功能最终都落在 FPGA 或者带冗余卸载能力的交换芯片里。硬件实现时判重表就是一个内容寻址存储器加一组定时器查表在一个时钟周期内完成时间戳由硬件计数器统一供给老化由后台扫描逻辑定期清理。软件在这里的角色退化成配置和诊断写参数、读统计、看哪个源被判了多少次重复。代价是灵活性。参数一旦烧进逻辑改一次要重新综合、重新验证、重新走一遍现场升级流程。这也解释了为什么这类设备的配置项看起来那么少——不是厂商偷懒是每个可配置项背后都对应着硬件资源的重新分配。6. 选型PRP 和 HSR 不是新旧关系是拓扑约束下的两种答案经常有人问哪个更先进这个问题本身就问偏了。两者解决的是同一个问题区别在于你愿意付哪种成本。维度PRPHSR拓扑两条独立 LAN可以是任意结构一个环节点首尾相连冗余域双连接节点之间整个环帧开销尾部 6 字节头部 6 字节单连接设备接入RedBox 代理RedBox 代理布线成本需要两套独立网络一套环网对上层透明是端到端不用改需要链路层支持标签有效带宽每条 LAN 满带宽环带宽的一半左右看完这张表选择逻辑其实很清楚。如果现场已经有两套独立的网络基础设施或者设备天然分布在两个可以物理隔离的通道上比如一列车的两侧、一条产线的两端PRP 更合适因为它对上层完全透明存量设备通过 RedBox 接入就行应用代码一行不用动。如果布线成本是主要矛盾节点本来就是串联分布的那就选 HSR用一半带宽换掉一整套额外布线。真正的坑在混合场景。两个环用 QuadBox 连起来、环里再挂几个 RedBox 接老设备这种结构在图纸上很好看实际排查时复杂度是单环的好几倍跨环判重要靠路径字段、代理表容量要按环间流量重新算、监管帧的节点表会变得又大又难读。我吃过一次亏一个跨环项目上线后偶发通信中断前后折腾了两周才定位到是某个 RedBox 的代理表满了而这种问题在单环结构里根本不会出现。从那以后我每次做这类方案都会强制走一遍三件事一是拿拓扑图逐个故障域做拔线推演确认任意单点失效后路径仍然存在二是把所有 RedBox 下挂设备数盘一遍和代理表容量对账留够余量三是上线前用监管帧的节点表核对一遍实际连接状态别信图纸信数据。这三步花不了半天但能省掉后面两周的返工。这份标准的价值也在这里——它不只是定义了两个协议而是把这类网络里所有该被验证的状态都显式写了出来照着它逐条对比凭经验猜靠谱得多。希望帮到你。本文还有配套的精品资源点击获取 简介IEC 62439-3:2016 第3.0版英文原版标准全文面向工业通信、电力自动化、轨道交通等领域的网络设计与测试工程师及高校研究者重点解决高可靠网络中单点故障引发通信中断的问题。文档系统规定了平行冗余协议PRP与高可用性无缝冗余HSR的帧结构、冗余实体、网络拓扑、配置与诊断方法并给出与其他工业通信协议的集成要点及测试验证流程可用于设备选型、方案评审与标准符合性自查。压缩包内仅 1 个 PDF 文件约 6.65MB共 358 页含目录、图表与英法双语标题页便于按章节检索定位具体条款已有 393 人学习下载。读者可据此掌握 PRP 双路径零切换与 HSR 双环无缝转发的完整规范原文厘清 DANP、RedBox、SAN 等节点角色的定义与部署差异并借助标准中的诊断与测试条款搭建验证用例为产品研发和现场故障分析提供权威依据。1. 零切换的真实含义系统里根本没有“切换”这个动作工业现场对“恢复时间”的容忍度和办公网络不是一个量级。办公网断五十毫秒用户只觉得卡了一下一条运动控制指令晚到十毫秒机械臂可能已经撞上夹具。常规思路是把切换做快各类环网冗余机制都在压缩这个数字压到毫秒级已经是大量工程实践反复摸索出来的极限。PRP 和 HSR 在 IEC 62439-3 第三版里给出的却是另一个答案不做切换。同一份数据被复制成两份沿两条互不相干的路径同时出发接收端只把先到的那份交给上层另一份按重复帧丢掉。所谓零恢复时间其实是系统里压根没有“恢复”这个动作。这套机制值得深入研究的点在于它把可靠性问题从“协议收敛得快不快”换成了“带宽和布线愿不愿意付”本质上是一次彻底的成本置换。2. PRP 的机制两份数据同时上路接收端凭什么只交一份给应用PRP 最容易被误解的地方是很多人以为它做了一个“主备切换”的加速版。实际情况恰恰相反它压根没有主备的概念两条 LAN 从开机那一刻起就是平权的每一帧都同时在两条路上跑。标准第 4 章把这件事拆成了几个互相咬合的部件——节点结构、尾部控制信息、重复判定表、监管帧少一个都转不起来。2.1 DANP 的两个端口为什么共用一个 MACPRP 里的核心角色叫 DANP双连接节点。它有两个独立的以太网口分别接到 LAN A 和 LAN B但这两个口对外呈现的是同一个 MAC 地址。这一点经常让刚接触的人困惑同一个 MAC 出现在两个网段里不会冲突吗不会因为 PRP 有一条硬性前提——LAN A 和 LAN B 必须在物理上和逻辑上完全独立中间不允许有任何桥接路径。两条 LAN 是两个平行世界同一个 MAC 各在自己世界里活动互不知情。共用一个 MAC 是精心设计的结果不是偷懒。上层应用只看到一张网卡、一个 IP、一个协议栈收发包的代码一行都不用改。如果两个端口用不同 MAC应用层就要处理“我从哪个身份发出去”“对端看到的是哪个我”这类问题PRP 对上层透明这个最大卖点就没了。换句话说PRP 把冗余全部藏在链路层以下用“两个物理口伪装成一个逻辑口”的手法把复杂性关进了网卡和交换芯片里。代价也随之而来两个 LAN 的带宽必须各自按全流量规划。因为每一帧都要走两遍LAN A 上跑多少流量LAN B 上就得有多少余量。这条约束在后面选型时会反复出现。2.2 尾部 6 字节冗余信息为什么不能放在帧头PRP 给每个复制出来的帧追加 6 字节的冗余控制信息业内常叫 RCT。它固定挂在帧尾位置很关键。字段长度作用LSDU size2 字节原始负载长度接收端据此剥离尾部填充Sequence number2 字节同一源发出的帧递增计数重复判定的主键LAN ID / Path2 字节标识这一份是从哪条 LAN 发出的放帧尾而不是帧头是整个协议里最见功力的一处取舍。PRP 网络里不可能只有双连接设备一定还挂着一堆普通的单网口设备——PLC、仪表、老式交换机。这些设备不认识任何冗余信息它们只会按标准以太网规则转发。如果把冗余字段插在帧头普通交换机会把它当成负载的一部分或者因为解析错位直接把帧丢掉更糟的是改动了帧头结构某些设备的安全策略会判定为异常帧。挂在帧尾就完全不一样了。普通交换机看帧头目的 MAC、源 MAC、类型字段全都原封不动转发行为和一个普通数据帧没有任何区别RCT 只是“多出来的一点尾巴”跟着帧一起被搬到对面。只有真正的 DANP 收到帧之后才会去读最后 6 个字节判断这是不是重复帧然后剥掉尾巴把干净的负载交给上层。LSDU size 这个字段存在的理由也很实在。以太网有 64 字节最小帧的限制短帧必须填充到 64 字节接收端如果只看帧长根本分不清哪部分是业务数据、哪部分是填充。所以发送方在 RCT 里写死原始长度接收方按这个长度截断一行代码解决。这种“把元信息随帧携带”的做法在链路层协议里很常见好处是无状态——接收端不需要维护任何上下文就能正确解析。2.3 重复丢弃一张按源 MAC 索引的表怎么撑住全线速接收侧的逻辑用伪代码表达最清楚。下面这段不是标准原文是按第 4.1.10 节 Duplicate handling 的描述还原出来的实现骨架import struct RCT_LEN 6 LAN_A, LAN_B 0x0A, 0x0B ENTRY_FORGET_TIME 0.4 # 表项老化时间标准第 4.5 节给常量 def build_prp_frames(lsdu: bytes, seq: int): 发送侧一份负载复制成两份各自追加 6 字节 RCT 分别从两个端口发出LAN ID 用来标记这一份走了哪条路 out [] for lan_id in (LAN_A, LAN_B): rct struct.pack(HHH, len(lsdu), seq 0xFFFF, lan_id) out.append(lsdu rct) return out def prp_receive(frame: bytes, src_mac: str, table: dict, now: float): 接收侧先看尾巴再查表命中就丢弃未命中才上送 lsdu, rct frame[:-RCT_LEN], frame[-RCT_LEN:] size, seq, lan_id struct.unpack(HHH, rct) key (src_mac, seq) # 判重主键谁发的 第几帧 last table.get(key) if last is not None and now - last ENTRY_FORGET_TIME: return None # 另一条 LAN 上的同一帧丢弃 table[key] now # 首份到达登记后正常上送 return lsdu[:size] # 按 LSDU size 截掉以太网填充这段代码里有三个设计点值得展开。第一判重的主键是“源 MAC 序列号”不是序列号本身。多条业务流同时在跑序列号各自独立计数只看序列号必然误判。第二表项带时间戳并在超时后失效因为序列号是 16 位、会回绕不做老化的话几秒钟之后的老表项会把新帧当成重复丢掉这种故障在现场极难定位现象是“跑一段时间后偶发丢包”。第三必须先查表再上送顺序不能反否则重复帧已经进了协议栈再丢也没意义。标准里还定义了两种模式Duplicate Discard 是正常工作模式Duplicate Accept 只用于测试——它把重复帧也放行专门给现场排查用。有人看到抓包里有成对出现的相同帧就以为网络出了环路其实在 PRP 里这是设计产物正常得不能再正常。真正该警惕的是“该丢的没丢”那才是表容量或者老化参数出了问题。表满的时候怎么办标准没有替实现做决定常见的实现思路有两种一种是淘汰最老的表项保证新流量正常另一种是表满后不再做重复过滤退化成普通转发。前者的风险是极短时间内的老帧可能漏判后者的风险是重复帧全部涌进协议栈。选哪种取决于你的业务能不能容忍偶发重复这个决定必须写进设备规格里不能留给运气。2.4 监管帧与节点表链路断了一半系统怎么知道PRP 有个容易被忽视的隐患LAN A 断了业务一点感觉都没有因为 LAN B 扛住了全部流量。这时候系统看起来一切正常实际上冗余已经耗尽再来一次故障就是真停机。这种“静默降级”比直接宕机更危险因为没人会去修。标准第 4.3 节定义的监管帧就是解药。每个 DANP 和 RedBox 周期性往两条 LAN 上各发一个监管帧帧里带 TLV 结构的信息自己的 MAC、两个端口各自的连接状态、以及其他实现自定义的诊断字段。收端把这些信息汇总进节点表网管系统就能画出“谁在线、谁双连接、谁的哪条腿断了”这张图。节点表的价值不只是画图。它还能识别出一种很隐蔽的部署错误某台设备号称双连接实际上两个口都插在同一个交换机上。从协议角度看它确实收到两份帧、也确实在做重复丢弃但两条路径共享同一个故障域冗余形同虚设。监管帧里记录的端口状态配合拓扑发现才能把这种“假冗余”揪出来。RedBox 也会发监管帧这让它后面的单连接设备在节点表里有代理身份。这一层代理关系是 PRP 扩展到存量设备的关键下一节涉及到 HSR 的 RedBox 时还会再遇到同样的设计。3. HSR 的机制环上跑两圈靠什么让帧自己停下来HSR 要解决的问题和 PRP 一样但约束条件完全不同。PRP 假设你有两条独立 LAN 可布现实里很多场景——比如一条产线、一列车厢、一个风机塔筒——布线本身就是成本大头拉两条环是奢侈。HSR 的回答是把两条路径折叠进一个环里设备首尾相连成一个圈每个节点两个口帧从两个方向各发一份绕环相向而行。3.1 DANH 的发送与吸收帧怎么自己终止DANH 是 HSR 里的双连接节点两个端口 A、B 接在环上。发送时它做两件事复制一份帧给两份都打上 HSR 标签然后分别从 A 口和 B 口发出去。两份帧沿着环的两个方向传播途经的每个节点都要做判断——这是给谁的、我是不是已经见过。终止条件有两条缺一不可。第一条帧的源 MAC 是自己直接丢。这一条保证了帧绕完一整圈回到原点时不会无限循环是环网协议最基本的防环手段。第二条帧的目的 MAC 是自己收下并且不再往另一个口转发。这一条决定了单播帧到达目的节点后就从环上消失不会继续占带宽。广播和组播帧没法这样终止它们会被每个节点收下直到绕回源点才被丢弃——这也是为什么 HSR 环上的广播风暴特别致命。和 PRP 一样判重的主键还是“源 MAC 序列号”只不过这次的序列号藏在 HSR 标签里。区别在于 PRP 的两份帧走的是两条物理上不相通的路天然不会互相干扰HSR 的两份帧在同一个环上相向而行中途可能在任意节点擦肩而过所以每个中间节点都必须参与判重不能只有目的节点做。3.2 HSR 标签的 6 个字节花在哪HSR 标签插在源 MAC 之后、原来的以太类型字段之前长度也是 6 字节。这个位置和 PRP 的帧尾方案形成鲜明对比原因很直接HSR 帧要在环上被每一个节点读取和改写转发时可能要更新路径信息标签必须在帧头附近让硬件能在流水线的第一拍就取到。字段长度作用HSR EtherType2 字节固定值让接收端在 MAC 之后立刻识别出这是 HSR 帧Path / NetId LSDU size2 字节高位是路径或网络标识低位是含标签的负载长度Sequence number2 字节16 位递增计数判重主键解析这段头部在软件里长这样import struct HSR_ETHERTYPE 0x892F def parse_hsr(frame: bytes): HSR 标签紧跟在源 MAC 之后即偏移 12 字节处开始 共 6 字节解析失败返回 None 表示这是普通以太网帧 if len(frame) 18: return None tag frame[12:18] ethertype struct.unpack(H, tag[0:2])[0] if ethertype ! HSR_ETHERTYPE: return None # 不是 HSR 帧按普通帧处理 path_len struct.unpack(H, tag[2:4])[0] path path_len 12 # 高 4 位路径 / 网络标识 lsdu_size path_len 0x0FFF # 低 12 位含标签的负载长度 seq struct.unpack(H, tag[4:6])[0] return {path: path, size: lsdu_size, seq: seq}那个路径字段是 HSR 里最容易被忽略、但多环组网时最要命的字段。单个环里它没什么存在感一旦用 QuadBox 把两个环连起来它就变成了区分“这一帧属于哪个环”的唯一依据。没有它一个帧从环 1 转到环 2、又从环 2 绕回环 1判重表会把两边搞混出现跨环的重复帧。LSDU size 的作用和 PRP 里一样解决以太网最小帧填充的问题。但 HSR 多了一层这个长度是含标签的长度不是纯负载长度因为环上转发时标签一直在剥标签是最后一步才做的事。3.3 转发规则从哪个口进来往哪个口出去标准第 5.3.4 节把 DANH 的转发规则列成了一张判定表逻辑可以压缩成四条帧来自本地链路层也就是本机应用要发的打标签从 A、B 两个口各发一份。帧从 A 口进来源 MAC 不是自己目的不是自己从 B 口转发出去只走一个方向。帧从 A 口进来源 MAC 是自己这是自己发出去绕了一圈回来的丢弃。帧从 A 口进来目的 MAC 是自己收下交给上层同时不再转发环上这一份到此为止。这套规则的精妙之处在于它完全无状态。节点不需要记住“这个帧我是从哪个口发的”“它应该从哪个口出”只需要看源 MAC 和目的 MAC 就能决定动作所有判断都是常数时间。环网协议里凡是需要维护转发表、需要跑生成树收敛的方案都会在拓扑变化时产生一段不确定期而无状态转发把这个不确定期直接抹掉了。代价是带宽。环上任何一帧都要走两遍两个方向各一遍所以 HSR 环的有效带宽只有链路速率的一半左右。这个数字必须在前期的容量规划里算清楚后面避坑章节会讲到忽视这一点的后果。3.4 RedBox 与 QuadBox把单连接设备和非 HSR 世界缝进环里现实里不可能所有设备都支持 HSR总要有老设备接入。RedBox 就是干这个的它有三个口两个 HSR 口挂在环上一个 interlink 口接普通以太网后面可以挂一堆单连接设备。从 interlink 收到帧时RedBox 干的事和 DANH 发帧一样打标签、复制、两个方向发出去。从环上收到帧时它要多做一步判断目的地址在不在我 interlink 后面那一串设备里在的话剥掉标签送出去同时记住这一帧已经处理过等另一份从另一个口绕回来时直接丢掉不能再往 interlink 送一遍。这里就冒出了代理节点表的概念。RedBox 背后挂的设备本身不会发监管帧、不会维护序列号RedBox 必须替它们维护身份和状态把自己变成它们在环上的代言人。代理表的容量是硬限制挂在 RedBox 下面的设备数量一旦超过表的深度后来的设备就进不了表转发和判重开始出问题而且是间歇性的抓包都不一定抓得到。QuadBox 是 RedBox 的加倍版两个 RedBox 背靠背拼起来四个 HSR 口用来把两个环连成一个更大的环。它带来的麻烦是跨环判重——同一个帧从环 1 进来转到环 2可能又从环 2 的另一个方向绕回环 1路径字段和序列号必须配合起来才能正确识别。多环结构下的故障排查难度是单环的好几倍不是必须做环间冗余的话尽量不要主动引入。4. 避坑五个在现场反复出现的翻车点标准写得再细落地时踩的坑还是那几类。下面这五条都来自真实工程的共性每条按“看到什么现象、根子在哪儿、怎么收拾”的顺序讲。4.1 拓扑接错引发的三类故障第一条两条 LAN 被悄悄桥接了。现象很典型——网络里广播包突然暴涨交换机的灯疯狂闪抓包看到同一个帧在不同网段反复出现CPU 占用直接飙满。原因几乎都是部署时为了方便随手拿一根网线把两个交换机连起来了或者两台设备的双口插到了同一台交换机的两个口上。PRP 的全部正确性建立在“两条 LAN 完全独立”这个前提上一旦有桥接路径两份复制帧会互相串门判重表彻底失效而且环化之后广播会自己放大自己。解决方式只能是从物理上把两条 LAN 隔离做完之后用监管帧的节点表确认每台设备的两个口确实落在不同的网段里别信接线图信表。第二条HSR 环里串进了一台普通交换机。现象是环上某个方向断流或者下游设备收到的帧缺标签、应用层解析报错。普通交换机不认识那个固定的以太类型它会把标签当成负载的一部分原样转发看起来好像没事但它的转发逻辑是“从另一个口出去”而不是 HSR 要求的方向性规则一旦拓扑有冗余路径就会泛洪帧在环上乱窜。HSR 环上只能有两种设备DANH 和 RedBox中间不允许出现任何不理解标签的转发设备。这条没有妥协余地。第三条以为接上口就是双连接其实两条腿在同一个故障域。现象是平时跑得好好的某台交换机一断电整条链路直接断冗余完全没起作用。原因是设备确实有两个口、也确实在发两份帧但两个口接在同一台交换机的不同端口上或者两条 LAN 最终汇聚到同一个上游设备。冗余的有效性取决于两条路径的独立性不取决于端口数量。做验收的时候必须逐个故障域做拔线测试而不是数端口。4.2 参数与观测引发的两类故障第四条老化时间和序列号窗口对不上跑久了开始偶发丢包。现象是设备刚上电一切正常连续跑几小时之后开始出现零星丢帧重启就恢复非常有规律。根子在于判重表的表项老化时间设得太短短到和网络里的最大帧重排时间不匹配——两条路径的延迟不一样先发的帧晚到是完全可能的如果第一份到达后表项很快就过期了第二份就会被当成新帧放行重复帧涌进协议栈反过来老化时间设得太长、表容量又小表被老表项占满新帧无法登记判重直接失效。这两个参数是一对必须和实际网络的最坏延迟抖动一起调调完还要用长时间压测验证。第五条抓包看到的东西和想象的不一样。现象是打开抓包工具看到的帧结构错位协议解析全乱或者干脆认不出那个以太类型。原因是标签插在 MAC 之后、原以太类型之前普通网卡的解析逻辑是“MAC 后面就是类型字段”位置被占用之后整条解析链就偏了。排查的时候要么用支持这类标签解析的抓包配置要么自己按固定偏移手工拆。这个坑本身不致命但它会让人误判问题——很多人第一次看到成对出现的重复帧第一反应是“网络有环”实际上那是设计本来的样子。顺带说一句 RedBox 后面的设备数量。代理表满了之后的表现是间歇性通信异常不是彻底不通所以特别容易被归到“玄学”里。上线前把每个 RedBox 下挂的设备数盘一遍留出余量比事后抓包省事得多。5. 从 16 位序列号到硬件流水线实现层面的三个硬约束协议描述起来不复杂真正把它做进设备里难点集中在三个地方序列号会回绕、表容量和老化时间互相牵制、以及每一帧都要在极短时间内完成判断。5.1 回绕比较为什么不能直接用大于号序列号是 16 位的计到 65535 之后回到 0。如果代码里写if seq last_seq那么在回绕的那一瞬间所有判断都会反过来现象是每隔六万多帧出现一次成批的误判丢包周期长到很难和业务现象关联起来。正确的做法是用无符号差值判断“新不新”而不是比较绝对值SEQ_MOD 1 16 HALF SEQ_MOD 1 def seq_newer(a: int, b: int) - bool: 判断序列号 a 是否比 b 更新。 用模差值落在前半区判定为“更新” 这样 65535 - 0 的回绕会被当成正常递增而不是数值变小 diff (a - b) % SEQ_MOD return 0 diff HALF这个写法的依据是在任何一个合理的窗口内两个序列号的真实差值不可能超过 32767 帧。超过这个数说明中间丢了太多帧连接状态本来就不可信了判定为新帧反而更安全。同样的逻辑在 TCP 序列号比较里也是这么处理的属于链路层和传输层共用的一条经验。5.2 窗口、老化时间与表容量判重不一定非要记录每一个序列号更省资源的做法是给每个源维护一个滑动窗口记录“见过的最大序列号”加上一个位图位图里每一位代表最大序列号往前第 N 帧有没有见过。收到一帧时算出它相对最大值的偏移落在窗口内就查位图落在窗口外就整体滑动。这套结构决定了三个参数必须一起定窗口宽度决定能容忍多大的帧重排范围表项数量决定能同时跟踪多少个源老化时间决定一个源静默多久之后可以回收。三者是乘法关系直接对应硬件资源。窗口开大一倍位图内存翻倍表项加一倍片内存储加一倍。选型阶段这些数字是要拿去和芯片容量对账的不能等软件写完才发现放不下。还有一条容易被忽略表满时的行为必须明确定义。是淘汰最老的表项还是拒绝新源、退化成不过滤前者可能导致极端情况下老帧漏判后者会在设备数量超过设计值时集体失效。两种都不可怕可怕的是没定义行为随实现漂移。5.3 为什么最后都做进了硬件千兆线速下最小帧 64 字节对应每秒约一百四十多万帧。每一帧都要做三件事解析头部取出源 MAC 和序列号、查一张可能上万条目的表、写回时间戳。这三步在软件里走一遍哪怕每步只要几百纳秒加起来也早就超过每帧 0.7 微秒的预算了更别说还要留给协议栈本身。所以这类功能最终都落在 FPGA 或者带冗余卸载能力的交换芯片里。硬件实现时判重表就是一个内容寻址存储器加一组定时器查表在一个时钟周期内完成时间戳由硬件计数器统一供给老化由后台扫描逻辑定期清理。软件在这里的角色退化成配置和诊断写参数、读统计、看哪个源被判了多少次重复。代价是灵活性。参数一旦烧进逻辑改一次要重新综合、重新验证、重新走一遍现场升级流程。这也解释了为什么这类设备的配置项看起来那么少——不是厂商偷懒是每个可配置项背后都对应着硬件资源的重新分配。6. 选型PRP 和 HSR 不是新旧关系是拓扑约束下的两种答案经常有人问哪个更先进这个问题本身就问偏了。两者解决的是同一个问题区别在于你愿意付哪种成本。维度PRPHSR拓扑两条独立 LAN可以是任意结构一个环节点首尾相连冗余域双连接节点之间整个环帧开销尾部 6 字节头部 6 字节单连接设备接入RedBox 代理RedBox 代理布线成本需要两套独立网络一套环网对上层透明是端到端不用改需要链路层支持标签有效带宽每条 LAN 满带宽环带宽的一半左右看完这张表选择逻辑其实很清楚。如果现场已经有两套独立的网络基础设施或者设备天然分布在两个可以物理隔离的通道上比如一列车的两侧、一条产线的两端PRP 更合适因为它对上层完全透明存量设备通过 RedBox 接入就行应用代码一行不用动。如果布线成本是主要矛盾节点本来就是串联分布的那就选 HSR用一半带宽换掉一整套额外布线。真正的坑在混合场景。两个环用 QuadBox 连起来、环里再挂几个 RedBox 接老设备这种结构在图纸上很好看实际排查时复杂度是单环的好几倍跨环判重要靠路径字段、代理表容量要按环间流量重新算、监管帧的节点表会变得又大又难读。我吃过一次亏一个跨环项目上线后偶发通信中断前后折腾了两周才定位到是某个 RedBox 的代理表满了而这种问题在单环结构里根本不会出现。从那以后我每次做这类方案都会强制走一遍三件事一是拿拓扑图逐个故障域做拔线推演确认任意单点失效后路径仍然存在二是把所有 RedBox 下挂设备数盘一遍和代理表容量对账留够余量三是上线前用监管帧的节点表核对一遍实际连接状态别信图纸信数据。这三步花不了半天但能省掉后面两周的返工。这份标准的价值也在这里——它不只是定义了两个协议而是把这类网络里所有该被验证的状态都显式写了出来照着它逐条对比凭经验猜靠谱得多。希望帮到你。本文还有配套的精品资源点击获取