0 Fork 0

Files

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	⛔ 「平台已有 / 已存在」未被核实前不得作安全假设	本档 §二自检要求

三、范围

改什么：⏳ 未开跑。本档为补遗 + 参考方案 + 反模式，不含实施。
不动什么：⛔ 不重复各档案已有内容（见 §四表格）；⛔ 本轮不动服务器、不改代码。
统一记录格式（本档所有补遗项按此）：分类 / 结论 / 依据 / 待验证点 / 若做需要什么。

四、决策点

已定

互联游戏 ✅ 支持，但由游戏形态决定：回合制/卡牌/桌游/异步 ✅非常合适；小规模实时合作（≤8–16 人）✅合适；大厅在服务器 + 对局 P2P ✅经典；大规模强实时竞技（FPS/MOBA 64+）❌不合适（需专用服务端 + 中继多一跳 + P2P 无法反作弊）。
给覆盖网络的第一建议：优先做「只传输入」的锁步/回合制（带宽可忽略、延迟容忍度高）；实时动作类必须限定在同区域。
⛔ P2P 无法防作弊 ⇒ 凡有竞技性就必须服务端权威（好消息：有公网 IP 的节点天然可当对局主机/专用服务端 —— 与骨干层天然衔接）。
⭐ 复用「房间」抽象：群聊房间与游戏对局是同一个模型（成员/可见性/事件分发/离线补拉）⇒ 一次投资四处共用。
落地优先级（补遗之后按依赖排）：① 房间层 ② 身份与密钥 ③ 会合/中继拆成独立组件（老结论，仍是第一件实事）④ IPv6 优先 + 上线自检 + 路径决策日志 ⑤ 配额与优先级队列 ⑥ 备份改造 ⑦ 游戏（锁步/回合制先行）。
反模式 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 游戏特有的风暴点（比聊天更危险）

状态广播放大：每帧每人发给全体 = 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。 ⭐ 该专稿的核心简化：这类游戏玩家之间不需要互联（服务端权威，玩家只与游戏服通信）⇒ 覆盖网络只需解决"让玩家到达游戏服"，中继容量按"服数"算、不按"玩家数"算。
输入风暴：锁步必须限帧率 + 合并输入，不能"每动一下发一条"。
主机切换惊群：房主掉线时全员抢当主机 ⇒ 必须确定性继任顺序 + 退避（不能"谁先喊谁当"）。
匹配/大厅风暴：开房高峰的列表刷新 ⇒ 列表走带 TTL 的拉取，不做推送。

1.4 反作弊（决定架构，不是可选）

P2P 无法防作弊 ⇒ 只要游戏有竞技性，就必须 服务端权威。好消息：覆盖网络里"有公网 IP 的节点"天然可当对局主机/专用服务端 —— 与骨干层设计天然衔接。

1.5 技术选型与复用点

传输：WebRTC DataChannel 的"不可靠 + 无序"模式（类 UDP，适合状态流）；或直接用覆盖网络的 UDP 隧道。WebRTC 自带 ICE（打洞）+ TURN（中继）兜底，与我们的中继设计同构。
⭐ 可复用"房间"抽象：群聊房间与游戏对局是同一个模型 —— 成员 / 可见性 / 事件分发 / 离线补拉。一旦建了房间层，群聊、游戏、协作编辑、看板共用一次投资。这是本方案最划算的一处架构复用。

二、补遗清单（按主题；凡前面没写到的都在这）

2.1 身份与账户（最容易被漏，且漏了会出运维灾难）

多设备同账号：一个用户多台设备如何归属同一身份；设备加入/移除流程。
密钥丢失的重建路径 ⚠️：私钥丢 = 设备永久失去身份。必须有恢复机制（恢复码 / 管理员重签 / 设备转让），且要能撤销被盗设备。
密钥存放：用系统密钥库（Windows DPAPI / macOS Keychain / Linux TPM），不要明文落盘。
账户与设备的绑定粒度：设备级身份 + 用户级授权（两层），避免"一台设备泄露 = 整个账号沦陷"。

2.2 寻址与名字（没有它，用户只能记 IP）

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

2.3 接入与可见性

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

2.4 自检与选路

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

2.5 流量与公平

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

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

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

2.7 升级、版本与自愈

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

2.8 可观测

集中指标 + 每节点画像（路径类型 / 打洞率 / 时延 / 重连次数）。
可 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 直达红利

五、落地优先级（补遗之后，按"依赖"排）

房间层（一次投资，群聊 + 游戏 + 协作 + 看板共用）。
身份与密钥（一机一钥 + 恢复机制 + 吊销）—— 大量能力的共同前置。
会合 / 中继拆成独立组件（老结论，仍是第一件实事）。
IPv6 优先 + 上线自检 + 路径决策日志（低成本高收益）。
配额与优先级队列（交互优先，备份让路）。
备份改造（去重 + 客户端加密 + 对象存储主层）。
游戏（锁步/回合制先行，服务端权威留给竞技类）。

六、未验证项

#	项	状态
1	本环境 IPv6 可用度（决定能否吃到"直达"红利）	⚠️ 未实测
2	移动端休眠唤醒后的实际重连耗时	⚠️ 未实测
3	WebRTC DataChannel 经我们中继的延迟与丢包表现	⚠️ 未实测
4	FEC / 多路径的实际收益	📋 待评估

17 KiB Raw Blame History Unescape Escape