dsh_shenxian/dsh-server-docs/04-调整方案/112-覆盖网络-九大瓶颈落地方案.md

112 · 覆盖网络 · 九大瓶颈落地方案

• 日期：2026-09-16 ｜ 状态：📋 规划态 / 未实施（落地解决方案稿）
• 来源：工作区根 覆盖网络_瓶颈落地方案_20260916.md（正文见 附录 A）
• 层级：专项落地（瓶颈 → 可执行做法）｜ 承接档案 107 §4（瓶颈排序）；被 104 §8 落地顺序引用
• 参考来源：Slack 官方 API 文档 · Microsoft SCCM / BranchCache / Delivery Optimization 官方文档 · presence 系统工程实践
• 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

TL;DR 把 107 §4 排出的九大瓶颈逐个给成可执行做法 + 验收判据（含 Slack / SCCM 官方照抄点）。 🎯 如果只做三件事：presence 改造 + 游戏服放 L1 + 块级内容寻址分发 —— 覆盖最大的三个瓶颈，且都不需要改传输协议。 🔑 两个"零成本/低成本高收益"点：游戏服部署规范（零成本，直接消掉 600 Mbps）；presence 改造（唯一第一瓶颈，纯应用层，不动协议）。

一、目标

把九大瓶颈（presence / 游戏服放家宽 / 首屏包冷启动 / 中继抖动 / 备份窗口挤占 / 重连风暴 / agent 自激 / NAT 表溢出 / 版本碎片）逐条转成可执行做法 + 验收判据 + 成本评级。 可判定「做完了没有」＝ 九条齐备，且每条都有可复现的验收判据（不是"感觉好了"）。

二、只读前置

#	事实	核对方式（期望输出）
1	首屏包 10.8 GB/次（1000 台口径）是 #3 的量级来源	实测 11,363,655 B × 1000（档案 97 / 107 §0.3）
2	游戏服放家宽 ⇒ 中继需要 600 Mbps 常驻	档案 107 §S3（300 × 10 KB/s = 24 Mbps/服 × 25 服）
3	presence 是 1000 台下的第一瓶颈（8.2k–16.7k 次/秒）	档案 107 §S2 / §3 / §4
4	平台已有 ETag / 304 短路能力（内容分发的现成基础）	档案 97
5	平台已有崩溃熔断 + 冷却先例（#6 重连治理可复用同一套机制）	档案 78

三、范围

• 改什么：⏳ 未开跑。方案面 = presence 应用层改造 · 游戏服部署规范 · 内容分发三件套 · 中继抖动选路 · 备份窗口治理 · 重连治理 · agent 硬约束 · 每子网打洞并发上限 · 协议版本治理。
• 不动什么：⛔ 官方 dsh 主程序（R2）｜⛔ 不改传输协议（"只做三件事"的硬前提）｜⛔ 本轮不动服务器、不改代码。

四、决策点

已定

1. 🎯 只做三件事 = presence 改造 + 游戏服放 L1 + 块级内容寻址分发（覆盖最大三个瓶颈，且都不需要改传输协议）。
2. 游戏服部署规范 = 游戏服一律部署在有公网 IP 的节点上（零成本，收益最大）⇒ 服主在 NAT 后时主动拨出到骨干、玩家连骨干入口（不是直连服主）。
3. 必须做「块级 + 内容寻址」，⛔ 不要做「包级」 —— 包级（Peer Cache 式）的坑：必须完整下载完才能当 peer 源，版本一变所有 peer 源失效 ⇒ 这正是「版本一发就全量重拉」的风暴成因。
4. ✅ 用户已定：presence 改造走 Slack 官方做法（presence_sub + batch_presence_aware：订阅式扇出 + 只推给"正在看的人" + 本地批合并 + 绑连接生命周期）。
5. ⛔ 禁止 agent 直接触发 agent（只有人的消息能触发）—— 唯一能真正切断指数增长的规则。
6. 明确使用最终一致（presence 允许 5–15 s 陈旧；⛔ 不要为 presence 上强一致）。
7. 落地顺序按「收益 ÷ 成本」排（见 §五）。

未定：agent 限额参数（M / N / 房间上限）取值 —— 需压测标定。

五、步骤（§落地顺序，按「收益 ÷ 成本」；每步自带一次验证）

1. presence 改造（七条落地做法）→ 验证：1000 人大房广播从 ~16,700/s 降到 <2,000/s；进房间首屏 presence 一次 bulk 请求完成（无 N+1）。
2. 游戏服部署规范（放 L1） → 验证：新开服默认落 L1；中继出口带宽与"服数"的关系可预测。
3. 内容分发：块级内容寻址 + 同网段 peer（一次投资治 #3、#5、#9）→ 验证：版本发布时回源字节数 ≈ 1 份 × 组数（不是 1000 份）。
4. 重连治理（指数退避 + 全抖动 + 重试预算 + 令牌桶）→ 验证：拔掉一台中继后 1000 台重连曲线平滑爬升，不是尖峰。
5. 备份抖动窗口 + 低优先级队列 → 验证：备份进行期间聊天与游戏的 p95 延迟不变。
6. jitter 度量与选路（按 jitter 排序，不按 RTT 排序；中继侧 fq_codel/SQM）→ 验证：每连接 jitter 直方图；超阈值自动切路径并告警。
7. agent 配额 + 硬约束 → 验证：注入「回声型 agent」压测，房间消息量有上限、不增长。
8. 每子网打洞并发上限 + 收敛探测 → 验证：同一办公室 20 台同时上线，NAT 不丢线、其他网络不受影响。
9. 协议版本治理（协商 + 灰度 1%→10%→100% + 相邻版本互通 + 内容寻址版本包）→ 验证：各版本节点数与错误率按版本切分可观测。

六、验收

#	口径	期望
A	九条各有判据	每条给出「可复现的验收判据」（本档各节末「验收判据」）
B	presence	<2,000/s（原 ~16,700/s）；首屏 presence 一次 bulk
C	游戏	新开服默认落 L1；中继出口带宽与服数可预测（不随玩家数漂移）
D	内容分发	回源字节 ≈ 1 份 × 组数；局域网内多台设备只回源一次
E	中继	利用率留 30%+ 余量；每连接 jitter 直方图可观测
F	备份	备份期间交互流量 p95 延迟不变
G	agent	回声型 agent 压测下消息量有上限
H	未验证项透明	§未验证项 五条已列全

七、回滚

• 本档自身：零改动 ⇒ 无回滚需要。
• 执行期：九步各自独立可回滚（均为应用层参数/规范/开关，不涉及传输协议变更）⇒ 回滚即还原参数。
• ⚠️ 第 3 步（内容分发）与第 9 步（版本包）共用一套分发机制 ⇒ 回滚须成对评估。

八、回报格式

执行会话回填：① 每步验证命令 + 实际输出（必须含本档各节的验收判据） ② presence 收敛实际降幅 ③ 同网段 peer 命中率 ④ fq_codel 实际效果 ⑤ agent 限额参数标定值 ⑥ commit ⑦ 未完成项与卡点。

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

presence 收敛的实际降幅（业界口径可达 5×–8×，需实测）｜中继链路的 jitter 分布（决定能否支撑游戏，最该先测）｜同网段 peer 命中率（决定 10.8 GB 能压到多少，需实测）｜fq_codel 在本环境中继上的实际效果（需实测）｜agent 限额参数（M / N / 房间上限）取值（需压测标定）。

---

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

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

日期：2026-09-16 ｜ 性质：落地解决方案（承接 覆盖网络_千台全场景推演_20260916.md 的瓶颈排序） 参考来源：Slack 官方 API 文档、Microsoft SCCM / BranchCache / Delivery Optimization 官方文档、presence 系统工程实践（详见各节"参考实现"） 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

---

总览：九个瓶颈 × 落地手段

#	瓶颈	量级	核心手段	成本
1	presence	8.2k–16.7k 次/秒	订阅式扇出 + 本地批合并 + 绑连接生命周期	低（纯应用层）
2	游戏服放家宽	600 Mbps 常驻	部署规范：游戏服一律放有公网 IP 的节点	零
3	首屏包冷启动	10.8 GB/次	块级内容寻址 + 同网段 peer 优先	中
4	中继抖动	需 <20 ms	按抖动选路 + 中继限载 + fq_codel	中
5	备份窗口挤占	136 Mbps	抖动窗口 + 低优先级队列	低
6	重连风暴	160 / 1000 并发	全抖动退避 + 重试预算 + 令牌桶	低
7	agent 自激	指数级	禁止 agent 触发 agent + 独立配额	低
8	NAT 表溢出	整屋掉线	每子网打洞并发上限 + 收敛探测	低
9	版本碎片	—	协议协商 + 灰度 + 内容寻址版本包	中

---

1. presence（最高优先，收益/成本比最好）

落地做法（七条，均有成熟先例）

1. presence 绑到连接生命周期，不要轮询 —— WebSocket 连上 = 在线、断开 = 离线；存储带 TTL 只作安全网（防网关崩溃漏事件）。彻底干掉"每 30 s 全员轮询"。
2. 本地批合并 + pipeline 刷写 —— 每个网关把本地心跳攒起来，每 1 s 一次 pipeline 提交。 业界的量级对照：10 万连接 × 0.2 心跳/s = 2 万条命令/秒 ⇒ 合并后变成 1 次 pipeline/秒（数量级差异）。
3. 订阅式扇出：只推给"正在看的人" —— 用户打开某个聊天/名单才订阅该用户的 presence，订阅只活在连接期间。 这是 Slack 官方做法（presence_sub + batch_presence_aware），也是它们把 presence 流量降下来的关键。
4. 批量事件 + 节流 —— 一条消息里带 user 数组（不是逐个 user）；最多每几秒推一批。
5. grace period 5–15 s + 离线 debounce 30 s —— 防止"网络抖一下 = 状态闪烁"，把短暂断连合并掉。
6. 多设备按 device 聚合 —— 任一设备在线即在线；重连后必须重新拉一次全量（否则状态陈旧）。
7. 明确使用最终一致 —— 允许 5–15 s 陈旧。⛔ 不要为 presence 上强一致（会毁掉吞吐，且业务上不需要）。

大房（≥1000 人）的特殊策略

• 只推 在线 / 离线（不推 idle、不推 typing）；按百分比抽样降频（如每 10 s 一轮）；
• 打开房间用 一次 bulk 查询拿全量，之后只增量。

参考实现

Slack 官方 changelog（batch presence + presence subscriptions）、Redis TTL + pub/sub 的 presence 标准设计、WebSocket 生命周期作为 presence 信号。

验收判据

• 1000 人大房的 presence 广播次数 从 ~16,700/s 降到 <2,000/s；
• 进房间首屏 presence 一次 bulk 请求完成（无 N+1）。

---

2. 游戏服放哪（零成本，收益最大）

落地做法

1. 部署规范：游戏服一律部署在有公网 IP 的节点上（= 骨干层）⇒ 玩家直连，中继承载 0。
2. 服主确实在 NAT 后时：服主动拨出到骨干，玩家连骨干入口（不是直连服主）—— 把中继点从"服主机器"搬到"骨干"，并让骨干做流量聚合。
3. 错峰 + 配额：攻城战高峰用按服限额，并提前公告时段。
4. 容量按 45% 设计、55% 留余量；骨干池 ≥ N+1。

验收判据

• 新开服默认落 L1；
• 中继出口带宽与"服数"的关系可预测（而不是随玩家数漂移）。

---

3. 首屏包冷启动（10.8 GB）—— 照抄内容分发三件套

落地做法（直接照搬 SCCM 的内容源优先级）

1. 内容源优先级（改成我们的版本）： 本地磁盘 → 同局域网 peer → 同区域边缘缓存 → 区域分发点 → 公网源 （原版优先级顺序见 Microsoft 官方文档，结构一致）
2. 必须做"块级 + 内容寻址"，不要做"包级" —— 这是 BranchCache vs Peer Cache 的关键分水岭：
   • 块级（BranchCache 式）：按哈希标识块、与文件无关 ⇒ 只拿到一部分也能开始共享；内容更新时只传变化的块；
   • ⚠️ 包级（Peer Cache 式）的坑：必须完整下载完才能作为 peer 源；版本一变所有 peer 源全部失效，客户端会集体回源 ⇒ 这正是"版本一发就全量重拉"的风暴成因。
3. 客户端校验哈希，不匹配就丢弃（Delivery Optimization 的做法）。
4. 分组：按"用户 / 团队 / 局域网"分组共享（对应 DO 的 group mode），避免跨组乱穿透。
5. 同网段优先广播发现（BranchCache 在子网内广播哈希找 peer）。
6. 已加载走 304（平台已有此能力）。

验收判据

版本发布时回源字节数 ≈ 1 份 × 组数（而不是 1000 份）；局域网内多台设备只回源一次。

---

4. 中继抖动（游戏可玩性的真正门槛）

落地做法

1. 把 jitter 做成一等指标 —— 持续采样 RTT 与 jitter（RTT 方差），选路按 jitter 排序，不按 RTT 排序。
2. 抑制 bufferbloat —— 中继侧启用 fq_codel / SQM 类队列管理；排队延迟是抖动最大的来源。
3. 路径多样性 —— 每连接维护 2–3 条候选（直连 / 就近中继 / 备用中继），抖动劣化即切。
4. 中继不要打满 —— 利用率留 30%+ 余量；打满必然抖动爆炸。
5. 就近接入 —— 骨干用 BGP 多线 / 就近节点（业界口径：BGP 多线可把跨网延迟压到 20 ms 内）。

验收判据

每连接的 jitter 直方图；超阈值自动切路径并告警。

---

5. 备份窗口挤占

1. 抖动窗口：200 台备份起点随机散布到 2–3 小时（cron + 随机 sleep），把 136 Mbps 尖峰摊平。
2. 低优先级队列：备份/同步走 background 类（fq_codel 的 background 档，或 LEDBAT 式延迟敏感型拥塞控制）⇒ 交互流量优先。
3. 双层限速：每台上限 + 全网上限。
4. 只备不可再生 + 增量去重 + 上传前加密（沿用备份三层方案）。
5. 上传走各自到对象存储的路径，不走中继。

验收判据

备份进行期间，聊天与游戏的 p95 延迟不变。

---

6. 重连风暴（160 / 1000 并发）

1. 指数退避 + 全抖动（full jitter） —— 关键结论：没有抖动，退避会同步化，等于没退。
2. 重试预算（retry budget） —— 限制"重试流量 / 正常流量"比例（如 10%），超预算就停止重试。
3. 控制面令牌桶 + 排队 + 明确的 429/Retry-After。
4. 数据面不依赖控制面 —— 已建立的连接在控制面重启时不受影响。
5. 熔断 + 冷却（平台已有崩溃熔断先例，可复用同一套机制）。

验收判据

拔掉一台中继后，1000 台的重连曲线是平滑爬升，不是尖峰。

---

7. agent 自激（本方案独有的放大源）

1. 禁止 agent 直接触发 agent —— 只有人的消息能触发 agent 发言。这是唯一能真正切断指数增长的规则。
2. 每 agent 每 N 分钟最多 M 条 + 发言后静默期。
3. 房间级 agent 数上限（建议 ≤ 房间人数 / 10）+ 房间级总速率上限。
4. agent 独立配额池（不与人共享额度，避免 agent 挤掉真人）。
5. 观测：agent 发言占比告警。

验收判据

注入一个"回声型 agent"做压测，房间消息量有上限、不增长。

---

8. NAT 表溢出

1. 每 NAT / 每子网的打洞并发上限（按该 NAT 的会话数能力推算）。
2. 收敛探测 —— 禁止所有设备同时打同一目标；加随机延迟 + 指数退避。
3. 同网段优先本地发现（mDNS 式）⇒ 压根不走 NAT。
4. 打洞失败即降级中继，不重试（与 #6 共用机制）。

验收判据

同一办公室 20 台同时上线，NAT 不丢线、其他网络不受影响。

---

9. 版本碎片

1. 协议版本协商 + 严格递增（防降级攻击）。
2. 灰度：1% → 10% → 100% 分批。
3. 相邻版本必须互通（客户端 N 与 N-1 必须能对话）。
4. 版本包走内容寻址（与 #3 共用一套分发机制）。
5. 观测：各版本节点数与错误率按版本切分。

---

落地顺序（按"收益 ÷ 成本"排）

序	动作	为什么排这里
1	presence 改造	唯一的第一瓶颈，且是纯应用层改动，不动协议
2	游戏服部署规范（放 L1）	零成本，直接消掉 600 Mbps
3	内容分发：块级内容寻址 + 同网段 peer	一次投资同时治 #3、#5、#9
4	重连治理（退避 + 全抖动 + 重试预算 + 令牌桶）	低成本，防事故
5	备份抖动窗口 + 低优先级队列	低成本
6	jitter 度量与选路	决定游戏可玩性
7	agent 配额 + 硬约束	本方案独有风险
8	每子网打洞并发上限	低成本
9	协议版本治理	随规模推进

如果只做三件事

presence 改造 + 游戏服放 L1 + 块级内容寻址分发 —— 这三件覆盖了最大的三个瓶颈，且都不需要改传输协议。

---

未验证项

#	项	状态
1	presence 收敛的实际降幅（业界口径可达 5×–8×）	⚠️ 需实测
2	中继链路的 jitter 分布（决定能否支撑游戏）	⚠️ 最该先测
3	同网段 peer 命中率（决定 10.8 GB 能压到多少）	⚠️ 需实测
4	fq_codel 在本环境中继上的实际效果	⚠️ 需实测
5	agent 限额参数（M / N / 房间上限）取值	📋 需压测标定