TLS基础概念：加密、解密、明文、密文、对称加密与非对称加密
这章是地基中的地基。不管后面多复杂的协议、多深的边界联动，底层都离不开这几个概念。我见过不少开发把“加密”和“签名”混着用，结果线上出事故才回头补课——嗯，咱们从一开始就捋清楚。
明文与密文
明文（Plaintext）就是人眼看懂的信息，比如你发出去的“密码是123456”。密文（Ciphertext）就是被加密算法搅乱后的乱码，类似“F3A8B9C1...”。没有密钥，谁拿到密文也只能干瞪眼。
加密（Encryption）是把明文变密文；解密（Decryption）是走反向流程。这两个操作分别由加密算法和解密算法完成。
项目经验：早年在做日志传输时，我见过有人直接把明文塞进HTTP头——这比没加密还危险，因为中间件就能看到。那之后我在团队里强调，任何离开本机的数据都不可能是“明文”。
对称加密
对称加密用同一个密钥干两件事：加密和解密。就像你和女朋友共用一个抽屉钥匙，你锁她开。
- 常用算法：AES（128/256）、3DES、SM4（国密）。实践中我首选AES-256-GCM，既能加密又能验证完整性。
- 核心优势：计算快，适合大量数据。TLS传输层用的就是对称加密。
- 致命缺点：密钥怎么安全交给对方？如果你把钥匙写在明信片上寄出去，那加密还有什么意义？
来个命令行示例，用OpenSSL演示对称加密：
# 加密：用AES-128-CBC，密钥是"deadbeef"
echo "Hello TLS" | openssl enc -aes-128-cbc -e -base64 -K 6465616462656566 -iv 00000000000000000000000000000000
# 输出类似：U2FsdGVkX1...（密文）
# 解密：用同一密钥
echo "U2FsdGVkX1..." | openssl enc -aes-128-cbc -d -base64 -K 6465616462656566 -iv 00000000000000000000000000000000
避坑：我曾经在项目中直接硬编码16字节的密钥，结果代码被人从github扒走……那感觉就像家里大门钥匙挂在门外。后来我改用KMS + 临时派生，才睡安稳。
非对称加密
非对称加密用一对密钥：公钥公开，私钥自己保管。用公钥加密的数据只能用对应的私钥解开。反过来，用私钥签名的数据可以用公钥验签（数字签名）。
- 常用算法：RSA（2048/4096）、ECDSA（P-256）、SM2。现在TLS握手我用ECDSA更多，同等安全强度下性能好不少。
- 核心优势：解决了密钥分发问题——任何人都可以用你的公钥加密消息，只有你才能看。
- 致命缺点：慢！慢到没法直接加密1MB数据。
你看这对比就出来了：对称加密快但密钥分发难，非对称加密安全但慢得离谱。那TLS怎么搞？——混合加密。
混合加密：TLS的聪明做法
握手阶段，客户端和服务端用非对称加密（加上证书验证）安全地协商出一个临时对称密钥（Session Key）。之后所有业务数据都用这个对称密钥加密传输。这样一来，速度（对称加密）和安全（非对称加密分发密钥）全占了。
我画了一张图，帮你把这两个加密体系的关系理清：
Table：对称 vs 非对称核心对比
| 对比维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1个（加解密同一把） | 2个（公钥+私钥） |
| 计算速度 | 极快（硬件加速可达10Gbps+） | 慢（RSA 2048约每秒5000次签名） |
| 密钥分发 | 困难（必须安全传给对方） | 容易（公钥随意传，私钥不离开设备） |
| 典型算法 | AES, 3DES, SM4 | RSA, ECDSA, SM2 |
| TLS中使用位置 | 数据传输阶段 | 握手阶段（密钥协商、证书验证） |
你真正该记住的
- 加密≠签名。加密保护机密性，签名保护完整性+身份。别搞混。
- 对称加密的密钥长度很重要：AES-128足够用于TLS到现在，但如果你做的是超长保密要求，上AES-256。
- 非对称加密的密钥长度同理：RSA 2048是底线，建议上4096或切到ECDSA P-384。
我在生产环境踩过最大的坑是：用RSA公钥直接加密整个HTTP响应体——服务端解密一次花了整整12秒，用户直接超时。正确做法永远是用非对称加密交换对称密钥，后续用AES跑。混合加密不是建议，是铁律。
注意：任何人跟你说“我们只用非对称加密就够了”，你直接拉他看TLS握手规范。没有对称加密的加持，现代互联网根本跑不动。