Cloudflare CDN IP优选规范

什么是Cloudfalre CDN(摘自CF官网)

Cloudflare CDN

一个全球性的企业级内容分发网络（CDN）

我们的 CDN 得到全球 330 个节点的支持，根据设备、浏览器和带宽需求优化静态和动态内容。

工作原理

提高内容可用性和冗余性
我们的 CDN 在 Cloudflare 每个数据中心的每台服务器上运行每项服务，确保内容从最近的可用位置交付最终用户。

我们全球网络的覆盖范围之广，能够以最高规模交付静态和动态内容，同时最大限度地提高性能和韧性。

Cloudflare CDN 简介

Cloudflare 为 CDN 提供软件即服务 (SaaS) 模式。借助 Cloudflare 的 SaaS 模式，客户无需管理或维护任何基础设施或软件即可享受 Cloudflare CDN 的便利。

Cloudflare CDN 的优势可归因于以下两点，本节将更详细地讨论。

1. CDN 通过将内容缓存在靠近用户的服务器上，本质上提高了性能
2. 独特的Cloudflare架构和集成生态系统

图 2 展示了 Cloudflare CDN 的简化视图。客户端从 Cloudflare 全球任播网络上距离其最近的服务器接收响应，从而大幅降低了延迟和 RTT。该图描绘了无论客户端和源站的物理位置如何，都能获得一致的最终用户体验。

图 2：使用任播向 Cloudflare CDN 发出的 HTTP 请求

Cloudflare CDN 架构和设计

图 3 是 Cloudflare CDN 在全球任播网络上的视图。除了使用任播来提高网络性能和弹性之外，Cloudflare CDN 还利用分层缓存来提供优化的结果，同时为客户节省成本。客户还可以启用 Argo Smart Routing来找到最快的网络路径，将请求路由到源服务器。本文档的其余部分将详细讨论这些功能。

图 3：Cloudflare CDN 在全球任播网络上采用分层缓存

---

在上图中，需要了解有关 Cloudflare CDN 及其所在的全球任播网络的一些重要关键点：

一个重要的区别是，Cloudflare 利用一个全球网络并在每个 Cloudflare 数据中心的每台服务器上运行每项服务，从而为最终用户提供与 Cloudflare 服务最接近的服务，并具有最高的规模、弹性和性能。
Cloudflare 是一个反向代理，这意味着它接收来自客户端的请求，并将请求代理回客户的源站。因此，每个请求在到达客户网络之前都会经过 Cloudflare 的网络。由于 Cloudflare 已在边缘（入口）强化并保护了其基础设施，因此所有客户也都受到了保护，免受基础设施级别和容量型 DDoS 攻击。请求和流量必须经过受保护的 Cloudflare 网络才能到达客户的源站。
Cloudflare CDN 利用 Cloudflare 全球任播网络。因此，传入的请求将被路由到距离用户最近的节点并由该节点进行响应。
任播的固有优势在于延迟更低、网络弹性更强、可用性更高，以及由于覆盖范围更大（可同时吸收合法流量负载和 DDoS 攻击）而增强的安全性。Cloudflare 的全球任播网络覆盖全球数百个城市↗，可在 50 毫秒内覆盖全球 95% 的互联网用户，同时提供超过 405 Tbps 的网络容量和 DDoS 防护能力。
Cloudflare 网络中的边缘节点缓存来自源服务器的内容，并能够通过缓存副本响应请求。Cloudflare 还使用相同的边缘架构提供DNS、DDoS 防护、WAF以及其他性能、可靠性和安全性服务。
Argo在 Cloudflare 网络中使用优化的路由和缓存技术，以更快、更可靠、更安全地向用户提供响应。Argo 包含智能路由和分层缓存功能。Cloudflare 利用 Argo 提供增强型 CDN 解决方案。

分层缓存

站点上线后，系统会默认配置标准缓存。使用标准缓存时，每个数据中心都充当源站服务器的直接反向代理。任何数据中心的缓存未命中都会导致请求从入口数据中心发送到源站服务器。

虽然标准缓存有效，但它并非最佳设计——靠近客户端的缓存内容可能已存在于其他 Cloudflare 数据中心，因此有时会导致源服务器不必要地过载。因此，最好启用分层缓存，该功能包含在所有 Cloudflare 套餐中。使用分层缓存，某些数据中心可以作为其他数据中心的源服务器的反向代理，从而提高缓存命中率并缩短响应时间。

分层缓存利用 Cloudflare 网络的规模来最大限度地减少对客户源的请求。当请求进入 Cloudflare 数据中心时，如果请求的内容未在本地缓存，则会检查其他 Cloudflare 数据中心是否存在缓存内容。

与数据中心和客户源服务器之间的连接相比，Cloudflare 数据中心之间的距离更短，路径更快，从而优化了对客户端的响应，并显著提高了缓存命中率。Cloudflare CDN 利用 Argo Smart Routing 数据来确定用于分层缓存的最佳上层数据中心。Argo Smart Routing 还可以作为插件启用，以便在出现缓存未命中和其他类型的动态流量时，提供数据中心和源服务器之间的最快路径。

Cloudflare CDN 允许客户配置分层缓存。请注意，根据 Cloudflare 套餐的不同，分层缓存的拓扑结构会有所不同。默认情况下，分层缓存处于禁用状态，您可以在主菜单的“缓存”选项卡下启用。

多的就不讲了，感兴趣的请自行查看内容分发网络 (CDN) 参考架构

优选方式

工具优选

在Gtihub有提供一个名为XIU2/CloudflareSpeedTest的项目，该项目可以为何用户提供多种优选姿势，无论是一键优选还是附带参数的优选，统统都有提供，具体使用方法请参考项目的README文件。

进阶使用

C:>cfst.exe -h

CloudflareSpeedTest vX.X.X
测试各个 CDN 或网站所有 IP 的延迟和速度，获取最快 IP (IPv4+IPv6)！
https://github.com/XIU2/CloudflareSpeedTest

参数：
-n 200
延迟测速线程；越多延迟测速越快，性能弱的设备 (如路由器) 请勿太高；(默认 200 最多 1000)
-t 4
延迟测速次数；单个 IP 延迟测速的次数；(默认 4 次)
-dn 10
下载测速数量；延迟测速并排序后，从最低延迟起下载测速的数量；(默认 10 个)
-dt 10
下载测速时间；单个 IP 下载测速最长时间，不能太短；(默认 10 秒)
-tp 443
指定测速端口；延迟测速/下载测速时使用的端口；(默认 443 端口)
-url https://cf.xiu2.xyz/url
指定测速地址；延迟测速(HTTPing)/下载测速时使用的地址，默认地址不保证可用性，建议自建；
当下载测速时，软件会从 HTTP 响应头中获取该 IP 当前地区码（支持 Cloudflare、AWS CloudFront、Fastly、Gcore、CDN77、Bunny 等 CDN）并显示出来。

-httping
    切换测速模式；延迟测速模式改为 HTTP 协议，所用测试地址为 [-url] 参数；(默认 TCPing)
    当使用 HTTP 测速模式时，软件会从 HTTP 响应头中获取该 IP 当前地区码（支持 Cloudflare、AWS CloudFront、Fastly、Gcore、CDN77、Bunny 等 CDN）并显示出来。
    注意：HTTPing 本质上也算一种 网络扫描 行为，因此如果你在服务器上面运行，需要降低并发(-n)，否则可能会被一些严格的商家暂停服务。
    如果你遇到 HTTPing 首次测速可用 IP 数量正常，后续测速越来越少甚至直接为 0，但停一段时间后又恢复了的情况，那么也可能是被 运营商、Cloudflare CDN 认为你在网络扫描而 触发临时限制机制，因此才会过一会儿就恢复了，建议降低并发(-n)减少这种情况的发生。
-httping-code 200
    有效状态代码；HTTPing 延迟测速时网页返回的有效 HTTP 状态码，仅限一个；(默认 200 301 302)
-cfcolo HKG,KHH,NRT,LAX,SEA,SJC,FRA,MAD
    匹配指定地区；IATA 机场地区码或国家/城市码，英文逗号分隔，大小写均可，仅 HTTPing 模式可用；(默认 所有地区)
    支持 Cloudflare、AWS CloudFront、Fastly、Gcore、CDN77、Bunny 等 CDN
    其中 Cloudflare、AWS CloudFront、Fastly 使用的是 IATA 三字机场地区码，如：HKG,LAX
    其中 CDN77、Bunny 使用的是 二字国家/区域码，如：US,CN
    其中 Gcore 使用的是 二字城市码，如：FR,AM
    因此大家使用 -cfcolo 指定地区码时要根据不同的 CDN 来指定不同类型的地区码。

-tl 200
    平均延迟上限；只输出低于指定平均延迟的 IP，各上下限条件可搭配使用；(默认 9999 ms)
-tll 40
    平均延迟下限；只输出高于指定平均延迟的 IP；(默认 0 ms)
-tlr 0.2
    丢包几率上限；只输出低于/等于指定丢包率的 IP，范围 0.00~1.00，0 过滤掉任何丢包的 IP；(默认 1.00)
-sl 5
    下载速度下限；只输出高于指定下载速度的 IP，凑够指定数量 [-dn] 才会停止测速；(默认 0.00 MB/s)

-p 10
    显示结果数量；测速后直接显示指定数量的结果，为 0 时不显示结果直接退出；(默认 10 个)
-f ip.txt
    IP段数据文件；如路径含有空格请加上引号；支持其他 CDN IP段；(默认 ip.txt)
-ip 1.1.1.1,2.2.2.2/24,2606:4700::/32
    指定IP段数据；直接通过参数指定要测速的 IP 段数据，英文逗号分隔；(默认 空)
-o result.csv
    写入结果文件；如路径含有空格请加上引号；值为空时不写入文件 [-o ""]；(默认 result.csv)

-dd
    禁用下载测速；禁用后测速结果会按延迟排序 (默认按下载速度排序)；(默认 启用)
-allip
    测速全部的IP；对 IP 段中的每个 IP (仅支持 IPv4) 进行测速；(默认 每个 /24 段随机测速一个 IP)

-debug
    调试输出模式；会在一些非预期情况下输出更多日志以便判断原因；(默认 关闭)
    目前该功能仅针对 HTTPing 延迟测速过程 及 下载测速过程，当过程中因为各种原因导致当前 IP 测速中断都会输出错误原因
    例如：HTTPing 延迟测速过程中，因为 HTTP 状态码不符合或测速地址有问题或超时等原因而终止测速
    例如：下载测速过程中，因为下载测速地址有问题（被阻断、403状态码、超时）等原因而终止测速（导致显示 0.00）

-v
    打印程序版本 + 检查版本更新
-h
    打印帮助说明

网站优选

关于网站优选，这里仅提供一个常用的地址，其它优选网站请自行搜索。

优选网站

该网站会提供各个IP所属运营商、ip地址、延迟Latency、丢包率Loss,通过这几个主要参数就可以判断出IP是否合适，因为Cloudfalre会不停的增删服务器，所以一切都有变故，如IP失效，请继续在此优选。

优选指标

延迟

延迟决定了这个CDN节点在你所在的网络环境下是否可以正常连接，在代理软件使用https与CDN进行连接的时候是有网络延迟的，这个网站所筛选出来的IP都是根据你现在网络所优选出的适合你当前网络的CDN，切换网络环境时就有可能达不到理论状态，有可能会出现网络变慢或者无法连接的情况。

同时，假如你的网络运营商换了，那节点的连通性和速度也会发生改变。请根据自己的网络事先选择好合适的运营商节点。

带宽

CDN节点的带宽也是衡量该CDN质量的重要指标，在流量的传输中，带宽取决于当前网络链路中外宽最低的那台设备，所以该节点的带宽就是整条链路的瓶颈。毕竟购买用于搭建节点的VPS一定是大带宽高流量的设备，任凭CDN设备跑也不会突破带宽限制。CDN带宽一般都是在1Mb到500Mb，理论上一定不会突破VPS物理带宽。

整条链路中，CDN既充当代理人的身份为你向外请求数据，又会将请求的数据重新发给你，所以CDN就决定了链路带宽的下限。

关于带宽的选择，其优先级应当是次于网路延迟，只有网络能联通才能考虑带宽，所以这两个参数都是极其重要的。高带宽意味着带宽冗余，在观看流媒体的时候可以明显看出其区别。高带宽就是可以观看高清晰度的视频，而低带宽的观看高清视频会出现卡顿与延迟，正常的非大流量行为不会受到带宽影响，也不会影响到你的网络聊天与网页访问。

应用场景

手动优选IP一般应用于网络加速服务，至于实际的场景，各位有需求的想必是心知肚明。

请注意：该方法具有时效性也挑场景，请各位根据自己的需求结合以上内容选择真正合适自己的。

以下是其常见的工作逻辑：

这张图详细展示了CDN（内容分发网路）的工作原理。

核心节点解析

1. 江苏用户（User）：发起请求的终端使用者。
2. **LDNS 本地DNS(Local DNS)**：使用者电脑配置的本地域名伺服器，通常由网路服务提供者(ISP)提供。它是使用者发出DNS解析请求的第一站。
3. **DNS伺服器(DNS Server)**：网站的权威DNS伺服器，负责管理juejin.cn这个网域的记录。
4. **CDN厂商(CDN Provider)**：CDN服务提供商的整体系统，其核心是将内容分发到各地的伺服器(边缘节点)。
   ***调度系统(Scheduling System)**：CDN的核心智慧部分。它根据使用者的地理位置、网路状况、边缘节点的负载等因素，智慧地将使用者导向最近、最快的边缘节点。
   ***管理(Management)**：负责CDN内容的更新、快取策略的配置和分发。
   ***(江苏)边缘节点((江苏)Edge Node)**：CDN在全国各地部署的伺服器。它们快取网站内容，直接响应附近使用者的请求，从而减少延迟。
5. **源站(Origin Server)**：网站内容的原始伺服器。当CDN边缘节点没有请求的内容时，会向源站回源（获取内容）。

运行逻辑串联（分步解析）

整个过程可分为两个主要阶段：DNS解析阶段和内容请求阶段。

阶段一：DNS解析(步骤1-7)

1. 使用者发起请求（步骤1）：江苏使用者在浏览器中输入juejin.cn，浏览器首先向本地LDNS伺服器发出对juejin.cn的IP地址查询请求。
2. LDNS向权威DNS查询（步骤2）：本地LDNS没有juejin.cn的IP快取，因此向其权威DNS伺服器发出查询。
3. 权威DNS返回CNAME记录（步骤3）：权威DNS伺服器返回一个CNAME（别名）记录，指向CDN厂商的域名，例如juejin.cn.w.cdngsb.com。这一步是CDN工作的关键，它将请求的解析权转交给了CDN。
4. LDNS再次查询（步骤4）：LDNS收到CNAME记录后，会继续向CDN的调度系统查询juejin.cn.w.cdngsb.com这个域名的IP地址。
5. 调度系统返回边缘节点IP（步骤5）：CDN的调度系统根据LDNS的IP地址判断出使用者来自江苏，并找到一个离使用者最近、负载最轻的江苏边缘节点，将其IP地址（36.156.181.240）返回给LDNS。
6. LDNS快取IP（步骤6）：本地LDNS将这个IP地址快取起来，以便下次使用者再次请求时可以直接返回，加快解析速度。
7. LDNS返回IP给使用者（步骤7）：LDNS将解析得到的边缘节点IP地址返回给使用者的浏览器。

阶段二：内容请求与分发（步骤8-11）

8. 使用者发起内容请求（步骤8）：浏览器拿到IP地址后，直接向该IP地址（江苏边缘节点）发出对juejin.cn内容的请求。
9. 边缘节点处理请求（步骤9）：边缘节点收到请求后，会首先检查自己是否有该内容的快取。
   ***快取命中(Cache Hit)**：如果节点有快取，它会直接将快取内容返回给使用者，整个过程结束。这极大地提高了访问速度。
   *快取未命中（Cache Miss）：如果节点没有快取，它会向源站发出请求，获取原始内容。源站返回内容给边缘节点后，边缘节点会将内容快取下来（步骤10），再返回给使用者（步骤11）。
10. 边缘节点快取内容（步骤10）：在快取未命中的情况下，边缘节点从源站获取内容后，会将其储存到本地，以便后续同一地区的其他使用者请求时可以直接提供服务。
11. 返回给使用者（步骤11）：无论是快取命中还是从源站回源后，边缘节点最终都会将网站内容返回给使用者，使用者可以在浏览器中看到网页内容。

这个流程通过CDN的边缘节点，有效地将内容从远处的源站拉到靠近使用者的位置，从而大幅减少了网路延迟，提高了网站的访问速度和稳定性。

流量：分层缓存、智能分层缓存拓扑

分层缓存已通过智能分层缓存拓扑启用。该图描绘了两个独立的流量，总结如下。第一个流量（客户端 1）是来自客户端的请求，该请求进入数据中心 1。第二个流量（客户端 2）是同一资源的后续请求，该请求进入另一个数据中心（数据中心 2）。

核心概念：Anycast广播

在上一张图中，CDN是通过DNS解析（CNAME）将使用者请求导向最近的节点IP。而这张图的核心是Anycast技术。

Anycast是一种网路路由技术，它允许多个伺服器广播同一个IP位址。当使用者发出请求时，网际网路的路由协定（BGP）会自动将请求路由到离使用者网路最近的、正在广播此IP的伺服器。

这就解释了图中两个使用者（Internet User）是如何向同一个IP位址（Request 1和Request 2都指向DC1和DC3的IP）发起请求，但被导向了不同的资料中心。与DNS导向相比，Anycast在网路层面实现了更快速、更直接的流量分发。

---

Cloudflare网路架构节点解析

图中的 Cloudflare 网路分为两个主要层级：

1. Lower Tier(下层)资料中心：
   *如图中的DC1和DC3，这些是边缘资料中心，数量最多，遍布全球。它们是使用者请求的第一站。
   *这些节点部署了多种服务，用于即时处理和过滤流量：
   DNS：处理域名解析请求。
   *DDoS：即时缓解分散式阻断服务攻击。
   *WAF（Web Application Firewall）：保护网站免受常见的应用层攻击（如SQL注入、跨站脚本等）。
   *Bot Management：区分并管理来自合法或恶意机器人的流量。
   API Gateway：管理和保护API流量。
   *Cache/CDN：快取静态内容，直接响应使用者请求。

2. Upper Tier(上层)资料中心：
   *如图中的DC6，这些是规模更大、更集中的核心资料中心。它们充当下层资料中心和**源站(Origin)**之间的桥梁。
   *当下层资料中心没有快取内容时，请求会被导向这里。这些上层节点通常有更丰富的快取内容，并且与源站的网路连接更优越。

---

请求与响应的运行逻辑

整个流程可以分为两个路径：一个是快取命中，一个是快取未命中（回源）。

1. 使用者发起请求：

• Internet User向Cloudflare广播的IP位址发出请求。
  *基于Anycast路由，请求被导向网路层面上最近的Lower Tier资料中心（例如，一个使用者被导向DC1，另一个被导向DC3）。

2. 下层资料中心处理：
   *Lower Tier资料中心收到请求后，首先会通过DDoS、WAF和Bot Management等服务对请求进行安全审核和过滤。
   *如果请求的内容在本地Cache/CDN中，则直接返回响应，此时整个过程结束。这就是最快的情况。

3. 请求转发到上层（快取未命中）：
   *如果下层资料中心没有快取内容，它会将请求转发到Upper Tier资料中心(DC6)。
   *DC6检查其更庞大的快取。如果快取命中，它将直接返回响应给下层资料中心。

4. Back Source to Original Server: a.
   *如果上层资料中心也没有快取内容，它会发出最终请求，回源到Origin（原始伺服器）以获取内容。

5. 响应返回：

• Origin将响应传回给Upper Tier资料中心(DC6)。
  *DC6会快取此响应，然后传给Lower Tier资料中心(DC1或DC3)。
  *Lower Tier资料中心也会快取此响应，并最终将其传回给Internet User。

这种多层级、Anycast驱动的架构，让Cloudflare不仅能高效分发内容（CDN），还能在距离使用者最近的网路边缘对流量进行多重安全过滤，提供了更强大的性能和防护能力。

区域分层缓存

智能分层缓存和全局分层缓存的主要区别在于可以与源服务器通信的上层缓存数量。智能分层缓存会使用 Argo 性能和路由数据选择距离源服务器最近的上层缓存。这意味着所有MISS在下层缓存中遇到的请求都将流经该上层缓存，从而有更高的几率到达缓存HIT，避免将流量发送到源服务器。然而，这种架构的缺点是下层缓存可能位于与上层缓存相距甚远的地方。即使上层缓存能够处理请求，上下层缓存之间的距离仍然可能增加响应延迟，具体取决于传输距离。总而言之，智能分层缓存确保所有缓存请求都流经单个上层缓存位置，从而提高缓存HIT利用率，并减少对源服务器的请求，但是，由于上层缓存可能与发出请求的下层缓存相距甚远，因此处理这些请求的延迟可能会更高。

借助通用全局分层缓存，Cloudflare 使用其全球最大的数据中心作为上层缓存，这意味着，通常情况下，上层缓存与下层缓存的距离更近。当下层缓存需要将请求传递到上层时，这可以显著降低延迟。然而，这最终会增加源服务器处理的请求量，因为每个上层缓存都需要从源服务器进行填充。总而言之，通用全局分层缓存可以在缓存填充后缩短响应时间，但也会增加源服务器的负载。

区域分层缓存通过在架构中添加额外的缓存层，将这两种策略的优势完美结合。将区域分层缓存选项与智能分层缓存结合使用意味着，虽然存在一个距离源站最近的上层缓存位置，但在上层和下层之间添加了一个地理位置更靠近下层的区域层。现在，来自下层的请求在发送到上层之前会先检查区域层是否存在缓存。单个区域层可以接受来自多个下层缓存的请求，因此可以显著改善全局可用应用程序的性能和延迟。

建议将区域分层缓存与智能分层缓存和自定义分层缓存配合使用。但是，对于在多个区域拥有多个上层缓存的客户（例如通用全局分层缓存），区域分层缓存并不适用。

流量：分层缓存、智能分层缓存与区域分层缓存

在图 5 中，分层缓存已启用智能分层缓存拓扑。该图描绘了启用区域分层缓存的智能分层缓存拓扑。较低层级的缓存在遇到缓存时，MISS会首先将请求发送到更本地的区域中心数据中心，以查看该缓存是否可以处理该请求。如果无法处理，则请求将继续发送到上层，然后根据需要发送到源服务器。

这张图是Cloudflare Anycast 网路的进阶架构，相比全局区域缓存，它增加了一个新的层级：**区域层 (Regional Tier)**。这使得整个网路结构更加分层和高效。

---

三层级架构解析

1. Lower Tier（下层）资料中心：

• 这是最边缘的节点，数量最多，也是使用者请求的第一站。
• 它们主要负责前端流量处理，包括DDoS缓解、WAF保护、Bot管理，并提供最基础的快取（Cache / CDN）。其核心职责是在离使用者最近的地方处理请求，以达到最低延迟。

2. Regional Tier（区域层）资料中心：

• 这是新加入的层级，位于下层和上层之间。
• 它们通常是区域性的网路中心，承担着该区域内所有下层节点的回源请求。
• 区域层的快取容量和处理能力通常比下层节点更大更强。它减少了下层节点直接回源到更远的上层节点或源站的频率，极大地提高了区域内的快取命中率和性能。

3. Upper Tier（上层）资料中心：

• 这是网路的核心，负责处理最终未命中的请求。
• 它们直接连接源站 (Origin)，拥有最大的快取容量和最稳定的网路连接。当区域层都没有请求内容时，请求才会到达这里，并最终回源。

---

请求与响应的运行逻辑（三层级版）

这个新架构的运行流程更精确，旨在减少不必要的长距离回源。

1. **请求发起 (Request)**：

• 使用者发起请求，Anycast 技术将其路由到地理位置最近的 Lower Tier 资料中心 (DC1、DC2 或 DC3)。

2. 下层节点快取查询：

• 下层节点接收请求后，首先检查本地快取。如果命中，直接返回响应。

3. 请求转发至区域层：

• 如果下层节点未命中快取，请求会被转发到所属区域的 Regional Tier 资料中心 (DC4 或 DC5)。

4. 区域层快取查询：

• 区域层节点检查其快取。如果命中，则从这里返回响应给下层节点。这就是三层架构的核心优势，它在边缘节点和核心节点之间增加了一层快取，截留了大量请求，避免了流量涌向上层。

5. 请求转发至上层：

• 如果区域层节点也未命中快取，请求会被转发到 Upper Tier 资料中心 (DC6)。

6. 最终回源：

• 上层节点检查快取。如果仍未命中，它会最终回源至 Origin 原始伺服器。

7. 响应返回与快取：

• 来自 Origin 的响应会沿着相反的路由返回：先到 Upper Tier，然后到 Regional Tier，最后到 Lower Tier。在每一层，内容都会被快取起来，以备将来的请求使用。

这种三层级架构确保了大多数请求在离使用者最近的边缘或区域层就能得到满足，仅在必要时才触及最远的核心层和源站，从而显著提升了性能、可靠性和安全性。

流量：缓存预留拓扑

缓存预留如何帮助减少原始服务器上的负载，同时帮助重新填充上层和下层数据中心的缓存存储。

這張圖是在先前 Cloudflare 三層級架構基礎上的進一步優化，主要增加了一個新的關鍵節點：Cache Reserve。

---

新增節點：Cache Reserve

Cache Reserve 是一個位於上層資料中心和源站 (Origin) 之間的持久化快取層。

與傳統的快取（位於下層、區域層、上層）不同，傳統快取通常是暫時性的，它會根據內容的熱門程度和快取時間過期策略來清除不常訪問的內容。

而 Cache Reserve 則是一種永久性的儲存層。它的作用就像一個完整的內容備份倉庫。即使某些內容非常冷門，在所有邊緣快取中都已過期被清除，它仍會被保留在 Cache Reserve 中。

這個節點的優勢非常明顯：

• 減少回源壓力：它大幅減少了對源站的回源請求，特別是針對那些不常訪問但仍需被快取保護的內容。
• 提高可靠性：即使源站不可用，大部分內容仍可以從 Cache Reserve 中快速檢索並提供給使用者。
• 降低成本：它減少了源站的頻寬和計算成本。

---

運行邏輯（四層級版）

這個新架構將回源路徑劃分為四個層級的快取檢查，最終目標是盡可能地不觸及源站。

1. 邊緣層快取查詢：
   • 請求到達最近的 Lower Tier 節點。如果內容命中快取，直接返回。
2. 區域層快取查詢：
   • 如果下層未命中，請求轉發到 Regional Tier 節點。如果快取命中，從這裡返回。
3. 核心層快取查詢：
   • 如果區域層也未命中，請求轉發到 Upper Tier 節點。如果快取命中，從這裡返回。
4. Cache Reserve 查詢：
   • 如果所有上游快取（上層、區域層、下層）都未命中，在向源站發出請求前，會先檢查 Cache Reserve。如果內容在這裡命中，則直接返回，避免了與源站的通訊。
5. 最終回源：
   • 只有當 Cache Reserve 仍未命中時，才會發出最終的請求，從 Origin 原始伺服器獲取內容。

整個響應返回路徑依然是相反的：Origin -> Cache Reserve -> Upper Tier -> Regional Tier -> Lower Tier -> User。每經過一個節點，內容都會被快取，以備將來使用。