dsh_ai1net_server/dsh-server-docs/04-调整方案/106-覆盖网络-百台规模推演-v2.md

# 106 · 覆盖网络 · 百台规模推演-v2
- 日期：2026-09-16 ｜ 版本：**v2**（09:3x 按用户纠正重写前提与结论）｜ 状态：📋 **规划态**（**纯文字推演**，纸面演算，未接入任何机器）
- 来源：工作区根 `覆盖网络_百台规模推演_20260916.md`（正文见 附录 A）
- 层级：规模推演（第一版）｜ 承接档案 103 §六；上级 = 档案 104；被 105（P0-1 展开）· 107（扩到 1000 台）承接

> ⚠️ **本档含一次前提级纠错（v1 作废），务必先读 §0 修正声明**
> 用户纠正原话：**「单机用也要互联，这正是建立覆盖网络的目的」**，且 **100 台是各种网络情况，不是全都是单机**。
> v1 错在**把「租户维度收窄」误当成「网络维度收窄」**（平台只有我一个用户 ≠ 我只有一台机器、不需要跨机）。

> **TL;DR（v2）**
> 租户维度只有一个人，**不影响**网络维度有 100 台设备要互通 ⇒ **覆盖网络正是为「同一个人/团队的多台设备散落在各种网络里」而存在**。
> 异构网络最直接的后果：**中继占比远高于同构假设**（不是 15%，基准 **40–45%**、最坏 **55%**）⇒ 中继容量必须按最坏情况预留，
> 并**先把网络里现成的公网节点（L1）用起来当会合/中继**。拓扑不用换（仍是星型/分组星型），要换的是**三件**：传输、身份、**443/TCP 兜底**。

## 一、目标

对「**同一个人/团队名下 100 台异构设备**经覆盖网络互联」做纸面推演：节点画像 · 中继容量 · 拓扑 · 分场景判读 · 瓶颈排序 · P0/P1/P2 前置项。
可判定「做完了没有」＝ 上述六项齐备，且**每条数值都标注是「推演设定」还是「实测锚点」**。

## 二、只读前置

| # | 事实（实测锚点，非推演） | 核对方式（期望输出） |
|---|---|---|
| 1 | 跨机访问实例 UI 首屏 **≈10.8 MB**（实测） | 抓壳页 `/plugins/` 合并脚本计字节（档案 97 同源，实测 `11,363,655 B`） |
| 2 | 跨云链路 **~22 KB/s**（下界参考） | 47↔106 实测记录（见档案 110 §三） |
| 3 | 心跳间隔 **20 s** | `src/worker/tunnel.ts` 自愈定时器 |
| 4 | 归属/租约**必须单点 Manager**；会合/中继**可多实例** | 集群化设计 §1.3 |
| 5 | 节点身份现为**共享密钥**（无法吊销单台）⇒ 一机一钥是硬前置 | `src/worker/agent.ts` 头部自陈 |

## 三、范围

- **改什么**：⏳ 未开跑。本档只输出推演与 P0/P1/P2 前置清单，不含实施。
- **不动什么**：⛔ 权威状态单点语义｜⛔ 本轮不动服务器、不改代码。
- **前提口径（用户纠正后）**：100 台 = **异构**（服务器 / 家宽 / 共享 IP·CGNAT / 移动网 / 企业校园网 / VPN 全隧道），**不是同构单机**。

## 四、决策点

**已定（v2 重写后的口径）**

1. **单机自用 ≠ 不需要互联** —— **租户维度收窄 ≠ 网络维度收窄**（用户原话）。⛔ 不得再用「单机自用所以没流量要互联」当前提。
2. **中继按 45% 设计 / 55% 留余量**（乐观 30% / 基准 40–45% / 悲观 55%）—— ⛔ 不得再用同构假设的 15%。
3. **必须补 443/TCP 兜底通道**（否则封 UDP 的企业/校园网整类节点进不来）。
4. **L1（有公网 IP）自动升格为中继候选池**。
5. **拓扑仍是星型 / 分组星型 + 按需建连 + 懒保活**（⛔ 不建全互联：100 台全互联 4,950 条 vs 星型 100 条，差 49.5 倍）。

**未定 / 待复核**：控制面机规格（1.8 GB / 2 核 系 09-08 旧记录）；各网络类型实际占比（推演设定，需按真实设备池校准）。

## 五、步骤（§7 前置项，按 P0/P1/P2）

**P0（不做就走不通）**
1. 中继容量按 **45–55% L3 占比**设计 + **L1 自动升格** → 验证：中继容量不随玩家/设备数漂移。
2. **443/TCP 兜底通道** → 验证：封 UDP 环境仍能接入。
3. **一机一钥 + 可吊销 + 限流** → 验证：吊销单台生效。
4. **SSH 反向隧道换成单进程多对端方案** → 验证：常驻内存下降 1–2 个数量级。

**P1（不做会出事）**：中继 ≥2 台且**与控制面分开部署** + 秒级切换｜跨机大流量直连优先 + 10.8 MB 首屏就近/本地缓存｜保活 ≤25 s；VPN/代理类**检测即降级中继**（不重试）｜重连指数退避 + 抖动 + 控制面令牌桶。

**P2**：节点自报网络画像（路径类型 / NAT 类型 / 是否 VPN / 上行带宽）｜客户端 × 平台版本兼容矩阵。

## 六、验收

| # | 口径 | 期望 |
|---|---|---|
| A | 分层数字 | L1 **10** / L2 **30** / **L3 需中继 40–55**；稳态中继 **20–27 Mbps** |
| B | 拓扑对比 | 全互联 4,950 条 vs 星型 100 条 ⇒ 明确**不建全互联** |
| C | 分场景判读 | S1–S9 逐条给出判读（含 **S4 定性从「危险」修正为「核心用例」**） |
| D | 瓶颈排序 | 7 条按「先炸顺序」排（中继带宽第一） |
| E | 未验证项透明 | §九 七条已列全 |

## 七、回滚

- **本档自身**：零改动 ⇒ 无回滚需要。
- ⚠️ **v1 的前提已被推翻**：本档**取代 v1**，⛔ 不得再引用 v1 §0 的结论（"100 台没有流量要互联"）。v1 全文保留在 附录 A 的 §0 修正声明中（作为错误样本）。

## 八、回报格式

执行会话回填：① 校准后的网络类型实际占比（与 §2 表对照）② 实测打洞成功率（分层）③ 中继出口带宽与 jitter 实测 ④ 控制面规格复核结果 ⑤ 若推翻本档任一数字，给出实测口径与取数时间。

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

各网络类型**实际占比**（推演设定，需按真实设备池校准）｜打洞成功率（分层：家宽 / CGNAT / 移动网 / 企业网，**未实测**）｜**VPN 全隧道是否真的破坏打洞**（未实测，推演按"会破坏"保守处理）｜企业网封 UDP 的比例（未实测）｜中继出口带宽与链路质量（未实测，仅有跨云 22 KB/s 作下界）｜控制面机规格（1.8 GB / 2 核，**待复核**）｜单条 SSH 隧道常驻内存 3–5 MB（量级估计）。

---

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

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

> 日期：2026-09-16 ｜ **版本：v2**（09:3x 按用户纠正重写前提与结论）｜ 性质：**纯文字推演**（纸面演算，未接入任何机器）
> 配套：`可行性评估_客户端安装与覆盖网络互联_20260916.md` §六｜`dsh客户端化部署方案_20260916.md`｜`dsh桌面客户端_开发方案_20260916.md`
> 📄 **本文的上一级（全球级复盘，含风暴类型学与流量组织）见 `覆盖网络_全球架构复盘_20260916.md`**

---

## 0. 修正声明（v1 的第 0 节被判定为错误）

> ⚠️ **用户纠正（2026-09-16 09:3x，原话要点）**：**「单机用也要互联，这正是建立覆盖网络的目的」**；且 **100 台是各种网络情况，不是全都是单机** —— 有服务器、有单机、有局域网、有互联网、有专属外网 IP、有共享外网 IP、有固定宽带、有移动网、有 VPN 等各种情况。

**v1 错在哪**：v1 断言"按单机自用形态，100 台之间根本没有流量要互联 ⇒ 覆盖网络无事可做"。
**错因**：把 **租户维度的收窄**（平台只有我一个用户）误当成 **网络维度的收窄**（我只有一台机器、不需要跨机）。

| 维度 | 单机自用是否收窄 | 说明 |
|---|---|---|
| **租户维度**（有几个人用） | ✅ **收窄为 1** | 形态开关决定 |
| **网络维度**（要连几台机器） | ❌ **完全不收窄** | **同一个人也有多台设备**，分布在家里宽带 / 移动网 / 公司网 / 云主机上 —— **这正是覆盖网络存在的理由** |

⇒ 修正后：**"单机自用"与"需要互联"不矛盾，而是同一条路线的两个正交面。** v2 据此重写。

---

## 1. 前提（v2）

| 项 | 取值 |
|---|---|
| 角色 | **同一个人（或同一个团队）名下的 100 台设备**，经覆盖网络互相可见 |
| 目标流量 | ① 跨机访问彼此的实例/工作区 ② 跨机文件与数据交换 ③ 平台侧的控制与调度 |
| 中心 | 控制面（会合点）+ 中继 —— **数量与落点见 §3（不再假设只有 1 台）** |
| 节点构成 | **异构**，见 §2 |

---

## 2. 节点构成：100 台的异构画像（**这是 v1 缺失的核心**）

> 台数为推演设定（可按实际调），**关键结论对比例敏感、对绝对值不敏感**。

| 类 | 场景 | 台数 | 公网可达 | NAT 行为 | 打洞前景 |
|---|---|---|---|---|---|
| A | **云服务器**（专属公网 IP） | 10 | ✅ 可直接拨入 | 无 NAT | 不需要打洞 |
| B | **家庭固定宽带** | 30 | ❌ | 多为锥形/受限锥形 | ✅ 最好 |
| C | **共享公网 IP / CGNAT**（含运营商大内网） | 20 | ❌ | 多用户共享同一出口，端口映射冲突 | ⚠️ 差 |
| D | **移动网**（4G/5G） | 15 | ❌ | **对称 NAT + CGNAT 居多** | ❌ 基本失败；且切基站就换 IP |
| E | **企业 / 校园局域网** | 15 | ❌ | 对称 NAT，**常封 UDP**，可能强制 HTTP 代理 | ❌ 差 |
| F | **VPN 用户**（全隧道） | 10 | 取决于 VPN | VPN 把流量全隧道化 ⇒ 映射被破坏 | ❌ 差 |

### 2.1 按可达性分三层（**决定谁是直连、谁是中继**）

| 层 | 定义 | 台数 | 在方案里的角色 |
|---|---|---|---|
| **L1** | 可直接拨入（有公网 IP） | **10** | **天然的会合点 / 中继候选** |
| **L2** | 能打洞（锥形类） | **30** | 直连主体，流量不过中心 |
| **L3** | **只能走中继** | **40–55**（C/D/E/F 中打洞失败的部分） | **中继容量必须按这一层算** |

> ⚠️ **v1 假设"15% 需中继"，对异构网络严重偏低。**
> 保守口径：**按 45% 设计中继容量，按 55% 留余量。**（乐观 30% / 基准 40–45% / 悲观 55%）

### 2.2 三类"特殊网络"的处置要求（缺一样就有整类节点进不来）

| 情况 | 现象 | 处置 |
|---|---|---|
| **封 UDP**（企业网/校园网） | 打洞与 UDP 中继全失败 ⇒ 该类节点**完全看不见** | 必须提供 **443/TCP 兜底通道**（TLS 伪装），否则 E 类 15 台直接出局 |
| **全隧道 VPN** | 反复尝试打洞、每次失败、白白抖动 | **检测到即直接降级中继**，不要重试 |
| **移动网** | 切基站换 IP，直连秒断 | 保活更密（≤20 s）+ 重打洞要快，且**中继常驻为该类兜底** |

---

## 3. 中继容量：按最坏情况排（v1 的数字作废）

| 项 | v1（同构假设） | **v2（异构）** |
|---|---|---|
| 需中继的台数 | 15 | **40–55**（按 45 设计 / 55 留余量） |
| 稳态占用（按 0.5 Mbps/台） | 7.5 Mbps | **20–27 Mbps** |
| 跨机首屏突发（≈10.8 MB/台） | 165 MB | 同口径：**3 台同时冷加载 ≈ 32 MB；10 台 ≈ 108 MB** |

**由此得出 v2 的第一条新设计点**：

> 🔑 **让 L1 层（有公网 IP 的 10 台）自动升格为中继候选池。**
> 异构网络里本来就躺着现成的公网出口 —— 不利用它，就等于用一台小服务器去扛 40+ 台的流量。**同构假设下想不到这一条。**

⚠️ 但有一条硬边界（与平台既有分层判据一致）：
- **会合点 / 中继：可以多实例**（谁有公网 IP 谁就能当）；
- **权威状态（归属 / 租约）：必须单点 Manager** —— 客户端节点永远不得持有权威状态，否则就是脑裂。

---

## 4. 拓扑：仍然**不能建全互联**（这条 v1 正确，保留）

全互联 = 100×99/2 = **4,950** 条；星型 = **100** 条 ⇒ 差 **49.5 倍**。
⇒ **星型 / 分组星型 + 按需建连 + 懒保活**。跨机通信由中心或直连路径承担，不靠"每对都常连"。

---

## 5. 分场景推演

| # | 场景 | 判读 |
|---|---|---|
| S1 | 逐台加入（1→10→50→100） | 心跳 0.1→0.5→2.5→**5 req/s**；控制面无压力 |
| S2 | 稳态一小时 | 控制面 5 req/s；中继常驻 **20–27 Mbps**（45 台口径） |
| S3 | **家宽笔记本换网**（家→公司） | 秒级重打洞；失败切中继。保活 ≤25 s 才不会表现为"随机断网" |
| S4 | **跨机访问对方实例 UI**（真实需求，非假设） | 首屏 **≈10.8 MB**（实测值）：**直连**（30 台上行 20–50 Mbps）≈ **2–4.5 s ✅**；**走中继**（100 Mbps）≈ 1 s/台但并发即叠加 ⇒ **必须直连优先** |
| S5 | **移动网节点切基站** | IP 变 ⇒ 直连断 ⇒ 回中继；该类节点**在中继上是常态而非例外** |
| S6 | **企业网节点**（封 UDP） | 打洞全败 ⇒ 必须走 **443/TCP 兜底**；否则整类不可用 |
| S7 | **中继 A 挂掉** | 受影响的是 L3 那 45 台 → 必须秒级切 B；**控制面与中继分开部署**（合并 = 挂了全员失联） |
| S8 | 控制面重启 / 早高峰 100 台同上线 | 瞬时 **100 并发** ⇒ 指数退避 + 抖动 + 令牌桶 |
| S9 | 异常节点 | 现状是**共享密钥**（无法吊销单台）⇒ 一机一钥是硬前置 |

**S4 的定性变了**：v1 把它当"要规避的危险场景"，v2 认定它是**核心用例** ⇒ 结论从"大流量绝不能过网"**修正为**：
> **大流量优先直连、中继兜底，且中继容量按几十台常驻来配**；同时把 10.8 MB 首屏做**就近/本地缓存**（同版本复用 + 已有 ETag/304），把跨机冷加载从常态降为例外。

---

## 6. 瓶颈排序（v2，按先炸顺序）

| 序 | 瓶颈 | 触发条件 | 量级 |
|---|---|---|---|
| 1 | **中继带宽** | L3 占 45%（v1 只算 15%） | 稳态 20–27 Mbps + 突发叠加 |
| 2 | **443/TCP 兜底通道缺失** | 企业网/校园网封 UDP | 整类节点（E: 15 台）完全进不来 |
| 3 | **控制面机内存** | 若沿用 SSH 隧道（每连接一进程） | 100 × 3–5 MB = **300–500 MB** |
| 4 | 控制面单点 | 重启/升级 | 100 并发重连风暴 |
| 5 | 共享密钥 | 无法吊销、可整片放行 | 一机一钥是硬前置 |
| 6 | VPN / 代理类节点 | 反复打洞失败 | 白抖动，需检测即降级 |
| 7 | 版本碎片 | 客户端 × 平台 | 排障成本随台数线性涨 |

---

## 7. 要扩到 100 台必须先做的（v2 修订）

**P0（不做就走不通）**
1. **中继容量按 45%–55% 的 L3 占比设计**，且**让有公网 IP 的节点自动成为中继候选**（不能只有一台中心）—— 具体设计见 **`覆盖网络_骨干层方案_20260916.md`**（多中心骨干 + 选择性加入 + 资格由控制面签发）。
2. **443/TCP 兜底通道**（治封 UDP 的企业网/校园网）——否则整类节点进不来。
3. **一机一钥 + 可吊销 + 限流**（替换共享密钥）。
4. **把 SSH 反向隧道换成单进程多对端方案**（内存差 1–2 个数量级）。

**P1（不做会出事）**
1. 中继 ≥2 台、就近选择、**与控制面分开部署**、秒级切换。
2. **跨机大流量直连优先** + 10.8 MB 首屏就近/本地缓存。
3. 保活 ≤25 s；VPN / 代理类节点**检测即降级中继**（不重试）。
4. 重连指数退避 + 抖动 + 控制面令牌桶。

**P2**
1. **节点自报网络画像**（路径类型 直连/中继、NAT 类型、是否在 VPN、上行带宽）——没有它，容量规划与排障只能靠猜。
2. 版本兼容矩阵（客户端 × 平台）。

---

## 8. 结论（v2，三句）

1. **单机自用与互联是两件事**：租户维度只有一个人，**不影响**网络维度有 100 台设备要互通 —— **覆盖网络正是为"同一个人/团队的多台设备散落在各种网络里"而存在的**。v1 把这两维混为一谈，是本次推演最根本的错误。
2. **异构网络最直接的后果是"中继占比远高于同构假设"**（不是 15%，基准 40–45%、最坏 55%）⇒ **中继容量必须按最坏情况预留**，并且**要先把网络里现成的公网节点用起来当会合/中继**。
3. **拓扑不用换（仍是星型/分组星型），要换的是三件**：传输（SSH → 多对端隧道）、身份（共享密钥 → 一机一钥）、**兜底通道（补 443/TCP）** —— 第三件在 v1 里完全没出现，是异构网络画像逼出来的。

---

## 9. 本推演的未验证项（勿当结论）

| # | 项 | 状态 |
|---|---|---|
| 1 | 各网络类型的**实际占比** | ⚠️ 推演设定（§2 表），需按真实设备池校准 |
| 2 | 打洞成功率（分层：家宽 / CGNAT / 移动网 / 企业网） | ⚠️ 未实测 |
| 3 | **VPN 全隧道是否真的破坏打洞** | ⚠️ 未实测（推演按"会破坏"保守处理） |
| 4 | 企业网封 UDP 的比例 | ⚠️ 未实测 |
| 5 | 中继出口带宽与链路质量 | ⚠️ 未实测（仅有跨云 22 KB/s 作为下界参考） |
| 6 | 控制面机规格（1.8 GB / 2 核） | ⚠️ 来自 2026-09-08 旧决策记录，**需复核** |
| 7 | 单条 SSH 隧道常驻内存 3–5 MB | 📋 量级估计 |