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

14 KiB

Raw Blame History

110 · 覆盖网络 · 答疑-群聊备份迁移保密

日期：2026-09-16 ｜状态：📋 规划态（技术答疑稿；未实施）
来源：工作区根 覆盖网络_答疑_群聊备份迁移保密_20260916.md（正文见附录 A）
层级：专项答疑（四问）｜承接档案 104；被 108（房间层）· 111 · 112（备份/保密）引用
🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

TL;DR 四问四答：① 群聊 + agent 入群 = ✅ 可实现（群聊是应用层的事，覆盖网络只解决「可达」）；② 备份 = 主备份优先对象存储，覆盖网络只当搬运通道与第三副本（P2P 副本无 SLA、可误删，不适合当存档）；③ 迁移提速 = 按收益 7 条， 最大那一招是「不搬可重建的」（46.3 MB vs 2.9 GiB ⇒ 约 64×）；④ 保密 = 三层加密 + 元数据保护，当前最大缺口是身份（共享令牌 → 一机一钥）。

一、目标

回答四个具体问题（群聊与 agent 参与 / 服务器用户数据备份方案 / 迁移服务器速度优化 / 传输保密性），每问给出可执行做法与判据。可判定「做完了没有」＝四问各有明确结论 + 可落地手段 + 与现有平台的「现成度」判定。

二、只读前置

#	事实	核对方式（期望输出）
1	平台没有「房间」抽象（现在是「每用户一个实例 + 会话」）⇒ 群聊 = 新增能力	读平台现状 / 档案 108 §2.1
2	备份基础已有：`backup.sh` + cron + `/opt/dsh/backups/` + 恢复演练	读 `scripts/` 与 `02-运维手册.md`
3	不可再生 46.3 MB / 可重建 2.9 GiB	备份口径实测记录
4	47→106 直连实测 ~22 KB/s（46.3 MB 需 ~35 分钟）	跨云实测记录
5	节点身份现为共享 bearer（无法吊销单台）⇒ 保密层最大缺口	`src/worker/agent.ts` 头部自陈

三、范围

改什么：⏳ 未开跑。方案面 = 群聊房间层 + agent 成员类型 · 备份补「对象存储主层 + 只备不可再生」· 迁移补「多流并行 + 惰性迁移」· 身份换一机一钥 + E2EE。
不动什么：⛔ 官方 dsh 主程序（R2）｜⛔ 本轮不动服务器、不改代码。
明确不做：⛔ 不用那条慢链路（22 KB/s）当备份/迁移通道 —— 备份上传应走各自到公网/对象存储的路径。

四、决策点

已定

群聊 = 应用层的事，覆盖网络只提供「可达」，不提供「有序、去重、不丢」⇒ 群聊必须自带：消息 ID（内容寻址/哈希）· 因果/逻辑时钟 · 送达确认 + 离线补拉（拉取式）· 房间级权限。
✅ 用户选：备份主层用对象存储（自建 MinIO 或云 OSS/COS），覆盖网络只当搬运通道与第三副本。
只备不可再生数据（+ 附一份重建清单）⇒ 体积降一个数量级。
上传前先加密（服务端/对象存储不持有明文）；校验和 + 版本化 + 防误删；恢复演练自动化。
传输保密 = 三层加密 + 元数据保护，一句话判据：中继只能看到密文与元数据，控制面只能看到密文与身份 —— 任何一条不满足即视为不合格。
agent 四条硬约束：⛔ 禁止 agent 直接触发 agent（只有人的消息能触发）· 每轮发言预算 · 静默期 · 房间级全局速率上限 + 排队。

未定：群聊/agent 的具体成员类型与发言预算参数（M / N / 房间上限，需压测标定）。

五、步骤（每条自带一次验证）

A · 群聊与 agent

选分发拓扑（推荐混合：小群网状 / 大群区域汇聚 / 离线补拉）→ 验证：大群禁止「每人每条广播给全体」。
群聊自带四项（消息 ID / 逻辑时钟 / 送达确认 + 补拉 / 房间权限）→ 验证：去重与乱序场景可正确收敛。
agent 作为独立对等成员（有自己的密钥与地址，身份绑定主人、权限可单独授）→ 验证：agent 四条硬约束在压测下生效。

B · 备份 4. 三层组合（本地快速恢复 / 对象存储主备份 / 网内第三副本）→ 验证：RTO 与不可变性达标。 5. 只备不可再生 + 增量去重 + 上传前加密 → 验证：备份集体积降一个数量级。 6. 恢复演练自动化 → 验证：演练通过。 7. 备份走各自到对象存储的路径（不走慢链路）→ 验证：备份期间交互流量 p95 延迟不变。

C · 迁移提速（按收益排序） 8. 不搬可重建的（~64×，已在做）→ 9. 分片并行 + 多流 → 10. 先压缩再传 → 11. 增量/块级 diff → 12. 多路径并行 → 13. 惰性迁移 → 14. 经公网对象存储中转。断点续传是前提。

D · 保密 15. 三层加密（隧道层 / 应用层 E2EE / 静态层）→ 16. 一机一钥 + 密钥轮换吊销 + 群密钥轮换 + 校验控制面签名 → 17. 元数据保护（最小网络地图 / 不透明 ID / 隐私模式强制走中继）。

六、验收

#	口径	期望
A	群聊拓扑	已选一种（推荐混合）且说明取舍
B	备份主层	对象存储为主；覆盖网络=通道+第三副本（非主备份）
C	迁移	以实测吞吐为准，目标把 22 KB/s 提到链路可支持的量级
D	保密判据	「中继只见密文与元数据 / 控制面只见密文与身份」两条均满足
E	现成度透明	§五五条已判定（群聊❌需新建 / agent⚠️部分 / 备份✅基础已有 / 迁移⚠️部分 / 保密⚠️缺口在身份）

七、回滚

本档自身：零改动 ⇒ 无回滚需要。
执行期：四块（群聊 / 备份 / 迁移 / 保密）互相独立，各自可回滚；⚠️ 备份改造须保留旧路径直到恢复演练验证通过。

八、回报格式

执行会话回填：① 每步验证命令 + 实际输出 ② 群聊拓扑选型与理由 ③ 备份三层落点与恢复演练结果 ④ 迁移实测吞吐（与 22 KB/s 基线对比的倍数） ⑤ 加密三层各自的落地位置与判据验证 ⑥ commit ⑦ 未完成项与卡点。

九、未验证项 / 待办

群聊房间层的具体成员模型与发言预算参数（待压测标定）｜E2EE 的实现路径（需新增）｜多路径并行与惰性迁移的实际收益（待评估）｜一机一钥迁移期间的兼容期处理（待设计）。

附录 A · 原始规划正文（逐字保留 · 2026-09-16）

以下为工作区根 覆盖网络_答疑_群聊备份迁移保密_20260916.md 的原文全文，仅删除其一级标题（避免与档案标题重复），其余一字未改；本档的可判定部分以上方 8 段为准。

日期：2026-09-16 ｜性质：技术答疑（承接 覆盖网络_全球架构复盘_20260916.md） 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

一、群聊 + 「用户配置的 agent 也在群里互动」——✅ 可以实现

关键判断：群聊不是覆盖网络的机制，它是应用层的事。覆盖网络只解决"参与者散在各种网络里也能互相到达"——而这恰好是群聊最麻烦的那一半。所以两者是互补，不是一回事。

1.1 三种分发拓扑（必须选一种，推荐第三种）

拓扑	优点	缺点
中心房间（消息过服务端）	简单、天然全序、易持久化	中心带宽与单点；隐私面大
网状（成员间直连分发）	省中心	N²、顺序与送达确认难做
混合（推荐）	小群网状 / 大群走区域汇聚节点；离线补拉	实现复杂度最高，但可控

1.2 覆盖网络给不了的，必须在应用层补

覆盖网络只提供"可达"，不提供"有序、去重、不丢"。所以群聊必须自己带：

消息 ID（内容寻址/哈希）⇒ 去重
因果/逻辑时钟 ⇒ 排序（无需全局时钟）
送达确认 + 离线补拉（拉取式，不是推送式）
房间级权限：加入房间才可见 —— 与"接入 ≠ 可见"一致

1.3 Agent 作为群成员的四个要点

身份：agent 是一个独立的对等成员（有自己的密钥与地址），但身份绑定其主人、权限可单独授（可只读、可仅在被 @ 时发言）。
运行位置决定数据面：跑在用户自己机器上 ⇒ 消息不出去；跑在服务器 ⇒ 平台要路由给它。
⚠️ 最大的坑 = agent 互相激发造成无限循环（A 说 → B 回 → A 再说）。必须内建四条硬约束：
1. 禁止 agent 直接触发 agent —— 只有人的消息能触发 agent 发言（切断自激环）；
2. 每轮发言预算（每个 agent 每 N 分钟最多 M 条）；
3. 静默期（发言后冷却）；
4. 房间级全局速率上限 + 排队（多 agent 同时发言时按序，不刷屏）。
风暴防护：群聊是典型"推送放大点"（1 条消息 × N 成员）⇒ 大群禁止"每人每条广播给全体"，改"摘要比对 + 按需拉取"。

二、服务器用户数据备份 —— 主备份优先对象存储，覆盖网络只当搬运通道与第三副本

用户问「优先还是云存储方案」。答案是分层组合，不是二选一；但从"备份的本质指标"看，主备份应当优先对象存储。

2.1 三层组合（推荐）

层	落点	作用	为什么
快速恢复层	本地盘	最近 N 份，恢复最快	RTO 最短、零流量
主备份层	对象存储（自建 MinIO 或云 OSS/COS）	长期、异地、不可变	备份的核心是可恢复性 + 不可变，对象存储天然给 SLA、版本化、生命周期
第三副本 / 通道	覆盖网络内的自有节点	异地冗余 + 搬运	零月费、跨地域；但没有 SLA

2.2 为什么"覆盖网络不适合当主备份"

P2P/网内副本的根本弱点：对端是否在线不由你控制，没有 SLA、没有不可变、容易被误删或版本混乱。它适合"搬运"，不适合"存档"。

2.3 工程要点（决定成本与可用性）

只备不可再生数据：已有实测口径 —— 不可再生 46.3 MB、可重建 2.9 GiB ⇒ 只备前者 + 附一份重建清单，体积降一个数量级。
增量 + 内容寻址去重（同一份只存一次）。
上传前先加密（服务端/对象存储不持有明文）。
校验和 + 版本化 + 防误删（对象存储的 lifecycle / 不可变桶）。
恢复演练自动化（现有平台已有恢复演练先例，保持）。
⚠️ 别用那条慢链路当备份通道：跨云实测 22 KB/s —— 备份上传应走各自到公网/对象存储的路径，而不是两地直连。

三、迁移服务器速度优化

现状痛点：47→106 直连实测 ~22 KB/s（46.3 MB 需 ~35 分钟）。

按收益排序的手段：

序	手段	收益
1	不搬可重建的（只搬 46.3 MB，而非 2.9 GiB）	~64× —— 已在做，最大的那一招
2	分片并行 + 多流	单流受 BDP（带宽时延积）限制；多流才能吃满链路 —— 实测脚本已在用分片
3	先压缩再传	文本/JSON 常见 10:1
4	增量 / 块级 diff（rsync 式或内容寻址）	只传变化块
5	多路径并行（直连 + 中继同时传）	覆盖网络带来的新能力；⚠️ 需给中继留额度，别打满
6	惰性迁移（内容寻址 + 按需拉取）	把"前置全量"变成"用哪个拉哪个" —— 体验上最优
7	经公网对象存储中转	两地直连慢时，各自到云的带宽往往更快

断点续传是前提（不追求一次传完；分块落盘、可续）。验收：以实测吞吐为准，目标把 22 KB/s 提到链路可支持的量级。

四、如何确保用户信息在覆盖网络传输中的保密性

4.1 三层加密（缺一层都不算保密）

层	机制	防谁
隧道层	WireGuard / Noise 端到端加密；中继只转发密文、不解密	中间网络、中继运营者
应用层（E2EE）	消息在应用层再加一层；密钥只在成员间分发	连自己的控制面/中继也读不到内容
静态层	磁盘与备份加密（上云前先加密）	存储侧泄露

4.2 身份与密钥（当前最大的缺口）

一机一钥替换共享令牌（现状是共享 bearer，无法吊销单台）。
密钥轮换与吊销（会话密钥定期 rekey —— WireGuard 已有基础）。
群聊的群密钥轮换：成员变更即轮换 ⇒ 前向保密。
必须校验控制面签名：否则可以下发假的网络地图（假身份）⇒ 中间人。

4.3 元数据保护（最容易忽略的一层）

隧道只保护内容，控制面与中继仍能看到谁连谁、何时、流量多大。要减少暴露：

最小网络地图：只下发"你确实需要连接的"对端，不下发全网名单。
不透明 ID：中继侧不用真实用户名/主机名。
隐私模式：直连会向对方暴露自己的真实 IP（P2P 的固有代价）⇒ 需要隐私的流量强制走中继，不暴露 IP。

4.4 一句话判据

"中继只能看到密文与元数据，控制面只能看到密文与身份" —— 任何一条不满足即视为不合格。

五、与现有平台的关系（这三件哪些是现成的）

需求	现成度	说明
群聊	❌ 需要新建	平台现在是"每用户一个实例 + 会话"，没有"房间"抽象 ⇒ 这是新增能力，不是开关
Agent 入群	⚠️ 部分	agent 能力有，但"作为群成员"需新增成员类型 + 发言预算机制
备份	✅ 基础已有	`backup.sh` + cron + `/opt/dsh/backups/` + 恢复演练；需补"对象存储 + 只备不可再生"
迁移提速	⚠️ 部分	分片已在用；缺多流并行、惰性迁移
传输保密	⚠️ 缺口在身份	隧道加密已有；共享令牌 ⇒ 一机一钥是硬前置；E2EE 需新增

14 KiB Raw Blame History Unescape Escape