Caching the uncacheable: CloudFlare's Railgun

CloudFlare recently rolled out a premium service called Railgun that's available to CloudFlare Business and Enterprise customers. Railgun is web optimization software that's designed to speed up the delivery of content that cannot be cached.

One of the major advantages of using CloudFlare is that cacheable content (such as images, JavaScript, CSS and HTML) is both cached by CloudFlare and delivered from our data centers around the world. Because CloudFlare has data centers covering the entire globe, cached content gets delivered quickly to web surfers wherever they are (and overcomes latency problems).

But only about 66% of content is cacheable. The other 34% must be obtained from the real origin web server. Railgun overcomes this problem by using a scheme that is able to cache dynamically generated or personalized web pages dramatically reducing bandwidth used and improving download times.

(Image credit: DaveFayram)

Caching the Uncachable

Railgun works by recognizing that uncacheable web pages do not change very rapidly. For example, I captured the CNN homepage HTML once, and then again after 5 minutes and then again after one hour. The page sizes were 92,516, five minutes still 92,516 and one hour later 93,727.

CNN sets the caching on this page to 60 seconds. After one minute it's necessary to download the entire page again. But looking inside the page itself not much has changed. In fact, the change between versions is on order of 100s of bytes out of almost 100k. Here's a screenshot of one of the small binary differences between the CNN home page at five minute intervals. The yellow bytes have changed, the rest have not:

Experiments at CloudFlare has revealed similar change values across the web. For example, changes by about 2.15% over five minutes and 3.16% over an hour. The New York Times home page changes by about 0.6% over five minutes and 3% over an hour. BBC News changes by about 0.4% over five minutes and 2% over an hour.

Although the dynamic web is not cacheable, it's also not changing quickly. That means that from moment to moment there's only a small change between versions of a page. Railgun uses this fact to achieve very high rates of compression. This is very similar to how video compression looks for changes from frame to frame; Railgun looks for changes on a page from download to download.

The Technical Details

Railgun consists of two components: the sender and the listener. The sender is installed at every CloudFlare data center around the world. The listener is a software component that premium customers install on their network.

The sender and listener establish a permanent TCP connection that's secured by TLS. This TCP connection is used for the Railgun protocol. It's an all binary multiplexing protocol that allows multiple HTTP requests to be run simultaneously and asynchronously across the link.

To a web client the Railgun system looks like a proxy server, but instead of being a server it's a wide-area link with special properties. One of those properties is that it performs compression on non-cacheable content by synchronizing page versions.

Each end of the Railgun link keeps track of the last version of a web page that's been requested. When a new request comes in for a page that Railgun has already seen, only the changes are sent across the link. The listener component make an HTTP request to the real, origin web server for the uncacheable page, makes a comparison with the stored version and sends across the differences.

The sender then reconstructs the page from its cache and the difference sent by the other side.

Blowing the Doors Off Standard Gzip

Of course, compression is used on web pages today. The most common technique is to gzip the page itself. CNN actually does this and sends 23,529 bytes of gzipped data which when decompressed become 92,516 bytes of page (so the page is compressed to 25.25% of its original size). And Google has proposed a somewhat complex dictionary based scheme called SDCH which is not widely deployed.

But the Railgun compression technique goes much further. The compression between versions 1 and 2 of the page above (at five minute intervals) results in just 266 bytes of difference data being sent (a compression to 0.29% of the original page size). The one hour difference (versions 2 to 3 above) is 2,885 bytes (a compression to 3% of the original page size). Clearly, Railgun compression outpeforms gzip enormously.

For pages that are frequently accessed the deltas are often so small that they fit inside a single TCP packet, and because the connection between the two parts of Railgun is kept active problems with TCP connection time and slow start are eliminated.

Railgun means that for premium CloudFlare customers the entire web becomes (almost completely) cacheable. Learn more about Railgun or upgrade to a CloudFlare Business or Enterprise account to enable it for you site.