我最近把网页小游戏合集项目 OmniGame 从零重构了一遍从立项第一天起就给自己上了两条硬约束运行时零依赖联机能走 WebRTC P2P 就绝不绕服务器中转。先把这俩约束摆出来是因为网页小游戏这个品类太容易走上“为了省事堆依赖”的邪路了。第三方库越堆越多加载越来越慢联机部分一上来就买服务器、开 WebSocket 网关结果一个二十兆以内的游戏项目光工程骨架就好几公斤重。这篇内容就是我整理出来的 OmniGame 技术白皮书核心想回答三个问题零依赖到底省掉了什么、省掉了这些之后拿什么顶上WebRTC P2P 在网页小游戏里能干什么、怎么从握手到传输完整落地以及这套方案的真实上限在哪哪些场景该用、哪些场景别硬用。全文没有什么高深理论全是工程取舍和实操记录适合所有想做网页小游戏联机、或者对零依赖和 P2P 感兴趣的前端开发者参考。我自己做下来的结论是这两条约束不是自虐而是把网页小游戏带回了它本来的位置——一个链接、一个浏览器、打开就能玩。下面直接进主题。1. 零依赖不是玄学是网页小游戏的工程选择1.1 为什么我先把第三方库清零网页小游戏有一个天然优势不需要下载安装打开链接就能玩。但这个优势非常脆弱加载速度一旦慢下来用户随手就关掉了。第三方依赖是加载速度的最大杀手一个动画辅助库、一个状态管理工具、一套 UI 组件即便做了 gzip 和 tree-shaking几张页面加起来往往就吃掉了几十甚至上百 KB。而我的整个游戏逻辑核心压缩之后可能才四五十 KB。为了一个库再背几十 KB 的运行时这个账怎么算都不划算。零依赖省掉的远不止体积。构建依赖串联起来之后每次升级都可能引入行为差异跨浏览器兼容问题也会从“我自己写的代码”变成“这个库在某个内核版本上表现异常”。调试的时候你要先分清是哪一层在出错修 bug 变成排查供应链问题。更现实的是安全审计成本你引用了二十个包就要信任二十个维护者和他们各自的传递依赖这对一个想长期运营的网页小游戏项目来说是一笔隐藏但持续的负债。我清零依赖之后整个项目的运行时栈变成了纯浏览器原生 APIDOM 操作用原生接口动画用 requestAnimationFrame 自己调度渲染用 Canvas 2D 直接画音效用 WebAudio 合成存档用 IndexedDB。有人会觉得这是在重复造轮子但实际并不是。现代浏览器原生 API 的能力已经相当完善游戏所需的基础设施绝大多数场景下有原生方案兜底真正需要自己补的只是薄薄的一层封装。1.2 从技术清单看“零依赖”怎么落地零依赖不代表“所有东西从汇编开始写”而是“选对原生默认值不为可有可无的便利买单”。我在 OmniGame 里做了一张替换表每遇到一个需求先看浏览器给了什么再决定要不要动手写。需求场景原生方案落地说明界面与场景渲染DOM Canvas 2D2D 小游戏用 Canvas 足够像素级控制比引擎抽象更直接动画与循环调度requestAnimationFrame自带屏幕刷新同步配合 dt 做插值和预测音频播放与合成WebAudio API音效可以直接用振荡器合成连音频文件体积都省了网络与联机WebSocket WebRTC信令用 WebSocket游戏数据走 WebRTC DataChannel本地持久化IndexedDB / localStorage存档直接用原生存储不引任何封装库模块组织原生 ES Modules浏览器原生支持 import开发期不需要打包器也能跑这张表看起来是个技术选型清单本质上是约束我自己的冲动不要把“想省事”当成“必须引入依赖”的理由。只要原生方案能覆盖 90% 的场景我就先不引库真到了 10% 覆盖不到的地方再针对性地手写一小段工具函数。整个过程下来单游戏页面从请求到可交互慢速网络下也能压在两三秒内本地开发不装 Node、不跑构建一个静态服务器就能起项目。这种感觉很纯粹甚至有点回到早期网页开发的味道。1.3 零依赖的真正代价想清楚边界我不能把零依赖吹成万能药。这个方案也有硬成本最现实的一点是你需要对浏览器原生 API 有更细的了解。比如 Canvas 2D 的绘制性能瓶颈在状态切换和 drawcall 数量如果不能像设计 DOM 结构一样去设计绘制批次画面复杂度一上来就容易卡。再比如音效合成虽然 WebAudio 完全能做出效果不错的声音但你要理解振荡器、增益节点、包络这些概念比直接丢一个 mp3 文件进去门槛高不少。第二个代价是“生态红利消失”。遇到成熟库提供的复杂能力比如物理引擎、骨骼动画、复杂寻路自己手写的成本可能远超省下的加载时间。我的原则是核心玩法相关的能力自己写通用且复杂度极高的能力才考虑引入而且尽量选体积小、无依赖、可内联的单文件方案。所以说到底零依赖是一条“默认值正确”的路线不是“绝对正确”的教条。它确保了项目保持轻盈但对开发者本人提出了更高的要求。把边界想清楚之后这条路是值得走的。2. 从“服务器中转”到 WebRTC P2P我为什么换赛道2.1 网页联机小游戏的延迟困局做网页小游戏联机绝大多数人会选择最稳妥的路线跑一台服务器前端通过 WebSocket 连上去所有玩家消息都先到服务器再由服务器广播回各客户端。这个模型实现简单也好维护但它有一个天然问题——延迟叠加。假设两个玩家一个在城市 A、一个在城市 B消息要先从 A 上行到服务器可能在中国中部或某个云厂商节点再下行到 B。折腾下来正常网络下也会多出几十毫秒甚至上百毫秒的开销。对回合制或慢节奏休闲游戏来说这点延迟无感。但动作类、反应类、派对类小游戏对延迟天生敏感哪怕只是五十毫秒的抖动玩家旋转镜头时能明显感觉到“肉”。WebRTC P2P 的价值就在这里让数据直接在两个浏览器之间流动不再绕行中心服务器。对等连接建立后A 到 B 的数据路径往往比经过服务器中转少了三分之一甚至一半的往返距离。这也是我把连入 OmniGame 的核心联机层从“服务器广播”改成 WebRTC P2P 的直接原因。注意这里说的 P2P 仅指“浏览器之间点对点传输游戏数据”不涉及任何资源索引和文件搜索场景这是两码事别混淆。2.2 一条 DataChannel 从握手到传输的完整生命周期WebRTC P2P 落地有个前提虽然数据面是点对点的但连接建立前仍然需要一次信令握手。因为两个浏览器互相不知道对方在哪必须有一个人帮忙牵线。我的信令服务是一个极其轻量的 WebSocket 服务只负责转发三种消息offer、answer、ICE candidate。游戏流量一旦跑起来信令服务基本就没事干了。下面是我在 OmniGame 里实际使用的建连核心代码TypeScript 写法逻辑上可以直接参考function createGamePeer(role: host | guest) { const peer new RTCPeerConnection({ iceServers: [ { urls: stun:stun.cloudflare.com:3478 }, { urls: stun:stun.l.google.com:19302 }, ], }); const channel role host ? peer.createDataChannel(game, { ordered: true }) : null; peer.onicecandidate (e) { if (e.candidate) { signal.send({ type: candidate, candidate: e.candidate.toJSON(), }); } }; if (channel) { channel.onopen () { transport.emit(open); }; channel.onmessage (e) { transport.dispatch(e.data); }; } else { peer.ondatachannel (e) { const recv e.channel; recv.onopen () transport.emit(open); recv.onmessage (e) transport.dispatch(e.data); }; } return { peer, channel }; }建连流程从代码里能看个大概我再把完整时序讲一遍。Host 创建 RTCPeerConnection 并 createDataChannel然后 createOffer、setLocalDescription再把产生的 SDP offer 通过信令发给 Guest。Guest 收到 offer 后 setRemoteDescriptioncreateAnswersetLocalDescription把 answer 发回。与此同时两边各自通过 onicecandidate 收集 ICE 候选并异步地发给对方对方收到后 addIceCandidate。当两端的 ICE 协商完成DataChannel 就会触发 onopen一条游戏数据的点到点通道就算通了。这里有个很多人第一次做会搞混的点SDP 交换要严格按“offer 先、answer 后”的顺序来但 ICE candidate 的交换完全可以在 SDP 交换的过程中并行进行。所以我在信令处理里刻意做了异步队列先保证 offer/answer 顺序candidate 来了就先存下来等 setRemoteDescription 完成后再统一 addIceCandidate避免出现“candidate 到了但远端描述还没设置”的错误。STUN 服务器解决的是公网地址发现问题默认加的这两个公共 STUN 在大部分场景下够用。但 WebRTC 有一个残酷现实不少网络环境对称型 NAT、企业网、部分移动网络只靠 STUN 打洞打不通这时候就需要 TURN 服务器做中继兜底。TURN 本质上还是走服务器转发所以它只是保底手段不是优先路径。我的建议是先不加 TURN通过日志统计直连成功率如果确实有一成以上的连接走不通再部署 TURN 也不迟。2.3 可靠与不可靠小游戏数据通道的传输策略DataChannel 底层是 SCTP over DTLS这个机制天然提供了两种传输风格可靠有序通道和不可靠无序通道。默认不额外设置参数时DataChannel 是可靠有序的数据不会丢、顺序不会乱类似 TCP 的行为适合传递房间状态、玩家加入退出、结算数据这类不允许出错的协议消息。但可靠有序是有代价的一旦某条消息在网络中丢了底层协议会重传后续所有消息都要等它补上才能继续这就是头部阻塞。在实时游戏里这种阻塞会导致明显卡顿感。所以我给高频、可丢失的数据单独设计了不可靠通道通过构造参数里的 maxRetransmits 或 maxPacketLifeTime 来限制重传次数或存活时间超过阈值直接丢。位置同步、输入帧这类数据就适合走这里因为玩家每秒钟都在产生大量新状态丢一帧旧数据根本无所谓等重传反而让画面更卡。我在 OmniGame 里实际开了两条 DataChannel一条可靠通道传控制类消息一条不可靠通道传高频游戏状态。两条通道互相独立不会因为一条通道的拥塞阻塞另一条。这就是为什么我在建连代码里把 createDataChannel 写成可配置的而不是固定一个通道用到底。做个简单对照数据类别通道策略原因加入/退出房间、游戏开始、结算可靠有序任何一条丢失都会导致状态错乱玩家操作输入、位置/朝向更新不可靠限时高频增量数据旧帧价值低重传反而延迟聊天消息、表情可靠有序或不可靠均可按交互成本取舍我选可靠聊天不用太频繁关键事件炸弹爆炸、道具拾取可靠有序这类事件需要所有玩家一致性看到2.4 什么时候不要用 P2P写这节是为了避免读者把 WebRTC P2P 当成银弹。我在 OmniGame 里敢大范围用 P2P是因为项目定位就是 2 到 8 人的小房间派对游戏每房间数据量低、人数少。一旦场景变化P2P 的限制就暴露出来了。第一个不适用场景是大型多人房间比如 50 人同场。全连接网状拓扑的数据量是 O(n²) 级别增长每加一个人其他所有人的上行和下行都要增加一条通道浏览器根本吃不消。第二个不适用场景是强服务端权威比如严肃的竞技对局需要服务器校验每个玩家操作来防作弊P2P 天然做不到这一点。第三个是极端 NAT 环境如果大量用户打洞失败被迫走 TURN那我等于花钱买了一台“形式上是中继、本质是代理”的服务器延迟和带宽成本比直接用 WebSocket 中转还高。所以我的结论很明确P2P 适合小规模、低数据量、对延迟敏感的玩法如果游戏要做大规模并发、严格反作弊或者用户网络环境太恶劣就老老实实用服务器中转不要为了炫技牺牲稳定性。边界清晰工程才能走远。3. OmniGame 的核心系统设计与落地实现3.1 三层架构Network / Room / Game为了让 WebRTC 不污染游戏业务代码我把 OmniGame 整个联机模块拆成了三层。网络层Network负责封装 RTCPeerConnection、DataChannel 的创建与生命周期管理对外只暴露 send(type, payload) 和 on(type, handler) 这类语义接口。房间层Room负责玩家加入退出、角色分配、主机选举和消息路由它会根据消息类型决定走可靠通道还是不可靠通道。游戏层Game只关心玩法本身比如玩家按了什么键、角色当前位置在哪、得分多少完全不感知底层是 P2P 还是服务器中转。这个分层最大的好处是如果某天某个玩法决定改用服务器权威我只需要替换网络层的内部实现Room 和 Game 几乎不用动。我在做 OmniGame 时反复提醒自己WebRTC 的天花板之一就是“技术和业务耦合”耦合一旦发生后面每次调连接策略都要牵动游戏逻辑那种改动是很痛苦的。分层以后联机消息在代码层面变得非常干净。比如玩家发送输入帧Game 层只要调用网络接口发送一个对象网络层负责序列化、加序号、塞进不可靠通道发出去。收消息时同理网络层解包后按类型分发Game 层只处理自己关心的事件。整个链路清晰出问题也好定位。3.2 消息帧协议怎么设计才不打架P2P 通道里传递的是二进制或字符串数据如果直接在 onmessage 里各传各的项目一长就会变成一团乱麻。我从一开始就定义了一个统一的消息帧格式所有 WebRTC 数据都走同一个序列化入口协议头包含几个关键字段opcode消息类型、seq发送端递增序号、roomId房间标识、tick游戏逻辑帧号、payload具体数据负载统一为 Uint8Array。单独把 seq 和 tick 摘出来讲一下。seq 是网络层的序号用来做发送端去重和乱序检测不需要所有消息都用但对不可靠通道的场景很关键接收端能通过 seq 判断某条状态是否过期。tick 是游戏层的帧号比如我可以规定游戏每 50 毫秒一个逻辑帧所有输入和状态的载体都打上 tick 标记这样接收端可以根据 tick 做插值和回放而不是依赖消息到达的墙钟时间。interface GameMessage { opcode: number; roomId: string; seq: number; tick: number; payload: Uint8Array; } function encodeMessage(msg: GameMessage): ArrayBuffer { const header new ArrayBuffer(12); const view new DataView(header); view.setUint8(0, msg.opcode); view.setUint16(1, msg.seq); view.setUint32(3, msg.tick); return header; }实际项目中我用的是更紧凑的二进制协议12 字节头 变长负载gzip 后几乎不会产生额外开销。设计消息帧时还有一个小细节一定不要往不可靠通道里塞超过单条 SCTP 消息合理尺寸的数据。DataChannel 虽然可以传大消息但大消息发生分片重组时在丢包场景下效率极差。我给自己定的经验值是单条消息尽量控制在 1KB 以内游戏状态同步超过这个量就拆成多条增量消息效果会好很多。3.3 Host 掉线怎么办迁移与重连P2P 拓扑里有一个无法回避的问题如果建连时选了一个 Host 负责集中接收和转发数据这个 Host 掉线整个房间就断了。我在 OmniGame 里为了避免这种情况做了两层设计优先采用“全连接网状拓扑”即每个客户端与其他所有客户端都建立单独的 P2P 连接没有中心节点任何一个人掉线不影响其他人同时保留定期心跳和 Host 迁移机制保证像裁判、计分这类“权威角色”始终有人接替。全连接在 2 到 8 人房间内完全可行连接数是 n(n-1)/28 人时也就 28 条通道现代浏览器轻松承载。真正需要 Host 迁移的场景集中在“共享游戏公共状态”上比如房间主持人手里的随机种子、房间设置、比分台账。我的做法是每个客户端都持有完整的房间状态副本Host 只是最终写入者。当 Host 心跳超时后存活玩家通过选举规则选出新 Host规则简单可靠——存活玩家中 playerId 字典序最小者当选。function chooseNewHost(players: Player[]) { const alive players.filter((p) p.connected); return alive.sort((a, b) a.playerId.localeCompare(b.playerId))[0]; }选举完成后新 Host 广播一条“状态快照”消息给所有客户端其他客户端用快照覆盖本地状态继续游戏整个迁移过程控制在几百毫秒内玩家体感上只是轻微卡顿一下。这类迁移动作在传统服务器模型里压根不需要考虑但在 P2P 里必须做扎实否则“掉线体验”会把前面所有延迟优化带来的好感全部清零。4. 实测数据、兼容性矩阵与问题排查实录4.1 我测的一组真实数据所有纸上谈兵都该用数据验证。我在 OmniGame 联机模块开发完成后分别在几种不同的网络场景下做了实测样本不算大但至少能说明趋势。测试方式是两台电脑、两个浏览器标签通过同一链接进入同一房间跑一局完整的派对小游戏过程中统计建连耗时和数据通道延迟。测试场景建连成功率建连中位耗时数据通道延迟中位数同一局域网100%20/200.6s3ms - 8ms同城跨运营商宽带约 95%19/201.2s15ms - 35ms跨省宽带直连约 85%17/201.8s35ms - 80ms直连失败走 TURN 中继100%配置后2.5s60ms - 120ms这组数据有几个值得注意的点。直连成功率不是 100%说明 STUN 打洞确实有天然上限走 TURN 之后成功率上去了但延迟明显涨了一档。对 OmniGame 这类派对型小游戏来说只要不是每帧都必须 10ms 内同步的硬核格斗六七十毫秒的延迟完全能接受。如果你做的是对延迟更敏感的游戏设计时建议把“直连/中继”作为一个可观测指标对不同玩家群体调整匹配策略而不是一刀切。4.2 兼容性矩阵不同端怎么表现WebRTC 虽然已经是浏览器标准但各家的实现和默认行为还是有差异。我在 OmniGame 里做了一个兼容矩阵方便上线前自检。运行环境DataChannel 支持实测表现备注Chrome / Edge桌面完整最稳ICE 和 SCTP 表现优秀首选用 Chrome 调试Firefox桌面完整稳定个别老版本 SDP 协商有差异建议保持 Firefox 122Safari桌面 / iOS完整iOS 14.3 可用性大幅提升旧 WKWebView 要回避Android WebView / Chrome完整Android 高版本 WebView 表现良好部分国产内核需要实机验证iOS WKWebView 内嵌部分受限老版本对 WebRTC 支持不完整建议优先让用户跳 Safari踩过的坑里最典型的是 iOS 上的状况同样是 WebView系统版本不同WebRTC 的行为差异很大。为了不让用户体验“门都进不去”我在入口页面做了环境检测如果识别到旧的 WKWebView 环境就提示用户用系统浏览器打开而不是在一个不可控的容器里硬跑。这个妥协成本很低但能让用户流失率明显下降。4.3 从问题到答案常见故障速查表做完整套联机系统我整理了一份速查表按网上遇到的求助高频问题分类。这里直接分享出来基本覆盖了新手做 WebRTC 游戏联机时会碰到的九成问题。问题现象可能原因处理建议一直停在“连接中”通道不 openICE 协商没完成常见是 candidate 没交换检查信令日志确认两端都 addIceCandidate远端能收到 offer但我这边没有 candidateSTUN 服务器不可达或网络屏蔽 UDP换公共 STUN 地址确认 UDP 35000 可用直连偶尔成功偶尔失败对端 NAT 类型属于对称型打洞不稳定部署 TURN 作为兜底不要反复调 STUN消息偶发丢失顺序错乱走了不可靠通道但业务假设它是可靠通道检查消息类型和通道策略是否匹配画面卡顿但网络延迟不高数据量超过单通道吞吐或消息体积过大触发分片拆小消息、合并冗余增量、降低发送频率多人房间延迟逐渐变差网状拓扑带宽占用叠加或某端上行带宽受限控制房间人数考虑转星型结构并做转发onicecandidate 收到 null 后通道仍未开忽略了一个关键点收到 null 只代表本地候选发完不代表协商完成检查对方是否已 setRemoteDescription 并完成 addIceCandidate移动端断线频繁移动网络信号切换导致网络路径变化开启 ICE 重启实现自动重协商必要时退化为 TURN房间内某个人掉线所有人跟着卡星型拓扑中 Host 走到瓶颈改用网状拓扑或实现 Host 迁移速查表之外还有一个非常容易被忽略的细节onicecandidate 收到 null 的时候只代表本地收集结束并不代表整个 ICE 协商结束。很多新手在这里误判“连接完成”导致明明两边 SDP 都换完了candidate 却只发了一半。正确的做法是始终以 DataChannel 的 onopen 或 peerConnectionState 变为 connected 作为成功标志不要用“本地 candidate 收完了”来判断。5. 工程上限在哪哪些事该做哪些事要止步5.1 OmniGame 把上限推到哪一步做完整套方案后我对“重新定义网页小游戏的工程上限”这句话有了更具体的理解。这里说的上限不是“能做 3A 大作”而是把网页小游戏最核心的特性发挥到位极快加载、极低门槛、延迟可控的多人体验。零依赖重新定义了加载上限。一个 OmniGame 的单局玩法HTML 加 CSS 加 JS 全部加起来可以压到几十 KB意味着用户在 2G 网络下也能在几秒内开始玩。对比动辄几百 KB 起步的框架型项目这个差距直接决定了用户愿不愿意等。WebRTC P2P 重新定义了联机成本上限。传统服务器中转模型里一个房间的实时流量全部经过自己的服务器一百个房间就可能让带宽账单起飞。P2P 模式下数据流量全部在玩家之间流动服务器只承担建连瞬间的信令负载这是一笔非常明显的成本优化。这两个上限叠加起来OmniGame 可以做“复制链接发给朋友打开即玩自动进入同一房间”的完整体验。对派对类小游戏来说这个体验闭环比任何广告投放都有效因为传播路径短到几乎没有摩擦。5.2 不适合的场景与明确边界从工程师角度我不建议所有网页游戏都抄这套方案。OmniGame 能成功因为它精准匹配了 P2P 的优势区间。换一批需求这套架构就会裂开。第一类是 MMO 类型或大型多人在线。P2P 网状连接在 20 人以上就接近崩溃边缘50 人以上基本不可行这种场景必须由服务器进行区域管理和状态广播而不是让每个人跟所有人都建立连接。第二类是严肃竞技对抗比如竞技场射击、排位赛这类对防作弊有强要求的玩法服务器权威结算绕不开P2P 的“玩家直连”无法提供可信的胜负判定。第三类是超低延迟强同步类玩法我指那种要求逻辑帧严格统一的格斗、音游对战P2P 网络状况不受你控制抖动稍微大一点整个同步体验就崩了。所以我在架构文档里明确写了一句P2P 是工具不是信仰。OmniGame 用它是因为它适合其他项目要用先做容量评估和风险分析别因为“看起来很酷”就把不适合的架构硬套在玩法上。5.3 后续规划把网络层做成可复用资产做完 OmniGame 联机模块后我一直在想怎么让这套工程经验发挥更大价值。当前的方向是把 Network 层从项目里抽成独立的纯 ES Module 模块保持零依赖特性让其他想做网页联机小游戏的开发者可以直接 import 使用。模块会内置信令客户端、P2P 建连、DataChannel 可靠/不可靠通道管理、ICE 状态统计、Host 迁移等核心能力同时提供一个 debug 面板来查看当前各个通道的状态。另一个跟进方向是关注 WebTransport 这类更新的传输协议它跟 WebRTC 并不互斥反而能互补解决部分场景的中继和队头阻塞问题。但这不是为了追新而是为了在“网页小游戏联机”这个目标下让工具选择始终服务于体验上限。把 OmniGame 完整跑通之后我个人最有体感的经验是信令服务只是开门钥匙不是游戏的路。整个联机过程中最重的流量都在浏览器之间直接流动信令端只需处理秒级建连时的少量请求一台轻量服务器就够一百个房间同时建连使用成本压力几乎可以忽略。另一条经验是 TURN 服务器千万别急着部署先通过日志统计直连成功率很多项目实际直连率在七成以上为剩下三成用户直接买带宽总觉得亏得慌。OmniGame 的下一步是把这套 Transport 层整理成一份可以直接 import 的零依赖 ES Module让其他想做网页联机小游戏的人不用再把 WebRTC 的坑重新踩一遍把精力花在游戏机制和体验上。这次从零依赖到 P2P 的完整走位也让我重新理解了网页小游戏该有的工程形态轻到极致快得自然玩法本身才是最有分量的东西。