从 40% 到 0.92%：一次征程6 OTA 下载的硬件加速优化全记录

副标题：为什么 HTTPS 下载会烧 CPU，以及一条 objdump 命令如何成为跨团队验收的判据。

摘要

在征程 6（J6）平台的车载 OTA 下载场景中，admsysiApp 下载模块长期占用约 15% CPU，在单核环境下挤占其他业务。我们通过火焰图定位、台架实测与软件包二进制比对三层证据，锁定根因：OTA 自带的 libfoundation.so 内嵌 OpenSSL 构建时未启用 ARMv8 汇编，TLS 1.3 AES-GCM 解密全程退回软件查表实现。经两轮跨团队交付迭代，最终把加解密开销从 约 40% CPU 压到 0.92%（约 43 倍），整机下载 CPU 占用从 15% 降到 10.4%。

本文完整复盘这一过程，重点放在两个层面：技术上——HTTPS/TLS 下载为什么是 CPU 密集型、ARMv8 硬件 AES/GHASH 加速的机理；方法上——如何用「动态火焰图 + 静态指令计数」双证据链把一次"疑似没生效"的优化追到真正的构建配置根因，并沉淀成一条可机械验证的验收判据。

一、背景

车载系统在 OTA（Over-The-Air）升级时，需要从云端通过 HTTPS 下载升级包。HSD方案中OTA升级包约2.5～3GB，下载过程要持续解密、落盘，是一个典型的持续 I/O + 持续计算的混合负载。

在内部项目中，征程 6 平台上的OTA 下载模块 admsysiApp（第三方 OTA 方案商交付）的 CPU 占用长期偏高。初始现象只有一句话——"下载时 CPU 高"——没有明确方向。而 OTA 下载只是后台能力，不应挤占车控、感知、数据回传等关键业务的资源，因此必须把这块开销压下去。

优化前基线（v1.0.6）：

整机下载 CPU 占用 约 15%；
火焰图叶子符号 AES_encrypt 占比 17.65%。

AES_encrypt 是 OpenSSL 中 AES 的软件查表实现。排查到这个信息，方向其实已经基本清楚了——但把"方向"变成"闭环的结论与可落地的修复"，中间还有好几步。

二、关键技术铺垫：HTTPS 下载是 CPU 密集型

在进入排查过程前，有必要先解释清楚一件事：下载文件明明主要是在"等网络"和"写磁盘"，为什么会大量消耗 CPU？

2.1 HTTPS = HTTP + TLS：每字节都要过一遍密码学

HTTPS 是跑在 TLS（Transport Layer Security）上的 HTTP。TLS 1.3 握手完成后，客户端与服务端协商出一组对称密钥，之后传输的每一个字节都要经过：

加密/解密：用对称加密算法（本项目是 AES）对明文/密文做分组运算；
完整性认证：用 MAC/认证算法（本项目是 GCM 模式，用 GHASH）验证数据未被篡改。

TLS 把数据流切分成一条条 record（记录），每条 record 都要独立完成一次「解密 + 认证」。总结来说，下载不是"拷字节到磁盘"，而是一个持续流式解密的过程。

2.2 AES-GCM 的两条计算路径

TLS 1.3 主流密码套件是 AES-GCM。它实际上是两个算法叠在一起：

AES（加密本体）：把 16 字节一块的明文变成密文，是一个 10~14 轮的置换网络；
GCM / GHASH（认证）：在 GF(2^128) 有限域上做乘加运算，为密文生成认证标签。

二者的 CPU 成本是同量级的。很多人（包括我们第一轮）只盯着 AES，会漏掉 GHASH 这另一半。

2.3 硬件加速 vs 软件查表：一个数量级的分水岭

ARMv8-A 架构提供了一组密码学扩展指令：

指令	作用
aese / aesd	AES 单轮加密/解密（硬件执行）
aesmc / aesimc	AES 列混淆/逆混淆
pmull / pmull2	多项式乘法，GHASH 的核心运算

启用这些指令后，AES 与 GHASH 都由专用硬件数据通路完成。OpenSSL 对应的硬件例程符号是 aes_v8_ctr32_encrypt_blocks、gcm_ghash_v8 等。

而软件实现（AES_encrypt、gcm_ghash_4bit）则是靠查表 + 大量通用整数运算来模拟同样的变换，速度要慢一个数量级。

这背后体现的就是本次问题的核心要点：同一颗征程6 芯片，系统库能用硬件指令，而 OTA 自带的库却在跑软件——性能差距是天然的、可量化的。

三、问题定位：从"CPU 高"到"根因锁定"

3.1 火焰图锁定热点

对下载中的 admsysiApp 做 perf 的 cpu-cycles 采样并生成火焰图。叶子符号统计：

叶子符号	占比
[unknown]（stripped 符号）	65.45%
AES_encrypt	17.65%
CRYPTO_gcm128_decrypt	1.34%
ssl3_get_record	0.51%

沿调用链一路下钻，可以确认热点来自 HTTPS 下载的 TLS 解密路径：

符号归属是 /app/adapter/lib/lion/libfoundation.so——OTA 方案商自带的、内嵌了 OpenSSL 的库。

3.2 台架实测：同一颗芯片，两个库两种表现

为了确认"是不是芯片根本不支持硬件 AES"，我们写了 aes_hw_validate.sh（纯 bash、零编译，直接推到台架复跑），得到一组最强对比：

验证项	结果	证据
CPU 是否支持 AES 硬件	✅ 支持	/proc/cpuinfo Features 含 aes pmull sha1 sha2
系统 libcrypto 硬件加速	✅ 已启用	libcrypto.so.3：aese/aesd/aesmc = 2598，pmull = 221
OTA 用的 libfoundation.so	❌ 纯软件	aese/aesd/aesmc = 0，pmull = 0，AES_encrypt 引用 12 处

同一颗 SoC，系统库能用硬件指令，OTA 用的库却是 0 条硬件指令。 通过这条信息，明确锁定了根因：不是征程芯片不支持，是这个库的 OpenSSL 构建时没把支持密码学运算的硬件加速 ARMv8 汇编指令编译进去。

3.3 量化收益上限：21 倍

为了确认优化收益，并判断优化是否值得执行，我们用 openssl speed 在台架上构造硬件（OPENSSL_armcap=0xbd）与软件（OPENSSL_armcap=0x0）两种方案实测，进行数据分析和对比：

cipher	块大小	硬件吞吐	软件吞吐	加速比
AES-128-GCM	1024 B	2.01 GB/s	102.9 MB/s	19.55x
AES-128-GCM	8192 B	2.19 GB/s	102.5 MB/s	21.37x
AES-128-GCM	16384 B	2.18 GB/s	102.9 MB/s	21.22x
AES-256-GCM	8192 B	1.92 GB/s	88.1 MB/s	21.84x

结果显示：启用硬件 AES 后，单就加解密这一块，理论上能拿到约 21 倍的加速。这是一个高 ROI 的优化项，值得推动方案商改进。

四、两轮交付，一次到位：构建配置才是真根因

4.1 Round 2：库重编了，但改错了地方

方案商按第一轮建议出了新版本 v1.1.6，部署复测后 CPU 仍是约 15%，几乎没改善。此时必须区分两种可能性：1）"优化没实现"；2）"优化实现了但没效果"。

先从火焰图看：AES_encrypt 仍占 16.72%，硬件符号仍为 0。同时本轮细查还发现了一个此前漏掉的大头——CRYPTO_gcm128_decrypt 下有 22.8% 落在软件 GHASH（gcm_ghash_4bit 查表实现）上。于是完整成本浮出水面：

软件 AES + 软件 GHASH ≈ 40% CPU。 之前只看 AES 是漏了一半。

接着从 Artifactory 拉取新旧OTA供应商的两个版本的软件包做二进制比对，结果是：libfoundation.so 的 md5、大小、.text 段都变了——库确实重新编译并发布了。但硬件指令计数都是0：

指令	v1.0.6	v1.1.6
aese/aesd/aesmc/aesimc	0	0
pmull/pmull2	0	0

进一步分析，定位到构建配置字符串发现了新线索。

构建配置字符串如下：

platform: Linux 不是合法的 OpenSSL Configure target，官方推荐的应是 linux-aarch64。方案商这次只是给编译器加了交叉工具链的 -I 路径，但Configure target使用的非法的Linux，因此构建没有使用默认清单文件，而是使用的供应商自实现的CMakeLists.txt。

经进一步定位，供应商自实现的CMakeLists.txt文件中并未显示包含汇编文件（.s和.pl文件），导致 aesv8-armx.pl、ghashv8-armx.pl 这些汇编模块世纪没参与编译。旁证是 .text 反而缩小了 65608 字节——若真启用了 asm，汇编例程会让代码段变大才对。

4.2 Round 3：一条命令的验收判据，一次到位

针对 Round 2 的教训，我们不再给"启用 asm"这种目标性描述，而是给了方案商一条可机械验证的验收判据：二进制文件中相应的符号需要能被显示搜索到。

方案商据此修正 Configure target 重新出包（v1.1.6_fix2），静态检查立即得到印证：

项目	v1.0.6	v1.1.6	v1.1.6_fix2
platform:	Linux	Linux	linux-aarch64 ✅
aese	0	0	77
pmull	0	0	59
文件大小	7181304	7115696	7313352（+197656）

文件体积如期变大（汇编例程真正链入），这是"优化代码到位"的物理证据。

复测火焰图：首次出现 ARMv8 硬件符号 aes_v8_ctr32_encrypt_blocks、aes_v8_encrypt、gcm_ghash_v8；软件实现 AES_encrypt、软件 GHASH 全部归零：

指标	优化前	优化后
软件 AES（AES_encrypt）	16.72%	0.000%
软件 GHASH	22.8%	0.000%
加解密合计	~40%	0.92%（约 43x）
tls13_enc	45.44%	3.41%
整机下载 CPU	~15%	10.4%

五、瓶颈转移：加密解决后，寻找是否有新的瓶颈

CPU 从 15% 降到 10.4%，说明原 ~40% 的加密开销一直掩盖着另一部分 I/O 开销；加密归零后，它成了新的主导项。后续几轮我们围绕 I/O 继续深挖，效果不太明显。这里简要交代，因为它同样有方法论价值。

Round 4 / 4.1：CURLOPT_BUFFERSIZE 的两次调优。 第一轮（Round 4）声称把 buffer 从 8KB 提到 128KB，但火焰图显示 recv 调用次数没有下降，反汇编也找不到 0x20000（131072）立即数——改动没落地。第二轮（Round 4.1）确证了改动真的落地（同一指令位置 0x2000 → 0x20000），但收益仍为零：selinux_socket_recvmsg（严格正比于 recv 次数）不降反升。原因是 TLS 1.3 单条 record 明文上限为 16KB，ssl3_read_n 每次最多解出一条 record，应用层 buffer 超过 16KB 后完全无边际收益。

Round 5：netqos 逐包节流才是真约束。 台架实测发现，系统层用 tc（HTB）对 OTA 下载做了 ingress 整形：rate 16Mbit ceil 16Mbit burst 1600b。而 eth1 的 MTU 是 1500——突发额度只有约一个 MTU，shaper 几乎是逐包放行。这才是 buffer 改动无效的深层原因：buffer 从来不是约束，数据到达速率才是——curl 每次被唤醒时 socket 里往往只到了约 1.5KB，根本凑不满一条 record。后续方向转向调大 burst（平均速率不变、数据成块到达），把 syscall 次数降一个数量级。但网络限速目前是硬需求，短期无法修改此约束。

这几轮的共同教训是：先测量、再改代码，且优化生效后必须重新识别瓶颈，不能沿用旧假设。

六、量化结果汇总

指标	优化前（v1.0.6）	优化后（v1.1.6_fix2）	变化
整机下载 CPU 占用	~15%	10.4%	-4.6pp
加解密总开销	~40%	0.92%	约 43 倍
软件 AES	16.72%	0.000%	归零
软件 GHASH	22.8%	0.000%	归零
硬件 AES 符号	无	aes_v8_* / gcm_ghash_v8	出现
tls13_enc	45.44%	3.41%	-42pp

口径说明：优化前的 ~15% 与优化后的 10.4% 均为同一 perf cpu-cycles 采样口径下的整机 CPU 占比；43 倍来自火焰图实测的加解密占比（40% → 0.92%），与台架 openssl speed 实测的 21 倍同量级（后者单测 AES-GCM、未含 GHASH 一并修复的增量）。

七、方法论沉淀

这次排查能闭环，靠的不是某一次灵感，而是几条可复用的工程原则：

动态 + 静态双证据，独立互证。 火焰图证明"在跑软件 AES"，objdump 指令计数证明"库里没有硬件指令"，二者独立、互相印证。任何单一证据都可能被质疑为采样偏差或环境问题。
给合作方可自检的验收判据。 objdump -d lib.so | grep -c aese 非 0 才验收——一条命令、不依赖上车、无歧义。Round 2 的失败，正是 Round 1 只给了"启用 asm"的目标描述、缺了可机械验证的判据；Round 3 的 fix2 包证明判据有效，方案商据此一次到位。
二进制比对能区分"没优化"与"优化没到位"。 md5/大小/.text 变化证明库确实重编（排除"没部署"），构建串 platform: Linux 直接暴露改错的位置。只看火焰图，只能得出"仍然没效果"。
可证伪的推断要留痕。 例如"若真启用 asm，代码段应变大"这条推断，在 Round 3 被 +197656 字节的体积印证；而"库没被替换"的猜想被证伪后，我们在过程文档中标注修正而非删除，避免后人重走弯路。
优化生效后要重新识别瓶颈。 CPU 未达预期并非优化不彻底，而是原瓶颈消除后暴露了次级瓶颈；沿用旧假设继续往加密方向排查会完全走错。

八、附：可复用的验证命令

结语

这次优化最深的体会是：性能问题的难点往往不在"算法本身"，而在"证明它、定位它、让它真的被改对"。 从火焰图的一个符号，到台架上一组 21 倍的实测，再到一条 objdump 命令作为跨团队验收判据，真正让 CPU 从 15% 降到 10.4% 的，是把结论做成了可证伪、可自检、可复现的证据链。

对于征程 6 这类搭载了完整 ARMv8 密码学扩展的芯片，硬件加速带来的性能优势是"零成本"且"收益巨大"的——前提是构建链路上任何一环都不能悄悄退化成软件实现。希望本文的排查路径与判据，能帮到同样在做 HTTPS/TLS 相关 CPU 优化的同学。