online · WebRTC P2P

联机对战：无后端的 P2P 实现

playground 是纯静态站点、没有后端，联机却仍然可行：用 WebRTC 在两个浏览器之间直接建立一条 RTCDataChannel，落子就通过这条点对点通道传输。唯一的难点是建连接前两端要先交换一段连接描述，即信令 (signaling)。本页把这一步换成手动复制粘贴一段编码——于是连信令服务器都不需要。

1 · 三种联机架构

表 1-1 · 三者的数据通道只有两种：经服务器中转，或浏览器点对点。区别主要在信令怎么交换。
方案	数据怎么走	要不要后端	取舍
WebSocket + 权威服务器	两端都连服务器，由它中转、托管对局状态	要（持续运行）	最稳定、天然穿透 NAT、好做防作弊；但要自建并运维后端。绝大多数在线对战这么做。
WebRTC P2P + 信令服务器	浏览器直连传数据；服务器只用来交换信令	要一个轻量信令服务 (+ STUN / TURN)	延迟低、省服务器带宽；信令服务很小，但 NAT 受限时仍需 TURN 中继兜底。
WebRTC P2P + 手动信令 ← 本页	浏览器直连；信令那一步改成手动复制粘贴	零后端	真正无服务器，适合 demo 与小范围对局；代价是建连需手动交换一次，且无 TURN 时对称 NAT 可能连不上。

建议 · 连接流程分四步：主持方点「创建邀请码」生成一段 offer 编码，把它发给对方（任意渠道均可），对方粘贴后生成 answer 编码发回来，主持方粘贴并完成连接。通道一开，落子就直接在两个浏览器间点对点传。本机自测的办法是把本页开成两个标签页，一个当主持、一个当加入，在两个标签间互相复制那两段码。

图 1-2 · 手动信令的对战盘。可开两个标签页互传 offer 与 answer 编码，连通后即可对下。

警示 · 本页只配了公共 STUN（帮双方发现自己的公网地址），没有 TURN 中继。当两端处在对称型 NAT（部分公司与校园网）后面时，纯 STUN 打洞会失败——生产环境通常再加一台 TURN 服务器兜底，那就又回到「需要一点后端」了。同一局域网或多数家庭网络下，手动信令的纯 STUN 方案可直接连通。