1. 加密参数配置概述
我参与过的几个高并发项目里，加密配置往往是被「随手写死」的。直到线上出现超时报警，大家才意识到：AES-256-CBC 和 AES-128-GCM 在吞吐量上能差出一个数量级。所以我一直觉得，加密参数配置不是安全工程师的专属任务，它直接决定了你的系统能撑住多少并发，能吐多少数据。
这一章我们先站高点，看看加密参数配置到底涵盖哪些东西，以及它为什么和并发、吞吐绑在一起。说白了，这不是纯安全话题，而是一个系统设计话题。
1.1 什么是加密参数配置？
加密参数配置，就是你告诉加密引擎「用什么算法、多长的密钥、怎么分组、怎么填满最后一块、用什么工作模式」。把这些参数组合好，才能正确加密、解密。
常见参数包括：
- 加密算法：AES、SM4、ChaCha20 等。
- 密钥长度：128、192、256 位。
- 工作模式：ECB、CBC、CTR、GCM、CCM 等。
- 填充方式：PKCS7、NoPadding、ISO10126 等。
- 初始向量（IV）：长度、生成策略、复用规则。
- 认证标签长度（AEAD 模式）：如 GCM 的 Tag 长度。
不同的参数组合，安全强度和性能差异极大。我整理了一张常用算法/模式对比表，方便你快速筛选：
| 算法 | 模式 | 密钥长度（位） | 吞吐量（MB/s） | 硬件加速 | 安全特征 |
|---|---|---|---|---|---|
| AES | ECB | 128 / 256 | ~800 | 是（AES-NI） | 不推荐，有模式弱点 |
| AES | CBC | 128 / 256 | ~600 | 是（AES-NI） | 需 IV，可被填充预言攻击 |
| AES | GCM | 128 / 256 | ~700 | 是（AES-NI + PCLMULQDQ） | AEAD，推荐 |
| ChaCha20 | Poly1305 | 256 | ~500 | 否（软件实现高效） | AEAD，移动端友好 |
| SM4 | GCM | 128 | ~400 | 部分国产芯片支持 | 国密标准，AEAD |
注意：表里的吞吐量是在单线程纯计算下测的，实际并发环境还要考虑上下文切换和锁竞争。
1.2 为什么并发与吞吐是关键？
你想想看，如果一个加密操作耗时 100μs，单线程时每秒只能加密 10,000 次。但如果你的网关需要每秒处理 50,000 个请求，那加密就成了瓶颈。
我曾经接手过一个金融支付系统，上线第一天就被压测打垮了。查到最后，发现他们用的 AES-256-CBC + PKCS7 填充，而且密码对象每次都 new 新的，完全不复用。每个请求都要花 2ms 做密钥扩展——在 16 核机器上，吞吐量死活上不去。换用 AES-128-GCM 并复用 SessionKey 后，吞吐翻了三倍。
这给我们一个启发：加密参数配置直接影响两个指标——
- 并发能力：系统能同时处理多少个加密任务。
- 吞吐量：单位时间内完成加密的数据量或请求量。
两者不是独立的。并发高了，如果加密实现里有全局锁或内存屏障，吞吐反而可能下降。
1.3 加密参数如何影响性能？
从底层看，影响性能的参数因素有这几条：
- 算法计算复杂度：AES 比 ChaCha20 更依赖硬件指令集；没有 AES-NI 的机器上，AES 可能比 ChaCha20 慢 2~3 倍。
- 密钥长度：256 位比 128 位多 40% 轮数，计算量增加，但在 AES-NI 上差距不大。
- 工作模式：ECB 可并行，但不安全；CBC 必须串行，不能并行加密；GCM 内部可以流水线化，但需要额外计算认证标签。
- 填充方式：NoPadding 最省，但要求数据长度对齐块大小；PKCS7 会额外产生一次内存拷贝。
- IV 管理：每次加密生成 IV 的成本很低，但如果 IV 是由随机数生成器调用，在高并发下 RNG 也成了共享资源。
下面这张图把加密参数配置的核心要素以及它们对并发/吞吐的影响画了出来。这也是做性能调优时需要盯住的几个维度。
1.4 平衡策略初探
既然参数这么多，我们怎么找到并发与吞吐的平衡点？这里先列几个宏观思路，后面章节会逐一深入：
- 选择硬件友好的算法：比如在 x86 上用 AES-NI，在 ARM 上用 ChaCha20。
- 复用加密上下文：避免每次加密都重新做密钥扩展和上下文初始化。
- 控制并发粒度：锁分段、无锁队列、或者每个线程绑定独立加密对象。
- 打散瓶颈资源：比如将 IV 生成从同步的 RNG 改为预生成池。
- 监控真实开销：用火焰图看加密函数的 CPU 占比，别凭直觉猜。
一句话总结本章：加密参数配置不是纯安全选择，它是一个系统性能决策。理解每个参数背后的计算模型，你才能在安全和性能之间找到那条最优曲线。