250 lines
17 KiB
Markdown
250 lines
17 KiB
Markdown
|
# 111 · 覆盖网络 · 补遗与参考方案
|
|||
|
|
- 日期：2026-09-16 ｜ 状态：📋 **规划态**（补遗复盘稿；未实施）
|
|||
|
|
- 来源：工作区根 `覆盖网络_补遗与参考方案_20260916.md`（正文见 附录 A）
|
|||
|
|
- 层级：专项补遗｜ 承接档案 104 · 110；被 108（游戏判定修正）引用
|
|||
|
|
- 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。
|
|||
|
|
|
|||
|
|
> **TL;DR**
|
|||
|
|
> 四部分：① **互联游戏可行性**（✅ 支持，但**由游戏形态决定**；优先做「**只传输入**」的锁步/回合制）；
|
|||
|
|
> ② **补遗 24 条**（身份与账户 / 寻址与名字 / 接入与可见性 / 自检与选路 / 流量与公平 / 移动端弱网 / 升级版本自愈 / 可观测）；
|
|||
|
|
> ③ **参考方案对照**（10 个能力域的现成物，**别自研**）；④ **反模式 12 条**（踩了就出事，逐条对照）。
|
|||
|
|
> ⭐ 最划算的一处架构复用：**群聊房间与游戏对局是同一个模型** ⇒ 一次建房间层，群聊 + 游戏 + 协作 + 看板共用。
|
|||
|
|
|
|||
|
|
## 一、目标
|
|||
|
|
|
|||
|
|
补齐前面各档案未覆盖的项（24 条）+ 给出可借鉴的现成物清单 + 反模式清单，并回答「互联游戏是否可行」。
|
|||
|
|
可判定「做完了没有」＝ 四部分齐备，且**补遗 24 条每条都能落到一个能力域**。
|
|||
|
|
|
|||
|
|
## 二、只读前置
|
|||
|
|
|
|||
|
|
| # | 事实 | 核对方式（期望输出） |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | 各档案已有明确分工（见 §三 表格「已有明确分工」） | 档案 104 §1–§5（五层 / 12 特性 / 流量）· §四（风暴）· §五（流量组织） |
|
|||
|
|
| 2 | ⚠️ 各档案**已有明确分工**，本档只补缺 | 逐条比对 104 / 105 / 106 / 107 / 108 / 109 / 110 |
|
|||
|
|
| 3 | 平台已有域名 `alotbuy.com` ⇒ 可做子域解析（MagicDNS 式） | 读 `01-规划与架构.md` 域名接入 |
|
|||
|
|
| 4 | 各档案**均有未验证项清单**（本档不重复） | 档案 104 §九 · 106 §九 · 107 §六 · 109 第三部分 |
|
|||
|
|
| 5 | ⛔ 「平台已有 / 已存在」**未被核实前不得作安全假设** | 本档 §二 自检要求 |
|
|||
|
|
|
|||
|
|
## 三、范围
|
|||
|
|
|
|||
|
|
- **改什么**：⏳ 未开跑。本档为**补遗 + 参考方案 + 反模式**，不含实施。
|
|||
|
|
- **不动什么**：⛔ 不重复各档案已有内容（见 §四 表格）；⛔ 本轮不动服务器、不改代码。
|
|||
|
|
- **统一记录格式**（本档所有补遗项按此）：**分类 / 结论 / 依据 / 待验证点 / 若做需要什么**。
|
|||
|
|
|
|||
|
|
## 四、决策点
|
|||
|
|
|
|||
|
|
**已定**
|
|||
|
|
|
|||
|
|
1. **互联游戏 ✅ 支持，但由游戏形态决定**：回合制/卡牌/桌游/异步 ✅非常合适；小规模实时合作（≤8–16 人）✅合适；大厅在服务器 + 对局 P2P ✅经典；**大规模强实时竞技（FPS/MOBA 64+）❌不合适**（需专用服务端 + 中继多一跳 + P2P 无法反作弊）。
|
|||
|
|
2. **给覆盖网络的第一建议：优先做「只传输入」的锁步/回合制**（带宽可忽略、延迟容忍度高）；实时动作类必须限定在同区域。
|
|||
|
|
3. **⛔ P2P 无法防作弊** ⇒ 凡有竞技性就必须**服务端权威**（好消息：有公网 IP 的节点天然可当对局主机/专用服务端 —— 与骨干层天然衔接）。
|
|||
|
|
4. **⭐ 复用「房间」抽象**：群聊房间与游戏对局是**同一个模型**（成员/可见性/事件分发/离线补拉）⇒ 一次投资四处共用。
|
|||
|
|
5. **落地优先级（补遗之后按依赖排）**：① 房间层 ② 身份与密钥 ③ **会合/中继拆成独立组件**（老结论，仍是第一件实事）④ IPv6 优先 + 上线自检 + 路径决策日志 ⑤ 配额与优先级队列 ⑥ 备份改造 ⑦ 游戏（锁步/回合制先行）。
|
|||
|
|
6. **反模式 12 条为硬拦项**：建全互联 · 无扇出限制的 gossip · 客户端持有权威状态 · 控制面下发全网名单 · 单中心中继当唯一通道 · 网内副本当主备份 · 用慢链路做备份/迁移 · 失败即重试 · agent 直接触发 agent · 推送式分发 · 共享密钥当节点身份 · 只按 IPv4 NAT 设计。
|
|||
|
|
|
|||
|
|
**未定**：本环境 IPv6 可用度（决定能否吃到「直达」红利，**未实测**）。
|
|||
|
|
|
|||
|
|
## 五、步骤
|
|||
|
|
|
|||
|
|
**本档为补遗，实施步骤已被下列档案承担**：
|
|||
|
|
- 房间层 → **档案 108 §五 第 2 步**（组队/行会/频道）
|
|||
|
|
- 身份与密钥 → **档案 112 §9**（协议治理同批）与 **110 §D**（一机一钥）
|
|||
|
|
- 会合/中继拆组件 → **档案 105 §五 第 1 步**（本线第一件实事，见 `接续入口 §2.5`）
|
|||
|
|
- IPv6 / 上线自检 / 决策日志 → **档案 109 §1.4**（数值依据）与 **112 §4**（jitter 选路）
|
|||
|
|
- 配额与优先级队列 → **档案 112 §5**（备份抖动窗口 + 低优先级队列）
|
|||
|
|
- 备份改造 → **档案 110 §B**
|
|||
|
|
- 游戏 → **档案 108 §五**（锁步/回合制先行）
|
|||
|
|
|
|||
|
|
## 六、验收
|
|||
|
|
|
|||
|
|
| # | 口径 | 期望 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| A | 补遗 24 条 | 每条有归属能力域，且**不与既有档案重复** |
|
|||
|
|
| B | 参考方案对照 | 10 个能力域各给出可借鉴的现成物与「借什么」 |
|
|||
|
|
| C | 反模式 12 条 | 逐条可对照，且**每条都指向一个具体后果** |
|
|||
|
|
| D | 落地优先级 | 7 条按**依赖**排（不是按收益） |
|
|||
|
|
| E | 未验证项透明 | §六 四条已列全 |
|
|||
|
|
|
|||
|
|
## 七、回滚
|
|||
|
|
|
|||
|
|
- **本档自身**：零改动 ⇒ 无回滚需要。
|
|||
|
|
- **执行期**：所引用的各档案步骤各自独立可回滚；⛔ **「客户端持有权威状态」不可回滚**（红线，见 §四 第 3 条）。
|
|||
|
|
|
|||
|
|
## 八、回报格式
|
|||
|
|
|
|||
|
|
执行会话回填：① 补遗 24 条中实际被采纳的条数与落点 ② 参考方案的选用结果（谁被选中、为什么） ③ 反模式自查结果（逐条对照，命中项与处置） ④ commit ⑤ 未完成项与卡点。
|
|||
|
|
|
|||
|
|
## 九、未验证项（勿当结论）
|
|||
|
|
|
|||
|
|
本环境 IPv6 可用度（决定能否吃到「直达」红利，**未实测**）｜移动端休眠唤醒后的实际重连耗时（**未实测**）｜WebRTC DataChannel 经我们中继的延迟与丢包表现（**未实测**）｜FEC / 多路径的实际收益（**待评估**）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 附录 A · 原始规划正文（逐字保留 · 2026-09-16）
|
|||
|
|
|
|||
|
|
> 以下为工作区根 `覆盖网络_补遗与参考方案_20260916.md` 的**原文全文**，仅删除其一级标题（避免与档案标题重复），
|
|||
|
|
> 其余**一字未改**；本档的可判定部分以上方 8 段为准。
|
|||
|
|
|
|||
|
|
> 日期：2026-09-16 ｜ 性质：**补遗复盘**（承接 `覆盖网络_全球架构复盘_20260916.md` 与 `覆盖网络_答疑_群聊备份迁移保密_20260916.md`）
|
|||
|
|
> 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 一、互联游戏：✅ 支持，但**由游戏形态决定**
|
|||
|
|
|
|||
|
|
覆盖网络对游戏是"够用"的底座，**但它是所有应用场景里最"重"的一个** —— 实时性、状态一致性、反作弊三条同时压上来。所以先分类：
|
|||
|
|
|
|||
|
|
| 游戏类型 | 覆盖网络可行性 | 关键约束 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 回合制 / 卡牌 / 桌游 / 异步 | ✅ **非常合适** | 带宽极小（只传输入），延迟不敏感 |
|
|||
|
|
| 小规模实时合作（≤8–16 人） | ✅ 合适 | 需要主机或专用服务端之一 |
|
|||
|
|
| 大厅在服务器 + 对局 P2P | ✅ 经典架构 | 匹配/排行在中心，对局在 P2P |
|
|||
|
|
| 大规模强实时竞技（FPS/MOBA 64+） | ❌ **不合适** | 需专用服务端 + 权威模拟；中继多一跳；P2P 无法反作弊 |
|
|||
|
|
| 需要严格反作弊的竞技类 | ❌ **P2P 的致命伤** | **客户端持有权威状态 = 可作弊**，必须服务端权威 |
|
|||
|
|
|
|||
|
|
### 1.1 三种同步模型（带宽与延迟特性完全不同）
|
|||
|
|
|
|||
|
|
| 模型 | 传什么 | 带宽 | 适合 |
|
|||
|
|
|---|---|---|---|
|
|||
|
|
| **状态同步** | 定期广播状态快照 + 客户端插值 | 高（随人数上升） | 动作类、小规模 |
|
|||
|
|
| **锁步 / 帧同步** | **只传输入（命令）** | **极低** | RTS、回合、卡牌 —— **对覆盖网络最友好** |
|
|||
|
|
| **回滚码（GGPO 式）** | 输入 + 确定性模拟 + 预测回滚 | 低但要求严格 | 格斗类；**对延迟最敏感，跨洲不可行** |
|
|||
|
|
|
|||
|
|
⇒ **给覆盖网络的第一建议：优先做"只传输入"的锁步/回合制**，带宽可忽略、延迟容忍度高；实时动作类必须限定在同区域。
|
|||
|
|
|
|||
|
|
### 1.2 延迟预算（决定哪些能玩）
|
|||
|
|
|
|||
|
|
| 路径 | 典型 RTT | 可承载 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 同区域直连 | 5–30 ms | 几乎任何类型 |
|
|||
|
|
| **经中继（多一跳）** | +RTT×2 | 回合/锁步仍可；动作类吃力 |
|
|||
|
|
| 跨洲 | ~200 ms | **只适合回合制/异步** |
|
|||
|
|
|
|||
|
|
### 1.3 游戏特有的风暴点（比聊天更危险）
|
|||
|
|
|
|||
|
|
1. **状态广播放大**：每帧每人发给全体 = O(N²) ⇒ 必须**主机聚合后再分发**，或按**兴趣区域（AOI）裁剪**。
|
|||
|
|
> 📄 **重点修正（2026-09-16 10:0x）**：用户明确游戏重点是 **MMORPG（2D/2.5D）· MUD · 传奇类** —— 这三类是**覆盖网络最匹配的应用**（天生服务端权威 + tick 驱动 + **AOI 九宫格广播** + 分区/分线扩展，每玩家仅数 KB/s~数十 KB/s，几百 ms 延迟无感）。本节上面那张"❌ 不合适"的表**只适用于 3D 大世界强实时竞技**。游戏专项见 **`覆盖网络_游戏专项_MMORPG与MUD_20260916.md`**。
|
|||
|
|
⭐ 该专稿的核心简化：**这类游戏玩家之间不需要互联**（服务端权威，玩家只与游戏服通信）⇒ 覆盖网络只需解决"**让玩家到达游戏服**"，**中继容量按"服数"算、不按"玩家数"算**。
|
|||
|
|
2. **输入风暴**：锁步必须限帧率 + 合并输入，不能"每动一下发一条"。
|
|||
|
|
3. **主机切换惊群**：房主掉线时全员抢当主机 ⇒ **必须确定性继任顺序 + 退避**（不能"谁先喊谁当"）。
|
|||
|
|
4. **匹配/大厅风暴**：开房高峰的列表刷新 ⇒ 列表走**带 TTL 的拉取**，不做推送。
|
|||
|
|
|
|||
|
|
### 1.4 反作弊（决定架构，不是可选）
|
|||
|
|
|
|||
|
|
**P2P 无法防作弊** ⇒ 只要游戏有竞技性，就必须 **服务端权威**。好消息：覆盖网络里"**有公网 IP 的节点**"天然可当对局主机/专用服务端 —— 与骨干层设计天然衔接。
|
|||
|
|
|
|||
|
|
### 1.5 技术选型与复用点
|
|||
|
|
|
|||
|
|
- 传输：**WebRTC DataChannel 的"不可靠 + 无序"模式**（类 UDP，适合状态流）；或直接用覆盖网络的 UDP 隧道。WebRTC 自带 ICE（打洞）+ TURN（中继）兜底，与我们的中继设计同构。
|
|||
|
|
- ⭐ **可复用"房间"抽象**：**群聊房间与游戏对局是同一个模型** —— 成员 / 可见性 / 事件分发 / 离线补拉。一旦建了房间层，**群聊、游戏、协作编辑、看板共用一次投资**。这是本方案最划算的一处架构复用。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 二、补遗清单（按主题；凡前面没写到的都在这）
|
|||
|
|
|
|||
|
|
### 2.1 身份与账户（**最容易被漏，且漏了会出运维灾难**）
|
|||
|
|
|
|||
|
|
1. **多设备同账号**：一个用户多台设备如何归属同一身份；设备加入/移除流程。
|
|||
|
|
2. **密钥丢失的重建路径** ⚠️：私钥丢 = 设备永久失去身份。必须有**恢复机制**（恢复码 / 管理员重签 / 设备转让），且要能撤销被盗设备。
|
|||
|
|
3. **密钥存放**：用系统密钥库（Windows DPAPI / macOS Keychain / Linux TPM），不要明文落盘。
|
|||
|
|
4. **账户与设备的绑定粒度**：设备级身份 + 用户级授权（两层），避免"一台设备泄露 = 整个账号沦陷"。
|
|||
|
|
|
|||
|
|
### 2.2 寻址与名字（没有它，用户只能记 IP）
|
|||
|
|
|
|||
|
|
5. **稳定名字解析**（MagicDNS 式）：`<设备>.<用户>.<域名>`；平台已有 `alotbuy.com`，可直接做子域解析。
|
|||
|
|
6. **IPv6 优先** ⚠️ **重要且常被忽略**：不少网络有 IPv6 直达能力 ⇒ **可跳过打洞直接连**。别只按 IPv4 NAT 设计，否则白丢一大块性能红利。
|
|||
|
|
|
|||
|
|
### 2.3 接入与可见性
|
|||
|
|
|
|||
|
|
7. **出口节点 / 子网路由**：把某台机器背后的**整个局域网**借进覆盖网络（访问家里的 NAS、打印机）—— 对"一个人的多设备"场景是关键能力。
|
|||
|
|
8. **服务暴露**：把实例或某端口按**网内可见 / 公网可见**两档暴露（对应 Serve / Funnel 的区分）。
|
|||
|
|
9. **ACL 的具体形态**：粒度（用户 / 设备 / 服务 / 端口 / 时间）、表达方式（策略语言）、下发与缓存、**默认拒绝**。
|
|||
|
|
|
|||
|
|
### 2.4 自检与选路
|
|||
|
|
|
|||
|
|
10. **上线自检**（netcheck 式）：探测 UDP 是否被封、NAT 类型、到各区域中继的时延 ⇒ 再决定选路。
|
|||
|
|
11. **路径决策可解释**：每次连接"为什么走了中继"要能查出原因（打洞失败？UDP 被封？策略强制？）—— 排障只能靠这个。
|
|||
|
|
12. **节点健康自评**：打洞率 / 丢包 / 时延 → 主动换路径或换骨干。
|
|||
|
|
|
|||
|
|
### 2.5 流量与公平
|
|||
|
|
|
|||
|
|
13. **按用户/设备配额**（带宽与连接数），防单点占满。
|
|||
|
|
14. **交互流量优先于后台流量**：备份/同步这类用**低优先级队列**（fq_codel / LEDBAT 类），保证聊天与游戏不被备份堵死。
|
|||
|
|
15. **多路径**：直连 + 中继同时传，聚合吞吐（大文件迁移用）。
|
|||
|
|
16. **前向纠错（FEC）**：丢包高的移动网，FEC 比"重传"便宜得多。
|
|||
|
|
|
|||
|
|
### 2.6 移动端与弱网（独立一章，坑最多）
|
|||
|
|
|
|||
|
|
17. **电量**：心跳频率要能与电量/前台状态联动（后台降频）。
|
|||
|
|
18. **系统休眠/冻结**：唤醒后必须**秒级重连**，不能等下一个心跳周期。
|
|||
|
|
19. **网络切换**：Wi-Fi ↔ 蜂窝切换会换 IP ⇒ 需**连接迁移**（QUIC 的 connection migration 就是为这个设计的）。
|
|||
|
|
|
|||
|
|
### 2.7 升级、版本与自愈
|
|||
|
|
|
|||
|
|
20. **协议版本协商**：客户端与平台必须能协商协议版本，**严格递增防降级**。
|
|||
|
|
21. **灰度与回滚**：按节点分批升级，出问题能退回上一版。
|
|||
|
|
22. **更新包签名校验**（防投毒）。
|
|||
|
|
|
|||
|
|
### 2.8 可观测
|
|||
|
|
|
|||
|
|
23. **集中指标 + 每节点画像**（路径类型 / 打洞率 / 时延 / 重连次数）。
|
|||
|
|
24. **可 grep 的决策日志**（"为什么走中继"）—— 与 12 配套。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 三、参考方案对照（可直接借鉴的现成物）
|
|||
|
|
|
|||
|
|
| 能力域 | 参考方案 | 借什么 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 组网 / 打洞 / 中继 | **Tailscale / headscale + derper**、NetBird、Nebula、ZeroTier、EasyTier、innernet | 控制面/数据面分离；先中继后直连；限额中继；区域 DERP |
|
|||
|
|
| 打洞 / 中继库 | **libp2p**（DCUtR + relay v2）、**Pion**（Go WebRTC）、**coturn** | 直接可用的协议实现与默认限流参数 |
|
|||
|
|
| 游戏网络 | **GGPO / 回滚码**、**Nakama**（开源游戏后端）、Colyseus、Photon、**WebRTC DataChannel** | 房间/匹配/状态同步的现成模型；不可靠传输 |
|
|||
|
|
| 联机传输库 | enet / KCP / QUIC | 类 UDP 的低延迟可靠传输 |
|
|||
|
|
| 协作编辑 / CRDT | **Yjs**、Automerge | 无中心也一致的协作模型（适合 P2P 房间） |
|
|||
|
|
| 群聊 / 联邦房间 | **Matrix**（联邦式房间，理念与覆盖网络最接近）、Nostr、Scuttlebutt | 房间、事件图、离线补拉、联邦 |
|
|||
|
|
| 备份 | **restic / Borg**（增量 + 去重 + 加密）、**rclone**（多后端 + 加密）、MinIO | **与我们结论一致**：去重 + 客户端加密 + 不可变 |
|
|||
|
|
| 迁移 | rsync（块级增量）、rclone、对象存储中转 | 断点续传与增量 |
|
|||
|
|
| 观测 | Prometheus + Grafana（libp2p 有现成面板）、集中日志 | 直接抄面板 |
|
|||
|
|
| 全球就近 | GeoDNS（PowerDNS / Route53）、anycast、DERP 的区域模型 | 就近接入 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 四、反模式清单（踩了就出事，逐条对照）
|
|||
|
|
|
|||
|
|
| # | 反模式 | 后果 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | **建全互联**（N² 保活） | 保活与连接数爆炸 |
|
|||
|
|
| 2 | **无扇出限制的 gossip / 广播** | 泛洪风暴 |
|
|||
|
|
| 3 | **客户端持有权威状态** | 可作弊、可伪造归属 |
|
|||
|
|
| 4 | **控制面下发全网名单** | 元数据全暴露 + 每条连接都要维护 |
|
|||
|
|
| 5 | **单中心中继当唯一通道** | 单点 + 带宽瓶颈 |
|
|||
|
|
| 6 | **把网内副本当主备份** | 无 SLA、可误删、对端离线即失效 |
|
|||
|
|
| 7 | **用慢链路做备份/迁移通道** | 22 KB/s 量级 ⇒ 不可用 |
|
|||
|
|
| 8 | **失败即重试（无退避/抖动）** | 重试风暴 |
|
|||
|
|
| 9 | **agent 直接触发 agent** | 无限循环消息风暴 |
|
|||
|
|
| 10 | **推送式分发（版本/目录/大资源）** | 冷启动拉取风暴 |
|
|||
|
|
| 11 | **共享密钥当节点身份** | 无法吊销、一泄全通 |
|
|||
|
|
| 12 | **只按 IPv4 NAT 设计** | 白丢 IPv6 直达红利 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 五、落地优先级（补遗之后，按"依赖"排）
|
|||
|
|
|
|||
|
|
1. **房间层**（一次投资，群聊 + 游戏 + 协作 + 看板共用）。
|
|||
|
|
2. **身份与密钥**（一机一钥 + 恢复机制 + 吊销）—— 大量能力的共同前置。
|
|||
|
|
3. **会合 / 中继拆成独立组件**（老结论，仍是第一件实事）。
|
|||
|
|
4. **IPv6 优先 + 上线自检 + 路径决策日志**（低成本高收益）。
|
|||
|
|
5. **配额与优先级队列**（交互优先，备份让路）。
|
|||
|
|
6. 备份改造（去重 + 客户端加密 + 对象存储主层）。
|
|||
|
|
7. 游戏（锁步/回合制先行，服务端权威留给竞技类）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六、未验证项
|
|||
|
|
|
|||
|
|
| # | 项 | 状态 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 1 | 本环境 IPv6 可用度（决定能否吃到"直达"红利） | ⚠️ 未实测 |
|
|||
|
|
| 2 | 移动端休眠唤醒后的实际重连耗时 | ⚠️ 未实测 |
|
|||
|
|
| 3 | WebRTC DataChannel 经我们中继的延迟与丢包表现 | ⚠️ 未实测 |
|
|||
|
|
| 4 | FEC / 多路径的实际收益 | 📋 待评估 |
|