SPDY Brings Responsive and Scalable Transport to Firefox 11

Firefox 11 contains the first Firefox implementation of the SPDY protocol. SPDY is a secure web transport protocol that encapsulates HTTP/1 while replacing its aging connection management strategies. This results in more responsive page loads today and enables better scalability with the real time web of tomorrow.

The most important goal of SPDY is to transport web content using fewer TCP connections. It does this by multiplexing large numbers of transactions onto one TLS connection. This has much better latency properties than native HTTP/1. When using SPDY a web request practically never has to wait in the browser due to connection limits being exhausted (e.g. the limit of 6 parallel HTTP/1 connections to the same host name). The request is simply multiplexed onto an existing connection.

Many web pages are full of small icons and script references. The speed of those transfers is limited by network delay instead of bandwidth. SPDY ramps up the parallelism which in turn removes the serialized delays experienced by HTTP/1 and the end result is faster page load time. By using fewer connections, SPDY also saves the time and CPU needed to establish those connections.

The page-load waterfall diagram below tells the story well. Note the large number of object requests that all hit the network at the same time. All of their individual load times are comprised exclusively of network delay and by executing them in parallel the total page load time is reduced to a single round trip.

Generally speaking, web pages on high latency connections with high numbers of embedded objects will see the biggest benefit from SPDY. That’s great because its where the web should be going. High latency mobile is a bigger part of the Internet every day, and as the Internet spreads to parts of the world where it isn’t yet common you can count on the fact that the growth will be mobile driven. Designs with large numbers of objects are also proving to be a very popular paradigm. Facebook, G+, Twitter and any avatar driven forum are clear examples of this. Rather than relying on optimization hacks such as sprites and data urls that are hard to develop and harder to maintain we can let the transport protocol do its job better.

Beyond better page load time, there is good reason to think this approach is good for the web’s foundation. The way HTTP/1 uses large numbers of small and parallel active connections creates a giant networking congestion problem. This inhibits the deployment of real time applications like WebRTC, VOIP, and some highly interactive games. SPDY’s small number of busier connections fit the congestion control model of the Internet much better and enables the transport of classic web content to cooperate better with these real time applications. Web browsers have only managed to keep the congestion problem in check with HTTP/1 through arbitrary limits on its parallelism. With SPDY we can have our parallel-cake and eat it in low latency conditions too. This property is what I find most promising about SPDY, and I’ve written about it extensively in the past.

There is a great transition path onto SPDY. It is a new protocol, but it uses the old https:// protocol scheme in URIs. No changes to markup are needed to use SPDY. Generally SPDY servers support both SPDYand HTTP/1 for use with browsers that are not SPDY capable. The protocol used is silently negotiated through a TLS extension called Next Protocol Negotiation. The great news here is that upgrading to SPDY is just a matter of an administrative server upgrade. No changes to content are needed and things like REST APIs continue to work unmodified. Indeed, a SPDY site is not visually different in any way from an HTTP/1 site.

Google did a lot of work to launch this technology and to evolve it in the open, but it isn’t a Google only project any more. Since the implementations in Chrome and various Google web services were introduced we have seen either code or commitments regarding SPDY from many other products and groups including Amazon’s tablet, node.js, an Apache module, curl, nginx, and even a couple CDNs along with Mozilla. In my opinion, that kind of reaction is because engineers have looked at this and decided that it is solves several serious problems with HTTP’s connection handling and that this is a technology well positioned for us all to cooperate on. There is also discussion and preliminary movement in all the right standardization forums such as the W3C TAG and the IETF. Open standardization of the protocol is a key condition of Mozilla’s interest in it, but it is not a precondition to using it. Gathering operational experience instead of just engineering on whiteboards, is a valuable part of how the best protocols are made. The details of SPDY can be iterated based on that experience and the standardization process. The protocol is well suited to that evolution at this stage.

SPDY needs to be explicitly enabled through about:config in Firefox 11. Go to that URL and search for network.http.spdy.enabled and set it to true. Future revisions hope to have it enabled by default.

View full post on Mozilla Hacks – the Web developer blog

11 thoughts on “SPDY Brings Responsive and Scalable Transport to Firefox 11

  1. Patrick McManus

    NPN won’t be a problem. It is part of the dev stream of both openssl and nss already. mod_spdy for apache builds and runs very well with openssl right from the tree. Same for node-spdy.

    biggest risk might be hardware firmware that requires upgrades. But they are undergoing widespread upgrades for BEAST related problems anyhow.. hopefully taking false-start, npn, sni, etc updates with them..

  2. Patrick McManus

    Firefox SPDY requires SSL 100% of the time.

    The best thing I’ve ever heard said about this is that SSL can be a logistical burden for server operators[*], but I’ve never met a browser user that wanted to be running an insecure protocol.

    [*] we need to improve the CA/PKI situation. I doubt you’ll find disagreement on that either.

  3. Patrick McManus

    Yes the code reviews went in as part of FF12 with any critical bits ported to FF11. Expect at least a trial run of default-on as part of FF 13 nightly.

  4. Techy Mike

    SSL isn’t required (but it is a recommended option)

    I use StartSSL myself for non-production use, but for people wanting alternatives…

    Self-signed certs… – never trusted in users browsers unless they manually add the cert

    http://www.cacert.org/ — not trusted in all browsers

    http://www.comodo.com/e-commerce/ssl-certificates/free-ssl-cert.php — free 90 day certs
    http://www.verisign.co.uk/ssl/free-30day-trial/index.html — 30 days free
    http://www.freessl.com/ — 30 days free
    http://www.ssl247.co.uk/ssl-certificates/brands/rapidssl/rapidssl-trial

    It should be fairly obvious that free SSL isn’t impossible… and seriously, if your site does require SSL (and for SPDY that isn’t 100% accurate) then there are plenty of cheap options out there.

  5. cuz84d

    Hey Patrick, there is a bug in the regular hetwork code I believe that kills the browser and maybe putting it in offiline mode or something weird.

    Occasionally we see the browser go from working fine one minute to just lock up and stop responding to network requests at work Firefox 4-9, and we end of having to clear cache and history and restart the browser before it works again. Any idea what could cause such a thing, its not reproduceable at all though. I wonder if the browser ended up in offline mode by ifself.. or the network messed with the disk cache.

    Anyway, I sure hope SPDy will take care of this.. I did turn it on, and I can say its pretty damn fast at pulling down pages.

  6. Mook

    Has the code been fully reviewed yet? The bug for the spdy changes originally contained reviews that only covered the bits where spdy was left off, not the spdy-specific code paths. Given that it’s been a while since those patches, and indeed even some time since the initial landing, it might have been all done somewhere else and it’s all good, of course – it’s just that the bug was a little complicated and unclear if all the code has been properly vetted.

  7. driax

    @Pikadude:

    Just use startssl.com. They provide free ssl certificates. Though you have to pay if you need subdomain or star-domain (*.example.com).

  8. nototoad

    anybody can afford an SSL cert, they’re free. the web shouldn’t be held back because some people don’t want to source out a cheap or free one.

  9. Pikadude No. 1

    I’m slightly disappointed that this is apparently only available to authors who can afford/use an SSL certificate.

Leave a Reply