升级包制作与管理：全量、差分、签名加密与版本号策略

各位工程师朋友，今天我们来聊聊升级包制作与管理。这是OTA系统的核心环节，说白了就是「怎么把新软件安全、高效地送到车上去」。我做了这么多年OTA测试，见过太多因为升级包没处理好而翻车的案例。嗯，咱们一个一个来看。

升级包类型：全量 vs 差分

先讲最基础的概念。升级包分两种：全量包和差分包。

全量包，就是把整个系统镜像打包。不管车上装的是哪个版本，直接刷新的就行。好处是简单粗暴，兼容性好。坏处呢？包体巨大。一个IVI系统动辄几个GB，下载时间长，流量费也高。

差分包，只包含新旧版本之间的差异部分。比如你只改了三个文件，差分包就只打包这三个文件的变化量。包体小很多，下载快，流量省。但有个前提——你得知道车上当前是什么版本。

我在项目中遇到过这么个事：某次OTA升级，全量包有2.8GB，差分包只有180MB。你想想看，在4G网络下，2.8GB下载要多久？用户可能直接关车门走人了。所以现在主流方案都是差分升级，除非是第一次刷机或者版本跨度太大。

差分算法：bsdiff vs hdiffpatch

差分包怎么做出来的？靠差分算法。目前业界主流就两个：bsdiff 和 hdiffpatch。

bsdiff 是经典算法，基于后缀排序。它生成的差分包压缩率很高，但有个问题——内存消耗大。我记得有一次在嵌入式设备上跑bsdiff，直接OOM了。所以bsdiff适合服务器端生成差分包，设备端做合并时内存压力也大。

hdiffpatch 是后来者，基于哈希匹配。它的优势是内存占用小，合并速度快。在车机这种资源受限的环境下，hdiffpatch更友好。我个人的习惯是：服务器端用bsdiff生成，设备端用hdiffpatch合并。但要注意，两个算法生成的差分包格式不兼容，别混用。

为什么会这样？因为bsdiff和hdiffpatch的差分算法原理不同。bsdiff找的是最长公共子串，hdiffpatch找的是哈希匹配块。你想想看，一个追求极致压缩率，一个追求运行效率，各有取舍。

升级包签名与加密

升级包在传输过程中可能被篡改，这是安全红线。签名和加密是两道防线。

签名：保证升级包的完整性和来源可信。车机收到升级包后，先验签，确认是官方发布的，没被改过。签名算法一般用RSA或ECDSA。我个人习惯用ECDSA，密钥长度短，签名速度快。

加密：防止升级包内容被窃取。加密算法用AES-256就够了。注意，加密和签名是两回事。加密是防偷看，签名是防篡改。我见过有人只加密不签名，结果被中间人替换了加密包——虽然解不出来，但车机刷了错误的包直接变砖。

我曾经踩过一个坑：升级包签名用的私钥没保护好，泄露了。结果有人伪造了升级包，远程刷了恶意固件。从那以后，我要求所有私钥必须存储在HSM（硬件安全模块）里，不能以文件形式存在服务器上。

版本号管理策略

版本号看似简单，但管不好会出大问题。我见过因为版本号混乱，导致车机反复升级、降级、甚至死循环的案例。

版本号一般用三段式：主版本.次版本.修订版本。比如 2.1.3。主版本表示大功能变更，次版本表示小功能增加，修订版本表示bug修复。

但光有数字不够，还要有版本号比较规则。比如 2.1.3 和 2.1.10 哪个大？按字符串比较，2.1.10 小于 2.1.3，因为 '1' < '3'。所以必须按数字逐段比较。

我建议的版本号管理策略：

• 版本号必须递增，不能回退（除非特殊场景）
• 版本号与升级包一一对应，一个版本号只能对应一个包
• 版本号中嵌入构建时间或构建序号，方便追溯

举个例子，我们项目里用的版本号格式是 2.1.3.20240315，最后一段是构建日期。这样一眼就能看出哪个包更新。

def compare_versions(v1, v2):
    parts1 = [int(x) for x in v1.split('.')]
    parts2 = [int(x) for x in v2.split('.')]
    for a, b in zip(parts1, parts2):
        if a > b:
            return 1
        elif a < b:
            return -1
    return 0

实战中的避坑指南

最后分享几个我踩过的坑，希望能帮大家少走弯路。

坑一：差分包基线版本不匹配。 有一次我们生成了基于版本A的差分包，但车上实际装的是版本A'（小改动）。结果合并失败，车机卡在恢复模式。后来我们强制要求：差分包必须精确匹配基线版本，版本号完全一致才能升级。

坑二：签名算法升级导致旧包失效。 我们把签名算法从RSA-2048升级到RSA-4096，结果所有旧版本的升级包验签失败。因为车机固件里只嵌了旧公钥。所以签名算法升级时，必须考虑向后兼容。

坑三：版本号溢出。 修订版本号用了两位十进制，结果到了99之后没法递增。嗯，这种低级错误我也犯过。现在都用三位数起步，或者直接用时间戳。

好了，关于升级包制作与管理，今天就聊到这里。下一章我们讲升级策略与流程控制，到时候再细聊。记住一句话：升级包是OTA的子弹，子弹不行，枪再好也白搭。