There is a revolution quietly happening on the web and if you blink you might miss it. The revolution is in the speed and latency with which some browsers can load some web pages, and what used to take 100’s of ms is now often reduced to 10’s.  The revolution is Google’s  SPDY protocol which I predict will soon replace HTTP as the primary protocol of the web, and  Jetty-SPDY is joining this revolution.

SPDY is a fundamental rethink of how HTTP is transported over the internet, based on careful analysis of the interaction between TCP/IP, Browsers and web page design .  It does not entirely replace HTTP (it still uses HTTP GET’s and POST’s), but makes HTTP semantics available over a much more efficient wire protocol. It also opens up the possibility of new semantics that can be used on the web (eg server push/hint).  Improved latency, throughput and efficiency will improve user experience and facilitate better and cheaper services in environments like the mobile web.

When is the revolution?

So when is SPDY going to be available?  It already is!!! The SPDY protocol is deployed in the current Chrome browsers and on the Amazon Kindle, and it is optionally supported by firefox 11.  Thus it is already on 25% of clients and will soon be over 50%. On the server side, Google supports SPDY on all their primary services and Twitter switched on SPDY support this month.  As the webs most popular browsers and servers are talking SPDY, this is a significant shift in the way data is moved on the web.   Since Jetty 7.6.2/8.1.2, SPDY is supported in  Jetty and you can start using it without any changes to your web application!

Is it a revolution or a coup?

By deploying SPDY on it’s popular browser and web services, Google has used it’s market share to make a fundamental shift in the web (but not as we know it)!  and there are some rumblings that this may be an abuse of Google’s market power.  I’ve not been shy in the past of pointing out google’s failings to engage with the community in good faith, but in this case I think they have done an excellent job.  The SPDY protocol has been an open project for over two years and they have published specs and actively solicited feedback and participation.  More over, they are intending to take the protocol to the IETF for standardisation and have already submitted a draft to the httpbis working group.   Openly developing the protocol to the point of wide deployment is a good fit with the IETF’s approach of “rough consensus and working code“.

Note also that Google are not tying any functionality to SPDY, so it is not as if they are saying that we must use their new protocol or else we can’t access their services.  We are free to disable or block SPDY on our own networks and the browsers will happily fallback to normal HTTP.  Currently SPDY is a totally transparent upgrade to the user.

Is there a problem?

So why would anybody be upset about Google making the web run faster?  One of the most significant changes in the SPDY protocol, is that all traffic is encrypted with TLS. For most users, this can be considered a significant security enhancement, as they will no longer need to consider if a page/form is secure enough for the transaction they are conducting.

However, if you are the administrator of a firewall that is enforcing some kind of content filtering policy, then having all traffic be opaque to your filters will make it impossible to check content (which may be great if you are a dissident in a rogue state, but not so great if you are responsible for a primary school network).  Similarly, caching proxies will no longer be able to cache shareable content as it will also be opaque to them, which may reduce some of the latency/throughput benefits of SPDY.

Mike Belshe, who has lead the development of SPDY, points out that SPDY does not prevent proxies, it just prevents implicit (aka transparent) proxies.  Since SPDY traffic is encrypted, the browser and any intermediaries must negotiate a session to pass TLS traffic, so the browser will need to give it’s consent before a proxy can see or modify any content.  This is probably workable for the primary school use-case, but no so much for the rouge state.

Policy or Necessity?

There is nothing intrinsic about the SPDY protocol that requires TLS, and there are versions of it that operate in the clear.  I believe it was a policy rather than a technical decision to required TLS only. There are some technical justification by the argument that it reduces round trips needed to negotiate a SPDY and/or HTTP connection,  but I don’t see that encryption is the only answer to those problems.  Thus I suspect that there is also a little bit of an agenda in the decision and it will probably be the most contentious aspect of SPDY going forward.  It will be interesting to see if the TLS-only policy survives the IETF process, but then I might be hard to argue for a policy change that benefits rogue states and less personal privacy.

Other than rouge states, another victim of the TLS-only policy is eas of debugging, as highlighted by Mike’s blog, where he is having trouble working out how the kindle uses SPDY because all the traffic is encrypted.  As a developer/debugger of a HTTP server, I cannot over stress how important it is to be able to see a TCP dump of a problematic session.  This argument is one of the reasons why the IETF has historically favoured clear text protocols.  It remains to be seen if this argument will continue to prevail or if we will have to rely on better tools and browser/servers coughing up TLS sessions keys in order to debug?

In Summary

Google and the other contributors to the SPDY project have done great work to develop a protocol that promises to take the web a significant step forward and to open up the prospects for many new semantics and developments.  While they have done this some what unilaterally, it has been done openly and with out any evidence of any intent other than to improve user experience/privacy and to reduce server costs.

SPDY is a great development for the web and the Jetty team is please to be a part of it.


Dominique De Vito · 19/03/2012 at 14:53

Is there any chance to have some features of SPDY to be backported into a new version of HTTP (say, HTTP 1.2) in order to get most of “speedy” SPDY features (but without TLS) into HTTP, that is, in order not to have to do a more radical move ?
Is SPDY making mandatory the use of “spdy://” addresses ?

    gregw · 20/03/2012 at 23:24

    You don’t need to say spdy:// as SPDY is still using the http semantics and thus is a valid transport for http URLs.
    I don’t think there will ever be a HTTP/1.2
    I think SPDY will form part of HTTP/2.0, but I do not know if that will require TLS or not. I think the odds are that there will be a push for a clear version of the protocol.

      Vieux · 07/04/2012 at 20:21

      The problem of csoure, is that they bothered to submit it to the IETF in the first place.First, to point out, the IETF has no power what-so-ever. They are an internet standards body because that’s what they say they are. Additionally they have enough people as members who actually know what they are talking about that that usually the standards they come up with are pretty decent. From a development perspective, it’s helpful since you can point and say I’m basing my work on RFC blah blah blah and you can usually be assured that the RFC has been well thought out. But they are a ton of protocols, processes, standards so to speak that are actively used out in the wild that has no RFC correlation. That never will, because no one can be bothered to go through the pain of submission. Because by submitting a proposal, you are essentially requesting a work group to review it.

Mars Saxman · 20/03/2012 at 17:12

Funny as the substitution is, I think you actually meant “rogue state”, not “rouge”.

    gregw · 20/03/2012 at 23:21


      Edaa · 07/04/2012 at 22:07

      Neither the IETF nor the WHATWG should have paimrry responsibility , it should be a joint effort. That’s what cooperation is.It’s worth noting also that the Web Socket protocol really wasn’t primarily designed by browser vendors. The original TCPConnection design was mostly my idea, but we threw most of that out and replaced it with a design from Michael Carter of Kaazing, a server-side developer, with input from Google (developers of the third largest Web server by active domains according to NetCraft), Squid, and many other server-side developers, including yourself.The entire protocol is in fact designed to put amateur Web developers (the most common Web developers and those with the fewest resources) first.

Minhaj · 25/04/2012 at 07:43

Do wordpress supports jetty?

Jetty gets ‘SPDY’ | Ameya Karve's Weblog · 20/03/2012 at 12:47

[…] the 7.6.2 release of Jetty, the SPDY™ protocol is now supported in the eponymous server. Previously a feature developed for […]

Jetty gets Speedy « async I/O News · 24/03/2012 at 11:02

[…] the 7.6.2 release of Jetty, the SPDY™ protocol is now supported in the eponymous server. Previously a feature developed […]

Comments are closed.