Comment by kjksf | Hacker News Reader

Comment by kjksf | Hacker News Reader

Parent Full thread

https://www.youtube.com/watch?v=-yxQIRl6Qic talks in great detail about why http2 exists and why it does things the way it does.

It also addresses the usual complaints, including the "binary" part.

The short version is that is all about speed and security (by encrypting everything).

As to the issue of binary vs. text. Implementing binary protocols (including tools used for debugging them) is much simpler than implementing text protocol. HTTP1 might look simple to human eyes but it's not an easy protocol to implement (fully and correctly). I know, I tried.

Furthermore, engineering is about tradeoffs. HTTP2 is not simple but the complexity exists to address real problems in failure modes of tcp stack and to maximize speed by both sending as little as possible (compression) and ensuring that one request doesn't block the other, as long as there is bandwidth to send both.

Maybe the purity and simplicity of the protocol is more important to you than improving the speed by few %, but to make it makes perfect sense to trade simplicity for even modest gains in performance in the context of http.

You only write the code once but it'll speed up every http connection until end of time. That's a lot of http connections which adds up to a lot of bandwidth and time savings.

Bandwidth is cheap. I don't buy that argument, but I do see that there are problems with HTTP and the way it is implemented. I think that if you are going to implement something that will replace HTTP that it had better be something that is huge step up from what we have today and in that respect HTTP2 fails to convince me that it is that step.

Keep in mind that we're talking about the protocol that currently powers much of the developed world as we know it and that mistakes will be extremely costly to correct. HTTP has its warts and quirks but for the most part we have worked our way around those.

Minor efficiency gains do not add up for me to a complete overhaul of the web and everything attached to it.

So what we'll get instead is this: a percentage of the web will transition (mostly the bigger players where that few % adds up to a higher bottom line), the rest will not care and wait for HTTP3 or whatever will come after HTTP2 to really address what's wrong with HTTP (and that's not that it isn't fast enough, that's mostly a problem with the underlying transports, HTTP is plenty fast).

> Bandwidth is cheap.

Says someone who I'm certain doesn't rely on a prepaid SIM for their primary Internet connection. Not that I do either, but I'm far more aware that tens (if not hundreds) of millions of these people exist today. In fact, it's likely that such people will be a clear majority of Internet users early in the life of HTTP2. Leaving them out of the conversation, as you implicitly do here, would be a colossal mistake for a protocol that intended to stand the test of time.

The difference between HTTP and HTTP2 is not noticeable cost-wise on the consumer side, it is only noticeable in the aggregate when serving millions of requests.

Let's not try to pretend that HTTP2 is about bandwidth savings in the third world, that didn't even enter the consideration at any level.

If you want to save bandwidth at that level then you're better off reducing eye candy and using apps rather than websites and not shipping bloated pages with 100's of requests and 1/2 MB of javascript frameworks across to mobile devices.

Shaving a couple of bytes off a header is not going to move the needle there.

For the record, I ran my internet connection of one of those pre-paid SIM cards for a month and the big killers were websites that keep refreshing their pages, javascript frameworks and advertising.

I agree the developing world wasn't an explicit consideration, but mobile most certainly was. And since better mobile performance and behavior is what developing world Internet clients most need from a new protocol, many of their concerns are being explicitly addressed.

As for whether "shaving a couple of bytes off of a header" makes a practical difference, you should consider the "Why do we need header compression?" answer here: http://http2.github.io/faq/ which references concrete evidence provided by an HTTP2 advocate. Personally, I find that more convincing than your apparently unsupported assertion.

Separately, it's nice to say websites should drop the eye candy and the Javascript frameworks (the hundreds of requests is addressed by HTTP2 multiplexing, I believe), but that's missing the point. As has been repeatedly demonstrated since the earliest days of WAP, mobile users don't want a stripped-down subset of the Internet, they want as much as they can get. From that perspective, raising the bar on what's possible (as HTTP2 tries to do) moves the ball far more than trying to convince websites to fit themselves into today's constraints (especially since the mobile user in the developing world has one of the strictest versions of those constraints).

You'd have to separate out the components in HTTP2 to make sense of the various advantages offered. As long as the cookie abomination persists the header compression makes sense, but if you were to really come up with an improved HTTP then you would get rid of cookies entirely and make HTTP a stateful protocol, since that's what we seem to be headed for anyway, or at a minimum get that session stuff under control.

So now we get this terrible mix, a binary protocol that pretends to be stateful but really isn't, carries over all that's wrong from the past and replaces it with a bunch of fixes that don't seem to address the root causes of the problems.

As for mobile users wanting the full experience, sure, that's why we want better mobile networks, and preferably un-metered ones. (Which is already happening, no limit contracts are making a come-back.)

Anyway, I'm sure that HTTP2 will be implemented because Google has found a way to ram its competitive advantage down our collective throats and we'll have to live with it but I don't think the minor advantages gained here are worth the retooling required. Think of it as a missed chance, if we're going to retool then let's do it well and not in a half-assed and fast-tracked manner like this.

Feel free to disagree.

Actually, I think I now understand where we disagree. It isn't exactly where I expected.

You want a New Improved Transport Protocol that is a sharp break with HTTP's past. I agree that would be a good thing. We both agree that HTTP2 isn't that.

Where we disagree is this: You want NITP to be called HTTP2. I think doing that would be the surest way to smother NITP in its crib. In my opinion, an HTTP2 that made a radical change like not supporting cookies wouldn't be a step forward, it would just be perceived as "breaking everything" and would never get adopted.

You can't just slap HTTP's brand on a radically different protocol and expect people to not notice or care about what's inside. If you want to do something really new, that's a much longer and harder path than what we see here. That's why things like HTTP2 (making improvements where practical while carrying forward the concepts and baggage of the past) are worth doing. Because while we're waiting for a bigger leap forward, we've accumulated a set of problems we can solve and that are worth solving.

> Bandwidth is cheap.

and the speed of light is constant. http1 has issues accessing all available bandwidth, and speed of light ensures that with a limited bandwidth your page load times will suffer. you don't go to web pages that take forever to load. nobody does.

the bandwidth argument is not the argument you should be making. you should be making the argument that today's pages are bloated and we need to work on reducing page/image size. that is being worked on too.

everybody willing to diff http1 and http2 should just take a look at this with a modern browser and imagine it in a standard site context (bigger images, many more site elements):

https://http2.golang.org/gophertiles

http://http2.golang.org/gophertiles

I think you are replying to the wrong comment here, I did not make the argument that bandwidth was a major consideration, my point is that it isn't.

Latency != bandwidth.

Installing ghostery will do more for your page load times than http2 will.

> Latency != bandwidth.

yes, and you're conflating the two.

From kjksf's comment above:

"That's a lot of http connections which adds up to a lot of bandwidth and time savings."

I was only addressing the 'bandwidth' part.

The latency bit (which is partially addressed by running multiple concurrent connections via a single socket) is a different issue, for which we also already have multiple solutions (for one, stop making a few hundred requests for a page).

> for one, stop making a few hundred requests for a page

Telling the world "you're doing it wrong" is not a pragmatic solution. HTTP/2 exists to improve the web as it exists today. In this, it demonstrably succeeds.

For the same reason Javascript will remain the assembly language of the web, so too will HTTP/1.1 semantics likely persist forever. It's not because it's what we want but because there is no (yet) known transition away from it. HTTP/2 doesn't replace HTTP/1.1. It just deprecates a horrible wire format and adds some other features.

> Latency != bandwidth

No, but latency has a linear relationship with throughput

Test at page at 1Mbps thorough 10Mbps and 25ms RTT and watch how small the performance gains are above 5Mbps, then do the same with 10 to 200ms RTT and 10Mbps and watch performance dive.

> Bandwidth is cheap.

Bandwidth is just one problem. If you use HTTP/1.1 to download large files, you won't have much problem. If you try to design a memcache-like protocol based on HTTP/1.1, the result will be terrible. You simply can't afford to parse text at 100+k QPS and wait for previous request to finish before sending next one. HTTP/2 is not designed to solve bandwidth issue. It is about latency and throughput in real world.

"Bandwidth is cheap"

It's not about bandwidth. It's about latency and how completely inefficiently HTTP uses TCP connections. And actually the fact that our modern connections have so much bandwidth is what is exposing how poorly HTTP utilizes the network.

"HTTP has its warts and quirks but for the most part we have worked our way around those"

No we haven't. Look at any waterfall graph. See all that green? That's the network doing nothing. It's mostly green. HTTP's request/response model creates head-of-line blocking and uses the network connection poorly. (And the HTTP pipelining dream isn't going to happen with 20 years or HTTP devices out there)

The way we have "worked our way around those" are hacky ways to either try and reduce the number of requests we have to make (combine files, CSS sprites, etc), or by hacks to try and run more poorly implemented network connections in parallel to minimize the effect (domain sharding).

The "reduce the number of request" hacks suck for many reasons, of both the devs (build scripts, slicing the CSS images) and the end user (caching opportunities limited to giant JS or CSS bundles that frequently change invalidating the entire bundle, do you know how much memory a 2000 x 2000 px PNG24 CSS sprite takes up?). The "use a bunch of bad connections in parallel" hack sucks a bunch too. It uses more socketsand it uses slower, cold TCP connections, and its a pain to maintain.

I agree that HTTP/2 is making some assumptions about the underlying network (specifically around reducing the size of certain payloads to the fit inside default TCP windows for cold connections). However, HTTP/1.x's way of sending several kilobytes of duplicate plaintext information for every request is a poor approach as well.

> The short version is that is all about speed and security (by encrypting everything).

I'm not up to speed on certificate verification for HTTP2. Have the IETF suggested a mechanism? If so t must be outside the draft-ietf-httpbis-http2-16.

Reply on news.ycombinator.com