WebSocket与实时通信：从长连接到心跳保活与断线重连的线上指南

半年前我接手了一个带实时推送需求的后台项目，第一反应就是：这不就是套WebSocket嘛，把原来的定时轮询改成一条长连接推送不就行了。结果真的把WebSocket接上线之后，接下来的两周我基本都在跟“连接突然断开”“浏览器页面崩溃”“线上告警半夜响”较劲。最后把我从坑里捞出来的，不是某个高大上的框架，而是一个专门负责扛住长连接接入层的小网关，我习惯把它叫做“脉脉”。这里先说明一下，它不是职场社交平台那个脉脉，是我们项目里给消息网关起的内部代号，干的是消息伴侣的活。

如果你正准备接触WebSocket，或者已经写过几条收发消息的Demo但还没上过生产环境，这篇文章值得看完。我会讲清楚WebSocket为什么能解决实时通信问题、为什么我不建议一上来就自建长连接服务、前端接入最常见的几个坑、一条报错信息的完整排查流程，以及Charles抓包、心跳保活、断线重连这些平时容易被忽略的稳定性细节。这里面的每一段，基本都来自我真实踩过的坑和复盘过的线上事故。

1. WebSocket解决的远不止是“省几个HTTP请求”

1.1 为什么轮询总是最省事的方案，却不是最省钱的方案

最早这个后台项目的需求其实很朴素：订单状态变了，希望正在看详情页的用户能比较快地看到新状态。第一版实现用的是定时轮询，前端每5秒请求一次接口，把最新的订单状态拉回来。从开发角度讲，这确实是最省事的方案，后端就是一个普通HTTP接口，前端一个setInterval完事，没有任何额外学习成本。

但上线之后问题马上暴露出来了。第一是延迟，5秒的轮询间隔意味着用户最坏情况下要等接近5秒才能看到状态变化，做客服工单的时候用户会反复追问“为什么还没刷新”。第二是浪费，我们把间隔缩短到2秒之后，后端接口的QPS直接翻了快三倍，高峰期一台实例的CPU从20%冲到60%多，而真正有数据变化的请求占比可能连10%都不到。换句话说，大量请求都是在空转。

这就涉及一个本质问题：HTTP协议是“请求-响应”模型，如果服务端没有新数据，客户端也必须定期问一次才知道“没有新数据”。这就像你每隔几秒就去信箱看一次有没有信，明明大部分时候信箱都是空的，但你不敢不去看，因为寄信人不会主动通知你。

1.2 HTTP、长轮询、SSE与WebSocket：四条实时路线的对比

当时我梳理了一下，能实现“服务端主动推送”的方案大概有四条路，它们的差异非常值得入门时搞清楚。

长轮询当时也考虑过，原理是客户端发一个请求过去，服务端先不给响应，等有新数据或者超过比如30秒再返回，客户端收到后立刻发起下一个请求。看起来比普通轮询省一点请求量，但服务端要维护大量挂起的请求，一旦实例重启或发生超时，这些请求全部要重新建立，处理起来并不轻松。而且它本质上仍然是单向的，做聊天、做实时状态上报这种需要客户端也频繁上行的场景会很别扭。

SSE则适合服务端单向广播的场景，比如股票行情、日志流，服务端往客户端推很舒服。但我们的需求里还有用户点击按钮后的即时交互，需要把操作也通过同一个通道传到服务端。这时候WebSocket的优势就很明显：它能把一条TCP连接升级成双向通道，客户端和服务端随时都能往对端发数据。

1.3 WebSocket协议里的最小常识：握手、数据帧和心跳

入门WebSocket一定要先理解它的握手过程。WebSocket并不是凭空冒出来的协议，它的连接通常是这样建立的：客户端先发一个普通HTTP请求，请求头里带上Upgrade: websocket，服务端同意后返回HTTP 101状态码，然后这条TCP连接就从HTTP协议切换成了WebSocket协议。

code复制GET /ws HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xxxx
Sec-WebSocket-Version: 13

切换完成之后，它就和HTTP没有关系了，双方可以随时发数据。数据以帧为单位传输，分为文本帧、二进制帧、Ping帧、Pong帧、Close帧等。常见的坑也在这里：虽然WebSocket协议里有Ping/Pong这种控制帧，但浏览器端的WebSocket API并没有把Ping/Pong帧暴露给Java开发者，你在JS里没法主动发一个协议层面的Ping。所以生产环境里大家普遍采用“应用层心跳”，也就是自己定义一种业务消息当心跳，比如隔20秒发一个{"type":"ping"}，服务端回一个{"type":"pong"}。这个后面我会专门展开讲。

如果要给一个生活化类比，我觉得HTTP像写信，每封信都要自己跑一趟邮局，投递结果要等回信才知道；WebSocket更像打电话，拨通之后双方都能随时说话，不用每说一句就重新拨一次号。理解了这一点，你就知道“实时通信为什么需要WebSocket”的答案了：它把“一问一答”变成了“一条随时可以说话的通路”。

2. 为什么我不自建长连接服务，而是把WebSocket这层外包给“脉脉”

2.1 自建WebSocket服务会翻车的三座大山

一开始我确实也想自己写一个WebSocket服务端，Spring Boot里加个Handler，再维护一个在线用户的Map，感觉并不复杂。但仔细往生产环境一想，事情就没那么简单了。

第一座山是连接容量。HTTP接口是无状态的，请求处理完连接就释放了。但WebSocket连接是长连接，一台普通业务服务器能同时撑住的空闲长连接数量和HTTP接口根本不是同一个量级。每条连接都要占用文件描述符、内核缓冲区、应用层对象。我粗略估算过，如果单机要扛5万条长连接，内存和句柄占用就够呛，更别说每条连接上还有收发消息的缓冲。

第二座山是网络环境的不可控。移动网络下用户经常在地铁、电梯、停车场之间穿梭，NAT设备、运营商防火墙、负载均衡设备对“空闲连接”往往有超时回收机制。客户端这边看起来连接还活着，实际上服务端早就收不到任何包了。如果不做心跳，不探测对端存活状态，这个连接就是一条“僵尸连接”，占着资源却没有任何作用。

第三座山是连接迁移和集群。真正线上不可能只部署一台实例，客户端可能连在A实例上，消息却从B实例的业务逻辑里发出来，那B怎么找到这个连接？服务端重启的时候大量连接同时断开，客户端同时重连上来又怎么保证不把服务打垮？这些问题已经超出“写一个WebSocket服务端”的范畴，它需要的是完整的长连接网关能力。

2.2 把长连接接入层交给“脉脉”后，我的业务服务端变成了什么样

所谓“脉脉”，本质上就是一个WebSocket长连接网关。它在我心里的定位是：所有客户端连接都连到脉脉上，由它统一维护连接生命周期、心跳保活、会话路由和消息推送。业务后端完全不需要关心浏览器或App的长连接在哪台机器上，只需要调用脉脉提供的OpenAPI把消息发出去。

这样带来的直接好处是，我的业务服务从“要时刻维持几十万条连接”的重状态服务，变成了一个可以随便水平扩展的无状态服务。我只需要在业务逻辑里确定“这个用户应该收到什么消息”，然后把消息交给脉脉就好。

整条链路的形态大概是这样的：浏览器或App通过wss://连到脉脉网关，连接建立成功后，脉脉会返回一个代表当前会话的连接ID，并把连接绑定到用户的业务ID上。当有消息需要推送给用户时，业务后端调用脉脉的推送接口，传入用户的业务ID和消息内容。

code复制POST https://gateway.internal.example.com/v1/push
Content-Type: application/json

{
  "userId": "user_10086",
  "event": "order.status.changed",
  "data": {
    "orderId": "20250613001",
    "status": "shipped"
  }
}

脉脉收到后，会根据userId找到对应的在线连接，然后把消息从连接上推给客户端。如果用户不在线，脉脉会告诉我“这个消息没有投递成功”，我再决定是走离线消息还是放弃这次推送。这个分工非常干净，连接相关的脏活累活都下沉到了网关层。

2.3 网关和业务服务之间，还要补齐鉴权和离线消息这两块拼图

有人可能会问：网关把连接都收走了，鉴权怎么做？其实很简单，客户端建立WebSocket连接时带一个临时Token，脉脉拿到Token后回调业务服务或直接校验签名，校验通过才允许连接建立。这个Token通常有过期时间，所以真实项目里往往还会在业务层维护一个“连接有效期”，过期后强制客户端重新鉴权。

离线消息也是一块容易被忽略的拼图。如果用户只是短暂断网，比如坐电梯、手机切后台，这期间产生的几条重要消息不应该直接丢掉。我们当时的做法是：脉脉推送失败时返回一个明确的失败标记，业务后端收到这个标记后把消息写入Redis Stream，等客户端重新建立连接并上报一个lastSyncId时，再把这个时间段内没推到的消息补推过去。

我当时非常庆幸把长连接这一层交给了脉脉，而不是自己从零维护。因为消息网关需要处理的连接风暴、集群内部路由、心跳探测、NAT穿透策略，短时间靠几个人很难打磨到稳定。把精力留给真正有业务价值的逻辑，这才是“好搭档”最大的意义。

3. 前端接入最容易翻车的地方：回调、版本兼容和浏览器崩溃

3.1 回调配不上同步思维，是前端新手最常见的地基问题

WebSocket前端API本身并不复杂，但很多人第一次写的时候会下意识用同步思维的写法，结果代码跑不通。最经典的问题就是连接还没建立成功就立刻send：

code复制const ws = new WebSocket('wss://api.example.com/ws');

// 这行几乎一定会失败，或者消息丢失
ws.send('hello');

WebSocket的连接过程是异步的，new WebSocket()之后，连接并不是瞬间建立完成的。你必须等onopen事件触发之后，才能安全地发送数据。同样地，收到消息也不是通过返回值拿到的，而是通过onmessage回调。

我当时的前端同事踩过一次很深刻的坑：他写了一个业务方法，建立连接之后立刻去后端拉取未读消息，却发现大多数时候能成功、偶尔失败。后来才发现，失败的原因是在某些网络慢的情况下，send执行时连接还没有完成握手。正确写法很简单，所有消息流必须在onopen之后启动，或者在send之前检查readyState：

code复制const ws = new WebSocket('wss://api.example.com/ws');

ws.onopen = () => {
  ws.send(JSON.stringify({ type: 'greeting', content: 'hello' }));
};

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  handleMessage(msg);
};

ws.onerror = (error) => {
  console.error('WebSocket error', error);
};

ws.onclose = (event) => {
  console.log('connection closed', event.code, event.reason);
};

如果消息类型比较多，建议不要一边写ws.onmessage一边到处拼业务逻辑，而是封装一个简单的连接管理类，把回调注册、消息分发、状态管理集中起来。这样后期加心跳、加重连，会省很多事。

3.2 “谷歌浏览器高版本用不了WebSocket”的真相：多数是混合内容拦截

我搜过不少“谷歌浏览器高版本无法启用WebSocket”的讨论，很多人以为是浏览器把WebSocket禁掉了，实际上这是对术语的误解。Chrome从来不会禁用WebSocket，真正拦截的是“在HTTPS页面里建立不加密的ws://连接”，也就是浏览器的混合内容安全策略。

如果你的页面本身是通过https://打开的，而你尝试连接的是ws://api.example.com/ws，Chrome会直接阻止这个连接，控制台会报类似Mixed Content: The page at 'https://...' was loaded over HTTPS, but attempted to connect to an insecure WebSocket endpoint 'ws://...'的错误。新版浏览器对混合内容限制越来越严格，本地开发偶尔能放行，线上环境基本都会被拦下来。

解决办法也很简单：线上环境统一使用wss://，WebSocket的TLS加密和HTTPS是同一套体系，只要域名有SSL证书就能用。如果前端在https页面下看到WebSocket连接立即失败，先别怀疑浏览器版本，优先检查自己是不是把ws://和wss://写错了，或者证书链是否完整。

另外还有一种情况是公司网络代理或防火墙只放行了443端口，如果WebSocket服务跑在自定义端口上就可能被拦截。线上最好让网关和页面共用443端口，或者明确把端口加入白名单，否则排障会很痛苦。

3.3 消息频率失控、无限重连循环，才是浏览器崩溃的真凶

还有一个容易让前端页面崩溃的场景：服务端推送频率很高，前端每收到一条消息就直接操作DOM更新页面，没有任何节流或批处理。比如价格波动、实时位置、日志流这类场景，一秒钟可能推几十条甚至上百条消息，如果每条都立刻创建DOM节点，浏览器一定会越跑越卡，最终崩溃。

很多文章会用“内存泄漏”来概括这类问题，但更准确的原因其实是消息消费速度跟不上生产速度，UI线程被大量微任务和渲染任务占满。正确的做法是把UI更新改为批量处理，比如用requestAnimationFrame做一帧合并：

code复制let pendingMessages = [];
let isScheduled = false;

ws.onmessage = (event) => {
  const message = JSON.parse(event.data);
  pendingMessages.push(message);

  if (!isScheduled) {
    isScheduled = true;
    requestAnimationFrame(() => {
      const batch = pendingMessages.slice();
      pendingMessages = [];
      isScheduled = false;
      renderBatch(batch);
    });
  }
};

这样即使一秒钟来了100条消息，最终渲染次数也基本被限制在帧率以内。配合maxPending限制，如果积压超过一定数量就丢弃一些不重要的中间状态，页面就能稳定很多。

另一个崩溃来源是无限重连。有些开发者在onclose里直接调用connect()，形成递归式的重连，如果服务端还没恢复，客户端就会以极高频率发起重连请求，不仅浏览器卡死，服务端也可能被重连风暴打崩。这个问题我在第5章会给出更详细的解决代码。

4. “stream disconnected”两段报错背后，服务端主动断连的完整排查过程

4.1 第一次看到这句报错，我第一反应是查错了方向

做实时通信，随时要面对断连。有一段时间我们的客户端日志里频繁出现下面两行报错：

code复制stream disconnected before completion: websocket closed by server before res
stream disconnected before completion: failed to send websocket request: io

第一行翻译过来大概是：服务端在还没返回完整响应之前就关闭了WebSocket连接。第二行意思是：发送WebSocket请求时发生I/O错误。乍一看很多人会把它理解成“服务端拒绝了我”或者“网络断了”，然后去查服务端有没有主动关闭连接的代码，结果查了半天没发现任何问题。

后来我复盘才明白，这种报错的特点是它的确发生在“发送”或“等待响应”的环节，但根源往往不在这一个时刻。真实情况是：客户端某个业务线程尝试发送一条请求或等待服务端响应时，发现底层的WebSocket连接早就被杀掉了。杀掉它的可能是服务端的空闲超时策略、可能是负载均衡设备的僵死连接回收、也可能是服务端进程在几秒前刚重启过。客户端只是在连接已经死亡之后才感知到而已。

4.2 三层日志定位法：客户端、网关、业务服务各看什么

后来我总结了一套“三层日志定位法”，以后再遇到类似断连问题，基本能快速缩小范围。核心思路是不要只看报错那一行，而是把客户端、网关、业务服务三个层面的日志放在同一个时间轴上对比。

在我们这次的真实情况里，客户端虽然连接建立了，但前端那个版本忘记加心跳逻辑。于是连接在空闲了一段时间之后，被网关的闲置回收策略判定为死连接并断开。客户端这时候并不知情，直到下一次业务逻辑试图通过这个连接发送数据时才报了“failed to send websocket request: io”这样的错误。

所以排查断连问题，第一步永远是先确认连接是什么时候断的、断在哪里，而不是只看业务代码有没有问题。如果服务端日志里明确写了idle timeout，那你真正的瓶颈就是“客户端没有按时发心跳”或者“心跳数据没有被服务端正确识别为活跃信号”。

4.3 close code能告诉你的线索：1006、1008、1011到底意味着什么

WebSocket关闭时，onclose事件里会带上一个code和reason，这是非常宝贵的定位信息。我见过不少团队完全不记录close code，排查断连问题全靠猜，这是非常可惜的。

如果客户端拿到的是1006，尤其要注意：1006并不是对端应用层主动发出的关闭帧，而是底层连接突然消失。这时候你去业务服务里查logout事件大概率是查不到的，真正的原因往往是网关或系统本身把连接回收了。这一点对实时通信入门的人特别容易产生误导，一定要记牢。

如果是1008，通常会带reason，很可能是鉴权问题。我记得有一次我们的Token有效期设置为2小时，但前端只在页面刷新时重新换取Token，用户挂机超过2小时后，服务端主动用1008把连接关了。这类问题通过记录close reason就能一眼发现。

4.3 排查“服务端断连”时最容易忽略的三个隐藏因素

除了上面说的时间线对齐和close code记录，还有三个因素在实际排查中很容易被忽略。

第一个是连接空闲但业务服务以为它还活着。如果客户端只在业务动作时才发消息，没有定时的心跳包，服务端或中间网络设备会把这个连接归类为“空闲连接”，按照策略回收。这种现象在移动端非常常见：用户切后台一段时间再切回来，连接经常已经死了，恢复后需要重新连接。

第二个是进程重启后的连接迁移问题。服务端发布重启时，旧连接全部释放，客户端如果没有感知到TCP断开，可能还维护着一个“假活”的连接。更麻烦的是有些负载均衡设备在服务端进程重启后不会立刻向客户端发送RST，客户端只知道连接断了，但不知道是服务端已经重新部署了。这时候需要客户端建立一套“连接状态探活+自动重连”机制，而不能指望网络异常自动暴露。

第三个是消息发送频率过高导致连接被服务端主动断开。有些网关会限制单连接每秒消息量，超过阈值就断连。这类问题的日志通常会有too many messages或rate limit exceeded这样的字段。客户端需要做的不仅是增加心跳，还要从根本控制消息生产端的频率和批量大小。

5. Charles监听、心跳保活、断线重连：一套实时链路的日常运维手段

5.1 用Charles监听WebSocket连接：证书、SSL代理和正确排查顺序

先纠正一个搜索习惯：那个抓包工具叫Charles，经常有人拼成Chales或者chrales，搜不到教程真的不是教程太少。Charles本身是HTTP代理工具，但WebSocket over TLS（也就是wss://）需要先解密TLS才能看到消息内容，所以光开代理是不够的，还要配置SSL Proxying。

我和前端同事当时联调时流程是这样的：先把手机或浏览器代理指到运行Charles的电脑IP和8888端口，然后在Charles里安装并信任根证书，接着在Proxy -> SSL Proxying Settings里添加要抓包的域名和端口，格式类似api.example.com:443。如果你漏了端口，或写的是*，很可能匹配不上。

SSL Pro