128 lines
7.6 KiB
Markdown
128 lines
7.6 KiB
Markdown
|
# 覆盖网络方案答疑：群聊与 Agent 参与 · 备份 · 迁移速度 · 传输保密
|
|||
|
|
|
|||
|
|
> 日期：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 需新增 |
|