解决什么问题
复制帧走不同路径后，到达顺序不一定和发送顺序一致。快路径可能先到，慢路径可能隔几个周期才到；故障恢复时，旧副本还可能突然出现。消除点必须判断哪些是重复，哪些是真正的新帧。
本节解决的是恢复窗口的可信度。窗口太小会误判晚到副本，窗口太大又增加状态成本和异常流量压力。
背景与直觉
想象你按编号收包裹。编号 100 的快递 A 已经到达并签收，另一家快递的编号 100 晚到时应该丢弃。如果你的记录只保存很短时间，晚到副本可能被当成新包裹；如果记录保存太久，管理成本会上升。
怎么解决
恢复窗口至少要覆盖路径最大延迟差异、处理抖动和短暂乱序。设计时可以从这些问题开始：
| 问题 | 影响 |
|---|---|
| 两条路径最大延迟差多少 | 决定同一序列副本相隔多久 |
| 流周期是多少 | 延迟差会跨几个序列 |
| 是否可能故障后恢复 | 旧副本是否突然重新出现 |
| 序列号是否会回绕 | 长时间运行后的判断边界 |
| 设备状态容量多少 | 窗口能开多大 |
验证时要构造正常双路径、主路径断开、主路径恢复、慢路径延迟增加、重复副本集中到达等场景。观察应用层是否只收到一份，设备计数器是否显示重复消除，是否出现序列缺口或误交付。
带来了什么新问题
恢复窗口和调度窗口会互相影响。备用路径延迟很大时，恢复窗口要变大，但业务 deadline 可能已经无法满足。也就是说，重复消除正确不代表时间边界正确。
另一个问题是证据采集。只看应用层收到的数据可能不够，你还需要设备侧 duplicate/discard 计数器、抓包时间戳和故障注入记录。
检查点
- 如果两条 FRER 路径最大延迟差是 3 个周期，恢复窗口至少要考虑什么？
- 为什么“没有重复交付”还不能证明 FRER 备用路径满足 deadline？