9.5 动态加速
一句话
动态内容不能缓存，所以动态加速优化的不是 “内容”，而是 路径：就近接入、连接复用、协议优化、回源走骨干——它把 “每次都要跨半个中国握手” 变成 “在离用户 20ms 的节点上复用一条已建好的连接”。
动态请求的时间都花在哪
| 阶段 | 典型耗时（跨境） | 可优化点 |
|---|---|---|
| DNS + TCP + TLS 建连 | 300–600ms（3 个 RTT 起） | 就近接入、会话复用、TLS 1.3 |
| 请求上行 | 100–200ms（含丢包重传） | 骨干网回源、减少往返 |
| 源站处理 | 20–200ms | 不是 CDN 的活 |
| 响应下行 | 100–200ms | 压缩、HTTP/2 多路复用 |
结论：跨境访问的主要成本是 “建连 + 往返次数”，不是带宽。动态加速的收益也主要来自这两项。
六种手段，按性价比排
| 手段 | 做什么 | 收益量级 | 代价 |
|---|---|---|---|
| 就近接入 | 用户连到最近的 PoP | 省 100–300ms | 需要节点覆盖 |
| 连接复用 | 边缘到源站保持长连接池，请求不再逐次握手 | 省 1–2 个 RTT/请求 | 源站要能承受长连接 |
| TLS 1.3 + 会话复用 | 1-RTT，恢复会话可 0-RTT | 省 1 个 RTT | 0-RTT 只限幂等请求（见 8.6 TLS 握手、证书与 mTLS） |
| 协议升级（HTTP/2、HTTP/3） | 多路复用、减少队头阻塞 | 高并发下明显 | 需要端到端支持 |
| 路由优化（专线/骨干） | 回源走高质量链路，绕开公网拥塞 | 丢包高时收益最大 | 成本高，按需购买 |
| 压缩与合并 | gzip/br + 合并小请求 | 减少字节数与请求数 | CPU；合并要防过度耦合 |
一条经验：先测 “建连时间 vs 源站处理时间” 的占比。建连占大头 → 做连接复用与就近接入；源站占大头 → 动态加速帮不上，先优化应用。
与 “专线 / SD-WAN” 的区别
| 方案 | 优化的是 | 适合 | 成本 |
|---|---|---|---|
| 动态加速（CDN） | 公网路径 + 边缘接入 | 面向海量公网用户 | 按流量/请求 |
| 专线 / SD-WAN | 固定两点之间的链路 | 总部与云上 VPC、跨地域内网 | 按月带宽，贵 |
| 全站加速（含静态） | 静态缓存 + 动态链路 | 混合站点 | 按流量 |
三者不互斥：面向公网用户用 CDN 动态加速，内部系统互联用专线。
指标：只看 TTFB 会误判
| 指标 | 含义 | 目标 |
|---|---|---|
| 建连时间（DNS+TCP+TLS） | 动态加速最该压的 | 复用后接近 0 |
| TTFB | 到首字节 | 跨境 < 200ms 已属良好 |
| 回源 RTT / 重传率 | 边缘到源站链路质量 | 重传 < 0.1% |
| 尾延迟 P99 | 丢包与拥塞的体感 | 与 P50 差距越小越好 |
只看平均值会被 “一半请求走了缓存、一半没走” 稀释，动态加速必须按 P95/P99 + 地域 + 运营商 分维度看。
反模式
| 反模式 | 后果 |
|---|---|
| 把动态接口也缓存来 “提速” | 越权泄露或脏数据（见 9.3 缓存键设计） |
| 只买 “加速” 不看建连占比 | 花在优化错误的地方 |
| 回源不做连接池 | 每个请求都重连，加速收益被抵消 |
| 对写请求开 0-RTT | 重放导致重复提交 |
| 忽略 Cookie/鉴权透传 | 加速后登录态丢失，表现为 “随机掉线” |
| 用平均 TTFB 验收 | 掩盖长尾；用户投诉的正是 P99 |
三条铁律
🔑 动态加速买的是 “路径与连接”，不是 “缓存”；不缓存是它的前提，不是缺陷。
🔑 先压建连，再压往返；建连不复用，其他优化都是小数。
🔑 验收看 P95/P99 与地域维度，平均值会骗人。
自检
Q1 跨境 API 的 TTFB 是 700ms，怎么判断该不该买动态加速？
▸ 答案：先拆时间：建连（DNS+TCP+TLS）占多少、回源往返占多少、源站处理占多少。若建连 + 往返占 70% 以上，动态加速（就近接入 + 连接复用 + 骨干回源）通常能把 TTFB 压到 200–300ms；若源站处理占大头，加速只能省下小头，应先优化应用与数据库。
Q2 为什么 “回源连接池” 是动态加速里最容易被忽略的一环？
▸ 答案：因为每个动态请求都要回源一次，如果边缘与源站之间每次都新建连接，就要重复付 TCP + TLS 的 2–3 个 RTT，跨境场景下每次多 300ms 以上，加速收益被抵消。保持长连接池（并配健康检查与超时）才能把 “省下的建连” 真正留住。
Q3 动态加速能替代专线吗？
▸ 答案：不能，两者优化对象不同。动态加速优化 “海量公网用户到边缘” 的路径，出口仍是公网；专线优化 “两个固定点之间” 的链路质量（低丢包、可预测延迟），适合总部-云、跨地域内网。对外服务用 CDN，内部互联用专线，是常见组合。
Q4 上了动态加速，为什么 P99 反而变差？
▸ 答案：常见三种原因：① 多了一跳，边缘到源站链路质量差时尾延迟放大；② 回源连接池过小，高并发时排队；③ 边缘节点回源绕路（调度就近但回源不就近）。诊断看 “边缘到源站的 RTT 分地域” 与 “回源队列等待时间”，而不是只看整体 TTFB。
Q5 什么情况下不该用动态加速？
▸ 答案：用户与源站本来就在同一区域（收益 < 20ms）、或流量极小（固定成本摊不平）、或数据合规要求请求不得经过第三方节点。判断依据仍是 “建连与往返在总耗时中的占比”，而不是 “有没有这个产品”。
跨篇相关：缓存命中与回源的原理见 9.1 边缘缓存原理；回源链路与限速见 9.2 回源策略与回源率；TLS 握手与复用见 8.6 TLS 握手、证书与 mTLS；HTTP/2 与 HTTP/3 的连接复用见 8.5 HTTP/1.1、HTTP/2、HTTP/3 (QUIC)；长连接与重连见 8.11 长连接与 WebSocket；CDN 的整体组成见 9.0 CDN 全景：它到底是什么。