Hacker News Reader

Comment by dsiegel2275 | Hacker News Reader

Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?

Not sure, isn't the whole point of pipelining to avoid these domain-sharding workarounds?

This test case shows that the performance is better with the same code. The invert test case would show that the code is more complex (because of sharding) for the same performance (actually not quite, because of multiple handshakes).

The whole point of pipelining is to avoid expensive TCP operations. Domain-sharding is effectively a workaround for the workaround (limiting connections to hosts).

You can actually do both domain-sharding and still use only a single TCP connection. SPDY/HTTP2 will reuse existing connections if they receive the same cert/ip combo. It's the best of both worlds while http1 still has some marketshare.

Good point, but domain sharding is just a clever optimization (hack) to emulate some of the parallelism provided by HTTP/2 out of the box.

Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!

Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing.

Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up.

[1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.

I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.

Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.

domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.)

Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer.

Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.

I wouldn't say so. Domain sharding is a hack, and not every website implements it, so I think this is a fair comparison.

Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.

Yes and no. It would speed up the client receiving the images but at the detriment of flooding servers with connections (even moreso bad if HTTPS). I assume since this is on golang's site, this is also trying to show off the difference with just using the HTTP2 vs HTTP package.

The page is also a reference server implementation for people working on clients are well.

Does anyone know when the HTTP/2 client for Go will be available? And, are they likely to include http/2 into a standard net/http package?

Reply on news.ycombinator.com