Hacker News new | ask | show | jobs
by hobohacker 4548 days ago
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"?

1 comments

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.