3. MAVLink 1.0 vs 2.0：版本差异、安全增强、兼容性策略、迁移指南
MAVLink 协议从 1.0 升级到 2.0，不是简单的修修补补。说白了，这是一次从「能用」到「好用、安全」的跨越。我最早接触 MAVLink 1.0 时，觉得它轻量、简单，挺好用的。直到有一次在公共频段做多机协同测试，发现有人能直接解析我们的数据包……嗯，从那以后，我对协议安全性的看法彻底变了。
3.1 为什么要有 MAVLink 2.0？
MAVLink 1.0 设计于 2010 年左右，那时候无人机还没这么普及。它的核心目标是「轻量」—— 8 字节 payload 起步，非常适合 8 位 MCU。但时代变了：
- Payload 不够用：1.0 的 payload 最大 255 字节，对于高精度地图、图像特征点传输来说，太局促了。
- 没有安全机制：1.0 的 CRC 校验只能防误码，防不了恶意篡改。我在一次竞品演示中亲眼看到，有人用简单的 UDP 注入工具就能伪造飞控指令。
- 消息 ID 空间不足：1.0 只有 8 位消息 ID（0-255），社区自定义消息经常冲突。
- 缺少签名机制：无法验证消息来源是否可信。
MAVLink 2.0 在 2017 年正式发布，它向后兼容 1.0，但引入了大量新特性。我个人习惯把 2.0 看作「1.0 的完全体」—— 保留了轻量的灵魂，补上了安全的短板。
3.2 核心差异对比
先看一张对比表，把关键差异列清楚：
| 特性 | MAVLink 1.0 | MAVLink 2.0 |
|---|---|---|
| 帧头长度 | 6 字节 | 10-14 字节（含签名） |
| Payload 最大长度 | 255 字节 | 255 字节（可扩展至 512） |
| 消息 ID 宽度 | 8 位（0-255） | 24 位（0-16777215） |
| 签名支持 | 无 | 可选（13 字节 HMAC-SHA256） |
| 兼容模式 | 不兼容 2.0 | 可接收 1.0 帧 |
| 目标系统/组件 | 仅目标系统（1 字节） | 目标系统（1 字节）+ 目标组件（1 字节） |
| CRC 校验 | 16 位 CRC（X.25） | 16 位 CRC（X.25）+ 额外 CRC 种子 |
你可能会问：「为什么 payload 最大长度还是 255？」其实 2.0 的帧头里有一个 payload 长度字段，理论上可以扩展到 512 字节。但为了兼容性，目前主流实现（如 PX4、ArduPilot）仍然限制在 255 字节以内。我个人觉得，对于绝大多数任务规划场景，255 字节已经够用了。
3.3 安全增强：签名机制详解
MAVLink 2.0 最大的亮点，就是引入了 消息签名。这玩意儿怎么工作的？
每个签名包含 13 字节：
- 8 字节时间戳：自 2015 年 1 月 1 日以来的 10 微秒计数。用于防止重放攻击。
- 5 字节签名值：HMAC-SHA256 截断结果。密钥是 32 字节的共享密钥。
签名覆盖整个数据包（包括帧头、payload、CRC）。接收方用同样的密钥和时间戳重新计算签名，如果匹配，说明消息未被篡改且来自可信源。
关键点：签名是可选的。你可以选择对所有消息签名，也可以只对关键指令（如 ARM、TAKEOFF、LAND）签名。我个人建议：在任务规划阶段，至少对 COMMAND_INT 和 MISSION_ITEM_INT 签名。
我曾经在一个客户现场遇到过这样的问题：他们的地面站和无人机之间通过 4G 网络通信，结果有人用中间人攻击篡改了航点数据，导致无人机飞到了禁飞区。后来我们启用了 MAVLink 2.0 签名，问题彻底解决。
小技巧：签名密钥不要硬编码在代码里。我习惯在飞控启动时通过安全通道（如加密的串口或 TLS）下发密钥，或者使用预共享密钥 + 设备序列号的组合。
3.4 兼容性策略：如何让 1.0 和 2.0 共存？
实际项目中，你不可能一夜之间把所有设备都升级到 2.0。兼容性策略很重要。我总结了几种常见场景：
场景一：地面站支持 2.0，飞控只支持 1.0
地面站发送 2.0 帧时，飞控会直接丢弃（因为帧头中的 magic byte 不同）。解决办法：地面站检测到飞控版本后，降级为 1.0 通信。MAVSDK 和 QGroundControl 都支持自动协商。
场景二：飞控支持 2.0，地面站只支持 1.0
飞控收到 1.0 帧后，可以用 1.0 格式回复。MAVLink 2.0 的兼容模式就是干这个的。飞控在发送时，如果检测到对方是 1.0，就使用 1.0 帧格式。
场景三：混合网络（部分设备 2.0，部分 1.0）
这是最头疼的。我建议的做法是：
- 所有设备默认发送 2.0 帧。
- 如果连续 3 次收不到回复，降级为 1.0 重试。
- 在系统 ID 和组件 ID 层面做好隔离，避免消息混淆。
注意：降级通信意味着失去签名保护。如果你在安全敏感环境中工作，建议强制所有设备升级到 2.0，不要开启降级。
3.5 迁移指南：从 1.0 到 2.0 的实操步骤
如果你正在维护一个基于 MAVLink 1.0 的任务规划系统，迁移到 2.0 可以按以下步骤来：
步骤 1：更新协议定义文件
从 MAVLink 官方仓库 拉取最新的 XML 定义文件。注意，2.0 的 XML 格式和 1.0 略有不同，多了 <version>2</version> 声明。
// 旧的 1.0 生成命令
python mavgenerate.py --lang=C --xml=common.xml --output=./mavlink_v1
// 新的 2.0 生成命令
python mavgenerate.py --lang=C --xml=common.xml --output=./mavlink_v2 --version=2.0步骤 2：修改消息发送/接收逻辑
MAVLink 2.0 的帧结构变了，发送和接收函数也不同。以 C 语言为例：
// 1.0 发送方式
mavlink_msg_command_long_send(chan, target_sys, target_comp, cmd, param1, ...);
// 2.0 发送方式（多了签名参数）
mavlink_msg_command_long_send(chan, target_sys, target_comp, cmd, param1, ...);
// 或者手动设置签名
mavlink_msg_command_long_send_struct(chan, &cmd);接收端的变化更大：
// 1.0 接收
mavlink_message_t msg;
mavlink_status_t status;
mavlink_parse_char(chan, c, &msg, &status);
// 2.0 接收（需要处理签名验证）
mavlink_message_t msg;
mavlink_status_t status;
mavlink_parse_char(chan, c, &msg, &status);
if (status.signing && !mavlink_signature_check(&msg, secret_key)) {
// 签名验证失败，丢弃
continue;
}步骤 3：启用签名（可选但推荐）
在飞控端和地面站端分别设置相同的 32 字节密钥。以 PX4 为例：
// 在飞控启动脚本中设置
param set MAV_2_SIGNING_KEY 0123456789abcdef0123456789abcdef
param set MAV_2_SIGNING 1步骤 4：测试兼容性
先用 2.0 模式连接，确认所有消息正常收发。然后模拟 1.0 设备接入，验证降级逻辑。我习惯用 Wireshark 抓包，配合 MAVLink 解析插件，可以直观看到帧格式差异。
避坑指南：我曾经在迁移时犯过一个低级错误 —— 忘记更新 CRC 种子表。MAVLink 2.0 的 CRC 计算方式变了，如果用了旧的 CRC 表，所有消息都会被接收方丢弃。记得重新生成 mavlink_crc256.h。
3.6 版本选择建议
说了这么多，到底该用哪个版本？我的建议很简单：
- 新项目：直接用 MAVLink 2.0，开启签名。别给自己挖坑。
- 旧项目维护：如果设备不支持升级，保持 1.0。但建议在网关层做协议转换，把 1.0 转成 2.0 再接入地面站。
- 混合场景：使用 MAVLink 路由器（如 MAVProxy、mavlink-router）做协议桥接。这些工具可以自动处理版本协商。
下面这张图展示了 MAVLink 2.0 的帧结构，以及签名如何保护数据完整性：
嗯，这张图把 2.0 的帧结构拆得很清楚了。你注意看签名覆盖范围 —— 它保护的是整个数据包，包括帧头。这意味着攻击者无法篡改任何字段，包括消息 ID 和 payload。
最后说一句：MAVLink 2.0 不是银弹。签名会增加 13 字节开销，对于高频率遥测（如 IMU 数据，100Hz 以上），CPU 负载也会上升。我一般只在控制指令和任务上传时启用签名，遥测数据保持明文。这样既保证了安全，又不影响性能。