What is your take on SPDY, Google's experimental HTTP replacement?

Question

Google is working on an experimental protocol called SPDY (pronounced "speedy") that supposedly makes the web twice as fast.

The problems with HTTP that SPDY tries to address are:

• only a single request per connection (barring persistent connections)
• the server cannot initiate a connection
• headers are always uncompressed (N.B. cookies are sent in the header)
• in a persistent connection, all headers are resent for each request
• data is not always compressed
• everything is in clear text

SPDY addresses these issues by:

• allowing unlimited and interleaved requests through a single connection
• prioritizing requests (controlled by the client only)
• compressing headers
• allowing the server to push resources to the client without the client's asking (e.g. you're going to want the CSS file anyway)
• allowing the server to suggest in the header what other resources the client might want to request (so no need to wait for the HTML to be parsed before knowing)
• always using SSL

Google claim to have built a web server and modified Chrome browser that support this protocol and achieve 50% less time for page loads.

I think that the server push would be the killer feature. If a client will keep the connection open as long as the user is on that web site, developing web applications become much easier. It means that polling the server with AJAX requests is no longer necessary; theoretically, the server can just push new data to you when it becomes available. And when a client connection terminates, you know that the client has closed the web site (application).

Of course, if SPDY ever makes it to market, HTTP will still stick around for a long time. But it seems that both protocols are happy to live side by side. I would say it takes at least five years until a significant portion of the web will be available from spdy:// URLs.

So, the web twice as fast! Easier webapp development! More security! It sounds too good to be true. But is it really going to happen? Do you see any drawbacks?

Answer 1

Doomed but useful.

The idea of supporting two different protocols side-by-side that have significant overlap in functionality will not appeal to real-world development and operations organizations, and HTTP is too deeply embedded to ever be tossed out at this point.

That said, I expect we'll see an HTTP 2.0 draft in the next few years that looks suspiciously like a merger between SPDY and HTTP 1.1. That's how these things usually work -- someone shakes up the industry with their shiny new toy that everybody loves but nobody will actually deploy, and after a while the existing specs get a nice revision to address the needs embodied in the shiny-but-failed effort.

Answer 2

It looks like a good thing overall. The FAQ suggests there won't be "spdy://", it will still be http:// but faster.

If Google can make surfing with Chrome 50% faster with an experience that equals Firefox, the market will move that direction and all the webservers and plumbing will be forced to move. Chrome itself has a way to go in that regard, so time will tell.

Answer 3

I don't think CSS is a very good example for server-push. If you've ever visited a site you'll have the CSS cached, so forcing it on the client would be wasteful.

Answer 4

From Google SPDY FAQ:

Q: Is SPDY a replacement for HTTP?

A: No. SPDY replaces some parts of HTTP, but mostly augments it. At the highest level of the application layer, the request-response protocol remains the same. SPDY still uses HTTP methods, headers, and other semantics. But SPDY overrides other parts of the protocol, such as connection management and data transfer formats.

So i think it will be a happy coexistence! Now let's test it!