腾讯云 EdgeOne vs 阿里云 ESA：国内 CDN 访问性能与全链路实测对比

1. HTTP/2 协议支持差异（关键瓶颈）#

在现代 Web 站点中，页面通常伴随大量的 CSS、JS Chunk 以及图标资源（以本站 Next.js 首页为例，包含 HTML + 17 个静态资源，压缩传输约 417 KB）。

我们通过 openssl s_client 抓取客户端声明 h2,http/1.1 时的 ALPN 协商结果：

1
# EdgeOne 实测
2
$ openssl s_client -connect www.antwen.cn:443 -servername www.antwen.cn -alpn 'h2,http/1.1'
3
Protocol: TLSv1.3
4
ALPN protocol: h2
5

6
# ESA 实测
7
$ openssl s_client -connect web-esa.antwen.cn:443 -servername web-esa.antwen.cn -alpn 'h2,http/1.1'
8
Protocol: TLSv1.3
9
ALPN protocol: http/1.1

• EdgeOne 顺畅协商到 HTTP/2：浏览器在一条 TCP 连接上即可多路复用并发加载所有 Chunks，因此整页并发加载耗时压缩在 406 ms。
• ESA 回落到了 HTTP/1.1：在 HTTP/1.1 协议下，浏览器对同域名的并发连接数被严格限制在 6 个左右，后续资源必须在队列中等待排队（Head-of-Line Blocking）。这就是为什么在串行测试中 ESA 更快，但在真实并发测试中 EdgeOne 反超近 32% 的根本原因。

2. 回源稳定性与长尾延迟（522 报错分析）#

在累计 180 次的动态请求交错压力测试中：

• EdgeOne 表现出极高的工业级可用性，0 失败，P95 延迟仅 624 ms。
• ESA 出现了 8 次 HTTP 522 (Origin Connection Timeout)，并且出现过单次耗时达到 6.5s 以上的严重尾部卡顿。

1
HTTP/1.1 522 Origin Connection Timeout
2
Server: ESA
3
Date: ...
4
EagleId: df6d04ad...

522 状态码表明 ESA 的边缘边缘节点在尝试连接源站（Next.js Origin Server）时发生握手超时。这可能是由于 ESA 的回源链路在高峰期路由绕行，或是其默认的回源超时与探测阈值设置过于敏感所致。

3. 全国多省各运营商 DNS 调度策略#

我们模拟了全国不同省份运营商的 LocalDNS 进行解析查询，两者的调度架构体现了不同的思路：

1
# 湖北电信 LocalDNS (202.103.24.68)
2
- EdgeOne: (调度至就近统一节点池)
3
- ESA    : 171.43.203.139 ~ 142 (精确下发湖北武汉/狮子山电信原生 IP)
4

5
# 北京联通 LocalDNS (202.106.0.20)
6
- EdgeOne: 123.6.40.77 (河南郑州联通节点)
7
- ESA    : 125.39.155.85 ~ 88 (天津联通就近节点)
8

9
# 北京移动 LocalDNS (211.136.17.107)
10
- EdgeOne: 211.136.106.223 等多省移动 IP 混合下发
11
- ESA    : 下发 112.51.127.239 (移动核心节点池)

• 阿里云 ESA 的调度粒度更加精细，做到了严格的「同省/邻省 + 同运营商精准匹配」（电信用户直连电信机房，联通用户直连联通机房）。
• EdgeOne 倾向于依靠更庞大的 Anycast/混合多 IP 轮询调度池，虽然单次下发的 IP 列表中偶有跨省节点，但客户端往往能在其中自适应选择低延迟链路。

1. 生产环境策略：推荐以 EdgeOne 为主，ESA 为备用#

• 主流量承载：继续由 EdgeOne（www.antwen.cn）承载，其 HTTP/2 完备性、高可用性（0 报错）与优异的并发加载性能能够为大众用户提供最稳妥的体验。
• 灾备与灰度：将 ESA 作为副节点或降级容灾线路保留。

2. 检查并开启 ESA 的 HTTP/2 开关#

如果希望进一步发挥 ESA 的极速单点吞吐优势，建议前往 阿里云 ESA 控制台：

• 进入站点配置 -> 网络优化 / 协议配置。
• 确认是否已开启 HTTP/2 及 HTTP/3 (QUIC) 支持。
• 检查回源配置，适当放宽 回源超时时间 并配置源站持久连接（Keep-Alive），以消除 522 超时问题。

3. 架构优化收益：开启边缘缓存（ISR / SWR）#

在本次测试中，站点的 HTML 响应头携带了：

1
Cache-Control: private, must-revalidate, no-cache, no-store, max-age=0

这意味着当前站点的 HTML 是**完全动态渲染（SSR）**的，所有访问都要边缘回源，CDN 仅仅充当了“四/七层代理”。

如果结合 Next.js 的 ISR（增量静态生成） 或配置 stale-while-revalidate 缓存策略，动态首页的 TTFB 将直接从当前的 200~400 ms 骤降至边缘缓存的 60 ms 级别。这带来的用户体验提升，将远超单纯切换 CDN 供应商。