前言
原本我不太想写这片文章，因为从根本上来说，”自选IP”、”优选IP”、”优选域名”这些概念都不是官方说法，说好听点是”民间偏方”，说难听点是”邪道”(老界王神如实说)，我在之前的文章中也有专门的篇幅纠正过这个说法(参见文章：家庭数据中心系列 cloudflare教程(七) CF worker功能介绍及基于worker实现”乞丐版APO for WordPress”功能加速网站访问的实操、验证及相关技术原理研究中关于优选IP部分的描述)。不过，时至今日，看到仍然不少的朋友因为不了解cloudflare CDN加速网站访问的原理，没有按照cloudflare官方的优化理念对网站访问进行优化，反而是把精力花在研究这些”邪道”上面(君不见超级赛亚人3最后连正常聚气都做不到了？)，想想还是写了这片文章，至少让大家能够把力气真正用在刀刃上。
注1：这篇文章纯属技术上的阐述，没有针对谁的意思，如果不小心对谁有言语上的冒犯请见谅，当然如果大家有不同的技术意见也欢迎在文章评论区或者留言板进行讨论。
注2：CDN加速网站访问虽然只是一句话，但在真正的实现中其实包含了很多技术点，更别说cloudflare的CDN，为了能讲清楚，我只能从头开始说了。
背景知识
很久很久以前
在CDN技术大行其道之前，传统的建站方式还是以自建机房使用服务器搭建web网站为主流。当时的自建机房项目，找宽带运营商申请一个线路(最早运营商还只是提供2兆的E1接口，用户需要自己买一台cisco 2600路由器用E1模块连接运营商的E1接口，cisco 2600自带的10兆电口当做运营商线路最终提供的 RJ45 接口，搁在现在，就相当于买个cisco路由器当光电转换器用来连接运营商提供的光纤，想想真是奢华啊，不过那个时候这个配置可是标配)，然后买个防火墙，用一个电口当做 wan 口来连接 ciaco 2600 路由器的 10 兆电口，一个电口连内网三层交换机做lan口，然后从运营商送的一堆IPv4公网地址中选一个出来做内网到外网的NAT地址，再选一个在防火墙上将该公网IP的tcp 80端口直接指向内网服务器IP的80端口，顶多再配置一个tcp 21端口的映射，一个机房建设项目基本就算完事了。
那个时候，由于访问者还不多(家庭宽带都还没普及，貌似还是isdn？)，网站发布使用一个IPv4公网IP+2兆的宽带已经绰绰有余了，当时也还没有什么访问体验的概念，网站页面能打开就行，5秒还是8秒感觉也无所谓。
后来，随着国内家庭宽带的快速发展以及出现多家宽带运营商并立的格局，引发了新的问题：电信宽带用户访问网通(现在是联通)地址的网站速度奇慢无比，而对于网通宽带用户访问电信地址的网站同样如此，这是因为运营商之间的流量会进行网间结算，费用还很贵，各个运营商都不约而同的对出网流量进行限制。
所以，当时各大ICP(网易、新浪等)只能在电信、网通的网络内分别搭建数据中心，来确保不同运营商用户在不产生出网流量的情况下得到好的访问体验(小运营商用户就苦了，比如铁通)。
网易、新浪对外只有一个域名，如何能让电信和网通用户在访问同一个域名时，能够准确的访问到自家运营商网内网易、新浪对应的数据中心呢？这里就引出了第一个重要技术点：全局服务器负载均衡。
DNS工作原理
在讲”全局服务器负载均衡”之前需要先复习一下基础知识-“DNS的工作原理”。
我们正常上网时，只需要打开浏览器输入想要访问的域名并回车，之后就可以随意浏览网页了。只是这个大家都习以为常的过程其实是靠一系列DNS服务器合作的结果，如下图所示：
从上图中可以看到：当用户在浏览器中输入目标域名(以www.tangwudi.com为例)并回车之后，用户操作系统首先会向Local DNS务器(也就是平时大家直接在电脑或者路由器上配置的dns地址，比如223.5.5.5、119.29.29.29、8.8.8.8等等)服以递归的方式询问想要访问域名的IP地址，随后Local DNS服务器会以迭代的方式从更多上级DNS服务器那里查询到目标域名的IP地址，并把结果返回给用户，在这期间，上级DNS(根域名服务器、顶级域名服务器、权威域名服务器)从头到尾看到的都是Local DNS服务器在问东问西，而不是用户的真实IP(这点mark一下，很重要)。
注1：其实第一步就查询Local DNS是不准确的，如果真要较真，第一步、应该是浏览器查询自身的dns缓存，如果有则直接使用，如果没有则继续往下走；第二步、调用操作系统的功能，此时应该是先看操作系统本地的dns缓存里有没有，有则直接使用，没有就查本地的host文件，如果还没有，才会向Local DNS发起请求。
注2：关于DNS的递归查询和迭代查询，有兴趣的朋友可以自己研究下，这个不是本文的重点，只是随便提一嘴。
全局服务器负载均衡(Global Server Load Balance)
继续前面的话题，全局服务器负载均衡(下文简称全局负载均衡，也叫智能DNS)为什么能实现让电信用户访问电信网内对应的数据中心、让网通用户访问网通网内对应的数据中心呢？
原理其实很简单，根据上一节DNS原理部分讲述的内容，上级DNS服务器都能够看到Local DNS发来的请求，所以只要负责网易、新浪域名解析的权威DNS服务器能够额外判断一下Local DNS的源IP地址归属：如果Local DNS是电信地址，那么就近返回电信网内数据中心的IP；同样的，如果Local DNS是网通地址，就近返回网通内网数据中心的IP就行了。
不过，权威DNS服务器的主要职责毕竟是DNS解析，并且本来负担就大，还要额外多做事也不太合适，所以把这个额外的判断工作交给了专门的设备”全局负载均衡”来完成：本来Local DNS的查询到了权威DNS服务器就该得到结果了，现在权威服务器又多说了一句”我虽然是老大，但是这事我已经交给小弟全权处理了，这是它的地址，你去找它吧”，然后Local DNS又多了一轮查询(如下图红框所示)：
注1：全局负载均衡名字很高大上，其实本质上也就是一台正常的DNS服务器，只是因为其内置了全国(或者全球)的IP地址库，所以能够基于Local DNS的源IP判断其归属。比如基于bind9自建DNS服务器，只需创建包含不同解析结果的区域文件，然后使用view语句将不同的dns查询的来源IP地址段关联到不同区域文件即可实现最简单的”智能”解析。
注2：专业的全局负载均衡(比如F5的GTM)具备更多的商用功能，如果部署在多个数据中心并且能够互相配合，同时结合数据中心多出口链路负载均衡以及应用的多活部署，这些组合起来就可以实现(同城/异地)灾备数据中心、两地三中心、多活数据中心方案。
CDN的实现原理
“多重影分身”:让源站内容无处不在
传统的自建网站方式一个最大的问题就在于源站服务器位置是唯一的。比如公网IP是4.4.4.4，那么全国(乃至全球)的用户访问都只能老老实实根据公网路由去这个地址获取网站内容，如果是网络通畅还好说，如果网络不通畅(类似以前电信/网通互相限制，或者国内用户想访问国外)，那难度简直不下于西天取经：需要经历九九八十一难。
那么，能不能在源站服务器位置唯一的情况下，让网站的内容遍布天下，让所有访问者都能即时取得呢？当然可以，就是对源站服务器使用”多重影分身术”：CDN。
虽然只有一个源站，但是通过CDN，理论上可以将源站内容镜像到全国各个区域的缓存服务器上(以nginx图标来代表缓存服务器)，可以让源站”无所不在”，同时也能将源站的性能压力卸载到各个缓存服务器上(理论上传统对源站的众多性能要求，比如并发连接数、新建连接数等都不那么重要了)：
但是在现实的具体实现中，并没有采取将源站内容全部镜像到缓存服务器，这是因为直接镜像源站内容到缓存服务器这种方式会有如下问题：
1. 存储效率与成本问题
• 海量数据难以镜像：源站上的内容可能非常庞大，包含大量的文件、视频、图片等。如果将所有源站内容完全镜像到所有缓存服务器上，需要非常巨大的存储空间。这会极大地增加CDN运营商的硬件成本，特别是全球范围内分布的多个数据中心都要存储这些数据。
• 按需缓存更高效：通过按需缓存的策略，CDN服务器只存储用户实际请求过的内容，减少不必要的存储消耗，提高了存储效率，降低了成本。
2. 内容动态性和时效性
• 动态内容的变化：某些内容是动态生成的或频繁更新的，例如用户个性化页面或实时新闻。这类内容无法被长期缓存，需要根据用户的请求实时回源获取最新版本，因此无法通过简单的镜像全部缓存到CDN节点。
• 内容时效性：某些内容可能有时效限制，比如短期活动页面、折扣信息或时事新闻。将这些内容完全镜像可能导致过期内容仍被缓存，带来用户体验问题和数据同步困难。
3. 网络带宽与传输成本
• 全量镜像增加带宽需求：如果将源站所有内容都传输到缓存服务器，特别是对于一些大型网站或流媒体平台，会产生巨大的带宽需求。这不仅增加了源站的负载，还会显著提高传输成本，尤其是跨区域的数据传输费用。
• 避免不必要的流量：按需回源可以减少不必要的流量传输，只在用户实际需要内容时才从源站拉取，这样可以优化网络资源的使用，避免浪费带宽。
4. 数据更新和同步的复杂性
• 源站内容更新频繁：如果源站内容频繁更新，CDN需要持续监控和同步所有缓存的内容，这增加了复杂性和管理成本。按需回源的模式则可以减少这种复杂性，只需要在内容被请求时确保其最新版本。
• 一致性管理问题：全量镜像到缓存服务器意味着每次源站有更新，所有缓存服务器都需要同步更新，否则会导致内容不一致。而通过按需回源，CDN节点可以根据缓存策略自动检查内容是否需要更新，有效减少一致性管理的压力。
5. 不同区域用户需求差异
• 内容请求分布不均衡：不同区域的用户对源站内容的需求是不同的，例如某些内容可能只在某个特定区域受欢迎。全量镜像所有内容到全球的CDN节点会导致很多不必要的数据存储，特别是针对那些几乎没有用户访问的内容。而按需回源可以更智能地根据不同区域的需求来缓存相关内容，优化存储资源的使用。
因此，最终采用的办法是缓存服务器在需要时对源站进行”回源”(当CDN节点没有缓存到用户请求的内容时，需要将请求转发回到源站服务器来获取该内容)的方式，也就是吃自助餐提倡的”按需取餐”。
注：缓存服务器的”回源速度”是一个非常重要的考量因素，只不过，通常国内各个CDN供应商和国内云主机供应商之间网络都有优化(有些就是一家)，回源速度再慢也慢不到哪里去，所以这里不多讲。
传统基于全局负载均衡的DNS调度
CDN虽然能用分布式的缓存服务器让源站内容”无所不在”，但是如何让用户能找到离自己最近的缓存服务器却是个值得考究的问题，最简单的实现就是全局负载均衡+各地分布的缓存服务器。
以国内用户访问我的博客网址www.tangwudi.com为例，假设我在全国多个区域都部署了nginx服务器来做缓存服务器，当用户请求访问www.tangwudi.com的时候，最后收到dns查询请求的全局负载均衡设备会根据用户使用的Local DNS地址作为参考返回一个它认为最近的缓存服务器地址，如下图：
所以使用了全局负载均衡进行了DNS调度之后，每个区域的用户都会感觉自己访问速度大大提升(本地访问当然速度快～)。
注1：理论上如果使用运营商默认提供的DNS服务器地址，比如重庆电信的用户使用61.128.128.68，成都电信的用户使用61.139.2.69，那么全局负载均衡能够准确判断出发起DNS请求的是哪个运营商的用户，返回的就近IP地址也会是最准确的。但是大家可能因为各种原因会修改Local DNS的地址(比如想使用阿里的doh，就会把DNS服务器地址改为阿里的DNS地址：223.5.5.5)，这种情况下，全局负载均衡依靠判断Local DNS服务器ip而返回的就近地址也未必就是真的最近，只不过都在国内，慢点也察觉不到而已。
注2：其实也有DNS请求中能携带用户真实IP的方式，这样全局负载均衡设备就能得到用户真实的源IP地址，从而返回最有效的就近访问IP，这种技术就是EDNS。不过这个功能需要dns客户端、Local DNS以及最终的权威DNS服务器均支持(中途各级DNS都支持最好)，所以实现难度比较大。
基于DNS调度方式实现CDN的局限
在上一节中，我使用最简单的基于全局负载均衡的实现方式讲述CDN的工作原理，严格意义上来说，虽然没有错，但是却有局限的：这种方式通常只适合特定的、局部化的需求场合，例如企业自用或者只针对特定区域(例如国内)提供服务，如果要做大做强扩展全球，这种方式就会产生很多问题：
1. 无法实现全球的流量分配
• 地理位置影响访问速度：CDN的一个重要功能是根据用户的地理位置将请求路由到离用户最近的服务器节点，单一区域还好，如果服务范围扩展到全球仍旧只依赖DNS或其他方式来决定流量路由，可能导致路由不准确、响应速度变慢。
2. 更复杂的流量管理
• DNS负载均衡的局限性：CDN通常需要依赖DNS负载均衡来实现流量分配。虽然DNS负载均衡可以根据Local DNS地址(甚至EDNS实现的用户IP地址)进行路由选择，但它的准确性和灵活性都不够好(更别说大家还喜欢改Local DNS地址)，且DNS记录更新较慢，无法实时应对网络变化。
• 故障切换更复杂：如果某个节点出现问题，使用DNS路由的CDN可能需要一定的时间才能更新DNS记录，将流量重定向到健康的节点。
3. 高延迟和不一致的网络性能
• 跨境流量延迟增加：用户的请求可能会被路由到远离他们的CDN节点，特别是当某些区域的DNS解析不够精确时。这会导致跨境网络传输时间增加，影响用户的体验。
• 不一致的性能：不同用户可能会因为网络路径的差异而体验到不同的访问速度。
4. 更高的网络复杂性和运营成本
• 需要复杂的地理DNS设置：为了实现全球或区域内的流量优化，CDN提供商需要投入更多的时间和资源来配置和维护地理DNS设置，以确保用户请求能够尽可能被路由到合适的节点。这不仅增加了运营成本，也使得系统的复杂性更高。
• 区域性拥堵问题：某些区域节点可能会承受更多的流量，导致区域性拥堵问题更加明显。
5. DDoS防护效果较差
• 难以分散攻击流量：DDoS攻击可能集中指向一个特定的IP地址或节点，导致这个节点更容易被击垮，整个服务受到影响。
• 更难实现全球防护：CDN难以通过多个节点分散和吸收攻击流量，影响整体的安全性和稳定性。
6. 扩展性受限
• 难以灵活扩展全球节点：CDN可能需要单独配置每个节点的IP地址，扩展难度更大，操作更复杂。
为了在全球范围内部署CDN，就会遇到上述问题，而解决问题的关键就是Anycast IP技术。
Anycast(任播) IP技术
什么是Anycast IP技术？
Anycast IP 是一种网络路由技术，其核心思想是将同一个IP地址分配给多个不同位置的服务器节点，也就是说，多个服务器共享一个IP地址。当用户向这个IP地址发出请求时，网络会自动将请求路由到距离用户最近的或最优的那个服务器节点。
以肯德基外卖电话”400-880-3823″为例，当你拨打这个电话订餐时时，不论你在哪里，电话会自动连接到离你最近的那家KFC快餐店，这家快餐店会根据你的地址提供服务，整个过程对你来说是无缝的，你不需要手动选择哪家店，但是却享受了最近那家店的服务。
回到之前那张图，如果全国部署了Anycast IP技术，并将www.tangwudi.com域名的解析IP绑定到10.10.10.10这个任播IP上，那么此时全局负载均衡完全可以偷懒，收到任何对www.tangwudi.com域名的查询都响应10.10.10.10(当然，一般不会这么懒，还有要根据客户区域响应不同的任播IP)，而每个用户使用这个IP作为目标IP进行访问，仍旧可以访问到离自己最近的缓存：
CDN使用了 Anycast IP 技术后，上一节提到的6个问题都得到了解决：
1. 全球或区域内的流量优化
• 快速响应：通过 Anycast IP 技术，用户的请求会自动路由到最近的 CDN 节点。这显著提升了用户访问的速度，尤其是在跨境访问或全球用户分布较广的情况下，减少了延迟。
• 智能流量分配：Anycast使得相同IP可以在全球多个节点共享，因此无论用户在哪里，他们的请求都会被智能分配到最优的服务器，从而优化性能。
2. 简化流量管理
• 实时路由优化：Anycast IP 自动选择最佳路径，无需像传统DNS负载均衡那样频繁更新或手动管理。这减少了流量管理的复杂性，提高了网络的灵活性。
• 快速故障切换：Anycast可以在某个节点出现故障时，快速将流量切换到其他健康的节点，确保服务的连续性，而不必依赖较慢的DNS更新。
3. 更低延迟和一致的网络性能
• 地理位置优势：Anycast IP 能够根据用户的物理位置，确保他们连接到最接近的节点，这意味着网络延迟降低，并为全球用户提供更一致的性能。
• 消除跨境访问延迟：对于跨境或跨区域的流量，Anycast可以通过最优路径路由请求，减少了数据传输中的网络延迟问题。
4. 简化的网络管理与成本控制
• 自动化流量调度：Anycast简化了地理DNS设置，自动将用户流量路由到最优节点，减少了手动配置的复杂性和管理成本。
• 有效分配流量：通过均衡流量，避免了某个节点过载，提升了整体网络的效率和性能，降低了额外的维护成本。
5. 增强的DDoS防护
• 分散攻击流量：当DDoS攻击发生时，Anycast技术能够将攻击流量分散到多个节点，减少单一节点承受的压力，从而有效减轻攻击的影响，提升网络的安全性。
• 全球防护能力：Anycast使得攻击流量可以在全球范围内被吸收和分散，不再局限于某个区域或节点，这提升了整体网络的防护效果。
6. 灵活扩展性
• 简化全球节点扩展：通过 Anycast IP，CDN服务商可以方便地在全球范围内扩展新节点，而无需为每个节点配置不同的IP地址。这种扩展方式更灵活、更快速，帮助CDN服务商应对不断增长的流量需求。
• 平衡网络负载：Anycast在全球范围内分配流量时，使得流量更加均衡，减少了单个节点过载的风险，提升了服务的稳定性和可靠性。
使用 Anycast IP 技术后，CDN 的优点在于更快的访问速度(比慢悠悠来回往返的DNS查询强)、更灵活的流量管理、更一致的网络性能、更强的DDoS防护能力以及更灵活的扩展性。这些优点使得CDN能够更好地为全球或大规模区域的用户提供优质的服务，并确保网络的稳定和安全，只不过，相对于传统的基于DNS调度的方式，Anycast IP的部署难度要高太多(涉及到骨干网优化)，所以并不适合小规模的CDN供应商或者企业自建CDN的场景。
注：Anycast IP 说它是 IP 地址，也的确是IP 地址，但是却又不是我们平时随处可见的普通的 IP 地址(单播 IP)，它其实更像外表披着IP地址的一扇出口不确定的门(就像哆啦A梦的任意门，看着是个普普通通的门，推开后却可能达到任何地方，所以即便某个时候推开门看到门外是A地，但是下一个时刻可能就变为了B地)。
使用cloudflare CDN加速网站访问
基于Anycast IP的全球范围CDN
cloudflare是面向全球提供整体解决方案的服务供应商(包括CDN、DDoS攻击防护等服务)，最关键的是，cloudflare还提供让众多个人站长受益的Free计划(参见文章：家庭数据中心系列 cloudflare教程(一) CF相关介绍及其对个人站长的助益)，其中就包含了无限流量的CDN，之所以能如此豪横，其中一个很关键的原因就是其遍布全球的部署Anycast IP的私有骨干网和数据中心：
cloudflare国内现状
可惜的是，牛逼如cloudflare也没办法在天朝自建骨干网。目前的折中方式是和京东云合作，利用京东云的网络延伸进国内，这会导致2个问题：
1、国内网络部分成本居高不下
京东可能让cloudflare白嫖吗？cloudflare在其他地方能省成本是因为自建网络，现在不得不和国内云供应商合作，成本高昂想都想得到，所以对于cloudflare来说，使用京东云网络的主要作用是满足自身企业级大客户(比如www.qualcomm.cn,www.visa.cn等等)在国内网站的使用，为此还出现了一个中国特有的服务”中国网络访问”，一般Free计划的用户肯定就只能流流口水了：
上图红框中的”中国网络访问”里直接访问京东云国内30个数据中心的意思有2个 ：
- 1、域名解析的IP是京东云的国内公网IP(全局负载均衡基于地域返回的解析结果)，所以国内用户可以直接使用就近的京东云国内IP来访问cloudflare企业用户的网站，这个大家可以自行用正常网络去ping
www.qualcomm.cn和www.ivsa.cn就能知道。 - 2、如果cloudflare企业用户国内网站的源站也是架设在国内，那么当国内用户在就近访问的京东云数据中心的缓存服务器中找不到网站需要的内容时，该缓存服务器可以直接从京东云的这个数据中心进行回源。
2、对网络的掌控远不如其自建的骨干网
这也很正常，毕竟是借用京东云的网络，肯定不可能像自家网络一样想怎么配就怎么配，况且国内的网络本来限制就大，导致很多cloudflare擅长的技术在国内不好使(比如Anycast)：
这也使得cloudflare只能根据京东云的网络情况因地制宜的打造有”中国特色”的服务，也因此导致了cloudflare的企业级用户的网站在国内解析地址也只是普通的国内公网地址(非Anycast IP)。
对使用Free计划的个人站长的影响
上面这2个问题直接导致的后果就是：京东云国内的任何网络只会为购买了”中国网络访问”服务的cloudflare企业级用户服务，和订阅其他计划的用户没有任何关系，也就是说，除了那部分企业级用户，对于订阅包括Free计划(也包括其他付费计划)的用户来说，cloudflare在国内相当于没有网(本来也没有～)。
这其实对目标用户群不包含国内的Free计划用户(搭建的网站)是没任何影响的，毕竟世界范围到处都是cloudflare的数据中心，其他区域的访问者在访问Free计划用户搭建的网站时，只需使用DNS解析的Anycast IP可以直接被分配到最近的数据中心，如果要回源的话直接从这个最近的数据中心回源就是。虽然也使用不了很多高级功能(比如”Argo Smart Routing”)，但是嘛，底子在那里，慢也慢不了太多(因为真实物理位置近)。
只是，对于目标用户群包含国内的Free计划的个人站长们(包括我)就惨了，因为国内没有网，而按照cloudflare对网络资源的管理和优化策略，来自国内访问者的访问请求通常会被cloudflare的Anycast IP引流到美国西部的数据中心(San Joses数据中心概率较大)，导致的直接结果就是国内用户访问慢。
为什么国内Free用户会被分配到San Jose数据中心？原因大概有以下几点：
• 1、成本管理：Cloudflare 的 Free 计划是免费的，企业通常会把更多优质的资源（例如亚洲的高质量数据中心）优先分配给付费用户。美国西部的数据中心相对较为廉价(主要原因)，且离中国大陆较近(地理位置近、海底光缆较短、延迟较小)，因此成为 Free 用户的常用分配地。
• 2、区域网络限制：中国大陆对国外的网络服务有一定的限制和监管要求，Cloudflare 在中国大陆的流量需要与当地的运营商和数据中心合作，这也可能导致非付费用户的流量被优先转发到美国数据中心，尤其是西部数据中心，因为其距离相对较近。
• 3、网络负载平衡：Cloudflare 的全球网络分布式流量调度系统会根据网络的负载情况选择合适的数据中心来处理流量。在流量高峰时段或者特定区域负载较大时，Free 计划的用户可能被分配到更远的服务器（如美国西部），以减轻亚洲数据中心的负担。
• 4、合作伙伴关系：Cloudflare目前在中国与京东云的合作(之前是百度云)，虽然这种合作为中国大陆用户提供了较好的访问速度，但这种合作关系优先服务购买了中国网络访问服务的企业级用户，导致 Free 用户的流量绕道国外节点。
国内用户访问网站慢原因深入分析
上一节我最后提到国内用户在访问cloudflare Free计划(的个人站长)搭建的网站会慢，是因为被分配到了美国西部的数据中心，大家可能会认为是理所当然：因为远。虽然事实也的确是因为如此，但是也有必要将具体慢的原因进一步拆分成多个环节来研究，这样才能便于后面进行有目的优化：
来看看国内用户的访问请求在San Jose数据中心没有命中缓存时，包括回源在内的4步完整的流程：
如果以上述场景简单的估算时间，可以看到如果需要回源，以单程时间为”1″计算，那么总体时间为”4″。
注1：访问用户被分配到哪个数据中心，之后如果有回源需求就会从哪个数据中心”发起”回源请求，这是铁律，对 cloudflare所有计划的订阅者都一样(包括企业版用户)，区别只在于企业级用户从开始就有更多的可选项(比如更多、更近的数据中心)，这点大家要注意。
注2：这个只是最简单的模拟示意，现实中到底有多少个1、2步的往返和多少个3、4步的往返决定了打开页面所花费的总体时间。
常规优化思路
所谓常规优化思路，就是针对上节内容中的4步访问流程进行优化的思路：使用缓存规则或者页面规则的方式使第3、4步发生的次数尽量少，最好是没有，简单来说就是”广积粮，缓称王多缓存、少回源”。
静态站点
这类站点优化目标是：全站缓存不回源(所谓不回源是指除了第一次回源，后续就不需要了)。也不用折腾太多，只要配置好cloudflare的缓存规则，把js、css、html、png等需要的内容全部缓存即可，之后的访问速度慢不到哪里去(虽然测试速度肯定不如国内的100ms以下，但是实际体验差不了太多)，而且还不用担心DDoS攻击。
大家可以使用我在cloudflare pages上部署的hexo测试站点来体验(只有默认首页，将就一下)：https://hexo.tangwudi.com。
动态站点
这类站点优化目标是：尽量多缓存、少回源。不过动态站点和静态站点不同，有些内容是不能被缓存的，以wordpress为例，特定URI( “/wp-admin”、”/wp-login”、”/wp-comment”等开头的内容)以及包含特定cookie字段(“wp-“、”logged_in”、”wordpress”、”comment_“、”woocommerce_“)的请求均不能缓存，所以需要将这部分内容进行排除，而除了这些内容以外的内容都要进行缓存，需要按优先级从上到下的方式分层配置缓存规则的策略(详细配置方式参见文章：家庭数据中心系列 cloudflare教程(六) CF Cache Rules(缓存规则)功能介绍及详细配置教程)。
来一张效果对比，我的测试wordpress站点，在不使用任何缓存规则，直接进行访问的时候(也就是完整走完第1、2、3、4步)，从发出请求到开始从服务器(cloudflare数据中心)开始接收数据的时间(TTFB)为2.74秒：
而使用缓存规则将可以缓存的内容都缓存之后，TTFB时间变为了1.14秒：
讲道理已经很可以了。
注1：TTFB (Time To First Byte)是”从发出页面请求到接收到应答数据第一个字节的时间总和”，它包含了DNS解析时间、 TCP连接时间、发送HTTP请求时间和获得响应消息第一个字节的时间，简单来说就是我们在浏览器输入域名并回车一直到看见页面内容开始出现的的时间。TTFB非常重要，因为平时我们在打开网页时整个网页内容全部呈现花了多少时间对用户来说其实并不敏感，真正敏感的是输入域名并按下回车，之后多久页面内容开始加载。
注2：分层缓存(Tiered Caching)功能非常重要，一定要打开：
分层缓存功能对于回源有很好的优化效果，虽然国内访问用户回源必须从San Jose数据中心发起回源请求，但是开启分层缓存功能之后，却可以不直接从San Jose对源站进行回源，而是询问更靠近源站的顶层数据中心(比如位于亚洲的数据中心)，如果顶层数据中心缓存里也没有，那么顶层数据中心会对源站发起回源请求，在得到源站回复之后，通过cloudflare内部网络将内容告知San Jose数据中心，这比直接从San Jose数据中心通过公共网络以路由方式进行回源更快，分层缓存是唯一一种能在 Cloudflare 的 Free 计划中需要回源时，间接实现”就近回源”效果的机制。
进阶优化思路-worker(适合动态站点)
所谓进阶优化思路，就是不在局限于cloudflare传统的缓存功能(基于缓存规则和页面规则)，而是采用worker功能，结合以前cloudflare在github上发过的一个js脚本”Edge Cache HTML”来更加灵活、智能的控制缓存功能(详细的配置参见文章：家庭数据中心系列 cloudflare教程(七) CF worker功能介绍及基于worker实现”乞丐版APO for WordPress”功能加速网站访问的实操、验证及相关技术原理研究)。
基于worker的优化方式和cloudflare传统的缓存功能比起来，更加适合动态类型的网站：
- 细粒度的缓存控制
• Worker 优化 允许你针对特定请求类型、URL、用户状态等条件自定义缓存策略。比如可以为未登录用户缓存更多的内容，而为登录用户动态生成个性化的部分。这种灵活性是传统缓存规则无法做到的。
• 可以通过 自定义 Cache Key 来决定哪些请求共享缓存，哪些请求独立缓存，从而提升缓存命中率。 - 动态内容的部分缓存
• Worker 允许你缓存动态页面的静态部分。例如，博客文章的主体内容可以缓存，而登录用户的个性化部分则从源服务器获取。这种 分片缓存（Partial Caching）能够显著减少服务器负载，并提高用户响应速度。 - 更高的缓存命中率
• 使用 Workers 可以提高缓存命中率，特别是在多用户、复杂内容的站点中。通过细致地控制缓存策略，你可以最大化缓存利用率，减少不必要的回源请求。 - 避免过度回源
• Worker 可以为某些资源设定不同的缓存 TTL，或者实现 缓存预取，在用户请求时将旧缓存返回，同时异步回源获取新的内容，更新缓存，而不影响用户体验。
如果你的网站有很多动态内容和用户交互，Worker 优化方式的确会带来显著性能提升，比如我的测试wordpress站点使用worker优化方式之后之后TTFB从传统缓存方式的1.14秒进一步降低到332.52毫秒：
注1：依旧不要忘记开启分层缓存功能。
注2：而对于主要提供静态内容的网站，传统缓存方式配置得当已经可以取得不错的效果了，就不需要折腾了。
附加知识：Argo Smart Routing
什么是”Argo Smart Routing”？
这个功能和咱们这种白嫖为主的个人站长其实关系不大(付费而且如此之贵)，但是因为其是堂堂正正网络级别的优化，所以我觉得还是可以提一下的。
“Argo Smart Routing”中的”Argo”并没有一个公开的具体缩写解释，但它可以理解为一个象征性名称，代表优化网络路径的解决方案。名字 “Argo” 可能是借用了希腊神话中的”Argonauts”(阿尔戈英雄)，他们是乘坐名为 “Argo”的船进行远航探险的英雄们。这对应了 Argo Smart Routing 的核心概念——通过最优的路径在全球网络中快速、智能地传递数据。
那么，什么是”Argo Smart Routing”呢？
Argo Smart Routing 是 Cloudflare 提供的一种高级网络优化服务，通过以下方式优化互联网流量：
• 智能路由选择：它通过 Cloudflare 的私有网络，基于实时网络状况动态选择最快、最可靠的路径，而不是使用传统的基于 BGP 协议的路由选择。
• 降低延迟和丢包：通过避开拥塞或性能不佳的网络路径，Argo 能够显著降低延迟和提高内容交付的可靠性。
• 减少回源时间：尤其是在回源请求上，Argo 可以找到更快的路径，从而减少请求回源的时间，提高网站的整体响应速度。
“Argo Smart Routing”的优化原理
还是以这张图中的访问流程为例说明：
1. 智能路由选择（以国内用户—>San Jose 数据中心为例）
未使用Argo Smart Routing：
当国内用户访问时，他们的请求会被 Cloudflare 的 Anycast IP 分配到 San Jose 数据中心。没有 Argo 时，用户的请求会按照默认的路由选择方式传输，可能经过以下路径：”国内 → 东南亚 → 太平洋海缆 → San Jose”，在某些情况下，这条路径可能较为拥堵或存在高延迟，影响用户的访问体验。
使用Argo Smart Routing：
Argo Smart Routing 可以动态检测到不同路径的网络状况，自动选择延迟更低、拥堵更少的路径。当Argo 检测到采用默认路由选择方式的路径出现延迟或拥堵时，它可以选择通过更快的路径，例如：”国内 → 香港 → 太平洋海缆 → San Jose”。这样，虽然国内用户仍然被分配到 San Jose 数据中心，但数据传输路径得到了优化，减少了往返的时间。
2. 降低延迟和丢包（以San Jose 数据中心—>国内用户为例）
未使用Argo Smart Routing：
从 San Jose 数据中心传输数据回国内时，传统路由选择可能导致某些路径拥堵或网络节点不稳定，进而引发丢包现象。例如：数据包经过一条拥堵的链路(如某条海缆线路)，用户可能会体验到数据丢失、页面加载缓慢，甚至需要多次重传数据包，导致更高的延迟。
使用Argo Smart Routing：
“Argo Smart Routing”能够监测不同网络节点的健康状况，避免丢包率高或网络不稳定的链路。当Argo 检测到从 “San Jose → 国内” 某条路径存在丢包或高延迟，它会自动选择更可靠的路径，例如：”San Jose → 新加坡 → 国内”或者”San Jose → 香港 → 国内”。通过这种智能调整，用户接收到的数据包更加稳定，减少了丢包现象，最终提升了访问体验。
3. 减少回源时间（以San Jose 数据中心到中国境内的源服务器为例）
未使用Argo Smart Routing：
如果 San Jose数据中心没有缓存国内用户请求的内容，它会向位于国内的源站发起回源请求。在没有 Argo 时，这个回源请求会使用默认的互联网路由选择方式，可能通过以下路径：”San Jose → 东南亚 → 中国”或者 “San Jose → 太平洋海缆 → 中国”，这些路径可能较长，或者存在拥堵问题，导致回源时间增加。
使用Argo Smart Routing：
“Argo Smart Routing”可以基于实时网络状况选择从San Jose 数据中心到国内源站的最佳回源路径，当 Argo 检测到回源路径中的某个节点拥堵，它会绕开拥堵节点，选择一条更快的路径，如：”San Jose → 香港 → 北京”，或者 “San Jose → 新加坡 → 北京”，通过这种智能路由选择，回源路径得到了优化，数据从源服务器获取的时间大大减少。
可以看出来，虽然第1、2、3、4步依然存在，但是从网络路由层面来说，却灵活高效了很多。
注1：”Argo Smart Routing”可以算是万金油，除了对HTTP类型的应用，对其他任何类型的应用都有效，这就是”网络层优化”(非应用层优化)的牛逼之处。
注2：也需要和分层缓存选项配合使用。
cloudflare网站优化理念总结
从cloudflare提供的多种网站优化方式，加上默认的就近访问策略，可以总结出cloudflare在优化网站访问方面的3点优化理念：
- 1、就近原则
这个就近原则包含了访问用户就近分配到cloudflare的数据中心(所以cloudflare需要在全球大量建立数据中心，少数国家除外)，也包含数据中心对源站的就近回源。
注：关于就近回源这一点，除了开启”分层缓存”选项外，采用tunnel方式回源在某些时候会比采用公网地址方式回源更有优势。这是因为tunnel 建立了一条从cloudflare 数据中心到源站的私密路径，这可能绕过采用公网地址方式回源时潜在的公共线路拥堵和延迟。然而，具体的性能提升会依赖于网络状况、源站的物理位置、以及 Cloudflare 数据中心的分布，如果源站与 Cloudflare 数据中心之间的公共网络连接良好，性能差异可能不大。
理论上，使用 Cloudflare Tunnel 的 Free 计划用户”有可能”被分配到任何cloudflare数据中心，包括亚洲的数据中心。Cloudflare 会根据网络条件、流量负载和其他因素，自动将tunnel 连接到其认为的最优数据中心。因此，如果你在亚洲或你的用户大部分在亚洲，cloudflare可能会将tunnel连接到离你最近的亚洲数据中心。
不过，对于 Free 计划用户的tunnel，cloudflare 的全球网络资源分配可能受到一定限制，相较于付费计划，Free 用户的tunnel更有可能在流量高峰时段被分配到较远的数据中心。例如，尽管你地理上更接近亚洲的某个数据中心，cloudflare 可能仍会因为负载或其他原因将你分配到一个较远的地点，比如美国的某个数据中心。
因此，在 Free 计划下，”不能完全保证”Free计划用户的tunnel被连接到亚洲的数据中心，但它是有可能的(采用公网地址方式回源就没可能了～)，具体取决于 cloudflare 的网络动态分配。
仍然以之前的例子为例：国内访问用户被分配到San Jose数据中心，如果San Jose数据中心的缓存没有对应内容，会根据分层缓存的要求，向顶层数据中心(亚洲数据中心)请求内容，当顶层数据中心发现自己的缓存里也没有时，如果是公网地址回源方式，会直接通过公用网络向源站发起回源；如果是tunnel回源方式，tunnel 会接管此过程，确保通过安全的专线直接回源，绕过公共互联网，从而增强安全性并减少网络不稳定性。因此，使用”tunnel方式回源”在一定程度上相当于使用”公网地址回源”+”Argo Smart Routing”，多多少少又能白嫖一点。
不过，tunnel方式也不是万能的，目前看来，国内使用tunnel方式建站最稳妥的是使用国内的云主机，对于家庭宽带建站而言，就要看当地宽带运营商对于cloudflare的IP地址段的访问策略了，有些地方做了劣化，可能就会导致tunnel本身不稳定。当然，大部分宽带应该都没问题。
- 2、路由优化
就近之后，仍旧还有路要走，对于剩下必须走的路，尽最大能力优化，让这条路更好走(Argo Smart Routing)。
- 3、尽可能多的利用缓存
就算再好走的路，走多了依旧会脚痛，所以最好还是能少走一点路，比如以前要起一大早去镇上赶集买菜买肉，现在只需要在村口的农贸市场买就行。
按照cloudflare的想法，第1、2点都是它的事，第3点才是希望我们自己做的事。
民间偏方之”自选IP”、”优选IP”、”优选域名”
“自选IP”、”优选IP”、”优选域名”的由来：因为中国国内用户使用解析到的Anycast IP访问free计划用户建立的网站时，会被分配到美国西部的San Jose数据中心而导致访问慢，所以这些free计划的用户就想用自己国内的IP去解析一些cloudflare企业级客户的网站域名(比如www.visa.com)，获得其Anycast IP之后，使用特定软件去测试这些Anycast IP(或者干脆使用cloudflare公布的IP地址段)，找出不掉包而延迟最小的那个IP，最后手动把自己网站的解析ip改成这个IP。
其实，这个想法本身是好的，是想解决前面提到的1、2、3、4步中第1、2步的问题，也是想手动实现cloudflare网站优化理念的第1步：就近原则，只不过，这种方式虽然看起来可能在某些特定情况下能够“暂时”改善国内用户访问速度，但从长远来看并不是一种可靠或推荐的做法(我以前手动改了IP之后，隔三差五就要访问博客看看速度正常不正常，最后被搞烦了，还是改回了默认解析)，有如下几点理由：
1. Cloudflare Anycast 机制本身的设计
• Cloudflare 的 Anycast IP 分配机制是全球性的，依赖于 动态路由，由 Cloudflare 根据网络条件和地理位置来自动优化和分配。虽然不同的 Anycast IP 段会对应不同的数据中心，但它并不是简单地根据 IP 地址来决定路由，而是根据网络拓扑和延迟、拥堵等实时因素动态决定。
• 即使手动指定某个 IP 地址，Cloudflare 依旧可能根据全球网络条件动态调整流量路径，因此你的手动修改未必总是能够维持有效的优化结果。
2. 违背 Cloudflare 的最佳实践和服务设计
• 手动更改 Anycast IP 并不符合 Cloudflare 的最佳实践。Cloudflare 的设计是让用户使用其提供的 DNS 服务，并通过其网络智能分配最佳的路径和 IP。
• 强制绑定到某个特定 IP 可能会让流量被 Cloudflare 识别为异常流量，影响访问的稳定性或导致其他不可预期的问题，比如 SSL 证书验证问题、性能波动等。
3. IP 地址的变化和不可控性
• Cloudflare 定期会在不同地区的 IP 段进行调整，某些特定的 Anycast IP 段可能会被重新分配或被重新路由到其他地区。如果你手动指定了某个 IP，它可能在一段时间后被路由到不同的区域，导致访问速度不稳定(以前面Anycast IP部分提到的哆啦A梦的任意门为例，你某个时候推开门看到门外是在成都，关上门后就认为门外一直是成都，但是实际上下一刻门外已经是重庆了，嗯，有点像薛定谔的猫，不实际打开门是不知道结果的)。
• 此外，Cloudflare 为不同的客户提供不同等级的服务（例如 Free 计划和 Enterprise 计划），手动解析到企业客户的 IP 段可能导致潜在的访问限制或不稳定性，因为这些 IP 段的分配和资源调度是针对企业级客户优化的，Free 计划可能无法享受到相同的优先级：
况且，真以为Free计划用户手动把解析IP指过去cloudflare不知道吗？并且还没有对这种情形做任何防备吗？只需要在这些IP段上启用SNI分级监测：属于企业计划用户网站域名的访问请求才正确处理，其他全部按照默认策略对待，爱咋滴咋滴就行了。
4. CDN 的智能优化功能被绕过
• Cloudflare 的免费计划虽然没有企业级的所有优化，但它仍然利用了 Cloudflare 的全局网络和缓存系统。手动绑定某个 IP 会绕过 Cloudflare 的智能优化和路由选择，反而可能会让你失去某些优化效果，尤其是当网络条件变化时。
5. 潜在的法律和服务条款问题
• 这种做法可能会违反 Cloudflare 的服务条款，尤其是如果你使用了非官方的手段去获得特定企业客户的 IP 地址进行手动解析。Cloudflare 可能会对这种行为采取措施，甚至终止服务。
其实上面这些理由都只是明面上的官方说法，我真正不推荐的理由是太折腾了，有那精力反复折腾IP的话，先问问自己：缓存策略到底配置好没有，该缓存的内容是不是都缓存了？wordpress类型的动态站点有没有尝试使用worker优化的方式？配置完成之后是不是最大化的减少了回源请求？要知道最影响网站体验的是TTFB时间太长以及频繁回源，如果这些都配置好了，对于wordpress类型的动态个人博客网站来说，使用worker优化方式打开页面可以达到TTFB几百毫秒的体验；或者使用传统缓存方式打开页面达到TTFB 1秒多的体验，这样还不够支撑个人博客的正常访问吗？
一句话：就算我们只是白嫖用户，但是也要有素质、有尊严的白嫖～。
总结
总算写完了，好累，本来只是想表达最后一段话的意思，结果发现没凭没据的，要有说服力需要先讲清楚cloudflare的优化理念；然后想着既然这样，就先把cloudflare的优化理念讲清楚就行了，结果发现要讲清楚cloudflare的Anycast IP，需要对比传统CDN的的工作原理；跟着想干脆把传统CDN的工作原理讲清楚得了，结果又牵扯到全局负载均衡的智能DNS调度；最后写全局负载均衡的智能DNS调度时，发现要讲清楚需要先说DNS的基本工作原理。。。。然后不知不觉写了这么多，我真的是服气了。。。
不过还是很有收获的，以前有几个概念似懂非懂，理解得并不透彻(包括如此重要的分层缓存功能，我之前虽然也讲过并建议打开，却也没有太过于重视)，甚至还有谬误的地方(我之前认为Argo Smart Routing会改变发起回源请求的数据中心)，不过为了写这篇文章算是彻底搞清楚了(把简单的思路具体化后变成文字真的很重要)，因此这篇文章也可以作为我给之前写的所有cloudflare相关的内容做的一个更高角度的概括与总结。
注：如果有朋友对本文中的诸多概念有不了解的部分，可以从cloudflare学习地图中查找，也许能够找到答案。
ヾ(≧∇≦*)ゝ
这个表情的意思是？～