WebSocket与负载均衡器协同工作的相关技术疑问

问题1：负载均衡器是否仅在开启粘性会话时才能与WebSocket配合工作？服务器增减导致哈希重均衡会发生什么？ #

不是必须，分两种场景：

• 对于不具备WebSocket感知能力的传统负载均衡器：确实需要开启粘性会话（比如基于Cookie或源IP哈希）。因为WebSocket是长连接，握手完成后所有后续帧必须发往同一后端服务器——如果没有粘性，负载均衡器可能把后续请求路由到其他服务器，而这些服务器没有该连接的上下文，会直接断开连接。
• 对于具备WebSocket感知能力的现代负载均衡器：不需要依赖传统粘性会话。这类负载均衡器能识别HTTP Upgrade请求（WebSocket握手的关键），一旦检测到要建立WebSocket连接，会在本地记录客户端与后端服务器的连接映射，后续所有该连接的帧都会直接路由到对应的服务器。

当服务器增减触发哈希重均衡时：

• 若使用基于哈希的粘性会话：部分已建立连接的客户端会被重新路由到新的后端服务器，由于新服务器没有该连接的上下文，WebSocket连接会直接断开，客户端需要重新发起握手建立新连接。
• 若使用WebSocket感知的负载均衡器：已建立的连接不受重均衡影响，因为负载均衡器已经记录了固定的路由映射，只有新发起的连接才会参与新的负载分配。

问题2：使用L3网络层负载均衡器时，SSL如何工作？ #

L3负载均衡器仅在网络层（IP层）工作，只负责转发IP数据包，无法处理应用层的SSL加密/解密逻辑，因此SSL处理有两种方案：

• 后端服务器终止SSL：所有后端服务器都配置SSL证书，客户端直接与后端服务器建立SSL连接，L3负载均衡器仅转发加密后的数据包，完全不碰SSL内容。这种方式的缺点是证书管理繁琐，且后端服务器需要承担SSL解密的性能开销。
• 前置SSL卸载层：在L3负载均衡器前端部署专门的SSL终止设备（比如L7反向代理、SSL卸载器），由这一层完成SSL解密，再将明文的WebSocket流量转发给L3负载均衡器，最后路由到后端服务器。这种方式可以集中管理证书，还能减轻后端服务器的性能压力。

问题3：新版负载均衡器（如Amazon ALB、HAProxy）的WebSocket选项如何工作？是否需要维护连接？如何扩展？ #

这类负载均衡器属于WebSocket感知的L7负载均衡器，工作机制如下：

1. 握手识别：当客户端发送包含Upgrade: websocket和Connection: Upgrade的HTTP请求时，负载均衡器会识别出这是WebSocket握手请求，然后按照负载均衡策略（比如轮询、最少连接）选择一台后端服务器，转发握手请求。
2. 连接映射记录：一旦后端服务器返回握手响应（101 Switching Protocols），负载均衡器会在本地建立一个客户端连接（源IP+端口）与后端服务器的映射关系，后续该客户端的所有WebSocket帧都会直接路由到这台服务器，不需要再经过负载均衡策略计算。
3. 连接维护：负载均衡器不需要维护WebSocket连接的具体内容（比如帧数据、会话状态），只需要维护路由映射表，同时会通过心跳检测（比如定期发送Ping帧）监控连接状态，一旦连接断开就删除对应的映射。

扩展方式：
这类负载均衡器通常以集群形式部署，每个集群节点独立维护自己的连接映射表。新增节点时，只需要将新的客户端请求分配给新增节点，存量的已建立连接仍由原节点负责路由；如果是节点下线，负载均衡器会将该节点上的连接信息同步到其他节点（部分实现支持），或者让客户端在连接断开后重新握手，由集群其他节点承接。这种分布式的映射管理方式，让负载均衡器集群可以轻松横向扩展，不会因为连接数增加而出现性能瓶颈。

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