admin/dsh_ai1net_server
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
dsh_ai1net_server/docs/覆盖网络/覆盖网络_补遗与参考方案_20260916.md
T
admin ce8e6ceed9 chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物） 
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
2026-09-24 07:51:03 +08:00

11 KiB
Raw Permalink Blame History

覆盖网络 · 补遗与参考方案（含「互联游戏」可行性）

日期：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