📚 课程目录第2章加密基础

第2章加密基础：对称与非对称加密、TLS/SSL 原理、证书链

说实话，很多做 gRPC 的朋友一提到「加密」就觉得是安全团队的事。我之前也这么想，直到有一次线上服务因为 TLS 握手太慢，导致 P99 延迟直接翻了三倍。那才意识到——不懂加密原理，性能优化根本无从下手。

这一章，咱们就聊聊那些绕不开的基础知识。我尽量用大白话讲清楚，同时给出性能视角的分析。

这两种加密方式，是所有安全体系的基石。说白了一个是「一把钥匙开一把锁」，另一个是「两把钥匙配一对锁」。

客户端和服务端用同一个密钥。加密快，但密钥怎么安全地传给对方？这是个死循环问题。

我在项目中做过压测，AES-256-GCM 在现代 CPU 上可以达到 3-5 Gbps 的加解密速度。相比之下，非对称加密慢了至少两个数量级。

公钥加密，私钥解密。解决了密钥分发问题，但性能代价很大。

你想想看，每次非对称加密都要做大数模幂运算，CPU 压力非常大。所以实际中我们只用它来做密钥交换和数字签名，真正的数据传输还是交给对称加密。

TLS（传输层安全协议）实际上把对称和非对称加密组合起来了。它的核心思路很巧妙：先用非对称加密安全地协商出一个对称密钥，然后用这个对称密钥加密后续所有通信。

相比 TLS 1.2，1.3 版本把握手从 2-RTT 降到了 1-RTT，甚至支持 0-RTT（但要注意重放攻击）。我建议所有新项目直接上 TLS 1.3，性能提升非常明显。

// 简化版 TLS 1.3 握手流程
1. ClientHello —— 客户端发送支持的密码套件和随机数
2. ServerHello —— 服务端选择密码套件，发送证书和公钥
3. 密钥协商 —— 双方用 ECDHE 计算共享密钥
4. Finished  —— 加密的握手完成消息

为什么这么快？因为 TLS 1.3 只保留了 3 个密钥交换算法（均基于 ECDHE），去掉了所有不安全或过时的选项。我在优化公司网关时，从 1.2 迁到 1.3，握手时间从 150ms 降到了 40ms 左右。

性能关键点：TLS 握手的主要开销来自非对称运算（签名验证、密钥交换）。使用 ECDSA 证书和 X25519 密钥交换，可以把计算量降到 RSA 2048 的 1/5 以下。

证书就是公钥的「身份证」。CA（证书颁发机构）负责给它签名，证明这个公钥确实属于某个域名或组织。

完整的证书链通常是这个样子：

根 CA（自签名） —— 中间 CA —— 服务器证书（叶子证书）

我最开始理解的时候有个误区：以为每个证书都要单独验证。其实验证过程是从下往上走：

这里有个性能陷阱。证书链越长，验证耗时越多。我记得有一个客户在证书链里塞了 5 个中间 CA，导致每次握手慢 200ms。优化方案很简单——只保留必要的中间 CA，通常 1-2 级就够了。

避坑指南：我以前调试过一个问题，客户端 CA 证书列表太长（超过 20KB），导致 TLS 握手包分片，反而增加了 30% 的延迟。把不需要的中间 CA 删掉，问题就解决了。

我在做性能基准测试时，整理了一份对比数据。你可以直接拿去参考。

算法	密钥长度	签名/验证速度	硬件加速	推荐场景
AES-256-GCM	256 bit	极快	AES-NI	对称加密（数据面）
ChaCha20-Poly1305	256 bit	快	软件优化	移动端/弱 CPU
ECDSA P-256	256 bit	中等	部分支持	证书签名
Ed25519	256 bit	快	良好	现代证书/SSH
RSA-2048	2048 bit	慢	广泛支持	遗留系统（不推荐）
X25519	256 bit	极快	恒定时间	密钥交换（TLS 1.3）

我的选择标准是这样：

小提示：如果你在用 OpenSSL 1.1.1+，可以用 openssl speed -elapsed 命令测试本机算法的实际性能。这个命令我每次换服务器都会跑一遍，心里有数。

嗯，这张图把整个知识结构串起来了。你从上往下看，先理解两类加密，再看 TLS 和证书，最后落到性能指标和建议上。后面的章节，咱们会反复用到这里的知识点。

第2章 加密基础：对称与非对称加密、TLS/SSL 原理、证书链