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）、记忆修复前备份。
168 lines
11 KiB
Markdown
168 lines
11 KiB
Markdown
# 覆盖网络 · 百台规模文字推演（逻辑预演，非实测）
|
||
|
||
> 日期：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 | 📋 量级估计 |
|