The latter is obligatory. HTTP/3 is a way of spelling the HTTP protocol over QUIC, and QUIC is implicitly doing TLS 1.3 (or later) cryptography.

So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?

>So the fairer comparison might be TLS 1.3 under all three, but if you need to upgrade why not upgrade the whole HTTP stack?

Because it's a benchmark of HTTP3 and not a comparison of "as it might be stacks".

It would a bit like bench-marking HTTP/1 with RHEL7 and Apache2, HTTP/2 with RHEL8 and NGINX and HTTP/3 with...let's say Alpine and Caddy...it's just not a clean benchmark if you mix more then one component and try to proof that this single one component is faster.

Good point. So TLS 1.3 everywhere would have been better

Especially when their benchmark scenario is something that plays to the strengths of tls1.3 and would probably only mildly be improved (if at all) by http/3

Well yes if it's a benchmark ;)

> HTTP/3 is a way of spelling the HTTP protocol over QUIC

HTTP/3 could perhaps be described as HTTP/2 over QUIC. It's still a very different protocol from HTTP/1.1, even if you were to ignore the transport being used - the way connections are managed is entirely different.

It's just spelling. It certainly wouldn't be better to think of it as HTTP/2 over QUIC since it works quite differently because it doesn't have an in-order protocol underneath it.

HTTP has a bunch of semantics independent of how it's spelled and HTTP/3 preserves those with a new spelling and better performance

QUIC does require TLS 1.3, but as far as I can tell HTTP/2 over TLS 1.3 is perfectly viable, and is likely a common deployment scenario.

Upgrading just TLS to 1.3 for most people likely just means upgrading to a newer openssl which you probably want to do anyway. In many web server deployment scenarios, deploying HTTP/3 is highly likely to be more involved. The Apache httpd doesn't support H3 at all, I don't know if nginx has it enabled by default these days?

NGINX has an experimental QUIC branch [1], but in my experience it is buggy and currently has lower throughput than using Quiche [2] with NGINX. I do the latter for my fork of NGINX called Zestginx [3], which supports HTTP/3 amongst a bunch of other features.

NGINX's QUIC implementation seems to also lack support for QUIC and or HTTP/3 features (such as Adaptive Reordering Thresholds and marking large frames instead of closing the connection).

[1] : https://hg.nginx.org/nginx-quic

[2] : https://github.com/cloudflare/quiche

[3] : https://github.com/ZestProjects/Zestginx

EDIT: A friend of mine who works at VK ("the Russian Facebook") informed me that they're helping out with the NGINX QUIC implementation which is nice to hear, as having a company backing such work does solidify the route a little.