3. 密码套件与性能权衡

在 TLS 握手与记录层中，密码套件决定了“用什么算法完成密钥交换、身份认证、对称加密和完整性保护”。很多性能问题并不是 TLS 协议本身慢，而是选错了套件组合：例如仍在使用 RSA 密钥交换、CBC 模式加密，或者在不支持 AES-NI 的移动设备上强行使用 AES-GCM。理解各算法的开销来源与安全边界，是连接治理的第一步。

一、密码套件的四段结构与性能归属

一个典型的 TLS 1.2 套件名如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，可拆成四段：密钥交换（ECDHE）、身份认证（RSA）、对称加密（AES-128-GCM）、PRF 哈希（SHA256）。TLS 1.3 则把密钥交换与认证合并到 key_share 与证书验证中，套件名简化为 TLS_AES_128_GCM_SHA256 或 TLS_CHACHA20_POLY1305_SHA256，不再单独协商密钥交换算法。

性能开销主要分布在三个位置：握手阶段的非对称运算（ECDHE 临时密钥对生成、RSA/ECDSA 签名验证）、记录层的对称加密（每个数据包的加解密）、以及哈希与 PRF（握手消息摘要、密钥派生）。其中非对称运算只发生在握手，对称加密则贯穿整个连接生命周期，因此高吞吐场景下对称算法选择对 CPU 影响更大。

二、AEAD 与 CBC：记录层加密的本质差异

CBC 模式需要“加密 + HMAC”两步：先对明文做填充，再用 AES-CBC 加密，最后对密文计算 HMAC。解密时先验证 HMAC，再解密并去除填充。这种“先 MAC 后加密”的结构不仅多一次哈希计算，还容易因填充校验与 MAC 校验顺序不当引入 Lucky13 等时序攻击。此外 CBC 无法并行解密，且填充长度可变，给实现带来额外分支。

AEAD（如 AES-GCM、ChaCha20-Poly1305）把加密与认证合并为一次原语调用，输出密文与认证标签。它天然支持并行处理，解密时先校验标签再释放明文，避免了填充预言问题。在 TLS 1.3 中，CBC 套件已被完全移除，AEAD 成为唯一选择。

三、AES-GCM 与 ChaCha20-Poly1305 的开销对比

AES-GCM 的性能高度依赖硬件指令。在支持 AES-NI 的 x86 服务器上，AES-128-GCM 可达数 GB/s，且延迟低；但在部分 ARM 移动设备或老旧虚拟化环境中，缺少 AES 加速会导致纯软件实现性能骤降，甚至低于 ChaCha20。ChaCha20-Poly1305 是纯软件友好的流密码，在无 AES 加速的设备上通常表现更稳定，且对侧信道攻击的抵抗力较好。

实际选型时，服务端可同时启用两组套件，由客户端根据自身能力选择。OpenSSL 默认的 DEFAULT 或 HIGH 策略已包含两者，但顺序会影响偏好。例如在 Nginx 中可显式配置：

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;

若服务端 CPU 支持 AES-NI，可把 AES-GCM 放在前面；若面向大量低端移动端，可把 ChaCha20 提前。注意 ssl_prefer_server_ciphers 在 TLS 1.3 中不生效，TLS 1.3 的套件偏好由客户端决定，服务端只能通过 ssl_conf_command Ciphersuites 调整支持列表。

四、密钥交换与认证：ECDHE 与 RSA 的取舍

RSA 密钥交换（TLS_RSA_WITH_*）在握手时由客户端用服务器公钥加密预主密钥，服务器私钥解密。它不具备前向保密，一旦私钥泄露，历史流量可被解密；且 RSA 解密开销随密钥长度增长，2048 位 RSA 解密约需 1~2 ms，4096 位则更慢。ECDHE 通过临时椭圆曲线密钥对协商共享密钥，每次握手生成新密钥，具备前向保密，且计算量远小于 RSA 解密。

认证环节，RSA 签名验证开销较低，ECDSA 签名更短、验证更快，但签发和兼容性需考虑。TLS 1.3 中密钥交换固定为 ECDHE 或 DHE，RSA 仅用于证书签名，不再用于密钥传输。因此现代部署应优先选择 ECDHE + ECDSA/RSA 签名组合。

五、安全强度与性能的平衡实践

安全强度并非越高越好。AES-128 与 AES-256 在抗暴力破解上差距巨大，但在实际攻击面中，128 位已足够；AES-256 在部分平台因密钥扩展更慢，吞吐略低。ChaCha20 使用 256 位密钥，安全强度与 AES-256 相当，但性能不受硬件限制。ECDHE 曲线选择上，X25519 比 P-256 更快且实现更简单，TLS 1.3 默认优先 X25519。

一个可落地的服务端套件顺序建议如下（以 OpenSSL 语法为例）：

# TLS 1.3 套件（服务端支持列表）
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;

# TLS 1.2 套件（按偏好排序）
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

验证时可用 openssl s_client -connect example.com:443 -tls1_3 观察实际协商结果，或使用 nmap --script ssl-enum-ciphers -p 443 example.com 列出服务端支持的套件与强度评级。若发现仍协商出 CBC 或 RSA 密钥交换套件，应检查配置是否被旧版客户端降级，或中间设备是否改写了 ClientHello。

六、常见误区与排障方向

误区一：认为“套件越长越安全”。实际上套件名长度与安全强度无关，关键看是否 AEAD、是否前向保密。误区二：在 TLS 1.3 中继续配置 ssl_ciphers 期望生效，但 TLS 1.3 套件由 Ciphersuites 控制，两者需分别设置。误区三：忽略客户端兼容性，直接禁用所有 CBC 套件，导致老旧 Android 或嵌入式设备无法连接。此时可保留一组 CBC 套件作为兜底，但应放在列表末尾，并监控其使用比例。

排障时，先确认协商到的套件版本与名称，再判断是否命中预期。若握手延迟高，重点看 ECDHE 曲线与证书签名算法；若吞吐低，重点看对称加密是否走了硬件加速路径。通过 openssl speed -evp aes-128-gcm 与 openssl speed -evp chacha20-poly1305 可快速评估本机两种算法的原始吞吐，为套件排序提供依据。