> This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and l

> This is why I'm not a big fan of HTTP/3. It's a attempt to get about 10% more performance in the good case, at the cost of considerable extra complexity and less immunity to gaming the system. To be clear, are you mainly complaining about the multiple streams aspect here, or do you have other concerns? Because while I'm no expert, using HTTP/3 (or QUIC, I'm ignoring the terminology differences here to avoid confusion with pre-standard QUIC, though I guess maybe we're past that point by now?) with just a single stream seems to be the only scalable solution to a certain problem. The main problem I've had with TCP is that anybody can maliciously inject an RST, and for long-lived active connections, the chances of this happening approach 1. If you control both ends you can just tell your firewall to drop all RST packets so the applications can keep talking to each other, but ... Dealing with this at the application layer is ... marginally possible I guess, but not easy unless your application looks a lot like a web browser (and even those tend to usually force the end user to manually fix it). Creating a new TCP connection sucks and you have no idea how much data got dropped after it left the application's buffer. So we need a UDP reliability layer, since that's the only other general-purpose protocol that actually gets routed (and SCTP is flawed anyway). And dozens of those exist ... but almost none have major use, so I can't trust that they will play nice with the wider internet. With HTTP/3, if there are major flaws found, I have confidence that - like TCP - it has enough users that someone will come up with an acceptable solution. (admittedly, since it's not part of the kernel it will be harder to actually deploy the fix) (I guess TCP-over-VPN is also viable for some users)