Well, it requires almost an order of magnitude more energy to serve HTTP/3 than HTTP/1, so maybe?

Why do I say this? Because it breaks nearly every optimization that's been made to serve content efficiently over the last 25 years (sendfile, TSO, kTLS, etc), and requires that the server's CPU touch every byte of data multiple times (rather than never, for http/1). Its basically the "what if I do everything wrong" case in my talk here: https://people.freebsd.org/~gallatin/talks/euro2022.pdf

Given enough time, it may yet get close to HTTP/1. But its still early days.

no it's more efficient in every way, they called it QUIC not SLO

Bit of a leading question since you assuming that this is "complexity bloat" and not just "a feature that people use", but yes, HTTP/3 has streams and so it should be vulnerable.

HTTP/3 is not vulnerable to this specific attack (Rapid Reset), because there it has an extra confirmation step before the sender can create a new stream.

HTTP/2 and HTTP/3 both have a limit on the number of simultaneous streams (requests) the sender may create. In HTTP/2, the sender may create a new stream immediately after sending a reset for an existing one. In HTTP/3, the receiver is responsible for extending the stream limit after a stream closes, so there is backpressure limiting how quickly the sender may create streams.

Thanks. I'm curious to see how the backpressure ends up playing out in terms of "do you need 10k boxes to DoS vs 100k vs not feasible".

> assuming that this is "complexity bloat" and not just "a feature that people use"

¿Por qué no los dos?

:)

Bloat implies that it isn't useful - that it's just dead weight.

If a lot of people use the thing, it must provide some value to them.

Well, to me "bloat" and "useful + used" are incompatible. The feature only made it into HTTP/2 because it saw validation from gRPC, I believe.