> in the first test, h1 compound is just as fast as h2
That's because HTTP/2 auto-compounds multiple requests to send in the same connection, thus there is no surprise there.
The main advantage of HTTP/2 is that it ensures that we can get the same benefit of compound data transfers in a completely transparent manner, without bothering to rearchitect how clients and servers operate.
> Considering all the additional complexity that HTTP/2 introduces, that doesn't seem like any improvement.
This assertion completely misses the whole point of HTTP/2, and why it's a huge improvement over HTTP/1.1.
> The main advantage of HTTP/2 is that it ensures that we can get the same benefit of compound data transfers in a completely transparent manner, without bothering to rearchitect how clients and servers operate.
Yea this assertion is spot-on, but sadly HTTP/2 still has enough overhead that if speed really is the most important requirement, compounding data is still better. I was hoping the difference would be at least smaller.
Also of note is having to terminate a single TCP/TLS connection per client vs one for every concurrent client request! Even if you are using a middle man like a CDN doing HTTP 1.1 pooling this is still reducing the established TCP/TLS connections by an order of magnitude or more.
That's because HTTP/2 auto-compounds multiple requests to send in the same connection, thus there is no surprise there.
The main advantage of HTTP/2 is that it ensures that we can get the same benefit of compound data transfers in a completely transparent manner, without bothering to rearchitect how clients and servers operate.
> Considering all the additional complexity that HTTP/2 introduces, that doesn't seem like any improvement.
This assertion completely misses the whole point of HTTP/2, and why it's a huge improvement over HTTP/1.1.