在Cloudflare Radar上推出新的区域互联网流量和证书透明度洞察功能
自2020年生日周推出以来，Radar在后续的生日周期间都宣布了重要的新功能和数据集。今年我们延续这一传统，推出了包含两部分内容的更新，为Radar分析和剖析互联网的能力增添了更多维度。
首先，我们新增了区域流量洞察功能。区域流量洞察为Radar上显示的流量趋势带来了更本地化的视角。
其次，我们还添加了详细的证书透明度（CT）数据。新的CT数据建立在Cloudflare自2018年以来围绕CT所做的工作基础上，包括我们最初的CT仪表板Merkle Town。
这两项功能都扩展了Radar的使命，即提供对互联网健康和安全更深入、更细致的可见性。下面，我们将深入探讨这些新功能和数据集。
在Radar上推出区域互联网流量洞察
Cloudflare Radar最初推出时提供的是国家层面的互联网流量趋势可见性：想了解互联网中断如何影响伊拉克的流量，或者印度IPv6采用情况如何？这些在Radar上都可见。仅仅一年半后，即2022年3月，我们在Radar上推出了自治系统（ASN）页面。这使我们能够为许多指标提供更细致的可见性：AS701（Verizon Fios）的网络性能如何？AS812（Rogers Communications）实施路由安全的彻底程度如何？AS58322（Halasat）是否刚刚离线？所有这些在Radar上都可见。
然而，有时互联网使用情况会在更局部的层面发生变化——也许某个地区的体育赛事会促使人们上网查找更多信息。或者，一场风暴或其他自然灾害可能导致某个州的设施损坏和停电，从而影响互联网流量。
在过去的几年里，Radar团队依赖内部数据集和Jupyter笔记本来可视化这些"国家以下级别"的流量变化。但今天，随着区域流量洞察功能的推出，我们将这些洞察带给Cloudflare Radar和您。借助这项新功能，您将能够在更局部的层面查看流量趋势，包括字节数和请求数，以及桌面/移动设备和机器人/人类流量份额的细分。为了获得更细致的可见性，在数据探索器中，您还可以选择一个自治系统与区域选择结合——例如，查看马萨诸塞州（美国）内的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 → 美国 > 新泽西州）
深入探究Radar流量数据
在Cloudflare Radar内，有几种方法可以获取这些区域数据。如果您知道感兴趣区域的名称，可以在页面顶部的搜索栏中输入，并从结果中选择它。例如，开始输入"Massachusetts"会返回美国的州，并链接到其区域流量页面。在流量页面顶部的"Traffic in"下拉框中输入区域名称也会返回相同的结果集。
Radar的国家级页面现在有一个新的"按区域划分的流量特征"卡片，其中包括区域流量的摘要视图和时间序列视图。摘要视图以地图和表格形式呈现，类似于全球流量视图中的"流量特征"卡片。从卡片右上角的下拉菜单中选择一个指标后，表格和地图会更新以反映所选时间段的相关摘要值。在分页表格中，区域名称带有链接，点击一个将带您到相关页面。在地图中，摘要值由放置在每个区域质心上的圆圈表示，圆圈大小与其值相关。点击圆圈将带您到相关页面。
在摘要地图和表格下方，该卡片还包括该国流量最高的前五个区域的区域级流量时间序列图。这些图表可以揭示流量模式中有趣的区域差异。例如，下面显示的伊拉克按区域划分的HTTP请求流量图突显了不同省份之间不同的互联网中断时间表（库尔德斯坦地区、伊拉克中部和南部）。在时间表不重叠的日子，例如9月2日和7日，位于库尔德斯坦地区的埃尔比勒省和苏莱曼尼亚省的流量不会与在巴格达和巴士拉观察到的流量下降同时下降。
移动设备与桌面设备流量趋势
在过去的几年里，许多Radar博客文章探讨了人类活动如何影响互联网流量，包括节日庆祝、选举和2024年巴黎夏季奥运会。借助新的区域视图，这种影响现在在更局部的层面上变得更加清晰。例如，在肯尼亚的内罗毕县，移动设备平均占请求流量的一半多一点。在工作日可以看到明显的昼夜模式，移动设备使用率在工作时间下降，然后在晚上再次上升。然而，在周末，移动流量保持较高水平， presumably due to fewer people using desktop computers in office environments, as well as fewer desktop computers in use at home, in line with Kenya’s mobile-first culture.
机器人与人类流量趋势
与移动设备与桌面设备视图揭示人类活动变化类似，机器人与人类流量洞察也是如此。对下图的一种解读是，来自里斯本的夜间机器人活动在9月头几天显著增加。然而，由于图表显示的是流量份额，并且考虑到明显增加的时间，更可能的原因是人为驱动的流量下降幅度越来越大——里斯本的用户似乎在UTC时间23:00（当地午夜）左右开始下线，并在UTC时间05:00（当地06:00）左右重新上线。份额和变化显然因国家和地区而异，但它们可以提供一个关于该地区用户夜间习惯的视角。
使用Radar的数据探索器自定义区域分析
在数据探索器内，您可以使用细分选项和过滤器来自定义对区域流量数据的分析。
在国家层面，选择按区域细分会生成一个堆叠面积图，显示所选国家前20个区域的相对流量份额，以及一个显示摘要份额值的条形图。例如，下图显示，总体而言，弗吉尼亚州和加利福尼亚州占美国HTTP请求量的四分之一以上。
您还可以使用数据探索器在给定区域内钻取到网络（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）可以发现，该网络在周六和周日的流量也较高，这为雨天周末理论提供了可信度。
区域比较，无论是在同一国家内还是跨不同国家，在数据探索器中也是可能的。例如，如果堪萨斯城酋长队和费城老鹰队再次在超级碗相遇，可以使用下面的配置来比较各自主场州的流量模式，并将趋势与前一周进行比较，显示人类活动在比赛过程中如何影响它。
与往常一样，为上述可视化提供支持的数据也可以通过Radar API获得。NetFlows和HTTP端点的timeseries_groups和summary方法现在具有ADM1维度，允许按一级行政区划细分流量。此外，NetFlows和HTTP端点的新geoId过滤器允许您使用GeoNames ID按特定地理位置过滤结果。最后，还有新的get和list端点用于获取地理位置详细信息。
关于数据量和质量的说明
正如您所料，我们从给定地理区域看到的流量越多，“信号"就越好，相关图表也越清晰——当流量在国家层面聚合时通常就是这种情况。然而，对于一些较小或人口较少的地区，特别是在发展中国家或互联网连接较差的国家，较低的流量可能会导致信号较弱， resulting in graphs that appear spiky or incomplete.（请注意，对于区域+ASN视图也是如此。）下面显示了苏丹北达尔富尔州的一个说明性示例。流量的观测有些不一致，导致图中出现尖峰。同样，“前7天"的线条大部分不完整，表明该时间段缺乏流量数据。在这些情况下，很难从这样的图表中得出明确的结论。
尽管互联网可以说超越了地理边界，但现实是使用模式可能因地点而异，流量趋势反映了更局部的人类活动。Cloudflare Radar流量页面和数据探索器中的新区域洞察提供了国家以下级别的视角。我们正在探索未来更深一层的潜力，提供"二级行政区划”（如县、市等）的流量数据。
如果您在社交媒体上分享我们的区域流量图，请务必标记我们：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)。如果您有任何问题或意见，可以通过社交媒体联系我们，或通过电子邮件联系我们。
在Radar上推出证书透明度洞察功能
正如我们为流量模式带来更细致的细节一样，我们也在更深入地揭示互联网信任的基础：TLS证书。证书颁发机构（CA）作为互联网的可信守门人：任何想要向客户端证明其身份的网站都必须出示由客户端信任的CA颁发的证书。但是我们如何知道CA本身是可信的并且只颁发它们被授权颁发的证书呢？
这就是证书透明度（CT）的用武之地。强制执行CT的客户端（大多数主流浏览器）只会信任网站证书，如果它既由受信任的CA签名，又有证据表明该证书已添加到公共的、仅追加的CT日志中，以便可以公开审计。就在最近，CT在检测为1.1.1.1（Cloudflare运营的公共DNS解析器服务）未经授权颁发证书方面发挥了关键作用。
除了作为互联网重要安全机制的作用外，CT在其他方面也被证明是无价的，因为它提供了互联网上使用的所有网站证书的公开可访问列表。这个数据集对于测量互联网的研究人员、检测恶意活动（如钓鱼活动）的安全团队或映射目标外部攻击面的渗透测试人员来说是一个情报宝库。
CT中可用的大量数据（数太字节）使得普通互联网用户难以自行下载和探索。相反，像crt.sh、Censys和Merklemap这样的服务提供了易于搜索的界面，允许发现特定的域名和证书。我们在2018年推出了Merkle Town，使用我们自己的CT监控服务的数据分享对CT生态系统的广泛洞察。
Cloudflare Radar上的证书透明度是Merkle Town的下一代演进，提供了与Radar上已有的安全和域名信息的集成，以及更多交互式探索和分析CT数据的方式。（对于长期的Merkle Town用户，我们将保留它，直到我们达到完全的功能对等。）
在下面的部分中，我们将引导您了解新仪表板中可用的功能。
证书数量和特征
CT页面首先展示了随时间推移颁发和记录的证书数量。由于同一证书可能在同一日志中出现多次或提交到多个日志，总数可能会膨胀。为了解决这个问题，显示了两条不同的线：一条用于总条目，另一条用于唯一条目。然而，唯一性仅在选定的时间范围内计算——例如，如果证书C在一个时间段内添加到日志A，在另一个时间段内添加到日志B，它将出现在两个时间段的唯一计数中。同样重要的是要注意，CT图表和日期过滤器使用日志时间戳，即证书添加到CT日志的时间。此外，页面上显示的数据是从Cloudflare监控的日志中收集的——可能存在延迟、积压或其他不一致之处，因此请报告任何问题或差异。
与此图表并列的是证书和预证书之间的比较。预证书是CT中使用的一种特殊类型的证书，允许CA在正式颁发证书之前公开记录证书。如果相应的预证书已经被记录，CA不需要记录完整证书（尽管许多CA仍然这样做），因此通常记录的预证书比完整证书多，如图表所示。
虽然证书颁发趋势本身很有趣，但分析已颁发证书的特征可以更深入地了解网络信任基础设施的状况。从公钥算法开始，它定义了客户端和服务器之间如何建立安全连接，我们发现超过65%的证书仍在使用RSA，而其余的使用ECDSA。RSA由于其与各种客户端的长期兼容性而保持主导地位，而ECDSA因其效率和较小的密钥大小而越来越多地被采用，这可以提高性能并减少计算开销。在未来几年，我们预计当公共CA开始提供支持时，会出现像ML-DSA这样的后量子签名算法。
接下来，按签名算法细分证书揭示了证书颁发机构（CA）如何签署它们颁发的证书。大多数证书（超过65%）使用RSA with SHA-256，其次是ECDSA with SHA-384占19%，ECDSA with SHA-256占12%，以及一小部分使用其他算法。签名算法的选择反映了广泛支持、安全和性能之间的平衡，像ECDSA这样更强的算法在现代部署中逐渐获得关注。
证书还按验证级别分类，这反映了CA验证证书请求者身份的程度。主要的验证类型是域名验证（DV）、组织验证（OV）和扩展验证（EV）。DV证书仅验证域名的控制权，OV证书验证域名控制权及其背后的组织，而EV证书涉及更严格的检查并在浏览器中显示额外的身份信息。行业趋势是朝着更简单、自动化的颁发方向发展，DV证书现在占已颁发证书的几乎98%，而EV颁发已基本过时。
最后，关于证书有效期的图表显示了每个证书中嵌入的NotBefore和NotAfter日期之间的差异，这些日期定义了证书有效的期间。目前，大多数（92%）已颁发的证书的有效期在47到100天之间。较短证书寿命通过限制证书受损时的暴露来提高安全性，并且受浏览器策略和自动续订系统的推动，行业正朝着更短的有效期发展。
证书颁发
证书颁发是CA为域名所有者生成证书的过程。许多CA由较大的组织运营，这些组织在同一个公司旗下管理多个从属CA。CT页面突出了证书颁发在顶级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。此图表也可以按运营商过滤，以仅显示与特定所有者关联的日志。在图表旁边，另一个视图显示了按日志API分布的证书，区分遵循原始RFC 6962 API的日志与兼容更新、更高效的静态CT API的日志。
与专门的CA页面类似，CT部分还提供日志特定页面。通过在顶部搜索栏中搜索日志名称，您可以访问一个页面，显示主CT页面上可用的所有洞察和趋势，并按所选日志过滤。包括两个额外的卡片：一个显示关于日志的信息，源自Google Chrome的日志列表，包括运营商、API类型、文档以及由同一组织运营的其他日志的列表等详细信息；另一个显示性能指标，带有两个雷达图，跟踪过去90天的正常运行时间和响应时间，由Cloudflare的CT监控器观察。这些指标对于确定日志是否满足像Google这样的CT计划的持续要求非常有用。
证书覆盖范围
最后但同样重要的是，CT页面包括一个关于证书覆盖范围的部分。证书可以覆盖多个顶级域（TLD），包括通配符条目，并支持主题备用名称（SAN）中的IP地址。
预证书在前10个TLD之间的分布突出了最常覆盖的域。.com以45%的证书领先，其次是其他流行的TLD，如.dev和.net。
在此视图旁边，两个半圆环图提供了关于证书覆盖范围的进一步洞察：一个显示包含通配符条目的证书份额——几乎25%的证书使用通配符来覆盖多个子域——而另一个显示包含IP地址的证书，揭示了绝大多数证书在其SAN字段中不包含IP。
扩展的域名证书数据
域名信息页面也已更新，以提供更丰富的证书详细信息。证书表格显示指定域名的活动CT日志中记录的证书，现在包括可展开的行。展开一行会显示更多信息，包括证书的SHA-256指纹、主题和颁发者详细信息——通用名（CN）、组织（O）和国家（C）——有效期（NotBefore和NotAfter），以及找到证书的CT日志。
虽然上述图表突出了CT生态系统中的关键洞察，但所有基础数据都可以通过API访问，并且可以使用Radar的数据探索器跨时间段、CA、日志以及额外的过滤器和维度进行交互式探索。并且一如既往，Radar图表可以下载以供共享或直接嵌入博客、网站和仪表板以进行进一步分析。请随时通过反馈、建议和功能请求与我们联系——我们已经在处理来自CT社区的早期反馈列表！
Cloudflare的连接云保护整个企业网络，帮助客户高效构建互联网规模的应用程序，加速任何网站或互联网应用程序，抵御DDoS攻击，阻止黑客，并可以帮助您完成零信任之旅。
从任何设备访问1.1.1.1开始使用我们的免费应用程序，使您的互联网更快更安全。
要了解有关我们帮助构建更好互联网的使命的更多信息，请从这里开始。如果您正在寻找新的职业方向，请查看我们的空缺职位。