admin
ce8e6ceed9
回收 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）、记忆修复前备份。
163 lines
8.9 KiB
Markdown
163 lines
8.9 KiB
Markdown
# 覆盖网络 · 骨干层方案（多中心 + 选择性加入）
|
||
|
||
> 日期：2026-09-16 ｜ 性质：**设计稿**（承接 `覆盖网络_百台规模推演_20260916.md` **P0-1** 的展开）
|
||
> 用户提出：**有公网 IP 的节点是否可以设置专门的网络服务，让其他有公网 IP 的节点加入形成专门的覆盖网络，其他用户节点可以选择性加入**
|
||
> 🟢 **范围**：**只考虑技术实现，跨境数据合规由使用者自行考虑**（同 `覆盖网络_全球架构复盘_20260916.md` §0 范围声明）
|
||
|
||
---
|
||
|
||
## 0. 判定
|
||
|
||
✅ **可以，而且这是成熟系统里的标准模式** —— 业内叫「**超级节点 / 骨干层（supernode / backbone）**」，不是新造东西。
|
||
|
||
| 先例 | 骨干层是什么 |
|
||
|---|---|
|
||
| ZeroTier | Planet（官方根）+ **Moon（自建公网节点）** |
|
||
| Nebula | **Lighthouse**（有公网 IP 的会合点，可多台冗余） |
|
||
| Tailscale | **DERP 中继** + exit node / subnet router（"提供服务的节点"） |
|
||
| libp2p | **relay v2 + AutoRelay**（有公网 IP 的节点自动成为中继候选） |
|
||
| 早期 Skype | **supernode**（有公网 IP 的节点自动升格） |
|
||
| EasyTier / 自建方案 | 指定"公网节点"作为中继与路由 |
|
||
|
||
**它解决的正是推演 v2 里最贵的那条**：中继容量要按 45%–55% 的 L3 占比预留 —— 靠一台中心服务器扛不住，而网络里本来就躺着现成的公网出口。
|
||
|
||
---
|
||
|
||
## 1. 形态：**多中心骨干**（取代单中心星型）
|
||
|
||
```
|
||
┌──────── 骨干层（有公网 IP，互相可直接连）────────┐
|
||
│ S1 ── S2 ── S3 ── … ── Sn （全互联或有界互联） │
|
||
└───┬──────┬──────┬───────────────┬───────────────┘
|
||
│ │ │ │ ← 选择性加入
|
||
┌─────┴─┐ ┌──┴───┐ ┌┴────┐ ┌────┴───┐
|
||
│家宽节点│ │移动网 │ │企业网│ │ VPN 节点│ ← L2/L3 层节点
|
||
└───────┘ └──────┘ └─────┘ └────────┘
|
||
```
|
||
|
||
| 项 | 取值 | 理由 |
|
||
|---|---|---|
|
||
| 骨干成员 | **有公网 IP 的节点**（服务器 / 专属 IP） | 互相可直接连，无需打洞 |
|
||
| 骨干互联 | **全互联，但成员数设上限** | 10 个 = 45 条；20 个 = 190 条；50 个 = 1,225 条 ⇒ **建议 ≤10–20** |
|
||
| 普通节点接入 | 每台只连 **1–2 个骨干**（主用 + 备用） | 100 台 ⇒ 100–200 条常连，完全可控 |
|
||
| 骨干承担 | 会合（rendezvous）· 中继（relay）· 可选 STUN-like 探测 | 都是用户态 UDP/TCP，**不需要特权** |
|
||
|
||
---
|
||
|
||
## 2. 一个骨干节点要跑什么（可以打成一个独立组件）
|
||
|
||
| 服务 | 作用 | 流量特征 |
|
||
|---|---|---|
|
||
| **会合** | 把两个节点的候选地址互相告诉对方 | 极小 |
|
||
| **中继** | 打洞失败时转发密文 | **大**（按 L3 占比算） |
|
||
| **NAT 探测** | 帮节点判断自己的映射类型 | 极小 |
|
||
| **目录镜像**（可选） | 分发"有哪些骨干可用"的**签名目录** | 小 |
|
||
|
||
⇒ 这四样打包成一个「节点服务」，**正好可以放进桌面客户端那个独立仓库**（复用打包与更新链），不需要碰平台主进程。
|
||
|
||
---
|
||
|
||
## 3. 三条必须钉住的设计约束
|
||
|
||
### 3.1 「选择性加入」必须拆成三个独立概念（否则一定出事）
|
||
|
||
| 层 | 含义 | 归属 |
|
||
|---|---|---|
|
||
| **接入**（connectivity） | 我能通过谁到达别人 | 节点自选（就近 / 按容量） |
|
||
| **成员**（membership） | 我在不在网里、谁批准 | **控制面签发 + 可吊销** |
|
||
| **可见**（visibility） | 我能看到/访问谁 | **ACL，默认最小** |
|
||
|
||
⚠️ **最危险的默认**是"加入骨干 ⇒ 能看见骨干上所有人"。那会变成一张巨型扁平网，与项目"**权限只准收窄**"直接冲突。
|
||
⇒ **接入与可见必须解耦**：可以借骨干做**转发通道**，而不暴露对端清单。
|
||
|
||
### 3.2 骨干资格：**只能由控制面签发**（不得由骨干节点自行批准）
|
||
|
||
- 若骨干节点能自行批准新成员 ⇒ 出现**第二个权威源**（违反单一来源），且**任何人开个公网 IP 就能进骨干** ⇒ 骨干沦为公网跳板。
|
||
- 正确形状：**控制面签发骨干成员资格（可吊销）+ 骨干之间只做"校验签名"**，不自行决策。
|
||
- 与平台既有分层判据完全一致：**会合/中继可以多实例（数据面），权威状态必须单点**。
|
||
|
||
### 3.3 骨干节点**不能**被默认征用去转发别人的流量
|
||
|
||
- 骨干节点的带宽可能属于**贡献者本人**。若默认"为全网转发" ⇒ **扩大权限面 + 占用他人资源**（命中 R5 与边界外）。
|
||
- ⇒ 必须显式：**服务范围**（只服务自己名下设备 / 服务全网）+ **带宽上限** + **随时退出**。
|
||
- 这一条需要用户定，见 §7。
|
||
|
||
---
|
||
|
||
## 4. 容量与数字（沿用推演 v2 的分层口径）
|
||
|
||
| 项 | 取值 |
|
||
|---|---|
|
||
| 100 台构成 | L1 有公网 IP **10** ｜ L2 可打洞 **30** ｜ **L3 只能中继 40–55** |
|
||
| 骨干规模 | 10 个 ⇒ 骨干内 **45** 条常连 |
|
||
| 每骨干接入 | **10–20** 个节点（100 / 10 上限） |
|
||
| 骨干心跳 | 45 条 × 1/20 s ≈ **2.3 req/s** ⇒ 可忽略 |
|
||
| 中继稳态 | 20–27 Mbps 总量，**摊到多个骨干**而非一台 |
|
||
| 骨干挂 1 个 | 受影响 = 接入它的那 10–20 台 ⇒ **秒级迁到备用骨干**（不是全网掉线） |
|
||
|
||
⇒ 相对单中心，**多中心骨干把"中继带宽"与"单点故障"同时摊开了** —— 这是它最大的收益。
|
||
|
||
---
|
||
|
||
## 5. 故障与运维面
|
||
|
||
| 场景 | 期望行为 |
|
||
|---|---|
|
||
| 骨干 S2 挂 | 接入它的节点秒级迁到备用骨干；正在进行的连接会断一下 |
|
||
| 骨干目录不可达 | **用本地缓存的签名目录**继续选路（目录不能是单点） |
|
||
| 骨干被攻破 | 影响面 = 接入它的那批节点（**不是全网**）⇒ 优于单中心 |
|
||
| 骨干换 IP / 身份轮换 | 由控制面更新目录，节点热切换 |
|
||
| 节点从骨干 A 迁到 B | 新旧路径短暂并存，避免"先断后连"的可见中断 |
|
||
|
||
---
|
||
|
||
## 6. 与现平台架构的兼容性（**这是能不能落地的前提**）
|
||
|
||
| 项 | 判定 |
|
||
|---|---|
|
||
| 骨干 = 一种新的 **host 类型**（有公网 IP、可做中继） | ✅ 与 T08 的 host / lease 模型兼容，属**新增能力标签** |
|
||
| 会合 / 中继多实例 | ✅ 属数据面，**架构本来就允许多实例** |
|
||
| 归属 / 租约 / 骨干资格 | ⛔ **必须单点控制面** —— 客户端与骨干一律不得持有权威状态 |
|
||
| 现有中继实现 | ⚠️ 现在是**挂在 Manager 上的 SSH 反向隧道**（单中心）⇒ 落地第一步就是**把它拆成可独立部署的组件** |
|
||
| 打包与分发 | ✅ 复用桌面客户端独立仓库的打包/更新链 |
|
||
|
||
---
|
||
|
||
## 7. 需用户拍板的一项（真取舍）
|
||
|
||
**骨干节点的服务范围**：是只服务自己名下的设备，还是替全网（含其他用户）转发流量。
|
||
|
||
**A · 只服务自己名下的设备（自用骨干）**
|
||
|
||
优点：无合规与计费问题；不占用他人资源；权限面不变（不命中 R5）；实现最简单，节点只认自己的主人。
|
||
缺点：骨干数量受限于"有几个用户有公网 IP 的机器"；跨用户无法互相兜底，冗余度低。
|
||
|
||
**B · 服务全网（共享骨干）**
|
||
|
||
优点：骨干多、冗余好、可用性高；单个骨干挂了影响小；对 L3 那 40–55 台的中继容量最容易满足。
|
||
缺点：**他人的流量跑在你的机器上**（资源与计费要立规矩）；骨干会看到流量元数据（谁连谁、流量大小）；节点被攻破的影响面变大。
|
||
|
||
**我倾向 A→B 渐进**：先把骨干做成"自用骨干"跑通（零合规风险、可立刻验证），把"是否贡献带宽给全网"做成**显式开关**，等 A 稳了再逐个放开。
|
||
|
||
---
|
||
|
||
## 8. 落地顺序（每步可单独回滚）
|
||
|
||
1. **把会合 / 中继从 Manager 里拆出来**，做成可独立部署的组件（当前是绑定在 Manager 上的 SSH 隧道）。
|
||
2. **控制面签发骨干资格 + 下发签名目录**（骨干之间只校验，不自行批准）。
|
||
3. **骨干互认与心跳**（≤10 个成员，全互联）。
|
||
4. **接入选路**（节点就近选主/备骨干，支持秒级迁移）。
|
||
5. **接入与可见解耦**（默认只见自己名下设备）。
|
||
6. 可选：开放"贡献带宽给全网"开关（= §7 的 B 档）。
|
||
|
||
---
|
||
|
||
## 9. 未验证项
|
||
|
||
| # | 项 | 状态 |
|
||
|---|---|---|
|
||
| 1 | 各网络类型实际占比（决定骨干数量需求） | ⚠️ 推演设定 |
|
||
| 2 | 骨干节点的上行带宽是否够（家宽上行常远小于下行） | ⚠️ 未实测 |
|
||
| 3 | 骨干全互联在 ≤10 个成员时的实际收敛开销 | 📋 量级推算（2.3 req/s） |
|
||
| 4 | 现有 SSH 隧道改造为独立组件的具体工作量 | 📋 待评估（未读该模块全量代码） |
|