h2 failed because it's mux everything into 1 single tcp connection, and it only takes 1 failed tcp to block everything in line.
h2 really need to do demux. But h2 actually can technically do M:N connections, but browsers do only 1:N.
Also h2 is a failed promise. Most sites deliver web assets and page and js in different host, also ws/wss in a different host. Thus renders h2 advantages complete useless.
Just curious, what do you mean? Quickly Googling this, it looks like 1/3 websites use HTTP2 today, which is darn good for a relatively new protocol.
Most sites use h2 by just wrapping http/1.0 behind some h2-enabled CDN or upgrade to latest nginx and call it done.
What about h2 push? Priority? WS inside h2? Nope. No one use them obviously.
I mean gRPC utilized more h2 features than most h2 browsers/CDN do.
I am less worried about what most sites do and more interested in the features offered by implementations. A huge number of sites don't even use https.
Again, the goal of h2 is not to maximize usage of features in the h2 protocol. So judging h2 by that metric does not make any sense. I could just as easily complain that HTTP is a failure because few sites use more than just GET/POST, or because many of the headers defined in the HTTP standard are not commonly used.
I'm curious to hear what you mean by WS inside h2, not sure how that's different. WS is only http for the first part i.e. the upgrade request.
Sure, there's some other stuff in there, server sent goaway in particular is a great way to indicate the server intentionally closed the connection, but the primary objective is to get around congestion control -- which could have been better solved by just adjusting congestion control to pool by destination IP in clients Google could control (at least Android) and on servers Google could control (at least their servers)