OpenSSL 3.2.0 released

You just don't debug anything protocol-wise with a single stream in QUIC, and that library is totally irrelevant to the rest of the ecosystem for not even being interoperable (hence testable) with anything else. Other libs such as ngtcp2 which have been there from the beginning and have adapted to their users' needs are well-tested and permit everything and much more than s_client could ever do. Even some command-line tools such as picoquicdemo are more relevant since relying on a proven and testable implementation.

> But, if they put a lot of energy into this with the idea that it would be used by others for real stuff, as part of the OpenSSL lib? Weird :).

Except they have exactly zero idea what their users want. Their users already expressed that 4.5 years ago, en masse, these people were just thanked by a middle finger. The simple fact of saying "ok we showed in 3.x how we could fail when touching stuff we have no skills on, but instead of trying to fix it we'll now switch to something completely new for us, a QUIC implementation that you don't want" is a great indicator that they have no care for their users' needs. All main HTTP implementations now have their own QUIC stack so anything that could be done by the openssl team now will just be limited to s_client and nothing else. Pure waste of time, effort, energy and trust.

> Certainly, there are major implementations that are essentially atrocious on performance if used server side (OK on the client).

Oh it's possible, but not all of them. We managed to pull 260 Gbps out of haproxy's QUIC stack (22M pkt/s both directions) on a perfectly standard Linux network stack. That's not bad at all and at least it scales well!

> Which I think is why so many cloud companies have had to go and write their own implementation.

No that's not the reason at all, the protocol was designed so that it runs entirely in userland to speed up protocol version upgrade deployments, and as such, there is no uniform API to implement it the best way for each implementation. Depending on your event model you'll use a set of totally different mechanisms and that's perfectly fine. From this point it becomes difficult to both uniformize everything and keep performance, however some of the stacks that offload all the painful stuff for you are still usable, but with some necessary overhead.

> The protocol also has a couple of places where it allows too much, meaning supporting this leads to a bit of extra complexity and (on one certain thing) a /lot/ more worst-case performance overheads, when compared to TCP.

Absolutely, and that's precisely one of the reasons why this should only be implemented by those who have enough time to grow transport-layer skills and become experts on the matter, instead of being developed as yet-another activity by a crypto team who thought they could play with a new toy (and worse, let people believe this will eventually be usable).