[BitPirate]

The performance difference between H1/H2 and H3 in this test doesn't really surprise me. The obvious part is the highly optimised TCP stack. But I fear that the benchmark setup itself might be a bit flawed.

The biggest factor is the caddy version used for the benchmark. The quic-go library in caddy v2.6.2 lacks GSO support, which is crucial to avoid high syscall overhead.

The quic-go version in caddy v2.6.2 also doesn't adjust UDP buffer sizes.

The other thing that's not clear from the blog post is the network path used. Running the benchmark over loopback only would give TCP-based protocols an advantage if the QUIC library doesn't support MTU discovery.

[Etheryte]

I don't think taking shots at the Caddy version being not the latest is a fair criticism to be honest. Version 2.6.2 was released roughly three months ago, so it's not like we're talking about anything severely outdated, most servers you run into in the wild will be running something older than that.

[zamadatix]

I think you mixed up what year we're now :). Caddy 2.6.2 October 13, 2022 so it's been not 3 but 15 months since release.

Even more relevantly, HTTP/3 was first supported out of the box in 2.6.0 - released Sep 20, 2022. Even if 2.6.2 had been just 3 months old that it's from the first 22 days of having HTTP/3 support out of the box instead of the versions from the following 3 months would definitely be relevant criticism to note.

https://github.com/caddyserver/caddy/releases?page=2

[francislavoie]

This is why I'm not a fan of debian. (I assume OP got that version from debian because I can't think of any other reason they wouldn't have used latest.) They packaged Caddy, but they never update at the rate we would reasonably expect. So users who don't pay attention to the version number have a significantly worse product than is currently available.

We have our own apt repo which always has the latest version: https://caddyserver.com/docs/install#debian-ubuntu-raspbian

[diggan]

Stable/tested but not latest version. Or unstable/untested but latest version. Chose one.

The distribution you chose, also makes you make that choice. If you're using Debian Stable, it's because your prefer stable in favor of latest. If you use Debian Testing/Unstable, you favor latest versions before stable ones.

Can't really blame Debian as they even have two different versions, for the folks who want to make the explicit decision.

[francislavoie]

I don't call an old version with known bugs to be "stable/tested". No actual fixes from upstream are being applied to the debian version. There are known CVEs that are unpatched in that version, and it performs worse. There's really no reason at all to use such an old version. The only patches debian applied are the removal of features they decided they don't like and don't want packaged. That's it.

[diggan]

By that definition, almost no software in Debian could be called "stable", as most software has at least one known bug.

When people talk about "stableness" and distributions, we're usually referring to the stableness of interfaces offered by the distribution together with the package.

> There's really no reason at all to use such an old version

Sometimes though, there is. And for those people, they can use the distribution they wish. If you want to get the latest versions via a package repository, use a package repository that fits with what you want.

But you cannot dictate what others need or want. That's why there is a choice in the first place.

[csande17]

Do you have an example of a CVE affecting Caddy that's not patched in Debian? In my experience they've been pretty responsive to security reports, including in the "long tail" of obscure / buggy packages.

For example, in December they noticed this CVE and determined it didn't apply to them because it was in one of the features they removed from Caddy: https://security-tracker.debian.org/tracker/CVE-2023-50463

[Etheryte]

Oh, right you are, somehow I completely mixed that up. Thanks for clarifying.