📚 课程目录第4章加密与负载均衡的结合

4. 加密与负载均衡的结合：为什么需要在负载均衡中处理加密，卸载与透传模式

4.1 为什么负载均衡非得碰加密这层？

加密流量对负载均衡器来说，就是个黑盒。你想想看，HTTPS 流量经过 TLS 加密后，七层的信息——URL、Cookie、Header 这些——全都被包在加密隧道里。负载均衡器如果想做七层路由（比如按域名、按路径分发），不解密根本看不到。

我刚开始接触这块时，觉得「把 HTTPS 直接透传过去不就完了嘛，后端自己解密」。后来在项目里被教育了：很多业务场景下，负载均衡器必须看七层信息才能做决策。比如电商大促时，需要把 /checkout 的流量引导到专门的支付集群，不解密怎么知道路径？

核心矛盾就两条：

可见性缺失：加密流量让七层路由、会话保持、限流降级全成瞎子。
性能瓶颈：如果让后端每台服务器都自己扛 TLS 握手和解密，CPU 开销很大，集群规模上去后成本翻倍。

说白了，在负载均衡层面处理加密，不是为了「找麻烦」，而是为了在可见性和性能之间找到平衡点。怎么做？业界就分化出了两种主流模式——SSL 卸载和SSL 透传。

    一句话总结：卸载模式让 LB 解密，后端只跑明文，性能好但 LB 到后端是裸奔；透传模式全程加密，后端自己解密，安全性高但 LB 做不了七层路由。

4.2 SSL/TLS 卸载模式：把加密的苦活揽到 LB 上

原理很简单：客户端和负载均衡器之间跑 HTTPS，LB 完成 TLS 握手和解密，然后把明文 HTTP 请求转发给后端服务器。

我在一个电商平台项目中用过这个模式。当时后端是几十台 .NET 应用服务器，如果每台都扛 TLS，CPU 直接飙到 80%。用了卸载之后，LB 统一管理证书和加解密，后端服务器 CPU 降到了 20% 左右，效果很明显。

优点

后端无负担：后端服务器不用处理 TLS，专注业务逻辑，CPU 和内存都省下来了。
证书集中管理：只在 LB 上部署证书，不用每台后端都放一遍，更换证书时也只需改 LB 配置。
七层路由能力：LB 能看到明文 HTTP 信息，可以做域名分发、路径重写、Cookie 会话保持等高级功能。

缺点

LB 到后端是明文：如果内网不可信，或者有合规要求（比如金融、医疗），这条链路就是风险点。
LB 性能瓶颈：TLS 加解密非常消耗 CPU，LB 的配置要足够高，否则自身会成为瓶颈。

配置示例（Nginx）

server {
    listen 443 ssl;
    server_name api.example.com;

    # 证书配置在 LB 上
    ssl_certificate     /etc/nginx/certs/example.crt;
    ssl_certificate_key /etc/nginx/certs/example.key;

    location / {
        proxy_pass http://backend_upstream;
        # 把客户端真实 IP 和协议透传过去
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

经验之谈：用了卸载模式后，别忘了在 LB 上开启 X-Forwarded-For 和 X-Forwarded-Proto。后端应用需要知道客户端真实 IP 和原始协议，否则日志里全是 LB 的内网 IP，排查问题时会很抓狂。

4.3 SSL/TLS 透传模式：让加密一路到底

透传模式就是：负载均衡器不碰加密内容，直接把 TCP 流量（TLS 握手数据）原封不动地转发到后端服务器。后端自己完成 TLS 解密。

我记得有个金融客户，合规要求「数据在任意网络链路上都必须是加密的」。卸载模式那种 LB 到后端跑明文的方式，直接被合规否掉了。最后只能上透传模式，LB 只做四层转发，后端自己扛 TLS。

优点

端到端加密：从客户端到后端服务器全程 TLS 保护，内网抓包也看不到明文。
LB 无解密压力：负载均衡器只做 TCP 转发，CPU 开销很低，可以支撑更高的并发连接数。
后端完全掌控：每台后端可以独立管理自己的证书和加密策略，适合多租户或证书异构的场景。

缺点

后端性能开销大：每台服务器都要处理 TLS 握手和解密，CPU 占用高，集群规模大时成本直线上升。
LB 无法做七层路由：只能基于 IP 和端口转发，做不到按 URL、Header、Cookie 分发。
证书分散管理：每台后端都要部署证书，更新时得挨个操作，运维复杂度高。

配置示例（HAProxy）

frontend fe_tls_pass
    bind *:443
    mode tcp
    default_backend be_tls_servers

backend be_tls_servers
    mode tcp
    server app1 10.0.1.10:443
    server app2 10.0.1.11:443

我曾经踩过一个坑：透传模式下，HAProxy 默认不修改 TCP 流，后端获取到的客户端 IP 是 LB 的内网 IP。如果你需要真实客户端 IP，必须开启 proxy_protocol。当时我排查了整整半天才知道问题出在哪。记住：透传 + 真实 IP = proxy_protocol 必须两端都配置。

4.4 两种模式对比：一张表说清楚

对比维度	SSL 卸载模式	SSL 透传模式
证书部署位置	负载均衡器	每台后端服务器
LB 到后端链路	明文 HTTP	加密 TLS
后端 CPU 开销	低（无解密负担）	高（每台都扛 TLS）
LB 支持七层路由	是	否（仅四层）
会话保持方式	Cookie、Header、IP 等	仅源 IP 或 SSL Session ID
安全性级别	中（内网需可信）	高（全程加密）
运维复杂度	低（集中管理证书）	高（每台独立管理）
适用场景	内部服务、电商、CDN 边缘	金融、医疗、合规敏感场景

4.5 选型思路：到底该选哪一种？

我个人习惯先问自己三个问题：

内网链路是否可信？——如果 LB 和后端在同一个机房或 VPC，内网可控，优先考虑卸载模式，性能和运维都更优。
是否需要七层路由？——需要按域名、路径、Header 分发流量？那只能选卸载模式，透传模式做不了。
合规要求有多严？——如果审计要求「数据在网络中全程加密」，那就别纠结了，直接上透传模式，或者用卸载 + 后端再加密的混合方案。

还有一种混合玩法：LB 做卸载，但 LB 和后端之间也跑 HTTPS（即 LB 先解密再重新加密转发到后端）。这种模式兼顾了七层路由和链路加密，代价是 LB 的 CPU 开销翻倍。嗯，实际项目中真正用混合模式的场景不多，但极端合规场景下值得考虑。

我的建议：大多数互联网业务，用卸载模式就够了。内网链路通常可信，而且七层路由带来的灵活性远大于那点安全增益。但金融、政务、医疗这些行业，老老实实上透传模式，别在合规上挑战审计。

4.6 来张图：两种模式的流量路径一眼看懂

4.7 避坑指南 + 个人经验总结

做了几年加密负载均衡，我踩过不少坑，也见过同行掉进同样的坑里。列几条最实用的：

真实 IP 传递：卸载模式用 X-Forwarded-For，透传模式用 proxy_protocol。两个方向搞反了，后端拿到的 IP 全是错的。我曾经在透传模式下忘了开 proxy_protocol，结果业务方查了半天日志，发现所有请求都来自 LB 的内网 IP，那场面…嗯，很尴尬。
证书有效期监控：卸载模式下证书在 LB 上集中管理，看似省心，但一旦证书过期，整个业务全挂。我建议用自动化工具监控证书有效期，提前 30 天告警。
性能基准测试：到底用哪个模式，不要光靠感觉。我习惯在选型前做一次压测：同样流量下，卸载模式的 LB CPU 是多少，透传模式的 LB CPU 是多少，后端 CPU 又是多少。数据说话，最靠谱。
合规敏感场景：如果客户是金融或政务，别主动推荐卸载模式。就算你解释一百遍「内网是安全的」，审计报告也不会改。直接上透传模式，省得后续扯皮。

    最后说一句：加密与负载均衡的结合，本质上是在「性能」和「安全」之间做取舍。没有完美的模式，只有适合你场景的模式。理解清楚卸载和透传的原理，选型时就不会纠结了。