This paper from 2017 showed QUIC performance was poor: https://arxiv.org/pdf/2310.09423.pdf
With no evidence to the opposite, the article's claim that QUIC is displacing TCP for speed is dubious at best.
This paper from 2017 showed QUIC performance was poor: https://arxiv.org/pdf/2310.09423.pdf
With no evidence to the opposite, the article's claim that QUIC is displacing TCP for speed is dubious at best.
* The version of Caddy used for the test was missing several recent updates that significantly improve its performance. * Performance improvements for QUIC have always been about removing/recovering from dynamic network connections, and are about running connections at scale. Simple HTTP 1 requests in environments where there are far less shenanigans going on will always be fast. (lib)curl powered requests being single threaded requesting across the local network stack are not representative of the types of performance gains to expect in an HTTP/3 world.
Perfect, lossless, zero-delay networks are of no interest when evaluating protocols. Under those conditions literally any protocol can do the job. The exercise only becomes interesting in the real world where delay and loss exist.