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）、记忆修复前备份。
8.9 KiB
覆盖网络 · 骨干层方案（多中心 + 选择性加入）
日期：2026-09-16 ｜ 性质：设计稿（承接
覆盖网络_百台规模推演_20260916.mdP0-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. 落地顺序（每步可单独回滚）
- 把会合 / 中继从 Manager 里拆出来，做成可独立部署的组件（当前是绑定在 Manager 上的 SSH 隧道）。
- 控制面签发骨干资格 + 下发签名目录（骨干之间只校验，不自行批准）。
- 骨干互认与心跳（≤10 个成员，全互联）。
- 接入选路（节点就近选主/备骨干，支持秒级迁移）。
- 接入与可见解耦（默认只见自己名下设备）。
- 可选：开放"贡献带宽给全网"开关（= §7 的 B 档）。
9. 未验证项
| # | 项 | 状态 |
|---|---|---|
| 1 | 各网络类型实际占比（决定骨干数量需求） | ⚠️ 推演设定 |
| 2 | 骨干节点的上行带宽是否够（家宽上行常远小于下行） | ⚠️ 未实测 |
| 3 | 骨干全互联在 ≤10 个成员时的实际收敛开销 | 📋 量级推算（2.3 req/s） |
| 4 | 现有 SSH 隧道改造为独立组件的具体工作量 | 📋 待评估（未读该模块全量代码） |