2. 双向认证与单向认证的区别
讲TLS，绕不开一个最基础的问题：单向认证和双向认证，到底差在哪？
很多刚接触的同学觉得，不就是“多验一次证书”吗？其实没那么简单。我个人习惯，先把这两种模式的核心逻辑讲透，你再去配置代码，心里才有底。
2.1 单向认证：只验服务端
单向认证是我们日常上网最常用的模式。你打开浏览器访问HTTPS网站，就是单向认证。
这个模型里，只有服务端需要出示证书。客户端（比如你的浏览器）去验证服务端的证书是不是合法的。验证通过，就建立加密连接。
关键在哪？服务端不关心客户端是谁。你是谁都可以访问，只要你的TLS握手能正常走完。
核心特征
- 服务端必须配置证书+私钥
- 客户端不需要任何证书
- 适用于公开访问的Web服务
我之前有个接口就是这种模式。一个公开的天气预报API，客户端千千万万，总不能要求每个调用方都装个证书吧？那运维起来简直噩梦。
2.2 双向认证：互相验明正身
双向认证就严格多了。它要求客户端也必须有证书，而且服务端会去验证客户端的证书。
说白了，就是“你验我，我也要验你”。双方都得掏出CA签发的身份证，互相检查。
握手阶段会多一个步骤：服务端在请求完客户端证书后，会校验它的合法性。如果客户端没证书，或者证书过期/被吊销，握手直接失败，数据包都发不过去。
避坑提醒
我曾经负责过一个金融项目，最开始测试环境跑双向认证一切正常。上了生产，发现部分老版本客户端握手失败。排查半天，原来是它们的根证书列表里没有服务端CA的中级证书。别以为配了服务端证书就万事大吉，客户端的信任链也得维护好。
2.3 两种模式的对比
为了方便你对照选择，我整理了一个表格。你想想看，你的业务场景属于哪种？
| 对比维度 | 单向认证 | 双向认证 |
|---|---|---|
| 服务端证书 | 必须 | 必须 |
| 客户端证书 | 不需要 | 必须 |
| 安全等级 | 中（防窃听） | 高（防窃听+防伪装） |
| 部署复杂度 | 低 | 高（证书分发、吊销） |
| 典型场景 | 公开网站、API | 内部服务、金融接口 |
| 握手性能 | 快 | 稍慢（多一次证书交换） |
嗯，这个表格基本把关键区别说清楚了。你注意看安全等级那一行。为什么单向认证不能防伪装？因为客户端是匿名的，服务端无法确认调用方是不是合法的内部系统。你想想看，如果有人拿到了你的，他就可以假装是合法客户端发起请求。双向认证直接把这个漏洞堵死了——没有证书，连握手都进不去。
2.4 怎么选？看你的信任边界
我个人建议，选哪种模式，先搞清楚你的信任边界在哪。
- 信任边界在服务端：你只关心用户访问时数据是否加密，不关心用户是谁。比如官网、博客、公开API。这种情况，单向认证完全够用。
- 信任边界在双方：你不仅要保护数据，还要确保调用方是已授权的实体。比如微服务间的内部RPC调用、核心支付接口、管理后台的API。那就得双向认证。
一个实际例子
我之前做过一个内部管理系统，所有服务部署在私有云。最开始用单向认证+鉴权。后来有一次安全审计，发现被截获后可以重放攻击。改造后上了双向认证，每个微服务都配了客户端证书，本质上是把信任从“应用层”下沉到了“传输层的证书”。从那以后，再没出现过类似的伪造请求。
图里把流程画出来了。你仔细看看右侧双向认证的部分，多了一个“客户端证书”的交换和“验证客户端”的步骤。这个多出来的步骤，就是整个安全模型的质变。
2.5 性能上也有一点差别
嗯，这里要提一嘴性能。双向认证的握手，比单向多了一次证书传输和一次非对称解密验证。如果你有大量短连接请求，这个开销会累积。
我建议：
- 如果QPS低于5000，性能差距基本可以忽略
- 高并发场景下，可以开启TLS会话复用，规避重复握手
但说实话，大部分业务场景，双向认证带来的安全收益远大于那点性能损耗。别为了省几毫秒把安全底线丢了。