Cloudflare's China Network: A Case Study

Hello everyone, this is Roy Zhai from Cloudflare TV. We co-work with local partner JD Cloud to provide most of the Cloudflare services in China.

We call it Cloudflare China Network.

Yeah, hi Bill. Yes, we provide most of application services in China, some of developer services.

And with China Express, a solution from our local partners, the customer may use Zero Trust services.

That's really cool.

We all know that closing China can optimize the accelerated website traffic within China.

Many of our colleagues as well as our customers ask me many questions about their business requirements in China.

One common question is that if the origin is out of China, can China network still accelerate the network?

Yes, it's a good question. We can still accelerate, but there is uncertainty out of our control.

The customer may have many big impacts when the traffic crosses the border.

I actually just did a test for one of our customers to analyze the latency issue.

We may have a look at the test results. Ah, that's a problem. Some customers will expect a matter with a long latency there.

Yes, the uncertainty could be reflected by too much latency.

Cloudflare callouts in China still need to route through the carriers path to the origin.

Each ISP will appear to different roles depending on the factors or algorithms at the moment.

China's Internet architecture differs from the rest of the world.

Some major ISPs control the network, but due to limited peering, traffic congestion is frequent.

Also, there are only three landing points for submarine optic fiber.

This creates a bottleneck for all users within China connecting to foreign origins.

Exactly.

That has been a topic for the customer for a long time. I believe the factors will reprioritize or new issues may come out over time.

The customer needs to pay a large amount of money and talk to each major ISP if they want to optimize the voting.

Theoretically, I think it will be okay for a networking company, but for the normal customers, that would be exhausting.

Do you think we could provide a sustainable solution for that?

That's true, but I'd like to introduce a solution delivered by our local partner to fit this scenario.

It's called China Express. As you can see from this picture, China Express is designed to mitigate such concerns for China network-enabled customers.

We leverage our partners' provide line to give customers a high performance of origin pool request.

By working with our China partners, they will provide us with special IPs that belong to their own pub in China.

For example, Shanghai, Beijing, and Guangzhou with NAT configuration.

They can bring one-to-one NAT to the customer's real origin IP. After the NAT configuration is done by our partner side, the only configuration from China network-enabled customer is to change their real origin IP to China Express IP on our dashboard DNS tab.

So the whole process is pretty straightforward.

I think this diagram just describes the design very clearly. And I see a lot of benefits from this kind of design.

I think the traffic will be directed along the design road, whatever the different ISPs or the different locations of IPOs in China.

And traffic back to the origin is also optimized and will be directed to the IPO efficiently.

With Cloudflare Workers, we can dynamically enable or disable the role we set in China Express.

And I have to highlight, I think this scenario has a precondition that the origin is a dedicated server or virtual machine or cloud vendor with a fixed IP or domain.

So I think this design can also avoid the congestion of the traffic when passing through the intercontinental peak traffic.

Yes, so let's dig into the real scenario and talk about how customers prepare the scenario.

First, we need customers to provide their origin IP to our local partner.

For example, they have a production domain called api.example.com.

And a record of this is this IP address.

Then we will provide this 34-point IP address to our local partner.

Our local partner will configure the NAT configuration on their router.

So after the configuration is done, they will provide us a new IP address.

That IP address belongs to our partners and it is inside of China.

Once our customers get this IP address from our local partner, they can configure it into our Cloudflare dash.

The first record I typed is the real origin IP address and it is the production domain the customer used.

Next, we add the China Express test domain.

This IP address is provided by our local partner and we have a common one called China Express origin.

That's pretty easy to configure, right?

Next, we will talk about how we set up the benchmark test on CatchPoint.

Right now, we have two tests. The UI of test A is the real origin one, which is the production domain api.example.com.

The test B is our China Express origin, which the URL is api.example.com.

Then we choose our China Performance Monitoring Group as the monitoring node.

It includes 40 nodes from China mainland.

They cover three ISPs, CT, CU, and CM. We set the random and frequency like this.

We ran on five random nodes from node groups and the frequency is five minutes.

In order to cover both on and off peak time in China, the test will last for 24 hours.

After we finish the monitoring, we will focus on the following metrics to benchmark our China Express solution with the public origin.

The metric we will focus on is the load time and download throughput.

The load time is the time from the first back to the last time of date for the response.

I think this one excludes the DNS time and the TLS time.

It is the total time of the dynamic request from the origin server.

Let's choose Chrome as the probe template.

We give the name China Express test. This test belongs to test A, which is our customer's real origin.

This dynamic request will use our public line, which may have congestion and packet loss.

We set up the monitoring time, which should be 24 hours.

We can keep this setting as default.

For the test node, we will override it and choose the China performance monitoring group, which we created beforehand.

Click Save.

We can see a new item appears.

We copy this test to create our next test. This test is based on our China Express solution.

We change the test URL to API Express, which points to the partner NAT IP address as our origin.

We keep the rest of things the same and click Save. OK, that's all. That's how we set up our whole process.

Alloy, I know you have spent 24 hours running the test.

Would you please share the test result with us? Yes, definitely. Now let's go through the report analysis part.

We have two test results shown on this picture.

The left-hand side is China Express test result, which shows lower -level and more stable load time on average.

Below is the table generated by CatchPoint, which shows the whole test window average data.

We can see China Express is 20% faster than public Internet on average load time metrics.

As we mentioned earlier in this video, in China, three major ISPs control the network, but due to limited peering, traffic congestion is frequent, especially during the peak hour.

When we dive into the peak hour data analysis, we prove rather than the whole test data.

The left -hand side is the China Express test result, shows fairly stable over peak hour.

The same metrics from a public Internet, which is the right-hand side diagram, shows unstable and drop of availability.

Also, we have more specific data analysis table as well, and give us more insight of how performance improves.

As we can see from this table, China Express result shows 54% of performance increase than public Internet.

Also, we got 20% improvement of download throughput.

Now, let's talk about the conclusion.

With Cloudflare, China Network, and China Express solution, we saw the average load time is 23% faster on average and 54% faster at peak hour.

Our customer is satisfied to see this overall result, especially in the Internet traffic peak time, and the overall connectivity availability enhancement as well.

Also solved the timeout issue while loading their management console and hybrid API queries.

We believe that providing a more stable and reliable China connection can help more customers in similar scenarios.

Wow, that's really impressive result.

I think our customers just get much excited for the scenario.

Sir Roy, very appreciate your sharing. Thank you very much. Thank you, Bill.

Thank you.