1. 为什么我把网页小游戏的网联层押注在 WebRTC P2P 上做网页小游戏最尴尬的时刻不是玩法设计不出来而是当你兴冲冲把双人联机功能加上去之后发现服务器带宽成了限速器。一个 60 帧的多人网页游戏如果所有操作都走中心服务器转发峰值并发稍微上来一点云主机费用和延迟就同时失控。我一开始做 OmniGame 的时候最想解决的就是这个问题能不能让浏览器和浏览器直接对话把中心服务器从实时数据链路里摘掉1.1 现状几十人同时在线的页游被服务器带宽卡死很多人做页游联机第一反应是 WebSocket 房间转发。这个方案开发起来确实顺手服务端收到消息按房间号广播出去逻辑简单排错也直观。但等到真上量你会算一笔账假设每个人每秒钟要同步 20 条小消息每条消息 200 字节一个房间 10 个人服务端就要承担 10(上传) 10*9(转发) 约 100 条/秒的消息处理。这还只是一个房间。当同时在线房间到 500 个服务器 CPU 和网络栈的压力立刻变得非常难看。更麻烦的是物理距离。中心服务器放在某个地域玩家分布在全国各地跨地域的 RTT 动不动 80ms 以上。对回合制小游戏还能忍对节奏类、动作类小游戏就是灾难。你按下去一个键音符已经过了两个拍子这种体验根本没法上线。1.2 P2P 不是新概念但 WebRTC 把入场券发给浏览器P2P 这种拓扑其实一点都不新鲜很多端游早就在用玩家主机作为房间权威其他人直连房主。以前这套思路拿到浏览器上行不通因为浏览器没有暴露通用的 UDP 和 TCP Socket API你想自己实现 NAT 穿透非常困难。这个困局是被 WebRTC 打破的。WebRTC 把 RTCPeerConnection、ICE、STUN/TURN 这些复杂协议全部集成进浏览器开发者不需要懂穿透原理也能建立浏览器到浏览器的数据通道。虽然有信令服务器做初步握手牵线但建立连接之后媒体流和 DataChannel 消息都是直接点对点流动中心服务器只承担毫秒级的信令转发不碰游戏业务数据。对网页小游戏来说这就是一个巨大的工程红利。1.3 OmniGame 的定位游戏运行时 网联框架OmniGame 从一开始就不是要做成一个大而全的游戏引擎。市面上有 Unity WebGL、Cocos它们做渲染、做物理、做编辑器都足够好但它们的联机方案默认绑定自家后端或者要你去自建同步服务器。OmniGame 的切入点更窄只负责两件事——提供一个极简的零依赖运行时让你能写轻量小游戏以及把 WebRTC P2P 的联机能力封装成接近普通函数调用的 API。为什么强调零依赖因为网页小游戏的生命周期往往很短可能是一个营销活动页、一个直播间的互动游戏、一个社群里的裂变小游戏。如果为了一个两周后下线的游戏去搭一套 Node 工程搞 Webpack 配置引入一堆 npm 包成本完全不成比例。零依赖意味着你可以直接写一个 HTML 文件或者最多引一个脚本文件就能跑起来。这也是为什么我在做 OmniGame 的时候把“不要让你为了跑游戏先折腾环境”当成第一原则。2. 零依赖的底层游戏运行时单文件内核如何跑起来说到零依赖很多人以为就是“代码写得乱一点不用框架”。但真正把一个运行时做成零依赖是需要做减法的。OmniGame 内核只保留四个核心概念场景、对象、更新循环、事件。没有组件化没有实体系统没有编辑器连资源加载都是直接用 HTML 原生能力。2.1 以浏览器为操作系统不引入构建工具、不引入框架我见过太多小游戏开发被构建工具劝退装 Node、配 Babel、配打包器、配热更新一整套流程还没开始写玩法就已经消耗掉半天热情。OmniGame 选择反过来直接在浏览器里运行源代码不做任何编译。开发时浏览器加载的就是你写的那个 JS 文件改完刷新就能看效果。这套方案在 ES Module 流行之后更加可行。你用script typemodule加载入口文件模块之间用import连接浏览器天然支持不需要打包器。对于小游戏这种规模的项目模块数量通常不会超过几十个浏览器直接加载源文件完全够用。生产环境要做优化的话用一个简单的文件拼接脚本或者原生importmap就能解决没必要上重型工具链。2.2 运行时最小抽象场景、对象、更新循环OmniGame 的运行时 API 看起来和传统游戏循环很像但实现极其轻。它维护一个场景栈每个场景包含对象列表对象上可以挂update和draw方法。requestAnimationFrame驱动主循环每个 tick 里按深度遍历场景对象先更新逻辑再绘制。这套抽象的关键在于约定游戏代码只需要实现特定接口引擎负责调度。画布渲染方面默认走 Canvas 2D因为 2D 小游戏 90% 的场景用 Canvas 2D 就够了。需要像素风、粒子、碰撞检测这些都可以在业务代码层自己实现运行时不做多余封装。这样设计的好处是当你需要调试帧率定位卡顿源头整个调用链非常短没有引擎层带来的黑盒。2.3 配置与资源用 HTML 标签加载游戏资产零依赖不代表游戏不能加载图片和音频。OmniGame 规定了一个惯例游戏资源全部通过 HTML 里的link、img、audio标签预先声明引擎在启动时扫描 DOM把加载好的资源缓存成键值对。游戏代码里直接asset(bgm)取用底层就是那几个 HTMLAudioElement 和 HTMLImageElement。这个设计可能不少人觉得简陋但仔细一盘算它省掉了资源清单、进度条、资源服务器等一整套基础设施。浏览器本身就有并发加载、缓存、解码能力你只是把它暴露给游戏逻辑。对营销页和活动小游戏来说资源通常就在几十 KB 到几 MB 之间完全没必要做成资产管线。真正遇到超大资源需求时你也越来越适合用真正的游戏引擎而不是 OmniGame。3. 信令层整个 P2P 链路中唯一绕不开的服务器WebRTC 名字里带 Peer但 WebRTC 不可能完全脱离服务器。浏览器和浏览器之间要建立连接首先得知道对方在哪里得把音视频或数据的参数协商好。这个“牵线搭桥”的过程就叫信令Signaling。我在 OmniGame 里做的原则是信令服务器只传递五种消息不做业务、不存游戏状态代码量压到最少。3.1 为什么 WebRTC 需要信令交换 SDP 和 ICE你可以把 WebRTC 连接理解成两个陌生人在不同大楼里要建一条专用管道。他们首先要互换自己的地址还要约定管道里用哪种规格的传输协议这些信息在 WebRTC 里就是 SDPSession Description Protocol和 ICE 候选。问题是浏览器 A 和浏览器 B 之间此时还没有建立数据通道怎么互传这些信息答案就是让它们先通过一个服务器转发信令。WebSocket 是最自然的选择因为它双向、低延迟、浏览器原生支持。信令服务器把 A 的 SDP 转给 B再把 B 的 SDP 转回 A然后交换 ICE 候选当两端都收集到足够的路由信息RTCPeerConnection 就开始尝试打通直连通道。一旦连接状态变成connected信令服务器就可以功成身退游戏里的实时数据完全不再经过它。3.2 30 行 WebSocket 信令服务我在 OmniGame 的示例仓库里放了一个不到 30 行的信令服务器实现用 Node.js 原生ws库没有框架没有数据库。它的核心就是一个房间通道表每个房间存着一组 WebSocket 连接收到消息就发给同房间其他连接。const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080 }); const rooms new Map(); wss.on(connection, (ws) { ws.roomId null; ws.on(message, (data) { const msg JSON.parse(data); if (msg.type join) { ws.roomId msg.roomId; if (!rooms.has(msg.roomId)) rooms.set(msg.roomId, new Set()); rooms.get(msg.roomId).add(ws); ws.send(JSON.stringify({ type: joined, members: rooms.get(msg.roomId).size })); return; } const peers rooms.get(ws.roomId); if (!peers) return; peers.forEach((peer) { if (peer ! ws) peer.send(data); }); }); ws.on(close, () { if (ws.roomId rooms.get(ws.roomId)) { rooms.get(ws.roomId).delete(ws); } }); });看到没有这个服务器就是个消息喇叭你在房间里喊话其他人能听见。所有 SDP、ICE 候选都通过 JSON 包转发。因为服务器不做持久化所以房间崩溃重建非常快扩容也只需要横向多开几个实例再用一个简单的路由规则把相同房间号打到同一个实例。小游戏活动只要不是同时在线几十万人这种轻量信令完全撑得住。3.3 用房间码作为连接凭证以及过期策略OmniGame 给玩家开房的凭证就是一串六位房间码。房主在游戏里点击“创建房间”信令服务器生成一个房间码其他人输入这个码就能加入。很多人在信令层问我要不要做 Token 鉴权我的经验是看业务风险。如果是内部测试房间码就够如果是公网运营建议在房间码基础上签一个短期 TokenServer 在join时校验防止有人扫房间码进来捣乱。房间码还有一个隐患假设房主退出房间空置如果服务器不清除这个房间后面加入的人会陷入无限等待。所以 OmniGame 的信令服务器实现了一个简单过期策略房间超过 5 分钟没有活跃信令就自动回收房主离开立即通知其他成员。这个策略在业务层做写 10 行就能搞定不必上 Redis 之类的东西。4. 从点击“开始游戏”到第一帧 P2P 数据联机关键路径信令搭好之后真正进入联机核心的是浏览器里的 RTCPeerConnection 逻辑。这一步是 OmniGame 封装最重的部分因为开发者不想关心 offer/answer 状态机只想调用一个joinRoom()拿到对方的数据通道。我会尽量拆开给你看里面到底发生了什么。4.1 RTCPeerConnection 的创建参数与 DataChannel创建联机连接核心对象是RTCPeerConnection。对网页小游戏我们只需要数据通道不需要音视频流所以参数可以精简const pc new RTCPeerConnection({ iceServers: [ { urls: [stun:stun.cloudflare.com:3478] } ] }); const dc pc.createDataChannel(game, { ordered: true });这里的iceServers配置了 STUN 服务器。STUN 的作用是帮浏览器探测自己的公网地址和端口映射方式这样 ICE 候选里能带上乙方可达的公网端点。我建议直接使用公共 STUN比如 Google 和 Cloudflare 提供的端点。如果业务规模不大公共 STUN 足够了一旦发现某些网络环境下 NAT 穿越失败率偏高再考虑上 TURN 中继。特别要注意TURN 会因为中继流量产生带宽成本那是 P2P 链路打不通时才应该启用的兜底方案。ordered: true表示数据通道按顺序投递对大多数游戏逻辑来说顺序性比吞吐量重要。如果你想走更极致的大流量同步比如多人同屏大量坐标可以再开一个ordered: false的通道专门传高频、允许丢包的坐标流。小游戏一般一个通道就够用。4.2 ICE 候选收集STUN 与宿主候选连接建立过程中ICE 候选的收集是阻塞项。每个端会收集自己的 host 候选本机局域网地址和 server reflexive 候选经过 STUN 探测后的公网地址。要想提高穿透成功率最好在两端收集完候选之后再统一交换一次而不是一边收集一边发那样容易让接收端错过某些有效候选组合。OmniGame 内部的做法是创建 PeerConnection 之后先收集候选等到icegatheringstate变成complete再把此时的 SDP 一并发给信令服务器。这个过程通常几百毫秒玩家体会不到延迟但能明显减少“明明同一个 LAN 却连不上”的尴尬情况。4.3 端到端延迟与消息分帧实践当 RTCPeerConnection 状态变成connectedDataChannel 的open事件触发你就可以在两端之间直接传输字符串或二进制数据。我在 OmniGame 的实现中默认把消息封装成一个小的二进制帧头前 2 字节消息类型动作同步、状态快照、心跳后 2 字节序列号剩余部分业务负载这么做不是为了炫技是为了在接收端快速分帧、去重、排序。WebRTC DataChannel 的消息边界是保留的——你 send 一次对端收一次不会出现 TCP 那种粘包问题。但正因为这样如果小游戏每帧都发好几条零碎消息通道上会有大量小包协议栈开销非常可观。OmniGame 做了一个简单的合帧同一帧内多条逻辑消息拼成一个 buffer 再 send接收端按帧头拆包实测在 60Hz 同步频率下能显著降低 DataChannel 的包数量。5. 主机权威Host Authority与状态同步设计P2P 连接建立起来之后还要回答一个核心问题游戏里的状态到底听谁的如果每个玩家都在自己的本地计算一份世界状态很快就会出现无法调和的分歧。对网页小游戏来说最简单的模式是主机权威房主的主机拥有最终决定权其他玩家把输入发给房主房主计算好状态后广播回所有玩家。5.1 为什么小游戏不适合纯帧同步很多实时对战游戏会采用帧同步所有客户端跑同一份逻辑输入下发到所有人每个客户端独立模拟确保结果一致。帧同步的问题在于它要求所有客户端确定性完全一致一套浮点计算、一次随机数生成、一次碰撞判定稍有差异就会产生蝴蝶效应。浏览器里跑游戏引擎、CPU 架构、浏览器实现都可能让你陷入不确定性的泥潭。网页小游戏如果为了做联机先把整个游戏逻辑改造成确定性执行模型工作量太大收益不成比例。主机权威模式就简单许多不管客机算得多不准真正的状态都以主机为准客机只负责渲染和接收输入响应。5.2 权威主机 消息转发 / 遮蔽逻辑在 OmniGame 的联机组件里房主创建连接时自动成为主机客户端连接上来时主机会在自己的对象池里生成对应的影子对象。客户端每帧发送自己的操作向量比如左移、跳跃、攻击主机收到后更新本地权威状态再把自己的状态广播到所有客户端。双方看到的延迟主要取决于主机到客户端的网络质量而不是中心服务器的位置。这里有几个工程细节值得说一下客户端本地不做预测的话按下按键要等主机回包屏幕才有反应体验非常差。所以我建议客户端可以做一个“乐观渲染”自己先动一下等主机快照回来后再做插值纠偏。这套机制在小游戏的逻辑简单时实现成本很低。主机广播不要每帧全量同步而是只同步有变化的状态。我在 OmniGame 里给对象加了一个脏标记只有 AABB、速度、朝向这些变化时才进入同步包静止对象根本不会出现在消息里。5.3 掉线与主机迁移主机一旦掉线整个房间就散了。这在 P2P 架构里是最难处理的问题。我的处理方案分两级如果此时房间只有两个玩家主机掉线就直接结束游戏引导重新匹配如果有三个人以上备用主机机制就派上用场——在客户端中加入该房间时信令服务器把加入顺序广播出去第二早的客户端自动备份主机的最新状态快照一旦主机失联第二早的客户端晋升为新主机其他人重新连接它的 PeerConnection。主机迁移的过程必然存在短暂断线但至少要保证房间不灭。这个机制在 OmniGame 里的实现只占几百行核心思路就是“角色是可转移的游戏数据是可重放的”。备份主机在正常模式下持续接受主机的状态快照并写入本地 shadow state切换时就从 shadow state 继续模拟玩家感受到的停顿大概只有一次 ICE 重连的时间。6. 工程化护栏当“零依赖”遇到浏览器差异零依赖可以免去构建工具的麻烦但换来的是你必须对浏览器差异有足够心理准备。不同的浏览器、不同的网络环境对 WebRTC 的支持程度和绕过 NAT 的力度都不一样。我在这部分踩了不少坑把需要重点盯住的工程化护栏列出来。6.1 浏览器兼容性与降级策略现代浏览器对 WebRTC 的支持已经基本统一但关键 API 的命名和时序在不同内核上还有差异。比如RTCPeerConnection的iceconnectionstatechange在旧版 Safari 上可能不触发某些中间状态。我的做法是不要依赖单一状态事件做业务判断而是在信令服务器和业务层都加上超时兜底。例如连接建立超过 15 秒仍未connected就弹提示“当前网络不支持直连请尝试更换网络”而不是让玩家无限转圈。对于实在打不通 P2P 的场景OmniGame 做了降级把原本发往 DataChannel 的消息中继到信令服务器由服务器转发给对端。这个方案相当于退回中心转发模式延迟会上去但至少游戏还能玩。降级开关由双方在连接建立后的第一次握手消息里协商决定不需要玩家手动干预。6.2 性能与延迟监控在控制台的应用我在开发 OmniGame 时在控制台里印了一批调试信息[OmniGame] peer connected, RTT12ms, candidates4 [OmniGame] host snapshot: objects23, bytes1482, tick45 [OmniGame] dataChannel bufferedAmount0, loss0通过这些输出我非常快速地定位过几个问题一是 DataChannel 发送过快导致bufferedAmount一直堆积后来改成按帧合并才好二是一些场景下 ICE 重连频繁后来发现是 WiFi 切网触发的。生产环境时这套调试输出会被关闭但开发期它比任何端到端测试工具都直接。6.3 安全通过浏览器安全限制处理不可信 P2P 数据P2P 意味着你会直接接收来自陌生人的数据浏览器沙箱能帮你挡住文件访问和系统调用但恶意数据仍然可能导致游戏崩溃、逻辑错乱。OmniGame 对从 DataChannel 收到的所有消息做两层校验第一层是帧头校验长度不合法直接丢弃第二层是业务层规范化比如坐标越界、速度超过合理阈值一律钳制到合法范围。另外一个很多开发者会忽略的点WebRTC 连接在公网上会暴露玩家 IP。如果小游戏面向不特定公众合规上要注意这一点。OmniGame 在隐私模式里可以强制走 TURN 中继让对端看不到彼此的裸 IP代价是流量成本和延迟上升。做不做取决于业务场景我建议至少提供这个选项。7. 实测与接入现有网页小游戏的效果技术选型说得再多不如实际跑一把。我把 OmniGame 接到了一个类似 mikutap 的网页版节奏小游戏上验证“零依赖 WebRTC P2P”这个组合在真实设备上的表现。这款游戏的核心玩法是鼠标键盘触发音符和颜色反馈非常适合测试低延迟联机下的同步精度。7.1 使用点击节拍器进行的验证测试场景非常简单两台笔记本一个开热点一个连热点房主打开游戏客机输入房间码加入随后两人同时点击按钮触发音符反馈。我故意让客机点击后本地立即渲染音符然后等主机广播状态回来后再对比偏差。实测结果在我的预期之内同一 LAN 下端到端状态延迟基本稳定在 5-15ms客机乐观渲染和主机权威状态几乎看不出偏差。跨运营商公网环境下RTT 波动到 40-80ms但因为在主机权威模式下主机广播频率是 30Hz客机做线性插值视觉上音符序列仍然连贯玩家基本感知不到网络抖动。7.2 OmniGame 的 API 使用游戏接入案例接入代码比我自己预期的还要少。在原有单机代码基础上只需要多做三件事初始化联机组件、监听输入并发送给主机、监听状态快照更新本地对象。const net new OmniGameNet({ roomId: ABC123, role: client }); net.on(connected, () { // 进入联机状态开始发送操作 document.addEventListener(keydown, (e) { net.sendInput({ type: pressed, code: e.code, time: performance.now() }); }); }); net.on(snapshot, (state) { // 用主机状态修正本地对象位置/颜色 applySnapshot(state); });房主那边更简单创建房间后启动主机循环在收到客机输入时更新音符状态再广播快照。整个接入过程没有改 Canvas 渲染逻辑也没有引入任何外部依赖。这让我确信对于“极简网页小游戏 实时联机”这个需求组合OmniGame 的路线是可行且高效的。7.3 从白皮书到实际部署的总结如果你也要做类似的事我最核心的建议是不要一开始就追求帧同步或全真模拟先跑通主机权威的小房间模式不要在信令服务器上堆业务逻辑让它保持轻不要忽略网络兜底P2P 打不通时的降级路径必须存在。网页小游戏的工程上限其实不是被浏览器限制的而是被你的架构决定。OmniGame 用零依赖换来了极低的入场门槛用 WebRTC P2P 换来了真正低延迟的玩家直连这套组合已经把普通 Web 开发者能够触及的联机体验拉到了一个相当高的位置。最后分享一个我在调试中的小技巧把 DataChannel 的bufferedAmount打到控制台面板上。这个数值能直观地反映当前端到端通道的拥塞程度如果你的游戏某个时刻突然掉帧卡顿凶手往往不是渲染逻辑而是这个数值悄悄涨到了几十 KB。把这一个指标盯住你能节省大量在游戏逻辑里找 bug 的时间。