自 2020 年生日周期间推出以来，Cloudflare Radar 每年生日周都会发布重要的新功能与数据集。今年我们延续了这一传统，通过分为两部分的发布，为 Radar 分析互联网的维度增添了更多视角。
首先，我们添加了区域流量洞察。区域流量洞察为 Radar 上显示的流量趋势带来了更具本地化的视角。
其次，我们还添加了详细的证书透明度 (CT) 数据。这些新的 CT 数据是在 Cloudflare 自 2018 年以来围绕证书透明度所开展工作的基础上构建的，其中包括我们最初的证书透明度仪表板 Merkle Town。
这两项功能进一步拓展了 Radar 的使命，即提供更深入、更细致的互联网健康状况和安全洞察。下文将深入探讨这些新功能和数据集。
Cloudflare Radar 最初推出时旨在提供国家层面的互联网流量趋势可视化：想了解互联网中断对伊拉克的流量造成了怎样的影响，或者印度的 IPv6 采用情况如何？这些信息都可以在 Radar 上找到。仅仅一年半之后，在 2022 年 3 月，我们在 Radar 上推出了自治系统 (ASN) 页面。这使我们能够更精细地展示许多指标：AS701 (Verizon Fios) 的网络性能如何？ AS812 (Rogers Communications) 的路由安全实施得有多彻底？AS58322 (Halasat) 是否刚刚离线？所有这些都在 Radar 上清晰可见。
然而，有时互联网使用情况的变化发生在更小的范围内——例如，某个地区的体育赛事可能会促使人们上网查找更多信息。又或者，暴风雨或其他自然灾害可能会造成某个州的基础设施损坏和停电，从而影响互联网流量。
过去几年，Radar 团队一直依赖内部数据集和 Jupyter Notebook 来可视化这些“次国家级”流量变化。但今天，我们将这些洞察引入 Cloudflare Radar，并通过推出区域流量洞察功能，让您也能获得这些洞察。借助这项新功能，您将能够查看更本地化的流量趋势，包括字节数和请求数，以及桌面/移动设备和机器人/用户流量份额的细分数据。为了获得更精细的可见性，您还可以在 Data Explorer 中选择一个自治系统加入区域选择范围——例如，查看位于美国马萨诸塞州的 AS7922 (Comcast)。
根据行业惯例，Radar 上显示的区域名称数据来源于 GeoNames (geonames.org)，这是一个众包地理数据库。具体来说，我们使用的是每个国家/地区列出的“一级行政区划”，例如，美国的各州、洪都拉斯的各省或加拿大的各省。这些地理名称反映了 GeoNames 提供的数据；更多信息，请参阅其关于页面。
Cloudflare 服务记录的请求包含请求发出设备的 IP 地址。包含此地址的地址范围（“前缀”）与我们 IP 地址地理位置数据中的一个 GeoNames ID 相关联，然后我们将该 GeoNames ID 与 GeoNames 数据集中找到的关联国家/地区和“一级行政区划”进行匹配。（例如：155.246.1.142 → 155.246.0.0/16 → GeoNames ID 5101760 → 美国 > 新泽西州）
在 Cloudflare Radar 中，有几种方法可以访问这些区域数据。如果您知道感兴趣的区域名称，可以在页面顶部的搜索栏中输入该名称，然后从结果中选择。例如，输入马萨诸塞州即可返回该美国州，并链接到其区域流量页面。在流量页面顶部的流量来源下拉菜单中输入区域名称，也会返回相同的结果集。
Radar 的国家/地区级页面现在新增了按地区划分的流量特征卡片，其中包含区域流量的汇总视图和时间序列视图。汇总视图以地图和表格的形式呈现，类似于全球流量视图中的流量特征卡片。从卡片右上角的下拉菜单中选择指标后，表格和地图将更新，以反映所选时间段的相关汇总值。在分页表格中，地区名称已链接，点击即可跳转到相应页面。在地图中，汇总值以圆圈表示，圆圈位于每个地区的中心，大小与其值成正比。点击圆圈即可跳转到相应页面。
在汇总地图和表格下方，该卡片还包含全国流量最高的五个区域的区域级流量时间序列图。这些图表可以揭示流量模式中有趣的区域差异。例如，下方所示的伊拉克各区域流量图表（HTTP 请求流量）突显了不同省份（库尔德斯坦地区、伊拉克中部和南部）不同的互联网关闭时间表。在时间表不重叠的日子，例如 9 月 2 日和 7 日，位于库尔德斯坦地区的埃尔比勒省和苏莱曼尼亚省的流量并没有像巴格达和巴士拉那样出现流量下降。
过去几年，许多 Radar 博客文章探讨了人类活动如何影响互联网流量，包括节日庆祝活动、选举以及 2024 年巴黎夏季奥运会。随着新的区域视图的推出，这种影响在更本地化的层面上变得更加清晰。例如，在肯尼亚内罗毕地区，移动设备平均占请求流量的一半以上。工作日期间，移动设备的使用量呈现出明显的昼夜节律模式：工作时间内移动设备使用量下降，晚上则再次上升。然而，在周末，移动流量仍然很高，这可能是由于办公环境中使用台式电脑的人较少，以及家庭中使用台式电脑的人较少，这与肯尼亚的移动优先文化相符。
与移动端和桌面端流量对比揭示用户活动变化类似，机器人流量与用户流量对比也能反映用户活动的变化。下图的一种解读是，里斯本夜间机器人活动在 9 月初的几天内显著增加。然而，由于该图显示的是流量份额，并且考虑到流量明显增加的时间，更可能的原因是用户流量的下降幅度越来越大——里斯本的用户似乎在 UTC 时间 23:00 左右（当地时间午夜）开始下线，并在 UTC 时间 05:00 左右（当地时间 06:00）重新上线。流量份额和变化显然会因国家和地区而异，但它们可以帮助我们了解某个地区用户的夜间活动习惯。
使用 Radar 的 Data Explorer 自定义区域分析功能
在 Data Explorer 中，您可以使用细分选项和筛选器来自定义您对区域流量数据的分析。
在国家层面，选择按地区细分会生成一个堆叠面积图，显示所选国家/地区排名前 20 的地区的相对流量份额，以及一个显示汇总份额值的条形图。例如，下图显示，弗吉尼亚州和加利福尼亚州合计贡献了美国超过四分之一的 HTTP 请求量。
您还可以使用 Data Explorer，在给定区域的网络 (ASN) 级别深入查看流量，包括汇总视图和时间序列视图。例如，查看马萨诸塞州按 ASN 划分的 HTTP 请求流量，我们可以看到 AS7922 (Comcast) 占三分之一，其次是 AS701（Verizon Fios，15%）、AS21928（T-Mobile，8.8%）、AS6167（Verizon Wireless，5.1%）和 AS7018（AT&T，4.7%），以及AS20115（Charter/Spectrum，4.5%）。超过 70% 的请求流量集中在这六家供应商，其中近一半来自一家供应商。
更进一步，您还可以查看特定区域内 ASN 的流量趋势随时间的变化，甚至可以将其与其他时间段进行比较。下图显示了马萨诸塞州 AS7922 (Comcast) 在七天内的流量情况，并与前一周进行了比较。虽然大多数日子的流量与前一周基本持平，但周六和周日的流量明显更高。这些差异可能反映了人们活动的变化，因为 9 月 6 日和 7 日马萨诸塞州雨水较多，人们可能更多地待在室内上网。（前一个周末是劳动节周末，但周六和周日的流量水平与再前一个周末持平。）您还可以将另一个 ASN 添加到流量趋势比较中。在比较部分选择马萨诸塞州（位置）和 AS701 (ASN) (Verizon Fios) 后，会发现该网络的流量在周六和周日也较高，这印证了雨天周末导致流量增加的理论。
在 Data Explorer 中，还可以进行区域比较，无论是在同一国家内还是跨越不同国家。例如，如果堪萨斯城酋长队和费城老鹰队再次在超级碗中相遇，可以使用以下配置来比较两队各自主场所在州的流量模式，并将趋势与前一周进行比较，从而显示人类活动在比赛期间如何影响流量状况。
与以往一样，上述可视化所需的数据也可通过 Radar API 获取。NetFlows 和 HTTP 端点的 timeseries_groups 和 summary 方法现在新增了 ADM1 维度，允许按一级行政区划细分流量。此外，NetFlows 和 HTTP 端点新增的 geoId 过滤器让您能够使用 GeoNames ID 按特定地理位置筛选结果。最后，新增了用于获取地理位置详细信息的 get 和 list 端点。
正如您所料，特定地区的流量越大，“信号”就越强，相应的图表也就越清晰——这通常是在按国家/地区汇总流量数据时的情况。然而，对于一些较小或人口较少的地区，尤其是在发展中国家或互联网连接较差的国家/地区，较低的流量可能会导致信号较弱，从而产生出现尖峰或不完整图表的情况。（请注意，区域+ASN 视图也会出现这种情况。）以下示例展示了苏丹北达尔富尔州的情况。该地区的流量观测结果不太稳定，导致图表中出现尖峰。同样，“过去7天”的曲线也基本不完整，表明该时期缺乏流量数据。在这些情况下，很难从此类图表中得出明确的结论。
尽管互联网可以说超越了地理边界，但现实情况是，用户使用模式会因地域而异，流量趋势反映了更具地域性的用户活动。Cloudflare Radar 流量页面和 Data Explorer 中新增的区域洞察功能，提供了次国家级层面的视角。我们正在探索未来进一步深入的可能性，提供“二级行政区划”（例如县、市等）的流量数据。
如果您在社交媒体上分享我们的区域流量图表，请务必标记我们：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)。如果您有任何问题或意见，可以通过社交媒体或电子邮件联系我们。
正如我们正在对流量模式进行更细致的分析一样，我们也正在深入研究互联网信任的基石：TLS 证书。证书颁发机构 (CA) 是互联网的可信守门人：任何想要向客户端证明自身身份的网站都必须提供由客户端信任的 CA 颁发的证书。但是，我们如何确定 CA 本身是可信的，并且只颁发它们有权颁发的证书呢？
这就是证书透明度 (CT) 发挥作用的地方。强制执行 CT 的客户端（大多数主流浏览器）只会信任由受信任的 CA 签名的网站证书，并且该证书必须有证据证明已添加到仅可追加的公共 CT 日志中，以便进行公开审计。就在不久前，CT 在检测 Cloudflare 运营的公共 DNS 解析器服务 1.1.1.1 的未经授权证书颁发事件中发挥了关键作用。
除了作为互联网的重要安全机制外，证书颁发机构 (CT) 在其他方面也展现出不可估量的价值，因为它提供了互联网上使用的所有网站证书的公开列表。对于研究互联网安全状况的研究人员、检测恶意活动（例如网络钓鱼）的安全团队以及绘制目标外部攻击面的渗透测试人员来说，该数据集都是一个宝贵的情报库。
CT 中海量的数据（数 TB）使得普通互联网用户难以自行下载和探索。因此，像 crt.sh、Censys 和 Merklemap 这样的服务提供了便捷的搜索界面，方便用户查找特定的域名和证书。我们于 2018 年推出了 Merkle Town，旨在利用我们 CT 监控服务的数据，分享对 CT 生态系统的广泛见解。
Cloudflare Radar 上的证书透明度 是 Merkle Town 的下一个发展阶段，它集成了 Radar 上已有的安全和域名信息，并提供更具交互性的方式来探索和分析证书透明度数据。（对于 Merkle Town 的老用户，我们会保留该功能，直到我们实现所有功能对等。）
在下面的几个部分，我们将带您详细了解新仪表板中提供的各项功能。
CT 页面首先展示的是证书的颁发和记录数量随时间的变化情况。由于同一证书可能在单个日志中多次出现，或者被提交到多个日志中，因此总数可能会被夸大。为了解决这个问题，页面显示了两条不同的线条：一条显示总条目数，另一条显示唯一条目数。但是，唯一性仅在选定的时间范围内计算——例如，如果证书 C 在一个时间段内被添加到日志 A，在另一个时间段内被添加到日志 B，则它将在这两个时间段的唯一条目数中都出现。此外，还应注意，CT 图表和日期筛选器使用的是日志时间戳，即证书添加到 CT 日志的时间。另外，页面上显示的数据来自 Cloudflare 监控的日志，可能存在延迟、积压或其他不一致的情况，如发现任何问题或差异，请及时报告。
此图表旁边是证书和预证书的比较。预证书是 CT 中使用的一种特殊证书类型，它允许 CA 在正式颁发证书之前，先将相关信息公开记录到日志中。即使尚未正式颁发完整证书，只要对应的预证书已经记录，CA 通常并不强制要求再记录完整的证书（不过许多 CA 仍会这么做）。因此，正如图表所示，通常记录在案的预证书数量会比完整证书更多。
证书颁发趋势本身就很有趣，但分析已颁发证书的特征，可以更深入地了解网络信任基础设施的现状。首先来看公钥算法，它定义了客户端和服务器之间如何建立安全连接。我们发现，超过 65% 的证书仍然使用 RSA，其余证书则使用 ECDSA。RSA 仍然占据主导地位，是因为它长期以来与各种客户端兼容；而 ECDSA 因其高效性和更小的密钥长度而日益普及，这可以提高性能并降低计算开销。在未来几年，我们预计当公共 CA 开始提供支持时，像 ML-DSA 这样的后量子签名算法将会出现。
接下来，按签名算法对证书进行细分，可以揭示证书颁发机构 (CA) 如何对其颁发的证书进行签名。大多数证书（超过 65%）使用 RSA 和 SHA-256 算法，其次是 ECDSA 和 SHA-384 算法 (19%)、ECDSA 和 SHA-256 算法 (12%)，还有一小部分使用其他算法。签名算法的选择体现了广泛支持、安全性和性能之间的平衡，而像 ECDSA 这样更强大的算法正逐渐在现代部署中得到应用。
证书还按验证级别进行分类，验证级别反映了证书颁发机构 (CA) 对证书请求者身份的验证程度。主要的验证类型包括域名验证 (DV)、组织验证 (OV) 和扩展验证 (EV)。DV 证书仅验证对域名的控制权，OV 证书同时验证域名控制权及其背后的组织，而 EV 证书则包含更严格的检查，并在浏览器中显示额外的身份信息。行业趋势是朝着更简单、自动化的颁发方式发展，目前 DV 证书已占已颁发证书的近 98%，而 EV 证书的颁发已基本被淘汰。
最后，证书有效期图表显示了每个证书中嵌入的“生效日期”和“失效日期”之间的差异，这两个日期定义了证书的有效期限。目前，已颁发证书中绝大多数 (92%) 的有效期在 47 到 100 天之间。较短的证书有效期可以提高安全性，因为如果证书被盗用，其风险敞口会更小。在浏览器策略和自动续订系统的推动下，业界正朝着更短的有效期发展。
证书颁发是指 CA 为域名所有者生成证书的过程。许多 CA 由大型组织运营，这些组织在单一企业集团的领导下管理多个下属 CA。证书颁发页面重点介绍了顶级 CA 所有者的证书颁发分布情况。目前，互联网安全研究组织 (ISRG)（也称为 Let's Encrypt）颁发的证书占所有证书的 66% 以上，其次是其他广泛使用的 CA 所有者，包括 Google Trust Services、Sectigo 和 GoDaddy。
在这份可视化图表中，我们可以清晰地看到类似 7 月 21 日至 22 日因内部 DNS 故障导致 Let's Encrypt API 服务中断的事件所产生的影响——在那两天期间，证书颁发率出现了显著下降。
除了 CA 所有者之外，该页面还提供了按各个 CA 证书划分的证书颁发情况。在排名前五的 CA 中，Let's Encrypt 的四个中间 CA（R12、R13、E7 和 E8）贡献了其大部分证书颁发量。用户还可以按 CA 所有者筛选柱状图，仅显示与特定组织关联的证书。
CT 部分还提供专门针对 CA 的页面。通过在顶部搜索栏中搜索 CA 名称或指纹，您可以访问一个页面，该页面显示主 CT 页面上的所有分析和趋势，并按所选 CA 进行筛选。该页面还包含一张额外的 CA 信息卡，其中提供 CA 的所有者、吊销状态、父证书、有效期、国家/地区、是否包含在公共根证书存储中以及同一所有者运营的所有 CA 的列表等详细信息。所有这些信息均来自通用 CA 数据库 (CCADB)。
CT 页面接下来的部分重点介绍CT 日志。该部分展示了证书在 CT 日志运营商中的分布情况，并指明了管理日志背后基础设施的组织。在过去三个月中，Sectigo 运营的日志包含的证书数量最多（28 亿），接下来是 Google（25 亿）、Cloudflare（16 亿）和 Let's Encrypt（14 亿）。需要注意的是，同一张证书可能会被多次记录在不同的 CT 日志中，因此对于那些运营多个具有重叠收录标准的 CT 日志的组织而言，其日志收录的证书数量可能会偏高。正因如此，本图表中各运营方的相对排名不应被解读为其日志在整个生态系统中所承担负载程度的衡量指标。
下方条形图显示了证书在各个 CT 日志中的分布情况。排名前五的日志包括 Google 的 xenon2025h1 和 argon2025h2、Cloudflare 的 nimbus2025 以及 Let's Encrypt 的 oak2025h2。该图表还可以按运营商筛选，仅显示与特定所有者关联的日志。图表旁边，另一个视图显示了基于 log API 的证书分布情况，区分了遵循原始 RFC 6962 API的日志与兼容更新、更高效的 static CT API 的日志。
与专门的 CA 页面类似，CT 部分也提供日志特定页面。通过在顶部搜索栏中搜索日志名称，您可以访问一个页面，该页面显示主 CT 页面上的所有洞察和趋势，并按所选日志进行筛选。此外，还包含两个卡片：一个显示日志信息，这些信息来自Google Chrome 的日志列表，包括操作员、API 类型、文档以及同一组织运营的其他日志列表等详细信息；另一个显示性能指标，其中包含两个雷达图，跟踪 Cloudflare CT 监控器观察到的过去 90 天的正常运行时间和响应时间。这些指标有助于确定日志是否符合 CT 计划（例如 Google）的持续要求。
最后，CT 页面包含一个关于证书覆盖范围的部分。证书可以覆盖多个顶级域名 (TLD)，包含通配符条目，并支持主题备用名称 (SAN) 中的 IP 地址。
前 10 个顶级域名预证书分布突显了最常被覆盖的域名。.com 以 45% 的证书数量领先，其次是其他热门顶级域名，例如 .dev 和 .net。
在此视图旁边，两个半环形图进一步展示了证书覆盖范围：一个显示了包含通配符条目的证书比例（近 25% 的证书使用通配符来覆盖多个子域），另一个显示了包含 IP 地址的证书比例，表明绝大多数证书的 SAN 字段中不包含 IP 地址
域名信息页面也已更新，提供更丰富的证书详情。证书表（显示指定域名的活动 CT 日志中记录的证书）现在包含可展开的行。展开行即可显示更多信息，包括证书的 SHA-256 指纹、主题和颁发者详细信息（通用名称 (CN)、组织 (O) 和国家/地区 (C)）、有效期（NotBefore 和 NotAfter）以及找到该证书的 CT 日志。
以上图表突出了 CT 生态系统中的关键洞察，所有底层数据均可通过 API 访问，并可使用 Radar Data Explorer，以交互方式探索不同时间段、CA、日志以及其他筛选条件和维度的数据。此外，Radar 的图表和图形均可下载用于分享，或直接嵌入到博客、网站和仪表板中进行更深入的分析。欢迎随时联系我们，提出反馈、建议和功能请求——我们已着手处理 CT 社区早期反馈的优化清单！