Cloudflare will deprecate the Railgun product on January 31, 2024. At that time, existing Railgun deployments and connections will stop functioning. Customers have the next eight months to migrate to a supported Cloudflare alternative which will vary based on use case.

Cloudflare first launched Railgun more than ten years ago. Since then, we have released several products in different areas that better address the problems that Railgun set out to solve. However, we shied away from the work to formally deprecate Railgun.

That reluctance led to Railgun stagnating and customers suffered the consequences. We did not invest time in better support for Railgun. Feature requests never moved. Maintenance work needed to occur and that stole resources away from improving the Railgun replacements. We allowed customers to deploy a zombie product and, starting with this deprecation, we are excited to correct that by helping teams move to significantly better alternatives that are now available in Cloudflare’s network.

We know that this will require migration effort from Railgun customers over the next eight months. We want to make that as smooth as possible. Today’s announcement features recommendations on how to choose a replacement, how to get started, and guidance on where you can reach us for help.

Cloudflare’s reverse proxy secures and accelerates your applications by placing a Cloudflare data center in over 285+ cities between your infrastructure and your audience. Bad actors attempting to attack your applications hit our network first where products like our WAF and DDoS mitigation service stop them. Your visitors and users connect to our data centers where our cache can serve them content without the need to reach all the way back to your origin server.

For some customers, your infrastructure also runs on Cloudflare’s network in the form of Cloudflare Workers. Others maintain origin servers running on anything from a Raspberry Pi to a hyperscale public cloud. In those cases, Cloudflare needs to connect to that infrastructure to grab new content that our network can serve from our cache to your audience.

However, some content cannot be cached. Dynamically-generated or personalized pages can change for every visitor and every session. Cloudflare Railgun aimed to solve that by determining what was the minimum amount of content that changed and attempting to only send that difference in an efficient transfer - a form of delta compression. By reducing the amount of content that needed to be sent to Cloudflare’s network, we could accelerate page loads for end users.

Railgun accomplishes this goal by running a piece of software inside the customer’s environment, the Railgun listener, and a corresponding service running in Cloudflare’s network, the Railgun sender. The pair establish a permanent TCP connection. The listener keeps track of the most recent version of a page that was requested. When a request arrives for a known page, the listener sends an HTTP request to the origin server, determines what content changed, and then compresses and sends only the delta to the sender in Cloudflare’s network.

The last major release of Railgun took place eight years ago in 2015. However, products should not be deprecated just because active development stops. We believe that a company should retire a product only when:

• the maintenance impacts the ability to focus on solving new problems for customers and

• when improved alternatives exist for customers to adopt in replacement.

Hundreds of customers still use Railgun today and the service has continued to run over the last decade without too much involvement from our team. That relative stability deterred us from pushing customers to adopt newer technologies that solved the same problems. As a result, we kept Railgun in a sort of maintenance mode for the last few years.

Cloudflare’s network has evolved in the eight years since the last Railgun release. We deploy hardware and run services in more than 285 cities around the world, nearly tripling the number of cities since Railgun was last updated. The hardware itself also advanced, becoming more efficient and capable.

The software platform of Cloudflare’s network developed just as fast. Every data center in Cloudflare’s network can run every service that we provide to our customers. These services range from our traditional reverse proxy products to forward proxy services like Zero Trust to our compute and storage platform Cloudflare Workers. Supporting such a broad range of services requires a platform that can adapt to the requirements of the evolving needs of these products.

Maintaining Railgun, despite having better alternatives, creates a burden on our ability to continue investing in new solutions. Some of these tools that power Railgun are themselves approaching an end of life state. Others will likely present security risks that we are not comfortable accepting in the next few years.

We considered several options before deciding on deprecation. First, we could accept the consequences of inaction, leaving our network in a worse state and our Railgun customers in purgatory. Second, we could run Railgun on dedicated infrastructure and silo it from the rest of our network. However, that would violate our principle that every piece of hardware in Cloudflare runs every service.

Third, we could spin up a new engineering team and rebuild Railgun from scratch in a modern way. Doing so would take away from resources we could otherwise invest in newer technologies. We also believe that existing, newer products from Cloudflare solve the same problems that Railgun set out to address. Rebuilding Railgun would take away from our ability to keep shipping and would duplicate better features already released in other products. As a result, we have decided to deprecate Railgun.

Railgun addressed a number of problems for our customers at launch. Today, we have solutions available that solve the same range of challenges in significantly improved ways.

We do not have an exact like-for-like successor for Railgun. The solutions that solve the same set of problems have also evolved with our customers. Different use cases that customers deploy Railgun to address will map to different solutions available in Cloudflare today. We have broken out some of the most common reasons that customers used Railgun and where we recommend they consider migrating.

“I use Railgun to maintain a persistent, secure connection to Cloudflare’s network without the need for a static publicly available IP address.”Customers can deploy Cloudflare Tunnel to connect their infrastructure to Cloudflare’s network without the need to expose a public IP address. Cloudflare Tunnel software runs in your environment, similar to the Railgun listener, and creates an outbound-only connection to Cloudflare’s network. Cloudflare Tunnel is available at no cost.

“I use Railgun to front multiple services running in my infrastructure.”Cloudflare Tunnel can be deployed in this type of bastion mode to support multiple services running behind it in your infrastructure. You can use Tunnel to support services beyond just HTTP servers, and you can deploy replicas of the Cloudflare Tunnel connector for high availability.

“I use Railgun for performance improvements.”Cloudflare has invested significantly in performance upgrades in the eight years since the last release of Railgun. This list is not comprehensive, but highlights some areas where performance can be significantly improved by adopting newer services relative to using Railgun.

• Cloudflare Tunnel features Cloudflare’s Argo Smart Routing technology, a service that delivers both “middle mile” and last mile optimization, reducing round trip time by up to 40%. Web assets using Argo perform, on average, 30% faster overall.

• Cloudflare Network Interconnect (CNI) gives customers the ability to directly connect to our network, either virtually or physically, to improve the reliability and performance of the connection between Cloudflare’s network and your infrastructure. CNI customers have a dedicated on-ramp to Cloudflare for their origins.

“I use Railgun to reduce the amount of data that egresses from my infrastructure to Cloudflare.”Certain public cloud providers charge egregious egress fees for you to move your own data outside their environment. We believe that degrades an open Internet and locks in customers. We have spent the last several years investing in ways to reduce or eliminate these altogether.

• Members of the Bandwidth Alliance mutually agree to waive transfer fees. If your infrastructure runs in Oracle Cloud, Microsoft Azure, Google Cloud, Backblaze and more than a dozen other providers you pay zero cost to send data to Cloudflare.

• Cloudflare’s R2 storage product requires customers to pay zero egress fees as well. R2 provides global object storage with an S3-compatible API and easy migration to give customers the ability to build multi-cloud architectures.

From the time of this announcement, customers have eight months available to migrate away from Railgun. January 31, 2024, will be the last day that Railgun connections will be supported. Starting on February 1, 2024, existing Railgun connections will stop functioning.

Over the next few days we will prevent new Railgun deployments from being created. Zones with Railgun connections already established will continue to function during the migration window.

Contract customers can reach out to their Customer Success team to discuss additional questions or migration plans. Each of Cloudflare’s regions has a specialist available to help guide teams who need additional help during the migration.

Customers can also raise questions and provide commentary in this dedicated forum room. We will continue to staff that discussion and respond to questions as customers share them.

Railgun customers will also receive an email notice later today about the deprecation plan and timeline. We will continue sending email notices multiple times over the next eight months leading up to the deprecation.

We are grateful to the Railgun customers who first selected Cloudflare to accelerate the applications and websites that power their business. We are excited to share the latest Cloudflare features with them that will continue to make them faster as they reach their audience.

A key Cloudflare feature is caching, which allows content to be served closer to the end user from our global network of data centers. Doing so improves the user's shopping experience and contributes to increasing the proportion of people completing a purchase (conversion rate).

For example:

• Walmart found improving page load time by 1 second increased their conversion rate by 2%

• Research for Amazon showed every 0.1 second of delay costs 1% of sales

• The Barack Obama campaign website saw an 80% page load time boost resulted in a 14% increase in donations

Cloudflare operates over 110 data centers around the world. When a website implements Cloudflare, visitor requests for the site will proxy through the nearest Cloudflare data center instead of connecting directly to the webserver hosting the site (origin). This means Cloudflare can store content such as images, JavaScript, CSS and HTML on our servers, speeding up access to those resources for end-users.

Most ecommerce websites rely on a backend database containing product descriptions and metadata such as prices. Without caching, each visit to a product page might involve several database requests to pull all the required data, which can introduce added latency to page load time, particularly on a busy website. Serving the website's homepage and product pages from Cloudflare's cache not only eliminates these costly database calls, but also reduces the load on your origin infrastructure.

To make the most of Cloudflare and to help maximize the speed of your website, serve as much content as possible from the Cloudflare cache.

By default, Cloudflare caches static content based on a fixed list of file extensions which includes assets such as images, CSS files and PDFs.

The reason Cloudflare only caches static content out of the box (and does not cache HTML content by default) is to avoid the risk of inappropriate data being cached. For example, if the shopping cart page is cached, then the next visitor might receive the cached version and see a cart with the incorrect contents. Therefore, while enabling more caching will let you make the most of Cloudflare, it requires careful and considered implementation.

Additional caching on Cloudflare can be enabled in one of two ways - using Page Rules or by sending cache headers from your origin. These two methods are explained in more detail here. In this blog post we’ll use Page Rules, but keep in mind you can use headers from your origin too.

A typical HTML page on an ecommerce website will contain static content (such as the product description) and dynamic content such as:

• a header section which varies according to the visitor’s logged in state - e.g. if the user is logged in, it may offer the user a “Logged in as..." message

• a basket section which populates as the user shops on the site

The user might have one or more session cookies to maintain these dynamic elements.

There are few ways to make the most of Cloudflare's caching, while taking into account the dynamic nature of ecommerce websites.

Note: the Bypass Cache on Cookie feature is only available on the Cloudflare Business and Enterprise plans

Many visitors to a site will be brand new, first time visitors - in other words, they won’t be logged in to the site and won’t have any items in their basket.

Serving their request from the Cloudflare cache means they can quickly view the page they’re looking for (whether the homepage or a specific product page). As they're a brand new visitor, the entire page can be served from the Cloudflare cache.

With most ecommerce platforms, as soon as the user logs in to the site or adds an item to basket, a relevant cookie is sent to the browser.

Cloudflare can cache the pages, but will bypass the cache should Cloudflare receive either of the cookies from the browser.

This is achieved by introducing a Page Rule with a “Bypass Cache on Cookie” setting:

In the above example, the Page Rule will cause all requests to the site to serve from cache, unless the web browser has sent a cookie named “loggedin” or “iteminbasket”.

Obviously every ecommerce platform is different, so always think through your settings and ensure you use the correct cookie values to ensure that there is no risk of private data (e.g. someone’s shopping basket) being served from cache and shown to another visitor.

A better solution would be to serve the entirety of the page from cache, but populate the dynamic elements using JavaScript / AJAX.

This means Cloudflare will serve the bulk of the page content and only small requests will pass (via Cloudflare) direct to origin to populate dynamic elements such as the basket contents.

To configure this, use a Page Rule with Cache Level “Cache Everything” for the static content and another Page Rule with Cache Level “Bypass” for the dynamic (AJAX) requests.

In this example, any requests going to www.example.com/ajax/basket_contents.php and www.example.com/ajax/logged-in-state.php would match the first Page Rule, which has cache level “Bypass” - Cloudflare will proxy the request but the request won't touch the Cloudflare cache.

Other requests, e.g. to www.example.com/products/product_page would not match the first Page Rule but would instead match the second “Cache Everything” Page Rule - thus the product page is served from the Cloudflare cache. Within that product page, the dynamic elements (such as the basket contents and the logged in state) are dynamically populated using the AJAX requests.

You should also consider introducing additional appropriate Page Rules for special pages such as the checkout pages - for example, you may wish to create a Page Rule that bypasses the cache for all the checkout pages.

Remember: only one Page Rule will execute for any given request, and Page Rules are processed in the order they exist in the Cloudflare control panel. Read over our Page Rules tutorial to better understand how they work.

Note: the Railgun feature is only available on the Cloudflare Business and Enterprise plans

Cloudflare’s Railgun technology optimizes the connection between Cloudflare and the website origin, for accelerating dynamic HTML content - content that can't be served from the Cloudflare cache.

Railgun helps in two ways:

• Establishing a persistent connection between Cloudflare and the website origin (to speed up initial connection times)

• Compressing the data that passes from the origin to Cloudflare by only sending content that has changed

Before Railgun:

After Railgun:

Railgun can happily be used in conjunction with the previously discussed caching methods.

If you’ve implemented method 1 (the bypass cache on cookie method) then Railgun will accelerate the requests which pass directly to origin due to the presence of the relevant bypass cache cookies.

Method 2 (caching everything on Cloudflare except AJAX calls to populate dynamic sections) is already more efficient than method 1. Railgun can still be used to further accelerate the AJAX requests that pass from Cloudflare to origin.

Railgun is a little more advanced as it requires installation of a small software package on (or very close to) the origin webserver to handle the compression. You can read more about Railgun here and find the installation documentation here.

Ideally a well optimized ecommerce website will leverage our caching service as much as possible - serving images, CSS and JavaScript from Cloudflare's network, in addition to as much static HTML content as possible. Adding our Railgun service to accelerate those inevitable non-cachable requests to the origin webserver will help create a fantastic, speedy shopping experience for your customers.

M42 Smart Motorway in the West Midlands, UK; courtesy of Highways England.

The load time of your website not only affects your search engine rankings, but is also correlated to the conversion rate on your site:

• Walmart.com found that for every 1 second of page speed improvement, they experienced a 2% increase in conversion rate.

• Greg Linden's presentation Make Data Useful demonstrated through A/B Testing every 100ms in page load time delays led to a 1% loss of sales for Amazon.

• Kyle Rush from the 2011 Obama for America campaign site showed a 3 second page load speed improvement increased on-site donations by 14% (resulting in over $34 million in donations).

Cloudflare is determined to help website administrators boost the performance of their websites. From today, Cloudflare users on our Business plan will gain a previously Enterprise-only Page Rule option, “Bypass Cache on Cookie”. When used in conjunction with a “Cache Everything” Page Rule, this setting allows for websites to cache the HTML of anonymous page visits without affecting dynamic content.

By caching anonymous page views, Cloudflare is able to help ensure that your origin webserver doesn't waste time constantly regenerating pages which change rarely. This ultimately allows us to reduce load on your server and reduce load times when users reach your site.

Cloudflare automatically caches static resources such as JavaScript, CSS and Images. Additionally, it is possible on all plans to instruct Cloudflare to cache static HTML using a “Cache Everything” Page Rule.

With static HTML, it is easy to work out what should and should not be cached - the response is exactly the same from request-to-request. However, this gets more complicated when you put a login form and a shopping cart into the mix. Once the user logs-in or adds a product to their shopping cart, the HTML being rendered is then personalised to them.

As HTTP is a stateless protocol; in order for a web application to determine which users need dynamic content, cookies are used. When the “Bypass Cache on Cookie” rule is matched, Cloudflare will bypass the “Cache Everything” rule and fetch HTML from the origin. Where a cookie is not set, Cloudflare abide by the "Cache Everything" rule and will seek to cache the static HTML for a given request.

Our Bypass Cache on Cookie setting allows for wildcard (“.*”) operators and OR pipe operators (“|”). Additionally, you are able to customise the cache TTL on our servers using the “Edge Cache TTL” option in Page Rule settings.

When your anonymous page views change, you can purge the cache using our web interface, our API or our platform integrations.

We have a number of tutorials on our Knowledge Base on how you can set this up with a variety of platforms:

• Caching Anonymous Page Views with WordPress or WooCommerce

• Caching Anonymous Page Views with Magento 1 and Magento 2

• How do I cache static HTML?

Want to go further? This setting can be used in conjunction with the Railgun web optimizer, which can speed up the delivery of dynamic content that cannot be cached.

Above this, Cloudflare’s Enterprise users have the option of taking their caching to the next level by using our Custom Cache Key functionality alongside other Page Rule options such as “Cache by Device Type” or “Cache on Cookie”.

Recently, I looked at how the standard library's built-in HTTP client handles connections to remote servers in order to provide minimal roundtrip latency.

CC By 2.0 Image by Dean Hochman

A common pattern that aims to avoid connection setup costs (such as the TCP handshake and TLS setup) and confer control over the number of concurrently established connections is to pool them. net/http maintains a pool of connections to each remote host which supports Connection: keep-alive. The default size of the pool is two idle connections per remote host.

More interestingly, when you make a request with net/http, a race happens. Races in code are often an unwanted side effect, but in this case it's intentional. Two goroutines operate in parallel: one that tries to dial a connection to the remote host, and another which tries to retrieve an idle connection from the connection pool. The fastest goroutine wins.

To illustrate, let's look at the code executed when transport.RoundTrip(req) is called:

go func() {
    pc, err := t.dialConn(cm)
    dialc <- dialRes{pc, err}
}()

idleConnCh := t.getIdleConnCh(cm)

select {
case v := <-dialc:
    // Our dial finished.
    return v.pc, v.err
case pc := <-idleConnCh:
    // Another request finished first and its net.Conn
    // became available before our dial. Or somebody
    // else's dial that they didn't use.
    // But our dial is still going, so give it away
    // when it finishes:
    handlePendingDial()
    return pc, nil
case <-req.Cancel:  
    handlePendingDial()
    return nil, errors.New("net/http: request canceled while waiting for connection")
case <-cancelc:  
    handlePendingDial()
    return nil, errors.New("net/http: request canceled while waiting for connection")
}

First a connection is dialed, then we select over idleConnCh (down which idle connections are passed) or dialc, which gives us the result of the dial. Cancellation of the request is also possible if the caller decides RoundTrip has taken too long.

So if an idle connection is available, retrieving it from the pool should win against dialing a new one. A similar approach (alongside other optimizations) has been used in Chromium, where it's referred to as late binding.

This echoes a mechanism we use in Railgun, CloudFlare's dynamic content optimizer, to ensure that an incoming request is serviced as quickly as possible. Idle connections to the Railgun component running at an origin server are periodically pruned after a timeout or may be closed because of errors, so an established connection from CloudFlare's edge is not always available. In this case, a direct request is made without Railgun whilst, in parallel, a persistent connection is initiated for use by subsequent requests.

As long as you have confidence that your connection manager is capable of cleaning up bad connections and cancelled requests properly, connection pooling and late binding can be important in reducing roundtrip latency. sync.Pool in the standard library may be a useful starting point if you need to pool something other than HTTP connections.

If you found this exploration interesting, we're hiring engineers in London, San Francisco and Singapore.

Some months ago, we made a big bet on partnering with CloudFlare for performance improvements and website security for our Magento hosting customers. Customer experience is core to our business and relying on another company is a major deal. CloudFlare is now included in Default–On mode for select Simple Helix hosting plans and can be added to any existing plan. The results have been great and we wanted to share a couple successes with the rest of the CloudFlare community.

The first thing one notices after melding their site with the worldwide CloudFlare CDN network is just how fast a website becomes. In Simple Helix’s testing, we found that proper CloudFlare implementation can yield 100% speed increases, and an even faster 143% speed increase when paired with the Railgun™ web optimizer for dynamic content.

Adding CloudFlare will certainly improve performance, but it can also significantly improve security through the Web Application Firewall feature. The security benefits of having the CloudFlare service can be seen after just the first few days of adoption as outlined below:

Total number of threats mitigated by CloudFlare in a week

The results provided insight: "CloudFlare helped break down the problem in an elegant way that made threat assessments much easier for our customers to digest and make well-reasoned decisions based on the information presented" said Brian Rorex, systems administrator at Simple Helix. CloudFlare protects sites from some of the most common maladies that plague the modern Internet like overly-aggressive crawler bots, botnet attacks, and DDoS attacks.

Given our happiness with the performance of the CloudFlare service, we have chosen it to respond to some unique performance challenges of our customers with much success. One such Simple Helix client is a popular fashion accessory company that let us know that they were launching a high-traffic media campaign that would increase traffic significantly for several days. We responded by putting them on CloudFlare as their first step in bolstering the company's infrastructure in preparation for the big day. When the tweet finally hit the internet and the traffic ramped up, CloudFlare and the servers hardly broke a sweat, reducing the effective bandwidth usage at the origin by almost 70%.

Another Simple Helix customer with a popular apparel store routinely saw 300-500% spikes in traffic during regular sales events. Nesting their web servers behind the CloudFlare CDN evened out the traffic to an almost flat bandwidth usage graph and provided an 83.4% bandwidth savings at the origin server.

Simple Helix is one of the leading hosting providers serving the Magento e-commerce market with over 100,000 domains. Our customers vary from mom and pop shops to internationally recognized brands. A young, rapidly growing company, Simple Helix is constantly on the look-out for new technology that will improve the quality of service for their customers and set them apart from the pack.

We’re excited to make CloudFlare a standard part of setup at Simple Helix. This means that our customers get the performance and security benefits of CloudFlare without any additional work. If you currently run an eCommerce store that could take advantage of what we have to offer, please contact the Simple Helix team to find out which plan is right for you.

CC BY 2.0 image by Nathan E Photography

Over those three years Railgun has been deployed widely by our customers to accelerate the delivery of their web sites and lower their bandwidth costs.

Today we're announcing the availability of Railgun v5 with a number of significant improvements:

Railgun performs delta compression on every request/response requiring CPU (to perform the compression) and memory (to keep a cache of pages to delta against). Version 5 has undergone extensive optimization based on the performance of Railgun on large web sites and at hosting providers. Version 5 requires much less memory and lower CPU.

The original Railgun wire protocol that transfer requests and compressed responses between the customer server and CloudFlare's infrastructure has been completely replaced with a new, lighter-weight completely binary protocol that is faster and uses less bandwidth.

We noticed in real-world tests that although delta compression provided incredible compression and faster page load times that it was possible to squeeze out even greater compression by performing traditional non-delta compression in addition to the delta compression. This is now standard and all content is compressed yielding an extra 10-15% compression.

Large downloads are not delta compressed for performance reasons (the benefits of the delta compression are outweighed by the cost of compressing very large pages). To ensure that large pages are downloaded as quickly as possible, Railgun v5 provides an automatic streaming mode where the page is streamed from the origin server across the Internet to CloudFlare and on to the end web browser. This substantially reduces the time to download very large pages through Railgun.

Railgun's management of the connection between Railgun and the customer origin server has been improved to pool connections and make best use of HTTP keep-alives. This reduces the load on the origin server and improves performance as connections are efficiently reused resulting in lower latency.

CloudFlare has been moving all communication between servers to encrypted connections. Railgun has always used a TLS connection between CloudFlare and the customer server even if the requests being passed were HTTP and not HTTPS. With version 5 we've switched Railgun to use our new CA for greater security. The connection between CloudFlare and the customer's Railgun is secured with certificates in both directions that are verified against the CloudFlare CA.

CloudFlare Optimized Partners in particular can benefit from the lower resource usage of Railgun version 5. A2 Hosting, an Optimized Partner and Railgun Beta participant, reported increased compression rates using version 5. Also new for partners is the ability to assign subdomains to a Railgun. Upgrading to the latest version, or installing Railgun for the first time, only takes a few minutes (Railgun Quick Start Guide for Optimized Partners). Railgun is perfect for ecommerce sites as well as news sites and popular blogs.

Railgun is available as part of CloudFlare's Business and Enterprise plans or from an Optimized Partner. Installation instructions for Railgun are available on CloudFlare's resources and downloads page. We recommend installing from CloudFlare's package repository, which makes it easy to keep Railgun up-to-date. This release also sees Railgun available on Red Hat Enterprise Linux (RHEL) and CentOS 7. Railgun v5's configuration is completely compatible with version 4 and customers can simply replace the Railgun binary and restart to use version 5 and immediately see the benefits.

CC BY-SA 2.0 by Yuko Honda (cropped, resized)

CloudFlare uses Go extensively to build our service and we need to people to build and maintain those systems. We've written a complete DNS server in Go, our Railgun service is all Go and we're moving more and more systems to Go programs.

We've recently written about our open source Red October Go project for securing secrets, and open-sourced our CFSSL Go-based PKI package. Go is now making its way into our data pipeline and be used for processing huge amounts of data.

We even have a Go-specific section on our GitHub.

If you're interested in working in Go on a high-performance global network like CloudFlare, send us an email.

Not into Go? We're hiring for all sorts of other positions and technologies.

You bring the sunscreen, we’ll supply:

• Complimentary limousine transfers from Miami International Airport to Loews Miami Beach Hotel on Sunday, June 15. Reserve your spot today.

• CloudFlare t-shirts

• Live music during breakfast each morning to start your day off right

• Our signature Nerf Railguns (quantity is limited: be sure to visit us early at booth #407!)

As it happens, this will be my first HostingCon, I've just joined CloudFlare as Partner Account Manager. Stop by to say hi to me and the team and learn about our new features and products.

If you’re interested in becoming a partner, please drop by the CloudFlare Booth #407 to learn how CloudFlare can reduce your server load; improve the performance of your network; block spammers, botnets, and other web threats; and provide DDOS protection.

Here’s where the CloudFlare Team will be during the show:

• Limo transfers from Miami International Airport to Loews Miami Beach Hotel. Registration is open, reserve your spot now.

• 7:45am-8:45am: Breakfast, sponsored by CloudFlare - Level 2 of the convention center (there will be signs)

• 5:30pm-8:30pm: Welcome Reception

• 7:45am-8:45am: Breakfast, sponsored by CloudFlare - Level 2 of the convention center

• 12:30pm-6:30pm: Exhibit hall is open. CloudFlare is booth #407

• 4:00pm-6:30pm: Happy hour! Visit our booth while you sip on your preferred beverage

• 7:45am-8:45am: Breakfast, sponsored by CloudFlare - Level 2 of the convention center

• 12:30pm-4:00pm: Exhibit hall is open. CloudFlare is booth #407

We’ll see you in Miami!

I first wrote about CloudFlare's use of Go back in July 2012. At that time there was only one CloudFlare project, Railgun, written in Go, but others were starting to germinate around the company. Today we have many major projects in Go. So, we celebrate Go's 4th birthday with a short list of interesting things we've written in Go.

RRDNS is a DNS proxy that was written to help scale CloudFlare's DNS infrastructure. Our DNS was already very fast and we wanted to make it faster, more reliable and resilient to attack.

RRDNS provides response rate limiting to stop DNS attacks, caching to lower the load on the database, load balancing to detect downed upstreams, seamless binary upgrade (with no service interruption), CNAME flattening and more. It is built on a modular framework that allows the implementation of each behaviour to exist in separately maintained modules.

This modularity was trivial to enforce with interfaces, allowing each module to remain strictly self-contained but retain the flexibility of implementation (some use cgo, others have background workers). A goroutine is dedicated to each request to force isolation where panics are recovered and logged instead of crashing the server.

The guarantees needed to avoid leaving the server in a bad state when handling panics would be impossible without the defer mechanism Go provides. Other language features simplified the complexity of writing new modules; garbage collection allows us to avoid complex reference counting schemes and concentrate on the business logic. Managing the concurrent requests' access to shared data was also easy, either by wrapping this in a goroutine or using read-write locks.

Railgun is CloudFlare's compression technology that's used to speed up connections between CloudFlare's data centers and origin web servers (especially when there is high latency between them). It's 100% written in Go and performs on the fly compression of web pages (and other textual assets) against recent versions of those pages to send the absolute minimum data possible.

Railgun also helps cache previously uncacheable assets (such as dynamically generated web pages) by spotting the often small changes between web pages over time, or the small changes between different users. Railgun is now widely used by CloudFlare customers to create responsive web sites wherever the end user is in the world.

It is now widely used by CloudFlare customers and hosting partners and achieves impressive real world speedups, including faster TTFB and better page load time, and bandwidth savings which translate into additional savings for people using services like AWS.

Red October is a cryptographically secure implementation of the two-man rule control mechanism. It is a software-based encryption and decryption server. The server allows authorized individuals to encrypt a payload in such a way that no one individual can decrypt it. To decrypt the payload, at least two authorized individuals must be logged into the server. The decryption of the payload is cryptographically tied to the login credentials of the authorized individuals and is only kept in memory for the duration of the decryption.

We'll be using Red October to secure very sensitive material (such as private encryption keys) so that no single CloudFlare employee (or single attacker) can get access to them. In coming months we'll write more about the cryptographic underpinnings of keeping CloudFlare secure.

The SSL Bundler allows us to take a customer's own SSL certificate and compute the fastest, shortest chain of intermediate certificates that can be used to verify the connection. When someone uploads a custom SSL certificate, we use our directory of intermediate certificates to build all the possible chains from the uploaded cert to a trusted browser root. We then rank these chains based on a number of factors including:

1. The length of the certificate chain

2. The ubiquity of the root certificate in browsers and other clients

3. The security of each step in the chain (e.g., does their Extended Key Usage include Server Authentication)

4. The length of the validity period of all the steps in the chain

The result is a server bundle that is small, fast and strong while having ubiquitous browser and client support. We then present that chain of certificates when an SSL connection is made so that the browser can securely verify the SSL connection as quickly as possible.

We're also experimenting with Go-based software like CoreOS (we're working with their go-raft library) and Docker. We have internal tools for load testing written in Go for Kyoto Tycoon, HTTP servers, SPDY and memcached. And we've open-sourced our Go stream processing library, a Go wrapper for high-performance syslogging, our changes to Go bindings for Kyoto Cabinet, and a tool for 'curling' SPDY sites. And, of course, we've been contributing directly to Go itself.

All in all Go is one of the main languages in use at CloudFlare and from here it looks like it has a bright future.

Happy 4th Birthday Go!

(And, yes, we're hiring Go programmers in London and San Francisco)

The other day I wrote about our use of Lua to implement our new Web Application Firewall. The other language that's become very popular at CloudFlare is Go. In the past, I've written about how we use Go to write network services including Railgun.

One of the operational challenges of using a garbage-collected language like Go for long-running network services is memory management.

To understand Go's memory management it's necessary to dig a little into the Go run-time code. There are two separate processes that take care of identifying memory that is no longer used by the program (that's garbage collection) and returning memory to the operating system when it doesn't look like it will be used again (that's called scavenging in the Go code).

Here's a small program that creates a lot of garbage. Once a second it asks for a byte array of between 5,000,000 and 10,000,000 bytes. It keeps a pool of 20 of these buffers around and discards others. This program is designed to simulate something that happens quite often in programs: memory is allocated by different parts of the program over time, some of it is retained, most of it is no longer needed. In a networked Go program this can easily happen with goroutines that handle network connections or requests. It's common to have goroutines that allocate blocks of memory (such as slices to store received data) and then no longer need them. Over time there will be some number of blocks of memory in use by network connections that are being handled and accumulated garbage from connections that have come and gone.

package main

import ("fmt""math/rand""runtime""time" )

func makeBuffer() []byte {return make([]byte, rand.Intn(5000000)+5000000)}

func main() {pool := make([][]byte, 20)

var m runtime.MemStats  
makes := 0  
for {  
    b := makeBuffer()  
    makes += 1
    i := rand.Intn(len(pool))
    pool\[i\] = b

    time.Sleep(time.Second)

    bytes := 0

    for i := 0; i < len(pool); i++ {
        if pool\[i\] != nil {
            bytes += len(pool\[i\])
        }
    }

    runtime.ReadMemStats(&m)
    fmt.Printf("%d,%d,%d,%d,%d,%d\\n", m.HeapSys, bytes, m.HeapAlloc,
        m.HeapIdle, m.HeapReleased, makes)
}

}

The program uses the runtime.ReadMemStats function to get information about the size of the heap. It prints out four values: HeapSys (the number of bytes the program has asked the operating system for), HeapAlloc (the number of bytes currently allocated in the heap), HeapIdle (the number of bytes in the heap that are unused) and HeapReleased (the number of bytes returned to the operating system).

Garbage collection runs frequently in a Go program (see the GOGC environment variable to understand how to control the garbage collector's operation), so when running the size of the heap will change as memory is spotted as unused: this will causes HeapAlloc and HeapIdle to change over time. The scavenger will only release memory that has been unused for more than 5 minutes so HeapReleased does not change often.

Here's a chart of the program above running for ten minutes.

(On this and subsequent charts the left axis in in bytes and the right axis is a count used for Make Count)

The red line shows the number of bytes that are actually in byte buffers in the pool. Because it has a fixed size of 20 buffers it quickly plateaus at around 150,000,000 bytes. The top blue line shows the amount of memory request from the operating system; it plateaus at around 375,000,000 bytes. So the program is using about 2.5x the amount of memory it needs.

As the program is churning through memory the allocated size of the heap and the amount of idle memory jumps around as garbage collection occurs. The orange line just counts the number of times makeBuffer() has been called to create a new buffer.

This sort of over request of memory is common in garbage collected programs (see, for example, the paper Quantifying the Performance of Garbage Collection vs. Explicit Memory Management). As the program churns through memory the idle memory gets reused and rarely gets released to the operating system.

One way to solve this problem is to perform some memory management manually in the program. For example, using a channel it's possible to keep a separate pool of buffers that are no longer used and use that pool to retrieve a buffer (or make a new one if the channel is empty).

The program can then be rewritten as follows:

package main

import ( "fmt" "math/rand" "runtime" "time" )

func makeBuffer() []byte { return make([]byte, rand.Intn(5000000)+5000000) }

func main() { pool := make([][]byte, 20)

buffer := make(chan \[\]byte, 5)

var m runtime.MemStats
makes := 0
for {
    var b \[\]byte
    select {
    case b = <-buffer:
    default:
        makes += 1
        b = makeBuffer()
    }

    i := rand.Intn(len(pool))
    if pool\[i\] != nil {
        select {
        case buffer <- pool\[i\]:
            pool\[i\] = nil
        default:
        }
    }

    pool\[i\] = b

    time.Sleep(time.Second)

    bytes := 0
    for i := 0; i < len(pool); i++ {
        if pool\[i\] != nil {
            bytes += len(pool\[i\])
        }
    }

    runtime.ReadMemStats(&m)
    fmt.Printf("%d,%d,%d,%d,%d,%d\\n", m.HeapSys, bytes, m.HeapAlloc,
        m.HeapIdle, m.HeapReleased, makes)
}

}

And here's a graph of its operation for 10 minutes:

This tells a very different story from above. The memory actually in pool is very close to the memory requested from the operating system and the garbage collector has little to no work to do. The heap only has a very small amount of idle memory that eventually gets released to the operating system.

The key to the operation of this memory recycling mechanism is a buffered channel called buffer. In the code above it can store 5 []byte slices. When the program needs a buffer it first tries to read one from the channel using a select trick:

select { case b = <-buffer: default: b = makeBuffer() }

This will never block because if the channel called buffer has a slice in it then the first case works and the slice is placed in b. If the channel is empty (meaning a receive would block) the default case happens a new buffer is allocated.

Putting slices back in the channel uses a similar non-blocking trick:

select { case buffer <- pool[i]: pool[i] = nil default: }

If the buffer channel is full then a send to it would block. In that case the empty default clause occurs. This simple mechanism can be used to safely make a shared pool. It can even be shared across goroutines since channel communication is perfectly safe from multiple goroutines.

We actually use a similar technique to this in our Go programs. The actual recycler (in simplified form) is shown below. It works by having a goroutine that handles the creation of buffers and shares them across goroutines in our software. Two channels get (to get a new buffer) and give (to return a buffer to the pool) are used for all communication.

The recycler keeps a linked list of returned buffers and periodically throws away those that are too old and are unlikely to be reused (in the example code that's buffers that are older than one minute). That allows the program to cope with bursts of demand for buffers dynamically.

package main

import ( "container/list" "fmt" "math/rand" "runtime" "time" )

var makes int var frees int

func makeBuffer() []byte { makes += 1 return make([]byte, rand.Intn(5000000)+5000000) }

type queued struct { when time.Time slice []byte }

func makeRecycler() (get, give chan []byte) { get = make(chan []byte) give = make(chan []byte)

go func() {
    q := new(list.List)
    for {
        if q.Len() == 0 {
            q.PushFront(queued{when: time.Now(), slice: makeBuffer()})
        }

        e := q.Front()

        timeout := time.NewTimer(time.Minute)
        select {
        case b := <-give:
            timeout.Stop()
            q.PushFront(queued{when: time.Now(), slice: b})

       case get <- e.Value.(queued).slice:
           timeout.Stop()
           q.Remove(e)

       case <-timeout.C:
           e := q.Front()
           for e != nil {
               n := e.Next()
               if time.Since(e.Value.(queued).when) > time.Minute {
                   q.Remove(e)
                   e.Value = nil
               }
               e = n
           }
       }
   }

}()

return

}

func main() { pool := make([][]byte, 20)

get, give := makeRecycler()

var m runtime.MemStats
for {
    b := <-get
    i := rand.Intn(len(pool))
    if pool\[i\] != nil {
        give <- pool\[i\]
    }

    pool\[i\] = b

    time.Sleep(time.Second)

    bytes := 0
    for i := 0; i < len(pool); i++ {
        if pool\[i\] != nil {
            bytes += len(pool\[i\])
        }
    }

    runtime.ReadMemStats(&m)
    fmt.Printf("%d,%d,%d,%d,%d,%d,%d\\n", m.HeapSys, bytes, m.HeapAlloc
         m.HeapIdle, m.HeapReleased, makes, frees)
}

}

Running that program for ten minutes looks very similar to the second program above:

These techniques can be used to recycle memory that the programmer knows is likely to be reused without asking the garbage collector to do the work. They can significantly reduce the amount of memory a program needs. And they can be used for more than just byte slices. Any arbitrary Go type (user-defined or not) could be recycled in a similar manner.

The following is a guest blog post by Chris Holland, Director of Technology at Luxury Link. Luxury Link has been using CloudFlare’s Railgun acceleration technology since March 2013.

In March 2013, we started testing Railgun, and slowly rolled it out across our three web properties. We saw immediate results.

First, we saw instant reductions in time to retrieve uncached HTML documents, and as an ecommerce web property every millisecond counts. Using Railgun, the HTML for our home page (hosted in Los Angeles, California) loads 40 percent faster from the East Coast in the United States. Measurements we've run from London showed a 2x speedup, which is invaluable in positioning ourselves as a global player in the travel industry.

Second, we saw a reduction in outbound bandwidth from our origin web servers. Because Railgun does compression between the origin server and CloudFlare’s data centers, our bandwidth needs were dramatically reduced. This is especially important for our business because sudden peaks of traffic are commonplace.

We had tried other dynamic acceleration products offered by top-tier CDNs, but the results weren't as good and they cost a lot more than the CloudFlare Business plan.

Railgun, to put it mildly, was rather impressive.

We had the sneaking suspicion that Railgun's delta compression algorithm might have a noticeable impact on outbound bandwidth consumption out of our data center. In fact, it was more than noticeable!

In the chart below, the green line shows our outbound bandwidth consumption over a six month period. You can see that before we turned Railgun on in March, there are many spikes. Post-March, the spikes disappear.

It is important to note that with or without Railgun enabled, all of our HTML documents are delivered using gzip encoding. All our images, stylesheets and scripts are cached in CloudFlare data centers; as such they barely factor in the outbound bandwidth consumption. It's for the most part fair to state that our outbound bandwidth consumption is solely comprised of the retrieval of uncached HTML documents.

For us, this is why Railgun makes such a difference on top of the traditional CDN benefits. Railgun is accelerating and compressing the parts of the site that a normal CDN just can't handle. By accelerating the delivery of ‘uncacheable’ HTML pages, our visitors are getting better response times and we are seeing a big decrease in outbound bandwidth.

This chart shows the inbound (orange line) and outbound (green line) bandwidth on February 6, 2013, before we introduced Railgun. It shows a pretty typical story for us: dramatic peaks in traffic linked to specific email campaigns.

The data shows that our outbound bandwidth is between 5x and 10x our inbound. That's pretty typical of gzipped HTTP traffic serving mostly HTML: inbound traffic is made up of HTTP requests, most of which fit in a packet or two, while outbound traffic is made up of all the actual HTML documents in response to those requests.

Our peak traffic often comes from email campaigns sending users to some of our largest HTML documents, which is why we're more likely to come in at a 10:1 ratio. Off-peak outbound is still about 5x inbound traffic, and reflects a longer tail of smaller HTML documents from more organic browsing.

Next take a look at this chart from May 8, 2013, with CloudFlare Railgun running on our site:

Railgun shines when many users access a handful of similar URIs, which is the pattern of our peak traffic. Even though the documents being returned are different in subtle ways for each user, those unique subtleties are the only bits of information exiting our data center. Think "diffs." Railgun essentially flattens our peaks: going from a 10:1 ratio to a 1:1 ratio, our peak outbound traffic is 1/10th of what it used to be before Railgun.

Off-peak outbound traffic, which is the longer-tail organic browsing, is also down to a 3:1 ratio from a 5:1 ratio without Railgun.

After much hard work internationalizing our platforms, we were extremely thrilled to launch our site in the UK just before July 4th: http://www.luxurylink.co.uk. As we expand internationally, our audience will continue to grow geographically further from our data center located in Los Angeles, California, and Railgun will have an even greater impact by ensuring less data has to travel over increasing distances. Our UK site is also backed by Railgun.

While Railgun is likely to have a different impact for every application based on trafficked URIs and heterogeneity of documents, our observations would indicate that the impact for most web applications will fall somewhere between "noticeable" and "unbelievable."

Looking at these numbers, Railgun ought to be extremely attractive to cloud-hosted companies, such as people using services like Heroku, AWS or the Rackspace Cloud, as well as anyone paying for every single byte transferred in and out of their applications.

I would love to one day see Railgun's "edge agents" implemented as Chrome, Firefox, or Safari extensions. Right now, while very significant in terms of percentage, Railgun's acceleration is only marginally "felt" by end-users: full HTML documents are still sent to end-users from CloudFlare's edges. Picture a day when this "diff'ing" technology gets baked into the web browser, such that a web property becomes faster as you browse it because you're rarely ever retrieving a full HTML document for a given request, but rather a small HTML fragment which might fit in a single packet.

Dreaming up possibilities afforded by CloudFlare's platforms could be a full-time occupation. But before getting too far ahead of ourselves, Railgun as it stands today ought to be wildly transformative to the Internet and the many businesses that operate online. It certainly is to us.

The CloudFlare team will be at HostingCon 2013 in Austin next week. This is our third year at the show and we have a lot of things in store for partners.

Here's a sneak peek:

• Complimentary limousine transfers from Austin-Bergstrom International Airport to the Hilton Austin hotel on Sunday, June 16th. Reserve your spot today!

• New CloudFlare tshirts

• Live music to supercharge your day during breakfast each morning

• Charging stations at our booth (#523) to keep your devices supercharged

• Bigger and better Nerf Railguns. There is limited quantity, so be sure to visit us at booth #523 to get your Railgun

CloudFlare Railguns ready for HostingCon 2013

We are looking forward to connecting with our current partners and meeting new partners at the show. If you are already a CloudFlare Certified Partner, be sure to stop by and introduce yourself. If you are not a partner yet, stop by to learn more about how CloudFlare can reduce your server load, improve the performance of your network, block spammers, botnets and other web threats, and provide DDOS protection. More details about the CloudFlare Certified Partner program here.

Here's where the CloudFlare team will be all week:

Limo transfers from Austin-Bergstrom International Airport to the Hilton Austin Hotel.

Registration is still open, reserve your spot now!

• 7:45am-8:45am: CloudFlare sponsored breakfast located in the Level 4, Ballroom D Foyer - Live music by Alternator Jones

• 5:00pm onwards: Come find the CloudFlare team at the welcome reception!

• 7:45am-8:45am: CloudFlare sponsored breakfast located in the Level 4, Ballroom D Foyer - Live music by Jackie Venson

• 12:00pm-4:00pm: CloudFlare is in Exhibit Hall 4 at booth #523

• 4:00pm-6:30pm: Visit our booth during the exhibit hall happy hour for a beverage and to supercharge your mobile phone!

• 8:00am-10:00am: CloudFlare sponsored breakfast located in the Level 4, Ballroom D Foyer - Live music by Sean Evan

• 9:00am-9:45am: Our co-founder and CEO Matthew Prince will be speaking on the IPv6 panel discussion "Now is the Time for IPv6" in room #18D

• 9:00-9:45am: Maria Karaivanova and John Roberts from CloudFlare will be co-hosting a talk on partnerships, "Strategies for Successful Partnerships" in room #16

• 12:00-4:00pm: CloudFlare is in Exhibit Hall 4 at Booth #523

Connect with us on Twitter during the event to find out where we are and what's coming up next:#hostingcon, @hostingcon, @CloudFlare

See you in Austin!

This blog post is about using headers we include in responses delivered from Railgun in order to see how it is working. We've been running Railgun on CloudFlare.com for the last few months so I'll use it as an example.

When a request is handled by Railgun, CloudFlare inserts a header with diagnostic information to track how the protocol is doing. If you want to see these headers, you'll need to use a browser that supports examining header information. Google's Chrome Browser or Apple's Safari Browser allow you to access Developer Tools (in Google, select the View > Developer > Developer Tools menu; in Safari, select the Develop > Show Web Inspector menu). In Firefox, you can install Firebug to see response headers. Microsoft's Internet Explorer makes it a bit trickier to see the response headers, but you can use a tool like Fiddler in order to expose them.

At CloudFlare, we've also made a Chrome extension for our own debugging purposes that we call Claire. When installed, it adds a small "cloud" icon to the right corner of the URL bar. If you're visiting a site that uses CloudFlare, lights up orange. Small icons under the cloud indicate whether you're using SPDY, Railgun, or IPv6 for your connection. Clicking on the icon exposes more data including information about the Railgun connection.

While Claire makes seeing the Railgun information easy, I'm going to walk through the rest of this post assuming you don't have it installed. Instead, I'll use Chrome's Developer Tools for the examples.

If you open the Developer Tools panel and click on the Network tab you'll see an interface like the one in the picture below:

Clicking on the first item in the list, which represents the dynamic HTML content that makes up the page, and then clicking on the Headers tab will show you the headers your browser sent to CloudFlare's servers as well as, if you scroll down, the response headers that your browser received back. Below is a sample of the response headers when accessing www.cloudflare.com:

There are two headers that CloudFlare is inserting in the response:

cf-railgun: e95b1c46e0 0.02 0.037872 0030 9878
cf-ray: 478149ad1570291

The second of these headers is what we call a RayID. This is a unique serial number attached to every request through the CloudFlare network, start to finish, which helps us diagnose if there's a problem at some step in our chain. If you ever have an error on your site when accessing CloudFlare, providing the RayID to our support team can help us track down the cause very quickly. The header I'm going to focus on for this post is the cf-railgun header, which I'll break down below.

The CF-Railgun header has up to five codes separated by a space. In order, these codes and their corresponding values from the example above are:

• Railgun Request ID: e95b1c46e0

• Compression Ratio: 0.02

• Origin Processing Time: 0.037872

• Railgun Flags: 0030

• Version Number: 9878

Breaking these down, the Railgun Request ID corresponds to an internal process number that allows us to track what connection handled a request in order to diagnose potential problems. Generally, you shouldn't need this value unless you're reporting a problem with your Railgun installation.

The Compression Ratio is more interesting in gauging how Railgun is down. It represents the size of the response after Railgun's delta compression expressed as a percentage. In the example above, the HTML returned for www.cloudflare.com is 0.02% of the size of the original that would be returned assuming no origin compression. Another way of thinking about this is the amount of data saved, which can be calculated by subtracting the Compression Ratio value from 100. In this case, 99.98% of the data that would have been required to generate www.cloudflare.comdoesn't need to be transmitted because of the Railgun compression.

The Origin Processing Time represents the time, in seconds, that Railgun waits for the origin web server to generate the page. In this case, the origin server takes 0.03782 seconds from when the Railgun listener sends the request to the origin to when it responds. If this number is large, it means your web server or database may be hitting a bottleneck that is slowing down its time to render the full page.

The Railgun Flags represent how a request was processed. The simplified way of looking at the Railgun Flags is to see the 4-digit sequence as zzXz. Ignore the z's and focus on the number or letter in the X position. If it is 3,7, B or F then it means Railgun Compression is working correctly.

If there is an error of some sort, the Compression Ratio is likely to be listed as "normal" or "direct." This means that Railgun's compression was bypassed for one reason or another. The Railgun Flags help diagnose why. The Railgun Flags are a bitset and, in order to fully interpret them, you need to use the rg-diag utility which is included with the Railgun packages. Run the utility from the command line with the -decode option. For example, to decode the Railgun Code 0038, for example, you'd run:

rg-diag -decode=0038

Which returns in:RailgunFlag Existing origin connection reusedRailgun Flag rg-sender sent dictionaryRailgun Flag rg-listener found dictionary

This information can be useful in diagnosing potential problems with Railgun. The good news is that the Railgun protocol is designed to be resilient. If a connection fails for some reason, in most cases it will immediately roll over to a normal HTTP or HTTPS connection without the visitor seeing an error.

Finally, returning to the cf-railgun header, the final variable is the Version Number which indicates the version of the Railgun Listener software that is running on the origin server's network. The numbers aren't necessarily sequential, so having a lower number than another Railgun Listener doesn't necessarily mean your Listener is out of date.

The Claire Chrome Plugin simplifies the header, leaving out the Railgun Flags and Version Number. Instead, it returns the Railgun Request ID (useful to provide to our support team if there's an issue), the amount of data saved for the particular request (derived from 100 - the Compression Ratio), and the Origin Processing Time (in seconds). Generally, this is all you should need to see whether Railgun is functioning as intended on your site.

Stay tuned. We'll post more information on tips for getting the most out of Railgun, as well as some of the design and engineering considerations that went into designing the protocol, over the coming days.

Over the next few days we have a number of announcements regarding CloudFlare's Railgun technology. We wanted to begin, however, with what is in some ways the end: the ways in which you can take advantage of Railgun yourself. Today we're proud to announce two ways in which you can make your dynamic content faster than was ever possible before.

First, today CloudFlare is announcing version 3.3.3 of Railgun. This version has been battle tested on high-traffic sites including Imgur and 4chan. It's run billions of requests in a number of different environments through the new protocol and we're ready to push it out to the world. To make the process of installing Railgun easy, we've released RPMs for most the popular Linux and BSD variants including:

• Ubuntu 12.10

• Ubuntu 12.04

• Ubuntu 11.10

• Ubuntu 10.04

• FreeBSD 9

• FreeBSD 8

• CentOS 6

• CentOS 5

• Debian 6

You can download any of these RPMs via the CloudFlare Downloads page. In addition, we've released an Amazon Machine Instance (AMI) for Amazon Web Services that you can install if you want to have you own Railgun listener. The AMI will be available soon via the AWS AMI manager.

The largest platform we're missing is Windows Server and we are working on updates to the Go runtime in order to allow us to compile for that platform and meet our quality standards. For the Windows Server users out there, stay tuned. We haven't forgotten about you.

But that's not the really exciting part. We're extremely excited to announce that a majority of the world's leading hosting providers are now supporting CloudFlare's Railgun technology. These 30 hosting providers have already registered to be CloudFlare Optimized Hosts. That means you can enable Railgun, usually with a single click and without having to install any software or change any of your code. Within the next few days, all of the following hosts will be supporting CloudFlare's Railgun:

• 040hosting

• A2 Hosting

• Arvixe

• Bluehost

• ByetHost

• CoreCommerce

• DreamHost

• ELServer

• FastDomain

• GreenGeeks

• HostPapa

• HostMonster

• Just Host

• InterServer

• MapleTime

• (mt) Media Temple

• MDDHosting

• NameCheap

• PacificHost

• PRO ISP

• SiteGround

• Sliqua Enterprise Hosting

• Softcloud Hosting

• SparkRed

• VentraIP

• VEXXHOST

• WebHostingBuzz

• WebHostingPad

• x10Hosting

• Zuver

In most cases, if you're already hosted with one of these hosting providers, getting the benefits of Railgun is free for you. If you're using one of these hosts, look for an option in your control panel to enable Railgun. If you're not already using one of these hosts, but you want to use Railgun, you should either contact your hosting provider to become a CloudFlare Optimized Partner, or consider switching to one of the providers above.

Railgun is a revolutionary new protocol that makes dynamic web performance significantly faster and less bandwidth-intensive than was ever previously possible. Over the next few days, we'll be releasing more details about the protocol. In the meantime, we wanted to make sure you knew where you could go to get Railgun today if you're interested. Stay tuned for more.

To solve that problem CloudFlare came up with a delta compression technique that recognizes that even dynamically-generated or personalized pages change only a little over time or between users. Railgun uses that compression technique to greatly reduce the amount of data that is sent over the Internet to CloudFlare's data centers from backend web servers. The result is faster delivery of the critical HTML that the browser must receive before it can download the rest of the page.

Testing with Railgun showed that very large compression ratios were possible and they resulted in a large speedup in page delivery. But two questions remained: "what's the effect in the real world?" and "how much difference does that make to page load time?".

We're now able to give some answers to those questions. The first hosting partner to roll out Railgun is Montreal-based Vexxhost. They gave us a sample of 51 web sites that they've enabled Railgun on and allowed us to run performance tests to see what difference Railgun makes. We decided to measure three things: how much faster the HTML is delivered, what the compression ratio is and how much page load time changes.

To get useful numbers we decided to load pages multiple times (each page was loaded 20 times with and without Railgun for a total of 40 downloads) and median values were used. Testing was done by downloading the pages from a machine in London, UK. The median round trip time between the nearest CloudFlare data center (where Railgun was running) and the origin web servers was 78ms.

On the 51 sites supplied by Vexxhost we saw a median speedup on downloading the HTML of 1.43x. To put that another way that means that the median time to download the HTML of the web pages decreased to 70% of what it was without Railgun.

Of the 51 sites 11 saw a speedup up of greater than 2x (i.e. the time to download the HTML of the web page more than halved) and for 8 of the sites the speedup was greater than 3x (i.e. the time to download the HTML of the web page was cut to a third of the original).

The median compression ratio achieved by Railgun was 0.65% (i.e. the page was reduced to 0.65% of its size). Of the 51 sites, only 9 saw a compression ratio greater than 3% (i.e. most of the pages were reduced to just a tiny percentage of their original size).

It's this huge compression that enables Railgun to speedup HTML delivery dramatically.

Another measurement to look at is Time To First Byte (how long it takes for the first byte of a page to be delivered to the browser). This is measured as the time from starting the TCP connection to the server to the moment the first byte is received from the server. Railgun has an effect on TTFB as well. The median improvement in TTFB was to drop it to 90% of the non-Railgun-accelerated value.

But HTML delivery is one thing, what's the real end-user visible effect? i.e. how does this translate to a difference in page load time.

Railgun makes a difference to page load time because it accelerates the download of the initial HTML which has to occur before the rest of the page downloads. Downloading the HTML faster helps the entire page download more quickly. Here's an example of the effect of Railgun on CloudFlare's Plans page. This small test was done from the same machine in London as all the other tests. First here's the waterfall for that page without Railgun enabled.

The page load time was 1.83s. Now with Railgun enabled the page load time dropped to 1.15s because the time to download the initial HTML dropped.

Of course, that's just one test. Repeating the test 10 times with and without Railgun saw a median page load time of 1.59s with Railgun and 2.59s without (making the Railgun accelerated time 61% of the non-accelerated page load time). A similar test with CloudFlare's home page showed a median Railgun-accelerated page load time of 2.56s and without Railgun of 3.2s (i.e. Railgun makes the page load time drop to 83% of what it was).

To measure page load time on the 51 sites supplied by Vexxhost we set up PhantomJS (a headless browser that uses the WebKit for engine) on the same machine as used for the measurements above. A small script enabled us to generate HAR files of the download of entire web pages (including the JavaScript, CSS, HTML and images) and to extract the page load time (we use the 'onload' time).

These page load times include assets that are not accelerated by CloudFlare or by Railgun so they show realistic figures of how Railgun helps. Nevertheless, Railgun helps across the sites picked by Vexxhost with a median decrease in page load time to 89% of the original time. The best increase in median page load time was 56%. A small number of sites didn't see an improvement in page load time (they correspond to sites that didn't get a significant Railgun speedup because they typically only had a small amount of HTML).

A comparison of the same site downloaded via Railgun and not can be seen in these two images. The decrease in page load time is due to the decrease in time to get the initial HTML. Here's the page loading without Railgun:

And with Railgun the intial HTML load is accelerated resulting in a faster overall load time.

The difficulty with measuring page load time to see the Railgun-related improvement is that page load time is highly variable as different assets (especially from sites that are not accelerated by a CDN like CloudFlare) cause the page load time to vary enormously. To get a picture of the expected page load time improvement we can move on from measurement to estimation to check that measurements are similar the expected improvement.

One obvious question is to ask how much improvement Railgun can bring to a web site. To work that out you need to know two numbers: the page load time (call it p) and the time to download the initial HTML (call that h). Both values can be obtained from the Developer view in Safari or Chrome or from Firebug.

Railgun will be able to decrease time h. Using the figures above the median improvement would be 70% so you'd expect a page that takes p seconds to load to take roughly p - 0.3 * h with Railgun. In the CloudFlare example above p was 1.83s and h was 0.949s. The formula would give a Railgun page load time of 1.83 - 0.3 * 0.949 = 1.55s (the actual value 1.15s because Railgun did better than the median for that particular page).

In general, the larger the initial HTML the more Railgun can help. Very small pages won't require many round trips between the origin server and Railgun edge server, but larger pages will benefit from the delta compression. And Railgun helps when the web browser and origin server are far apart (for example, when a web site is accessed from around the world, Railgun will help eliminate the round trip time between a web surfer in one country and a web server in another).

To double check the measured performance above we ran a prediction for the sites that Vexxhost gave us. To predict the speedup generated by Railgun we first loaded each page 20 times using PhantomJS and extracted the median page load time (p) and the median time to download the initial HTML (h).

Then using the measured median speedup in the initial HTML load (see the first section above) we predicted that change in page load time by accelerating the initial HTML load and leaving all the other asset load times fixed.

The prediction showed that the median page would load in 93% of the non-Railgun-accelerated time. The measured times were 89%. As with the prediction for the speedup of a CloudFlare page, the measured times are better than the crude predictor, but both show the importance of accelerating the initial HTML load.

In real world tests Railgun gives a median decrease in the page load time to 89% of the non-accelerated time. That translates directly into an improved experience for the end user, and because Railgun runs everywhere in the CloudFlare network it means that page load times are improved for users wherever they are in the world.

Of course, none of this means that web page authors can be complacent about page load time. CloudFlare provides many tools to accelerate web page delivery and web page authors need to be mindful of slow assets and use tools like YSlow to make web page as fast as possible. They need to be particularly mindful of slow third-party assets (such as JavaScript libraries or Like and Share buttons loaded from other domains) as these directly affect page load time.

In fact, the greatest benefit from Railgun comes for sites that have already optimized page load time. Railgun will help drastically reduce the time taken for the already optimized page to reach our edge servers and be sent on to end users. In contrast, a page that has not been optimized may rely on tens of slow or third-party assets that must be downloaded for the page to be ready masking the effects of Railgun.

In a future post I'll look at Railgun performance when accelerating RESTful APIs. And I'll look at the effect of Railgun on subsequent page loads where static assets will be in local cache: in that case Railgun acceleration will be even more noticeable as the HTML download time will be a greater proportion of the total page load time.

So, Go has become an important part of CloudFlare Engineering.

And because of that we are actively hiring for people who know Go or want to learn it. We'll soon be open sourcing some of our Go programs and want to find more people to work on our Go code base.

We're currently using Go for PKI tools, our Railgun web optimizer, a new high-performance DNS server and a curl-like tool for SPDY. And we've hosted the GoSF meetup in the past.

So, if you're interested in writing Go code, contributing to Golang itself and having your code go into production against billions of page views per day, get in touch.

CloudFlare is going to be at HostingCon 2012 in Boston from Sunday, July 15th to Wednesday, July 18th. We are excited to see our current partners and meet potential new partners at the show! Our team is looking forward to an extremely busy conference and we have several fun events planned, including complimentary limousine service between Boston Logan International Airport and the Boston Sheraton Hotel, a daily CloudFlare hosted breakfast, an exhibit booth and of course, attending all of the parties.

If you are already one of our certified hosting provider partners, be sure to stop by and introduce yourself. We will have CloudFlare t-shirts and some mystery goodies to celebrate the launch of Railgun. If you are not a partner yet, stop by to learn more about how CloudFlare can save you server and bandwidth resources, provide DDOS protection, IPv6 compatibility and much more.

Our schedule for the week is as follows:

Limo transfers from Boston Logan International Airport to the Boston Sheraton Hotel.

Registration is now closed for the limos, however, if you send an email to limos@cloudflare.com with your flight number, airline and time of arrival, we will try to accommodate you.

8am-10am: CloudFlare sponsored breakfast in Room #31211am-12pm: Our co-founder and CEO Matthew Prince speaks on Railgun in the 3rd level meeting rooms5pm onwards: Come and find the CloudFlare team at the welcome reception!

8am-10am: CloudFlare sponsored breakfast in Room #312**11:30am onwards:**CloudFlare is in the Exhibit Hall at Booth #809.1pm-6pm: Conversations with CloudFlare - We will be conducting live video interviews with thought leaders within the hosting industry, including founders and executives.3:30pm: Our co-founder and CEO Matthew Prince will be speaking on the DDoS panel discussion _"Technology Strategies and Practices for Defending Against DDoS Attacks"_in the 3rd level meeting rooms

8am-10am: CloudFlare sponsored breakfast in Room #31211:30am onwards: CloudFlare is in the Exhibit Hall at Booth #809.

Connect with us on Twitter during the event to find out where we are and what's coming up next:

#hostingcon, @hostingcon, @CloudFlare

See you next week in Boston!

Image source: stanleylieber.com; created by Renée French

We chose to use Go for Railgun because Railgun is inherently highly concurrent. A single instance of the Railgun client should be able to handle large numbers of requests from the CloudFlare data center for content and then multiplex them across an Internet connection to be handled. Go's concurrency makes writing software that must scale up and down very easy.

Railgun makes extensive use of goroutines and channels. Goroutines handle both the multiplexed Internet connections (of which there could be many between a single CloudFlare data center and our clients) and the connections needed to get content from origin web servers and provide the content back to the nginx server that sends it on to the web browser.

Probably the nicest thing about goroutines and channels is that they make it easy to create 'fire and forget until needed' systems. You create a channel, create a goroutine that communicates on that channel and then read from the channel when needed (perhaps using a select statement).

(Aside: for those who studied computer science, Go owes a lot to Hoare's CSP and Dijkstra's Guarded Commands.

A small example of a goroutine inside Railgun is this unique ID generator. It generates a sequence of IDs that are used to identify streams (a stream contains a single HTTP request) being sent between the CloudFlare data center and a client site.

It works by adding data to a SHA1 hash and each time a read is made on the channel id a new string ID is created by hashing the data. The whole thing is running as an independent goroutine that only does work when needed. (You can play with this code live here).

Another powerful aspect of Go is the way in which it handles object orientation. Go has a notion of an interface which is used to identify a capability of an object and where it can be used. One common interface is io.Writer. To be an io.Writer an object has to implement the Write function which has the signature Write(p []byte) (n int, err error). Any object that implements that can be used wherever an io.Writer is needed.

In Railgun there's a simple object called a Counter that is an io.Writer. It turns an ordinary io.Writer into one that writes, but also counts how much it's written. When its Write is called it keeps track of the number of bytes and calls the underlying io.Writer. It looks like this:

As an example of its use, here's how the unique ID generator above can be altered to count the number of bytes of data that have been written to the SHA1 hash. Since h implements io.Writer it can be passed to counter.New and it can be used to write data to the hash and keep a count. Reading from the count channel would retrieve how many bytes had been written. (See the live version for an example).

Part of the reason Railgun is so small is that Go's library is extensive and easy to work with. Go has libraries for HTTP, raw network connections, URL manipulation, TLS, many different types of serialization systems, cryptographic hashing, compression, and the more mundane string manipulation, date/time, and logging.

Another reason Go has been helpful is that is generates a single executable that can be distributed to our clients. There's no complex dependency chain or layout of shared libraries to worry about.

On HTTP, caching is done at the file level. A browser will cache the JPEG, CSS, and Javascript files on a page. However, the HTML of most pages is dynamically generated. As a result, the pages cannot be cached. This is unfortunate because the HTML of even highly dynamic pages rarely changes more than 10%. The 90% of the HTML that is the same from one request to the next is transmitted needlessly.

On the web, compression equals performance. If you can compress a response by 50% you will, roughly, double network performance. Given that 90%+ of HTML doesn't need to be transmitted over the network, if you could only transmit the actually dynamic parts of the content then you'd get a massive performance increase.

Recognizing this opportunity, traditional content delivery network (CDN) vendors created the Edge Side Include (ESI) protocol. The protocol was submitted as an official standard to the World Wide Web Consortium (W3C) but it was never accepted. A handful of other old school CDNs today support ESI, although it's adoption has been slow.

Here's how ESI works: when you create a web page you determine what parts are static and dynamic. You implement the static portions as a file that you upload to your CDN. Within that file you include tags that reference the dynamic portions of the content, with URL of where to fetch the dynamic portions from. The CDN fetches each of these dynamic resources and combines them with the static portion in order to render the HTML of the page before it sent across the network back to the browser.

If that sounds easy to implement then you likely haven't done much web development. To get a sense of the complexity, check out this 106 page ESI developer's guide. While ESI can theoretically deliver significant performance benefits, the pain of actually developing for it is significant. And, once you've developed for it, there's significant process lock-in: good luck ever leaving. We think you shouldn't have to learn a new programming language or change a single line of your code just to make your site fast.

And if you're spending your time bending your HTML so that a CDN can serve it up better then you're not spending it on developing your actual web site.

Yesterday, we posted about Railgun and how it lets you cache what was previously uncacheable content. One way of thinking about Railgun is that it is like automatic ESI support without the work. Rather than you having to tag your own content to mark what is static and what is dynamic, Railgun automatically determines the static portions of HTML and caches that at the edge. Dynamic portions of HTML are always fetched from the origin without you needing to change a single line of code.

Moreover, the caching logic is responsive to what is actually happening on the page. If different elements on the page change at different rates then Railgun's cache will deliver them optimally, never wasting a byte that doesn't otherwise need to be transmitted. And, since you don't need to change how you write code in order to support Railgun, there's no process lock-in if you ever decide to turn the service off. While youwon't get the benefits of Railgun without CloudFlare, you won't need to completely rewrite your code. In fact, you won't need to change a thing.

We talk to a lot of web publishers and the constant refrain we hear is that the performance and security tools that are available to them are too expensive and too complicated. We've had nearly half a million websites sign up for CloudFlare largely because we focused on these two issues. Railgun takes ESI, another technology that was previously reserved for only those sites with huge budgets and dedicated CDN management teams, and makes it available in a way that is affordable and easy to implement.

Because Railgun requires software to be installed on the origin server, we have limited its availability to our Business and Enterprise customers. However, our plan is to roll it out to CloudFlare's Free- and Pro-level customers if they are hosted on a CloudFlare Optimized Hosting Partner. If you're interested in Railgun, you can upgrade to CloudFlare Business or Enterprise. Alternatively, ping your hosting provider to know they should become a CloudFlare Optimized Host. It's free for hosts and, if they tell us you're the person who convinced them to sign up, we'll send you a T-shirt and make sure you're one of the first of the host's customers to get access to 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: Dave Fayram

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, reddit.com 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.

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.

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.