From the link

"HTTP/1.x has a problem called “head-of-line blocking,” where effectively only one request can be outstanding on a connection at a time."

Does it? Why?

In HTTP/1.1, more than one request can be outstanding at a time, but responses must be delivered by the server in the order they're received (this is required by the HTTP/1.1 spec).

The head-of-line blocking problem actually refers to that behavior-- if I have two requests, one of which is for a 2 MB file and one of which is for a 1 KB file, and I send the 2 MB request first, the server's obligated to completely finish the 2 MB response before it can send the 1 KB file. This isn't great for perceived performance, and runs contrary to how a user expects their web browser to behave (let the small stuff appear first, then let the big stuff finish downloading as it can). HTTP/2 corrects this oversight and allows (through multiplexing) a single connection to behave more like multiple connections would in HTTP/1.1 (multiple transfers can happen simultaneously).

I agree that the case of 1 large 2MB image and a small 1KB file is a good case for multiplexing.

What annoys me somewhat is that HTTP2.0 was basically sold on the back of such demonstrations as 'load 256 identical images'. In that case a proper implementation of HTTP 1.1 with keepalive/pipelining would be just as fast (or even slightly faster due to avoiding multiplexing overhead) as HTTP 2.0.

I think it's pretty pathetic that people can't implement this properly, and I find it worrying that the solution to not being able to implement a protocol properly is to replace it with a more complex protocol.

A cool thing about HTTP/2 is that it's really mostly just an optimization for HTTP/1.1.

Which means that if and when we come up with something better, we can deprecate HTTP/2 support, and support only HTTP/next + HTTP/1.1. This helps avoid legacy cruft.

Google did that for SPDY with Chrome - it's no longer supported.

While I'm not convinced that a proper implementation of HTTP 1.1 would actually be just as fast as HTTP 2.0, if you are right, there will be data to show it, and it's not too late for us to change the ecosystem based on that data.

While I understand and agree with what you said, HTTP 2 still runs on top of TCP, which means that when you lose a packet, subsequent packets belonging to other responses can't be delivered to the application layer, even though there's no reason to delay them. TCP's strict byte order semantics is the problem.

If only the HTTP/2 implementation on the receiving side could tell the underlying TCP stack that it wants to opt out of byte order semantics and to deliver data as it's available. That will decrease latency while not requiring any protocol changes on the sending side.

This is one of the advantages of the QUIC protocol [1]. Which basically implements what you're saying over UDP.

[1]: https://en.wikipedia.org/wiki/QUIC