WebSocket协议要点：弹幕游戏连接的稳定性与心跳重连实践

这第3集本来想直接往弹幕协议里钻，但我把进度往后调了半集。原因很简单——前两周我们的弹幕游戏原型接上弹幕网关之后，出现整片整片的连接断线，客户端日志里反反复复刷着“stream disconnected before completion: websocket closed by server before res”这种报错。一开始怀疑是网关的问题，后来抓包一条条排查才发现，是我们对WebSocket的理解停留在“能连上、能收消息”的层面，很多细节没吃透，才导致一个看起来最简单的环节变成第一道坎。

所以这一集我打算把地基重新打一遍：WebSocket基础知识。它不是给刚接触网络编程的新手准备的科普，而是结合抖音弹幕游戏这个具体场景，把协议原理、连接状态、心跳重连、常见抓坑以及消息协议设计串起来讲清楚。适合正在写弹幕游戏、连弹幕网关或者准备把观众弹幕变成游戏指令的开发者参考。你未必会亲手去实现一个WebSocket协议栈，但理解了它为什么这么设计，很多线上问题一眼就能定位到方向。

1. 弹幕游戏的实时链路：为什么短连接方案第一个出局

1.1 一条弹幕从观众手机到游戏场景要经过的路径

弹幕游戏的链路并不复杂：观众在直播间发弹幕，抖音弹幕网关把海量弹幕通过长连接推送给我们自己的游戏服务，游戏服务再把弹幕映射成游戏操作指令，广播给同一局的所有玩家客户端。玩家屏幕上看到的可能是“弹幕变成陨石砸下来”或者“刷666给角色加血”，但底层的通道逻辑完全一致。

这条链路最核心的要求是低延迟和双向通信。从观众点击发送，到游戏里产生反馈，中间隔着弹幕网关、业务服务器、游戏客户端渲染，如果每一跳都有明显延迟，互动效果就会变成“挥挥手三秒后才有人回应”，弹幕玩法的“即时反馈感”就没了。

我自己在给玩法定技术指标时一般会按这三条来卡：

• 观众弹幕从网关到达业务服务的传输延迟应该在几百毫秒以内，越接近实时越好。
• 游戏服务的状态变化要能主动推给所有玩家，而不是等着玩家来问“现在战况如何”。
• 每个观众端保持着一个长期存活的连接，避免每来一条弹幕就重新建一次连接。

这三点综合下来，WebSocket几乎是当前浏览器和客户端环境里最顺手的选择。它能在一根TCP连接上同时承载上行和下行数据，而且服务端有新的弹幕事件时可以马上推送，不需要客户端持续轮询。

1.2 轮询、长轮询、SSE 和 WebSocket 的本质差异

很多没接触过实时通信的开发者第一反应是“用定时器去请求接口不就行了”，做法也不复杂：前端每2秒调一次“最近弹幕列表”接口，有数据就更新UI。这种思路在单机玩具Demo里能跑通，放到真实弹幕场景马上会崩。

HTTP轮询最大的开销不在于数据本身，而在于请求头。每次建连都要把几百字节的Header传一遍，弹幕峰值常常每秒上千条，轮询拉取不但延迟不可控，还会给网关和业务服务带来巨大的无效请求量。弹幕数据本身是一条条几十字的小消息，却包在一层层HTTP协议里传，传输效率肉眼可见地低。

有人会想到长轮询：客户端发一个请求，服务端有数据才返回，没有数据就一直挂着。看着比普通轮询聪明，但本质上还是半双工的——服务端等下一次请求才能继续推送，而且HTTP代理、网关的超时设置很容易把挂起的请求掐断。

SSE（Server-Sent Events）比轮询好很多，服务端能持续单向下推，但它是单向的，只支持服务端到客户端的方向。弹幕游戏里客户端不仅收消息，还要上报控制指令、确认状态、发送准备信息，单向通道根本不够用。

WebSocket的价值正好弥补上面所有方案的空缺：一次HTTP握手完成协议升级，之后这条TCP连接保持打开，服务端和客户端随时可以对发数据，消息没有明显的HTTP头部负担，浏览器和主流开发框架都原生支持。拿打电话来类比最直观：HTTP轮询像是你每隔几秒给对方写一封信问“有消息吗”，WebSocket则是直接打通了电话，双方想说就说。

弹幕游戏选WebSocket不是因为它“流行”，而是这一场景对低延迟、双向通信、长连接和连接复用都有硬性要求，WebSocket恰好把这些能力都集成了。如果你要做的是简单弹幕墙单向展示，SSE可能更省事；但一旦涉及游戏操作的回传、同局状态同步，基本就绕不开WebSocket了。

2. 握手与帧格式：一次WebSocket通信背后的基本功

2.1 从HTTP Upgrade到101状态码，连接是怎么建立的

很多人用WebSocket写业务代码时，都是直接new WebSocket('wss://xxx')，然后监听onopen、onmessage。这样用当然没问题，但如果你没搞懂握手过程，遇到网关拒绝连接、返回403或者连接被重置时，会完全不知道从哪里查起。

WebSocket连接不是凭空冒出来的，它需要先把协议从HTTP升级到WebSocket。浏览器发起WebSocket连接时，实际发出的是一段特殊的HTTP GET请求，核心特征是带着Upgrade头和Sec-WebSocket-Key。

http复制GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务端收到这段请求之后，会取Sec-WebSocket-Key的值，拼上一个固定的GUID字符串，做一次SHA-1哈希，再转成Base64编码，放进响应头的Sec-WebSocket-Accept里，同时返回101状态码，表示“协议切换成功”。

http复制HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

这个设计看起来绕，实际上只是为了防止普通HTTP请求被误升级成WebSocket连接。如果服务端没有正确返回101，而是直接返回200或400，说明连接根本没有建立，后面再怎么写onmessage都是白等。我们在接入弹幕网关时遇到过一类问题，网关前置的负载均衡设备没放行Upgrade头，请求始终被当成普通HTTP处理，客户端表现就是连接一直pending到超时。这种问题上手查的时候很懵，因为你代码里握手过程完全不可见，但了解过HTTP Upgrade原理之后，思路就清晰多了。

2.2 数据帧格式：那一串二进制里到底有什么

握手结束之后，WebSocket的数据不再走HTTP格式，而是走自己的帧协议。为了排查各种诡异的连接问题，我建议至少把帧结构看懂，不要求你背下来，但要知道每个字节大概在干什么。

WebSocket帧的基本布局大致是这样的：

• FIN（1 bit）：标记这是不是消息的最后一帧。如果一个消息被拆成多帧发送，前面的帧FIN=0，最后一帧FIN=1。
• RSV1-3（各1 bit）：扩展字段，通常为0，只有启用扩展协议时才可能置1。
• Opcode（4 bits）：帧类型。0x1表示文本帧，0x2表示二进制帧，0x8表示关闭连接，0x9是Ping，0xA是Pong。
• Mask（1 bit）：掩码标志。浏览器和客户端发送给服务端的数据必须为1，服务端发给客户端时通常为0。
• Payload length（7 bits或扩展长度）：数据长度。如果长度小于126，直接用这7位表示；等于126时后面还有2字节表示长度；等于127时后面有8字节表示长度。
• Masking-key（4字节）：当Mask位为1时存在，用于数据解密。
• Payload data：实际负载数据。

掩码机制是WebSocket协议里比较有意思的一环。为什么客户端发给服务端的数据要强制加掩码？早期有一种攻击场景是，攻击者通过恶意网页向无辜的缓存服务器发起“伪造”请求，如果浏览器直接发送未经掩码的WebSocket数据，可能会污染缓存服务。所以协议规定客户端帧必须做掩码处理，把真实数据“遮”一下，服务端根据自己的角色区分处理。咱们平时写业务不需要自己实现掩码，但理解它能帮你解释一些抓包问题：在Charles里看到的WebSocket数据可以直接读，是它已经解析并展示出来的结果，并不代表线上协议里明文流通。

2.3 文本帧、二进制帧、关闭帧和Ping/Pong，都在什么场景用

Opcode决定了这一个WebSocket帧在应用层的含义。做弹幕游戏最常见的是文本帧和二进制帧。

弹幕网关推给我们的消息基本都是JSON字符串，对应WebSocket的文本帧，代码里onmessage拿到的event.data就是一段字符串，直接JSON.parse就能用。开发期我强烈建议先用文本格式，因为出问题时可以把原始消息直接打到日志里，肉眼定位非常方便。等以后流量做大了，为了减少序列化开销，再考虑切更紧凑的二进制协议。这一步不能省，不少团队一上来就直接用Protobuf，结果调试时每条消息都要额外写解码脚本，排查问题的成本反而更高。

Ping和Pong帧平时很不起眼，但心跳机制全靠它们。客户端可以周期性发送Ping帧，服务端收到后自动回Pong帧；反过来服务端也可以主动发Ping探测客户端是否存活。弹幕网关为了节省资源，通常会给每条连接设置空闲超时时间，如果一段时间内没有任何流量，就可能主动断开。要想让连接不被误杀，客户端就得定期发心跳维持活性，这个我们在下一节细讲。

还有一个总被忽略的类型是关闭帧。连接关闭不是直接断TCP，而是先发一个Opcode为0x8的关闭帧，里面可以携带关闭状态码和原因文本。状态码1000表示正常关闭，1001表示设备离线，1006是异常关闭，1009表示消息太大被拒收。我们在排查线上“莫名其妙被断线”的问题时，第一步就是看关闭帧的code是多少，有些服务端会在关闭原因里写清楚具体规则，早看早爽。

3. 连接生命周期管理：心跳、断线与重连才是稳不稳的分水岭

3.1 readyState：千万别用“猜”的来判断连接状态

WebSocket对象有一个readyState属性，有四个取值：0是CONNECTING，1是OPEN，2是CLOSING，3是CLOSED。大多数客户端代码的bug不在于连接建立失败，而在于连接已经断了，业务层还傻乎乎地往里发数据。

我们踩过一个很典型的坑：游戏房间进入倒计时后，有玩家网络闪断，WebSocket进入CLOSED状态，但业务层没有感知，仍然把“玩家就绪”的指令往socket里发。由于WebSocket.send在JS里是异步的，失败并不一定会立刻抛错，结果这一个人的状态就永远卡在半路。后来我们统一在发送函数前面加了状态检查：

javascript复制function sendMessage(socket, payload) {
  if (!socket || socket.readyState !== WebSocket.OPEN) {
    console.warn('连接不可用，消息丢弃', payload);
    return false;
  }
  socket.send(JSON.stringify(payload));
  return true;
}

这段逻辑很简单，但它强制我们要求所有业务模块都先确认连接真的可用再发消息。不做这层防护，线上的偶发问题会非常难复现，因为你没法保证用户网络永远顺畅。

3.2 弹幕服务断开连接的几类常见原因

服务端不是平白无故断你连接的，绝大多数WebSocket断连都能找到明确诱因。

第一种是空闲超时。很多弹幕服务会设置一个时间窗口，比如60秒内没有任何上行消息、也没有收到客户端的心跳，就判定这个连接已经死了，直接把TCP连接回收。服务端要管理几十万条连接，不可能为一条“可能还活着”的连接长期占用资源。

第二种是网络层切换。手机在Wi-Fi和4G/5G之间切换时，客户端IP会变，原有的TCP连接基本都会断。此外，运营商NAT设备对长时间空闲的TCP连接也有回收机制，空闲久了连接被静默砍掉，客户端却感知不到，除非再发一条消息才可能触发超时错误。

第三种是服务端主动踢人或重启。弹幕网关升级、负载过高主动断开部分连接、或者检测到某些业务违规行为时，会主动下发关闭帧。如果我们能收到关闭帧，说明是正常关闭流程；最怕的是物理链路中断或者服务端进程崩溃，连接没有任何告别直接消失，客户端只能靠心跳超时来发现。

弹幕游戏这种场景比普通聊天室更容易触发空闲超时。聊天室里用户会持续发消息，连接天然活跃；但弹幕游戏里很多时候观众在看、玩家在操作，并没有持续的数据上行流量，如果刚好玩的是“不用发指令也能自动进行”的模式，连接可能长时间没有任何上行数据，服务端就容易误判为空闲。

3.3 心跳与指数退避重连：被动等待改成主动探测

为了避免连接被服务端静默回收，WebSocket客户端必须主动做心跳保活。常见方案是每隔一段时间发送一个Ping帧，或者发送一条业务层定义的心跳消息，服务端有响应就说明链路还通。

客户端代码里可以起一个定时器，每30秒发一次Ping。服务端如果连续几次没有收到Pong，就判定连接已死，主动清理资源。你在对接一些弹幕网关时，文档会明确说“请每30秒发送心跳”，这个间隔不是拍脑袋定的，通常是服务端空闲回收阈值的二分之一左右。如果服务端空闲回收是60秒，客户端心跳间隔30秒就够，不要高频无脑发，纯浪费。

断线后的重连策略同样要做设计。最简单粗暴的方式是断线立即重连，但如果有几千个客户端同时断线，同时发起重连，服务端可能直接被重连风暴打挂。更稳妥的方式是指数退避加随机抖动：

javascript复制function scheduleReconnect(attempt) {
  const baseDelay = 1000;
  const maxDelay = 30000;
  const exponential = Math.min(maxDelay, baseDelay * Math.pow(2, attempt));
  const jitter = Math.random() * 1000;
  const delay = exponential + jitter;
  setTimeout(() => reconnect(), delay);
}

第一次重连大约1.2秒后，第二次约2.2秒，第三次约4.2秒，以此类推，封顶30秒左右。这样既不会让用户在闪断后等太久，也不会在服务端故障恢复时造成瞬间连接风暴。

断线重连还有一个关键点：要区分是用户主动关闭还是异常断开。用户主动退出直播间时不能再触发重连逻辑，不然会陷入“退了又被拉回来”的死循环。我习惯在业务层加一个allowReconnect标志位，用户主动退出时置false，连接管理器检测到这个标志就只走清理流程，不再尝试重连。

3.4 一个典型报错的完整排查路径

回到开头那个报错：“stream disconnected before completion: websocket closed by server before res”。这行提示在不同语言环境里长得不太一样，但意思通常是：连接还没正常完成（比如还没收到101响应，或者响应过程被中断），服务端就把连接关了。

我们复盘那次线上故障时，走的排查路径大致是这样：

第一步，先判断是握手阶段失败还是连接建立后被断。抓包看请求第一段HTTP Upgrade发出的时间和服务端断开的间隔。如果间隔极短，基本可以确定是握手校验失败；如果间隔是从几十秒到几分钟不等，那就要往超时策略上查。

第二步，确认是否走代理或负载均衡。我们在测试环境一切正常，上生产就断开，最后发现生产环境在客户端和服务端之间多了一层网关，网关的空闲连接超时设置只有15秒，比业务侧的心跳间隔还短，连接自然总是被掐断。把网关超时调长之后问题立刻消失。

第三步，看服务端返回的关闭码和关闭原因。很多WebSocket框架允许服务端在主动断开时附带原因文本，比如“heartbeat timeout after 60s”或“invalid origin”。看到这类信息基本就能定位到问题域。

第四步，如果服务端根本没有收到连接，就要检查防火墙、安全组、报文里的Origin是否被校验拒绝。浏览器发起的WebSocket请求会自动带上Origin头，有些服务端为了安全会校验这个字段，导致非白名单来源被拒。我们曾被这个坑过：用postman调试没问题，但在网页里连不上，最终发现是服务端只允许特定域名的Origin。

整个排查链路的核心思路不是盯着报错串看，而是拆出“握手失败”和“连接存活期被断开”两个分支，分头找证据。

4. WebSocket实战中的高频问题与排查记录

4.1 “WebSocket导致浏览器崩溃”是怎么发生的

网络热搜词里能看到不少“WebSocket导致浏览器崩溃”的讨论。根据我的经验，WebSocket本身不会把浏览器搞崩溃，真正崩溃的往往是页面里处理WebSocket消息的那段代码。

弹幕游戏实时性高，消息量又大，问题容易集中在三个地方：一是所有弹幕消息到达后都直接创建DOM节点并插入页面，没有做任何节点回收，内存占用直线上升，最终把渲染进程拖垮；二是JSON.parse高频执行但结果没有被正确释放，内存里堆积大量无用的对象引用； 三是在onmessage回调里同步执行了太重的计算逻辑，导致页面主线程卡死，看起来就像崩溃。

我们在做弹幕游戏时明确过一条红线：收到WebSocket消息后只做轻量处理，比如把消息扔进队列，UI层再按帧批量取走渲染。绝不能在每个消息回调里直接触发场景对象的创建、销毁或复杂逻辑。订阅弹幕频道、播报弹幕和游戏特效渲染要拆开来做，否则再多优化手段都顶不住千万级弹幕的洪峰。

4.2 “高版本谷歌浏览器无法启用WebSocket”的真实原因

网上有说法称谷歌浏览器高版本无法启用WebSocket，这基本是误解。Chrome一直默认支持WebSocket，不存在高版本主动关闭的开关。

那为什么有人会感觉连不上？真实原因通常是三类：

第一类是页面地址是HTTPS，但代码里连的是ws://，浏览器会按混合内容规则拦截。解决方式很简单：HTTPS页面下统一使用wss://，或者干脆把页面也降到HTTP联调。

第二类是页面被某种接入层拦了，比如公司局域网网关或安全策略软件没有放行Upgrade请求，表现为WebSocket握手一直pending，最终失败。这种问题换手机热点验证一下就能区分，如果是网络环境导致，用同一个客户端在手机流量下就能连上。

第三类是服务端没有正确处理协议升级请求。很多自研网关只转发了普通HTTP请求，遇到Upgrade头直接按普通请求处理，没有返回101。这在自定义协议网关中非常常见，不是你浏览器有问题，而是服务端没按规矩来。

遇到这类问题，我的排查顺序永远是先打开DevTools的Network面板，找到那条WebSocket请求，看状态码是101还是别的，再看Console有没有混合内容警告，基本五分钟就能判断问题出在哪一层。

4.3 Charles抓WebSocket与OBS配置的几个细节

调试WebSocket时，Charles是常用的工具。Charles新版支持在“WebSocket”标签页里看到握手之后上行的消息和下行消息。想抓明文消息，有个大坑要注意：如果连接走的是wss://，必须先配置Charles的SSL Proxying并安装证书，否则只能看到加密后的乱码，没法阅读具体数据内容。

抓WebSocket消息的姿势我推荐这么展开：先用浏览器DevTools的Network面板找一个单独的WS条目，面板里会显示握手信息、帧消息、关闭帧等；需要更全局地看上下游交互时才用Charles。理由很简单，Charles会站在中间代理层干扰连接，某些服务端如果校验Origin或证书，开了Charles反而连不上了。

顺带说一个和弹幕游戏直播相关的小场景：有些开发者会用OBS做直播间画面合成和特效联动，此时会用到OBS的WebSocket插件。OBS WebSocket的配置不是“导出成一个连接串”那么简单，它包含端口、密码认证和权限规则。拿不到正确格式，很容易出现“服务连上了但控制不了OBS”的情况。可以先把配置参数写好保存成JSON，再在插件里导入，确保端口、认证、权限都对上。

5. 弹幕消息协议：WebSocket之上的业务设计

5.1 消息结构里加一个“类型”字段

WebSocket保证的是一个完整双向通道，它不负责告诉你消息属于哪一类业务。如果直接往通道里塞消息，不约定结构，客户端收到之后要猜这是弹幕消息、点赞消息还是系统通知，代码会写得非常痛苦。

我建议所有应用层消息至少包含类型和负载两部分，心跳、认证、上行指令、下行通知都走同一条连接，但通过type区分。

json复制{
  "type": "danmaku",
  "seq": 20240318001,
  "ts": 1710000000,
  "data": {
    "uid": "123456",
    "nickname": "观众A",
    "content": "冲啊",
    "giftId": 0
  }
}

type字段让接收方可以做统一路由，seq字段可以用于排查丢消息和乱序问题。弹幕玩法的公屏投递不要求严格有序，但游戏操作指令一旦乱序会导致状态错乱，所以指令类消息能带序号就尽量带。

5.2 弹幕高并发消息别幻想“一条不漏”地渲染

所谓弹幕洪峰，是指一个爆款直播间里每秒能产生海量观众消息，游戏客户端如果打算把每一条弹幕都渲染成游戏里的一个元素，CPU、内存、网络全都会被打满。

实际业务中一定会做降频、聚合或抽样。最常见的做法是服务端先按窗口聚合，比如把200毫秒内的同类型弹幕聚合为一条带计数的事件，再推给游戏客户端；或者客户端收到消息后按优先级抽样，优先处理礼物、打赏等对游戏有实际影响的指令，普通文本弹幕做滚动展示即可。

这属于业务取舍，但很多人一开始没有意识到这个问题的严重性，直到第一次压测才发现瓶颈不在WebSocket吞吐，而在消息处理逻辑的设计。WebSocket本身单连接收发几万条消息是没问题的，问题在于“每条都触发一次游戏对象操作”这种架构设计。

5.3 连接是稀缺资源：按业务拆分而非每次新建

弹幕游戏客户端通常要同时维护两条WebSocket连接：一条连弹幕网关，订阅直播间弹幕流；另一条连自己的游戏服务，上报对局操作和接收游戏状态广播。最初我们图省事，把两种逻辑塞进同一条连接，结果游戏服务偶发重启时，连弹幕网关的通道也被一起断开重连，导致观众弹幕中断了几十秒，观感极差。

长期运营下来，我倾向于把不同生命周期的连接分开管理：弹幕网关连接生命周期跟随直播间状态，游戏服务连接生命周期跟随对局状态。直播间退出才关弹幕连接，对局结束不一定要关游戏连接。二者混合的话，任何一端的断线重连都会殃及另一端，复杂度成倍增加。

服务端广播也要按房间维度设计。弹幕指令推到服务端后，要对房间号做分组，只广播给当前房间的在线连接。如果做成全局广播，一局游戏的弹幕会推给所有玩家，不仅浪费带宽，还可能把弹幕数据错插进别的对局，导致游戏状态混乱。

WebSocket连接的资源开销其实不大，瓶颈往往在业务设计上。真正出现问题的时候，先回去看一下：是不是每个弹幕都当成一条独立消息处理了？是不是一个连接管了太多不该管的事？把这两件事理顺，弹幕游戏的实时通道一般就很稳了。

这一集聊到这里，我自己的习惯是每接一个新的弹幕玩法，先花一个小时把连接状态转移图、心跳间隔、重连策略、消息类型定义画成一张表贴在工位旁边。等到第4集我们正式解析弹幕网关的协议字段时，你会发现自己已经站在一个很扎实的基础上，后面进入正题会顺畅得多。