Hacker News Reader

Comment by bsdetector | Hacker News Reader

The problem with SPDY is that HTTP pipelining has essentially the same performance as it:

http://research.microsoft.com/apps/pubs/?id=170059

There hasn't been a single publication by Google that hasn't been fundamentally flawed, for instance comparing SPDY to HTTP without pipelining (all their claims) or leaving out the TCP handshake for SPDY but including it for HTTP (their claims for mobile).

There are a ton of unsubstantiated claims that followers just repeat without analysis, for instance "head of line blocking" across several connections is not a problem that needs to be solved.

SPDY was designed largely by one recent college grad. That isn't the way to design a protocol to replace HTTP because no matter how smart they may or may not be they don't have the experience to do a good job. Take for instance the compression not being secure... this attack was known to experts at the time SPDY was developed and should have been avoided.

View on HN

To your points about pipelining, there's a reason it doesn't get compared. It's not usable - https://insouciant.org/tech/status-of-http-pipelining-in-chr...

Head of line blocking is so well documented that there are many common web performance techniques to get around it, like domain sharding: http://www.stevesouders.com/blog/2009/05/12/sharding-dominan.... It'd be very interesting to see where you get your data that head of line blocking is not a problem.

I'm not sure where you are getting your info that SPDY was designed largely by one recent college grad. I don't think of Mike Belshe and Roberto Peon as the same person, much less recent college grads :) Maybe 40+ year olds still counts as "recent"?

Sharding is because of browsers only opening a few connections to each domain (6 for example). Even with keep-alive the resource on each connection must be finished before sending the next request, so there is a round trip for each resource -- exactly the problem pipelining solves by sending the other requests immediately. This is not "head of line blocking".

On your first link, note the "in chrome". Pipelining works great in Firefox, Opera, Android Browser, but Google has only ever tested with Chrome. In fact, probably the reason they didn't test pipelining in mobile Chrome was that it did not even support pipelining at the time. Google never went back once Chrome (kind of) supported pipelining.

Microsoft actually tested pipelining and found with it that HTTP was basically equivalent to SPDY in performance. Read the paper. And with an unoptimized pipelining implementation.

The page you link to provides a lot of hand waiving like about incompatibilities, but this is actually completely beside the point of whether the complication in SPDY actually improves anything. If you come up with a new protocol just to overcome bad proxies you can just as well have HTTP/1.2 that is exactly the same as HTTP/1.1 except pipelining works; incompatible proxies will only support HTTP/1.1 and the browser can disable pipelining (or some similar solution).

EDIT: apparently the main SPDY guy is older than I thought. The point stands however that having one or two people design a protocol to be used by the whole internet is a bad idea.

Head of line blocking is when something ahead in the line blocks things behind it. If browsers choose to use connection limits, then that means that things ahead in the line and get to use the connections are blocking things behind in line which have to stay queued up waiting for the connections to free up. So yes, that's head of line blocking.

As for pipelining working great in those browsers, you should note that no major desktop browser uses pipelining. Firefox does not enable it by default. See the Firefox bug thread where it's explained why it's not on by default, and also identifying its head of line blocking issues: https://bugzilla.mozilla.org/show_bug.cgi?id=264354#c30.

Microsoft did test pipelining. In their theoretical lab network, with ideal situations, they can match SPDY performance. But the sad reality is that real websites and networks don't match that. Please see http://www.guypo.com/technical/http-pipelining-not-so-fast-n.... And you have to ask yourself, if Microsoft really believed that result, why don't they enable pipelining in IE?

It's fascinating to me that you still seem to hold onto your claims that HTTP pipelining is feasible in real networks, even though IE, Firefox, and Chrome developers have all clearly tried and given up on it.

Reply on news.ycombinator.com