下载站怎么选CDN？大文件测速不能只看首字节

两个CDN同时测试，一个首字节只要80毫秒，另一个需要300毫秒。只看这项数据，前者似乎赢得很轻松。

真正下载一个2GB文件时，结果却可能完全相反。

如果第一个CDN的持续下载速度只有2MB/s，理论上需要约17分钟；第二个CDN虽然多等了两百多毫秒，但持续速度能达到20MB/s，整个文件大约两分钟就能完成。

对于网页来说，几百毫秒的首字节差异可能比较明显；对于软件安装包、游戏补丁、系统镜像和素材压缩包来说，后面几分钟的传输能力才真正决定用户体验。

这就是下载站选择CDN时最容易踩的坑：用测网页的方法测大文件，只看Ping、延迟或者TTFB，却没有真正把文件下载一段时间。

CDN节点响应得快，不代表它能一直传得快；开始几秒很快，也不代表下载到80%时不会掉速。下载站需要考察的是一条完整交付链路，而不是请求刚开始时的那一个数字。

下载站和普通内容网站，对CDN的要求有什么不同

普通资讯网站、电商网站和企业官网，大部分资源可能只有几十KB到几MB。页面更在意DNS、连接、TLS、TTFB和首屏资源加载顺序。

下载站面对的情况不同：

• 单个文件可能从几十MB到数GB；

• 一个用户会长时间占用连接和带宽；

• 用户可能暂停、恢复或重新下载；

• 下载工具可能同时建立多个连接；

• 热门文件上线时会形成突发流量；

• 冷门文件可能因为缓存淘汰而频繁回源；

• 下载失败会浪费已经传输的流量；

• 部分用户来自移动网络或跨境线路；

• 文件被外部网站盗链后，流量账单可能迅速增加。

因此，一个适合网页静态资源的CDN，不一定适合大文件下载。节点多、Ping低、TTFB漂亮，只能说明部分能力，不能直接说明大文件分发效果。

下载站选择CDN，至少要回答四个问题：

1. 用户能不能稳定连接到节点；

2. 节点能不能持续提供足够的下载速度；

3. 下载中断后能不能从中断位置继续；

4. 热门和冷门文件是否都能合理缓存，而不是不断回源。

为什么大文件测速不能只看TTFB

TTFB是从客户端发出请求到收到第一个响应字节所经历的时间。它可以反映DNS、连接、TLS、CDN处理、缓存和回源等环节，但它只覆盖了下载开始之前和刚开始的阶段。

假设一个500MB文件的测试结果如下：

对于500MB文件来说，CDN A虽然最早返回第一个字节，用户却需要等待更长时间才能下载完成。

这并不代表TTFB没有价值。TTFB过高可能说明缓存未命中、节点调度不合理、回源距离过远或者源站响应慢。问题在于，TTFB必须和持续吞吐、完成时间及失败率一起看。

如果只是测试一张图片、一个HTML页面或几百KB的小文件，TTFB在总耗时中的占比可能很高；如果测试的是数GB文件，持续下载速度通常会成为主要因素。

关于这两个概念的区别，可以参考《Ping很快，网站却很慢？别把延迟当成加载速度》和《TTFB高是什么原因？CDN和源站应该先查谁》。

下载速度中的Mbps和MB/s，不要混在一起

CDN控制台、测速工具和下载软件使用的单位可能不同。

• Mbps表示每秒多少兆比特；

• MB/s表示每秒多少兆字节；

• 1字节等于8比特；

• 理论上，100Mbps约等于12.5MB/s。

因此，用户的宽带是100Mbps，并不意味着下载工具会显示100MB/s。考虑协议开销、线路波动、设备性能和其他流量后，实际速度通常还会低于理论值。

对比CDN时必须统一单位。一个结果显示“80Mbps”，另一个显示“12MB/s”，不能直接比较数字大小。

可以使用下面的换算关系：

MB/s = Mbps ÷ 8
Mbps = MB/s × 8

例如：

80Mbps ≈ 10MB/s
20MB/s ≈ 160Mbps

文章、测试报告和内部评审表最好同时标注单位，避免把“兆带宽”和“每秒下载多少兆文件”混为一谈。

下载站选CDN，应该重点看哪些指标

1. 下载成功率

速度再快，连接经常中断也没有意义。

成功率应优先于最快速度。测试时需要记录：

• DNS解析失败；

• TCP或TLS连接失败；

• HTTP 4xx、5xx状态码；

• 下载中途断开；

• 客户端超时；

• Range请求失败；

• 文件大小或校验值不一致；

• 重试后是否能够恢复。

不要只记录“最终成功”。一个用户重试三次才下载完成，和第一次就成功并不是同一种体验。

2. 首字节时间

TTFB可以帮助判断下载是否能够快速开始，也能发现缓存MISS和回源问题。

但对大文件来说，TTFB适合用来回答“多久开始下载”，不适合单独回答“多久能够下载完成”。

3. 持续下载速度

持续速度是大文件测试的核心。至少应记录：

• 前10秒平均速度；

• 整个测试过程的平均速度；

• 中途最低速度；

• 下载后半段速度；

• 完成指定文件所需时间；

• 多次测试的P50和P95。

有些CDN在刚开始下载时速度很高，几十秒后明显下降；也有些节点启动稍慢，却能长时间维持稳定吞吐。只运行三五秒的测速可能会错过这种差异。

4. 速度波动

平均速度相同，不代表体验相同。

一种情况是始终保持在10MB/s左右；另一种情况是在1MB/s和25MB/s之间反复波动。两者平均值可能接近，但后者更容易造成预计剩余时间跳动、下载超时和用户误以为任务卡住。

因此，还需要观察速度曲线和离散程度，而不是只保留一个平均值。

5. 多地区和多运营商表现

北京电信下载很快，不能证明广州移动、成都联通或者海外用户也快。

下载站应该根据真实用户分布安排测试：

• 中国大陆用户：分电信、联通、移动及主要地区；

• 海外用户：按国家、城市和当地主要网络测试；

• 跨境下载：重点观察跨境链路和高峰时段；

• 移动用户较多：增加4G、5G和家庭宽带环境；

• 校园、企业或特殊网络用户：用真实环境补充测试。

可以先通过CDNChart网站测速观察不同地区的解析、连接、TTFB和可用性，再使用实际文件下载测试补充持续吞吐数据。

需要注意，常规网站测速通常不会为了一个任务完整下载数GB文件。它适合发现节点、连接和首字节问题，不能代替长时间的大文件传输测试。

6. 高峰时段稳定性

下载站最怕测试时很快，用户集中下载时速度突然下降。

测试至少应该覆盖：

• 工作日白天；

• 当地晚间高峰；

• 周末；

• 新版本发布前后；

• 游戏更新、系统升级或活动开始时；

• 单节点出现大量并发时。

一次凌晨测速得出的最高速度，只能证明这个CDN在当时有过这样的表现，不能证明它能长期稳定提供相同吞吐。

测试文件怎么选，才不会测出一个假结果

测试文件应该来自真实业务，而不是为了跑分临时制作一个特别容易缓存的小文件。

可以准备三个档位：

具体大小不必机械固定为10MB、100MB或1GB。软件下载站应该按照安装包的实际大小选择，游戏资源站则应模拟补丁包、完整客户端和素材文件。

如果业务中的大部分文件在300MB到800MB之间，却只用5MB文件测试，得到的结果很难代表真实用户。

测试文件还应满足以下条件：

• 内容固定，不在同一个URL下频繁覆盖；

• 文件大小明确；

• 可以计算SHA-256等校验值；

• 响应头与正式下载文件一致；

• CDN缓存规则与正式文件一致；

• 不携带每次都变化的随机查询参数；

• 不包含敏感信息；

• 测试结束后可以核对文件完整性。

为了避免测试流量失控，可以限制测试频率和节点数量，不必让每个探针每分钟下载一个数GB文件。

冷缓存和热缓存必须分开测试

同一个文件第一次访问时，CDN节点可能没有缓存，需要从源站获取；第二次访问时，文件可能已经保存在节点上。

这两种情况回答的问题不同：

• 冷缓存测试：观察回源线路、源站带宽、首个用户体验和缓存填充能力；

• 热缓存测试：观察边缘节点向用户持续传输文件的能力。

如果拿一个CDN的热缓存结果，去对比另一个CDN的首次回源结果，结论没有参考价值。

可以连续请求相同URL并查看缓存状态：

curl -sS -D - -o /dev/null \
  'https://download.example.com/files/client-v3.2.zip'

重点关注：

Cache-Control
Age
ETag
Last-Modified
Content-Length
Accept-Ranges
Via
X-Cache
CF-Cache-Status

不同CDN使用的缓存状态头并不统一，应结合服务商文档判断。HIT通常表示从缓存返回，MISS通常表示当前缓存层未命中，但多层缓存、回源盾和分层缓存可能让实际链路更加复杂。

关于缓存状态，可以参考《CDN缓存命中怎么看？HIT、MISS和Age怎么理解》。

大文件缓存不能只看“支持缓存”

CDN服务商说“支持大文件缓存”，不代表你的所有安装包都能长期保存在所有边缘节点。

选择时要继续确认：

• 单文件最大可缓存多大；

• 不同套餐的文件大小限制是否相同；

• Range分片是分别缓存还是回源获取；

• 冷门文件多久可能被淘汰；

• 是否支持分层缓存或区域缓存；

• 是否可以进行缓存预热；

• 预热是预热全部节点还是部分区域；

• 缓存刷新是否按URL、目录或标签计费；

• 文件MISS时是否会完整回源；

• 多个用户同时请求冷文件时能否合并回源；

• 大文件缓存是否有额外费用。

这些规则变化较快，而且不同套餐可能不同，最终应以CDN服务商当前官方文档、合同和实际测试结果为准。

为什么冷门文件特别容易暴露问题

热门文件访问频繁，通常更容易留在缓存中。冷门文件可能几天甚至几周才被访问一次，更容易被节点淘汰。

用户下载冷门文件时，节点需要重新回源。如果源站出口只有100Mbps，同时来了多个请求，CDN节点再多也无法凭空提高源站带宽。

所以，测试不能只选最热门的安装包。应该同时选：

• 刚发布、访问量很高的热门文件；

• 日常稳定下载的普通文件；

• 很久没有访问的冷门文件；

• 接近单文件大小上限的大文件。

Range请求为什么对下载站很重要

Range请求允许客户端只获取文件的一部分。下载暂停后，客户端可以从已经完成的位置继续，而不是重新下载整个文件。

MDN的HTTP Range请求说明指出，支持部分请求的服务通常会返回Accept-Ranges: bytes；成功的范围请求通常返回206 Partial Content，并通过Content-Range说明返回的是文件中的哪一段。

先查看响应头：

curl -sSI \
  'https://download.example.com/files/client-v3.2.zip'

如果看到：

Accept-Ranges: bytes
Content-Length: 1073741824
ETag: "example-version-id"

说明服务器声明支持按字节请求。不过，最可靠的方法仍然是实际发起一次Range GET：

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1048575' \
  'https://download.example.com/files/client-v3.2.zip'

正常情况下，响应类似：

HTTP/2 206
Content-Range: bytes 0-1048575/1073741824
Content-Length: 1048576

这表示客户端只请求并获得了文件的前1MB。

如果服务器返回200 OK并发送整个文件，可能表示Range请求被忽略；如果返回416 Requested Range Not Satisfiable，则可能是请求范围超过了文件长度或格式不正确。

Amazon CloudFront的Range GET官方文档也说明，边缘节点可以对大文件的部分字节范围进行处理和缓存；如果源站不支持Range，实际行为可能变成从源站获取完整对象。因此，不能只验证客户端到CDN这一段，还要确认CDN回源时的Range处理。

断点续传不能只看响应头，要真的中断一次

有Accept-Ranges并不等于整个断点续传流程一定正常。

实际测试应该包括：

1. 开始下载一个大文件；

2. 下载一部分后主动中断；

3. 保留本地的部分文件；

4. 再次发起续传；

5. 检查是否返回206；

6. 确认没有从零重新下载；

7. 下载完成后校验文件哈希。

使用curl可以这样测试：

curl -L \
  -o client-v3.2.zip.part \
  'https://download.example.com/files/client-v3.2.zip'

中断后继续：

curl -L -C - \
  -o client-v3.2.zip.part \
  'https://download.example.com/files/client-v3.2.zip'

完成后计算校验值：

sha256sum client-v3.2.zip.part

如果下载期间文件内容被替换，但URL没有变化，续传出来的文件可能由新旧内容拼接。下载站应该使用版本化URL，并通过ETag、Last-Modified、If-Range或客户端校验机制降低这种风险。

例如，不要一直使用：

/download/client-latest.zip

更适合作为实际下载地址的是：

/download/client-3.2.0-build-184.zip

client-latest.zip可以用来跳转到确定版本，但真正的大文件URL最好保持内容不可变。

怎么用curl测试大文件真实下载速度

下面的命令会下载完整文件，但不把内容保存到磁盘：

curl -L -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{response_code}\nsize=%{size_download}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\navg_speed=%{speed_download}\n' \
  'https://download.example.com/files/test-500mb.bin'

输出可能类似：

remote_ip=203.0.113.20
http_code=200
size=524288000
dns=0.018
connect=0.052
tls=0.091
ttfb=0.146
total=42.831
avg_speed=12240164

speed_download默认以字节每秒表示。上面的12240164大约相当于11.7MB/s。

curl的--write-out官方说明列出了可输出的请求变量。测试报告中不要只保留最终速度，还应同时记录响应IP、状态码、文件大小、TTFB和总耗时。

为什么不能只跑一次

第一次可能遇到冷缓存，第二次可能命中节点；某一次可能恰好连接到空闲节点，下一次可能调度到另一个IP。

建议在相同地区、相同运营商、相同时段重复测试，并记录：

• 每次解析和连接的节点IP；

• 缓存状态；

• 平均下载速度；

• 总耗时；

• 是否发生中断；

• P50和P95；

• 最慢一次的实际表现。

如果网站本身存在“有时快、有时慢”的问题，可以参考《网站有时快有时慢，CDN测速应该怎么测》。

单连接快，不代表多用户同时下载也快

大文件下载有两种不同的并发：

• 一个用户通过下载工具建立多个连接；

• 多个用户同时从同一节点下载不同或相同文件。

这两种情况都要测，但不能混在一起。

单连接测试

单连接更接近浏览器直接下载和普通客户端行为，可以观察一条连接的持续吞吐和稳定性。

多连接测试

下载工具可能把文件分成多个Range，同时建立多条连接。多连接有时能提高速度，但也可能只是绕过单连接限速，不能代表CDN的整体容量。

如果候选CDN只有在开启16条或32条连接后才有正常速度，而浏览器单连接非常慢，就要确认真实用户到底使用什么客户端。

多用户并发测试

多个用户同时下载时，需要观察：

• 总吞吐是否随并发合理增长；

• 单用户速度是否迅速下降；

• 是否出现429、503或连接重置；

• 节点是否进行单IP、单连接或单URL限速；

• 热门文件是否始终从缓存返回；

• 源站回源流量是否异常增加。

并发测试容易产生大量流量和费用，应在已获授权的测试域名、文件和容量范围内进行，不要对第三方下载站发起压力测试。

下载速度慢，问题不一定在CDN节点

大文件下载链路通常是：

用户 → 本地网络 → 运营商 → CDN边缘节点 → 上层缓存 → 源站或对象存储

任何一段都可能成为瓶颈。

热缓存慢

如果文件已确认是HIT，但下载仍然慢，重点检查：

• 用户到节点的网络质量；

• 节点出口和当前负载；

• 单连接限速；

• 地区或运营商调度；

• 下载工具并发策略；

• 用户本地带宽和磁盘写入速度。

冷缓存慢

如果只有MISS时慢，命中后正常，重点检查：

• CDN到源站的回源线路；

• 源站出口带宽；

• 对象存储读取性能；

• 源站是否支持Range；

• 同一冷文件并发请求是否重复回源；

• 分层缓存和回源合并是否生效。

所有地区都慢

多个地区、多个运营商都慢，而且速度上限非常接近时，应怀疑：

• 源站或对象存储限速；

• CDN套餐带宽限制；

• 单文件、单连接或单IP限速；

• 鉴权服务响应缓慢；

• 下载程序自身限制；

• 测试设备磁盘或CPU瓶颈。

只有部分地区慢

这更可能与节点覆盖、运营商互联、调度或当地网络有关。需要把地区、运营商、节点IP和时段放在一起比较，不能只看全国平均值。

签名URL和防盗链，会不会影响缓存命中

下载站经常使用带签名的URL：

/file/client.zip?expires=1789800000&token=abc123

如果每个用户的token都不同，而CDN又把全部查询参数纳入缓存键，同一个文件可能生成大量缓存副本，缓存命中率会明显下降。

但简单地忽略所有参数也可能带来鉴权绕过风险。

更合理的方向是：

• 在边缘完成签名校验；

• 校验通过后，让相同文件尽量复用同一缓存对象；

• 明确哪些参数影响文件内容；

• 只有影响内容的参数进入缓存键；

• 限制签名有效期和允许访问的文件范围；

• 对敏感、付费或私有文件保持严格鉴权；

• 不把“提高命中率”置于访问控制之上。

具体实现依赖CDN服务商的边缘鉴权、缓存键和签名能力，必须在测试环境验证，不能照搬其他平台的规则。

选择下载站CDN，还要算清这些费用

大文件业务的流量费用通常远高于请求费用，但不能只比较每GB单价。

完整成本可能包括：

• 不同国家和地区的CDN下行流量；

• 源站或对象存储出口流量；

• 回源流量；

• HTTPS请求费用；

• Range请求数量；

• 缓存刷新和预热；

• 日志存储与投递；

• 边缘鉴权或边缘计算；

• 超出套餐后的阶梯价格；

• 热门版本发布时的突发带宽；

• 被盗链、爬虫和恶意下载产生的无效流量。

例如，一个CDN单价较低，但大文件缓存淘汰频繁，可能产生大量对象存储出口费用；另一个CDN单价略高，却能保持较好的缓存命中和回源控制，总成本反而更低。

测试期间应该同时查看CDN流量、源站流量和对象存储账单，不能只看用户端速度。

下载站CDN对比表应该怎么做

可以为候选CDN建立一张统一评分表：

不同下载站可以调整权重。

软件下载站可以提高断点续传、文件完整性和跨地区稳定性的权重；游戏补丁站可以提高大文件吞吐、峰值容量和预热能力；私有资源下载平台则应提高签名URL、鉴权和日志审计的权重。

不要把所有指标简单平均。对下载站来说，失败率和持续速度通常比首页打开速度更重要。

一个更接近真实业务的测试流程

正式选择CDN前，可以按下面的顺序进行：

建立文件样本

从真实业务中选择小文件、中等文件、典型大文件、热门文件和冷门文件，并记录大小、版本与哈希值。

统一候选CDN配置

尽量让各候选CDN使用相同的源站、缓存时间、测试域名逻辑和访问权限。避免一边开启分层缓存，另一边仍使用默认配置。

先验证基础链路

检查DNS、HTTPS证书、HTTP状态码、缓存状态和节点IP，确认文件确实经过候选CDN。

分开测试HIT和MISS

首次回源和缓存命中分别记录，不能混合计算，也不能拿不同缓存条件互相比较。

实际下载足够长的时间

测试应该足以观察持续吞吐和中途波动。真实文件需要下载十分钟，就不能只测试前五秒。

验证Range和断点续传

实际中断并恢复下载，确认206、文件偏移和最终校验值正确。

覆盖真实用户地区

根据访问日志、订单、客户端上报和业务计划选择地区、运营商及时段，而不是平均分配测试点。

加入受控并发

先测单连接，再测下载工具多连接，最后在授权容量内进行多用户并发测试。

观察源站和成本

用户端变快的同时，源站出口是否增加、缓存命中是否下降、回源请求是否异常，也必须一起检查。

小流量灰度上线

先让部分用户或部分文件使用新CDN，观察完成率、平均速度、P95、中断率、投诉和费用，再决定是否扩大。

常见问题

下载站应该选择节点最多的CDN吗？

不一定。节点数量只能说明覆盖规模，不能直接代表你的用户能连接到合适节点，也不能证明这些节点具有足够的大文件吞吐能力。应以真实用户地区、运营商和文件下载结果为准。

大文件下载速度多少才算正常？

没有统一标准。它受到用户带宽、CDN节点、线路、源站、单连接策略和文件热度影响。更有意义的做法，是基于真实用户网络建立目标，例如核心地区下载速度、P95完成时间和成功率，而不是追求一个脱离环境的固定数字。

测试100MB文件可以代表1GB文件吗？

不一定。100MB文件可以发现明显的连接和吞吐问题，但可能不足以暴露长时间限速、后半段掉速或连接中断。如果实际业务经常分发1GB以上文件，至少要选择部分代表性大文件进行完整测试。

CDN显示HIT，为什么下载还是慢？

HIT只说明文件来自某个缓存层，不代表用户到节点的线路一定好，也不代表节点出口没有拥塞或限速。还要结合响应IP、地区、运营商、持续下载速度和时间段判断。

支持Range就一定能断点续传吗？

不一定。还需要确认CDN、源站和客户端配合正常，文件在续传过程中没有被同名覆盖，并且返回了正确的206和Content-Range。最好实际中断一次，再完成续传和文件校验。

一个大文件可以由多个CDN提供吗？

可以。下载站可以按照地区、运营商、文件类型或流量比例使用多家CDN，也可以配置主备切换。但多CDN会增加缓存一致性、签名鉴权、日志归集和故障判断的复杂度。相关问题可以参考《一个网站能用多个CDN吗？多家检测结果怎么看》。

用CDNChart能直接测完整的大文件下载吗？

CDNChart更适合先观察不同地区和运营商的节点调度、连接、TTFB、可用性及基础下载表现。对于数百MB或数GB文件，还应配合curl、真实下载客户端和受控的长时间测试，补充持续吞吐、Range、断点续传与完成率数据。

下载站筛选CDN时，可以先记住一个很实用的判断：首字节决定用户什么时候看到下载开始，持续吞吐决定用户什么时候真正拿到文件。

如果测速报告里只有Ping和TTFB，却没有文件大小、下载时长、平均速度、速度波动、缓存状态和Range结果，那么这份报告还不足以支持大文件CDN选型。