For many years now, we have relied on the marriage of the TCP and HTTP protocols for handling data request/response communication, and transporting the resulting data packets to where they need to go. In short, they are how we get things done on the Web. But they are not perfect. Websites are a lot bigger and more complicated than they used to be when these protocols were first designed. HTTP in particular has problems with latency, because:

It can only fetch a single resource at a time, per connection

Only the client can initiate requests under HTTP

HTTP request and response headers are uncompressed, and can become rather large. In addition, many header transmissions are redundant

Data transmitted via HTTP is not always compressed.

In short, the web is slower than it could be, and the problem will get worse as web sites continue to increase in size and complexity. To mitigate this problem, the Google Chromium team set to work and developed a new networking protocol for the web, which would reduce latency and speed up page loading. The result is SPDY, which Google have put to work on most of their services (Twitter and a number of other sites are also using it), allowing much faster loading speeds, provided the web browser being used supports SPDY.

The good news is that we've been hard at work implementing SPDY support in Opera, so the big red O can also take advantage of these performance increases! Other advantages include better compatibility with all Google services (and other sites and applications that employ SPDY), and allowing developers to test their own SPDY based services with Opera.

We are proud to present an experimental labs release that includes our SPDY support. Please try it out, and let us know what you think.

Further SPDY information

SPDY does not completely replace HTTP and TCP — it augments and works on top of those protocols. HTTP's communication semantics and TCP's congestion control, for example, are still used, but SPDY provides many advantages, such as multiple streams per connection, and more efficient connection management and data formats.

SPDY doesn't force data compression, but SPDY user-agents MUST support gzip compression. Regardless of the Accept-Encoding header sent by the user-agent, the server may always send content encoded with gzip or deflate encoding.

Currently there are two versions of SPDY that are deployed and used in the web: spdy/2 and spdy/3. All Google services (using secure connection) and Twitter can be used with both of them - it's for the client to negotiate which version is to be used. The negotiation is being done by the NPN protocol during the SSL handshake. Of course, the client can also negotiate to use plain HTTP over SSL if desired.

Google have prepared an SPDY module for Apache 2.2, therefore anyone can deploy SPDY on their own Apache-based server and use it for creating web sites and applications.

Download our SPDY build

Please select a suitable build for your operating system:

Support notes

Opera's SPDY implementation currently supports all features of the spdy/2 and spdy/3 protocols, except for:

PUSH and HINT: There is no deployment of PUSH and HINT usage on the web (as far as we know), and no way to use it with mod_spdy, so we decided not to implement it for the time being, until we have something to test it on, and more evidence of actual usage.

The Alternate-Protocol header: Neither Chrome nor Firefox have implemented this in the way described in SPDY draft 2, moreover SPDY draft 3 does not even mention that header anymore, so we decided to not support it.

header: Neither Chrome nor Firefox have implemented this in the way described in SPDY draft 2, moreover SPDY draft 3 does not even mention that header anymore, so we decided to not support it. Persisting SETTINGS values: Servers may request that the client persists some of the connection settings sent to it in the SETTINGS frame. In such cases the client should remember such settings, and use them in all future connections (the user should also be able to clear them when desired.) This isn't a key feature of the SPDY protocol, and SPDY works perfectly fine without it, but we'll probably implement it in a future build.

How fast is it?

Our rough performance tests ran on Windows with 50ms extra latency, and revealed that SPDY gave us a 38,67% performance boost (compared to normal HTTPS) in the network layer. That's great for a start!

Google also has some SPDY performance test results available.

How do I know that Opera is using SPDY?

Use of the SPDY protocol is completely transparent for users. There is no additional scheme like spdy:// , and we don't have any indicator saying ATTENTION, page loaded with SPDY! . There is an SPDY indicator extension available for Firefox and Chrome, and this should also be available for Opera, soon after we've created the necessary API to make this possible.

One way to recognise an SPDY site is by looking at the additional headers loaded with SPDY: Opera Dragonfly makes this easy. The spdy/2 additional headers are method , scheme , url and version . For spdy/3, the additional headers are :method , :scheme , :host , :path and :version .

Summary

SPDY is a useful new protocol that has already demonstrated significant performance increases over using HTTP/HTTPS alone, and Opera is proud to unveil support for it. Please let us know what you think of our experimental SPDY build, by leaving comments on this article or filing bugs through our bug wizard.

You can find much more detail about SPDY, including Google's own performance test results, at the Chromium Team SPDY Whitepaper.