4. 故障检测机制

星间通信网络的节点分布在高速相对运动的轨道上，链路时延、可见性和误码率都随几何关系持续变化。故障恢复的第一步不是切换，而是“发现故障”。如果检测环节把瞬时抖动误判为链路中断，就会触发不必要的路由切换；如果检测过慢，业务又会在失效链路上持续丢包。因此，故障检测机制的核心任务是在可接受的误报率和检测时延之间取得平衡，并把“哪条链路、哪个方向、哪类故障”尽可能准确地定位出来。

一、四类检测手段的分工

工程上通常把检测手段分为四个层次，它们不是互相替代，而是互补使用。

• 心跳协议：节点周期性向邻居发送轻量心跳报文，若在约定窗口内未收到对端心跳，则判定邻居不可达。它实现简单、开销低，适合作为第一层快速告警。
• 链路层监测：在物理/链路层统计误码率、信噪比、同步丢失、帧校验失败等指标。它能在业务尚未明显受损时发现链路质量劣化，属于“劣化预警”。
• 端到端探测：由源节点向目的节点发送探测包，测量往返时延、丢包率和路径可达性。它反映的是整条路径的可用性，而不是单跳状态。
• 分布式故障检测算法：多个节点交换各自的局部检测结果，通过一致性判断区分“单点误判”和“真实故障”，避免因单节点异常导致全网误切换。

四者的关系可以用下面的信号链与判定关系图表示：心跳和链路层监测提供局部、快速的原始证据；端到端探测提供路径级确认；分布式算法对多源证据做融合与仲裁，最终输出“链路正常 / 疑似劣化 / 确认故障”的状态。

二、心跳协议的关键参数

心跳协议看似简单，但参数选择直接决定检测性能。设心跳周期为 T，连续丢失 N 个心跳后判定失联，则最坏检测时延约为 N×T。以星间链路为例，若取 T=1s、N=3，则最坏约 3 秒发现邻居失联。若把 N 降到 1，检测时延缩短到 1 秒，但一次随机丢包就会触发误判。

实际部署中常用“软状态”设计：连续丢失 1 个心跳时标记为“可疑”，连续丢失 3 个才升级为“失联”。同时心跳报文应携带序列号和发送时间戳，接收端据此计算单向时延和丢包率，而不仅仅判断“收到/未收到”。下面是一段典型的心跳判定伪代码：

每 T 秒发送一次 HEARTBEAT(seq, t_send)
收到心跳时：
    loss = seq - last_seq - 1
    rtt  = now - t_send
    更新邻居状态：last_seen = now, loss_count += loss
若 now - last_seen > N * T：
    标记邻居为 SUSPECT，并通知分布式检测模块
若 now - last_seen > M * T（M > N）：
    标记邻居为 FAILED，触发恢复流程

三、链路层监测与端到端探测的配合

链路层监测关注的是“链路本身好不好”。星间激光链路可采集误码率（BER）、接收光功率、指向偏差、帧同步丢失次数等。若 BER 从 1e-9 缓慢升到 1e-6，业务可能尚未中断，但已进入劣化区，此时应提前降速或准备切换，而不是等到心跳超时。

端到端探测关注的是“这条路径还能不能用”。源节点周期性发送探测包，记录 RTT 和丢包率。当某条路径 RTT 从 20ms 突增到 200ms 且丢包率超过 5%，即使每一跳心跳都正常，也说明路径中存在拥塞或隐性故障。端到端探测的周期通常比心跳长（例如 5～10 秒），因为它开销更大，但能发现心跳和链路层都覆盖不到的路径级问题。

四、分布式故障检测算法

单节点检测存在两个风险：一是自身时钟或接口异常导致误判；二是只掌握局部信息，无法区分“邻居真的坏了”还是“自己收不到”。分布式检测通过邻居间交换状态摘要来解决。常见做法是每个节点维护一张邻居状态表，定期与相邻节点交换“我认为谁可疑、谁失联”，当多个独立节点对同一链路给出一致判断时，才升级为确认故障。

一种实用的判定规则是：若节点 A 认为链路 A→B 失联，同时节点 C、D 也报告 B 不可达，则置信度高，直接确认；若只有 A 报告异常，则先降级为疑似，并加密探测频率观察一个窗口。这样可以把单点误判造成的误切换显著压低。

五、检测结果如何支撑恢复

检测模块的输出不应只是“好/坏”二值，而应包含链路标识、故障方向、置信度和时间戳。恢复模块据此决定是切换路径、降速保业务，还是仅加密监测。若检测只给出模糊的“网络异常”，恢复模块就无法判断该切哪条链路，容易造成震荡切换。因此，检测与恢复之间的接口设计，和检测算法本身同样重要。

综合来看，心跳协议负责快速发现邻居失联，链路层监测负责提前发现质量劣化，端到端探测负责确认路径可用性，分布式算法负责融合多源证据、抑制误判。四者协同，才能在星间网络这种高动态、易受干扰的环境中，既快又准地识别真正的故障。