解决什么问题
关键控制流通常不是“丢一帧无所谓”。如果单条路径中断，应用看到的可能不是延迟变大，而是控制周期直接缺失。只靠 Qbv 或 CBS 解决不了这个问题，因为它们默认帧还能沿计划路径转发。
最朴素的办法是“同一份数据发两份”。但这马上带来两个问题：第一，接收侧怎么知道两份帧是同一份数据；第二，如果两份帧都到达，接收侧应该交付哪一份、丢弃哪一份。FRER 的机制就是围绕这两个问题展开。
背景与直觉
可以把一条关键帧想成一张带编号的工单。复制点把工单复印两份，分别走 A 路和 B 路。到达消除点时，如果编号 105 的工单已经处理过，另一份编号 105 就不再交给上层。这样上层看到的是连续编号，而不是重复消息。
这里的关键不是“复印”本身，而是编号与记忆。没有编号，消除点无法判断两份帧是不是同一份数据；没有记忆窗口，消除点无法处理晚到副本和乱序到达；没有路径设计，两个副本可能被同一个故障同时打断。
怎么解决
FRER 通常可以拆成四个逻辑动作。
| 动作 | 它做什么 | 需要追问什么 |
|---|---|---|
| Sequence generation | 给属于同一流的帧附加递增序列信息 | 序列空间是否足够，重启后如何处理 |
| Replication | 在复制点生成多个副本 | 复制点之前的故障是否仍是单点 |
| Relay on paths | 副本沿不同路径转发 | 路径是否独立，每条路径是否有资源 |
| Elimination/recovery | 在汇合点识别重复并恢复交付 | 恢复窗口是否覆盖乱序和延迟差异 |
序列号让消除点可以回答“这个帧我见过没有”。恢复窗口让设备不用记住无限历史，而是在一个有限范围内判断哪些序列号已交付、哪些是晚到副本、哪些可能是新帧。窗口越大，越能覆盖路径延迟差异和乱序，但状态和处理成本也越高；窗口越小，设备更轻，但晚到的合法副本可能被误判。
这个例子说明 FRER 的收益来自“至少一份到达”。但它也暴露了另一个约束：如果应用 deadline 是 100 us，路径 B 虽然能救连续性，却救不了准时性。只有当备用路径也满足时间边界，FRER 才能在故障下维持确定性服务。
关键参数如何影响结果
恢复窗口要覆盖路径延迟差异、设备处理抖动和短暂乱序。例如关键流周期是 250 us，路径 A 比路径 B 快 500 us，那么同一序列的两个副本可能相差两个周期才到。消除点必须能在这个范围内识别“旧副本”，否则会把晚到副本当成新数据。
但窗口也不是越大越好。窗口越大，设备要保存更多序列状态；攻击或异常流量下，重复判断压力也更高。对工程设计来说，恢复窗口应该来自路径差异和周期，而不是拍脑袋。
还要注意复制点和消除点的位置。复制点越靠近 talker，能覆盖的下游故障越多；但复制越早，网络里承载副本的链路也越多。消除点越靠近 listener，上层更干净；但重复副本会占用更长路径上的资源。很多设计会在保护范围和资源成本之间折中。
带来了什么新问题
FRER 引入的第一个新问题是资源消耗。同一份关键帧走两条路径，意味着网络里至少多了一份关键流量。它要占用队列、窗口、带宽、计数器和消除状态。如果网络原本已经接近容量边界，复制可能让其他流失去可调度性。
第二个问题是乱序与误判。两条路径延迟不同，副本到达顺序可能变化。故障恢复过程中，某些序列可能缺失、迟到或突然恢复。消除点既不能重复交付，也不能误删真正的新帧。
第三个问题是责任边界。FRER 只说明如何复制和消除，不会自动证明路径独立，也不会自动证明备用路径的 deadline。你仍然需要 Qcc 管理流需求，需要 Qbv 或其他机制提供时间边界，需要验证计划证明故障场景真的被覆盖。
检查点
- 画一条两路径 FRER 流：复制点在哪里，消除点在哪里，复制点之前和消除点之后还有哪些单点风险？
- 如果两条路径的到达时间分别是 90 us 和 260 us，而流周期是 100 us，恢复窗口至少要考虑什么？
- 为什么“备用路径能到达”不等于“备用路径满足业务 deadline”？