WebSocket 怎么接入负载均衡
WebSocket 建立在 HTTP 之上，通过 Upgrade 头把连接升级为长连接，因此七层监听需要支持协议升级头的透传（多数产品默认支持）。接入后真正的难点在超时：链路上任意一层的空闲超时都可能先于业务把连接清掉，表现为连接周期性断开。所以配置要点是「超时大于静默间隔，并配合应用层心跳」，两者缺一不可。
基本信息
| 前提 | 七层监听透传 Upgrade 与 Connection 头 |
|---|---|
| 超时 | 空闲超时需大于静默间隔上限，并配合心跳 |
| 心跳 | 客户端与服务端定期 ping，防止中间设备清理空闲会话 |
| 排查 | 连接周期性断开时，从链路上游逐层核对空闲超时 |
典型使用场景
- 在线客服与消息推送：需要服务端主动向客户端推数据
- 协同编辑与实时看板：长连接承载高频小消息
- 行情与状态推送：消息间隔不固定，长静默期反而更常见
- 把长连接服务放到负载均衡后面，便于统一扩容与后端摘除
测试协议升级握手
测试协议升级握手
curl -sv -H 'Connection: Upgrade' -H 'Upgrade: websocket' \
-H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \
http://<LB地址>/ws 2>&1 | grep -i -E 'HTTP/|upgrade'
# 期望看到 101 Switching Protocols断连排查顺序
| 环节 | 检查点 |
|---|---|
| 客户端 | 是否实现心跳与自动重连 |
| 负载均衡 | 空闲超时是否大于心跳间隔 |
| CDN 或 WAF | 是否支持长连接并放宽超时 |
| 后端应用 | 自身连接上限与超时设置 |
CDN、WAF、负载均衡、接入网关任意一层的空闲超时都可能先清理连接，按链路顺序逐层核对。
扩容时的注意点
长连接会导致流量分布与连接数分布不一致：某台后端可能连着大量空闲连接，却几乎不消耗带宽，扩容时如果只看带宽指标就会判断失误。建议把「活跃连接数」和「平均连接时长」加入监控，缩容前先用连接摘除让存量连接自然结束，而不是直接下线实例；否则大量用户会在同一时刻被动断连并集中重连，形成新的尖峰。