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.

spacer

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 fits 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.

34 comments

Post a comment

  1. spacer Pikadude No. 1 wrote on February 3rd, 2012 at 7:13 pm:

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

    Reply

    1. spacer nototoad wrote on February 3rd, 2012 at 10:42 pm:

      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.

      Reply

  2. spacer Dan wrote on February 3rd, 2012 at 7:48 pm:

    The SSL and NPN requirements will almost certainly prevent widespread adoption.

    Reply

    1. spacer Patrick McManus wrote on February 4th, 2012 at 8:30 am:

      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..

      Reply

  3. spacer Adam wrote on February 3rd, 2012 at 9:48 pm:

    Pikadude – you know you can get free SSL Certs right? – www.startssl.com/

    Reply

    1. spacer Techy Mike wrote on February 4th, 2012 at 2:00 am:

      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

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

      www.comodo.com/e-commerce/ssl-certificates/free-ssl-cert.php — free 90 day certs
      www.verisign.co.uk/ssl/free-30day-trial/index.html — 30 days free
      www.freessl.com/ — 30 days free
      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.

      Reply

      1. spacer Patrick McManus wrote on February 4th, 2012 at 8:27 am:

        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.

        Reply

  4. spacer driax wrote on February 3rd, 2012 at 10:52 pm:

    @Pikadude:

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

    Reply

  5. spacer Mook wrote on February 4th, 2012 at 12:07 am:

    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.

    Reply

    1. spacer Patrick McManus wrote on February 4th, 2012 at 8:24 am:

      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.

      Reply

  6. spacer cuz84d wrote on February 4th, 2012 at 1:11 am:

    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.

    Reply

  7. spacer Jo Hermans wrote on February 4th, 2012 at 2:01 pm:

    Is there an add-on that does something similar to Chrome’s ? That would it easier to debug SPDY network connections.

    Reply

    1. spacer Jo Hermans wrote on February 5th, 2012 at 10:54 am:

      Sorry, I mentioned chrome://net-internals/#spdy in the above post, but it got removed because I used angular quotes.

      Reply

  8. spacer Dmitry Pashkevich wrote on February 5th, 2012 at 5:09 am:

    I bet implementing SPDY in the coming FF version was one of the Google-Mozilla renewed contract clauses :)

    Reply

    1. spacer louisremi wrote on February 5th, 2012 at 10:18 am:

      I bet you’re wrong: SPDY is good for the Web and its users, why would Mozilla need to be forced to adopt it?

      Reply

    2. spacer RyanVM wrote on February 5th, 2012 at 5:32 pm:

      Yeah, except for that whole part about starting on it in August of last year…

      Reply

  9. spacer Matt Wilcox wrote on February 6th, 2012 at 9:38 am:

    This is awesome news :D

    Has Mozilla considered that SPDY now makes it much more realistic to send useful headers to the server to indicate device capabilities? Due to the compression and multiplexing there is far less overhead in doing this than with HTTP, and it would be extremely useful:

    I agree that headers are still ‘expensive’. But are they expensive compared to a few hundred kilobytes of saved bandwidth because we were able to successfully negotiate content?

    At the moment we can’t do *reliable* sever adaption without *reliable* client feature-set reporting. Which we can’t get any way we try right now, and there are many approaches tried – JS, cookies, and UA sniffing. None are bullet-proof, and all are merely ways of attempting to *guess* what a browser header could explicitly tell us. Which is why headers are wanted.

    To shave off any ‘wastage’ I would love to see browsers behaving something like this: behave exactly as now, but listen out for a server response header that in turn requests the browser to append certain headers with all requests to the domain. I.e.,

    1) Client asks for spdy://website.com
    2) Server responds with content and adds a “request [bandwidth] & [device screen size] headers”
    3) Client then appends these headers to all future requests on the domain.
    4) Server can push any amended content from 2) over SPDY without another request (because SPDY can).

    This way there are no additional overheads in general browsing unless the server has requested them specifically. And with SPDY they’re all compressed anyway.

    At last, reliable feature detection the server can get hold of?

    Reply

  10. spacer Anunturi wrote on February 7th, 2012 at 11:38 pm:

    This is great news. I’m tired of using sprites and spreading images across multiple hosts just for a small speed improvement.
    Too bad this relies on a ssl cert. Anyway, this should be default in the future and companies should adopt startssl’s initiative to provide free limited ssl certificates.
    I’m guessing that there will be a bigger gap between the sites who can afford its own private IP address and those hosted together with hundreds of other sites.

    Still, the future looks good and the transition to IPv6 will be accelerated due to this new protocol.

    Reply

  11. spacer Major wrote on February 9th, 2012 at 2:57 am:

    IMO SPDY is a dangerous hype with lesser advantages over http1 than published.

    I think “Server push” may be a nice advertising feature for SPDY-inventor google, but a really dangerous hole because theroetically a bad server can push any bad content or unsolicited ads to the browser without using client-side scripts.

    As a second drawback, there is no CPU saving, because servers and clients need to decrypt AND decompress and client-side CPU usage may be a real problem in mobile devices.

    The third problem are SSL certificates. Small hosters won’t and in some case even can’t install SSL-certificates, mostly because hosters are afraid of the additional CPU usage for SSL-encryption in shared environments.

    My advice is to use SPDY:// instead of . The user can choose his benefits by choosing the protocol.

    Reply

    1. spacer Patrick McManus wrote on February 9th, 2012 at 6:40 am:

      @major – thanks for the comments.

      wrt server push – FF does not yet accept server push – we are waiting for the flow control mechanisms of spdy/3 (or better) to be defined before using it. Partially for the concerns you describe.

      re CPU – crypto is absolutely required. We won’t make that mistake again. And SPDY is much more CPU friendly than HTTP/1 over SSL because it terminates so many fewer connections (and the RSA operation of the connection termination is the major cost of SSL – not the bulk cipher on the stream).

      As for compression, its used in a very targetted way with very small windows (which matter for both RAM and CPU)- a lot of thought has gone into this. Your whole stream is not just passed through gzip. The value is extraordinary.

      wrt small hosters: we need to do a better job of running the PKI. But the emphasis should be on making sure users are running secure protocols as the first order of business. users first.

      Reply

  12. spacer Pikadude No. 1 wrote on February 9th, 2012 at 5:05 pm:

    @Everyone replying to me: You’re only solving half the problem; free SSL certs do you no good if your host doesn’t allow them yet. Although I suppose there’s the silver lining that it’s only a matter of time.

    Reply

  13. spacer Gautam Dewan wrote on February 13th, 2012 at 9:45 pm:

    Patrick: I have a question similar to Jo Hermans above.

    I was trying out Firefox 11 on my web server that implements spdy/2. Chrome and spdycat clients work great. Firefox 11 does not. Is there something in Firefox 11 or an add-on that can show active SPDY sessions, and the flow of frames to and from the web server ?

    To me it look like Firefox is not able to interpret the SYN_RESPONSE frame coming back from the webserver. The webdeveloper console in firefox lists the URL with a status of unknown.

    Reply

  14. spacer Patrick McManus wrote on February 14th, 2012 at 7:05 am:

    There is some info in https://groups.google.com/forum/#!topic/mozilla.dev.platform/5dtG0hKRg5U that may help you – a response header and a lot of HTTP Logging information.

    I’d be happy to work on your