Cloudflare R2 走 EdgeOne 还是 ESA？139MB 安装包下载实测：单连接差 50 倍

一、测试对象#

同一个安装包，分别上传到两个 R2 存储桶，由两家 CDN 代理：

从 Content-Range 响应头可以读出这份文件的真实大小：

1
Content-Range: bytes 0-5242879/145716483

即 145,716,483 字节（139.0 MiB）。两边的 ETag 完全一致，确认是同一份文件：

1
ETag: "a9069887fe77d48fec498186889e8eee"

二、核心结论速览#

核心结论：对 R2 大文件分发，ESA 明显更快，EdgeOne 这个站点被硬限速了。

• 5MB 分片（8 轮交错中位）：EdgeOne 38.2 Mbps vs ESA 177.3 Mbps，ESA 快 4.6 倍
• 20MB 单连接：EdgeOne 三轮都是 7.2 Mbps（耗时 22.10 / 22.06 / 22.12 秒）；ESA 预热后跑到 239 ~ 259 Mbps
• 整包 139MB 单连接：EdgeOne 需要 276.5 秒（4.6 分钟）；ESA 约 5 秒——差约 50 倍

EdgeOne 的问题：单连接被限速。前约 2 秒（约 10MB）有 ~40 Mbps 突发，随后**断崖式跌到 ~4 Mbps（500 KB/s）**并稳定保持。

ESA 的问题：冷启动回源大文件会失败（HTTP/2 流重置、响应截断、HTTP 522）。缓存预热后性能极佳，但首次访问容易踩坑。

三、冷启动：两家的第一印象完全不同#

链接在此之前从未被访问过，所以第一次请求会穿透缓存回源到 R2。这是最珍贵的一次测量机会（缓存一旦预热就回不到冷态）。

ESA 的失败信息很明确：

1
The HTTP/2 server reset the stream.
2
HTTP/2 error code 'INTERNAL_ERROR' (0x2). (HttpProtocolError)

这一轮 EdgeOne 「赢了」——但赢的原因是它至少传完了，而不是它快。276 秒下完一个 139MB 的文件，平均只有 4 Mbps。

四、关键证据：EdgeOne 的「2 秒断崖」#

为了搞清楚那 4 Mbps 从哪来，我们用 Range 请求做了一个 30MB 的连续下载，并逐秒采样：

原始采样数据（单位 Mbps）：

1
1s:39.5  2s:39.9  3s:4.0   4s:3.9   5s:3.9   6s:4.6   7.1s:4.7  8.1s:3.9
2
9.1s:4.1 10.1s:3.7 11.1s:3.8 12.1s:5.0 13.1s:2.8 14.1s:3.0 15.1s:6.4
3
17s:2.4  18s:3.9  19s:4.1  20s:4.2  21s:3.6  22s:4.4  23s:3.9  24.1s:4.7
4
...
5
42.1s:4.7

前两秒 39.5 → 39.9 Mbps，第三秒直接掉到 4.0 Mbps，之后 40 秒一直贴着 4 Mbps 波动（2.4 ~ 6.8）。这不是网络抖动，是限速。

1
第 1 轮: 22.10 s  (7.20 Mbps)
2
第 2 轮: 22.06 s  (7.30 Mbps)
3
第 3 轮: 22.12 s  (7.20 Mbps)

五、排除干扰：限速到底是谁造成的？#

看到 4 Mbps 这种「太整」的数字，第一反应应该是怀疑自己的线路。我们做了三组对照：

三条结论：

1. 我的线路不对长连接限速 —— 一条 TCP 连接持续 7 秒跑完 146.9MB，全程 166 Mbps。
2. EdgeOne 平台本身不限速 —— 腾讯官方镜像同样由 EdgeOne 承载，响应头带着 EO-Cache-Status: HIT，能跑到 273 Mbps。
3. 所以那个 ~4 Mbps，是这个站点（gta-db-team.antwen.cn）特有的限速——大概率来自套餐档位自带的单连接/带宽限制，或站点上配置的「带宽封顶 / 限速」规则。

建议：去 EdgeOne 控制台核对这个站点的套餐档位，以及规则引擎 / 流量管理里有没有限速相关配置。

顺带一提，http:// 那个链接并非直出——实测返回 301 跳转到 HTTPS，说明站点的强制 HTTPS 是开启的。

六、ESA 的软肋：回源 R2 会失败#

ESA 预热后快得惊人，但首次拉取大对象时非常不可靠：

17 分钟后复查，情况完全变了：

1
HTTP/1.1 206 Partial Content
2
Server: ESA
3
X-Site-Cache-Status: HIT
4
cf-cache-status: HIT
5
Age: 176
6
Content-Range: bytes 0-5242879/145716483

三个区段（开头 / 60MB / 120MB）全部 HIT、全部成功。缓存填满之后，ESA 的速度优势才显现出来。

1
EdgeOne: CF-RAY: a4618cbf8ddfc236-SJC   ← 圣何塞（美国西海岸）
2
ESA    : CF-RAY: a461ae578b6d346b-SEA   ← 西雅图（美国西海岸）

七、并发测试：多连接并不能线性叠加#

既然 EdgeOne 单连接被限速，那多开几条连接能不能绕过去？

每轮合计传输 80MB：

两个反直觉的结果：

1. EdgeOne 在 8 并发时就已经触顶 ~40 Mbps，继续加到 16 并发完全没有提升。这说明限速不是按连接独立计算的，而是站点/客户端维度共享一个上限。想靠多线程下载器翻倍，行不通。
2. ESA 也远达不到单连接的水平：单个 5MB 能跑 177 Mbps，但 16 并发聚合只有 62.9 Mbps。并发场景下的瓶颈转移到了边缘节点回源一侧。

不过 EdgeOne 换成分片下载仍有实打实的收益——28 次连续 5MB 覆盖整个 139MB：

1
成功 28/28 | 总耗时 30.3 秒 | 合计 139.0 MB | 聚合 36.7 Mbps | 最慢单片 1.42s

对比单连接的 276.5 秒，快了约 9 倍。原因是每个新请求都能重新拿到一次突发额度。

八、结论与落地建议#

附录：复现方法#

1
curl.exe -s -o NUL -A $UA --http1.1 `
2
  -H "Range: bytes=0-5242879" `
3
  -w "%{http_code}|%{time_total}|%{size_download}|%{speed_download}" $URL

1
$resp = $cli.SendAsync($req, [System.Net.Http.HttpCompletionOption]::ResponseHeadersRead).GetAwaiter().GetResult()
2
$st = $resp.Content.ReadAsStreamAsync().GetAwaiter().GetResult()
3
$buf = New-Object byte[] 262144
4
while (($k = $st.Read($buf, 0, $buf.Length)) -gt 0) {
5
    $n += $k
6
    $el = $sw.Elapsed.TotalSeconds
7
    if (($el - $lastT) -ge 1) {
8
        # 记录这一段（$el - $lastT）内传输的字节数换算成的 Mbps
9
    }
10
}

1
无法将类型"System.Object[]"的值转换为类型"System.Management.Automation.SwitchParameter"

后记#

这轮实测最有价值的一点，其实是方法本身：

• 不要只用「整包下载」下结论——它会把限速曲线和稳态吞吐混成一个数字
• Range 分片能把一次长传输拆成多个短请求，从而区分「单连接限速」和「边缘分发能力」
• 逐秒采样才能看清「突发 + 断崖」这类令牌桶行为
• 一定要做对照实验，否则很容易把自己线路的问题误判成 CDN 的问题

顺便说一句，上一篇的结论（主站用 EdgeOne）和这一篇的结论（大文件用 ESA）并不矛盾——它们是两种完全不同的负载：动态 SSR 拼的是稳定性和首字节，大文件分发拼的是持续吞吐。同一个账号下的不同站点，配置和套餐也可能不一样。

选型要看负载，而不是看品牌。