为什么应用层心跳是 WSS 长连接的“保命符”
WebSocket Secure 作为全双工通信协议，承载着消息推送、实时协作、在线游戏等大量业务。但在生产环境中，许多开发者遇到过这样的场景：连接建立后十几分钟或几十分钟后悄然断开，客户端却没有收到任何错误事件。主要原因并非 WebSocket 协议本身的问题，而是介于浏览器和服务器之间的各种中间件——Nginx、HAProxy、云托管负载均衡器以及运营商网关——它们会默认在一定空闲时间后关闭 TCP 连接。
例如 Nginx 默认的 proxy_read_timeout 是 60 秒，AWS ALB 的空闲超时默认 60 秒，某些 CDN 或反向代理的阈值甚至更短。当连接上没有数据流动超过该时间，中间件就会主动拆除连接。底层 TCP keepalive 机制默认触发间隔通常为 2 小时（Linux 默认值），远远无法满足毫秒级超时场景。在应用层实现轻量心跳，才是从根源上保持连接活跃、防止中间件“休眠”回收连接的标准做法。
WSS 长连接的工作原理与常见超时场景
一个完整的 WSS 连接经过 TCP 三次握手、TLS 握手、WebSocket 升级握手后建立。此后数据帧以掩码（客户端到服务端）或非掩码（服务端到客户端）形式直接传输。协议的关闭只由一方发送 Close 帧发起，但如果中间设备直接中断 TCP 连接，双方将无法感知——直到下一次发送数据时触发超时或异常。
中间件的空闲超时
- 反向代理（Nginx/HAProxy）：通过
proxy_read_timeout和proxy_send_timeout控制，默认 60 秒无双向流量即中断。 - 云负载均衡器：如 AWS ALB 默认 60 秒，阿里云 SLB 默认 60 秒（可调至 900 秒），但更长的超时意味着连接存储开销。
- 运营商 NAT 网关：通常对 UDP 映射保留 30-300 秒，对 TCP 映射保留 10-30 分钟，但 TCP 保活报文（keepalive probe）可能被过滤。
因此，无论服务端将 WSS 超时设得多长，只要经过上述任一设备，连接寿命就会受制于其中最短的超时阈值。
服务端主动回收
即使没有中间件，服务端框架（如 Node.js 的 ws 库、Python 的 websockets 库、Go 的 gorilla/websocket）通常不会自动断开空闲连接。但为了防御资源耗尽，很多库或应用层自建了空闲超时机制——当一定时间内没有收到任何帧（包括 Ping/Pong），就会主动关闭连接。如果不配置心跳，这一机制会按时清退“看起来”正常的连接。
应用层心跳的设计原则与参数选择
心跳包格式应轻量
心跳帧应尽可能小，使用 WebSocket 的 Ping/Pong 帧是最佳选择：Ping 帧不含有效载荷（或仅含少量数据），服务端收到后自动回复 Pong 帧，由底层 WebSocket 库处理，应用代码无需序列化。如果库不支持自定义 Ping，可以改用一条极短的 JSON 消息，例如 { "type": "ping" }，服务端回复 { "type": "pong" }。注意避免携带业务数据，以免干扰连接状态判断。
心跳间隔的“三分之一原则”
一个安全且通用的做法：将心跳间隔设为链路上最短空闲超时时间的 1/3 或 1/2。例如若已知 Nginx 超时 60 秒，则将心跳间隔设为 20～30 秒。这样即使一次心跳丢失（网络抖动），下次心跳仍能在超时前达到；同时留出 2 次左右的重试机会。实际项目中考虑在 15 秒到 45 秒之间调整，避免过于频繁增加网络负担或过于稀疏无法覆盖超时。
重试与断开策略
单向心跳有一个风险：服务端如果连续未收到客户端心跳，会认为客户端离线而断开；客户端也可能因为服务端未回复而认为服务端挂掉。建议两端约定：连续 N 次（通常 3 次）未收到对方心跳帧则主动关闭连接并触发重连。关闭前可发送 Close 帧带 reason code 1000 让对端知道是正常关闭，而非异常中断。
避免心跳风暴
多个客户端同时重连后可能以相同间隔发送心跳，导致短时间内流量尖刺。解决方案是为每个连接引入随机偏移量：interval + random(0, interval/3)。此外，服务端应限制同一 IP 的 WebSocket 连接数，并将心跳包计入限流策略。
前后端具体实现示例
Node.js 服务端（基于 ws 库）
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws) => {
ws.isAlive = true;
ws.on('pong', () => { ws.isAlive = true; });
// 每 30 秒发送一次 Ping
const interval = setInterval(() => {
if (ws.isAlive === false) return ws.terminate();
ws.isAlive = false;
ws.ping();
}, 30000);
ws.on('close', () => clearInterval(interval));
});
这里利用 ws.ping() 发送 WebSocket 内置 Ping 帧，浏览器收到后自动回复 Pong，无需应用层处理。注意 ws 库的 ping() 在 WSS 下同样正常工作。
Python 服务端（基于 websockets 库）
import asyncio
import websockets
async def handler(websocket: websockets.WebSocketServerProtocol):
# websockets 库内置心跳：ping_interval
# 创建 server 时设置：
# await websockets.serve(handler, "0.0.0.0", 8765, ping_interval=20, ping_timeout=10)
pass
Python 的 websockets 库在 v10.0+ 后默认开启 Ping/Pong，只需在 serve 时传入 ping_interval 和 ping_timeout，库会自动维护心跳并丢弃超时连接。
前端浏览器实现
const ws = new WebSocket('wss://example.com');
let pingInterval;
ws.onopen = () => {
pingInterval = setInterval(() => {
ws.send(JSON.stringify({ type: 'ping' }));
}, 20000);
};
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
if (data.type === 'pong') {
// 确认服务端存活，可记录时间
}
};
ws.onclose = () => {
clearInterval(pingInterval);
// 触发重连
};
因为浏览器原生 WebSocket API 不暴露 ping() 方法（W3C 规范不允许），所以只能通过自定义消息模拟。这里要注意服务端必须实现对应的 pong 回复逻辑。
反向代理 Nginx 配置要点
location /wss {
proxy_pass http://upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# 调大读写超时，防止过早断开
proxy_read_timeout 60s;
proxy_send_timeout 60s;
}
注意 proxy_read_timeout 的单位是秒，可以设置为和心跳间隔匹配的值（如 70 秒），但更推荐依靠应用层心跳保持连接活跃，而非单纯调大超时——因为过大的超时也会让连接积压。
防心跳超时的常见陷阱与解决方案
陷阱1：仅依赖 TCP keepalive
TCP keepalive 默认间隔 2 小时（7200 秒），探测次数 9 次，意味着最长 2 小时才检测一次。即使调整到 30 秒，中间件（如 NAT 网关）可能不认识 TCP keepalive 探针，会将其视为普通数据包过滤掉。只有应用层心跳使用 WebSocket 协议帧，才能被所有中间设备识别为合法流量。
陷阱2：心跳间隔与服务端超时脱节
有些开发者设置了 10 秒的心跳，却未检查上游云负载均衡器的超时策略。例如 AWS ALB 空闲超时是 60 秒，10 秒心跳本应安全，但如果 ALB 之前还有一层 Nginx 超时 120 秒，那么心跳只照顾了 Nginx 而忽视了 ALB。正确做法是梳理全链路代理设备的超时参数，取最小值作为心跳设计依据。
陷阱3：忽略服务端单向超时
假设客户端每 20 秒发一次心跳，服务端回复 Pong。如果某次服务端因为抖动没有及时回复，客户端会认为超时断开——但连接实际上可能还活着。更好的方案：两端都开启双向心跳检测。服务端在 ping_interval 到期时发送 Ping，客户端回复 Pong；同时客户端也定期发送自定义 Ping 消息。这样任何一方的网络问题都能被及时捕获。
陷阱4：心跳包过大增加带宽成本
某些开发者将完整的业务数据（如 token、时间戳）压在心跳里。正确做法：Ping 帧空载荷，或自定义消息只用一个字节标识类型。如 0x09 代表 Ping，0x0A 代表 Pong。在 WSS 中由于 TLS 加密，消息头部和尾部都有额外开销，但载荷越小心跳影响越小。
生产环境下的监控与验证
- 连接存活率指标：在服务端记录每个连接的最近一次心跳时间。如果超过 2 倍心跳间隔未收到任何帧，则视为僵尸连接并主动清理。记录清理原因（心跳超时）到日志中。
- 心跳成功/失败统计：通过 Prometheus 指标
websocket_ping_count和websocket_pong_miss观察总体健康度。若 pong miss 比例突然升高，可能预示着中间件配置变更或网络故障。 - 自动化测试：在网络模拟器（如 Toxiproxy）中注入延迟、丢包或连接中断，验证客户端是否能按预期重连、心跳间隔是否合理。
- Wireshark 抓包校验：在 WSS 连接中捕获 TLS 解密后的数据，确认 WebSocket Ping/Pong 帧按时出现，且中间设备没有错误地终止连接。
结语：动态调优而非一劳永逸
应用层心跳并非配置一次就万事大吉。业务用户分布不同网络环境，云服务商调整负载均衡默认参数，甚至微服务架构中 sidecar 代理的加入都可能改变空闲超时阈值。建议将心跳间隔、重试次数设计为可调配置项，通过管理后台或环境变量下发。定期分析真实连接断开日志，如果发现“因心跳超时关闭”的记录异常增多，及时调整心跳频率或检查上游网络设备变更。只有把心跳机制当作一个持续维护的运维任务，WSS 长连接才能真正做到稳定可靠。
延伸阅读