You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper [chromium.org] - it's quite interesting.
It's really not that interesting. They make a lot of claims without sources or any support whatsoever and won't answer questions about it, for instance see threads here or on reddit where google employees post about SPDY (ie are reading the thread) but won't answer questions about methods and sources or defend their theories.
Sorry that you feel this way - we've been very explicit about how to contact us, and many many people have found us without trouble. If you've got a question that you want answered, the discussion is on firstname.lastname@example.org, and we've always been very open about that fact.
The problem that SPDY is supposed to solve in it's overly complicated way has a simple solution: tweak HTTP pipelining so that the server can respond in any order it wants to.
Well, you should go implement that and come back with some data. If you're right, I'd love to see it. But before you do, you might want to ask yourself, why none of IE, Firefox, nor Chrome ship with pipelining turned on, even though we all want to be fast?
The answer is that pipelining has serious deployment problems, which you can read more about these within the IETF HTTP working group if you wish. Here is a quick list:
* client-side proxies and intermediaries sometimes just fail to process the requests correctly
* the responses must come back in the order which they are sent by the client
* you can't start pipelining until you finish receiving at least one HTTP/1.1 response from a server
* server farms sometimes loadbalance requests across HTTP/1.1 and HTTP/1.0 servers
* pipelining requests behind a hanging GET (or any high-latency request) completely breaks.
These might be surmountable - but I assure you that the complexity of implementing pipelining in a way that works on the web today is pretty much on par with the complexity of SPDY. Up until just a few years ago, major sites in the top-100 could not handle pipelining. And when it fails, the user is left with a hung browser, or worse, garbled data. That is why it isn't implemented.
Then servers can send resources when they are available, in smallest-first order, or whatever and the pipeline doesn't block on ad.doubleclick.net (it's just sent last when it is finally finished profiling you).
This is just incorrect information - you should re-read the pipelining specification.
That's all there is to it. The HTTP designers didn't do it because they didn't want to go far enough with changes, instead just tacking pipelining on almost as an afterthought. Maybe Google invented SPDY because they are afraid of tweaking HTTP or think standards move too slowly? I don't know, all I know is that SPDY is bad news.
If you've got data to back that up, I'm listening.