Digital Experience Monitoring (DEX) offers device, application, and network performance monitoring, providing IT administrators with insights to quickly identify and resolve issues. With DEX notifications , account administrators can create configurable alert rules based on available algorithms (z-score, SLO) and existing DEX filters. When notification criteria are satisfied, customers are notified via email, Pagerduty, or Webhooks

As with other notification types, DEX notifications can be configured and reviewed from Cloudflare dashboard notifications.

DEX notifications address the challenge of proactively identifying issues affecting the digital experience of your end users. By monitoring device health and conducting synthetic tests from WARP clients deployed on your fleet's end-user devices, DEX provides valuable insights. These notifications empower IT administrators to quickly identify and address connectivity and application performance problems before they impact a wide range of users.

By proactively notifying administrators when problems arise, DEX helps minimize user disruption and provides peace of mind. Instead of actively refreshing and looking for issues as before, administrators can now receive immediate notifications. Management is simple, as notifications can be easily configured through the Cloudflare dashboard.

Administrators can now create three new notification types:

1) Device Connectivity Anomaly

Are you tired of manually monitoring your end-users' device connectivity? Do you want to be notified immediately when there's a sudden change? Our new DEX notification for Device Connectivity Anomaly alerts you when there's a significant increase or decrease in the number of monitored devices connecting or disconnecting to the WARP Client. This can be filtered by various characteristics such as data center (“colo”), platform (operating system), and WARP Client version.

We use a statistical method called z-score to detect anomalies in monitored device count. A z-score measures how many standard deviations a data point is from the mean. By comparing the current five minutes of data to the past four hours, we can calculate the mean and standard deviation. If the z-score value exceeds 3.5 or falls below -3.5, a notification is triggered.

Here's an example of a notification configuration for macOS devices in the UK using WARP Client version 2023.7.24:

2) DEX Test Latency 

Ever worry application performance is slow? We're thrilled to introduce DEX Test Latency notifications, which are designed for administrators who want to stay ahead of the curve when it comes to application performance. This notification proactively alerts you of significant spikes or drops in latency based on:

• HTTP Test: Resource Fetch Time measures the time it takes for a web browser to retrieve a specific resource from your application and deliver it to the end user.

• Traceroute Test: Round Trip Time measures the average time it takes for data packets to travel from your device to a specific destination IP address and back (when successful). Traceroute tests focus on the overall network performance between the test client/device and your application.

This notification can be filtered by various characteristics such as data center (“colo”), platform (operating system), WARP Client version, and test name.

In this example, you have a DEX test monitoring the latency of the website www.cloudflarestatus.com. This test, named "Cloudflare Status," uses an HTTP GET request and runs on Windows devices connecting through the Lisbon colo (data center). 

3) DEX Test Low Availability

Is application downtime causing headaches for you and your users? 

DEX Test Low Availability notifications help maintain optimal application health by notifying you when availability falls below a given threshold. This notification monitors the success rate of HTTP or Traceroute requests sent to an application through pre-configured DEX tests. These synthetic tests simulate user traffic and measure the percentage of successful interactions with your application.

You define the Service Level Objective (SLO) — a specific availability threshold — for each notification. When the percentage of successful requests falls below this threshold, you'll receive immediate notification, allowing you to proactively address issues before they impact a wide range of end users.

This can be filtered by various characteristics such as colo (data center), platform (operating system), WARP Client version, and test name.

In this example, a DEX test is targeting www.google.com. This Traceroute test runs on Chrome OS devices connecting through the Tel Aviv colo. The example notification is configured to alert you whenever the availability (percentage of successful requests) drops below 98%, allowing you to investigate potential issues and take corrective action quickly.

DEX notifications are now available for Cloudflare One customers. They can be configured by going to Cloudflare Dashboard > Account home > Notifications > Add, and then selecting any of the three DEX notification types. For more information, refer to Create a notification. DEX notifications are one of the many ways the Cloudflare One suite of solutions work seamlessly together as a unified platform to find and fix security issues across SaaS applications. Get started now with Cloudflare’s Zero Trust platform by signing up here.

In January 2023, we proudly launched China Express with multiple partners in China to extend Cloudflare One into China and provide connectivity to ensure that customers within the country could enjoy the same level of access to global services as the rest of the world. Our goal was simple: to deliver a consistent experience for customers and employees everywhere.

Over the past year, we've observed a notable increase in demand from enterprise customers seeking secure access to China-hosted sites. These customers, who often require consistent zero trust security policies applied through Cloudflare Gateway, including device posture checks, have faced challenges like scenic routing, where Internet traffic passes through multiple countries or networks, leading to significant packet loss when connecting to these websites.

For example, a global company with offices in both Hong Kong and San Jose has implemented Cloudflare One to implement a unified Zero Trust platform globally, with all employees using WARP on their devices to manage Internet access. As part of their daily operations, employees need to access websites hosted in mainland China. However, they have experienced unstable connections, particularly when accessing the AWS web console in China. Further investigation revealed long and sometimes unpredictable network routes, contributing to the instability.

Global Internet traffic to and from China flows through a limited number of international links, tightly regulated by government authorities, often leading to significant instability and fluctuations. To address these challenges, our China Express partners offer the 'Reverse Tunnel' solution, a reliable service that ensures stable access to Chinese websites, effectively mitigating connectivity issues.

Today, we are thrilled to announce a significant enhancement to China Express: a new offering tailored to the needs of global Cloudflare Gateway customers accessing China-hosted sites. This enhancement introduces a dedicated tunnel configuration, ensuring safe and predictable connectivity while maintaining stringent zero trust security policies.

By partnering with JD Cloud, one of our trusted local providers in China, we've developed a solution that seamlessly integrates with Cloudflare's Zero Trust Firewall DNS Policies by:

Directly routing through our Cloudflare Hong Kong data center: When global Cloudflare Gateway customers attempt to access China-hosted sites, their traffic is routed directly to our Hong Kong data center. This strategic routing point allows us to apply Zero Trust policies before the traffic continues its journey into China.

Using JD Cloud's connectivity tunnel: From our Cloudflare Hong Kong data center, the traffic is then securely transmitted through JD Cloud's private tunnel infrastructure, ensuring reliable and efficient connectivity into China. This partnership with JD Cloud leverages their local expertise and infrastructure capabilities, further enhancing the reliability and performance of the connection.

Note: This premium service is exclusive to China Network customers and requires a dedicated reverse tunnel contract with JD Cloud.

This solution offers several key benefits for our customers:

• Improved stability: By directing all traffic to a dedicated tunnel, customers experience more reliable connections to websites within China.

• Enhanced security: Zero Trust policies are consistently applied to all traffic, regardless of its destination, ensuring the highest level of security for customers accessing China-hosted sites.

• Seamless customer experience: With a dedicated tunnel configuration, customers can access websites in China with confidence, knowing that their connections are both safe and predictable. Whether it’s multinational corporations expanding into the Chinese market, e-commerce platforms serving Chinese customers, or remote workers accessing corporate resources from within China, Cloudflare's China Express with JD Cloud partnership provides a solution tailored to their specific needs.

By having companies implement a DNS host override policy in Cloudflare Gateway for origins in China, which routes traffic through the China Express Reverse Tunnel instead of using public Internet routes, companies can ensure more stable and reliable connections for their employees.

Looking ahead, we remain committed to continuously improving and expanding our offerings within China Express. Future developments may include further enhancements to performance, additional partnerships with local providers, and ongoing innovation to meet the evolving needs of our customers in the region.

We’ll continue to share roundup blog posts as we continue to build and innovate. Be sure to follow along on the Cloudflare Blog for the latest news and updates.

Welcome to the sixteenth edition of Cloudflare’s DDoS Threat Report. This edition covers DDoS trends and key findings for the fourth and final quarter of the year 2023, complete with a review of major trends throughout the year.

DDoS attacks, or distributed denial-of-service attacks, are a type of cyber attack that aims to disrupt websites and online services for users, making them unavailable by overwhelming them with more traffic than they can handle. They are similar to car gridlocks that jam roads, preventing drivers from getting to their destination.

There are three main types of DDoS attacks that we will cover in this report. The first is an HTTP request intensive DDoS attack that aims to overwhelm HTTP servers with more requests than they can handle to cause a denial of service event. The second is an IP packet intensive DDoS attack that aims to overwhelm in-line appliances such as routers, firewalls, and servers with more packets than they can handle. The third is a bit-intensive attack that aims to saturate and clog the Internet link causing that ‘gridlock’ that we discussed. In this report, we will highlight various techniques and insights on all three types of attacks.

Previous editions of the report can be found here, and are also available on our interactive hub, Cloudflare Radar. Cloudflare Radar showcases global Internet traffic, attacks, and technology trends and insights, with drill-down and filtering capabilities for zooming in on insights of specific countries, industries, and service providers. Cloudflare Radar also offers a free API allowing academics, data sleuths, and other web enthusiasts to investigate Internet usage across the globe.

To learn how we prepare this report, refer to our Methodologies.

1. In Q4, we observed a 117% year-over-year increase in network-layer DDoS attacks, and overall increased DDoS activity targeting retail, shipment and public relations websites during and around Black Friday and the holiday season.

2. In Q4, DDoS attack traffic targeting Taiwan registered a 3,370% growth, compared to the previous year, amidst the upcoming general election and reported tensions with China. The percentage of DDoS attack traffic targeting Israeli websites grew by 27% quarter-over-quarter, and the percentage of DDoS attack traffic targeting Palestinian websites grew by 1,126% quarter-over-quarter — as the military conflict between Israel and Hamas continues.

3. In Q4, there was a staggering 61,839% surge in DDoS attack traffic targeting Environmental Services websites compared to the previous year, coinciding with the 28th United Nations Climate Change Conference (COP 28).

For an in-depth analysis of these key findings and additional insights that could redefine your understanding of current cybersecurity challenges, read on!

Illustration of a DDoS attack

2023 was the year of uncharted territories. DDoS attacks reached new heights — in size and sophistication. The wider Internet community, including Cloudflare, faced a persistent and deliberately engineered campaign of thousands of hyper-volumetric DDoS attacks at never before seen rates.

These attacks were highly complex and exploited an HTTP/2 vulnerability. Cloudflare developed purpose-built technology to mitigate the vulnerability’s effect and worked with others in the industry to responsibly disclose it.

As part of this DDoS campaign, in Q3 our systems mitigated the largest attack we’ve ever seen — 201 million requests per second (rps). That’s almost 8 times larger than our previous 2022 record of 26 million rps.

Largest HTTP DDoS attacks as seen by Cloudflare, by year

After the hyper-volumetric campaign subsided, we saw an unexpected drop in HTTP DDoS attacks. Overall in 2023, our automated defenses mitigated over 5.2 million HTTP DDoS attacks consisting of over 26 trillion requests. That averages at 594 HTTP DDoS attacks and 3 billion mitigated requests every hour.

Despite these astronomical figures, the amount of HTTP DDoS attack requests actually declined by 20% compared to 2022. This decline was not just annual but was also observed in 2023 Q4 where the number of HTTP DDoS attack requests decreased by 7% YoY and 18% QoQ.

On the network-layer, we saw a completely different trend. Our automated defenses mitigated 8.7 million network-layer DDoS attacks in 2023. This represents an 85% increase compared to 2022.

In 2023 Q4, Cloudflare’s automated defenses mitigated over 80 petabytes of network-layer attacks. On average, our systems auto-mitigated 996 network-layer DDoS attacks and 27 terabytes every hour. The number of network-layer DDoS attacks in 2023 Q4 increased by 175% YoY and 25% QoQ.

HTTP and Network-layer DDoS attacks by quarter

In the final quarter of 2023, the landscape of cyber threats witnessed a significant shift. While the Cryptocurrency sector was initially leading in terms of the volume of HTTP DDoS attack requests, a new target emerged as a primary victim. The Environmental Services industry experienced an unprecedented surge in HTTP DDoS attacks, with these attacks constituting half of all its HTTP traffic. This marked a staggering 618-fold increase compared to the previous year, highlighting a disturbing trend in the cyber threat landscape.

This surge in cyber attacks coincided with COP 28, which ran from November 30th to December 12th, 2023. The conference was a pivotal event, signaling what many considered the 'beginning of the end' for the fossil fuel era. It was observed that in the period leading up to COP 28, there was a noticeable spike in HTTP attacks targeting Environmental Services websites. This pattern wasn't isolated to this event alone.

Looking back at historical data, particularly during COP 26 and COP 27, as well as other UN environment-related resolutions or announcements, a similar pattern emerges. Each of these events was accompanied by a corresponding increase in cyber attacks aimed at Environmental Services websites.

In February and March 2023, significant environmental events like the UN's resolution on climate justice and the launch of United Nations Environment Programme’s Freshwater Challenge potentially heightened the profile of environmental websites, possibly correlating with an increase in attacks on these sites​​​​.

This recurring pattern underscores the growing intersection between environmental issues and cyber security, a nexus that is increasingly becoming a focal point for attackers in the digital age.

It’s not just UN resolutions that trigger DDoS attacks. Cyber attacks, and particularly DDoS attacks, have long been a tool of war and disruption. We witnessed an increase in DDoS attack activity in the Ukraine-Russia war, and now we’re also witnessing it in the Israel-Hamas war. We first reported the cyber activity in our report Cyber attacks in the Israel-Hamas war, and we continued to monitor the activity throughout Q4.

Operation “Iron Swords” is the military offensive launched by Israel against Hamas following the Hamas-led 7 October attack. During this ongoing armed conflict, we continue to see DDoS attacks targeting both sides.

DDoS attacks targeting Israeli and Palestinian websites, by industry

Relative to each region's traffic, the Palestinian territories was the second most attacked region by HTTP DDoS attacks in Q4. Over 10% of all HTTP requests towards Palestinian websites were DDoS attacks, a total of 1.3 billion DDoS requests — representing a 1,126% increase in QoQ. 90% of these DDoS attacks targeted Palestinian Banking websites. Another 8% targeted Information Technology and Internet platforms.

Top attacked Palestinian industries

Similarly, our systems automatically mitigated over 2.2 billion HTTP DDoS requests targeting Israeli websites. While 2.2 billion represents a decrease compared to the previous quarter and year, it did amount to a larger percentage out of the total Israel-bound traffic. This normalized figure represents a 27% increase QoQ but a 92% decrease YoY. Notwithstanding the larger amount of attack traffic, Israel was the 77th most attacked region relative to its own traffic. It was also the 33rd most attacked by total volume of attacks, whereas the Palestinian territories was 42nd.

Of those Israeli websites attacked, Newspaper & Media were the main target — receiving almost 40% of all Israel-bound HTTP DDoS attacks. The second most attacked industry was the Computer Software industry. The Banking, Financial Institutions, and Insurance (BFSI) industry came in third.

Top attacked Israeli industries

On the network layer, we see the same trend. Palestinian networks were targeted by 470 terabytes of attack traffic — accounting for over 68% of all traffic towards Palestinian networks. Surpassed only by China, this figure placed the Palestinian territories as the second most attacked region in the world, by network-layer DDoS attack, relative to all Palestinian territories-bound traffic. By absolute volume of traffic, it came in third. Those 470 terabytes accounted for approximately 1% of all DDoS traffic that Cloudflare mitigated.

Israeli networks, though, were targeted by only 2.4 terabytes of attack traffic, placing it as the 8th most attacked country by network-layer DDoS attacks (normalized). Those 2.4 terabytes accounted for almost 10% of all traffic towards Israeli networks.

Top attacked countries

When we turned the picture around, we saw that 3% of all bytes that were ingested in our Israeli-based data centers were network-layer DDoS attacks. In our Palestinian-based data centers, that figure was significantly higher — approximately 17% of all bytes.

On the application layer, we saw that 4% of HTTP requests originating from Palestinian IP addresses were DDoS attacks, and almost 2% of HTTP requests originating from Israeli IP addresses were DDoS attacks as well.

In the third quarter of 2022, China was the largest source of HTTP DDoS attack traffic. However, since the fourth quarter of 2022, the US took the first place as the largest source of HTTP DDoS attacks and has maintained that undesirable position for five consecutive quarters. Similarly, our data centers in the US are the ones ingesting the most network-layer DDoS attack traffic — over 38% of all attack bytes.

HTTP DDoS attacks originating from China and the US by quarter

Together, China and the US account for a little over a quarter of all HTTP DDoS attack traffic in the world. Brazil, Germany, Indonesia, and Argentina account for the next twenty-five percent.

Top source of HTTP DDoS attacks

These large figures usually correspond to large markets. For this reason, we also normalize the attack traffic originating from each country by comparing their outbound traffic. When we do this, we often get small island nations or smaller market countries that a disproportionate amount of attack traffic originates from. In Q4, 40% of Saint Helena’s outbound traffic were HTTP DDoS attacks — placing it at the top. Following the ‘remote volcanic tropical island’, Libya came in second, Swaziland (also known as Eswatini) in third. Argentina and Egypt follow in fourth and fifth place.

Top source of HTTP DDoS attacks with respect to each country’s traffic

On the network layer, Zimbabwe came in first place. Almost 80% of all traffic we ingested in our Zimbabwe-based data center was malicious. In second place, Paraguay, and Madagascar in third.

Top source of Network-layer DDoS attacks with respect to each country’s traffic

By volume of attack traffic, Cryptocurrency was the most attacked industry in Q4. Over 330 billion HTTP requests targeted it. This figure accounts for over 4% of all HTTP DDoS traffic for the quarter. The second most attacked industry was Gaming & Gambling. These industries are known for being coveted targets and attract a lot of traffic and attacks.

Top industries targeted by HTTP DDoS attacks

On the network layer, the Information Technology and Internet industry was the most attacked — over 45% of all network-layer DDoS attack traffic was aimed at it. Following far behind were the Banking, Financial Services and Insurance (BFSI), Gaming & Gambling, and Telecommunications industries.

Top industries targeted by Network-layer DDoS attacks

To change perspectives, here too, we normalized the attack traffic by the total traffic for a specific industry. When we do that, we get a different picture.

Top attacked industries by HTTP DDoS attacks, by region

We already mentioned in the beginning of this report that the Environmental Services industry was the most attacked relative to its own traffic. In second place was the Packaging and Freight Delivery industry, which is interesting because of its timely correlation with online shopping during Black Friday and the winter holiday season. Purchased gifts and goods need to get to their destination somehow, and it seems as though attackers tried to interfere with that. On a similar note, DDoS attacks on retail companies increased by 16% compared to the previous year.

Top industries targeted by HTTP DDoS attacks with respect to each industry’s traffic

On the network layer, Public Relations and Communications was the most targeted industry — 36% of its traffic was malicious. This too is very interesting given its timing. Public Relations and Communications companies are usually linked to managing public perception and communication. Disrupting their operations can have immediate and widespread reputational impacts which becomes even more critical during the Q4 holiday season. This quarter often sees increased PR and communication activities due to holidays, end-of-year summaries, and preparation for the new year, making it a critical operational period — one that some may want to disrupt.

Top industries targeted by Network-layer DDoS attacks with respect to each industry’s traffic

Singapore was the main target of HTTP DDoS attacks in Q4. Over 317 billion HTTP requests, 4% of all global DDoS traffic, were aimed at Singaporean websites. The US followed closely in second and Canada in third. Taiwan came in as the fourth most attacked region — amidst the upcoming general elections and the tensions with China. Taiwan-bound attacks in Q4 traffic increased by 847% compared to the previous year, and 2,858% compared to the previous quarter. This increase is not limited to the absolute values. When normalized, the percentage of HTTP DDoS attack traffic targeting Taiwan relative to all Taiwan-bound traffic also significantly increased. It increased by 624% quarter-over-quarter and 3,370% year-over-year.

Top targeted countries by HTTP DDoS attacks

While China came in as the ninth most attacked country by HTTP DDoS attacks, it's the number one most attacked country by network-layer attacks. 45% of all network-layer DDoS traffic that Cloudflare mitigated globally was China-bound. The rest of the countries were so far behind that it is almost negligible.

Top targeted countries by Network-layer DDoS attacks

When normalizing the data, Iraq, Palestinian territories, and Morocco take the lead as the most attacked regions with respect to their total inbound traffic. What’s interesting is that Singapore comes up as fourth. So not only did Singapore face the largest amount of HTTP DDoS attack traffic, but that traffic also made up a significant amount of the total Singapore-bound traffic. By contrast, the US was second most attacked by volume (per the application-layer graph above), but came in the fiftieth place with respect to the total US-bound traffic.

Top targeted countries by HTTP DDoS attacks with respect to each country’s traffic

Similar to Singapore, but arguably more dramatic, China is both the number one most attacked country by network-layer DDoS attack traffic, and also with respect to all China-bound traffic. Almost 86% of all China-bound traffic was mitigated by Cloudflare as network-layer DDoS attacks. The Palestinian territories, Brazil, Norway, and again Singapore followed with large percentages of attack traffic.

Top targeted countries by Network-layer DDoS attacks with respect to each country’s traffic

The majority of DDoS attacks are short and small relative to Cloudflare’s scale. However, unprotected websites and networks can still suffer disruption from short and small attacks without proper inline automated protection — underscoring the need for organizations to be proactive in adopting a robust security posture.

In 2023 Q4, 91% of attacks ended within 10 minutes, 97% peaked below 500 megabits per second (mbps), and 88% never exceeded 50 thousand packets per second (pps).

Two out of every 100 network-layer DDoS attacks lasted more than an hour, and exceeded 1 gigabit per second (gbps). One out of every 100 attacks exceeded 1 million packets per second. Furthermore, the amount of network-layer DDoS attacks exceeding 100 million packets per second increased by 15% quarter-over-quarter.

DDoS attack stats you should know

One of those large attacks was a Mirai-botnet attack that peaked at 160 million packets per second. The packet per second rate was not the largest we’ve ever seen. The largest we’ve ever seen was 754 million packets per second. That attack occurred in 2020, and we have yet to see anything larger.

This more recent attack, though, was unique in its bits per second rate. This was the largest network-layer DDoS attack we’ve seen in Q4. It peaked at 1.9 terabits per second and originated from a Mirai botnet. It was a multi-vector attack, meaning it combined multiple attack methods. Some of those methods included UDP fragments flood, UDP/Echo flood, SYN Flood, ACK Flood, and TCP malformed flags.

This attack targeted a known European Cloud Provider and originated from over 18 thousand unique IP addresses that are assumed to be spoofed. It was automatically detected and mitigated by Cloudflare’s defenses.

This goes to show that even the largest attacks end very quickly. Previous large attacks we’ve seen ended within seconds — underlining the need for an in-line automated defense system. Though still rare, attacks in the terabit range are becoming more and more prominent.

1.9 Terabit per second Mirai DDoS attacks

The use of Mirai-variant botnets is still very common. In Q4, almost 3% of all attacks originate from Mirai. Though, of all attack methods, DNS-based attacks remain the attackers’ favorite. Together, DNS Floods and DNS Amplification attacks account for almost 53% of all attacks in Q4. SYN Flood follows in second and UDP floods in third. We’ll cover the two DNS attack types here, and you can visit the hyperlinks to learn more about UDP and SYN floods in our Learning Center.

DNS floods and DNS amplification attacks both exploit the Domain Name System (DNS), but they operate differently. DNS is like a phone book for the Internet, translating human-friendly domain names like "www.cloudflare.com" into numerical IP addresses that computers use to identify each other on the network.

Simply put, DNS-based DDoS attacks comprise the method computers and servers used to identify one another to cause an outage or disruption, without actually ‘taking down’ a server. For example, a server may be up and running, but the DNS server is down. So clients won't be able to connect to it and will experience it as an outage.

A DNS flood attack bombards a DNS server with an overwhelming number of DNS queries. This is usually done using a DDoS botnet. The sheer volume of queries can overwhelm the DNS server, making it difficult or impossible for it to respond to legitimate queries. This can result in the aforementioned service disruptions, delays or even an outage for those trying to access the websites or services that rely on the targeted DNS server.

On the other hand, a DNS amplification attack involves sending a small query with a spoofed IP address (the address of the victim) to a DNS server. The trick here is that the DNS response is significantly larger than the request. The server then sends this large response to the victim's IP address. By exploiting open DNS resolvers, the attacker can amplify the volume of traffic sent to the victim, leading to a much more significant impact. This type of attack not only disrupts the victim but also can congest entire networks.

In both cases, the attacks exploit the critical role of DNS in network operations. Mitigation strategies typically include securing DNS servers against misuse, implementing rate limiting to manage traffic, and filtering DNS traffic to identify and block malicious requests.

Top attack vectors

Amongst the emerging threats we track, we recorded a 1,161% increase in ACK-RST Floods as well as a 515% increase in CLDAP floods, and a 243% increase in SPSS floods, in each case as compared to last quarter. Let’s walk through some of these attacks and how they’re meant to cause disruption.

Top emerging attack vectors

An ACK-RST Flood exploits the Transmission Control Protocol (TCP) by sending numerous ACK and RST packets to the victim. This overwhelms the victim's ability to process and respond to these packets, leading to service disruption. The attack is effective because each ACK or RST packet prompts a response from the victim’s system, consuming its resources. ACK-RST Floods are often difficult to filter since they mimic legitimate traffic, making detection and mitigation challenging.

CLDAP (Connectionless Lightweight Directory Access Protocol) is a variant of LDAP (Lightweight Directory Access Protocol). It's used for querying and modifying directory services running over IP networks. CLDAP is connectionless, using UDP instead of TCP, making it faster but less reliable. Because it uses UDP, there’s no handshake requirement which allows attackers to spoof the IP address thus allowing attackers to exploit it as a reflection vector. In these attacks, small queries are sent with a spoofed source IP address (the victim's IP), causing servers to send large responses to the victim, overwhelming it. Mitigation involves filtering and monitoring unusual CLDAP traffic.

Floods abusing the SPSS (Source Port Service Sweep) protocol is a network attack method that involves sending packets from numerous random or spoofed source ports to various destination ports on a targeted system or network. The aim of this attack is two-fold: first, to overwhelm the victim's processing capabilities, causing service disruptions or network outages, and second, it can be used to scan for open ports and identify vulnerable services. The flood is achieved by sending a large volume of packets, which can saturate the victim's network resources and exhaust the capacities of its firewalls and intrusion detection systems. To mitigate such attacks, it's essential to leverage in-line automated detection capabilities.

Cloudflare’s mission is to help build a better Internet, and we believe that a better Internet is one that is secure, performant, and available to all. No matter the attack type, the attack size, the attack duration or the motivation behind the attack, Cloudflare’s defenses stand strong. Since we pioneered unmetered DDoS Protection in 2017, we’ve made and kept our commitment to make enterprise-grade DDoS protection free for all organizations alike — and of course, without compromising performance. This is made possible by our unique technology and robust network architecture.

It’s important to remember that security is a process, not a single product or flip of a switch. Atop of our automated DDoS protection systems, we offer comprehensive bundled features such as firewall, bot detection, API protection, and caching to bolster your defenses. Our multi-layered approach optimizes your security posture and minimizes potential impact. We’ve also put together a list of recommendations to help you optimize your defenses against DDoS attacks, and you can follow our step-by-step wizards to secure your applications and prevent DDoS attacks. And, if you’d like to benefit from our easy to use, best-in-class protection against DDoS and other attacks on the Internet, you can sign up — for free! — at cloudflare.com. If you’re under attack, register or call the cyber emergency hotline number for a rapid response.

Global organizations have always strived to provide a consistent app experience for their Internet users all over the world. Cloudflare has helped in this endeavor with our mission to help build a better Internet. In 2021, we announced an upgraded Cloudflare China Network, in partnership with JD Cloud to help improve performance for users in China. With this option, Cloudflare customers can serve cached content locally within China without all requests having to go to a data center outside of China. This results in significant performance benefits for end users, but requests to the origin still need to travel overseas.

We wanted to go a step further to solve this problem. In early 2023, we launched China Express, a suite of connectivity and performance offerings in partnership with China Mobile International (CMI), CBC Tech and Niaoyun. One of the services available through China Express is Private Link, which is an optimized, high-quality circuit for overseas connectivity. Offered by our local partners, a more reliable and high performance connection from China to the global internet.

“Acme Corp” is a global Online Shopping Platform business that serves lots of direct to consumer brands, transacting primarily over e-commerce channels. Web performance for them directly translates to customer engagement and suppliers and revenue. With 90% of their suppliers in mainland China and online stores serving the consumers out of China, Acme Corp had enabled the Cloudflare China Network to help accelerate performance and improve suppliers’ experience of Store Backend systems with the suppliers. While their suppliers had a great experience with static content, they still had challenges with dynamic content. They experienced performance bottlenecks and high packet loss on their origin requests. This manifested as an intermittent timeout issue on their origin pull requests.

This is an expected issue with cross-border network congestion and the vagaries of ISP routing in and out of China. Coming out of the pandemic, the business needed to rapidly evolve and direct suppliers’ dynamic content to global consumers, which meant they couldn’t cache as much content statically within the country. This led to increasing user experience issues and increased the administrative burden on the IT teams.

The organization wanted a solution that would improve cross-border performance and reduce the number of timeouts experienced during origin pull requests. They wanted to avoid the administrative complexity of using a private line through a third-party vendor which had the potential to increase the chance for human error.

The organization chose a private link service through Cloudflare’s local partner CMI. The preliminary design looked like this.

• Eyeballs in mainland China land on a Cloudflare China Network data center within mainland China.

• Statically cached content is delivered directly out of one of the 30 data centers within    China

• Origin pull requests for dynamic content are routed through tunnel to the partner data center in Hong Kong

• From the partner data center, these requests arrive at the origin server

• Workers in China Data Center fall back to user through China Express while required, otherwise go through the public Internet

China Express removes the timeout issue, and the performance doubles in peak time!

When we dive into the peak hour data analysis during 20:00 - 02:00 +1 CST (China Standard Time) by 5 Mins

China express shows fairly stable Avg. Download Throughput over peak hour, while due to congestion with public internet the Avg. Download Throughput has a big impact

Bar chart view of Avg. Load Time over peak hour, China express shows 54% performance improvement than public line over peak hour.

China Express is a great solution for global organizations looking to improve stability and performance for users in mainland China. In conjunction with our in-country China Network data centers, this can make measurable improvements in app stability and performance and reduce the administrative burden for IT teams. If you’d like to learn more, talk to one of our experts who can discuss your specific needs and propose a tailored solution.

Cloudflare has been helping global organizations offer their users a consistent experience all over the world. This includes mainland China, a market our global customers cannot ignore but that continues to be challenging for infrastructure teams trying to ensure performance, security and reliability for their applications and users both in and outside mainland China. We are excited to announce China Express — a new suite of capabilities and best practices in partnership with our partners China Mobile International (CMI) and CBC Tech — that help address some of these performance challenges and ensure a consistent experience for customers and employees everywhere.

Cloudflare has been providing Application Services to users in mainland China since 2015, improving performance and security using in-country data centers and caching. Today, we have a presence in 30 cities in mainland China thanks to our strategic partnership with JD Cloud. While this delivers significant performance improvements, some requests still need to go back to the origin servers which may live outside mainland China. With limited international Internet gateways and restrictive cross-border regulations, international traffic has a very high latency and packet drop rate in and out of China. This results in inconsistent cached content within China and a poor experience for users trying to access dynamic content that requires frequent access to the origin.

Last month, we expanded our Cloudflare One, Zero Trust network-as-a-service platform to users and organizations in China with additional connectivity options. This has received tremendous interest from customers, so we’re looking at what else we could do to further improve the user experience for customers with employees or offices in China.

China Express is a suite of connectivity and performance offerings designed to simplify connectivity and improve performance for users in China. To understand these better, let’s take an example of Acme Corp, a global company with offices in Shanghai and Beijing — with origin data centers in London and Ashburn. And let’s see how we can help their infrastructure teams better serve employees and users in mainland China.

Premium Dedicated Internet Access, is an optimized, high-quality public Internet circuit for cross-border connectivity provided by our local partners CMI and CBC Tech. With this service, traffic from mainland China will arrive at our partner data center in Hong Kong, using a fixed NAT IP. Customers do not worry about compliance issues because their traffic still goes through the public Internet with all regulatory controls in place.

Acme Corp can use Premium DIA to improve origin performance for their Cloudflare service in mainland China. Requests to the origin data centers in Ashburn and London would traverse the Premium DIA connection, which offers more bandwidth and lower packet loss resulting in more than a 60% improvement in performance.

Acme employees in mainland China would also see an improvement while accessing SaaS applications such as Microsoft 365 over the Internet when these apps are delivered from outside China. They would also notice an improvement in Internet speed in general.

While Premium DIA offers Acme performance improvements over the public Internet, they may want to keep some mission-critical application traffic on a private network for security reasons. Private link offers a dedicated private tunnel between Acme’s locations in China and their data centers outside of China. Private Link can also be used to establish dedicated private connectivity to SaaS data centers like Salesforce.

Private Link is a highly regulated area in China and depending on your use case, there might be additional requirements from our partners to implement it.

Acme Corp might have employees visiting China on a regular basis and need access to their corporate apps on their mobile devices including phones and tablets. Their IT teams not only have to procure and provision mobile Internet connectivity for their users, but also enforce consistent Zero Trust security controls.

Cloudflare is pleased to announce that the Travel SIM provided by Cloudflare’s partner CMI automatically provides network connectivity and can be used together with the Cloudflare WARP Client on mobile devices to provide Cloudflare’s suite of Zero Trust security services. Using the same Zero Trust profiles assigned to the user, the WARP client will automatically use the available 4G LTE network and establish a WireGuard tunnel to the closest Cloudflare data center outside of China. The data connection can also be shared with other devices using the hotspot function on the mobile device.

With the Travel SIM, users can enjoy the same Cloudflare global service as the rest of the world when traveling to China. And IT and security teams no longer need to worry about purchasing or deploying additional Zero Trust seats and device clients to ensure the employees’ Internet connection and the security policy enforcement.

As mentioned in a previous blog post, we are extending Cloudflare One, our zero trust network-as-a-service product, to mainland China through our strategic partnerships. Acme Corp will now be able to ensure their employees both inside and outside China will be able to use consistent zero trust security policy using the Cloudflare WARP device client. In addition, they will be able to connect their physical offices in China to their global private WAN using Magic WAN with consistent security policies applied globally.

Cloudflare is excited to work with  our partners to help our customers solve connectivity and performance challenges in mainland China. All the above solutions are easy and fast to deploy and are available now. If you’d like to get started, contact us here or reach out to your account team.

IT teams have historically faced challenges with performance, security, and reliability for employees and network resources in mainland China. Today, along with our strategic partners, we’re excited to announce expansion of our Cloudflare One product suite to tackle these problems, with the goal of creating the best SASE experience for users and organizations in China.

Cloudflare One, our comprehensive SASE platform, allows organizations to connect any source or destination and apply single-pass security policies from one unified control plane. Cloudflare One is built on our global network, which spans 275 cities across the globe and is within 50ms of 95% of the world’s Internet-connected population. Our ability to serve users extremely close to wherever they’re working—whether that’s in a corporate office, their home, or a coffee shop—has been a key reason customers choose our platform since day one.

In 2015, we extended our Application Services portfolio to cities in mainland China; in 2020, we expanded these capabilities to offer better performance and security through our strategic partnership with JD Cloud. Today, we’re unveiling our latest steps in this journey: extending the capabilities of Cloudflare One to users and organizations in mainland China, through additional strategic partnerships. Let’s break down a few ways you can achieve better connectivity, security, and performance for your China network and users with Cloudflare One.

Performance and reliability for traffic flows across the mainland China border have been a consistent challenge for IT teams within multinational organizations. Packets crossing the China border often experience reachability, congestion, loss, and latency challenges on their way to an origin server outside of China (and vice versa on the return path). Security and IT teams can also struggle to enforce consistent policies across this traffic, since many aspects of China networking are often treated separately from the rest of an organization’s global network because of their unique challenges.

Cloudflare is excited to address these challenges with our strategic China partners, combining our network infrastructure to deliver a better end-to-end experience to customers. Here’s an example architecture demonstrating the optimized packet flow with our partners and Cloudflare together:

Acme Corp, a multinational organization, has offices in Shanghai and Beijing. Users in those offices need to reach resources hosted in Acme’s data centers in Ashburn and London, as well as SaaS applications like Jira and Workday. Acme procures last mile connectivity at each office in mainland China from Cloudflare’s China partners.

Cloudflare’s partners route local traffic to its destination within China, and global traffic across a secure link to the closest available Cloudflare data center on the other side of the Chinese border.

At that data center, Cloudflare enforces a full stack of security functions across the traffic including network firewall-as-a-service and Secure Web Gateway policies. The traffic is then routed to its destination, whether that’s another connected location on Acme’s private network (via Anycast GRE or IPsec tunnel or direct connection) or a resource on the public Internet, across an optimized middle-mile path. Acme can choose whether Internet-bound traffic egresses from a shared or dedicated Cloudflare-owned IP pool.

Return traffic back to Acme’s connected network location in China takes the opposite path: source → Cloudflare’s network (where, again, security policies are applied) → Partner network → Acme local network.

Cloudflare and our partners are excited to help customers solve challenges with cross-border performance and security. This solution is easy to deploy and available now - reach out to your account team to get started today.

The same challenges that impact connectivity from China-based networks reaching out to global resources also impact remote users working in China. Expanding on the network connectivity solution we just described, we’re looking forward to improving user connectivity to cross-border resources by adapting our device client (WARP). This solution will also allow security teams to enforce consistent policy across devices connecting to corporate resources, rather than managing separate security stacks for users inside and outside of China.

Acme Corp has users that are either based in or traveling to China for business and need to access corporate resources that are hosted beyond China, without necessarily being physically in an Acme office in order to enable this access. Acme uses an MDM provider to install the WARP client on company-managed devices and enroll them in Acme’s Cloudflare Zero Trust organization. Within China, the WARP client utilizes Cloudflare’s China partner networks to establish the same Wireguard tunnel to the nearest Cloudflare point of presence outside of mainland China. Cloudflare’s partners act as the carrier of our customers’ IP traffic through their acceleration service and the content remains secure inside WARP.

Just as with traffic routed via our partners to Cloudflare at the network layer, WARP client traffic arriving at its first stop outside of China is filtered through Gateway and Access policies. Acme’s IT administrators can choose to enforce the same, or additional policies for device traffic from China vs other global locations. This setup makes life easier for Acme’s IT and security teams - they only need to worry about installing and managing a single device client in order to grant access and control security regardless of where employees are in the world.

Cloudflare and our partners are actively testing this solution in private beta. If you’re interested in getting access as soon as it’s available to the broader public, please contact your account team.

The last two use cases have focused primarily on granting network and user access from within China to resources on the other side of the border - but what about improving connectivity and security for local traffic?

We’ve heard from both China-based and multinational organizations that are excited to have the full suite of Cloudflare One functions available across China to achieve a full SASE architecture just a few milliseconds from everywhere their users and applications are in the world. We’re actively working toward this objective with our strategic partners, expanding upon the current availability of our application services platform across 45 data centers in 38 unique cities in mainland China.

Talk to your account team today to get on the waitlist for the full suite of Cloudflare One functions delivered across our China Network and be notified as soon as beta access is available!

We’re so excited to help organizations improve connectivity, performance and security for China networks and users. Contact your account team today to learn more about how Cloudflare One can help you transform your network and achieve a SASE architecture inside and outside of mainland China.

If you'd like to learn more, join us for a live webinar on Dec 6, 2022 10:00 AM PST through this link where we can answer all your questions about connectivity in China.

Core to Cloudflare’s mission of helping build a better Internet is making it easy for our customers to improve the performance, security, and reliability of their digital properties, no matter where in the world they might be. This includes Mainland China. Cloudflare has had customers using our service in China since 2015 and recently, we expanded our China presence through a partnership with JD Cloud, the cloud division of Chinese Internet giant, JD.com. We’ve also had a local office in Beijing for several years, which has given us a deep understanding of the Chinese Internet landscape as well as local customers.

The new Cloudflare China Network built in partnership with JD Cloud has been live for several months, with significant performance and security improvements compared to the previous in-country network. Today, we’re excited to describe the improvements we made to our DNS and DDoS systems, and provide data demonstrating the performance gains customers are seeing. All customers licensed to operate in China can now benefit from these innovations, with the click of a button in the Cloudflare dashboard or via the API.

With over 14% of all domains on the Internet using Cloudflare’s nameservers we are the largest DNS provider. Furthermore, we pride ourselves on consistently being among the fastest authoritative nameservers, answering about 12 million DNS queries per second on average (in Q2 2021). We achieve this scale and performance by running our DNS platform on our global network in more than 200 cities, in over 100 countries.

Not too long ago, a user in mainland China accessing a website using Cloudflare DNS did not fully benefit from these advantages. Their DNS queries had to leave the country and, in most cases, cross the Pacific Ocean to reach our nameservers outside of China. This network distance introduced latency and sometimes even packet drops, resulting in a poor user experience.

With the new China Network offering built on JD Cloud’s infrastructure, customers are now able to serve their DNS in mainland China. This means DNS queries are answered directly from one of the JD Cloud Points of Presence (PoPs), leading to faster response times and improved reliability.

Once a user signs up a domain and opts in to serve their DNS in China we will assign two nameservers, from two of the following three domains:

cf-ns.com
cf-ns.net
cf-ns.tech

We selected these Top Level Domains (TLDs) because they offer the best possible performance from within mainland China. They are chosen to always be different from the TLD of the domain using them. For example, example.com will be assigned nameservers using the .tech and .net TLD. This gives us “glueless delegations” for customers’ nameservers, allowing us to dynamically return nameserver IP addresses instead of static glue records.

A “glue record” (or just “glue”) is a mapping between nameservers and IPs that’s added by registrars to break circular lookup dependencies when a domain uses a nameserver with the same TLD. For example, imagine a resolver asks the .com TLD nameserver: “Where do I find the nameservers for example.com?” and this domain is using ns1.example.com and ns2.example.com as nameservers. If .com just replied: “Go and ask ns1.example.com or ns2.example.com.” the resolver would come back to .com with the same question and this would never stop. One solution is to add glue at .com, so the answer can be: “The nameservers for example.com are ns1.example.com and ns2.example.com, and they can be reached at 192.0.2.78 and 203.0.113.55.”.

By using different TLDs, as described above, we don’t need to rely on glue records for customers’ nameservers. This way, we can ensure that queries will always be answered from the nearest point of presence (PoP) leading to a faster DNS response. Another advantage of serving dynamic nameserver IPs is the ability to distribute queries across different PoPs, which helps to spread load more efficiently and mitigate attacks.

Everywhere in the world except for China and India, we use a technique known as anycast routing to distribute DDoS attacks and absorb them in data centers as close to the traffic source as possible. But as we first wrote in 2015, the Internet in China works a bit differently than the rest of the world so anycast-based mitigation was not an option:

Unlike much of the rest of the world where network routing is open, in China core Internet access is largely controlled by two ISPs: China Telecom and China Unicom. [Today this list also includes China Mobile.] These ISPs control IP address allocation and routing inside the country. Even the Chinese Internet giants rarely own their own IP address allocations, or use BGP to control routing across the Chinese Internet. This makes BGP Anycast and many of the other routing techniques we use across Cloudflare's network impossible inside of China.

The lack of anycast in China requires a different approach to mitigating attacks, and our expansion with JD Cloud pushed us to further improve the edge-based mitigation system we wrote about earlier this year. Most importantly, we pushed the detection and mitigation of application (L7) attacks to the edge, reducing our time to mitigate and improving the resiliency of the system by removing a dependency on other core data centers for instructions. In the first quarter of 2021, we mitigated 81% of all L7 attacks at the edge.

For the larger network-based (L3/L4) attacks, we worked closely with JD Cloud to augment our in-data center protections with remote signaling to China Telecom, China Unicom, and China Mobile. These integrations allow us to remotely — and automatically — signal from our edge-based mitigation systems when we want upstream filtering assistance from the ISP. Mitigating attacks at the edge is faster than relying on centralized data centers, and in the first quarter of 2021 98.6% of all L3/4 DDoS attacks were mitigated without centralized communication. Attacks exceeding certain thresholds can also be re-routed to large scrubbing centers, a technique that doesn’t make sense in an anycast world but is useful when unicast is the only option.

Beyond the improved mitigation controls, we also developed new traffic engineering processes to move traffic from overloaded data centers to locations with more spare resources. These controls are already used outside of China, but doing so within the country required integration with our DNS systems.

Lastly, because all of our data centers run the same software stack, the work we did to improve the underlying components of DDoS detection and mitigation systems within China has already made its way back to our data centers outside of China.

Cloudflare on JD Cloud is significantly faster than our previous in-country network, allowing us to accelerate the delivery of our customers’ web properties in China.

To compare the Cloudflare PoPs on JD Cloud vs. our previous in-country network, we deployed a test zone to simulate a customer website on both China networks. We tested each website with the same two origin networks. Both origins are commonly used public cloud providers. One site was hosted in the northwest region of the United States, and the other in Western Europe.

For both zones, we assigned DNS nameservers in China to reduce out-of-country latency incurred during DNS lookups (more details are on DNS below). To test our caching, we used a monitoring and benchmarking service with a wide variety of clients in various Chinese cities and provinces to download 100 kilobyte, 1 megabyte, and 10 megabyte files every 15 minutes over the course of 36 hours.

Latency, as measured by Round Trip Time (RTT) from the client to our JD Cloud PoPs, was reduced at least 30% across tests for all file sizes. This subsequently reduced our Time to First Byte (TTFB) metrics. Reducing latency — and making it more consistent, i.e., improving jitter — has the most impact on other performance metrics, as latency and the slow-start process is the bottleneck for the vast majority of TCP connections.

Our latency reduction comes from the quality of the JD Cloud network, their placement of the PoPs within China, and our ability to direct clients to the closest PoP. As we continue to add more capacity and PoPs in partnership with JD Cloud in the future, we only expect our latency metrics to get even better.

Cloudflare’s sustained product investments in China, in partnership with JD Cloud, have resulted in significant performance and security improvements over our previous in-country network first launched in 2015.

Specifically, innovations in DNS and DDoS mitigation technology, alongside an improved network design and distribution of PoPs, have resulted in better security for our customers and at least a 30% performance boost.

This new network is open for business, and interested customers should reach out to learn more.

It’s well known that global companies can face challenges doing business in and out of China due to the country’s unique rules, regulations, and norms, not to mention recent political and trade complications. Less well known is that China’s logistical and technical network infrastructure is also quite different from the rest of the world’s. With global Internet traffic up 30% over the past month due to the pandemic, these logistical and technical hurdles are increasing the burden for global businesses at exactly the wrong time. It’s now not unusual for someone based in China to have to wait extended periods and often be unable to access applications hosted elsewhere, or vice-versa, due to the lower performance of international Internet traffic to and from China. This affects global companies with customers, suppliers or employees in China, and Chinese companies who are trying to reach global users.

Our mission is to help build a better Internet, for everyone, everywhere. So, today we’re excited to announce a significant strategic partnership with JD Cloud & AI, the cloud and intelligent technology business unit of Chinese Internet giant JD.com. Through this partnership, we’ll be adding 150 data centers in mainland China, an increase in the region of over 700%. The partnership will also enable JD to provide a Cloudflare-powered service to China-based customers. As a result, it will create a one-stop solution for companies both inside and outside of China to go truly global.

Cloudflare has helped our global customers deliver a secure, fast, and reliable Internet experience for China-based visitors since 2015 and we’ve served Chinese customers since our inception. Cloudflare customers currently are able to extend their configurations with the click of a button across data centers in 17 cities in mainland China. As a result, they’re able to deliver their content faster, more securely, and reliably in-country. The demand for the service has been overwhelming, and we’ve been exploring ways to provide our customers with a network that would have an order of magnitude greater coverage.

What we’ve learned from our experience is that having a widely distributed network and world class partners in China matters more there than almost anywhere else in the world. To understand why, it’s important to understand the specific technical and logistical hurdles that exist there.

China has a non-uniform technical and network infrastructure, directly impacting Internet performance. Mainland China has three major telecom carriers—China Telecom, China Unicom, and China Mobile—serving 22 provinces, 4 municipalities, and 5 autonomous regions. In many of these places, each carrier operates a distinct network and in some provinces more than one network, that in many cases, operate independently of one another. The result is many different sub-networks that need to be coordinated.

Regulatory hurdles in the network space can also present challenges. Unlike the rest of the world, where Anycast routing is generally available, in China the three main ISPs control IP address allocation and routing for customers’ networks both inside the country and globally. Small or large companies rarely own their own IP address allocations, and even fewer use BGP to control Internet routing. Because of the lack of BGP and the static allocation of IPs, the carriers’ customers operate on IP addresses that are homed onto a single network’s backbone.

The combination of this single-homed IP connectivity and the fragmented network topography leads to frequent bottlenecks between the various domestic ISPs. This makes network coverage all the more important. Add in a rapidly expanding economy with growing Internet activity, and extraordinary times such as these which puts even more strain on the Internet, and it's easy to see why situations regularly occur where too much traffic is paired with too little capacity.

Compounding these hurdles further is that, from a business and logistics perspective, China is similarly a collection of sub-markets. There are huge variations between provinces in terms of population levels, average income, consumer spending, and the like. Regional business regulations also vary dramatically_._ Although it is slowly opening up to outside competition, the Chinese transportation and logistics market is one of the most highly regulated in the world. Regulation exists at a number of different tiers, imposed by national, regional, and local authorities. Finally, there are shortages of high-quality logistics facilities and warehousing spaces, making it hard to find domestic providers for managing import, export, and local transportation as well as trade compliance. You often have to hire consultants who specialize in the China market to assess quality, trustworthiness, and other factors.

This makes it challenging both for foreign companies seeking a fast, secure, and reliable Internet experience but also, as we often hear from our customers, to navigate China more generally.

Given these technical, logistical, and regulatory complexities, it’s very difficult for foreign companies to navigate the China landscape without local expertise. Partnering with JD Cloud & AI provides not only local expertise, but also a relationship with one of the world’s largest logistics, e-commerce, and Internet companies, JD.com.

JD.com is a juggernaut, operating at a scale that’s rare among global companies. It’s China’s largest retailer by revenue, online or offline, with one billion retail customers, a quarter billion registered users, seven million enterprise customers, and $83 billion in 2019 revenue. Its highly automated logistics system uses robots, AI, and fleets of drones to cover 99% of China’s population.

JD decided several years ago to open its technology platform to its enterprise customers and began offering cloud services through a new business unit called JD Cloud & AI. JD Cloud & AI has quickly become the fastest growing cloud company among the top five Chinese providers. It offers a full range of services across eight availability zones in China and has made security and compliance a key part of its offering. In line with its parent company, JD Cloud & AI has made serving a global audience a key part of its strategy and has partnered with the likes of Microsoft and Citrix to build on this strategy. Importantly, like Cloudflare, the company has continued to invest in its infrastructure through the current pandemic, and has been critical to keeping China’s supply chains flowing and its businesses functioning.

Our partnership with JD Cloud & AI will allow international businesses to grow their online presence in China without having to worry about managing separate tools with separate vendors for security and performance in China. Customers will benefit from greater performance and security inside China using the same configurations that they use with Cloudflare everywhere else in the world.

Using Cloudflare's international network outside of China, and JD Cloud & AI’s network inside of China, any enterprise can rapidly and securely deploy cloud-based firewall, WAN optimization, distributed denial of service (DDoS) mitigation, content delivery, DNS services, and Cloudflare Workers, our serverless computing solution, worldwide. All with the click of a button within Cloudflare’s dashboard and without deploying a single piece of hardware.

For those customers who need it, we also expect JD.com to be able to help with in-country logistics. JD operates over 700 warehouses that cover almost all the counties and districts in China. It has over 360 million active individual consumers and seven million enterprise customers that purchase products on its platform. For Cloudflare customers interested in reaching these Chinese end-customers, no matter where they are located in China, JD.com will be able to help.

The partnership with JD Cloud & AI will also allow us to help Chinese companies reach global audiences. JD Cloud & AI will use Cloudflare's international network outside of China, and the JD Cloud & AI network inside of China, to allow any China-based enterprise to use Cloudflare’s integrated performance and security services worldwide, all seamlessly controlled from within the JD Cloud & AI dashboard.

As always, we’re taking care to be thoughtful about the treatment of customer data with this partnership. Cloudflare operates all services outside of China, and JD Cloud & AI all services inside of China. No Cloudflare customer traffic passes through the China network unless a customer explicitly opts-in to the service. And, for Cloudflare customers that opt-in to proxying content inside China, traffic and log data from outside of China is not stored in the China network or shared with our partner.

We are excited about this new partnership which will help us continue to offer customers the best performance and security service available anywhere in the world — and as a one-stop solution. While we can’t control the trade and political climate, which will inevitably ebb and flow over time, we can help our customers with technical and logistical challenges they may face doing business around the world, especially in these challenging times.

New and existing Cloudflare customers can request to be served in China by filling out an information request at https://www.cloudflare.com/china.

DEF CON is one of the largest and oldest security conferences in the world. Last year, it launched a beta event in China in hopes of bringing the local security communities closer together. This year, the organizer made things official by introducing DEF CON China 1.0 with a promise to build a forum for China where everyone can gather, connect, and grow together.

Themed "Technology's Promise", DEF CON China kicked off on 5/30 in Beijing and attracted participants of all ages. Watching young participants test, play and tinker with new technologies with such curiosity and excitement absolutely warmed our hearts!

It was a pleasure to participate in DEF CON China 1.0 this year and connect with local communities. Great synergy as we exchanged ideas and learnings on cybersecurity topics. Did I mention we also spoiled ourselves with the warm hospitality, wonderful food, live music, and amazing crowd while in Beijing.

Event Highlights: Cloudflare Team Meets with DEF CON China Visitors and Organizers (DEF CON Founder Jeff Moss and Baidu Security General Manager Jefferey Ma)

Meet our youngest and cutest attendee today at BugZee village. Meet 8 year old "Joy" from Beijing who did phenomenal soldering. Amazing crowd at @defcon China. pic.twitter.com/ub1qpGyGso

— Abhinav SP | #BugZee, DEFCON China (@TweetsFromPanda) May 31, 2019

Youngest DEF CON China Participant Explores New Technologies on the Eve of International Children's Day. (Source: Abhinav SP | #BugZee, DEFCON China )

All my root lights are on! #unlocked #DEFCONChina 1.0 @defcon #badgelife @Hyr0n1 ?? pic.twitter.com/YXJDW0vuds

— donds (@donds) May 31, 2019

The Iconic DEF CON Badge, Designed by Joe Grand, is a Flexible Printed Circuit Board that Lights up the Interactive "Tree of Promise".

The Capture The Flag (CTF) Contest is a Continuation of One of the Oldest Contests at DEF CON Dating Back to DEF CON 4 in 1996.

Founded in 2009, Cloudflare is a global company with 180 data centers across 80 countries. Our Performance and Security Services work in conjunction to reduce latency of websites, mobile applications, and APIs end-to-end, while protecting against DDoS attack, abusive bots, and data breach.

We are looking forward to growing our presence in the region and continuing to serve our customers, partners, and prospects. Sign up for a free account now for a faster and safer Internet experience: cloudflare.com/sign-up.

We are a team with global vision and local insight committed to building a better Internet. We are hiring in Beijing and globally. Check out the opportunities here: cloudflare.com/careers and join us at Cloudflare today!

The Cloudflare Team from Beijing, Singapore, and San Francisco

Good things come in pairs, 好事成双！ The month of May marks a double celebration in China for our customers, partners and Cloudflare.

A Beijing Customer Appreciation Cocktail was held in the heart of Beijing at Yintai Centre Xiu Rooftop Garden Bar on the 10 May 2019, an RSVP event graced by our supportive group of partners and customers.

We have been blessed with almost 10 years of strong growth at Cloudflare - sharing our belief in providing access to internet security and performance to customers of all sizes and industries. This success has been the result of collaboration between our developers, our product team as represented today by our special guest, Jen Taylor, our Global Head of Product, Business Leaders Xavier Cai, Head of China business, and Aliza Knox Head of our APAC Business, James Ball our Head of Solutions Engineers for APAC, Kate Fleming our Head of Customer Success for APAC, most importantly, by the trust and faith that our partners, such as Baidu, and customers have placed in us.

On the same week, we embarked on another exciting journey in China with our grand office opening at WeWork. Beijing team consists of functions from Customer Development to Solutions Engineering and Customer Success lead by Xavier, Head of China business. The team has grown rapidly in size by double since it started last year.

We continue to invest in China and to grow our customer base, and importantly our methods for supporting our customers, here are well. Those of us who came from different parts of the world, are also looking to learn from the wisdom and experience of our customers in this market. And to that end, we look forward to many more years of openness, trust, and mutual success.

感谢所有花时间来参加我们这次北京鸡尾酒会的客户和合作伙伴，谢谢各位对此活动的大力支持与热烈交流！

“Real knowledge is to know the extent of one's ignorance.”― Confucius

Don’t tell our CEO, Matthew Prince, but the first day I interviewed at Cloudflare I had a $9.00 phone in my pocket, a knock-off similar to a Nokia 5140, but the UI was all in Chinese characters—that phone was a fitting symbol for my technical prowess. At that time in my career I could send emails and use Google, but that was about the extent of my tech skill set. The only code I’d ever seen was in the Matrix, Apple computers confused me, and I was working as a philosophy lecturer at The University of California, Santa Cruz. So, you know, I was pretty much the ideal candidate for a deeply technical, Silicon Valley startup.

This was in 2013. I had just returned from two years of Peace Corps service in the far Southwest of China approaching the Himalayan plateau. That experience gave me the confidence to walk into Cloudflare’s office knowing that I would be good for the job despite the gaps in my knowledge. My early training in philosophy plus my Peace Corps service gave me a blueprint for learning and figuring things out when thrown into the deep end (it turns out that I love being thrown into the deep end and learning to swim).

I had no idea that this first meeting with Matthew would eventually lead me back to China, this time riding on the cloud of a fast-growing Silicon Valley tech giant.

Two years earlier, eighty Peace Corps Volunteers and myself landed in the capital of Sichuan province, Chengdu. The vast majority of us, myself included, spoke zero Mandarin and only knew about China from books and a few news snippets here and there. The Chinese staff members that greeted us at the Peace Corps China headquarters on the Sichuan University campus affectionately called us “baby pandas”, because we were cute and fairly incompetent in terms of operating in China.  

Our mission was to help China meet its need for trained men and women—specifically to teach college level students English and train qualified Teachers of English as a foreign language instructors (TEFL instructors). We were also there to promote a better understanding of Americans abroad, and to do our best to gain some understanding of China and its people.

Thus began two years of deep learning and profound personal growth.

When I think about the most important aspects of my time in China, there are three fundamentals that I come back to:

• The importance of learning the language and culture

• The importance of 关系 (guanxi) or personal connections and relationships

• The necessity of being resourceful

The most successful Peace Corps volunteers in my cohort were the ones that learned to speak Mandarin well, understood enough about Chinese culture to operate effectively in their schools and communities, had built important personal and professional relationships, and had figured out how to survive in Southwest China and be useful as English language resources and American cultural liaisons. There was a steep learning curve.

Peace Corps Service in China has four phases more or less. Phase one, Pre Service Training (PST), took place at Sichuan University. We were all living with Chinese host families, taking 8-9 hours of Mandarin class each day, learning about Chinese culture, and being trained as TEFL instructors. It is an intense period of learning against a backdrop of tremendous culture shock, jet lag, and general confusion of how to be an American in Southwest China.

After three months of well taught crash courses, I was sent out to the college where I would spend the next two years of my service. That first night, after I unpacked my bags and took a shower, the reality of my life decisions came crashing down. This was going to be *very* hard. I was alone with millions and millions of Chinese people in remote Sichuan. Phase two was about to begin.

This is Yibin (宜宾), the city I lived in for two years. A small city in China of just 5,000,000 people right on the Yangzi river. Photo taken from the countryside looking towards the center of town.

Getting familiar with the college where I was to spend two years was another steep learning curve. I was introduced to the colleagues I’d be teaching with as well as the school administrators, and, most importantly, I was introduced to my students. I got lucky, the English department at my school was small, and I only had 20-30 students in each of my classes. I met with them 4 times a week for two hours a day, so I had ample time to really get to know them and work with them one-on-one in the classroom, during office hours, and over spicy Sichuan dinners.

Me and a few of my top students.

That first year of service I studied Mandarin as if my life depended on it—because it sort of did. Few people, i.e. my students and colleagues, spoke English in rural Sichuan. As I was able to communicate better in Mandarin, my understanding of the culture grew and so did my relationships with folks at my school and community.

In an effort to understand more about the culture I was living in, I gave myself an education in Chinese philosophy starting with Confucius (孔子) and the Daoist like Laozi (老子) and Zhuangzi (庄子), and I also looked into Buddhism. Since the world’s wisdom traditions contain universal principles that transcend time and culture, these readings gave me subtle insights into the Chinese way of life. I learned that Confucianism is the invisible glue holding much of Chinese society together. And while Confucius spoke to Chinese society and how people ought to act, his contemporary, Laozi, considered the founder of Daoism, spoke to the Chinese soul via the Dao de Jing (道德经).

Apropos of philosophy, one beautiful Chinese proverb I found in my reading goes: “Only those who take leisurely what the rest of the world is concerned about, can be concerned about with the rest of the world takes leisurely”. A calligraphy artist at my school gifted me a piece of work expressing this:

I also learned early on in my service what my students needed: authentic opportunities to express themselves in English, understanding and encouragement, and a solid English text book that employed the latest pedagogical techniques for learning a foreign language. Since my Mandarin was slow going, my students had all sorts of authentic opportunities to speak to me in English. They ended up helping me translate a lot that first year as I navigated my life on campus. As for encouragement, I would often talk to them in my developing and broken Mandarin in front of the class. I messed up words and tones constantly, and they laughed (hard) and then kindly corrected me. In this way, I showed them that learning is all about making mistakes, and that it is fine to get it wrong as you begin. There is no other way to learn a language (or anything else). The last part, providing a solid textbook, would be more tricky.

I received enough training during PST to have some good ideas for teaching English as a foreign language, but I had no experience writing a language textbook. What I ended up doing was replicating the structure of the textbooks I was using to learn Mandarin: a dialogue which incorporates a few new vocab words, a list of those new vocab words, grammar practice using grammatical structures from the dialogue, and then photos of relevant objects or scenes that would allow students to use new vocabulary words to describe the photos using new words and structures. I would record these dialogues and then distribue the audio file to my students so they could hear my pronunciation.

We’d work with this dialogue, vocabulary, and grammar all week, then on Fridays I’d put them in a “language line”. Sort of like speed dating, but they would have to hold a conversation with their classmates around the topic of that week and use the new vocab words. I’d listen in and help guide them. Then at the end of class, we’d form a line and I’d ask each one of them a question individually that they had to answer before they could leave the classroom. This pushed each student into learning so that they could actually speak English confidently to a native English speaker. It was a rewarding project.

My mom sent Halloween candy for my students in October. They were *very* excited.

My students were super smart and diligent, and week after week their English level was going up. I was able to hold natural conversations with them while speaking slow, and my Mandarin was progressing to the point that I could clarify things in Mandarin to aid their English learning. And so I learned how to teach English.

I consider all of the second year of service phase three. It is in that second year that volunteers can do really great work. My language level was high enough to really communicate with my community and explore China more, I had a basic structure for teaching and kept honing it to fit the needs of my students, and I developed a lot of really important relationships with the administrators at my school and other wonderful folks in the area.

Phase four is the return to the US. Something that no one told me about Peace Corps service before I joined is that you actually sign up for three years, not two. And that the third year, the first year back home after service, would be the most challenging by far … readjusting to life in the US, starting up or continuing a career, feeling a million miles behind peers who cranked through two extra years in a work world. All of this while trying to work on one of the most important goals of the Peace Corps—Goal 3—helping Americans better understand China through my experiences. I’m doing this every chance I get. This blog is a part of fulfilling Goal 3.

Me and my good friend, 兵哥, goofing around in the Sichuan countryside after a long bike ride.

My service in China impacted me in profound ways. I have a love and respect for China that was born of close contact with the wonderful people, culture, philosophy, and language I was steeped in. And it gave me a clear experience of my ability to grow and change and acquire new skills swiftly. By the end of my time, I could confidently hold a conversation in Mandarin, I could read sections of Chinese newspapers, I had written an English text book for my students, and I made so many friends. All of that came from slow, diligent, hard work—and finding the necessary resources to get things done for my students in non-obvious ways. I had a clearly outlined experience of what diligence and time can do, and I knew deep in me is the potential to learn, adapt, and grow into almost anything.

Two years of remote Peace Corps work (which, despite being among millions of Chinese people, is often an isolating experience) gave me ample time to reflect on my life. While I find teaching deeply rewarding and I love the study of philosophy, I felt that I needed a different pool to swim in than academia. I thought that the private sector would likely offer the most opportunity, so when I came back to the US, I decided to move to San Francisco and aim for a job in tech. I figured that would be like plunging into the ocean, and I was keen to see where the global economic currents might take me.

In the first few weeks I was back in the US I set up 4-5 informational interviews each week. I spoke to people at Google and Square, folks working in event planning, in finance, in HR, in construction, etc. Then one of my colleagues at the university mentioned that their friend (Matthew) had a tech startup called “Cloudflare” and could maybe use some help writing stuff. I followed up right away.

Despite hours of Googling “What is a Cloudflare?”, I was utterly and completely out of my depth when Matthew explained to me what the company does. Before my interview with him, I had done my homework memorizing definitions for acronyms like CDN, DNS, DDoS, and API, but I didn’t really know what they were. The instructions I received before the interview were to learn a bit about how Cloudflare works, and “Don't wear a suit and tie”. This was a time in Cloudflare history when we had about 60 employees, about 30 data centers, and a bit of duct tape in the office pressing extension cords into the carpet.  

I was intimidated speaking to Matthew the first time. He is an amazingly accomplished and incredibly intelligent person. I checked out his LinkedIn profile, and I didn’t know anything about SPAM, law school, business school, being an entrepreneur, or how the Internet works. The folks in Peace Corps China always talked about being resourceful, so I looked for and found an opportunity to connect with him on a level that I could grasp. Matthew, who has unbelievable credentials and professional accolades, still has “Ski Instructor” on his LinkedIn profile somewhere between “Adjunct Professor of Law” and “Harvard Business School”:

I had just spent all of my time in China aiming to build relationships with my students and other people in my community that were from vastly different backgrounds and trying to find common ground from which to build rapport and trust. I thought, if someone this accomplished keeps their ski instructor experience on their resume, it must have a lot of meaning. I’m glad I followed that intuition because this topic led to a great conversation with Matthew about hometowns, ski trips, and ski equipment, which eventually lead to a conversation about surfing and surfboards, which is right in my wheelhouse. It turned out to be a great interview because we connected over things that we both found important. We found a piece of common ground that didn’t seem obvious at first---part of that being a deep curiosity for how and why things work. Looking back five years, I can say without reservation that finding a way to connect with Matthew that day has had a profoundly positive impact on the course of my life.

When it came time for me to interview with our co-founder, Michelle, she understood that I had a lot to learn about the company, and she took the time to draw out a simplified map of Cloudflare’s network on a yellow legal pad. She drew jagged, little clouds around the world and patiently explained what global caching is, how Anycast networking helps with DDoS attacks, and how DNS is like the phone book of the Internet. I was struck that such a highly intelligent person, HBS grad, co-founder of a major tech firm would take time out of their busy day to do this. I learned later that Michelle is always like this. She is amazing with names, stops to talk to folks in the office whenever she can, and sets a tone of respect, compassion, and understanding at the office. It is inspiring.

I then had a video interview with John Graham-Cumming, our CTO, who was in London. There was no getting away from tech with this interview. So I Googled everything I could about John. I read his book Geek Atlas, I watched his TED Talk, and I looked into his interest in Movie Code. I was ready for this interview. We talked about the Parkes Radio Telescope in Australia, Alan Turing, and about the code in the Matrix (thank you, Neo!). John is a fascinating speaker and a legend in the technology space. He is also kind and patient, and he never made me feel silly for not grasping technical concepts right away.

After 6-7 interviews over the following weeks, the feedback I got was that I was a good culture fit, I was hard-working and smart, but I just didn’t have the technical knowledge to do the job. That feedback seemed spot on, but I wasn’t going to let that hold me back. I knew I could be useful to this company. I knew that if they gave me a shot and threw me into the deep end that I would learn to swim. I knew what I needed to do: learn the language and culture of Silicon Valley, make connections, and be resourceful.

I stood outside of the old Cloudflare office at 665 3rd St. in San Francisco, and I told myself that I have to get in that door. I didn’t know exactly what they are doing in there, but it seemed weird and interesting, and I wanted to be a part of it.

So I started learning. Another returned Peace Corps volunteer that I’d met in the Bay Area sat down with me one weekend and helped me build a simple website from the ground up. In the most basic HTML and CSS, we embedded a video we made about my China experience. On the site I made the background color orange to match the Cloudflare logo and wrote something like, “Check it out Matthew and Michelle, I’m learning how to write code!”, and I sent them the link.

In the following weeks, I sent more follow up emails to Matthew than felt polite. But it worked. Matthew, Michelle, and John took a huge risk on me, and I got an offer to be Cloudflare’s “Writer” (since that was really the only thing that made sense for an academic philosopher to do at a tech firm). They actually gave me business cards that read: Andrew A. Schafer - Writer.

When I accepted the offer via email, Matthew wrote back saying that getting up to speed with Cloudflare was “going to be like drinking from a fire hose”.

On day one, I sat down next to the folks on the Data Team and introduced myself. They all said a quick, polite “hi” and then put their head phones back on immediately and continued to write code. I didn’t learn for a long time that engineers DO NOT like to be interrupted when they are coding. This is a key feature of tech culture.

I spent part of my first week at Cloudflare watching a lot of YouTube videos by Eli the computer guy. He does a great job explaining DNS, the OSI model, basic networking, etc. He even has an older video about Cloudflare, which was super helpful (Thank you, Eli!).

Eli, The Computer Guy

At one point John Graham-Cumming walked past my desk and asked me why I was staring at that man in the orange shirt so much. I turned around and exclaimed, “John, did you know that the Internet has LED lasers that blink on and off BILLIONS of times per second?!” He calmly replied, “yes” and then went about his business. That fact made my mind melt. I had so much to learn.

One of the first things I worked on as Cloudflare’s Writer was some of the PR efforts surrounding Project Galileo, DDoS attack protection for at-risk public interest websites, which I’m still proud of. I worked with our legal team to draft up this blog post, which helped me to understand the implications and power of Cloudflare’s technology in real-world terms.

I worked with Nick Sullivan a whole bunch at the beginning also, which was mystifying. He is already a great writer and he was writing about such complex things. There were times where I was adding punctuation to sentences that made sense grammatically, but I didn’t understand their content. I learned a lot about encryption, and my tech vocabulary grew.

At one point I also helped John Graham-Cumming with a few blogs. John is a published author, so I didn’t really help him write anything, but I did help him bring his posts way down to my level. You can see my influence on this blog post about Shellshock. That day I learned the term “zero day vulnerability”.

In that blog John wrote: “Attackers will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a "shell". I read his draft and I asked him, “What is a shell?”. A question, I learned much later, that was highly embarrassing to ask at a tech office. But I didn’t know, and I wanted to know. So we clarified that, “A shell is a command-line where commands can be entered and executed” in the post just in case other tech noobs like myself were trying to follow along. I learned how to be a translator from tech-speak to normal English.

I even researched and wrote a few posts of my own, like this one about Raspberry Pi’s fronted by Cloudflare. I had no idea what a Raspberry Pi was before being asked to write this. Thankfully one of the folks on the Data Team had one and let me borrow it for a photo op. I learned about the inspiring philosophy behind Raspberry Pi and the vibrant community that uses them.

As the official Cloudflare Writer, I was proud of writing the copy for our dashboard. That project was an amazing way for me to get to know a lot of key members of the engineering team and have them teach me exactly how each feature worked. I wrote out what I understood, clarified some points with them, and then made a pull request to get the explanations into the code base for our dashboard.  

If you’ve ever used these help menus—you are welcome! (Note: lots of other Cloudflare team members have kept this updated and expanded.)

Eventually, I became an honorary member of the Data Team. It took some doing, but I learned Python the hard way, and I wrote a Python script that would print my name 100,000 times in the terminal. I crashed my machine when I tried to make it print my name 100,000,000,000,000 times. I learned something about code that day—it can break things.

I ran this code while sitting next to the person who had built Cloudflare’s original database. I did a victory dance when I crashed my laptop I was so proud of myself. That is sort of like me bragging about my backyard badminton skills next to Serena Williams.

I dipped my toes into the language of code, and started to speak that language with the engineers around me. This helped me to learn an important lesson about tech culture: the deeper your technical understanding the greater the respect you receive.

Eventually, I was ready for a new challenge at Cloudflare—talking to our clients.

The first thing I learned in a client facing role at Cloudflare is that Cloudflare is not a widget or a nice-to-have—it is mission critical technology for everyone that uses it. When something goes wrong people are very upset. The second thing I learned in a client facing role at Cloudflare is that the Internet is a fragile little teacup and it runs on human trust—which is astonishing. The combination of those two facts created ample opportunity for me to develop my listening and communication skills.

I started by rereading How to Win Friends and Influence People, by Dale Carnegie and took special note of rule number four, which states, “Be A Good Listener”. I quickly graduated to the philosophy and practice of Nonviolent Communication, by Marshall B. Rosenberg. I ended up taking some NVC courses in San Francisco focused on listening skills in this style. I also took compassion meditation courses via Stanford a few years in a row, which had a profound impact on my ability to empathise with our clients.

While brushing up on and honing these interpersonal skills was helpful, what I learned in a lot of those early meetings with clients was that I need to understand Cloudflare’s technology better. It’s one thing to be able to talk about it, it’s a whole different thing to be able to understand it enough to solve real issues.

I decided to do the “homework” our Solutions Engineering team gives out to their hiring candidates. I had to learn command-line basics, create an origin web server on DigitalOcean, install Ubuntu, configure a firewall, install NGINX, create a simple website from HTML, add an image to that site, set up DNS, and then put Cloudflare in front of it.

I set up my first DNS record in Cloudflare to point to my origin server, and was like “OHHHHHHH SNAP! That is how DNS works! It maps my domain name to the IP address of my server!” Hands on learning makes all the difference.

And I learned that WWW is a subdomain of the apex!! What???

It wouldn't be a legit Cloudflare blog without more code, so here we go. I ended up writing (modifying) this amazing piece of code based on the NGINX HTML welcome page template:

Notice that I added an image:

I’m now a web developer! I’ve added yet another cat photo to the Internet. You are welcome world! (Note at the time of publishing my site is offline [I forgot to renew the domain—oopsy]).

Once I had my site up and running on Cloudflare, I learned how to make API calls to pull down the our Enterprise raw logs and use jq to sort them (jq, I learned, is “a lightweight and flexible command-line JSON processor”):

curl -H "X-Auth-Email: aschafer@cloudflare.com" -H "X-Auth-Key:
cc1e78b22222229b9d72643fbda69655579d" -H "Content-Type: application/json" 
"https://api.cloudflare.com/client/v4/zones/f5fb827cf31f628c1c0730bc4b0792d
d/logs/requests?start=0&count=1" | jq 'select(.clientRequest.uri == 
"/admin"), .client.ip'| sort | uniq -c | sort -r

(Note: This cURL command does not contain a real API key. I learned the hard way to NEVER include the API key when sharing a cURL.)

I was so proud. I could say things like, “pull down the raw logs and pipe them into jq” to my clients, and I actually knew what I was saying—my tech language skills were improving.

I then read “High Performance Browser Networking” by Ilya Grigorik. I didn't even understand what that title meant at first. I had to translate it into non-tech English. It turns out that, for example, Chrome is a high performance browser, which is a tool you use to navigate a network of computers, a.k.a. the Internet. So it is a guide book for building the most performant web apps within the limits of current browser and networking technology.

Grigorik’s philosophy resonates with me, “Good developers know how things work. Great developers know why things work.” Insert any other profession or art and the statement remains true.

It took me six months of reading on bus rides to work, but by the end I could say things like, WebSocket API, Subprotocol Negotiation, TLS OCSP Stapling, and TCP Head-of-Line Blocking. I learned from Grigorik that, “TCP provides the abstraction of a reliable network running over an unreliable channel, which includes basic packet error checking and correction, in-order delivery, retransmission of lost packets, as well as flow control, congestion control, and congestion avoidance designed to operate the network at the point of greatest efficiency. Combined, these features make TCP the preferred transport for most applications.” Who knew?

After putting so much work into learning what Cloudflare really does, I came to understand something fundamental about the tech world: the learning never stops. Never. The fire hose never turns off.  

When I started at Cloudflare we offered more domains and extra SSL cert hosting slots as our additional products. Now we have Workers and Access and Argo and Argo Tunnel and Spectrum and Load Balancing and Stream and a Mobile SDK, and the list keeps growing. And we all have to learn about all of this new technology as it gets released. It is amazing!

Over the last few years, I’ve learned the language of Silicon Valley, and more specifically, I can speak the language of Cloudflare fluently. That has made a huge difference in my career.

I’ve enjoyed a lot of successes at Cloudflare, but the one achievement I’m most proud of is creating the “Big Horse Award for Strong Work”.

The idea for this came directly from chapter 2 of How to Win Friends and Influence People: “Give honest and sincere appreciation”. I make it a point to tell the folks I work with that they are doing outstanding work every chance I get because the folks I work with really are doing outstanding work all the time, and they should know about it.

Maybe three years ago my best friend at Cloudflare sent me a message via HipChat that read something like: “Hey Big Horse, you check that Jira ticket yet?”. From that day forward I called everyone “Big Horse” on HipChat at all times, which I thought was hilarious and everyone else thought was weird or annoying.

Shortly after that, in an effort to step up my “Give honest and sincere appreciation” game, I started sending emails to the whole company pointing out the strong work our support team was doing in our Zendesk customer support tickets. Our support team is world-class, but since only a few teams in the office can access Zendesk, a lot of folks internally don’t see their amazing work. I decided to take screenshots of tickets that were particularly well-handled and share them. I’d titled these emails “Strong Work, Big Horse!”. I quickly learned that emailing the whole company “does not scale”.

This culminated at one of our all hands B.E.E.R. meetings, where I gave out a Big Horse Award to a few outstanding members of our Support team. I had this stunningly beautiful trophy made for the occasion:

We needed a logo, so I Googled “stupid horse drawings” and found an image. With a little editing via photo editor and PowerPoint, a meme was born:

Since then we’ve had all sorts of iterations of the Big Horse logo:

And we had paraphernalia made:

Our support team even spray painted “Big Horse” on the side of a building on 4th St in downtown San Francisco on a team outing:

We’ve issued a new Sparkle Lama award as well—since not everyone wants to be called a big horse:

Many Cloudflare team members have Big Horse and Sparkle Lama stickers on their laptops, and we’ve shipped those golden big horse trophies around the world to our London and Singapore offices. These symbols have become easy ways to let our teammates know that they are doing great work. It is a small thing, but it adds up and helps make Cloudflare a great place to work.

Just a few weeks ago this Tweet was pointed out to me:

"For a reason I don’t understand yet, members of the Cloudflare engineering team own over 2% of all active .horse domains in the world" > https://t.co/IhGW55Oi2h

— Neil Levine (@neilwlevine) February 22, 2019

Well, Neil, the reason for this is that a few engineers and myself had big plans of launching a website around the Big Horse Award, we bought big.horse and a few others, but we didn’t follow through—yet. Stay tuned.

The Big Horse and Sparkle Lama Awards are my contribution the tech culture I’ve been a student of these last few years.

Five years after those first conversations with Matthew, Michelle, and John, I’m headed back to China with Cloudflare!

We are expanding our presence in China, and I have the good fortune (幸福) to combine the skills I acquired in philosophy and in the Peace Corps with the skills I acquired in Silicon Valley. We will be onboarding new Chinese clients, hiring more team members, and building out partnerships with other Chinese tech firms. I’m incredibly lucky to be headed back to a country that I love and embark on a new adventure.

I have a whole new fire hose aimed at me, and I plan to drink deep. I’ve been taking Mandarin classes again, this time to learn words like encryption (加密), caching (缓存), and cloud software (云软件). I’ll be learning a whole new interpersonal skill set around working with clients in China and across Asia. And since the office is just starting, this project will be a new exercise in resourcefulness.

 life_journey = ["China", "Silicon Valley", "China"]
for x in life_journey
   print(x)

I had no idea how much opportunity lay before me when I walked in the door as “the writer”, and I am profoundly grateful that Cloudflare took a chance on me. I plan to throw myself into this project in China, to learn and grow and contribute, and to figure out the best way to translate “Strong Work, Big Horse” into Mandarin.

我非常开心回去中国帮助成立我们的北京分部！

Photo by chuttersnap / Unsplash

At the end of 2017, Xinhua reported that there will be 200 Million IPv6 users inside Mainland China by the end of this year. Halfway into the year, we’re seeing a rapid growth in IPv6 users and traffic originating from Mainland China.

IPv6 is often referred to the next generation of IP addressing. The reality is, IPv6 is what is needed for addressing today. Taking the largest mobile network in China today, China Mobile has over 900 Million mobile subscribers and over 670 Million 4G/LTE subscribers. To be able to provide service to their users, they need to provide an IP address to each subscriber’s device. This means close to a billion IP addresses would be required, which is far more than what is available in IPv4, especially as the available IP address pools have been exhausted.

To solve the addressability of clients, many networks, especially mobile networks, will use Carrier Grade NAT (CGN). This allows thousands, possibly up to hundreds of thousands, of devices to be shared behind a single internet IP address. The CGN equipment can be very expensive to scale and further, given the scale of the networks, they might need to layer CGNs behind other CGNs. This increases costs per subscriber, can reduce performance and makes scaling very challenging. A further solution, NAT64, allows IPv6 addresses to be given to subscribers, but then translated to IPv4 addresses similar to other NATs. This allows networks and ISPs to begin deploying IPv6 to subscribers, a first step in transition to IPv6.

Announcements IPv6 address blocks from China Mobile. Source: Hurricane Electric

On June 7, China Mobile started to announce IPv6 address blocks to the Internet at large. At the same time, Cloudflare started seeing traffic being exchanged with China Mobile users over IPv6 connections.

IPv4 to IPv6 percentage of traffic as seen from Cloudflare to AS9808 China Mobile’s Guangdong network.

Throughout the past 45 days, we’ve seen more and more IPv6 address blocks being announced to the internet, along with very aggressive usage. Interestingly this all started on-or-around June 8th 2018 (seven years to the day from World IPv6 Day)

It’s natural to see traffic graphs like this go up; then down after a while. This could indicate there’s some testing still going on with the deployment. We fully expect that the traffic percentage will climb back up once this is fully rolled out.

It’s fantastic to see the IPv6 enablement! We congratulate China Mobile on their successful enablement going forward.

Almost as soon as Dyn came under attack we noticed a sudden jump in DNS errors on our edge machines and alerted our SRE and support teams that Dyn was in trouble. Support was ready to help joint customers and we began looking in detail at the effect the Dyn outage was having on our systems.

An immediate concern internally was that since our DNS servers were unable to reach Dyn they would be consuming resources waiting on timeouts and retrying. The first question I asked the DNS team was: “Are we seeing increased DNS response latency?” rapidly followed by “If this gets worse are we likely to?”. Happily, the response to both those questions (after the team analyzed the situation) was no.

CC BY-SA 2.0 image by tracyshaun

However, that didn’t mean we had nothing to do. Operating a large scale system like Cloudflare that deals with the continuously changing nature of the Internet means that there’s always something to learn.

Back in July 2015 Dyn had an outage that also affected some of our customers and we changed our handling of so-called infrastructure DNS records in response to prevent a similar problem, from any provider, affecting Cloudflare.

Based on what we learned last Friday we are making some changes to our internal DNS infrastructure so that it performs better when a major provider is having problems or an outage (whether caused by DDoS or not). To understand those changes it’s helpful to take a look at the role of DNS and what we saw on Friday.

The Domain Name System (DNS) provides an address book service for the Internet. It is responsible for converting the friendly, human-readable domain names we type into our web browsers to IP addresses for websites. Let’s walk through the life of an example web request to see where DNS plays a role.

We can start by entering a web address into our browser, https://www.cloudflare.com/. The browser translates this name into an IP address so it can contact the server that’s hosting the page, it will do this using DNS. We can make these DNS queries ourselves using the dig command line tool to see what values are returned.

$ dig www.cloudflare.com A
...
;; QUESTION SECTION:
;www.cloudflare.com.		IN	A


;; ANSWER SECTION:
www.cloudflare.com.	10	IN	A	198.41.215.162
www.cloudflare.com.	10	IN	A	198.41.214.162

The DNS data model is split into two core concepts, names and records. The name here is www.cloudflare.com and the record type we have queried is A, which is used to store IPv4 addresses. There are other types of records for storing other types of data, e.g AAAA records for IPv6 addresses. We can see from the answer above that there are two IPv4 addresses for www.cloudflare.com; the browser picks one of these to use.

Records in the DNS also have an associated TTL which defines how long the data should be cached for, these records have a TTL of 10 seconds. This means the browser can store this information and skip making further DNS queries for the domain for the next 10 seconds.

For Cloudflare customers, the answer will contain our Anycast IPs instead of the origin ones (the IP addresses of the web hosting provider). The browser will then send requests to us, and we will serve content from our cache or proxy the request to the origin web server.

There are two common ways of configuring origins on Cloudflare. The first is to specify A and AAAA records, which explicitly provides us with the IP addresses of the origin. In this situation, our network knows ahead of time where it can contact the origin, so no further DNS resolution is required. For example, if www.example.com uses Cloudflare and has specified 2001:db8:5ca1:ab1e as the IP address of the origin server in the Cloudflare control panel, we can connect directly to the origin server to retrieve resources.

The other is to use a CNAME, which is a pointer to another DNS name.

When our servers receive a request with the origin configured using a CNAME, we have to perform an external DNS lookup to resolve the target of the CNAME to IP addresses. This information is cached, based on the TTL defined on the CNAME record. In this case, our ability to serve content (that is not in the cache) entirely depends on an external DNS lookup to resolve the CNAME to IPs.

For example, suppose www.example.com had set up a CNAME in the Cloudflare control panel pointing to server11.myhostingprovider.biz it would be necessary to look up the IP address of server11.myhostingprovider.biz before contacting the origin server.

In many cases the target of a CNAME is handled by a third party DNS provider. If the third party provider is unable to answer our query, we are unable to resolve the domain to an origin IP and cannot serve the request.

As Dyn says in their discussion of the DDoS attack there were three distinct waves. For Cloudflare that manifested itself in two periods during which our internal DNS query error rate spiked.

The first attack started at 1110 UTC and mostly affected DNS resolution on the US East Coast. This world map from our monitoring systems shows the Cloudflare data centers where the DNS error rate was spiking because of the Dyn outage.

The green dots on the map are Cloudflare data centers that were unaffected by the Dyn DDoS. The largest effect was on the US East Coast, although the attack had a knock-on effect in Singapore and some parts of Europe. This is most likely because the architecture of the Internet does not directly line up with geography. Locations that are physically disparate can sometimes appear ‘close’ on the Internet because of undersea cables or decisions on how to route traffic.

The chart shows the DNS error rate in each Cloudflare data center affected by the outage. It’s possible to see the attack ramp up rapidly and then remained sustained until Dyn was able to tackle it.

Later in the day the attackers returned with greater force and had a worldwide impact. This map shows the Cloudflare data centers seeing errors because Dyn was inaccessible. As you can see almost the entire planet was affected (with the exception of our China locations; we’ll return to why below).

Once again it’s possible to see the attack ramping up at 1550 UTC and continuing for some time. Dyn reports that the attack was fully mitigated at 1700 UTC.

Media and Dyn reported a third wave of attacks later on Friday, but Dyn mitigated that wave immediately and so fast that it did not have any affect on Cloudflare protected websites and applications and did not show up in our systems.

During the most intense period of attack on Dyn our locations in China were almost completely unaffected. That’s because we handle DNS a little differently inside China.

To cope with sometimes fluctuating network conditions inside China our data centers are configured to keep DNS records for origin servers cached in our servers for longer than the rest of the world. This caching meant that even though Dyn was down and couldn’t be reached from anywhere (including China) we still had cached DNS records for sites that used Dyn on our China servers. Thus we were able to reach origin servers and continue serving content. That shows up as green dots on the map above.

Unfortunately, there’s a downside to hanging on to DNS records for a long time: if one of our customers changes their origin’s DNS records we’ll keep using the old DNS records and IP addresses. That could lead to downtime, or poor service.

The ideal system would recheck DNS records frequently so that changes are reflected quickly but in the event that the upstream DNS provider was unavailable (because of an attack or other outage) it would be able to use the DNS records it has cached.

Doing so is known as ‘serve stale while revalidating’. Our upstream DNS resolvers will cache records checking frequently for changes. If the upstream DNS is unavailable we’ll continue to serve from cache until it’s possible to refresh the DNS records.

We are testing and rolling out that change now and expect this to greatly diminish the impact of events similar to the Dyn DDoS for all of our customers who use CNAME’d DNS records that rely on a third-party DNS provider.

The Internet is a shared space. Because companies, people, and institutions work together we have a global, connected network that allows us to work and play from almost anywhere. Cooperation means that we work together on standards and interoperability to keep the network running and evolving.

But the Internet is very complex and, as with many things, the devil is in the details and operating Internet infrastructure is a process of constant improvement. Although the Dyn DDoS felt scary to many people unfamiliar with how the Internet operates, such attacks result in a stronger network. Just as Cloudflare is making changes to its software and configuration, so are others across the net.

We are always looking to hire smart people interested in making DNS and the Internet better for everyone. Jobs can be found here.

In the last five years we've stopped 7 trillion cyber attacks, saved more than 94,116 years worth of time, and served 99.4 trillion requests — nearly half of those in the last 6 months. You can learn more from this timeline of the last five years.

Every year we like to celebrate our birthday by giving something seemingly impossible back to our users. Two years ago we enabled on our Automatic IPv6 Gateway, allowing our users to support IPv6 without having to update their own servers. Last year we made Universal SSL support available to all our customers, even those on our free plan. And this year, we announced the expansion across Mainland China, building the first truly global performance and security platform.

We celebrated in San Francisco last week with CloudFlare's first Internet Summit at our new San Francisco Headquarters with more than 500 of our customers and friends. Speakers discussed their visions for the challenges and opportunities for the Internet over the next five years. We'll be posting videos of those talks over the course of this week. In the meantime, here are some photographs from the Summit and the party later that night with one of our favorite bands, Walk Off the Earth.

Thanks everyone for your support over the last five years. As Michelle likes to say, we're just getting started.

CloudFlare launched five years ago. Within a year of our launch, the biggest surprise was the strong global demand for our service. From nearly the beginning, China was the second largest source of traffic by country to our network, behind only the United States.

In retrospect, that shouldn't have been a surprise. In 2010, the year we launched, 34% of China's population, or 450 million people, were online. Today, nearly half the country is online. To put it another way, with 700 million people online, China represents a quarter of all Internet users. If your mission is to help build a better Internet, like CloudFlare's is, then China is a country you cannot ignore.

Consequently, starting in 2011, we began to investigate how CloudFlare could bring our service to the Chinese Internet. Four years later, we're excited to announce the extension of CloudFlare's performance and security platform across mainland China. This is the story of how we did it.

There are three major challenges to extending a service like CloudFlare's across mainland China: technical, economic, and regulatory.

Technical

From a technical perspective, the Chinese Internet, despite its many similarities, is different than the rest of the world. Unlike much of the rest of the world where network routing is open, in China core Internet access is largely controlled by two ISPs: China Telecom and China Unicom. These ISPs control IP address allocation and routing inside of the country. Even the Chinese Internet giants rarely own their own IP address allocations, or use BGP to control routing across the Chinese Internet. This makes BGP Anycast and many of the other routing techniques we use across CloudFlare's network impossible inside of China.

At the same time, there are also frequent bottlenecks both within and between the domestic ISPs. For instance, China Telecom operates many distinct networks across several provinces, many of which operate independently of one another. The interconnection points between these networks, and the ISPs themselves, are also candidates for congestion, with too much traffic paired with too little capacity. The connectivity between different ISPs in different provinces can become so fraught that it is sometimes more efficient to route traffic outside the country, across a third party network, and then back in.

Economic

The technical challenges of the Chinese Internet drive up the costs of doing business as a service provider. Because of local market dynamics among ISPs, the cost of bandwidth, and particularly Anycast bandwidth, is among the highest in the world. Moreover, in order to get adequate performance and route around congestion, you need a large number of geographically distributed data centers across the country. Not an easy feat for a new, non-Chinese entrant to the market.

Despite what some non-Chinese cloud providers suggest, to provide a quality service in China is not as simple as putting up a single location in Beijing. In fact, when we tested the performance of other non-Chinese cloud providers who claimed to have established a presence in mainland China, we were surprised to find that Chinese traffic to their networks was often routed outside of the country through the West Coast of the United States before being delivered back into the country (what is known as networking tromboning). This inherently adds hundreds of milliseconds per request and, ironically, often makes it more likely the content will never be delivered.

The high cost of bandwidth, and the requirement to have a large number of data center locations in order to adequately service the country, makes providing service inside China extremely costly. These costs are further compounded by the difficulty of importing equipment into the country from abroad.

Regulatory

As is the case in many countries, Chinese law prohibits the announcement of certain types of content inside of the country. Although such policies vary greatly between countries, in order to maintain local operations, it is necessary to comply with all local laws and regulations in each country in which we operate. In the case of China, any organization that wishes to operate a website inside of the country needs an Internet content provider (ICP) license from the Chinese Ministry of Industry and Information Technology (MIIT). We investigated whether it would be possible for CloudFlare to obtain an ICP license to cover all our customers, but determined that licenses needed to be issued on a per-site basis. This introduced an enormous amount of regulatory complexity.

Another technical and policy challenge involves the determination of what content can, and cannot be served from within China. At CloudFlare, we fundamentally believe that we should not act as an Internet censor. While we strictly adhere to local rules and regulations, we are careful to do so in a manner that preserves a free and open Internet. Although we may not be able to announce certain content from within China, or any other country in which certain content may be prohibited, we continue to serve it across the Internet from the rest of the network.

After a survey of our customer base, we determined that more than 99% of our customers’ websites are locally available in China today. This provides a tremendous opportunity to increase the performance and security for millions of websites to 700 million Internet users in China. In the meantime, those of our customers that do not qualify for a permit would continue to be served across our network outside of China with a level of performance and security that is neither any better nor worse.

These challenges made it clear that we would be unable to enter the Chinese market on our own. Instead, like others in our space, we started looking for a local partner to resell access to China on top of our own service. The problem with this approach is that, in addition to adding expense, it also adds significant complexity. The features of any local provider's platform were different from our own, meaning that our customers couldn't rely on a unified platform to provide global performance and security, and the customer experience was poor.

Even though we didn’t have a presence in mainland China, we were surprised that Chinese companies continued to sign up for CloudFlare's service. When we surveyed them, there were two primary reasons: 1) we were better at mitigating DDoS attacks (a huge problem for businesses in China) than any rival service; and 2) they had an audience outside of China, and wanted access to our global network even if it meant that their performance suffered at home.

By the summer of 2013, CloudFlare's market share inside China began to get the attention of several Internet companies in the region. Despite the fact that several services with similar feature sets to CloudFlare had started to spring up in China, CloudFlare quickly became the market share leader. Beginning that summer, we began to meet with potential partners to discuss whether there was a way to work together.

Traditionally, when tech companies enter China they do so with a partner and form what is known as a joint venture. We studied the various JVs that other tech companies had formed and came away with the conclusion that they were largely unsuccessful. The repeated mistake appeared to be that non-Chinese tech companies applied too heavy a hand, assuming that what had worked outside of China would work inside of the country.

We concluded that if a collaboration was going to work, we needed to start with the premise that it was a true partnership with CloudFlare providing technology and access to our global network, and the partner contributing local Chinese knowledge and operations. This meant that selecting the right partner was critical.

Among the proposals that we received, Baidu's stood out. Baidu is China’s leading search engine. As we got to know the Baidu team, it was clear that their mission and ethos aligned closely with our own. Moreover, as one of the Internet giants of China, they had the expertise and resources to help us overcome the aforementioned technical, economic, and regulatory challenges.

Today, we're proud to announce our partnership with Baidu as well as the launch of 17 data centers across mainland China—in Qingdao, Fuzhou, Hengyang, Dongguan, Shenyang, Luoyang, Hangzhou, Jiaxing, Tianjin, Guangzhou, Chengdu, Langfang, Xian, Nanning, Zhengzhou, Shijiazhuang, and Foshan. In the months ahead, we will continue to expand our footprint in the country, and expect that by the end of 2016 there will be more locations in mainland China than exist across all the rest of CloudFlare's network today.

Globally, CloudFlare’s network now extends to 62 data center locations:

Baidu's regulatory expertise also helped to solve what previously seemed like an insurmountable problem. They developed a process whereby ICP license applications could be automatically submitted on behalf of CloudFlare customers. This removes the burden of individual customers having to navigate local licensing requirements.

In addition to making China available to CloudFlare's customers, we also worked with Baidu to launch their own service: Yunjiasu (百度云加速), which roughly translates to “fast cloud.” Chinese customers of the Yunjiasu network receive the same performance and security benefits as CloudFlare, including access to CloudFlare’s global network. Yunjiasu has grown rapidly since it its launch in December 2014. Already, the service is used by hundreds of thousands of customers, and serves more than 57 billion page views per month. Between CloudFlare and Yunjiasu, we power more than 60% of all websites using a performance and security service in China today.

The performance benefits of our China expansion are staggering. We are now able to reduce the time to serve a request from outside of China by over 200ms. Across the span of a single day, the time savings for all the requests served inside China across the CloudFlare and Yunjiasu services collectively saves more than 240 years of time that Chinese Internet users would otherwise have to wait for websites to load. Moreover, website availability in China for sites served on the China network has nearly doubled. These benefits will only increase as we begin to serve more customers across the China network.

To give you a sense, one of the first customers to be served across the China network was TechCrunch. CloudFlare has a close relationship with the TechCrunch team, having launched at their Disrupt conference in 2010, and we were happy to learn that TechCrunch’s local China edition is just as widely followed as it is in the US. Before TechCrunch.cn went live on CloudFlare's China network, page loads in mainland China averaged 17 seconds. Now they average 2.5 seconds.

Similar improvements were registered for site availability. Before enabling the China network, TechCrunch.cn was only available about 50% of the time in mainland China. Now the site averages nearly 100% availability.

The benefit of a network inside mainland China goes beyond just performance. Given its large Internet population, China, like other countries, has a number of active botnets. These botnets can be used to launch large-scale distributed denial of service (DDoS) attacks. Some of the largest attacks we see come from botnets with a large number of nodes inside China. With a network inside China, CloudFlare is now better able to sinkhole attacks before they leave the country. This means that attack traffic originating inside China is less likely to cause disruptions for customers outside of the region.

As we’ve extended our network into China, we’ve also taken numerous steps to ensure the security and integrity of our customers’ data. CloudFlare operates all services outside of China, and Baidu all services inside of China. No CloudFlare customer traffic will pass through the China network unless a customer explicitly opts-in to the service. A customer’s traffic and log data from outside of China is never sent into China. And, for customers that opt-in to serving content inside China, customer identifiable information such as email addresses, password hashes, and billing information is never stored in the China network or shared with our partner.

The security and privacy of other potentially sensitive information is also strictly maintained. For instance, CloudFlare's Keyless SSL technology allows us to serve encrypted traffic for customers who opt-in to the China network without having to store private SSL keys within the China network. This allows any customer to receive the benefits of CloudFlare’s full suite of services, even if they elect to have their keys stored outside of China.

The same is true for Yunjiasu customers. While they get the benefits of CloudFlare's global network, we’ve worked with Baidu to ensure that personal information is kept with Baidu and never shared with CloudFlare.

As part of this partnership, CloudFlare was never asked nor did we ever volunteer to provide any data about any of our users to China, the United States, or any other governmental authority. Had that been a requirement of entering the region, we would have passed on the opportunity.

Existing and new CloudFlare customers can request to be served in China by filling out an information request at:

https://www.cloudflare.com/china

Initially, the China network will be limited to Enterprise customers. Over time, as we are better able to operationalize the onboarding of customers, we hope to extend the benefits to all plan levels.

This is an announcement that has been four years in the making. We’re excited to have built the only truly global performance and security platform. And, while China is the largest country in the world that--until today--didn’t have any CloudFlare data centers, there’s another one that’s almost as big that’s still missing some. Stay tuned as that’s soon about to change.

In CloudFlare's relentless effort to make the web faster and safer worldwide, we're excited to announce our newest data center came online last night: Hong Kong. Approximately 10% of the traffic to CloudFlare's network currently originates from Hong Kong and China. The new data center will help give users in this region a substantially faster experience.

The facility includes our latest hardware upgrades, specifically designed to help mitigate DDoS attacks. Since a significant percentage of the attacks we see come from this region, having a data center closer to the front line will help significantly lessen the load on our existing facilities in Los Angeles and San Jose that have previously borne the brunt of these attacks.

Next up: Paris and Dallas.