第四章 下载与传输机制：断点续传、多线程下载、流量控制、传输加密

各位工程师，咱们今天聊点实在的。OTA升级的下载传输，说白了就是怎么把几十兆甚至几个G的升级包，从云端安全、稳定、快速地搬到车机里。

我见过不少项目，升级包做得挺好，校验也没问题，结果卡在下载环节——下载到一半断了重来、流量跑超了被用户投诉、传输过程被中间人篡改……这些坑，我基本都踩过。今天就把这些经验掰开揉碎了讲。

4.1 断点续传：断了别怕，接着干

先问个问题：你下载一个500MB的升级包，已经下了490MB，突然进隧道没信号了。如果没有断点续传，会怎样？

答案是：从头再来。用户得再等半小时，流量还得再跑500MB。这体验，换谁都得骂娘。

断点续传的核心逻辑其实很简单：记录已下载的位置，下次接着下载。

我在项目中遇到过一种情况：车机在下载过程中突然断电，重启后进度文件丢了。嗯，这是个很典型的坑。后来我强制要求：每下载完一个分片，必须同步写一次进度文件。虽然多写几次Flash，但安全第一。

struct DownloadProgress {
    uint32_t magic;          // 魔数，校验数据完整性
    uint32_t totalSize;      // 总大小
    uint32_t downloadedSize; // 已下载大小
    uint32_t crc32;          // 结构体自身CRC
};

4.2 多线程下载：把带宽吃满

单线程下载，说白了就是一条车道跑车。网络再好，也受限于TCP的慢启动和拥塞控制。多线程下载，就是开多条车道并行跑。

为什么多线程能提速？

• 每个线程独立建立TCP连接，绕过单连接的拥塞窗口限制
• 利用HTTP Range分片，每个线程下载不同区间
• 某个线程卡住时，其他线程不受影响

但注意，不是线程越多越好。我见过有人开32个线程下载一个100MB的包，结果大部分时间花在线程切换和连接建立上，反而更慢。

4.3 流量控制：别让用户心疼流量费

智能座舱的OTA升级，很多场景用的是车载4G/5G流量。用户套餐可能只有几个G，你一个升级包就干掉了500MB，用户不投诉才怪。

流量控制的核心策略：

• 按需下载：只下载需要的分片，不预下载整个包
• 限速下载：限制下载速率，避免占满所有带宽影响其他业务
• 流量统计：实时统计已消耗流量，超过阈值时暂停或提示用户
• Wi-Fi优先：检测到Wi-Fi连接时自动切换，优先使用免费流量

我个人习惯在车机端实现一个流量预算管理器。每次升级前，先检查当前周期已用流量，如果接近套餐上限，就弹窗让用户确认是否继续。

// 令牌桶算法实现限速
#define TOKEN_RATE 102400  // 100KB/s
#define BUCKET_SIZE 512000 // 500KB

void download_with_throttle() {
    while (has_data_to_download()) {
        if (token_bucket_consume(1)) {
            // 下载一个分片
            download_chunk();
        } else {
            // 令牌不足，等待
            delay(10);
        }
    }
}

你想想看，如果不做限速，OTA下载可能会把T-Box的带宽占满，导致导航地图加载失败、语音助手响应延迟。这些用户体验问题，最终都会变成你的bug单。

4.4 传输加密：防篡改、防窃听

升级包在传输过程中，如果被中间人篡改，后果不堪设想。轻则升级失败，重则刷入恶意固件，整个座舱系统被攻破。

传输加密的三道防线：

1. TLS/HTTPS：传输层加密，防止窃听和中间人攻击
2. 数字签名：应用层签名，确保包体完整性
3. 双向认证：车机验证服务器身份，服务器验证车机合法性

我曾经在一个项目中发现，有些车厂为了省成本，只用了HTTP没上HTTPS。结果升级包在公网传输时被运营商插入了广告脚本……嗯，从那以后，我坚持所有OTA传输必须走HTTPS，没得商量。

4.5 整体传输架构

把上面四个机制串起来，就是一套完整的下载传输架构。我画了一张图，帮你理清关系。

从这张图你能看到，整个下载传输不是孤立的。断点续传、多线程、流量控制、加密，这四个模块在车机端的下载管理器里协同工作。任何一个环节出问题，升级体验都会打折扣。