2. TLS终止概念：什么是TLS终止、架构模型与典型场景

聊TLS终止之前，我先问一个问题：你部署的HTTPS服务，证书是放在哪台机器上的？

很多人会说「当然放在Web服务器上啊」。嗯，这确实是最直觉的做法。但我在大型项目中见过太多这样的案例——每台后端服务器都扛着证书、做握手、解加密，结果CPU烧得厉害，运维也累得够呛。这时候，TLS终止就派上用场了。

2.1 什么是TLS终止

说白了，TLS终止就是「把加密连接在某个节点上停下来」。这个节点负责解密客户端发来的TLS流量，然后把明文请求转发给后端服务。

你可以把它理解成一个翻译官。客户端说的是加密的「TLS语」，后端服务只懂明文的「HTTP语」。翻译官在中间，把加密的话翻译成明文，再传给后端。

我个人的习惯是，只要后端服务在同一个内网、可信环境中，我都会优先考虑做TLS终止。为什么？因为省事、省资源、好管理。

2.2 TLS终止的架构模型

根据终止节点位置的不同，我把它分成三种主流模型。每种模型都有它的适用场景，也有坑。

2.2.1 模型一：负载均衡器终止

这是最常见的模型。客户端 → 负载均衡器（TLS终止） → 后端服务器（明文HTTP）。

我在某电商平台做过一次架构升级，当时后端有200多台Tomcat实例。如果每台都配证书、做握手，光证书续期就能把人逼疯。后来统一在Nginx负载均衡层做TLS终止，后端只跑HTTP，运维效率直接翻倍。

维度	说明
证书管理	集中管理，只需在负载均衡器上配置
性能开销	加解密集中在负载层，后端服务器CPU压力小
内网安全	后端传输为明文，需确保内网隔离
典型产品	Nginx、HAProxy、AWS ALB、F5

2.2.2 模型二：反向代理/API网关终止

这个模型和负载均衡器终止类似，但多了很多七层能力。比如你可以在这里做请求路由、限流、鉴权、日志记录。

我记得有一次帮一个金融客户做方案，他们要求所有API请求必须经过统一的认证网关。我们就在Kong网关层做TLS终止，网关解密后先校验JWT Token，再转发给后端微服务。这样后端服务完全不用关心证书和认证逻辑，专注业务就好。

2.2.3 模型三：后端服务器直接终止

嗯，这个模型就是「不终止」。每台后端服务器自己配证书、自己做TLS握手。适合小规模部署，或者对端到端加密有强合规要求的场景。

我曾经在一个医疗项目中被迫采用这个模型——合规要求从客户端到数据库全程加密，中间任何节点都不能看到明文。没办法，只能每台应用服务器都配证书，性能开销确实大，但合规优先。

2.3 TLS终止的典型应用场景

光讲概念太虚，我结合真实项目经验，给你列几个最常见的场景。

2.3.1 场景一：CDN边缘节点

CDN节点在全球各地，用户请求先到最近的CDN节点。CDN做TLS终止，解密后通过内部网络回源获取内容。

这里有个细节：CDN到源站之间，很多厂商支持「回源加密」，也就是CDN节点解密用户请求后，再用自己的证书重新加密发给源站。这叫TLS卸载（TLS Offloading），和TLS终止略有不同，但思路类似。

2.3.2 场景二：微服务网关

微服务架构中，外部请求统一经过网关。网关做TLS终止，内部服务之间走RPC或HTTP明文通信。

我参与过的一个项目，内部服务间通信用了gRPC，但gRPC默认使用HTTP/2明文。网关层做TLS终止后，外部是HTTPS，内部是gRPC明文，性能和安全都兼顾了。

2.3.3 场景三：SSL卸载（SSL Offloading）

这个场景和TLS终止几乎是一回事，但强调「卸载」这个动作——把加解密运算从后端服务器卸载到专用设备上。

我记得早年做银行项目时，后端服务器还是小型机，CPU性能很金贵。我们专门买了硬件SSL加速卡，挂在F5负载均衡器上做TLS终止。那效果，立竿见影，后端服务器CPU使用率直接从80%降到20%。

2.4 核心架构图：TLS终止的三种模型对比

下面这张图我画了三种模型的流量路径，你看一眼就明白了。

2.5 避坑指南

最后，我分享几个自己踩过的坑，你遇到了可以少走弯路。

• 证书过期没人管：我曾经在一个项目里，负载均衡器上的证书过期了三天才发现，用户全炸了。后来我强制加了证书监控和自动续期脚本，再也没出过事。
• 内网明文传输风险：做TLS终止后，后端走的是明文HTTP。如果内网被渗透，流量就能被嗅探。我的做法是：内网用VPC隔离，加上mTLS做服务间认证。
• Session粘连问题：有些负载均衡器做TLS终止后，客户端的源IP会被替换成负载均衡器的IP。后端服务如果依赖客户端IP做会话保持，就会出问题。记得开启X-Forwarded-For透传。

嗯，TLS终止的概念和模型就讲到这里。你想想看，你的项目现在用的是哪种模型？有没有踩过类似的坑？