Preface

原本我不太想写这片文章，因为从根本上来说，”自选IP”、”优选IP”、”优选域名”这些概念都不是官方说法，说好听点是”民间偏方”，说难听点是”邪道”(老界王神如实说)，我在之前的文章中也有专门的篇幅纠正过这个说法(参见文章：Home Data Center Series Cloudflare Tutorial (VII) Introduction to CF Worker Functions and Practical Operation, Verification and Research on Related Technical Principles of Implementing "Beggar Version APO for WordPress" Function to Accelerate Website Access Based on Worker中关于优选IP部分的描述)。不过，时至今日，看到仍然不少的朋友因为不了解cloudflare CDN加速网站访问的原理，没有按照cloudflare官方的优化理念对网站访问进行优化，反而是把精力花在研究这些”邪道”上面(君不见超级赛亚人3最后连正常聚气都做不到了？)，想想还是写了这片文章，至少让大家能够把力气真正用在刀刃上。

Note 1: This article is purely a technical explanation and is not directed at anyone. Please forgive me if I accidentally offend anyone with my words. Of course, if you have different technical opinions, you are welcome to discuss them in the article comment section or message board.

Note 2: Although CDN accelerates website access is just a sentence, its actual implementation actually involves many technical points, not to mention Cloudflare's CDN. In order to explain it clearly, I can only start from the beginning.

Background

Once upon a time

Before CDN technology became popular, the traditional way of building a website was to build a server in your own computer room. At that time, for the self-built computer room project, users had to apply for a line from a broadband operator (at first, the operator only provided a 2-megabit E1 interface, and users had to buy a Cisco 2600 router and use an E1 module to connect to the operator's E1 interface. The Cisco 2600's built-in 10-megabit electrical port was used as the RJ45 interface ultimately provided by the operator's line. Now, this is equivalent to buying a Cisco router as an optical-to-electrical converter to connect to the optical fiber provided by the operator. It's really luxurious to think about it, but this configuration was standard at that time). Then, they bought a firewall, used one electrical port as a WAN port to connect to the 10-megabit electrical port of the CIAC 2600 router, and one electrical port to connect to the intranet layer 3 switch as a LAN port. Then, they selected one of the IPv4 public network addresses provided by the operator as the NAT address from the intranet to the external network, and then selected one on the firewall to point the TCP port 80 of the public network IP directly to the port 80 of the intranet server IP. At most, they would configure a TCP port 21 mapping, and a computer room construction project was basically completed.

At that time, there were not many visitors (home broadband was not yet popular, it seemed to be ISDN?), and it was more than enough to publish the website using an IPv4 public IP + 2 megabit broadband. At that time, there was no concept of access experience. It was enough for the website page to be opened, and it didn’t matter whether it took 5 seconds or 8 seconds.

Later, with the rapid development of domestic home broadband and the emergence of multiple broadband operators, new problems arose: Telecom broadband users experienced extremely slow speeds when accessing websites with Netcom (now China Unicom) addresses, and the same was true for Netcom broadband users when accessing websites with Telecom addresses. This was because the traffic between operators would be settled across networks, and the fees were very expensive, so all operators unanimously restricted outbound traffic.

Therefore, at that time, major ICPs (NetEase, Sina, etc.) could only build data centers within the networks of China Telecom and China Netcom respectively to ensure that users of different operators had a good access experience without generating outbound network traffic (users of small operators suffered, such as China Tietong).

NetEase and Sina have only one domain name for external use. How can users of China Telecom and China Netcom accurately access the corresponding data centers of NetEase and Sina within their own operator networks when accessing the same domain name? This leads to the first important technical point: global server load balancing.

How DNS works

在讲”全局服务器负载均衡”之前需要先复习一下基础知识-“DNS的工作原理”。

When we surf the Internet normally, we just need to open the browser, enter the domain name we want to visit and press Enter, and then we can browse the web at will. However, this process that everyone is accustomed to is actually the result of the cooperation of a series of DNS servers, as shown in the following figure:

From the above figure, we can see that when the user enters the target domain name (starting withwww.tangwudi.comFor example) and press Enter, the user's operating system will first recursively ask the Local DNS server (that is, the DNS address that everyone usually configures directly on the computer or router, such as 223.5.5.5, 119.29.29.29, 8.8.8.8, etc.) for the IP address of the domain name you want to access. Then the Local DNS server will iteratively query the IP address of the target domain name from more upper-level DNS servers and return the result to the user. During this period, the upper-level DNS (root domain name server, top-level domain name server, authoritative domain name server) will see the Local DNS server asking questions from beginning to end, rather than the user's real IP (mark this point, it is very important).

Note 1: Actually, it is inaccurate to query Local DNS in the first step. If you really want to be picky, the first step should be that the browser queries its own DNS cache. If it exists, use it directly. If not, continue to move on. The second step is to call the operating system's function. At this time, you should first check whether there is a DNS cache in the local operating system. If it does, use it directly. If not, check the local host file. If not, it will initiate a request to Local DNS.

Note 2: Regarding DNS recursive query and iterative query, friends who are interested can study it by themselves. This is not the focus of this article, I just mentioned it casually.

Global Server Load Balance

Continuing with the previous topic, why can global server load balancing (hereinafter referred to as global load balancing, also called smart DNS) enable telecom users to access the corresponding data center within the telecom network and Netcom users to access the corresponding data center within the Netcom network?

The principle is actually very simple. According to the content of the DNS principle part in the previous section, the upper-level DNS server can see the request sent by the Local DNS, so as long as the authoritative DNS server responsible for the domain name resolution of NetEase and Sina can additionally determine the source IP address of the Local DNS: if the Local DNS is a telecom address, then the IP of the data center in the telecom network will be returned nearby; similarly, if the Local DNS is a Netcom address, then the IP of the Netcom intranet data center will be returned nearby.

不过，权威DNS服务器的主要职责毕竟是DNS解析，并且本来负担就大，还要额外多做事也不太合适，所以把这个额外的判断工作交给了专门的设备”全局负载均衡”来完成：本来Local DNS的查询到了权威DNS服务器就该得到结果了，现在权威服务器又多说了一句”我虽然是老大，但是这事我已经交给小弟全权处理了，这是它的地址，你去找它吧”，然后Local DNS又多了一轮查询(如下图红框所示)：

注1：全局负载均衡名字很高大上，其实本质上也就是一台正常的DNS服务器，只是因为其内置了全国(或者全球)的IP地址库，所以能够基于Local DNS的源IP判断其归属。比如基于bind9自建DNS服务器，只需创建包含不同解析结果的区域文件，然后使用view语句将不同的dns查询的来源IP地址段关联到不同区域文件即可实现最简单的”智能”解析。

Note 2: Professional global load balancing (such as F5's GTM) has more commercial functions. If it is deployed in multiple data centers and can cooperate with each other, and combined with the load balancing of multiple export links in the data center and the multi-active deployment of applications, these combinations can realize (same city/different location) disaster recovery data center, two-site three-center, and multi-active data center solutions.

How CDN works

“多重影分身”:让源站内容无处不在

One of the biggest problems with the traditional way of building a website is that the source server location is unique. For example, if the public network IP is 4.4.4.4, then users across the country (or even the world) can only go to this address according to the public network route to obtain the website content. If the network is smooth, it is fine. If the network is not smooth (similar to the previous restrictions between China Telecom and China Netcom, or domestic users want to visit foreign countries), the difficulty is no less than the journey to the West: you need to go through 81 difficulties.

那么，能不能在源站服务器位置唯一的情况下，让网站的内容遍布天下，让所有访问者都能即时取得呢？当然可以，就是对源站服务器使用”多重影分身术”：CDN。

虽然只有一个源站，但是通过CDN，理论上可以将源站内容镜像到全国各个区域的缓存服务器上(以nginx图标来代表缓存服务器)，可以让源站”无所不在”，同时也能将源站的性能压力卸载到各个缓存服务器上(理论上传统对源站的众多性能要求，比如并发连接数、新建连接数等都不那么重要了)：

However, in actual implementation, the entire source site content is not mirrored to the cache server. This is because directly mirroring the source site content to the cache server will have the following problems:

1. Storage efficiency and cost issues

• Massive data is difficult to mirror：The content on the source site may be very large, including a large number of files, videos, pictures, etc. If all the source site content is completely mirrored to all cache servers, a very large storage space is required. This will greatly increase the hardware cost of CDN operators, especially when multiple data centers distributed around the world need to store this data.
• On-demand caching is more efficient: Through the on-demand caching strategy, the CDN server only stores the content that the user has actually requested, reducing unnecessary storage consumption, improving storage efficiency and reducing costs.

2. Content dynamics and timeliness

• Dynamic content changes：Some content is dynamically generated or frequently updated, such as user personalized pages or real-time news. This type of content cannot be cached for a long time and needs to be retrieved from the source in real time according to user requests. Therefore, it is impossible to cache all of it to the CDN node through simple mirroring.
• Content timeliness：Some content may have a time limit, such as short-term event pages, discount information, or current news. Fully mirroring these contents may cause expired content to still be cached, causing user experience problems and data synchronization difficulties.

3. Network bandwidth and transmission costs

• Full mirroring increases bandwidth requirements：If all the content of the source station is transferred to the cache server, especially for some large websites or streaming platforms, huge bandwidth requirements will be generated. This not only increases the load on the source station, but also significantly increases the transmission cost, especially the cross-regional data transmission fee.
• Avoid unnecessary traffic：On-demand back-to-source can reduce unnecessary traffic transmission and only pull content from the source site when the user actually needs it. This can optimize the use of network resources and avoid wasting bandwidth.

4. Complexity of data update and synchronization

• The source site content is updated frequently: If the source site content is frequently updated, CDN needs to continuously monitor and synchronize all cached content, which increases complexity and management costs. The on-demand back-to-source model can reduce this complexity and only requires ensuring the latest version of the content when it is requested.
• Consistency management issues: Full mirroring to the cache server means that every time the source site is updated, all cache servers need to be updated synchronously, otherwise it will lead to inconsistent content. By returning to the source on demand, the CDN node can automatically check whether the content needs to be updated according to the cache strategy, effectively reducing the pressure of consistency management.

5. Differences in user needs in different regions

• Unbalanced content request distribution：Users in different regions have different demands for origin server content. For example, some content may only be popular in a certain region. Full mirroring of all content to global CDN nodes will result in a lot of unnecessary data storage, especially for content that is rarely accessed by users. On-demand retrieval can more intelligently cache relevant content according to the needs of different regions and optimize the use of storage resources.

因此，最终采用的办法是缓存服务器在需要时对源站进行”回源”(当CDN节点没有缓存到用户请求的内容时，需要将请求转发回到源站服务器来获取该内容)的方式，也就是吃自助餐提倡的”按需取餐”。

注：缓存服务器的”回源速度”是一个非常重要的考量因素，只不过，通常国内各个CDN供应商和国内云主机供应商之间网络都有优化(有些就是一家)，回源速度再慢也慢不到哪里去，所以这里不多讲。

Traditional DNS scheduling based on global load balancing

CDN虽然能用分布式的缓存服务器让源站内容”无所不在”，但是如何让用户能找到离自己最近的缓存服务器却是个值得考究的问题，最简单的实现就是全局负载均衡+各地分布的缓存服务器。

Visit my blog URL as a domestic userwww.tangwudi.comFor example, suppose I have deployed nginx servers in multiple regions across the country as cache servers. When a user requests accesswww.tangwudi.comWhen the global load balancing device that receives the DNS query request last will return an address that it considers to be the nearest cache server based on the Local DNS address used by the user as a reference, as shown in the following figure:

Therefore, after using global load balancing for DNS scheduling, users in each area will feel that their access speed is greatly improved (local access is of course fast~).

Note 1: In theory, if you use the DNS server address provided by the operator by default, such as 61.128.128.68 for Chongqing Telecom users and 61.139.2.69 for Chengdu Telecom users, then the global load balancing can accurately determine which operator's user initiated the DNS request, and the nearest IP address returned will be the most accurate. However, you may modify the address of the Local DNS for various reasons (for example, if you want to use Alibaba's doh, you will change the DNS server address to Alibaba's DNS address: 223.5.5.5). In this case, the nearest address returned by the global load balancing based on the judgment of the Local DNS server IP may not be the real nearest address, but it is all in China, and it is not noticeable if it is slow.

Note 2: In fact, there is also a way to carry the user's real IP in the DNS request, so that the global load balancing device can obtain the user's real source IP address and return the most effective nearby access IP. This technology is EDNS. However, this function requires the support of the DNS client, Local DNS and the final authoritative DNS server (it is best if all levels of DNS in the middle support it), so it is difficult to implement.

Limitations of CDN based on DNS scheduling

In the previous section, I used the simplest implementation method based on global load balancing to explain the working principle of CDN. Strictly speaking, although it is not wrong, it has limitations: this method is usually only suitable for specific, localized demand occasions, such as enterprise self-use or only providing services for a specific region (such as China). If you want to expand globally, this method will cause many problems:

1. Unable to achieve global traffic distribution

• Geographic location affects access speed: An important function of CDN is to route requests to the server node closest to the user based on the user's geographic location. This is fine for a single region, but if the service scope is expanded to the world and still relies solely on DNS or other methods to determine traffic routing, it may lead to inaccurate routing and slower response speeds.

2. More complex traffic management

• Limitations of DNS Load Balancing：CDN usually needs to rely on DNS load balancing to achieve traffic distribution. Although DNS load balancing can perform routing selection based on Local DNS addresses (or even user IP addresses implemented by EDNS), its accuracy and flexibility are not good enough (not to mention that everyone likes to change Local DNS addresses), and DNS records are updated slowly and cannot respond to network changes in real time.
• Failover is more complicated: If a node has a problem, a CDN using DNS routing may take some time to update the DNS record and redirect traffic to a healthy node.

3. High latency and inconsistent network performance

• Increased delays in cross-border traffic：Users’ requests may be routed to CDN nodes far away from them, especially when the DNS resolution of certain areas is not accurate enough. This will increase the cross-border network transmission time and affect the user experience.
• Inconsistent performance: Different users may experience different access speeds due to differences in network paths.

4. Higher network complexity and operating costs

• Requires complex geographic DNS setup：In order to achieve global or regional traffic optimization, CDN providers need to invest more time and resources to configure and maintain geographic DNS settings to ensure that user requests can be routed to appropriate nodes as much as possible. This not only increases operating costs, but also makes the system more complex.
• Regional congestion problem: Some regional nodes may bear more traffic, causing regional congestion problems to become more obvious.

5. Poor DDoS protection

• Difficult to disperse attack traffic：DDoS attacks may be concentrated on a specific IP address or node, making the node more vulnerable to being brought down and the entire service affected.
• Global protection is more difficult to achieve：It is difficult for CDN to disperse and absorb attack traffic through multiple nodes, affecting the overall security and stability.

6. Limited scalability

• Difficult to flexibly expand global nodes: CDN may need to configure the IP address of each node separately, which makes expansion more difficult and operation more complicated.

In order to deploy CDN globally, the above problems will be encountered, and the key to solving the problem is Anycast IP technology.

Anycast IP Technology

What is Anycast IP technology?

Anycast IP is a network routing technology. Its core idea is to assign the same IP address to multiple server nodes in different locations. In other words, multiple servers share one IP address. When a user sends a request to this IP address, the network will automatically route the request to the server node that is closest to the user or the best.

---

以肯德基外卖电话”400-880-3823″为例，当你拨打这个电话订餐时时，不论你在哪里，电话会自动连接到离你最近的那家KFC快餐店，这家快餐店会根据你的地址提供服务，整个过程对你来说是无缝的，你不需要手动选择哪家店，但是却享受了最近那家店的服务。

---

Going back to the previous picture, if Anycast IP technology is deployed nationwide andwww.tangwudi.comThe domain name resolution IP is bound to the anycast IP 10.10.10.10, so the global load balancing can be lazy and receive anywww.tangwudi.comThe domain name query will respond to 10.10.10.10 (of course, generally we are not so lazy, and we need to respond to different anycast IPs according to the customer area), and each user uses this IP as the target IP to access, and can still access the cache closest to him:

After CDN uses Anycast IP technology, the six problems mentioned in the previous section are all solved:

1. Global or regional traffic optimization

• Quick response：Through Anycast IP technology, user requests are automatically routed to the nearest CDN node. This significantly improves user access speed, especially in the case of cross-border access or global user distribution, and reduces latency.
• Intelligent traffic distribution: Anycast allows the same IP to be shared among multiple nodes around the world, so no matter where the user is, their requests will be intelligently assigned to the optimal server, thereby optimizing performance.

2. Simplify traffic management

• Real-time route optimization：Anycast IP automatically selects the best path, without the need for frequent updates or manual management like traditional DNS load balancing. This reduces the complexity of traffic management and improves network flexibility.
• Fast failover: Anycast can quickly switch traffic to other healthy nodes when a node fails, ensuring service continuity without having to rely on slower DNS updates.

3. Lower latency and consistent network performance

• Geographical advantage: Anycast IP ensures that users are connected to the closest node based on their physical location, which means lower network latency and more consistent performance for users around the world.
• Eliminate cross-border access delays: For cross-border or cross-regional traffic, Anycast can route requests through the optimal path, reducing network latency issues in data transmission.

4. Simplified network management and cost control

• Automatic traffic scheduling: Anycast simplifies geographic DNS settings, automatically routes user traffic to the optimal node, and reduces the complexity and management costs of manual configuration.
• Effectively distribute traffic：By balancing the traffic, it avoids overloading of a certain node, improves the efficiency and performance of the overall network, and reduces additional maintenance costs.

5. Enhanced DDoS protection

• Disperse attack traffic: When a DDoS attack occurs, Anycast technology can disperse the attack traffic to multiple nodes, reducing the pressure on a single node, thereby effectively alleviating the impact of the attack and improving network security.
• Global protection capabilities: Anycast allows attack traffic to be absorbed and dispersed globally, no longer limited to a certain area or node, which improves the overall network protection effect.

6. Flexible scalability

• Simplify global node expansion：With Anycast IP, CDN service providers can easily expand new nodes around the world without having to configure different IP addresses for each node. This expansion method is more flexible and faster, helping CDN service providers cope with the growing traffic demand.
• Balancing network load: When Anycast distributes traffic globally, it makes the traffic more balanced, reduces the risk of overloading a single node, and improves the stability and reliability of the service.

After using Anycast IP technology, the advantages of CDN are faster access speed (better than slow DNS queries), more flexible traffic management, more consistent network performance, stronger DDoS protection capabilities and more flexible scalability. These advantages enable CDN to better provide high-quality services to users around the world or in large areas, and ensure network stability and security. However, compared with the traditional DNS scheduling method, Anycast IP is much more difficult to deploy (involving backbone network optimization), so it is not suitable for small-scale CDN suppliers or enterprises to build their own CDNs.

Note: Anycast IP says it is an IP address, and it is indeed an IP address, but it is not the ordinary IP address (unicast IP) that we can see everywhere. In fact, it is more like a door with an uncertain exit covered with an IP address (just like Doraemon's Anywhere Door, which looks like an ordinary door, but can lead to anywhere after being pushed open. So even if you open the door and see place A outside at one time, it may become place B at the next moment).

Use cloudflare CDN to speed up website access

Global CDN based on Anycast IP

Cloudflare is a service provider that provides overall solutions to the world (including CDN, DDoS attack protection and other services). Most importantly, Cloudflare also provides a Free plan that benefits many individual webmasters (see article:Home Data Center Series CloudFlare Tutorial (I) CF related introduction and its benefits to personal webmasters), which includes unlimited traffic CDN. One of the key reasons why it is so powerful is its private backbone network and data centers that deploy Anycast IP all over the world:

Cloudflare's current situation in China

Unfortunately, even a powerful company like Cloudflare cannot build its own backbone network in China. The current compromise is to cooperate with JD Cloud and use JD Cloud's network to extend into China, which will lead to two problems:

1. Domestic network costs remain high

Will JD.com let Cloudflare get it for free? Cloudflare can save costs in other places because it built its own network. Now it has to cooperate with domestic cloud providers, and the high cost is imaginable. Therefore, for Cloudflare, the main purpose of using JD.com’s cloud network is to meet the needs of its own large enterprise customers (such aswww.qualcomm.cn,www.visa.cn等等)在国内网站的使用，为此还出现了一个中国特有的服务”中国网络访问”，一般Free计划的用户肯定就只能流流口水了：

---

上图红框中的”中国网络访问”里直接访问京东云国内30个数据中心的意思有2个 ：

• 1. The IP of the domain name resolution is the domestic public IP of JD Cloud (the global load balancing is based on the resolution result returned by the region), so domestic users can directly use the nearest JD Cloud domestic IP to access the website of cloudflare enterprise users. You can ping it with a normal network.www.qualcomm.cnandwww.ivsa.cnYou will know.
• 2. If the source site of the domestic website of a Cloudflare enterprise user is also set up in China, then when the domestic user cannot find the content required by the website in the cache server of the JD Cloud data center that they visit nearby, the cache server can directly return to the source from this JD Cloud data center.

---

2. The control over the network is far inferior to the backbone network built by itself

This is normal. After all, we are using JD Cloud's network, so we cannot configure it as we want like our own network. Moreover, the domestic network has many limitations, which makes many technologies that Cloudflare is good at not working well in China (such as Anycast):

这也使得cloudflare只能根据京东云的网络情况因地制宜的打造有”中国特色”的服务，也因此导致了cloudflare的企业级用户的网站在国内解析地址也只是普通的国内公网地址(非Anycast IP)。

Impact on individual webmasters using the Free plan

上面这2个问题直接导致的后果就是：京东云国内的任何网络只会为购买了”中国网络访问”服务的cloudflare企业级用户服务，和订阅其他计划的用户没有任何关系，也就是说，除了那部分企业级用户，对于订阅包括Free计划(也包括其他付费计划)的用户来说，cloudflare在国内相当于没有网(本来也没有～)。

这其实对目标用户群不包含国内的Free计划用户(搭建的网站)是没任何影响的，毕竟世界范围到处都是cloudflare的数据中心，其他区域的访问者在访问Free计划用户搭建的网站时，只需使用DNS解析的Anycast IP可以直接被分配到最近的数据中心，如果要回源的话直接从这个最近的数据中心回源就是。虽然也使用不了很多高级功能(比如”Argo Smart Routing”)，但是嘛，底子在那里，慢也慢不了太多(因为真实物理位置近)。

However, it is a disaster for individual webmasters (including me) whose target user base includes domestic Free plans, because there is no Internet in China. According to Cloudflare's management and optimization strategy for network resources, access requests from domestic visitors are usually directed by Cloudflare's Anycast IP to the data center in the western United States (the probability is higher in the San Joses data center). The direct result is slow access for domestic users.

---

Why are domestic Free users assigned to the San Jose data center? There are probably the following reasons:

• 1. Cost management: Cloudflare's Free plan is free, and companies usually allocate more high-quality resources (such as high-quality data centers in Asia) to paying users first. Data centers in the western United States are relatively cheap (the main reason) and are closer to mainland China (close geographical location, shorter submarine optical cables, and lower latency), so they have become a common allocation location for Free users.

• 2. Regional network restrictions: Mainland China has certain restrictions and regulatory requirements on foreign network services. Cloudflare’s traffic in mainland China needs to cooperate with local operators and data centers. This may also cause the traffic of non-paying users to be forwarded preferentially to US data centers, especially western data centers, because of their relatively close distance.

• 3. Network load balancing: Cloudflare's global network distributed traffic scheduling system will select the appropriate data center to handle traffic based on the network load. During peak traffic hours or when a specific area is overloaded, users of the Free plan may be assigned to a more distant server (such as the western United States) to reduce the burden on Asian data centers.

• 4. Partnership: Cloudflare currently cooperates with JD Cloud (previously Baidu Cloud) in China. Although this cooperation provides better access speeds for users in mainland China, this partnership prioritizes serving enterprise-level users who have purchased Chinese network access services, causing Free users' traffic to detour through foreign nodes.

---

In-depth analysis of the reasons why domestic users access websites slowly

In the last section, I mentioned that the reason why domestic users are slow when accessing websites built by cloudflare Free plan (for individual webmasters) is that they are assigned to the data center in the western United States. You may think that this is natural: because it is far away. Although this is indeed the case, it is also necessary to further divide the specific reasons for the slowness into multiple links for research, so as to facilitate targeted optimization later:

Let's take a look at the complete 4-step process including back-to-origin when a domestic user's access request does not hit the cache in the San Jose data center:

如果以上述场景简单的估算时间，可以看到如果需要回源，以单程时间为”1″计算，那么总体时间为”4″。

注1：访问用户被分配到哪个数据中心，之后如果有回源需求就会从哪个数据中心”发起”回源请求，这是铁律，对 cloudflare所有计划的订阅者都一样(包括企业版用户)，区别只在于企业级用户从开始就有更多的可选项(比如更多、更近的数据中心)，这点大家要注意。

Note 2: This is just the simplest simulation. In reality, the total time it takes to open a page is determined by how many round trips there are in steps 1 and 2 and how many round trips there are in steps 3 and 4.

Conventional optimization ideas

所谓常规优化思路，就是针对上节内容中的4步访问流程进行优化的思路：使用缓存规则或者页面规则的方式使第3、4步发生的次数尽量少，最好是没有，简单来说就是”Store up food and slowly claim the throne多缓存、少回源”。

Static Site

The optimization goal of this type of site is to cache the entire site without returning to the source (the so-called non-return to the source means that except for the first return to the source, there is no need for subsequent return to the source). You don't have to worry too much, just configure the cache rules of cloudflare and cache all the required content such as js, css, html, png, etc. The subsequent access speed will not be much slower (although the test speed is definitely not as good as the domestic 100ms, but the actual experience is not much different), and there is no need to worry about DDoS attacks.

You can use the hexo test site I deployed on cloudflare pages to experience it (only the default homepage, so make do with it):https://hexo.tangwudi.com.

Dynamic Site

这类站点优化目标是：尽量多缓存、少回源。不过动态站点和静态站点不同，有些内容是不能被缓存的，以wordpress为例，特定URI( “/wp-admin”、”/wp-login”、”/wp-comment”等开头的内容)以及包含特定cookie字段(“wp-“、”logged_in”、”wordpress”、”comment_“、”woocommerce_“)的请求均不能缓存，所以需要将这部分内容进行排除，而除了这些内容以外的内容都要进行缓存，需要按优先级从上到下的方式分层配置缓存规则的策略(详细配置方式参见文章：Home Data Center Series CloudFlare Tutorial (VI) CF Cache Rules Function Introduction and Detailed Configuration Tutorial).

Here is a comparison of the results. When my test WordPress site is accessed directly without using any cache rules (that is, completing steps 1, 2, 3, and 4), the time from sending a request to starting to receive data from the server (cloudflare data center) (TTFB) is 2.74 seconds:

After using the cache rule to cache all cacheable content, the TTFB time becomes 1.14 seconds:

It's good enough to be reasonable.

注1：TTFB (Time To First Byte)是”从发出页面请求到接收到应答数据第一个字节的时间总和”，它包含了DNS解析时间、 TCP连接时间、发送HTTP请求时间和获得响应消息第一个字节的时间，简单来说就是我们在浏览器输入域名并回车一直到看见页面内容开始出现的的时间。TTFB非常重要，因为平时我们在打开网页时整个网页内容全部呈现花了多少时间对用户来说其实并不敏感，真正敏感的是输入域名并按下回车，之后多久页面内容开始加载。

Note 2: The Tiered Caching feature is very important and must be enabled:

分层缓存功能对于回源有很好的优化效果，虽然国内访问用户回源必须从San Jose数据中心发起回源请求，但是开启分层缓存功能之后，却可以不直接从San Jose对源站进行回源，而是询问更靠近源站的顶层数据中心(比如位于亚洲的数据中心)，如果顶层数据中心缓存里也没有，那么顶层数据中心会对源站发起回源请求，在得到源站回复之后，通过cloudflare内部网络将内容告知San Jose数据中心，这比直接从San Jose数据中心通过公共网络以路由方式进行回源更快，分层缓存是唯一一种能在 Cloudflare 的 Free 计划中需要回源时，间接实现”就近回源”效果的机制。

Advanced optimization ideas - worker (suitable for dynamic sites)

所谓进阶优化思路，就是不在局限于cloudflare传统的缓存功能(基于缓存规则和页面规则)，而是采用worker功能，结合以前cloudflare在github上发过的一个js脚本”Edge Cache HTML”来更加灵活、智能的控制缓存功能(详细的配置参见文章：Home Data Center Series Cloudflare Tutorial (VII) Introduction to CF Worker Functions and Practical Operation, Verification and Research on Related Technical Principles of Implementing "Beggar Version APO for WordPress" Function to Accelerate Website Access Based on Worker).

Compared with CloudFlare's traditional caching function, the worker-based optimization method is more suitable for dynamic websites:

1. Fine-grained cache control
   • Worker Optimization Allows you to customize caching strategies for specific request types, URLs, user status, etc. For example, you can cache more content for logged-in users, and dynamically generate personalized parts for logged-in users. This flexibility is not possible with traditional caching rules.
   • Can be Custom Cache Key To decide which requests share the cache and which requests are cached independently, thereby improving the cache hit rate.
2. Partial caching of dynamic content
   • Workers allow you to cache static parts of dynamic pages. For example, the body of a blog post can be cached, while the personalized parts for logged-in users are fetched from the origin server. Shard Cache(Partial Caching) can significantly reduce server load and improve user response speed.
3. Higher cache hit rate
   • Using Workers can improve cache hit rates, especially in multi-user, complex content sites. By carefully controlling the cache strategy, you can maximize cache utilization and reduce unnecessary back-to-origin requests.
4. Avoid excessive back-porting
   • Workers can set different cache TTLs for certain resources, or implement Cache prefetching, when the user requests it, the old cache is returned, and the new content is asynchronously retrieved from the source to update the cache without affecting the user experience.

If your website has a lot of dynamic content and user interaction, the Worker optimization method will indeed bring significant performance improvements. For example, after using the worker optimization method on my test WordPress site, the TTFB was further reduced from 1.14 seconds with the traditional cache method to 332.52 milliseconds:

Note 1: Don’t forget to enable the layered cache function.

Note 2: For websites that mainly provide static content, traditional caching methods can achieve good results if configured properly, so there is no need to bother with it.

Additional knowledge: Argo Smart Routing

什么是”Argo Smart Routing”？

This feature actually has little to do with personal webmasters like us who mainly use it for free (it is paid and so expensive), but because it is a legitimate network-level optimization, I think it is worth mentioning.

---

“Argo Smart Routing”中的”Argo”并没有一个公开的具体缩写解释，但它可以理解为一个象征性名称，代表优化网络路径的解决方案。名字 “Argo” 可能是借用了希腊神话中的”Argonauts”(阿尔戈英雄)，他们是乘坐名为 “Argo”的船进行远航探险的英雄们。这对应了 Argo Smart Routing 的核心概念——通过最优的路径在全球网络中快速、智能地传递数据。

---

那么，什么是”Argo Smart Routing”呢？

Argo Smart Routing is an advanced network optimization service provided by Cloudflare that optimizes Internet traffic by:

• Intelligent routing: It dynamically selects the fastest and most reliable path based on real-time network conditions through Cloudflare's private network, rather than using traditional BGP protocol-based routing selection.

• Reduce latency and packet loss: By avoiding congested or poorly performing network paths, Argo is able to significantly reduce latency and improve the reliability of content delivery.

• Reduce back-to-source time: Especially for back-to-origin requests, Argo can find a faster path, thereby reducing the time for request back-to-origin and improving the overall response speed of the website.

“Argo Smart Routing”的优化原理

Let's take the access process in this picture as an example:

1. 智能路由选择（以国内用户—>San Jose 数据中心为例）

Without Argo Smart Routing:

When domestic users visit, their requests will be blocked by Cloudflare. Anycast IP Assign to San Jose Data Center。没有 Argo 时，用户的请求会按照默认的路由选择方式传输，可能经过以下路径：”国内 → 东南亚 → 太平洋海缆 → San Jose”，在某些情况下，这条路径可能较为拥堵或存在高延迟，影响用户的访问体验。

Using Argo Smart Routing:

Argo Smart Routing 可以动态检测到不同路径的网络状况，自动选择延迟更低、拥堵更少的路径。当Argo 检测到采用默认路由选择方式的路径出现延迟或拥堵时，它可以选择通过更快的路径，例如：”国内 → 香港 → 太平洋海缆 → San Jose”。这样，虽然国内用户仍然被分配到 San Jose Data Center, but the data transmission path has been optimized to reduce the round-trip time.

2. 降低延迟和丢包（以San Jose 数据中心—>国内用户为例）

Without Argo Smart Routing:

When transmitting data from the San Jose data center back to China, traditional routing may cause congestion on certain paths or instability of network nodes, which in turn causes packet loss. For example, when a data packet passes through a congested link (such as a submarine cable line), users may experience data loss, slow page loading, or even need to retransmit the data packet multiple times, resulting in higher latency.

Using Argo Smart Routing:

“Argo Smart Routing”能够监测不同网络节点的健康状况，避免丢包率高或网络不稳定的链路。当Argo 检测到从 “San Jose → 国内” 某条路径存在丢包或高延迟，它会自动选择更可靠的路径，例如：”San Jose → 新加坡 → 国内”或者”San Jose → 香港 → 国内”。通过这种智能调整，用户接收到的数据包更加稳定，减少了丢包现象，最终提升了访问体验。

3. Reduce the time to return to the source (taking the San Jose data center to the source server in China as an example)

Without Argo Smart Routing:

如果 San Jose数据中心没有缓存国内用户请求的内容，它会向位于国内的源站发起回源请求。在没有 Argo 时，这个回源请求会使用默认的互联网路由选择方式，可能通过以下路径：”San Jose → 东南亚 → 中国”或者 “San Jose → 太平洋海缆 → 中国”，这些路径可能较长，或者存在拥堵问题，导致回源时间增加。

Using Argo Smart Routing:

“Argo Smart Routing”可以基于实时网络状况选择从San Jose 数据中心到国内源站的最佳回源路径，当 Argo 检测到回源路径中的某个节点拥堵，它会绕开拥堵节点，选择一条更快的路径，如：”San Jose → 香港 → 北京”，或者 “San Jose → 新加坡 → 北京”，通过这种智能路由选择，回源路径得到了优化，数据从源服务器获取的时间大大减少。

It can be seen that although steps 1, 2, 3, and 4 still exist, they are much more flexible and efficient from the perspective of network routing.

注1：”Argo Smart Routing”可以算是万金油，除了对HTTP类型的应用，对其他任何类型的应用都有效，这就是”网络层优化”(非应用层优化)的牛逼之处。

Note 2: It also needs to be used with the hierarchical cache option.

Summary of cloudflare website optimization concept

From the various website optimization methods provided by Cloudflare, plus the default nearest access strategy, we can summarize Cloudflare's three optimization concepts in optimizing website access:

• 1. Proximity principle

This proximity principle includes allocating access users to the nearest Cloudflare data center (so Cloudflare needs to build a large number of data centers around the world, except for a few countries), and also includes the data center returning to the source server nearby.

注：关于就近回源这一点，除了开启”分层缓存”选项外，采用tunnel方式回源在某些时候会比采用公网地址方式回源更有优势。这是因为tunnel 建立了一条从cloudflare 数据中心到源站的私密路径，这可能绕过采用公网地址方式回源时潜在的公共线路拥堵和延迟。然而，具体的性能提升会依赖于网络状况、源站的物理位置、以及 Cloudflare 数据中心的分布，如果源站与 Cloudflare 数据中心之间的公共网络连接良好，性能差异可能不大。

---

理论上，使用 Cloudflare Tunnel 的 Free 计划用户”有可能”被分配到任何cloudflare数据中心，包括亚洲的数据中心。Cloudflare 会根据网络条件、流量负载和其他因素，自动将tunnel 连接到其认为的最优数据中心。因此，如果你在亚洲或你的用户大部分在亚洲，cloudflare可能会将tunnel连接到离你最近的亚洲数据中心。

However, for Free plan users' tunnels, Cloudflare's global network resource allocation may be subject to certain restrictions. Compared with paid plans, Free users' tunnels are more likely to be allocated to distant data centers during peak traffic hours. For example, even if you are geographically closer to a data center in Asia, Cloudflare may still allocate you to a distant location, such as a data center in the United States, due to load or other reasons.

因此，在 Free 计划下，”不能完全保证”Free计划用户的tunnel被连接到亚洲的数据中心，但它是有可能的(采用公网地址方式回源就没可能了～)，具体取决于 cloudflare 的网络动态分配。

仍然以之前的例子为例：国内访问用户被分配到San Jose数据中心，如果San Jose数据中心的缓存没有对应内容，会根据分层缓存的要求，向顶层数据中心(亚洲数据中心)请求内容，当顶层数据中心发现自己的缓存里也没有时，如果是公网地址回源方式，会直接通过公用网络向源站发起回源；如果是tunnel回源方式，tunnel 会接管此过程，确保通过安全的专线直接回源，绕过公共互联网，从而增强安全性并减少网络不稳定性。因此，使用”tunnel方式回源”在一定程度上相当于使用”公网地址回源”+”Argo Smart Routing”，多多少少又能白嫖一点。

However, the tunnel method is not a panacea. At present, the safest way to build a website in China is to use a domestic cloud host. For home broadband website building, it depends on the access strategy of the local broadband operator for the cloudflare IP address segment. Some places have been degraded, which may cause the tunnel itself to be unstable. Of course, most broadbands should be fine.

---

• 2. Route Optimization

After getting close, there is still a way to go. For the remaining road that must be taken, we will do our best to optimize it to make it easier to travel (Argo Smart Routing).

• 3. Use cache as much as possible

No matter how easy the road is to walk on, your feet will still hurt if you walk too much, so it is best to walk less. For example, in the past you had to get up early in the morning to go to the market in town to buy vegetables and meat, but now you only need to buy them at the farmers' market at the entrance of the village.

According to Cloudflare, points 1 and 2 are its business, and point 3 is what they want us to do ourselves.

民间偏方之”自选IP”、”优选IP”、”优选域名”

“自选IP”、”优选IP”、”优选域名”的由来：因为中国国内用户使用解析到的Anycast IP访问free计划用户建立的网站时，会被分配到美国西部的San Jose数据中心而导致访问慢，所以这些free计划的用户就想用自己国内的IP去解析一些cloudflare企业级客户的网站域名(比如www.visa.com)，获得其Anycast IP之后，使用特定软件去测试这些Anycast IP(或者干脆使用cloudflare公布的IP地址段)，找出不掉包而延迟最小的那个IP，最后手动把自己网站的解析ip改成这个IP。

In fact, this idea itself is good. It is intended to solve the problems of steps 1 and 2 in the above steps 1, 2, 3, and 4. It is also intended to manually implement the first step of Cloudflare's website optimization concept: the principle of proximity. However, although this method may seem to be able to "temporarily" improve the access speed of domestic users in certain specific cases, it is not a reliable or recommended approach in the long run (after I manually changed the IP address, I had to visit the blog every now and then to check whether the speed was normal. In the end, I was annoyed and changed back to the default resolution). There are several reasons for this:

1. The design of Cloudflare Anycast mechanism itself
• Cloudflare's Anycast IP allocation mechanism is global and relies on Dynamic Routing, which is automatically optimized and allocated by Cloudflare based on network conditions and geographic location. Although different Anycast IP segments correspond to different data centers, it does not simply determine the route based on the IP address, but dynamically determines it based on network topology and real-time factors such as latency and congestion.
• Even if you manually specify an IP address, Cloudflare may still dynamically adjust traffic paths based on global network conditions, so your manual modifications may not always maintain effective optimization results.

2. Violation of Cloudflare’s best practices and service design
• Manually changing the Anycast IP is not in line with Cloudflare's best practices. Cloudflare is designed to let users use its DNS service and intelligently assign the best path and IP through its network.
• Forcibly binding to a specific IP may cause the traffic to be identified as abnormal traffic by Cloudflare, affecting the stability of access or causing other unexpected problems, such as SSL certificate verification issues, performance fluctuations, etc.

3. Changes and uncontrollability of IP addresses
• Cloudflare regularly adjusts IP segments in different regions, and some specific Anycast IP segments may be reallocated or rerouted to other regions. If you manually specify an IP, it may be routed to a different region after a period of time, resulting in unstable access speed (taking the Doraemon's Anywhere Door mentioned in the previous Anycast IP section as an example, you push open the door and see that the outside is Chengdu. After closing the door, you think that the outside is always Chengdu, but in fact, the next moment the outside is Chongqing. Well, it's a bit like Schrödinger's cat. You don't know the result unless you actually open the door).
• In addition, Cloudflare provides different levels of services for different customers (such as Free and Enterprise plans). Manual resolution to enterprise customers' IP segments may lead to potential access restrictions or instability, because the allocation and resource scheduling of these IP segments are optimized for enterprise-level customers. The Free plan may not enjoy the same priority:

Besides, do you really think that Free plan users manually pointed the resolution IP to Cloudflare without knowing it? And have you not taken any precautions against this situation? You only need to enable SNI hierarchical monitoring on these IP segments: access requests from website domains of enterprise plan users will be processed correctly, and all others will be treated according to the default policy. You can do whatever you want.

4. CDN’s intelligent optimization function is bypassed
• Cloudflare’s free plan doesn’t have all the optimizations of the enterprise level, but it still takes advantage of Cloudflare’s global network and caching system. Manually binding an IP will bypass Cloudflare’s intelligent optimization and routing, and may cause you to lose some optimization effects, especially when network conditions change.

5. Potential Legal and Terms of Service Issues
• This practice may violate Cloudflare's terms of service, especially if you use unofficial means to obtain the IP addresses of specific corporate customers for manual resolution. Cloudflare may take action against such behavior and even terminate the service.

In fact, the above reasons are just official statements. The real reason why I don’t recommend it is that it’s too troublesome. If you have the energy to repeatedly mess with the IP, ask yourself first: Is the cache strategy configured properly? Is all the cached content cached? Have you tried to use the worker optimization method for dynamic sites of the WordPress type? After the configuration is completed, has the return request been reduced to the maximum extent? You should know that the most influential factors for website experience are too long TTFB time and frequent return to the source. If these are configured, for dynamic personal blog sites of the WordPress type, using the worker optimization method to open the page can achieve a TTFB experience of several hundred milliseconds; or using the traditional cache method to open the page to achieve a TTFB experience of more than 1 second, is this not enough to support normal visits to personal blogs?

In a word: Even if we are just freeloaders, we must do so with quality and dignity.

Summarize

Finally finished writing, so tired, I just wanted to express the meaning of the last paragraph, but found that it was unfounded, and to be convincing I need to first explain the optimization concept of cloudflare; then I thought that in this case, I should just explain the optimization concept of cloudflare first, but found that to explain the working principle of cloudflare's Anycast IP, I need to compare it with the working principle of traditional CDN; then I thought I should just explain the working principle of traditional CDN, but it involved the intelligent DNS scheduling of global load balancing; finally, when I wrote about the intelligent DNS scheduling of global load balancing, I found that to explain it clearly, I need to explain the basic working principle of DNS first. . . . Then I wrote so much without realizing it, I am really convinced. . .

But it was still very rewarding. I had only a vague understanding of several concepts before (including such an important layered caching function, which I had mentioned before and recommended to be enabled, but I didn’t pay too much attention to), and there were even some fallacies (I previously believed that Argo Smart Routing would change the data center that initiates the back-to-origin request). However, in order to write this article, I figured it out completely (it is really important to concretize simple ideas and turn them into text). Therefore, this article can also serve as a higher-level summary and conclusion of all the cloudflare-related content I wrote before.

Note: If you have any questions about the concepts in this article, you cancloudflare learning mapSearch in and you may find the answer.