支持SSL Passthrough及服务器持久化的负载均衡方案咨询

你需要的「SSL全透传（不在负载均衡层终止加密）+ 客户端请求固定路由到同一后端节点」的能力不存在技术实现障碍，DigitalOcean负载均衡不支持是其产品本身的功能限制，并非行业通用情况。下面分原生支持的成熟方案、受限环境下的可行workaround分别说明：

原生支持该能力的负载均衡实现 #

• HAProxy：生产环境最常用的四层透传方案，配置TCP模式监听即可实现SSL Passthrough，不需要在LB侧加载SSL证书、不终止TLS连接。内置的粘性表支持三类匹配规则满足会话保持要求：
  • 基于源IP的一致性哈希，适合客户端IP固定的业务场景
  • 提取SSL握手阶段明文传输的SNI、Session ID字段做哈希绑定，匹配精度远高于纯IP哈希
  • 基于长连接五元组的连接跟踪，连接存续期间所有报文固定转发到同一后端
• Nginx/NGINX Plus：开源版Nginx从1.13.10版本开始支持stream块做四层TCP转发，配置hash $remote_addr consistent;即可实现源IP维度的会话保持，全程不触碰SSL加密内容；NGINX Plus额外支持基于SSL Session ID的粘性策略，匹配精度更高。
• 主流云厂商网络负载均衡器：AWS NLB、阿里云NLB、腾讯云四层CLB的TCP监听器都支持SSL Passthrough模式下的源IP粘性会话，转发全程不做TLS终止，性能比七层LB高一个量级。

针对DigitalOcean LB这类不支持原生粘性的透传场景Workaround #

• 方案1：开启四层源IP一致性哈希转发
  部分云厂商的LB虽然没有明确标注支持SSL Passthrough粘性，但只要支持TCP监听器的一致性哈希调度规则，本质上就能实现基础的会话固定：同一公网出口IP的客户端请求会持续转发到同一台后端。缺点是大内网NAT出口、客户端IP频繁变动的场景会出现会话漂移，适合客户端IP稳定的ToB类业务。
• 方案2：客户端侧维护节点绑定关系
  第一次发起SSL连接前，客户端先请求一个轻量的调度接口，获取分配给自己的后端节点唯一标识，后续所有SSL连接直接指向对应节点，LB仅做四层端口透传、不做流量调度，把会话绑定逻辑从LB侧移到客户端侧，完全绕开LB的功能限制。
• 方案3：自部署边缘LB做调度
  如果必须使用DigitalOcean的云主机资源，可以直接替换其原生LB，自己搭一层HAProxy/Nginx做四层透传调度，按前面提到的配置实现SSL Passthrough+会话保持，后端节点仍然部署在DigitalOcean内网即可，性能损耗极低。

注意：SSL Passthrough工作在四层，全程不解密流量，因此不可能实现七层SSL终止模式下的Cookie级粘性，所有透传场景下的会话保持，都是基于源IP、SSL握手明文字段、连接五元组这几类信息做的匹配，不存在LB侧解析加密会话内容做绑定的可能。

内容的提问来源于stack exchange，提问作者Cyborg7459