主动探测和RUM有什么区别？选CDN该信哪一种数据

主动探测显示某家CDN的延迟只有40毫秒，真实用户监控却显示P95超过500毫秒；另一家CDN在测试节点上的成绩一般，正式接入后用户访问反而更快。

遇到这种结果，应该相信哪一个？

答案不是二选一：

选型阶段，优先用可复现的主动探测进行同条件比较；接入CDN以后，再用RUM验证真实用户是否真正受益。

主动探测解决的是“在控制变量后，哪家CDN的网络表现更好”；RUM解决的是“我的真实访客实际上经历了什么”。两者观察的对象不同，数据不一致并不意味着其中一个不可信。

真正危险的是把主动探测当成全部用户体验，或者拿未经控制的RUM数据直接给两家CDN排名。

什么是主动探测

主动探测也叫合成监控、Synthetic Monitoring。它由部署在不同地区和运营商网络中的探测节点，按照预先设定的频率访问指定域名或文件，并记录各阶段耗时。

一次比较完整的探测通常会记录：

• DNS解析时间

• TCP连接时间

• TLS握手时间

• TTFB，即请求发出到首字节返回的时间

• 内容下载时间和传输速度

• HTTP状态码

• 解析IP、节点位置和ASN

• HTTP协议版本

• 缓存命中状态

• P50、P95和失败率

主动探测最大的价值不是“模拟得像不像真人”，而是控制变量。

例如测试两家CDN时，可以让相同城市、相同运营商的节点，在相近时间请求相同大小的文件，并统一缓存、压缩、协议和回源条件。这样得出的差异，才更接近CDN本身造成的差异。

关于探测节点、测试轮次和分位数的具体设置，可以参考CDN测速方法论：主动探测、P50/P95与可复现性能排名。

主动探测适合回答哪些问题

主动探测特别适合回答以下问题：

1. 某个地区能否稳定解析和访问域名？

2. 不同运营商分别调度到了什么节点？

3. 首次连接时，DNS、TCP和TLS分别需要多久？

4. CDN缓存命中后，TTFB是否明显下降？

5. 大文件的持续下载速度和吞吐量如何？

6. 某次配置变更后，延迟或失败率是否出现回归？

7. 尚未承载正式流量的候选CDN，表现是否达到预期？

最后一点对CDN选型尤其重要。还没有把用户流量切到候选CDN时，自然也没有这家CDN的真实用户数据，但主动探测可以提前比较它的基本网络质量。

主动探测的局限

探测节点通常部署在云服务器、数据中心或固定网络中，它不一定能代表家庭宽带、校园网、移动网络以及弱信号环境。

因此，主动探测可能遗漏：

• 家庭宽带最后一公里拥塞

• 移动网络的信号波动和切换

• 老旧设备的CPU与渲染瓶颈

• 特定小运营商或地区的路由异常

• 浏览器缓存、连接复用和Service Worker的影响

• 第三方脚本、图片和前端代码造成的页面卡顿

所以，主动探测成绩好，只能证明选定测试条件下表现良好，不能直接推出所有用户都会快。

什么是RUM真实用户监控

RUM是Real User Monitoring的缩写。它通过浏览器提供的Performance API、Navigation Timing、Resource Timing以及Web Vitals等数据，采集真实访客在实际访问过程中的性能表现。

RUM数据来自真实用户，因此会自然包含：

• 用户所在地区和网络运营商

• 家庭宽带、移动网络等接入条件

• 手机、平板和电脑等设备差异

• 浏览器版本和设备性能

• DNS缓存、浏览器缓存及连接复用

• 页面类型、资源数量和第三方脚本

• 用户实际访问的时间段

• LCP、INP、CLS等页面体验指标

• 真实流量中的长尾延迟和偶发错误

web.dev关于性能测量工具的说明将实验室数据描述为假设环境下的性能，将现场数据或RUM描述为真实用户实际经历的性能。两者应该互相补充，而不是互相替代。

RUM最擅长发现什么

RUM最有价值的地方，是发现平均值掩盖的真实问题。

例如整体TTFB看起来只有150毫秒，但拆分数据后可能发现：

• 某个省份的P95达到1.2秒；

• 移动网络用户明显慢于家庭宽带；

• Android低端机的LCP显著偏高；

• 首页正常，商品详情页因为接口慢而延迟；

• 工作日正常，晚高峰某运营商出现长尾；

• CDN缓存命中正常，但第三方脚本拖慢了页面。

这类问题很难通过少量固定探测节点完全覆盖。

RUM也不是天然公平

RUM数据虽然来自真实用户，但“真实”不等于“可以直接横向比较”。

假设CDN A承载的是促销活动期间的移动端流量，CDN B承载的是普通工作日的桌面端流量，即使B的数据更好，也不能证明B的CDN性能更强。

影响RUM可比性的变量包括：

• 两组用户的地区和运营商比例不同

• 页面版本或资源数量不同

• 一组用户以新访客为主，另一组大量复用缓存

• 请求对象和缓存命中率不同

• 营销活动导致流量结构改变

• 不同时间段的公网拥塞程度不同

• 用户设备性能差异明显

因此，使用RUM比较CDN时，最好进行稳定分流，让两家CDN在同一时间承载结构相近的流量，并按照地区、运营商、设备和页面类型分层观察。

主动探测和RUM的核心区别

简单来说：

• 主动探测更像标准化体检；

• RUM更像持续记录每位真实用户的实际感受。

选CDN时应该信哪一个

初选和招标阶段：主动探测权重更高

在尚未接入候选CDN的阶段，没有足够的真实用户数据。这时应该主要依靠主动探测，比较：

1. 目标地区和运营商的可用率；

2. DNS、TCP、TLS和TTFB；

3. 缓存命中后的响应速度；

4. 静态资源下载速度；

5. P50、P95和失败率；

6. IPv4与IPv6差异；

7. 首次连接与重复访问差异；

8. 高峰期和非高峰期稳定性。

测试节点不应只选北上广和主流运营商，而要根据网站真实用户分布加权。如果30%的用户来自东南亚，那么只在中国大陆测试得出的排名没有多少决策价值。

选择第三方测速平台前，也应先确认它是否公开节点位置、运营商、测量阶段和原始结果。具体可以参考CDN测速网怎么选？先检查节点、指标和结果记录。

小流量试运行阶段：主动探测与RUM并用

当候选CDN可以承载一部分真实流量时，最有价值的做法是稳定分流。

例如使用一致性哈希，让同一用户在测试周期内始终进入同一个CDN组，并确保两组尽量使用：

• 相同页面版本；

• 相同缓存策略；

• 相同源站；

• 相同压缩方式；

• 相同证书和HTTP协议；

• 相同资源路径和文件大小；

• 相近的地区、运营商及设备结构。

主动探测继续监控底层网络与可用率，RUM则验证页面体验和真实长尾。两组数据同时改善，才能比较有把握地判断CDN带来了收益。

正式上线以后：RUM权重更高，但不能停掉主动探测

正式上线后，最终目标不是让探测节点跑出漂亮分数，而是让真实用户获得更稳定的体验。因此，RUM在日常优化中的权重应该提高。

但主动探测仍然不能停，因为它可以：

• 在低流量地区持续检查可用性；

• 主动发现DNS、证书和节点异常；

• 在真实用户投诉前发现区域故障；

• 用固定条件判断配置变更是否引起回归；

• 区分CDN问题、源站问题和页面问题。

比较合理的组合是：主动探测负责持续巡检和定位，RUM负责验证真实影响。

两种数据冲突时怎么判断

情况一：主动探测快，RUM慢

常见原因包括：

• 探测节点位于数据中心，真实用户使用移动网络或家庭宽带；

• 真实用户集中在CDN覆盖不足的地区；

• 探测的是单个静态文件，用户访问的是完整页面；

• 页面包含慢接口、大图片或第三方脚本；

• 真实请求缓存未命中，而探测对象长期命中缓存；

• 用户设备性能较低，渲染阶段耗时较长。

此时不要立刻认定“CDN测速不准”，而应先拆分RUM中的地区、运营商、页面类型、缓存状态和设备等级。

如果网络请求本身很快，但LCP仍然很慢，问题很可能不在CDN网络，而在图片尺寸、渲染阻塞资源、前端代码或第三方脚本。

情况二：主动探测慢，RUM快

可能原因包括：

• 探测每次都强制进行DNS解析和TLS握手；

• 真实用户复用了已有连接；

• 浏览器缓存或Service Worker直接返回了资源；

• 探测节点所在网络不具有代表性；

• CDN或WAF对探测流量进行了限速、验证或拦截；

• 真实流量集中在少数优势地区。

这种情况下，需要区分首次访问和重复访问，并检查探测节点的解析IP、运营商和HTTP状态码。

情况三：主动探测和RUM都慢

两者同时变慢，通常意味着问题更值得优先处理。

可以按照DNS、连接、TLS、TTFB和下载时间，哪个环节最值得先优化？中的顺序，先确定延迟集中在哪个阶段：

• DNS慢：检查权威DNS、递归解析路径和TTL；

• TCP慢：检查节点距离、路由和丢包；

• TLS慢：检查连接复用、协议版本和证书链；

• TTFB慢：检查缓存命中、边缘处理和源站响应；

• 下载慢：检查吞吐量、文件大小、压缩和拥塞。

不要只盯着总耗时，因为总耗时只能说明慢，不能说明慢在哪里。

情况四：主动探测稳定，RUM的P95突然升高

这通常意味着问题只影响部分真实用户，例如：

• 某个地区或小运营商出现绕路；

• IPv6路径异常；

• 移动网络晚高峰拥塞；

• 某类设备或浏览器出现兼容问题；

• 特定页面的资源或接口变慢。

此时平均值往往没有明显变化，应重点观察P75、P95、P99以及细分维度。

情况五：RUM正常，但部分探测节点持续失败

首先排除探测IP被WAF、限速策略或机器人规则拦截的可能。如果请求状态码、响应头或挑战页面异常，可能只是探测环境受到限制。

但如果同一地区多个独立节点都失败，就应把它视为区域性故障预警，而不是因为当前RUM样本较少就直接忽略。

如何建立一套可信的CDN评估流程

第一步：先保证测试条件一致

比较多家CDN时，至少统一以下条件：

• 测试文件内容与大小；

• 源站位置和源站性能；

• 缓存规则与缓存有效期；

• 是否启用压缩；

• HTTP/2或HTTP/3配置；

• TLS证书和证书链；

• IPv4或IPv6；

• 首次访问或重复访问；

• 缓存命中或回源；

• 测试时间和探测频率。

如果CDN A使用缓存命中结果，CDN B每次都回源，那么比较结果没有实际意义。

第二步：分别测试冷路径和热路径

建议至少建立两组主动探测：

• 冷路径：使用不同查询参数或可控刷新方式，观察缓存未命中和回源；

• 热路径：重复请求固定资源，观察边缘缓存命中后的表现。

注意查询参数是否参与缓存键。如果只是随意增加随机参数，可能测试到的不是正常用户路径，而是一条永远无法命中缓存的特殊路径。

第三步：记录分位数，不只看平均值

网站“有时快、有时慢”时，平均值很容易掩盖问题。

例如99次请求为100毫秒，1次请求为5秒，平均值仍然可能看起来可以接受，但那一次慢请求对应的用户体验已经很差。更合理的方式是同时记录：

• P50：典型体验；

• P75：大部分用户体验；

• P95：长尾稳定性；

• P99：极端异常；

• 错误率和超时率。

更完整的测量方法可参考网站有时快有时慢，CDN测速应该怎么测？。

第四步：让RUM记录足够的上下文

RUM只上报一个“页面加载用了多少毫秒”，定位价值非常有限。建议在保护隐私的前提下，同时记录：

• 页面类型；

• 国家或大区；

• 网络类型；
  -浏览器和设备等级；

• CDN标识或实验分组；

• 页面版本；

• DNS、连接、TLS、TTFB和下载耗时；

• LCP、INP和CLS；

• 请求是否复用连接；

• 缓存状态或边缘节点标识。

如果需要让浏览器获取跨域CDN资源的完整Resource Timing数据，资源响应必须正确配置Timing-Allow-Origin。W3C的Resource Timing规范明确限制了跨源资源可暴露的详细计时信息。

第五步：按真实业务流量加权

一家CDN可能在全球平均成绩上排名第一，但在网站主要用户所在地区表现一般。

最终评分应根据实际业务权重计算，例如：

• 华东电信用户占30%；

• 华南移动用户占20%；

• 东南亚移动用户占15%；

• 欧洲用户占10%；

• 其他地区占25%。

同时还可以提高关键页面和付费用户路径的权重。CDN选型不是全球节点数量比赛，而是为自己的真实用户选择更合适的网络。

一个基础的RUM采集示例

浏览器的Navigation Timing接口可以记录主文档的部分阶段耗时：

<script>
window.addEventListener('load', () => {
  const nav = performance.getEntriesByType('navigation')[0];
  if (!nav) return;

  const secureStart = nav.secureConnectionStart || nav.connectEnd;

  const sample = {
    dns_ms: nav.domainLookupEnd - nav.domainLookupStart,
    tcp_ms: Math.max(0, secureStart - nav.connectStart),
    tls_ms: nav.secureConnectionStart > 0
      ? nav.connectEnd - nav.secureConnectionStart
      : 0,
    request_to_first_byte_ms: nav.responseStart - nav.requestStart,
    download_ms: nav.responseEnd - nav.responseStart,
    total_response_ms: nav.responseEnd - nav.startTime
  };

  navigator.sendBeacon(
    '/rum',
    new Blob(
      [JSON.stringify(sample)],
      { type: 'application/json' }
    )
  );
});
</script>

这里需要注意：DNS、TCP或TLS为0，并不一定表示这些步骤瞬间完成，也可能是浏览器使用了DNS缓存、复用了现有连接，或者页面并未重新进行TLS握手。

实际部署时还需要增加采样、异常值处理和版本标识，并避免上传账号、Token、完整查询参数、原始IP等敏感信息。RUM数据应有明确的保留期限和访问权限，并根据适用地区完成隐私与合规评估。

CrUX数据等于自己部署的RUM吗

不完全等于。

Chrome UX Report，也就是CrUX，使用符合条件的Chrome用户产生的真实体验数据，并将数据聚合到页面或站点级别。CrUX官方说明明确指出，这些指标来自全球真实Chrome用户的实际访问。

因此，CrUX属于真实用户数据，但它与网站自行部署的RUM仍有区别：

• CrUX是聚合数据，无法提供单次访问明细；

• 低流量页面或站点可能没有足够数据；

• 很难根据自定义业务维度拆分；

• 不能精确标记访问使用了哪家CDN；

• 数据更新存在周期，不适合分钟级故障告警；

• 自建RUM可以记录页面版本、实验组和业务路径。

CrUX适合观察网站整体用户体验和长期趋势，自建RUM则更适合CDN实验、故障定位和业务维度分析。CrUX的数据方法说明也表明，单个用户体验会被汇总为页面或站点的分布数据。

选CDN时的推荐判断顺序

无论使用主动探测还是RUM，都建议按照以下顺序做决策：

1. 可用率和错误率
   频繁超时或返回错误的CDN，再低的平均延迟也没有意义。

2. 目标地区和运营商表现
   先看核心用户群，而不是不加权的全球平均值。

3. P95与P99稳定性
   CDN的价值不仅是最快能有多快，还包括最慢时会不会失控。

4. 主文档和API的TTFB
   它们通常直接影响页面开始渲染的时间。

5. 静态资源吞吐量
   图片、视频和安装包业务尤其需要关注持续下载性能。

6. Core Web Vitals和业务指标
   最终检查LCP、INP、跳出率、转化率等是否真的改善。

7. 故障定位和回滚能力
   CDN切换、配置发布和故障恢复是否足够可控，同样属于选型的一部分。

常见误区

误区一：RUM来自真人，所以一定比主动探测准确

RUM更接近真实体验，但未必适合未接入CDN之间的公平比较。如果两组流量的地区、设备和页面版本不同，结果可能出现明显偏差。

误区二：主动探测不是真实用户，所以没有参考价值

主动探测的意义恰恰在于控制变量。只要节点覆盖、请求对象和测试方法合理，它是选型、回归测试和故障定位中非常重要的数据来源。

误区三：测速最快的CDN就是最适合的CDN

单个探测点的最快结果不能代表整体表现。还要检查目标用户覆盖、P95、失败率、回源能力、缓存策略和正式流量中的体验。

误区四：平均值没有变化就说明没有问题

区域性故障或少数运营商异常可能只影响5%的用户，平均值几乎不会变化，但P95会明显升高。

误区五：RUM里TLS为0说明TLS性能特别好

更常见的原因是连接被复用，当前页面没有重新建立TLS连接。首次访问和重复访问必须分开分析。

最后的选择原则

如果只能记住一句话，可以记住：

选CDN时，先信可复现的主动探测来做同条件比较；接入以后，再信RUM来验证真实用户是否获得收益。

当两组数据冲突时，不要简单投票决定谁对谁错，而应继续拆分：

• 地区和运营商是否一致；

• 是否复用了DNS、TCP和TLS连接；

• 缓存是否命中；

• 是否测试了相同页面和资源；

• 用户设备与网络是否不同；

• 慢的是CDN网络、源站响应，还是页面渲染；

• 比较的是P50还是P95、P99。

主动探测负责建立可重复的基准，RUM负责检验这些基准在真实世界里是否成立。两种数据能够互相解释时，CDN选型结论才真正可信。

常见问题

1. 主动探测的数据是不是一定不如RUM准确？

不是。主动探测和RUM测量的是不同环境。主动探测适合受控比较和故障定位，RUM适合评估真实用户体验。准确与否取决于问题本身以及测试设计。

2. 已经部署RUM，还需要使用CDN测速平台吗？

需要。RUM只能覆盖已经产生的真实流量，很难持续检查低流量地区，也不能直接测试尚未接入的候选CDN。主动探测还能提供固定基线和主动告警。

3. 网站流量很小，应该优先看哪种数据？

低流量网站的RUM样本容易波动，细分到地区和运营商后可能没有统计意义。此时应以主动探测为主，同时逐步积累RUM数据。

4. 候选CDN没有真实用户数据，怎么比较？

先使用统一域名、文件、源站、缓存策略和探测节点进行主动测试。条件允许时，再分配少量真实流量进行稳定的A/B验证。

5. 为什么RUM采集到的DNS、TCP或TLS时间经常是0？

通常是浏览器使用了缓存或复用了已有连接，也可能是相关计时信息无法获得。0不应直接解释为网络阶段没有任何耗时。

6. 可以直接把CrUX当作网站自己的RUM吗？

不建议。CrUX适合观察聚合后的真实用户体验和长期趋势，但缺少自定义实验组、CDN标识、页面版本等维度，不能完全替代自建RUM。

7. CDN试运行需要采集多长时间的数据？

没有适用于所有网站的固定天数。至少应覆盖主要流量时段、工作日和周末，并保证核心地区及运营商有足够样本。活动型网站还应避免把促销期与普通日期直接比较。

8. 选CDN时最应该看平均值还是P95？

应先看可用率和错误率，再看目标用户群的P50、P95及P99。平均值可以描述总体趋势，但无法充分反映少数用户遇到的严重长尾问题。