admin/dsh_shenxian
1
0 Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
09ce76f3af9fa6211ec6931c65e5302fda911ecd
dsh_shenxian/dsh-server-docs/04-调整方案/111-覆盖网络-补遗与参考方案.md
T
admin 4e3a1a4a13 docs(overlay): 覆盖网络/客户端化 10 份规划转正式档案 103-112 + 登记 
- 新增 04-调整方案/103-112：可行性评估 · 全球架构复盘 · 骨干层方案 ·
  百台推演 v2 · 千台全场景推演 · 游戏专项 · 游戏网络与群聊上限调研 ·
  答疑(群聊/备份/迁移/保密) · 补遗与参考方案 · 九大瓶颈落地方案
- 每份按 交接单/README.md §二 8 段改写（目标/只读前置/范围/决策点/
  步骤/验收/回滚/回报格式）+ 头部状态标注（📋 规划态 · 未实施）
- 技术内容不变：附录 A 逐字保留原文全文（仅去其一级标题），已逐份校验字节一致
- 登记：INDEX.md §二 +10 行、03-路线图与待办.md §二 +1 行
- 收尾：docs-audit.py 退出码 0（无 P0）· docs-manifest.py 已刷新
- 本轮零代码、零服务器改动；⛔ 未 push
- 占号：103-112（先原子 mkdir .lock-<NN> 再写）
2026-09-16 10:25:09 +08:00

17 KiB
Raw Blame History

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）

  1. 稳定名字解析（MagicDNS 式）：<设备>.<用户>.<域名>；平台已有 alotbuy.com，可直接做子域解析。
  2. IPv6 优先 ⚠️ 重要且常被忽略：不少网络有 IPv6 直达能力 ⇒ 可跳过打洞直接连。别只按 IPv4 NAT 设计，否则白丢一大块性能红利。

2.3 接入与可见性

  1. 出口节点 / 子网路由：把某台机器背后的整个局域网借进覆盖网络（访问家里的 NAS、打印机）—— 对"一个人的多设备"场景是关键能力。
  2. 服务暴露：把实例或某端口按网内可见 / 公网可见两档暴露（对应 Serve / Funnel 的区分）。
  3. ACL 的具体形态：粒度（用户 / 设备 / 服务 / 端口 / 时间）、表达方式（策略语言）、下发与缓存、默认拒绝。

2.4 自检与选路

  1. 上线自检（netcheck 式）：探测 UDP 是否被封、NAT 类型、到各区域中继的时延 ⇒ 再决定选路。
  2. 路径决策可解释：每次连接"为什么走了中继"要能查出原因（打洞失败？UDP 被封？策略强制？）—— 排障只能靠这个。
  3. 节点健康自评：打洞率 / 丢包 / 时延 → 主动换路径或换骨干。

2.5 流量与公平

  1. 按用户/设备配额（带宽与连接数），防单点占满。
  2. 交互流量优先于后台流量：备份/同步这类用低优先级队列（fq_codel / LEDBAT 类），保证聊天与游戏不被备份堵死。
  3. 多路径：直连 + 中继同时传，聚合吞吐（大文件迁移用）。
  4. 前向纠错（FEC）：丢包高的移动网，FEC 比"重传"便宜得多。

2.6 移动端与弱网（独立一章，坑最多）

  1. 电量：心跳频率要能与电量/前台状态联动（后台降频）。
  2. 系统休眠/冻结：唤醒后必须秒级重连，不能等下一个心跳周期。
  3. 网络切换：Wi-Fi ↔ 蜂窝切换会换 IP ⇒ 需连接迁移（QUIC 的 connection migration 就是为这个设计的）。

2.7 升级、版本与自愈

  1. 协议版本协商：客户端与平台必须能协商协议版本，严格递增防降级。
  2. 灰度与回滚：按节点分批升级，出问题能退回上一版。
  3. 更新包签名校验（防投毒）。

2.8 可观测

  1. 集中指标 + 每节点画像（路径类型 / 打洞率 / 时延 / 重连次数）。
  2. 可 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 / 多路径的实际收益 📋 待评估
Reference in new issue View Git Blame Copy Permalink