[fusiongyro]

HTTP wasn't, and isn't, broken. Google alone had the combination of a financial incentive to improve, engineers capable of improving, and few application-level opportunities to exploit instead. This is literally the last thing you should worry about optimizing. Very few of us are privileged enough to work at a place that is so short on real problems we can worry about one like this.

In this industry we have a 15-25 year rewrite cycle. The cycle always begins with something deceptively simple that wins wide support through being easy, and ends with multilayered nonsense of dizzying complexity. Efficiency was not a design goal of HTTP. "Changing" that isn't just insulting to the spirit of HTTP, it expresses a complete lack of regard for history.

I don't know how we're going to break the rewrite cycle, but I can tell you heaping complexity atop complexity appears to be exactly the engine driving it, and just when things reach the pinnacle of the absurd, someone comes along with a disruptive, simple alternative and takes over the world with it. SPDY is late-game technology. The end of this loop is near, and we'd be better served keeping an eye open for the start of the next one than trying to master the intricacies of one more difficult and unnecessary improvement.

[acdha]

This is only true if you narrowly define the scope to be what HTTP started as: synchronous, unidirectional, and only concerned with single files[1]. When you consider the problems many, many people - not just Google - are dealing with break at least one of those assumptions it's clear that HTTP is incomplete.

1. SPDY will be nice for anyone using much JS/CSS on their site

[fusiongyro]

I don't think I could disagree with you more thoroughly than I do. Your argument amounts to saying the postal service is incomplete because mail trucks don't have jet engines on top.

First, HTTP pipelining exists.

Second, HTTP's inefficiencies establish a bounds on your performance. HTTP itself does not define your application's performance, unless you've already mined every optimization opportunity at the levels above. Do you ensure all your CSS and JavaScript assets are bundled into single files and minified? If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will. What about your caching story? What about your database, is it indexed properly? These are tangible improvements that you can make in your application today that can and will improve performance for the end user.

At my work, there is a CGI app written in C that does some atmospheric calculations against a database. The old database was Oracle, the new one is PostgreSQL. The CGI now takes twice as long to run as it did before, which is noticeable because it used to take about 5 seconds, so now it's taking 10, for one day of calculations. Looking into the problem, we found a place where an index would be a good thing to add. So we added it, and the performance didn't change at all.

It turns out, the app is sending a separate SQL query for individual data points. The app needs hundreds of thousands of data points to do its work, so it's sending many thousands of queries on each request. One query can fetch all of the data this program needs in about 0.3 seconds. So this app is, in effect, not measuring the performance of the database itself at all; instead it's measuring the overhead of running an instantaneous query on Oracle and Postgres, multiplied by several thousand. It turns out that the overhead of setting up and performing a query is about twice as high with Postgres. This fact never matters in practice though, because when you notice it you're doing something stupid. Nobody ever says "you should switch to Oracle, because that Postgres's queries take 4 milliseconds to setup instead of 2." (The fact that this app is written in C and could easily be outperformed by a shell script is also telling.)

This is exactly why HTTP is in no sense incomplete or narrowly defined. Google is the one with the narrowing requirements: they know exactly how much money HTTP's inefficiencies are costing them and are in a position to throw engineering time and energy at that number to decrease it. They are also in a position to optimize every other corner of their stack, and presumably they have. This is not true anywhere else.

SPDY is somewhat beneficial for consumers. But it undermines the simplicity and clarity of HTTP. That's what makes this late-game technology. SPDY is SOAP and CORBA to HTTP's RPC. Is it a better definition? Probably. But it's also harder and the benefits are insignificant except at scale.

[acdha]

> First, HTTP pipelining exists.

… and is not currently usable, nor as full-featured as SPDY even if correctly implemented by all vendors

> If the answer is "no," you have no business complaining about HTTP's performance—managing your assets better will improve performance far more than using SPDY alone will

Flat-out wrong: there are many use cases which require multiple requests (you only mentioned CSS/JS but images are significant, too) and this would be exhibit A for an HTTP deficiency: you've internalized the idea that a visitor to the site must download and process EVERYTHING you could ever use to avoid making multiple requests, wasting bandwidth and device CPU/memory because you're trying to use asset packaging as an end-run around protocol shortcomings.

As for databases, this was a fascinating and completely irrelevant digression.

[fusiongyro]

Proof:

http://www.guypo.com/technical/not-as-spdy-as-you-thought/