dsh_shenxian/dsh-server-docs/04-调整方案/105-覆盖网络-骨干层方案.md

105 · 覆盖网络 · 骨干层方案

• 日期：2026-09-16 ｜ 状态：📋 规划态 / 未实施（设计稿；未接入任何机器）
• 来源：工作区根 覆盖网络_骨干层方案_20260916.md（正文见 附录 A）
• 层级：专项设计（承接档案 106 §7 P0-1 的展开）｜关联：档案 104 §7 落地顺序第 7 步
• 触发（用户原话）：有公网 IP 的节点是否可以设置专门的网络服务，让其他有公网 IP 的节点加入形成专门的覆盖网络，其他用户节点可以选择性加入

TL;DR ✅ 可以，而且是成熟系统里的标准模式 —— 业内叫「超级节点 / 骨干层（supernode / backbone）」（ZeroTier Moon · Nebula Lighthouse · Tailscale DERP · libp2p AutoRelay · 早期 Skype supernode）。 它解决的正是推演里最贵的那条：中继容量要按 45–55% 的 L3 占比预留，靠一台中心服务器扛不住 —— 而网络里本来就躺着现成的公网出口。 🔑 三条硬约束：接入 / 成员 / 可见三分离；骨干资格只能控制面签发；骨干不得被默认征用。

一、目标

把「有公网 IP 的节点组成骨干层、其他节点选择性加入」设计成可落地方案。可判定「做完了没有」＝ 形态（多中心）· 成员上限 · 三条硬约束 · 容量数字 · 兼容性判定 · 落地 5 步 齐备。

二、只读前置

#	事实	核对方式（期望输出）
1	骨干 = 一种新的 host 类型，与 T08 host/lease 模型兼容（属新增能力标签）	读 src/db/（lease）与集群化设计 §1.3
2	会合 / 中继属数据面，架构本来允许多实例；归属/租约/资格必须单点控制面	集群化设计 §1.3
3	现有中继实现 = 挂在 Manager 上的 SSH 反向隧道（单中心） ⇒ 落地第一步就是拆组件	sed -n '147,155p' src/worker/tunnel.ts
4	打包与分发可复用桌面客户端独立仓库的打包/更新链	见 dsh桌面客户端_开发方案_20260916.md §3.4/§6
5	骨干全靠用户态 UDP/TCP，不需要特权	本档 §1 表「骨干承担」行

三、范围

• 改什么：⏳ 未开跑。方案面 = ① 拆会合/中继为独立可部署组件 ② 控制面签发骨干资格 + 下发签名目录 ③ 骨干互认心跳（≤10 成员全互联）④ 接入选路（主/备，秒级迁移）⑤ 接入与可见解耦 ⑥ 可选「贡献带宽给全网」开关。
• 不动什么：⛔ 权威状态（归属 / 租约 / 资格）不得由骨干自行批准｜⛔ 本轮不动服务器、不改代码。
• 红线约束：R5（骨干若默认替全网转发 = 扩大权限面 + 占用他人资源，命中 R5 与边界外 ⇒ 必须显式开关）。

四、决策点

已定

1. 形态 = 多中心骨干（取代单中心星型）：骨干成员上限 ≤10–20（10 个 = 45 条；20 个 = 190 条；50 个 = 1,225 条）。
2. 普通节点每台只连 1–2 个骨干（主用 + 备用）⇒ 100 台 = 100–200 条常连，完全可控。
3. 资格只能由控制面签发（不得由骨干节点自行批准，否则出现第二个权威源、骨干沦为公网跳板）。

待拍板（唯一一项，真取舍 —— 与档案 104 §四 同一项）

骨干节点的服务范围：

• A · 只服务自己名下的设备（自用骨干） 优点：无合规与计费问题；不占用他人资源；权限面不变（不命中 R5）；实现最简单，节点只认自己的主人。 缺点：骨干数量受限于「有几个用户有公网 IP 的机器」；跨用户无法互相兜底，冗余度低。
• B · 服务全网（共享骨干） 优点：骨干多、冗余好、可用性高；单个骨干挂了影响小；对 L3 那 40–55 台的中继容量最容易满足。 缺点：他人的流量跑在你的机器上（资源与计费要立规矩）；骨干会看到流量元数据（谁连谁、流量大小）；节点被攻破的影响面变大。

倾向 A→B 渐进：先把骨干做成「自用骨干」跑通（零合规风险、可立刻验证），把「是否贡献带宽给全网」做成显式开关，等 A 稳了再逐个放开。

五、步骤（§8 落地顺序；每步自带一次验证）

1. 把会合 / 中继从 Manager 里拆出来，做成可独立部署的组件 → 验证：Manager 重启不影响骨干侧已有转发。
2. 控制面签发骨干资格 + 下发签名目录（骨干之间只校验，不自行批准）→ 验证：未签发的公网 IP 无法成为骨干。
3. 骨干互认与心跳（≤10 个成员，全互联）→ 验证：45 条常连心跳 ≈ 2.3 req/s（可忽略）。
4. 接入选路（节点就近选主/备骨干，支持秒级迁移）→ 验证：掐掉主骨干，节点秒级迁到备用。
5. 接入与可见解耦（默认只见自己名下设备）→ 验证：借骨干转发时不暴露对端清单。
6. 可选：开放「贡献带宽给全网」开关（= §四 的 B 档）。

六、验收

#	口径	期望
A	骨干规模与常连数	10 个骨干 ⇒ 骨干内 45 条常连；每骨干接入 10–20 个节点
B	中继容量摊开	稳态 20–27 Mbps 摊到多个骨干，而非一台
C	单点故障收敛	骨干挂 1 个 ⇒ 受影响 = 接入它的 10–20 台，秒级迁到备用（不是全网掉线）
D	目录可用性	骨干目录不可达时用本地缓存的签名目录继续选路（目录不能是单点）
E	故障影响面	骨干被攻破 ⇒ 影响面 = 接入它的那批节点（不是全网）
F	未验证项透明	§九 四条已列全（网络类型占比、家宽上行是否够、全互联收敛开销、SSH 隧道改造工作量）

七、回滚

• 本档自身：零改动 ⇒ 无回滚需要。
• 执行期：5 步各自独立可回滚 —— 拆组件（回退到 Manager 内置隧道）｜签发资格（停发即回到无骨干态）｜互认心跳（关服务）｜选路（回落到单骨干）｜解耦（关开关）。
• ⛔ 不可回滚项：控制面签发资格这一条是红线（一旦下放给骨干自行批准即产生第二权威源）—— 不是开关。

八、回报格式

执行会话回填：① 每步验证命令 + 实际输出 ② 骨干清单与上限实际取值 ③ 服务范围决策落地形态（A / A→B / B） ④ 红线遵守声明（R5 未默认征用他人带宽 / 资格由控制面签发） ⑤ commit ⑥ 未完成项与卡点。

九、未验证项（勿当结论）

各网络类型实际占比（决定骨干数量需求，推演设定）｜骨干节点上行带宽是否够（家宽上行常远小于下行，未实测）｜骨干全互联在 ≤10 成员时的实际收敛开销（量级推算 2.3 req/s）｜现有 SSH 隧道改造为独立组件的具体工作量（待评估，未读该模块全量代码）。

---

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

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

日期：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 隧道改造为独立组件的具体工作量	📋 待评估（未读该模块全量代码）