Files
dsh_shenxian/dsh-server-docs/04-调整方案/110-覆盖网络-答疑-群聊备份迁移保密.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

221 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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)当备份/迁移通道 —— 备份上传应走**各自到公网/对象存储**的路径。
## 四、决策点
**已定**
1. **群聊 = 应用层的事**,覆盖网络只提供「可达」,**不提供**「有序、去重、不丢」⇒ 群聊必须自带:消息 ID(内容寻址/哈希)· 因果/逻辑时钟 · 送达确认 + **离线补拉(拉取式)**· 房间级权限。
2. **✅ 用户选:备份主层用对象存储**(自建 MinIO 或云 OSS/COS),**覆盖网络只当搬运通道与第三副本**。
3. **只备不可再生数据**(+ 附一份重建清单)⇒ 体积降一个数量级。
4. **上传前先加密**(服务端/对象存储不持有明文);**校验和 + 版本化 + 防误删**;**恢复演练自动化**。
5. **传输保密 = 三层加密 + 元数据保护**,**一句话判据:中继只能看到密文与元数据,控制面只能看到密文与身份** —— 任何一条不满足即视为不合格。
6. **agent 四条硬约束**:⛔ 禁止 agent 直接触发 agent(只有**人的消息**能触发)· 每轮发言预算 · 静默期 · 房间级全局速率上限 + 排队。
**未定**:群聊/agent 的具体成员类型与发言预算参数(M / N / 房间上限,需压测标定)。
## 五、步骤(每条自带一次验证)
**A · 群聊与 agent**
1. 选分发拓扑(**推荐混合**:小群网状 / 大群区域汇聚 / 离线补拉)→ 验证:大群**禁止「每人每条广播给全体」**。
2. 群聊自带四项(消息 ID / 逻辑时钟 / 送达确认 + 补拉 / 房间权限)→ 验证:去重与乱序场景可正确收敛。
3. 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 覆盖网络给不了的,必须在应用层补
覆盖网络只提供"**可达**",**不提供**"有序、去重、不丢"。所以群聊必须自己带:
1. **消息 ID**(内容寻址/哈希)⇒ 去重
2. **因果/逻辑时钟** ⇒ 排序(无需全局时钟)
3. **送达确认 + 离线补拉**(**拉取式**,不是推送式)
4. **房间级权限**:加入房间才可见 —— 与"接入 ≠ 可见"一致
### 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 工程要点(决定成本与可用性)
1. **只备不可再生数据**:已有实测口径 —— 不可再生 **46.3 MB**、可重建 **2.9 GiB** ⇒ **只备前者 + 附一份重建清单**,体积降一个数量级。
2. **增量 + 内容寻址去重**(同一份只存一次)。
3. **上传前先加密**(服务端/对象存储不持有明文)。
4. **校验和 + 版本化 + 防误删**(对象存储的 lifecycle / 不可变桶)。
5. **恢复演练自动化**(现有平台已有恢复演练先例,保持)。
6. ⚠️ **别用那条慢链路当备份通道**:跨云实测 **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 身份与密钥(当前最大的缺口)
1. **一机一钥**替换共享令牌(现状是共享 bearer,无法吊销单台)。
2. **密钥轮换与吊销**(会话密钥定期 rekey —— WireGuard 已有基础)。
3. **群聊的群密钥轮换**:成员变更即轮换 ⇒ **前向保密**。
4. **必须校验控制面签名**:否则可以下发假的网络地图(假身份)⇒ 中间人。
### 4.3 元数据保护(最容易忽略的一层)
隧道只保护**内容**,控制面与中继仍能看到**谁连谁、何时、流量多大**。要减少暴露:
- **最小网络地图**:只下发"你确实需要连接的"对端,不下发全网名单。
- **不透明 ID**:中继侧不用真实用户名/主机名。
- **隐私模式**:直连会**向对方暴露自己的真实 IP**(P2P 的固有代价)⇒ 需要隐私的流量**强制走中继**,不暴露 IP。
### 4.4 一句话判据
> **"中继只能看到密文与元数据,控制面只能看到密文与身份"** —— 任何一条不满足即视为不合格。
---
## 五、与现有平台的关系(这三件哪些是现成的)
| 需求 | 现成度 | 说明 |
|---|---|---|
| 群聊 | ❌ **需要新建** | 平台现在是"每用户一个实例 + 会话",**没有"房间"抽象** ⇒ 这是新增能力,不是开关 |
| Agent 入群 | ⚠️ 部分 | agent 能力有,但"作为群成员"需新增成员类型 + 发言预算机制 |
| 备份 | ✅ **基础已有** | `backup.sh` + cron + `/opt/dsh/backups/` + 恢复演练;需补"对象存储 + 只备不可再生" |
| 迁移提速 | ⚠️ 部分 | 分片已在用;缺多流并行、惰性迁移 |
| 传输保密 | ⚠️ **缺口在身份** | 隧道加密已有;**共享令牌 ⇒ 一机一钥**是硬前置;E2EE 需新增 |