第二讲 加密算法的硬核指标：吞吐量、延迟与CPU占用率
选加密算法，光看“安不安全”可不够。
我在处理支付系统加密时发现，很多团队一上来就问“AES-256够不够安全？”，却没想过QPS能不能扛住。结果上线没多久，CPU直接飙满，延迟爆炸。
说白了，性能指标就是加密算法的“体检报告”。今天我们就来聊聊三个最关键的：吞吐量、延迟、CPU占用率。
2.1 三个指标，一个都别落下
先给你一张对比表，快速建立整体认知：
| 指标 | 定义 | 业务影响 |
|---|---|---|
| 吞吐量 | 单位时间内能处理的数据量（MB/s 或 TPS） | 决定了系统的并发处理上限 |
| 延迟 | 单次加密或解密操作所需的时间（毫秒/微秒） | 直接影响用户体验，API 响应时间 |
| CPU占用率 | 执行加密操作时占用的 CPU 计算资源百分比 | 影响服务器部署密度和成本 |
2.2 吞吐量：加密的“高速公路”有多宽？
吞吐量，就是衡量加密算法“搬砖能力”的指标。你想想看，一个算法再安全，如果跑一次要等5秒，业务还怎么搞？
我个人习惯，看吞吐量时，主要关注两个场景：流式加密和块式加密。
避坑指南
我曾经在做一个日志加密的项目，直接用了AES-256-CBC模式。
跑了一周才发现，吞吐量只有硬件加速时的30%。后来换成AES-256-GCM，吞吐量直接翻了3倍。
原因很关键：CBC模式不支持并行加解密，而GCM模式可以。
为啥GCM会快？因为GCM的CTR（计数器模式）天生支持并行。你可以同时加密多个数据块，就像同时开多个收费站。
而CBC模式前一个块没算完，后一个块就得等着。典型的“串行瓶颈”。
- 对称加密：AES-GCM、ChaCha20-Poly1305 是吞吐量第一梯队。
- 非对称加密：RSA 加密小数据还行，大数据吞吐量惨不忍睹。ECC（椭圆曲线）要好得多。
2.3 延迟：关注那“该死的”最慢链路
延迟这东西，千万不能只看平均值。我见过太多只看平均延迟的案例，结果上线就被p99延迟打脸。
有一次我优化一个API接口，平均延迟只有2ms，但p99延迟高达200ms。为什么？因为非对称加密在最坏情况下，RSA私钥解密操作是极度耗时的。
重要提示
别只看加密效率，忽略了密钥协商的延迟。
比如TLS握手，ECDHE密钥交换的首次延迟大约在5-10ms（ECC），而RSA交换可能高达20-30ms。虽然就十几毫秒，但在高并发场景下，这个“启动成本”会让连接池容易打满。
这么说吧，延迟与吞吐量之间有个跷跷板效应。
吞吐量高不代表延迟低。我举个例子：
实测对比数据（Intel Xeon, 256字节数据）：
- AES-256-GCM: 延迟约 0.05ms，吞吐量约 5GB/s
- RSA-2048 加密: 延迟约 0.3ms，吞吐量约 800MB/s
- RSA-2048 解密: 延迟约 8ms，吞吐量约 30MB/s
看出来了吗？RSA解密简直是性能黑洞。
2.4 CPU占用率：真金白银的成本
CPU占用率，决定了你服务器的运行成本。在KMS里，这就是白花花的银子。
我建议，在选型时问自己三个问题：
- 能不能硬件加速？很多现代CPU有AES-NI指令集，用AES加密几乎不占CPU。
- 上下文切换多不多？频繁调用KMS API进行加密，每次调用都是一次网络IO + CPU运算，代价很大。
- 内存使用大不大？有些算法需要大量内存来跑查找表，比如SM4的扩展。
我在项目中遇到过，一个客户疯狂使用RSA加密小数据块。每次就加密128字节，每次都跑RSA-4096。CPU占用率直接从20%飙到80%，服务器数量翻了3倍。后来指导他改成AES-256-GCM加密数据，RSA只用来加密AES密钥。CPU占用直接降回到25%以下。
给你一个简单的成本估算公式：
单服务器加密成本 ≈ (CPU占用率_加密) × (单核心价格) × (核心数) 如果一个加密操作吃掉30%的CPU，另一台服务器可能就白买了。
2.5 实战：如何快速评估这三个指标？
别光靠理论，得动手跑一跑。
我一般用openssl speed来跑基准，比如：
# 测试 AES-256-GCM 的吞吐量
openssl speed -evp aes-256-gcm -multi 4
# 测试 RSA 2048 的签名延迟
openssl speed rsa2048不过要注意，测试环境跟线上永远不一致。我习惯在压测中，额外记录netdata或perf的CPU热点。有些库为了兼容性，没有使用CPU的SIMD指令，导致性能会慢5-10倍。
选型速查
- 高吞吐 + 低延迟 + 低CPU：无脑选 AES-256-GCM（有硬件加速），或者 ChaCha20-Poly1305（无硬件加速，软实现快）。
- 非对称场景：ECDSA + ECDH 配合 AES，延迟和CPU比纯RSA低一个数量级。
- 低功耗/物联网：优先选 ChaCha20-Poly1305，因为它在 ARM 和无AES加速的CPU上表现更好。
2.6 核心知识图：一张图看懂性能指标体系
下面的SVG图，帮你理清三个指标的关系、权衡以及应用场景。
看完这张图，你应该很清楚三个指标怎么互相制约了。你看，选择算法时，一定要先跑基准测试。不要相信网上某个“最快”的结论，那可能是在特定硬件上跑出来的。
我记得之前在ARM服务器上，ChaCha20-Poly1305的吞吐量竟然比AES-256-GCM还高30%。因为那台ARM芯片没有AES加速指令。所以说，你的场景只能由你自己验证。