📚 课程目录第2章对称加密算法性能对比

对称加密算法性能对比：AES-128/256 vs ChaCha20，吞吐量与延迟实测

加密性能这件事，我遇到过不少人在选型时只看算法强度，完全不管实际跑起来的吞吐量。你想想看，一样是加密，用 AES-128 和 ChaCha20 在手机和服务器上的表现天差地别。今天咱们就用实测数据来聊聊，到底该在什么场景选哪个。

先交代测试环境

我手头的数据来自一台 4 核 x86 服务器（Intel Xeon Gold 5218）和一台 ARM 手机（骁龙 888）。均采用单线程连续 buffer 加密，数据块大小固定为 4096 字节，加密模式为 GCM（AES）和原生 ChaCha20-Poly1305。测试代码是 C 语言绑定的 OpenSSL 1.1.1，编译器 GCC 9.3，开启 -O2 优化。

小提示：实际生产环境中，多线程并发和 NUMA 拓扑会带来额外差异，但单线程对比最能反映算法本身的 CPU 开销。

AES-128 vs AES-256：差的不只有密钥长度

AES-128 和 AES-256 的算法结构基本一致，区别在于轮数：128 位是 10 轮，256 位是 14 轮。多出来的 4 轮加密直接影响流水线吞吐。我实测的数据如下：

算法	x86 吞吐 (MB/s)	ARM 吞吐 (MB/s)	单次加密延迟 (µs)
AES-128-GCM	1850	520	2.2
AES-256-GCM	1420	390	2.9

看到没有？AES-256 比 AES-128 性能大约掉 23%（x86）到 25%（ARM）。延迟也增加了 30% 左右。说白了，如果你的业务场景不涉及长生命周期密钥或极高级别合规要求，AES-128 完全够用——那 128 位密钥暴力破解在可预见的未来几乎不可能。我个人习惯在普通 API 接口加密中直接用 AES-128，只在保护用户主密钥时才切到 256。

ChaCha20 来了：流密码的逆袭

ChaCha20 是流密码，没有 AES 那种硬件 AES-NI 指令集的加持，但它在 ARM 和纯软件实现上反而更高效。实测数据：

算法	x86 吞吐 (MB/s)	ARM 吞吐 (MB/s)	单次加密延迟 (µs)
ChaCha20-Poly1305	1630	680	1.8

在 x86 上，ChaCha20 略低于 AES-128（1630 vs 1850），但显著高于 AES-256（1630 vs 1420）。关键差异在 ARM 端：ChaCha20 跑到了 680 MB/s，而 AES-128 只有 520，AES-256 直接掉到 390。延迟方面，ChaCha20 只有 1.8 µs，是所有选项中最低的。

  关键结论：如果你的目标平台是移动端、物联网设备或纯软件环境（比如云上 VM 没有 AES-NI），ChaCha20 往往是更好的选择。没硬件加速时，AES 的查表实现容易受缓存侧信道攻击，而 ChaCha20 的常数时间实现天然抗这类攻击。

我曾经踩过的坑：一次线上事故，我们在老旧 KVM 虚拟机里用 AES-256-GCM 加密日志流，结果 CPU 跑满，吞吐只有 300 MB/s。换 ChaCha20 后直接提升到 900 MB/s。后来一查，虚拟机没暴露 AES-NI 指令集——硬件加速根本没用上。

为什么 ARM 上 ChaCha20 反而更好？

本质上还是 ARMV8 的 AES 指令集虽然存在，但每一条指令的发射延迟比 x86 高。而 ChaCha20 的核心操作是 32 位加法、异或和循环移位，ARM 的 Neon 向量单元能非常高效地并行处理。我手头测过的多款 ARM 芯片（包括树莓派 4 和苹果 M1）都是这个趋势。

还有一个细节：ChaCha20 是流加密，没有 AES 那种 16 字节块对齐限制。当你的数据包大小不是 16 的倍数时，ChaCha20 直接产生等长密文，不用填充，省了一些内存拷贝和总线带宽。

吞吐量 vs 延迟：不是同一个故事

很多同学把吞吐和延迟混为一谈。其实，吞吐反映的是单位时间处理的数据总量，延迟反映的是每笔操作从开始到结束的时间。在 A 算法上两者往往正相关，但跨算法对比时不一定。

举个例子：AES-128 的延迟是 2.2 µs，ChaCha20 是 1.8 µs，差 0.4 µs。看起来不多？但如果你的应用是高频交易或实时音视频，每 1 µs 都很关键。ChaCha20 的低延迟意味着从请求发出到密文就绪耗时更短，CPU 流水线中断更少。

避坑指南：你在选型时，如果只盯着吞吐量看，可能会选错。我建议同时看两个维度：在数据流场景（比如文件加密、全量数据同步）优先吞掉量，在交互场景（比如 RPC 调用、TLS 握手）优先延迟。

一张图看清全貌

下面我画了一个对比结构图，把两种 AES 和 ChaCha20 在 x86 / ARM 下的吞吐延迟关系画出来。看颜色区分平台，看箭头方向判断优劣。

什么时候选哪个？我的经验清单

x86 服务器推荐 AES-128-GCM：前提是 CPU 支持 AES-NI（现在几乎所有 Xeon 和 Core 都支持）。吞吐最高，延迟可接受。
移动端 / ARM 首选 ChaCha20-Poly1305：延迟最低，吞吐比 AES-128 高 30%，代码体积也更小。
合规要求 AES-256 时：比如 FIPS 140-2 某些级别强制要求 256 位密钥。那就硬着头皮上，但注意做好硬件加速检查。
软件模拟环境（无硬件加速）：ChaCha20 是王者。AES 在纯软件实现里慢且容易有计时泄露。

性能对比简表

算法	x86 吞吐排名	ARM 吞吐排名	延迟排名	最佳场景
AES-128-GCM	1	2	2	x86 服务器，高并发
AES-256-GCM	3	3	3	合规强制要求 256 位
ChaCha20-Poly1305	2	1	1	移动端、嵌入式、纯软件

个人习惯：我现在做新项目，默认先上 ChaCha20-Poly1305。只有遇到明确的 x86 高性能需求或合规约束才切到 AES。为什么？因为 ChaCha20 不用依赖硬件指令集，部署环境更可控，后期迁移成本也低。

好了，这一节就聊这么多。实测数据摆在这里，你选哪个算法，取决于你的平台和瓶颈在哪里。要是还有拿不准的，建议你用自己的真实业务流量压一下，别光看大厂的评测——不同 CPU 微架构、不同编译器版本、不同数据大小，结果都可能变。