3 ms·

Does HTTP/3 suffer from this kind of complexity bloat?

• insanitybit 3y ago
  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.
  • throw0101c 3y ago
    > assuming that this is "complexity bloat" and not just "a feature that people use" ¿Por qué no los dos? :)
    • insanitybit 3y ago
      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.
    • sophacles 3y ago
      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.
  • neild 3y ago
    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.
    • insanitybit 3y ago
      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".
• drewg123 3y ago
  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 https://people.freebsd.org/~gallatin/talks/euro2022.pdf Given enough time, it may yet get close to HTTP/1. But its still early days.
  • juped 3y ago
    no it's more efficient in every way, they called it QUIC not SLO
    • giantrobot 3y ago
      That's why they don't have data centers in San Luis Obispo.