2265 字
约 7 分钟
6
S23-J32 · 广域网、无线与端边云部署

适用读者:要做跨地域服务、要解释"链路 333 Mbit/s 却要 1 秒"、要判断集中部署还是就近部署的人。
前置:S23-J31(端到端公式)、J20–J21(网络与拥塞)。
覆盖旧文:A-4345 §12.3–§12.5(广域网额外开销 + 无线变化与恢复 + 端边云分工,382 点)→ 382 点。
扩展点:E-S23-118(B_useful ≤ min(B_path, W/R):64 KB / 100 ms = 5.1 Mbit/s → 30 MB 要 47 s)、E-S23-119(慢启动:4 轮 219 KB、5 轮 452.6 KB)、E-S23-120(跨地域语音:理想 238.5 ms vs 直接 >1 s vs Queqiao 约 300 ms)、E-S23-121(无线共享空口与"过期数据必须能取消")。
上一篇:S23-J31 · 端到端交互时间
下一篇:系列收尾(S23 v2 验收)。


1. 一句话结论

跨地域短请求的时间不由带宽决定,由"往返次数"决定。 355 KB 音频、333 Mbit/s、RTT 200 ms:理想 238.5 ms(8.5 发送 + 200 传播 + 30 处理),实测直接调用 >1 秒,优化后约 300 ms——差的全是连接建立、窗口增长与丢包恢复。

出处:AI Infra 教材 §12.3–§12.5(id 4345),实测路径贵阳→美国 Irvine。

B_useful ≤ min(B_path, W/R)

2. 连接建立与复用(§12.3.1)

阶段 代价 复用能省
TCP 握手 1 RTT ✅
TLS 握手 1–2 RTT ✅(会话恢复更少)
慢启动 多轮翻倍 部分(可调初始窗口)
首字节 传播 ❌(物理下界)

判据:短请求的时间预算里,握手可能是最大项。 跨地域 RTT 200 ms 时,两次握手就是 400 ms——比模型处理(30 ms)大一个量级。


3. 窗口:链路的"节流阀"(E-S23-118)

B_useful ≤ min(B_path, W/R)

本算例:20 Mbit/s 路径、RTT 100 ms,要持续填满需在途 20e6/8 × 0.1 = 250 KB。

窗口 有效吞吐 30 MB 需要
64 KB 64,000/0.1 = 640,000 B/s ≈ **5.1 Mbit/s** 约 47 s
250 KB 20 Mbit/s 12 s
整批确认模型:发送 25.6 ms + 反馈 100 ms = 125.6 ms/批
链路空着的时间,是发送方在等 ACK —— 提物理带宽只缩短那 25.6 ms

判据:"链路有带宽"和"用得上带宽"是两件事。 长肥管道(高 RTT × 高带宽)必须靠大窗口或并行流。

3.1 慢启动:短请求可能死在爬坡期(E-S23-119)

初始窗口 10×1460 = 14,600 B,每轮翻倍
4 轮累计:14,600×(1+2+4+8) = 219,000 B
5 轮累计:452,600 B

355 KB 的语音请求要到第 5 轮才发完。 RTT 200 ms → 几轮反馈就是几百毫秒。

优化 效果
增大初始窗口 少爬 1–2 轮
连接预热/复用 跳过握手与慢启动
多流并行 用多条连接绕过单窗口上限
前向纠错(FEC) 不丢包就不用等重传

4. 丢包不等于拥塞(§12.3.3)

现象 传统反应 更好做法
随机丢包(无线/光衰) 降速(当拥塞) 区分:FEC/重传,不降窗
真拥塞(队列增长) 降速 ✅ 降速
乱序 当丢包重传 按序重组

判据:把"丢包"一律当"拥塞",在无线和长距离链路上会误降速。 这是 J21 拥塞模型的延伸:λ>B 才是拥塞,丢包只是证据之一。


5. 案例:Queqiao 的优化组合(E-S23-120)

Queqiao:开源可自托管,在可控客户端与可信网关之间承载 TCP/UDP;应用通过本地 SOCKS5 接入。

理想:8.5 ms(355 KB @333 Mbit/s) + 200 ms(RTT) + 30 ms(模型) ≈ 238.5 ms
直接调用:> 1 s
Queqiao:约 300 ms
手段 解决什么
连接复用 握手 RTT
共享路径测量与传输状态 多流协同、不各自慢启动
发送调度 交互流优先于大文件
FEC 不丢包就免一轮重传
按路径安排恢复 减少等待 RTT

判据:传播距离无法消除(200 ms 是物理下界)。优化只能削掉"额外的往返次数"——本项目把 1 s 削到 300 ms,剩下的就是 238.5 ms + 协议余量。


6. 无线:共享空口与过期数据(E-S23-121)

特性 影响 对策
空口共享 上下行争用、邻居干扰 调度优先级、错峰
时变带宽 瞬时吞吐波动大 自适应码率、缓冲
数据会过期 迟到的帧已无价值 必须能取消(J21 的取消语义)
双路径 Wi-Fi + 蜂窝 分流/热切换,避免双发浪费

判据:实时交互里"过期的正确数据"等于错误数据。 系统必须支持"取消在途请求",否则恢复出来的结果已经没用。

双路径的两个坑:① 两条都发 → 浪费上行、可能加剧拥塞;② 切换时状态不一致 → 需要序号/版本对齐。


7. 端边云:集中还是就近(§12.5)

维度 集中(少数大 DC) 就近(边缘)
加速器利用率 高(集 batch) 低(各地预留)
单位成本 低 高
网络延迟 高(跨地域 RTT) 低
运维复杂度 低 高(多站点)
适用 吞吐优先、可容忍延迟 强实时、语音/交互

判据:"集中部署省成本"成立的前提是"优化后的延迟仍满足业务期限"。 本案例:集中后 300 ms 可接受 → 集中;若业务要求 150 ms → 200 ms 的传播就已经不可能,必须就近。

7.1 部署决策清单

# 问题 不通过
1 业务期限是多少(p95 端到端) 未定义就无法选
2 传播下界(RTT/2)占多少 超期限 → 必须就近
3 短请求的握手/慢启动能否复用掉 不能 → 延迟不可控
4 丢包会不会被误当拥塞 会 → 无线场景降速
5 过期数据能否取消 不能 → 恢复无意义
6 集中带来的利用率收益 vs 延迟代价 收益 < 损失 → 就近

8. 可复算(实测)

$ cd /root/博客运营官/blog-v2 && python3 tools/s23_book_calc.py | tail -10
图片: 12.0 上传 + 0.1 RTT + 0.3 处理 + 0.4 下行 = 12.8 s
压缩省 15 MB: 20 Mbit/s → 6.0 s;100 → 1.2 s;800 → 0.15 s(= T_e,交叉点 800 Mbit/s)
分块流水: 12 + 0.1 + 0.16 + 2×0.05 = 12.36 ≈ 12.4 s(只省 0.4)
语音: 960 B/块;块 1 就绪 20 / 处理 32 / 发 33 / 到 38 / 播 78
  第 3 块传播 50 ms → 到达 123 ms > 118 ms(晚 5 ms,全体顺延)
窗口: W=64 KB, R=0.1 s → 5.1 Mbit/s(路径 20);30 MB 需 47 s
  填满需 250 KB 在途;整批确认 25.6 ms + 100 ms = 125.6 ms/批
慢启动: 10×1460 B,4 轮 219,000 B;5 轮 452,600 B(355 KB 需 5 轮)
跨地域语音: 8.5 + 200 + 30 = 238.5 ms(理想);直接 >1000 ms;优化后约 300 ms

9. 前提与边界

结论 成立条件 不成立时
B_useful ≤ W/R 单流、无并行 多流 → 叠加
慢启动 5 轮 初始 10 段、每轮翻倍 初始窗口更大 → 更少
传播是下界 光速/路由不变 更近的 PoP → 下界降低
集中部署可行 优化后仍满足期限 期限紧 → 就近

10. 常见误区

误区 纠正
"333 Mbit/s 就该 8.5 ms" 200 ms RTT 是下界
"带宽够就不慢" 窗口 64 KB 只有 5.1 Mbit/s
"丢包就是拥塞" 无线丢包不该降窗
"流量大就多开流" 交互流要调度,不是硬抢
"边缘一定更好" 利用率低、成本高

11. 自测

  1. RTT 100 ms、窗口 64 KB,有效吞吐多少?传 30 MB 多久?
  2. 初始窗口 14,600 B 每轮翻倍,4 轮累计多少?
  3. 355 KB、333 Mbit/s、RTT 200 ms、处理 30 ms,理想时间多少?
  4. 什么情况下必须就近部署?
答案
  1. 640,000 B/s ≈ 5.1 Mbit/s;约 47 s。
  2. 219,000 B(第 5 轮 452,600 B)。
  3. 8.5 + 200 + 30 = 238.5 ms。
  4. 业务期限小于"传播下界 + 必要处理"时。

12. 系列收尾

这是 S23 教材细讲的第 28/28 篇。整个系列的入口、分层与依赖见 README.md,全量点位见 coverage.csv,验收结论见 acceptance.md。

S23-J32 · 广域网、无线与端边云部署
https://www.clxhxhhr.top/posts/5559/
作者
clxstart
发布于
2024-12-31
许可协议
CC BY-NC-SA 4.0
评论
0 条
还没有评论,先写一条吧。