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）、记忆修复前备份。
114 lines
7.6 KiB
Markdown
114 lines
7.6 KiB
Markdown
# 覆盖网络 · 应用场景推演完成度 & 方案待完善清单（2026-09-16 检查）
|
||
|
||
> **性质**：只读检查报告。⛔ 未改任何代码、未动服务器、未写文档库（全局执行锁被 `修复轮-决策方法-2b` 占用）。
|
||
> **检查对象**：工作区根覆盖网络线 13 份文档。
|
||
> **📌 口径校正（2026-09-16 11:4x 用户纠正）**：本方案的目标应用场景 = **① 多人 + agent 对话 ② MUD / MMORPG 网游 ③ 以上述应用为负载的 1000 台异构网络互联**。此前本报告 §一 把"跨机访问实例/文件交换"排在第 1 档，属**次级用途**，已按用户口径重排。
|
||
|
||
---
|
||
|
||
## 一、判定：三块场景的「互联逻辑模拟」完成了吗
|
||
|
||
| # | 应用场景 | 纸面推演 | 可运行模拟 |
|
||
|---|---|---|---|
|
||
| 1 | **多人 + agent 对话** | ✅ **完成**（S2/S4/S5 有数值 + 调研 §2 分档 + 答疑 §一） | ❌ 零 |
|
||
| 2 | **MUD / MMORPG 网游** | ✅ **完成**（S3 有数值 + 游戏专项 12 条 + 调研 §1） | ❌ 零 |
|
||
| 3 | **1000 台异构互联（承上述负载）** | ✅ **完成**（6 类画像 + S1–S11 + 流量预算总表） | ❌ 零 |
|
||
|
||
**结论**：
|
||
- **"文字推演"这一步是完成的** —— 11 个场景逐个有计算、有结论、有处置手段，三块应用都有对应推演。
|
||
- **"模拟"一步都没开始** —— **全部是纸面演算，零代码、零数据回流**。文档自己标注"未接入任何机器"。
|
||
- ⇒ 差别在于：**现在所有输入数字都是估值**（打洞成功率、jitter、每玩家带宽全是估的），文档自己写"关键结论**对比例敏感、对绝对值不敏感**"。**换言之：结构判断可信，具体容量数字还不可信。**
|
||
|
||
---
|
||
|
||
## 二、三块场景的实际覆盖（逐块）
|
||
|
||
### 2.1 多人 + agent 对话
|
||
|
||
| 已推 | 出处 | 数值 |
|
||
|---|---|---|
|
||
| presence（200 房 × 50 人） | S2 | **8,200 次/秒** |
|
||
| presence（1 个 1000 人大房） | S2/S4 | **16,700 次/秒** ← 第一瓶颈 |
|
||
| 大房消息扇出 | S2/S4 | 1,000 投递/秒（可承受） |
|
||
| agent 放大 | S5 | 无约束 ⇒ **指数增长**；四条硬约束 |
|
||
|
||
- ⭐ 最重要的量化结论：**presence 比消息早爆一个量级**（16,700 vs 1,000）。
|
||
- ⚠️ **缺口 A**：**agent 预算从头到尾没有标定数值** —— 而 §5 结论却说"单房间实际上限 = min(扇出预算, presence 预算, **agent 预算**)"。三个预算里有一个是空的 ⇒ **单房间上限目前给不出数**。
|
||
|
||
### 2.2 MUD / MMORPG 网游
|
||
|
||
| 已推 | 出处 | 数值 |
|
||
|---|---|---|
|
||
| 40 服 × 300 玩家，服放 L1 | S3 | 每服 24 Mbps，**中继承载 0** |
|
||
| 服放家宽（25 服） | S3 | **600 Mbps 常驻** ← 第 2 瓶颈 |
|
||
| 攻城战峰值 | S3 | 1.2–2.0 Gbps |
|
||
| 抖动门槛 | S3 | **jitter < 20 ms** |
|
||
| 核心简化 | 游戏专项 | 玩家之间不需要互联，**中继按服数算** |
|
||
|
||
- ⚠️ **缺口 B（逻辑跳跃）**：S3 推出"服放家宽 ⇒ 600 Mbps 过中继"，但**玩家是外部客户端、不是覆盖网络成员** —— 他们凭什么走我们的中继？游戏专项的说法是"服主动拨出到骨干、玩家连骨干入口"，可**"骨干入口"对外开放 = 把中继变成公网游戏入口**，这是完全不同的形态（权限面扩大 + 计费 + 防滥用），**这一分支在 13 份文档里没有展开**。而它恰好是第 2 大瓶颈的来源。
|
||
|
||
### 2.3 1000 台异构网络互联
|
||
|
||
| 已推 | 数值 |
|
||
|---|---|
|
||
| 设备构成 | 6 类（云服务器 100 / 家宽 300 / CGNAT 200 / 移动网 150 / 企业网 150 / VPN 100） |
|
||
| 需中继占比 | **48.5%**（按 45% 设计、55% 留余量） |
|
||
| 分场景 | **S1–S11 全覆盖**（冷启动 / 稳态 / 游戏 / 大房 / agent / 备份 / 迁移 / 中继故障 / 控制面重启 / 区域突变 / NAT 溢出） |
|
||
| 流量预算总表 | 10 类流量 × 频率 × 单次 × 放大 × 上限手段 |
|
||
|
||
- ⚠️ **缺口 C**：**逐场景独立推，没有并发叠加** —— S1–S11 是串行列举。真实最坏情况是"游戏攻城战 + 备份窗口 + 1000 人大房 + agent 风暴同时发生，且其中 1/3 节点正因中继故障重连"，**这一叠加没有任何一份文档推过**，而瓶颈排序表是按"单瓶颈先炸顺序"排的。
|
||
|
||
---
|
||
|
||
## 三、要把"推演"变成"模拟"，还差三件事
|
||
|
||
1. **固化输入参数表**（设备占比 / 打洞率 / 每玩家带宽 / 消息频率 / 心跳 —— 现在散在 6 份文档里，无统一表 ⇒ **不可复算**）。
|
||
2. **补并发叠加的最坏情况**（缺口 C）。
|
||
3. **用 3–5 台真机把 3 个关键估值换成实测**：打洞成功率、中继 jitter、真实可用带宽 —— 这三个一换，全部容量结论才从"结构可信"变成"数字可信"。
|
||
|
||
---
|
||
|
||
## 四、方案待完善清单（P0 / P1 / P2）
|
||
|
||
### P0 · 不补就走不通（5 条）
|
||
|
||
| # | 缺口 | 为什么是 P0 |
|
||
|---|---|---|
|
||
| **1** | **缺「网（network）」抽象** | 骨干被同时当作"平台 Worker 隧道"与"用户设备 P2P"的会合点，两者权限模型完全不同。**13 份文档从未出现"网络标识（tailnet / network id）"** ⟹ 所有节点落进同一扁平命名空间，与"可见性默认最小"冲突 |
|
||
| **2** | **首次入网引导（bootstrap）无答案** | 会合地址从 env 来，但新设备**第一次**怎么拿到、**首次没有缓存签名目录**时怎么办，无人回答 |
|
||
| **3** | **地址规划与名字解析无落地设计** | 内部地址段怎么分、如何避开用户内网 10/8 · 192.168/16、split DNS 怎么不破坏用户原 DNS |
|
||
| **4** | **信任根与密钥生命周期未设计** | 只写"一机一钥 + 可吊销"，缺控制面签发者（根）的保管与轮换、私钥丢失恢复、设备被盗吊销 |
|
||
| **5** | **外部玩家如何进入游戏服（缺口 B）** | 决定第 2 大瓶颈（600 Mbps）是否真的存在 —— 若玩家不能进，这条瓶颈根本不成立；若能进，则是**权限面扩大**（命中 R5） |
|
||
|
||
### P1 · 不做会出事（7 条）
|
||
|
||
参数表是空的（libp2p 默认值可直接固化）· 30 条未验证项未收敛成取证计划（最该先测 jitter）· 观测最小指标集与阈值缺失 · **权限面评估缺失 = 命中 R5**（虚拟网卡驱动需管理员权限 / 骨干开端口 / nft 打洞）· 成本模型缺失 · 滥用与安全事件处置缺失 · 卸载与退出机制缺失 · 协议选型未收敛 · **最小可用规模（3–5 台）路径缺失**。
|
||
|
||
### P2 · 一致性与流程（4 条）
|
||
|
||
首屏口径笔误（瓶颈落地 §3 标题写 10.8 GB，实为 **10.8 MB/台**）· 落地路线图 **4 个版本**未收敛 · 10 份文档未归档 · 双源声明与判定句矛盾未修（可行性评估 §6.4 已指出）。
|
||
|
||
---
|
||
|
||
## 五、唯一主线（收敛 4 个版本后）
|
||
|
||
| 序 | 动作 | 状态 |
|
||
|---|---|---|
|
||
| 1 | 会合 / 中继从 Manager 拆出（S0–S4） | **现在就能开工** |
|
||
| 2 | 网抽象 + 地址规划 + 引导（P0 1/2/3） | 依赖 ① |
|
||
| 3 | 一机一钥 + 信任根（P0-4） | 依赖 ① |
|
||
| 4 | 443/TCP 兜底（否则封 UDP 的整类节点进不来） | 依赖 ① |
|
||
| 5 | **参数表 + 观测最小集 + 权限评估**（P1 三条） | 可并行 |
|
||
| 6 | **3–5 台最小形态跑通**（把 3 个关键估值换成实测） | 依赖 2/3/4 |
|
||
| 7 | 之后才谈：内容分发 · 房间层 · 游戏 | — |
|
||
|
||
> ⚠️ **别被 1000 台带偏**：1000 是设计上限；**当前目标是同一人的几台设备跨公网互通**。
|
||
|
||
---
|
||
|
||
## 六、本次未做（范围声明）
|
||
|
||
- ⛔ 未写文档库（全局执行锁被占用）；本报告落工作区根。
|
||
- ⛔ 未改代码、未在 47 / 106 执行任何命令。
|
||
- 📌 **未新增上抛项** —— 待拍板仍只有骨干服务范围一项（A 自用 / B 全网，倾向 A→B 渐进）。
|