[pi-e-sigma]

This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)

[avianlyric]

Have you got any data to backup that claim?

It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection.

You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.

[pi-e-sigma]

Yes I do have data. You can have that data, too. Just do the testing yourself.

[avianlyric]

You’re making the claims, feel free to share the data you already have.

Oh and while doing that, also feel free to respond to the rest of comment that outlines why opening an unbounded number of TCP connections to a server might be a bad idea.

[jchw]

I'm sure it can. However in my real world use cases, HTTP/2 and 3 work better when available for me, so I'm glad to have them. I'm sure this comes as no surprise to most people since SPDY went through a lot of testing before becoming HTTP/2, but just because it doesn't win on every point of the graph does not mean it doesn't still win overall.

Besides that, more than half my point is that I like HTTP/2 and HTTP/3 for the featureset, and you can't get that by increasing the max connection limit for HTTP/1.1.

[JackSlateur]

That would greatly limit the maximum number of simultaneous clients behind the same IP (at the office, at the university etc)

When the limit is reached, all clients would be broken

Looks like a good deal indeed, why do not we do that