第4章协议栈总体架构设计

第4章协议栈总体架构设计：分层设计原则、弹载协议栈参考模型与接口定义

好，咱们进入正题。协议栈总体架构设计，说白了就是给弹载数据链搭骨架。我见过不少团队，一上来就写代码，写到一半发现层与层之间耦合得跟麻花似的，改一处动全身。嗯，这就是没做好顶层设计。

今天咱们就聊聊，弹载协议栈到底该怎么分层，每层干什么活，层与层之间怎么打招呼。

4.1 分层设计原则：为什么非分不可？

你想想看，一个导弹从发射到命中，要经历多少环节？传感器采集、目标识别、指令下发、遥测回传……如果所有功能都揉在一起，那代码维护起来就是噩梦。

我个人习惯，分层设计遵循三个核心原则：

高内聚、低耦合：每层只干自己那摊事。物理层只管发比特流，别去操心数据包重传。
接口标准化：层与层之间通过固定接口通信。接口一旦定好，各层可以并行开发。
可替换性：比如今天用跳频物理层，明天换扩频物理层，上层代码一行都不用改。

重要提醒：弹载环境特殊，分层不能像互联网协议那么“厚”。每多一层封装，就多一次延迟。我在项目中遇到过，某次因为传输层加了太多重传机制，导致实时控制指令延迟超标，差点把试验搞砸。

4.2 弹载协议栈参考模型：五层架构

咱们参考OSI七层模型，但做了裁剪。弹载场景不需要表示层和会话层，那些花架子去掉。最终我们定下五层：

层次	名称	核心职责	典型协议/技术
第5层	应用层	业务数据处理、指令解析	火控指令、遥测帧、图像压缩
第4层	传输层	端到端可靠传输、流量控制	类UDP（实时）、轻量TCP（可靠）
第3层	网络层	路由寻址、组网管理	动态TDMA、自组网路由
第2层	MAC层	信道接入、帧封装、差错控制	TDMA时隙分配、CRC校验
第1层	物理层	信号调制解调、射频收发	OFDM、跳频、扩频

为什么这么分？我解释一下每层的设计思路。

4.2.1 物理层：最底层的硬功夫

物理层负责把0和1变成电磁波发出去。弹载环境干扰大、多普勒频移严重，所以物理层必须扛得住。

我记得有一次外场测试，导弹高速飞行时信号突然断了。查了半天，发现是物理层的自动增益控制（AGC）跟不上速度变化。从那以后，我要求物理层必须支持快速AGC锁定，锁定时间不超过1毫秒。

实战技巧：弹载物理层建议预留多种调制模式。平时用BPSK保证链路稳定，信道好时切到QPSK或16QAM提速率。这个切换逻辑由MAC层触发，物理层只负责执行。

4.2.2 MAC层：信道的交通警察

MAC层解决的是“谁什么时候发”的问题。弹载场景下，多枚导弹同时通信，信道必须有序。

我们一般采用动态TDMA方案。每个导弹分配一个时隙，但时隙长度可以动态调整。比如某枚导弹需要回传高清图像，就给它多分几个时隙。

MAC层还要做帧封装。一个典型的MAC帧结构如下：

| 帧头(4B) | 源地址(2B) | 目的地址(2B) | 帧类型(1B) | 载荷长度(2B) | 载荷(NB) | CRC(2B) |

嗯，这里要注意：CRC校验必须硬件加速。软件算CRC在高速场景下根本来不及。我曾经吃过这个亏，后来全部改成硬件CRC引擎。

4.2.3 网络层：找路的高手

网络层负责路由。单枚导弹不需要这层，但多弹协同、编队飞行时，网络层就至关重要了。

弹载自组网路由和地面不一样。节点高速移动，拓扑变化快。我们用的是一种基于预测的路由协议——根据导弹的弹道轨迹预判下一跳位置，提前建立路由。

避坑指南：我曾经在路由协议里加入了太多Hello包来维护邻居表，结果Hello包占用了30%的信道带宽。后来改成事件触发式更新，只在拓扑变化时才发路由更新，带宽占用降到5%以下。

4.2.4 传输层：端到端的管家

传输层提供端到端服务。弹载场景下，我们通常提供两种服务：

实时通道（类UDP）：用于火控指令、飞行控制。不重传，延迟优先。
可靠通道（轻量TCP）：用于遥测数据、日志回传。需要确认重传，但窗口要小。

我个人建议，可靠通道的确认机制用选择性重传，别用回退N步。弹载链路误码率不低，回退N步会导致大量无效重传。

4.2.5 应用层：业务逻辑的终点

应用层最贴近用户。它解析来自地面的控制指令，也打包导弹的状态数据。

举个例子，一个典型的遥测帧格式：

| 帧同步(2B) | 时间戳(4B) | 经度(4B) | 纬度(4B) | 高度(4B) | 速度(4B) | 姿态(6B) | 状态字(2B) |

应用层设计时，一定要考虑向后兼容。我见过一个项目，升级后遥测帧格式变了，地面站解析不了，所有数据都丢了。从那以后，我要求每个应用层帧头都带版本号。

4.3 接口定义：层与层之间的契约

接口定义是协议栈设计中最容易被忽视的环节。接口定得好，各层开发可以并行；接口定得差，联调时就是灾难。

我们采用服务原语的方式定义接口。每层向上层提供四种原语：

Request：上层请求下层做某事
Indication：下层通知上层有事件发生
Response：上层响应下层的通知
Confirm：下层确认上层的请求已完成

以MAC层向上层（网络层）提供的接口为例：

// MAC层向上提供的服务原语
MAC_DATA_REQUEST( dest_addr, data, len, priority )
    // 网络层调用，请求发送数据
    // 参数：目的地址、数据指针、长度、优先级

MAC_DATA_INDICATION( src_addr, data, len, rssi )
    // MAC层调用，通知网络层收到数据
    // 参数：源地址、数据指针、长度、信号强度

MAC_STATUS_INDICATION( status_code, param )
    // MAC层调用，通知网络层状态变化
    // 参数：状态码、附加参数

关键设计点：接口参数中一定要包含优先级字段。弹载场景下，火控指令的优先级必须高于遥测数据。MAC层看到高优先级数据，可以打断当前的低优先级发送。

物理层向MAC层提供的接口相对简单：

// 物理层向上提供的服务原语
PHY_DATA_REQUEST( freq, mode, data, len )
    // MAC层调用，请求发送物理帧
    // 参数：中心频率、调制模式、数据、长度

PHY_DATA_INDICATION( freq, rssi, snr, data, len )
    // 物理层调用，通知MAC层收到物理帧
    // 参数：接收频率、信号强度、信噪比、数据、长度

你可能会问，为什么物理层接口要带频率和调制模式？因为弹载通信经常需要跳频，MAC层要控制物理层在哪个频点发。

4.4 接口设计的几个坑

最后分享几个我踩过的坑：

接口参数别太多：曾经一个接口传了十几个参数，调用者记都记不住。后来改成结构体传参，清爽多了。
异步接口要带回调：物理层发送是异步的，发完要通知MAC层。如果不用回调，就得轮询状态，浪费CPU。
接口版本要管理：协议栈迭代过程中，接口会变。我建议每个接口文件开头都写个版本变更记录，谁改了啥一目了然。

好了，这一章就到这。分层设计是协议栈的骨架，骨架搭好了，后面填肉就顺了。下一章咱们聊聊物理层的具体实现——跳频和扩频到底怎么选。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录