76 lines
5.1 KiB
Markdown
76 lines
5.1 KiB
Markdown
---
|
||
tags: []
|
||
date created: 星期三, 十一月 26日 2025, 11:23:15 晚上
|
||
date modified: 星期三, 十一月 26日 2025, 11:23:51 晚上
|
||
---
|
||
|
||
# 2.7 工程基线总结报告 - 链路鲁棒性与错误校检
|
||
|
||
**适用范围**: 外部网络链路 (UDP) + 内部 IPC 通道 (EventBus/Queue)
|
||
|
||
## 1\. 核心架构基线 (Core Architecture Baselines)
|
||
|
||
本章节作为通信协议的“安全气囊”，确立了系统在面对物理链路劣化、网络拥塞及数据损坏时的防御机制。设计遵循 **“快速失败 (Fail Fast)”** 与 **“分级恢复 (Graded Recovery)”** 原则。
|
||
|
||
| 决策领域 | 核心基线 (Baseline Established) | 关键技术特征 (Key Specs) | 设计意图/依据 |
|
||
| :--- | :--- | :--- | :--- |
|
||
| **2.7.1 完整性校验** | **应用层 CRC32c** | 算法：**CRC32c (Castagnoli)**<br>策略：**零容忍丢弃 (Zero Tolerance)** | 弥补 UDP 16-bit 校验和在高吞吐下的碰撞风险，利用 CPU 指令集加速，杜绝脏数据污染滤波状态。 |
|
||
| **2.7.2 链路保活** | **双向高频心跳** | 频率：**10Hz** (空闲时)<br>超时：**2000ms** (静默判定断连) | 维持中间网络设备 NAT 映射，实现亚秒级的物理断连感知与告警。 |
|
||
| **2.7.3 丢包恢复** | **业务感知差异化策略** | 数据流：**即时丢弃 (Fire-and-Forget)**<br>控制流：**ARQ 重传 (Stop-and-Wait)** | 在“实时性”与“可靠性”之间按需切换，防止雷达数据因重传导致队头阻塞 (HOL Blocking)。 |
|
||
| **2.7.4 拥塞控制** | **背压与尾部丢弃** | 机制：**高水位线 (High Watermark)**<br>动作：**Tail Drop / Gap Insertion** | 防止内部无锁队列溢出导致 OOM，优先牺牲非关键数据以保全系统稳定性。 |
|
||
|
||
-----
|
||
|
||
## 2\. 关键技术规范详解
|
||
|
||
### 2.7.1 应用层数据完整性校验 (Integrity Verification)
|
||
|
||
- **算法选型**：强制使用 **CRC32c (Castagnoli 多项式)**。
|
||
- *理由*：相比标准 IEEE 802.3 CRC32，CRC32c 在 iSCSI 等存储网络中被验证具有更强的检错能力，且现代 CPU (ARMv8/x86) 均提供硬件指令加速 (`crc32` / `_mm_crc32_u32`)，开销可忽略不计。
|
||
- **实施位置**：
|
||
- **生成端**：`DisplayController` 在序列化 `TrackDataBatch` 后计算，写入协议头。
|
||
- **校验端**：显控终端在解析 Payload 前校验。
|
||
- **处置策略**：校验失败的数据包视为**物理损坏**，执行**静默丢弃**并增加 `checksum_error_count` 计数，严禁尝试修复。
|
||
|
||
### 2.7.2 链路健康监测 (Link Health)
|
||
|
||
- **心跳注入**：
|
||
- `DisplayController` 维护一个 `LastSendTime`。若当前时间距离上次发送超过 **100ms**，强制插入一个空的 `HeartbeatPacket`。
|
||
- **状态机流转**：
|
||
- **Connected**: `LastRecvTime < 2000ms`。
|
||
- **Disconnected**: `LastRecvTime >= 2000ms`。触发 `LinkDownEvent`，清空态势图，重置接收缓冲区。
|
||
|
||
### 2.7.3 差异化丢包恢复 (Differentiated Recovery)
|
||
|
||
- **数据面 (Data Plane)**：雷达点迹/航迹。
|
||
- **策略**：**不重传**。
|
||
- *逻辑*：雷达数据具有强时效性，$T_k$ 时刻丢失的数据在 $T_{k+1}$ 时刻已失去价值。重传只会挤占 $T_{k+1}$ 的带宽。
|
||
- **控制面 (Control Plane)**：配置下发、启停指令。
|
||
- **策略**：**应用层 ARQ**。
|
||
- *逻辑*：发送端发出指令后启动定时器，等待接收端回传 `AckPacket`。若超时 (如 200ms) 未收到 ACK，则触发指数退避重传，直至成功或达到最大重试次数 (Max=3)。
|
||
|
||
### 2.7.4 内部 IPC 背压机制 (Backpressure)
|
||
|
||
- **监控对象**：进程内 `SPSC` 队列（如 `DataReceiver` -\> `SignalProcessor`）。
|
||
- **水位控制**：
|
||
- **High Watermark (80%)**: 队列占用率超过 80% 时，消费者向生产者发送 `BackpressureSignal`。
|
||
- **Low Watermark (50%)**: 降至 50% 以下时，解除背压。
|
||
- **响应动作**：
|
||
- 生产者收到背压信号后，启动 **L1 级流量整形**（参见 2.4.4），主动丢弃低优先级数据（如原始回波切片），仅保留核心元数据入队，防止内存爆炸。
|
||
|
||
-----
|
||
|
||
## 3\. 风险与应对 (Risk Mitigation)
|
||
|
||
| 潜在风险 | 现象 | 应对/缓解措施 |
|
||
| :--- | :--- | :--- |
|
||
| **背压死锁** | 生产者被阻塞等待队列空间，导致无法处理新的控制指令（如停止指令）。 | **队列分离**。数据流使用有界队列，控制流使用无界（或大容量）高优队列，确保控制指令永远能插队。 |
|
||
| **CRC 碰撞** | 极小概率下脏数据通过校验。 | 在协议头增加 `Magic Number` 和 `Payload Length` 双重检查，进一步降低碰撞概率。 |
|
||
| **心跳风暴** | 网络恢复瞬间大量心跳包涌入。 | 接收端实施**速率限制 (Rate Limiting)**，每秒最多处理 N 个心跳包，多余丢弃。 |
|
||
|
||
-----
|
||
|
||
**结论**：
|
||
至此，**第二章：数据接口与通信协议** (2.1 - 2.7) 已全部完成。
|
||
我们构建了一条从物理层 (1GbE/PCIe) 到应用层 (Protobuf)，从内部内存 (SHM) 到外部网络 (UDP)，兼顾**高性能** (Zero-Copy/JUMBO) 与**高可靠** (CRC32/Backpressure) 的数据高速公路。
|