全球加速：跨境链路延迟优化实战

出海系统最扎心的往往不是代码慢，而是物理距离：服务端优化到极致，用户还是觉得慢。这篇把跨境链路的延迟从哪来、怎么测、怎么优化一次讲透——沿用系列案例：中国访问美西系统，首屏 3.2s → 0.8s，接口 P99 1200ms → 180ms。

先给结论：同一次请求，直连公网是 200ms RTT、±50ms 抖动、2% 丢包；换成「就近接入 + 云骨干网」后是 80ms RTT、±5ms、0.1% 丢包。加速的本质不是让数据跑得更快，而是让它少绕路、少折返。

一、先算物理账：有些延迟优化不掉

光在光纤里的速度约为真空的 2/3（约 20 万 km/s），这是所有优化的天花板：

两个直接推论：

1. 物理下限决定了：中国到美西的接口，无论怎么优化，一去一回至少 100ms。谁承诺"美西机房做到 30ms RTT"，要么就近有边缘节点，要么在骗你；
2. 减少往返次数 > 优化单次往返。RTT 是乘法因子——串行 6 次往返就是 6×RTT，把 6 次并成 1 次，比把线路提速 50% 收益大得多。

二、拆解一次跨境请求：服务端只占 7%

很多人埋头优化服务端代码，却不知道时间都花在哪。看一次真实的跨境请求拆解：

1400ms 里，服务端处理只有 100ms（7%），剩下 93% 全是网络：DNS 解析 220ms、TCP 握手 200ms、TLS 握手 400ms、上下行传输 480ms。把服务端优化到 0ms，也只能省 7%——这就是跨境场景和单机优化的根本区别。

逐段说怎么压：

• DNS 解析（220ms）：跨境递归查询尤其慢。用 HTTPDNS / 长缓存 + 客户端 dns-prefetch 预解析，能压到几十 ms；
• TCP + TLS 握手（600ms）：这是重头，第四章专门讲；
• 上下行传输（480ms）：压缩、精简响应体、图片走 CDN，见第六章。

和第一篇《接口优化》对照着看：单机场景 93% 的时间在数据库和外部调用；跨境场景 93% 的时间在路上。优化对象变了，方法论不变：先测量，抓大头。

三、五层加速方案：从边缘到数据

完整的加速体系分五层，按"离用户越近收益越大"排序：就近接入层（CDN/Anycast）→ 传输协议层（TLS1.3/HTTP2/HTTP3）→ 网络专线层（云骨干/跨境专线）→ 边缘计算层（边缘函数）→ 应用层（聚合/压缩/预连接）；数据层单独一列：多区域只读副本，读就近、写回主。

落地优先级建议（性价比从高到低）：

1. 静态资源全量上 CDN——成本最低、见效最猛，一天就能上；
2. 协议升级 TLS1.3 + HTTP/2——改配置就行，白捡的提速；
3. 接口聚合 + 压缩——改应用代码，中等成本；
4. 边缘函数——把鉴权、签名这类轻逻辑放到边缘，请求不用回源；
5. 专线/全球加速——花钱买确定性，最后一招，见第五章。

四、协议层：少跑几个来回，比跑得快更有效

在 200ms RTT 的链路上，光是握手就能差出 3 倍时间：

四行时序对比一目了然：TCP+TLS1.2 要 3 个来回（600ms），TLS1.3 省 1 个（400ms），QUIC 首次连接 1 个来回（200ms），连接复用直接 0-RTT（0ms）。同样的服务器，仅仅是协议升级，每次建连就省 3 倍时间。

服务端 Nginx 一段配置就能吃到前两档红利：

server {
    listen 443 quic reuseport;          # HTTP/3 (QUIC)
    listen 443 ssl;
    http2 on;                            # HTTP/2 多路复用
    ssl_protocols TLSv1.3;               # TLS 1.3：握手 2 RTT -> 1 RTT
    ssl_early_data on;                   # 0-RTT（配合 QUIC）
    brotli on;                           # Brotli 压缩，比 gzip 再省 20% 体积
}

客户端配合两件事：

// OkHttp：连接池 + HTTP/2，让多个请求共用一条已握手的连接
OkHttpClient client = new OkHttpClient.Builder()
        .connectionPool(new ConnectionPool(5, 5, TimeUnit.MINUTES))  // 长连接复用
        .protocols(List.of(Protocol.HTTP_2, Protocol.HTTP_1_1))
        .connectTimeout(3, TimeUnit.SECONDS)   // 跨境超时要按 RTT 设置，见第六章
        .build();

注意：HTTP/2 多路复用解决的是「并行」，但在丢包率高的跨境链路上存在 队头阻塞——一个包丢了，整条连接的所有流都得等。这正是 HTTP/3（QUIC 基于 UDP）要解决的问题：流之间独立丢包恢复。跨境场景，QUIC 的收益远大于内网场景。

五、网络层：专线该不该买，怎么算账

云厂商的「全球加速 / Global Accelerator」本质是：Anycast 就近接入 + 骨干网专线回源，让流量避开拥堵的公网。

决策口径一句话：按「这条链路上跑的业务，1ms 值多少钱」来算。下单、支付、风控这类实时交互链路，超时率和抖动直接等于丢单，值得上加速；报表拉取、日志回传，公网多等几百毫秒无所谓，不用花这个钱。

六、应用层：不改网络也能省一半

网络方案要花钱花时间，应用层的手段当天就能上线：

1. BFF 接口聚合——把 6 次往返变 1 次

// 页面原来串行调 6 个接口 = 6 × 200ms = 1200ms
// BFF 网关聚合为 1 个接口，内部并行取数 = 200ms + max(内部耗时)
@GetMapping("/api/page-data")
public PageData getPageData(@RequestParam long userId) {
    CompletableFuture<User>    u = supplyAsync(() -> userService.get(userId));
    CompletableFuture<List<Order>> o = supplyAsync(() -> orderService.recent(userId));
    CompletableFuture<Notice>  n = supplyAsync(() -> noticeService.latest());
    return assemble(u.join(), o.join(), n.join());   // 1200ms -> ~300ms
}

2. 响应瘦身：字段按需返回、Brotli 压缩、列表接口分页懒加载。跨境带宽贵，每省 1KB 都是真金白银的 RTT。

3. 预热连接：页面加载时对关键域名发 preconnect，把 DNS/TCP/TLS 握手提前到用户点击之前完成。

4. 数据就近：多区域部署只读副本，读请求就近走本地、写请求回主区域。配合上一篇讲的统一适配层，业务代码几乎不用改。

5. 超时要按 RTT 重设：跨境链路 RTT 200ms，客户端超时还设 1s 的，一次网络抖动就误杀。经验值：连接超时 ≥ 2×RTT，读超时 ≥ 3×RTT + 服务端 P99。

七、效果对比：3.2s 是怎么变成 0.8s 的

【配图位置 ⑤：放在收尾章节】 各手段叠加后的实测：TTFB 680ms→120ms（-82%）、首屏 3.2s→0.8s（-75%）、接口 P99 1200ms→180ms（-85%）、超时率 3.2%→0.1%（-97%）。

各手段贡献占比（也是动手顺序）：

📎 延伸：文中提到的跨境平台数据接口（1688 跨境、淘宝海外等），可直接通过 万邦开放平台接口注册入口 申请试用——出海业务的第一公里数据打通，从拿到 Key 开始。

实测方法提醒（呼应上一篇《压测》）：跨境延迟必须用目标地区的探测点测（云厂商多地域拨测、或真实用户 RUM 上报），在自己办公室 ping 出来的数字没有代表性——你的出口线路和用户的不一样。

八、跨境加速自查清单（发版前过一遍）

【测量】用目标地区探测点/RUM 建立优化前基线？
【DNS】HTTPDNS 或长缓存？关键域名 preconnect？
【协议】TLS1.3 + HTTP/2 已开启？条件允许上 HTTP/3？
【连接】客户端连接池 + 长连接复用？队头阻塞评估过？
【聚合】页面串行请求是否合并为 BFF 单接口？
【体积】Brotli 压缩？图片 webp/avif？响应按需裁剪？
【就近】静态全量 CDN？数据只读副本读就近？
【超时】连接/读超时按 RTT 重新标定？
【专线】实时链路是否值得上全球加速？算过账吗？

写在最后：跨境优化的思维转变只有一句话——别再只盯服务端，链路上的每个来回都是钱。先测量定位（延迟构成拆解），再按五层方案从性价比最高的动手，最后用目标地区的探测数据验证