[vitus]

Personally, I'm more curious to see the comparison with QUIC, which eliminates the RTTs to set up TCP + TLS, and multiplexes connections in a way that doesn't lead to the head-of-line blocking problem that you can see with HTTP/2 over TCP -- QUIC uses UDP, so no requirement for in-order delivery across the entire connection, just within each resource flow (in this context, each request).

On that note, I do think it's a bit inaccurate to say that Google's efforts are/were primarily focused on data compression -- yes, they did introduce brotli, which is just a better LZ77 implementation (primary difference with gzip is that window size isn't a fixed 32KB), but they also pioneered SPDY (which turned into HTTP/2 after going through the standards committee) and now QUIC.

(obligatory disclaimer that google gives me money, so I am biased)

[tyingq]

Wouldn't it be difficult to do a straight comparison without other variables, given that there isn't a popular webserver that supports the protocols they tested with, as well as QUIC?

Edit: Should note that I'm excited about QUIC as well, just thought I may have been missing some new development where it's (already) more usable outside Google's walls.

[vitus]

It is, but that doesn't change the fact that I'm still more curious on that front. The wiki page has a few sample servers [0], but again, those don't meet your criterion of popular.

I realize that the initial RTT reduction isn't so relevant in the context of large dependency graphs, but especially in the context of packet loss, the proper multiplexing across flows seems useful.

There are also a number of other QUIC-based features that might be relevant, since it does essentially reimplement the relevant parts of the TCP stack, so parameter choices might be better suited to today's internet (as opposed to 1980's).

[0] https://en.wikipedia.org/wiki/QUIC#Server_support