1. 加密服务概述:什么是加密服务,为什么需要加密,常见加密协议

大家好,我是这次课的讲师。做负载均衡这么多年,我见过不少因为加密配置踩坑的团队。在开始讲具体的均衡器和健康检查之前,咱们先把加密服务这件事聊透。你想想看,如果连基础概念都模糊,后面的优化策略基本就是空中楼阁。

1.1 什么是加密服务

加密服务,说白了就是一套把原始数据变成“乱码”再还原回来的机制。这乱码不是随便变的——它依赖算法和密钥。只有持有正确密钥的接收方才能解开。我以前带过一个新人,觉得加密就是“把文件压个密码包”,结果项目上线后密钥管理一团糟,回滚了两次才解决。

在负载均衡的场景下,加密服务通常部署在以下位置:

  • 客户端到负载均衡器:比如 HTTPS 监听器,对外暴露公网端口。
  • 负载均衡器到后端服务器:有些环境为了性能,会在内网使用明文回源,但敏感业务建议全链路加密。
  • 节点之间的控制面通信:像 Consul 或 ZooKeeper 的 TLS 加密心跳。

核心要点:加密服务不是只保护传输的数据,还包括身份认证和完整性校验。三者合一才算完整的安全方案。

1.2 为什么需要加密

我经常被问到:“我们的内网有防火墙,还需要加密吗?” 我的回答很直接——需要。原因有三点:

  1. 数据机密性:防止第三方窃听。明文传输就像在明信片上写银行卡密码,任何人都能看。
  2. 数据完整性:防止中间人篡改。没有完整性校验,攻击者可以在你下载的安装包里植入恶意代码。
  3. 身份认证:确认通信对方的真实身份。没有证书验证,谁都可以假装成你的服务器。

我记得有次排查一个生产问题:用户登录后偶尔出现“此连接不安全”的警告。跟踪日志发现,是负载均衡器的证书链只配置了叶子证书,没有包含中间 CA 证书。浏览器拒绝信任,用户数据差点走明文回源。嗯,从那以后我强制团队把证书链完整性加进了部署 checklist。

避坑指南:我曾经遇到过某个海外节点因为使用自签名证书,被上游健康检查误判为“异常”,导致流量全被路由到另一个区域。后来我们在健康检查请求里加了独立 CA 验证,才彻底解决。

1.3 常见加密协议

从业这么多年,最常用的就那几个。我给你列个清晰的对照表。

协议 所在层级 典型应用 性能特点
TLS/SSL 传输层(TCP 之上) HTTPS、MQTTS、SMTPS 握手开销大,但后续对称加密快
IPsec 网络层(IP 包) 站点到站点 VPN、远程接入 对上层透明,但配置复杂
SSH 应用层 远程管理、文件传输 交互式安全隧道,短连接效率高
DTLS 传输层(UDP 之上) WebRTC、实时音视频 基于 UDP,抗丢包设计
WireGuard 网络层(新兴) 现代 VPN 内核级实现,极低延迟

TLS/SSL 协议

这是负载均衡器上配置最多的协议。TLS 1.3 减少了握手到 1-RTT,并废弃了不安全的密码套件。我建议生产环境至少启用 TLS 1.2,禁用 SSLv3 和 TLS 1.0/1.1。配置示例(Nginx 片段):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;

IPsec 协议

IPsec 有两个模式:传输模式和隧道模式。在负载均衡场景中,IPsec 隧道常用于连接不同云厂商的 VPC。我曾在混合云项目里用 IPsec 把阿里云和 AWS 打通,结果因为 IKE 版本不匹配(AWS 要求 IKEv2,阿里云默认 IKEv1),折腾了一整天。记住:两端必须协商一致的加密算法和认证方式。

IPsec 基本结构:

IKE 阶段1(主模式):证书/预共享密钥 + DH 交换
IKE 阶段2(快速模式):建立 IPsec SA,使用 ESP 头封装数据包
数据面:每个包加 ESP 头和尾,再加密。

其他协议

SSH 主要用于管理通道,但不适合高并发场景。DTLS 把 TLS 的可靠性降级到 UDP 上,适合 WebRTC。WireGuard 是后起之秀,代码量极小,内核集成后性能极佳,不过目前主流负载均衡器原生支持还不够多。

个人建议:如果你是新建系统,默认选 TLS 1.3 + ECDSA 证书。ECDSA 比 RSA 短很多,能减少握手包大小,对低带宽链路友好。

1.4 加密协议在 OSI 模型中的位置

下面这张图可以帮你快速建立空间感。我把常见加密协议按 OSI 层级排列,方便理解它们在网络栈中的位置。

常见加密协议在OSI模型中的位置 应用层 HTTP/SMTP/SSH 传输层 TCP/UDP (DTLS在此层) 网络层 IP包 TLS/SSL HTTPS, MQTTS SSH 远程管理 DTLS WebRTC IPsec VPN 应用层加密 对上层应用透明 应用需支持协议 传输层加密 TLS/DTLS 最常用 网络层加密 IPsec 对上层透明

从图上可以清楚看到:应用层的 SSH 和 TLS 需要应用程序自身支持;IPsec 工作在网络层,对整个 IP 包加密,负载均衡器不需要理解上层协议就能转发。这一点在做站点间 VPN 时特别有用——后端任何 TCP/UDP 流量都可以自动走加密隧道。

1.5 加密服务与负载均衡的关联

我最后点一下:为什么这本教程要把加密服务和负载均衡放在一起?因为当你用负载均衡器做 TLS 终结时,证书管理、会话复用、密码套件协商都会直接影响均衡策略。比如:

  • Session Ticket 复用:负载均衡器是否在所有节点间同步 SSL 会话 ID?不同步会导致客户端每次请求都新建握手,影响性能。
  • 证书轮换:AKS 或 ELB 如何热更新证书?我曾经因为证书轮换时没重启后端,导致健康检查认为后端 TLS 异常,流量全被导走。
  • 密码套件降级攻击:负载均衡器如果不限制最低密码套件,攻击者可以强制使用弱加密。

这些细节我们将在后续章节里逐一拆解。先打好加密基础,后面学均衡器配置时你才能理解“为什么这里要这么配”。

小结:加密服务是数据安全的第一道防线,选对协议、配好证书、做好密钥管理,是负载均衡架构的基石。下一章我会带你看看负载均衡器是如何处理 TLS 握手的,以及我们怎么通过健康检查来验证加密通道是否可用。