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

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.

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.

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.