Archive

Category Archives for "CloudFlare"

CloudFlare Now Supports WebSockets

CC BY 2.0 from Brian Snelson

I'm pleased to announce that CloudFlare now supports WebSockets. The ability to protect and accelerate WebSockets has been one of our most requested features. As of today, CloudFlare is rolling out WebSocket support for any Enterprise customer, and a limited set of CloudFlare Business customers. Over the coming months, we expect to extend support to all Business and Pro customers.

We're rolling out WebSockets slowly because it presents a new set of challenges. The story below chronicles the challenges of supporting WebSockets, and what we’ve done to overcome them.

The Web Before WebSockets

Before diving into WebSockets, it's important to understand HTTP—the traditional protocol of the web. HTTP supports a number of different methods by which a request can be sent to a server. When you click on a traditional link you are sending a GET request to a web server. The web server receives the request, then sends a response.

When you submit a web form (such as when you're giving your username and password when logging into an account) you use another HTTP method called POST, but the interaction is functionally the same. Your browser (called the ‘client’) sends data to Continue reading

Experimenting with mozjpeg 2.0

One of the services that CloudFlare provides to paying customers is called Polish. Polish automatically recompresses images cached by CloudFlare to ensure that they are as small as possible and can be delivered to web browsers as quickly as possible.

We've recently rolled out a new version of Polish that uses updated techniques (and was completely rewritten from a collection of programs into a single executable written in Go). As part of that rewrite we looked at the performance of the recently released mozjpeg 2.0 project for JPEG compression.

To get a sense of its performance (both in terms of compression and in terms of CPU usage) when compared to libjpeg-turbo I randomly selected 10,000 JPEG images (totaling 2,564,135,285 bytes for an average image size of about 256KB) cached by CloudFlare and recompressed them using the jpegtran program provided by libjpeg-turbo 1.3.1 and mozjpeg 2.0. The exact command used in both cases was:

jpegtran -outfile out.jpg -optimise -copy none in.jpg

Of the 10,000 images in cache, mozjpeg 2.0 failed to make 691 of them any smaller compared with 3,471 for libjpeg-turbo. So mozjpeg 2.0 was significantly better at recompressing images.

On average Continue reading

Listo! Medellin, Colombia: CloudFlare’s 28th Data Center

“What’s that? CloudFlare’s 28th data center is in Medellin, Colombia!?”

With the World Cup at an end, so too is our latest round of data center expansion. Following deployments in Madrid, Milan and São Paulo, we are thrilled to announce our 28th data center in Medellin, Colombia. Most of Colombia’s 22 million Internet users are now mere milliseconds away from a CloudFlare data center.

A data center unlike the others

Our deployment in Medellin is launched in partnership with Internexa, operators of the largest terrestrial communications network (IP backbone) in Latin America. Internexa operates over 28,000 km of fibre crossing seven countries in the continent. Our partnership was formed over a shared vision to build a better Internet—in this case, by localizing access to content within the region. Today, it is estimated that as much as 80% of content accessed in Latin America comes from overseas. It is with great pride that, as of now, all 2 million sites using CloudFlare are available locally over Internexa’s IP backbone. Let’s just say we’ve taken a bite out of this percentage (and latency)!

Lots of bits in Medellin

If your Internet service provider (ISP) is not connected to Internexa, Continue reading

Courage to change things

This was an internal email that I sent to the CloudFlare team about how we are not afraid to throw away old code. We thought it was worth sharing with a wider audience.

Date: Thu, 10 Jul 2014 10:24:21 +0100
Subject: Courage to change things
From: John Graham-Cumming
To: Everyone

Folks,

At the Q3 planning meeting I started by making some remarks about how much
code we are changing at CloudFlare. I understand that there were audio
problems and people may not have heard these clearly, so I'm just going to
reiterate them in writing.

One of the things that CloudFlare is being brave about is looking at old code
and deciding to rewrite it. Lots of companies live with legacy code and build
on it and it eventuallybecomes a maintenance nightmare and slows the company
down.

Over the last year we've made major strides in rewriting parts of our code
base so that they are faster, more maintainable, and easier to enhance. There
are many parts of the Q3 roadmap that include replacing old parts of our
stack. This is incredibly important as it enables us to be more agile and 
more stable in future.

We should feel good  Continue reading

CloudFlare Joins Three More Peering Exchanges in Australia

In the coming weeks, connectivity to CloudFlare in Australia is going to a new level. As part of CloudFlare’s ongoing upgrades program, we established connections to three new Internet exchanges: the Megaport Internet exchanges in Sydney, Brisbane, and Melbourne. These connections doubled the number of Australian Internet exchanges we reach and marked the first exchanges outside of Sydney that Cloudflare participates in.

What is Peering?

When two ISPs peer, they agree to exchange traffic directly between each other rather than sending it a third party. By doing this, both partners avoid congested paths between transit providers, and they avoid paying to ship traffic—it's win-win!

What peering exchanges mean for CloudFlare is that we can significantly increase our service performance to users on ISPs that peer with us. Take Australia for example, for users who are currently on ISPs peering at Megaport, instead of CloudFlare sending traffic to the transit providers of those ISPs, we can now route the traffic directly to them. The result is lower latency, and traffic taking paths that are often less congested.

Low latency is crucial for internet speed due to the nature of TCP, the fundamental protocol on which the internet is built. TCP operates Continue reading

1 136 137 138