Jetty gets Speedy

With the 7.6.2 release of Jetty, the SPDY™ protocol is now supported in the eponymous server. Previously a feature developed for 8.2, it has now been back-ported to 7.6.2 as well as 8.1.2, and future releases of both that and the Hightide application server.

SPDY™ is an evolution of the transport layer for HTTP connections, available by default in Google Chrome and with a config option in Firefox 11. Although not a standard yet, it has been submitted to the IETF as a draft for the httpbis working group. Many of the Google services are available via SPDY, and other public sites (such as Webtide and Twitter) are providing support for the protocol.

SPDY™ works over TLS with an upgrade via the Next Protocol Negotiation proposed enhancement to the TLS specification. As a result, SPDY™ is implicitly a secured protocol; and further, HTTP proxies that currently allow traffic over port 443 that don't perform man-in-the-middle inspection will transparently support the use of the protocol. To understand what benefits SPDY™ will bring, InfoQ caught up with Greg Wilkins and Simone Bordet of the Jetty project to ask them, starting with where the speed advantages of SPDY come from:

Greg Wikins: There are several aspects of SPDY that will give it improved performance. Firstly as it uses a multiplexed connection, the latencies associated with creating new connections (sometimes as many as 6 per browser) will be avoided. Furthermore, by compressing the HTTP headers, it saves many hundreds of bytes on every request/response and as many pages take 10,20 or more requests to render then this represents a significant reduction in data overhead. Furthermore, by reducing the number of connections needed, this reduces the resources needed per client on the server, freeing more memory and CPU to do useful work.

Note that it is not all positive. SPDY will require the server to use TLS and compression, so there is CPU/memory to be used for this. However this is the kind of thing that can be easily offloaded to dedicated SPDY intermediaries if that extra CPU becomes an issue.

Simone Bordet: Note that multiplexing also brings additional advantages with respect to resource loading. A typical web page has 10-30 secondary resources that are contained in the page and that needs to be fetched from the server. Whereas now a browser can only issue 6 concurrent requests to the same server, with SPDY this limit is removed and the browser is free to open as many multiplexed "streams" as it needs, speeding up page loading considerably, and removing the need for HTTP pipelining. In addition, multiplexed "streams" can be prioritized, favoring more important resources such as CSS over less important resources like favicons. This in turn improves the utilization of the TCP connection, resulting in better TCP performance too.

The ability of issuing multiplexed "streams" without the 6 connection limit makes real-time web application (those based on Comet techniques) less tied to implementation details. Whereas now a Comet web application has to make sure to not exhaust the 4-6 connections that the browser allocates, with SPDY this limit does not exist.

InfoQ: Do you have any benchmarks on the performance difference between SPDY and HTTP?

Greg Wilkins: Not yet for Jetty. Google have seen latency improvements of > 60% for page loads, but they have not disclosed how their CPU/memory usage changed.

For jetty, our initial implementation does have to deal with a software architecture that was not designed for multiplexed HTTP, so we expect some inefficiencies. However, we are already working on jetty-9, that is specifically rearchitected for SPDY style connections. We hope to have some performance numbers soon and that they will continue to improve a we work towards jetty-9.

InfoQ: How does using SPDY affect caching HTTP proxies? Are there plans for a caching SPDY server instead?

Greg Wilkins: There will be a huge impact! Existing HTTP proxies will not be able to see into the SPDY streams, as they are encrypted. However SPDY does include very good support for caching, as it has mechanisms for pushing and hinted content in anticipation of resources that the client is likely to need. But any proxy cache would have to understand SPDY and be part of the SSL session. Thus some TLS extensions are probably going to be needed to allows active intermediaries in a SPDY connection.

InfoQ: Are there any code or configuration changes necessary to support SPDY in Jetty for existing web applications? Is there special configuration required to enable SPDY on the server, or is it a default setting?

Greg Wilkins: SPDY carries HTTP requests, so the applications do not need to change and the request/response semantics remains unchanged. Eventually there may be call to program applications directly to the SPDY layer, but for now it can be considered a transparent change for the application.

Simone Bordet: No, existing Java web applications can be deployed into Jetty exactly like before, and will benefit of most SPDY features – such as header compression and stream multiplexing – without any change. Only the server configuration needs to be updated, and the changes are minimal: just replacing the SSL connector with the SPDY connector ( org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector).

InfoQ: How do clients upgrade their HTTP connection to SPDY? Is this done transparently in Jetty's existing Http client classes?

Greg Wilkins: A SPDY connection is established by opening an TLS connection to port 443 using the Next Prototocol (NPN) extensions. If the server understands the NPN extension, then it will see that a SPDY connection is being offered and it can accept it. Otherwise the connection falls back to a normal https connection.

The NPN extension is not yet a standard and is not yet supported by JVMs. Simone has done some really clever work to extend the open JDK classes to support NPN now. Hopefully this will soon become a standard and will eventually be supported in all JVMs.

Simone Bordet: We have not integrated SPDY into Jetty's HttpClient yet, but we do offer a pure SPDY client that can be used to perform SPDY calls to SPDY-enabled servers (and therefore the HTTP layering has to be done manually by the client, for now).

Another interesting thing of SPDY is that it can push resources to clients before they request it. So, for example, when downloading a static HTML page, the server may be aware that the page contains a CSS resource, a JS script, and various images. The server may start downloading the initial lines of the page, then push the CSS, continue to download one more line, push the JS script, download more lines, push the images, and so on. This will save a lot of roundtrips and result in big savings in page rendering.

There is an ongoing discussion about how the server can be aware of these additional resources to push. Solutions range from additional metadata files (e.g. an index.html.spdy file containing the resources to push for index.html), to runtime profiling of requests by the server, filling a cache-per-resource with the secondary resources that are always requested after the primary resource, etc. Whether servers implement or not these features is up to server implementations, but the point is that SPDY enables a range of server side optimizations that are impossible with plain HTTP.

A last note is that in browsers, SPDY is fully integrated in every HTTP aspect of the browser, so not only when requesting pages from the address bar, but also via XMLHttpRequest.

InfoQ: Can clients and servers use SPDY for additional requests, rather than just HTTP, to serve push information for example?

Greg Wilkins: Yes. Well not currently from the browser, but in the server it is possible to access SPDY directly. It remains to be seen if the browser will directly expose SPDY semantics or just continue to hide it below application layers like HTTP and WebSockets.

InfoQ: To be ubiquitous, SPDY will need to be an IETF standard, instead of a Google project. Is there an RFC which explains the protocol in its current stage? If not, do you know when it is likely to happen? Is it a concern that Google owns SPDY as a trademark?

Greg Wilkins: Firstly let me applaud Google for the way they have handled this project. In many ways this could be considered an abuse of Google's market power, as they use their popular web browser and web services to foist a new proprietary protocol on the web, weather we want it or not. On the other side, Google have been very open about their intentions and about the development of the protocol. The protocol has been a Google dev project for over 2 years and the developers there have engaged well with the community to consider feedback and contributions to the design and implementation.

It is Google's stated intention to take the protocol to the IETF to be standardised, and they have submitted a draft http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00, which is addressed to the httpbis working group. I'm not familiar with the exact time frame for moving forward with standardisation, however I would think that the approach taken so far will fit well with the IETF's preference of standards via rough consensus and working code.

So there are indeed some questions about if this is an use or an abuse of Google's market share, but I don't think we need to be overly concerned so long as this moves to the IETF in reasonable time. Importantly there are no "features" of Google's offering that are tied to SPDY. If you don't like it, you are free to block it and you will get the same services over HTTP with a little more latency.

InfoQ: Finally, Jetty also supports WebSockets as a generic communication mechanism, which uses HTTP for its frame transport. Can you explain how SPDY differs from WebSockets, and whether the two are likely to meet in the future?

Greg Wilkins: WebSockets, like HTTP can be considered in two parts: the semantic of the communication exchange and the wire protocol for transporting that semantic. WebSocket introduces bidirectional datagrams to the browser and provides a protocol to transport those to/from the server. Just like SPDY has replaced the wire protocol for HTTP, it can be used to replace the wire protocol for WebSocket. There is already a proposal and beta implementations of WebSocket over SPDY.

SPDY™ is a registered trademark of Google, Inc.