Avoiding HTTP/3 (for a while) as a pragmatic default
utcc.utoronto.ca
utcc.utoronto.ca
They've set up an incredibly restrictive systems of firewalls and networks, making it super hard for themselves to upgrade their own network or adapt to the world around them.
Then they write a big post about how much work allowing UDP/443 through their network supposedly is, proving that they not only already blocked tons of legitimate traffic (OpenVPN over 443 is super common) but also that apparently their setup is set up in a way that's impossible for them to manage.
They're running some kind of firewall system that's analysing people's traffic and they're afraid HTTP/3 will put a stop to that. That means either their tooling isn't maintained well enough or they employ some kind of sketchy trickery to get the older protocols to play "nice" with their data collection.
They implore others to please stick to the protocols of the past so they don't need to change their network in the future.
This university acts like the worst ISP imaginable. Who even uses a whitelist for outgoing ports anymore? Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need. If I were a student or an employee there, I would make sure that every single but leaving my devices is going through some kind of encrypted VPN, though I'm sure they'll try their hardest to block that too. Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
When HTTP/3 hits the common software packages, I'll be turning it on on all of my services purely out of spite against institutions and companies like this. If your network can't deal with industry standards, it deserves all the shame and support tickets it'll generate.
All of this is of course academic until Ubuntu's version of Apache supports HTTP/3. We're quite unlikely to switch web servers to get HTTP/3
They're worried some of their users will be in environments that don't properly support QUIC, and if they started serving HTTP/3 today they might have more support hassle.
Their network is somehow horribly broken and that leads them to pain a picture as if the protocol is somehow inherently stable or problematic to turn on. They're projecting their own misconfiguration onto the wider internet as a whole, and this is exactly the kind of behaviour that has led to the protocol ossification we see today.
I think that post is much less reasonable, but it's also almost 2 years old and they may not be doing that kind of blocking anymore?
Personally, I'd much rather have seen SCTP get picked up than QUIC for solving the HTTP/3 problem, but we need to wrap modern protocols in 1980's UDP or risk networks dropping the traffic for no good reason. TLS 1.3 had to be written in a specific way to look like TLS 1.2 or middleboxes everywhere would throw a fit.
Some old protocols used are used because they Just Work, (most of) NTP is a clear demonstration of that. However, many other protocols are still in use simply because rolling out alternatives isn't feasible.
You should probably spend some time understanding these environments before giving in to such hostility for your peers.
I've spent most of the last 20 years supporting users and systems in higher education environments. Universities are class environments, research facilities, mid size enterprises and residential environments ALL IN ONE. I'm sure there are some with open positions if you're willing take a shot at supporting all of that with a budget that covers less and less every year. Good luck staying at the forefront of technology.
However, as an institution, the university should still remain at the forefront. Whether their network can't keep up because of a lack of funding, bad management decisions, or other factors doesn't really matter.
These tickets and questions aren't punishment for bad management, they're a signal that an overhaul (and the accompanying funding) is necessary. Migration plans need to be made, plans need to be written down, a lot of work is going to need doing, and without any signals that the system can't keep up you're not going to get anyone to sign off on such grandiose plans.
Maybe that won't be enough, maybe the network is doomed to survive only by constant patching and emergency fixes until the staff is driven mad and quits, but that's no reason for others to slow down the rollout of modern network protocols.
Network management is there for a purpose, and the people focusing on bypassing it are generally bad actors. The authors of HTTP/2 and HTTP/3 are more focused on guaranteeing delivery of ads than being able to block malicious activity.
I don't follow your reasoning. So you have the ability to block QUIC, but declare QUIC to be a "bad actor" trying to bypass your network management?
They switched from TCP to QUIC base, what can be done over HTTP3 can also be done over HTTP2.
From the POV of the network it is much more similar to a UDP VPN than to HTTPS over TCP
I fully support user choice to disable whatever protocol they want. I also think modern browsers lack options in this department. If you dislike QUIC, which I can completely understand, you should disable it.
On the server side, though, you can use modern servers and tell all your clients to stick with HTTP 1.1. Let the people who do like QUIC (or don't care) get the benefit of faster page loads and lower latency. HTTP/2 and HTTP/3 solve some real performance issues, particularly for users with unstable or slow internet connections. I don't see why would would deprive them of that simply because you prefer to have the protocol disabled.
But networks often block them for security reasons, and it's their network and prerogative to do it as a condition to use the network.
> Block whatever stupid protocols Windows uses for file sharing so you don't leak your credentials, that's all the outgoing filtering you need.
It's clear that you've never managed networks that need to meet stringent security requirements.
> Universities are research facilities, they're supposed to be at the forefront of technology, not run into service issues because their policies are frozen in the late 90s.
It's also clear that you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
Yeah both of those problems are solved or alleviated with tooling but it can take years to get all the disparate systems managed in house.
This isn't the first post the author has made about their university's network infrastructure. The HTTP/3 issues start being named years back.
The university, as an organisation, doesn't seem to want to move away from the old way of doing networking. There's no indication this is a "we have to hotfix it for now because our new systems are done in 2030" network, and every indication that they're stretching their current design for as long as it'll hold.
Even if they're doing this for security reasons, the days of unsecured bastions with a strict firewall around them, as suggested by their latest infrastructure blog post, are long gone. I highly doubt security is the reason the university can't move on.
With no migration plans as far as I can see, they're setting themselves up for failure again when HTTP/4 inevitably comes around, or when strict networking peculiarities cause the next QUIC/HTTP3/TLS 1.3 bug the author will have to dive into and figure out.
That need to meet overreaching legal compliance requirements, maybe, but this isn't the same as security.
> you've never worked on infrastructure in a large heterogenous environment that grew organically over decades. Or dealt with infrastructure that was grant funded.
I should hope you don't need to be an outsider/inexperienced to point out obvious dysfunction. Yes, said dysfunction almost always has very explainable context and causes (organic growth over decades, inconsistent/dependent funding structures, etc.) but neither negate the fact that it is a form of dysfunction, nor should they put it beyond criticism (from inside or out).
Just because some guys out west had an idea and therefore it's the "new thing" doesn't mean that it the right thing for everyone.
I’d love to have more rigorous analysis of what tricks are pulled, and how those can be addressed from first principles. I’ve yet to see such a take, but that’s understandable, because all this institutional knowledge is spread across segmented information islands.
I was just lamenting a couple days ago about the email templates written in tables and HTML4 Transitional. It’s 2023, wtf.
https://demo.react.email/preview/nike-receipt doesn't seem that bad
Inline styling and tables, instead of semantic HTML5 and a style block.
This blog post itself served from HTTP/1.1 and IPv4 for me.
I guess the improving internet is handed over to the big companies who benefit them.
They have no incentive to hold backward compatibility and putting smaller websites offline
HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.
I'm saying that there is no way for me to distribute and install my custom CA into the browsers of every random person around the globe that will try to visit my website on software defined radio.
I've self-signed my website(s) for 20 years now. In the past it did not matter. But over the last few years I've noticed that actual browser connections are disappearing and all that's left is http bots. They're the only HTTP clients not failing to load my page because of $browsers HTTPS only configuration causing them to see my self-signed cert and thus the browser scaremongering about it causing them to close the tab. HTTP/1.1 going away will be the death of the personal website.
Really? Are you sure about that? I'd love to believe you as it'd mean there's been progress on this front but the last time I checked it required compile time flags in Chrome and Firefox. The problem is that this is a function of the libraries these browsers use, it's not an option that is within the browser itself.
>removing easy ways for end users to do insecure things.
That's a legit pov as long as you think about browsers as in the for-profit way: as insecure virtual machines for customers to run your untrusted third party code. And that's certainly the zeitgeist. But that's not what the web is to many human people.
The web of documents still exists despite the last decade of the web just being a mechanism to distribute JS applications. I know that the for-profit point of view doesn't care about the web of documents (not profitable) but that doesn't make their use case the only use case. All you have to do to make accepting self-signed certs as secure (or more secure) than the "normal" web is to turn off automatic execution of untrusted code sent to you. I'd wager that a good fraction of the HN userbase already does this with their NoScript or uBlock or whatever anti-javascript protection extensions.
And in this particular exact scenario, you can use my .onion site for superkuh.com to verify the end-point identity if you're really worried that someone might change the text. A system that works without CAs.
Among other things a MitM can:
- insert ads in your page
- run miners on your user's browser
- change links or redirect the page (likely to an CA-signed malware site)
- insert malware in downloadable scripts on your site (http://superkuh.com/TkTTS.pl)
Software\Policies\Google\Chrome,SSLErrorOverrideAllowed,REG_DWORD,1
The thing I wonder: will this prevent Internet of Sh*t devices to spread or will they become fully reliant on cloud, thus dependent on the vendor (as the customer's browser won't talk to it)
How does requiring HTTPS turn into no more personal websites? Let's Encrypt offers free certificates with automated renewal and minimal hassle, and if you don't like them there are several free alternatives.
The second is more abstract but notice how literally everyone in this thread is recommending LetsEncrypt. That's great, and I love LE and I'm really glad they exist. But this is literally putting all our eggs in one basket. The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites. Like, say, a website for an abortion clinic that is now against the law in Texas. Switching to comodo when this happens won't fix it.
Web serving has always had moving parts, and there has always been some maintenance required to keep sites up. I agree that HTTPS increases the burden here, but not from zero.
> at some point that complex stack of software (who's complexity is hidden from the user) will break
Sort of? People definitely screw up their HTTPS configuration from time to time, or run into bugs. But the acme software is very reliable, so this is rare, and if it does happen blowing your existing configuration away and starting fresh will fix it.
> And not only does it make them more fragile but it makes setting up a website for the first time much more complex.
If you want to set up a website with minimal steps you generally get someone else to host, at which point they are dealing with HTTPS. If you want to do it all yourself HTTPS does add a step, but it is small compared to all of the other steps involved in setting up a server.
> The increased centralization will inevitably lead to increased pressures, social, political, and otherwise on LE to censor, revoke permission, or otherwise cancel the accounts of law breaking websites.
The US legal system cannot currently compel Let's Encrypt to refuse service to lawbreaking sites, and even if the law changed here you could get a certificate from a CA in another country.
And you do understand the reason why having browsers verify that they're actually talking to who they think they're talking to is important, right?
HTTP/3 would break this.
These are very different. If need to convince your audience to get and install some alternate client with an alternate protocol, now you audience it at best only a few techies who can do that for themselves.
Whereas sending anyone an URL they can click on with any client, even if it identified by an IP address instead of a hostname, is as easy at it gets.
Let's Encrypt is awesome, I use them for all my personal sites (web and non).
Threat modeling covers more than just authenticity and confidentiality. For instance, denial of service is also something to evaluate. So why does this matter?
Today if Let's Encrypt suddenly disappears or goes evil and no longer wants to issue me a certificate, I can simply re-enable plan HTTP on my site and my content remains available. Sure there are drawbacks but there are pros and cons to everything. As a static site I'm comfortable with the cons of hosting it via HTTP if the only alternative is not being able to host at all. Important things is I can make that choice.
In a world where normal people (i.e. non-techies who can't be expected to build their own browsers from source or whatever) can only have access to a client that enforces public CA issued certificates, it becomes easier than ever to drop unwelcome people effectively off the internet.
HTTPS only, CA TLS only, leads to websites with lifetimes that max out around several years. This is fine for corporate/institutions as nothing of theirs lasts this long anyway. But it's a huge problem with personal sites which remain useful and valuable for longer time periods.
I can find some references to Chrome's QUIC not supporting self signed certificates, but I can't find any source that says that WebKit and Firefox made the same decision. Do you happen to know a self signed HTTP/3 URL that I can test this with?
Browsers choosing to break self signed certificates can happen even with HTTP 0.9. All they need to do is require the user to type the bypass phrase ("thisisunsafe" in the Chrome error screen) on any certificate validation error and enable HTTPS only mode. This has nothing to do with spec. Browsers have even removed spec implementations for HTTP/2 spec (HTTP push) after a few years.
IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension.
IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.
[1] https://github.com/ipfs/kubo.
Reaching http3 servers outside those networks is indeed not a problem as the connection gets downgraded appropriately. You'd know this when Google, for example, stops working inside your network as most of their load balancers are serving http3. Users tend to complain about these things and this obviously hasn't been happening. Ergo, connections are being downgraded as you'd expect.
But putting up webservers serving http3 in a network that blocks udp3 is indeed not going to work until somebody fixes the firewall. You could still do it and test if browsers from outside the network downgrade correctly. But that seems a bit pointless.
Would be interesting to see how many will requests get downgraded or not over a long period of time.
Therefore, to reduce pain, it should be inflicted often.
Especially in mobile setups, which are the primary target of QUIC with resumable sessions.
Corporate networks are not the Internet.
>since HTTP/3 is the newer and less common version, it's the version most likely to not work.
Which means those clients will end up using HTTP/2.
>I'm also uncertain about how much HTTP/3 usage there is among the big players like Google, Cloudflare, and so on
Google and Cloudflare have had it for years. Other big players have adopted it too.
But at least it just works for everything I have thrown to it.
If everything would be implemented like this, next time leftpad should be a web service on my machine as well?
Basically all I know is:
- Updated from Caddy 2.5.1 to 2.6.2.
- Customer reported video was buffering endlessly.
- Downgraded Caddy to 2.5.1.
- Issue resolved.
But I can file an issue like that if you think it would be helpful.
Organizations who are not doing this are not adequately managing their network.
Your basic test case of a web browser being able to do ChaCha-HTTP/2-only is simply to visit https://egbert.net/ and successfully get a web page.
An interesting usage from Wikimedia: https://www.usenix.org/sites/default/files/conference/protec...
Shame about the minimum MTU otherwise it’d be perfect
Neither are particularly useful unless you're a web browser. I'm sticking to HTTP/1.1 myself in all of my code.
Funnily enough most engineers don't seem to have any idea how TCP works these days.
> HTTP/2 is bad because XYZ, HTTP 3 at least fixes Z
Note giving reasons, and preferably also reasoning behind those reasons. You know, the "arguments"
Here is what clown riding that dunning-kruger peak thinks that "argument" is:
> HTTP/2 is just plain silly, HTTP/3 is a silly idea but implemented correctly.
We also plan to closer evaluate HTTP/3 (h3) soon, mainly to see how the promised improvements, like no head of line blocking, turn out in practice for our use case.
So I'd disagree that h2 or h3 is useless "unless you're a web browser"; but sure if you use HTTP only to provide a simple text (e.g., JSON) based API it might not be _that_ relevant. But some benefits like faster TLS setup might even make a difference there, e.g., faster initial startup, fewer packets transmitted, IIRC even packet sniffing should be a bit harder to do with h3. If those benefits are worth it on its own, depends then probably on how easy it's to integrate in your project, iow., if your framework/standard lib/ecosystem/... already supports h3 nicely. We use the rust hyper crate for most of our HTTP* communication, and their h3 implementation is still marked as experimental; and as we're not in a rush we'll just wait until the hyper project stabilizes h3.
What HTTP 2 does is that it makes it possible to send multiple responses in parallel instead of one after each other.
Chunked transfer isn't the issue, I know that would be easily dooable with h1.1, but it would be one serialized & sync stream.
All you're doing is reducing the latency of the first request.
But yeah on package loss there's head of line blocking, which http 3 solves by using UDP and handling the reliability on the higher level.
Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients). The rate at which it can write doesn't magically increase by attempting to write multiple streams concurrently; quite the opposite. The rate is controlled by the other end, and what you should do if you implement a high-performance TCP service (HTTP or not) is simply disconnect clients that require you to ever block.
Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely). Queues in general are serious business and require a careful design to ensure the producer doesn't produce data faster than the consumer, with adequate back-pressure algorithms. It is better to keep track of when you can write and decide on how to handle not being able to write rather than block or queue like an idiot.
Multiplexing with HTTP/2 logically makes the TCP stream which is logically a spsc queue into a pseudo-mpsc queue. Those are also way more difficult to reason about to guarantee fairness and back-pressure, they're pretty much a bottleneck by design. It's just a bad idea any way you look at it.
> TCP must send all data in order. To implement that, all data sent out gets written to a retransmit buffer (which may be dynamically sized, but only up to a maximum).
To a send buffer, at least that's what most TCP implementation name it and with modern surprisingly high reliable networks it's mostly used for that. But yes, again (3rd time now), this is head-of-line blocking which HTTP/3 would solve (and which you also classified as being just useful for web browsers, whatever that even means).
More important, yes while TCP is in-order and if the network is slow and/or drops a lot of packets you will notice that, BUT it can batch multiple HTTP requests into single TCP package and that's why an async concurrent or even parallel application can benefit from using it directly.
> Your thread is spending its time waiting for the other end to ack before it can send more data, delaying any other kind of work your thread has to do (such as serving other clients).
No it doesn't, as we are fully async on all layers with rust's zero-cost async model, e.g. using the async tokio rust crate, it can just continue to handle other requests.
Also, what would change here by using HTTP/1.1? It has the same limitations as it also uses TCP, but additionally can't batch multiple requests into single TCP packets is text based (bad for binary data) and has additional down sites - e.g., slow on start up.
> Now you could say, "I don't care, I write the data asynchronously". Asynchronous writes are very bad and an anti-pattern, they should typically never be used because they mean you are just queueing data indefinitely until it is eventually written, wasting massive amounts of RAM (if not taking the machine down entirely).
Note that 1) we're talking mostly about reads here, and 2) async writes where never that bad and especially nowadays we're not in the spinning-rust-HDDs-only era anymore, so I'd recommend getting that rather dated and never quite right view updated. How would async writes even take down a machine? The kernel just uses the scheduler (or none for NVMes as they have massive amounts of queues and queue depths and can do that themselves) to reorder them in-flight and commit them, once there's to many, your write OPs will block (i.e., unsurprisingly the kernel doesn't allow every unprivileged process to just take down a machine by triggering some async writes) now with a sync model that means the thread is blocked, with async I can just do something else.
> It's just a bad idea any way you look at it.
Nope, not in our experience; and we heavily evaluated that back when adopting our current design. But happy to be actually proved wrong, just prototype the fully async multiplexing on top of HTTP/1.1 and let's see if it's faster. You can either check against our Proxmox Backup Server project directly; it has a benchmark that among other things checks the pure HTTP streaming bandwidth, but we also have a few (a bit dusted) example programs from the very early evaluation time:
https://git.proxmox.com/?p=proxmox-backup.git;a=tree;f=examp...
the initial response headers can arrive as fast as you like, but the body can be streamed, which can have potentially infinite data, and take potentially infinite time, and it can't be interrupted without terminating the connection altogether
(before you say it: streaming response bodies are in no way abnormal, and can't be dismissed as irrelevant)
as http/1 serializes requests over connections (even with chunking or whatever else) clients cannot in general re-use connections for independent requests for this reason (and others)
if a client makes request A at t=1 and request B at t=2, and request A creates an unbounded length SSE response that lasts until t=999, request B should not need to wait until t=1000 to begin, yet this is what http/1 requires
You can switch to raw socket and do the TCP syn/ack dance on your own but this is mostly done for network testing/pen testing, as there are more overhead involved, not less.
This is mostly because the OS actually controls the send/receive buffers used by the actual network drivers. The userland program just takes care of filling these buffers and the kernel and drivers take care of emptying them (i.e. sending). TCP flow control is handled by the kernel, freeing the app to focus on its data. This abstraction actually works quite well.
There are frameworks for userland network stacks, when you're working in high performance networking and need to avoid any overhead the kernel could introduce. The drawback is you need to implement the entire stack, including the low level driver, otherwise it would be slower than what you can already do with classic sockets.
Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to cram SCTP in there[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.
[1] https://datatracker.ietf.org/doc/html/rfc6458
[2] https://quiche.googlesource.com/quiche
most often, it helps when there are multiple logical connections muxed over a single physical connection
In real life, browsers open up to four to six HTTP 1.1 connections and maintain them for pipelining. You can increase that number to pretty much anything and enjoy a web full of "permission denied" pages, timeouts and IP bans. I did that for a while when I followed one of those "how to make Firefox faster" guides as a kid, cannot recommend.
That's also four to six three way handshakes, each taking several hundred milliseconds to complete with a risk of failure and retrying, most of which are pretty meaningless, with a hard limit on the amount of individual files one can request at the same time. You'll also have to deal with the traffic congestion engine kicking in multiple times when the WiFi connection degrades. There's also no real way to bypass the TCP slow start for every connection, so you'd better have an excellent connection available or you're artificially restricting your throughput when those streams suddenly start delivering data.
The inline mixing of HTTP/2 removes a whole bunch of restrictions. There are still a bunch of restrictions that only got fixed in HTTP/3 but there's no doubt that HTTP connections improved when HTTP/2 came about.
request-per-connection is a nice, simple, but ultimately naïve model for network communication
All a connection is doing is managing the state of a given byte stream, keeping track of how much was sent on one end and received on the other end. All the packets for all connections go through the same pipes and are even routed the same. The TCP stack sees an IP packet coming in, and in its IP and TCP headers it sees it's from IP:port, so it maps it to the state it is maintaining for that source.
HTTP/3 is using UDP, which is inherently connectionless, but is implementing its own logic of multiple streams/connections. It is not doing anything sensibly different.
"the state it is maintaining for that source" is the "discrete" thing I'm referring to
creating that state requires at least one network round-trip to the remote, and incurs non-negligible costs on the local machine in the application, network, system, and kernel layers
those costs define a per-connection overhead which are almost immediately the main performance bottleneck in systems that do connection-per-request
those costs amortize to zero if you multiplex requests over a single connection
Http/1 Keep-Alive was one the earliest protocol performance improvement. It meant the TCP connection could be reused for the next resource, avoiding the overhead if closing and reopening a new connection for every request to the same server.
You can see http/2 multiplexing as a natural evolution to the keep alive. Instead of doing every request sequentially, just send everything you need at once and let the server figure out in which order to process everything.
Concurrent TCP connections do have an impact on all stateful firewalls in your path, stateful load balancers and of course the server itself. A client that opens dozens of simultaneous TCP to request all the resources on a page all at once would be frowned upon, and quickly hit rate-limits and anti-abuse protections. You can call it ossification of protocols but that is the situation even google could not workaround when specifying http/2 and then quic.
Probably they are referring to head of line blocking: https://en.wikipedia.org/wiki/Head-of-line_blocking
But I suppose it's common for web people to have no idea how networking actually works.
https://web.dev/performance-http2/
With HTTP/1.x, if the client wants to make multiple
parallel requests to improve performance, then multiple TCP
connections must be used (see Using Multiple TCP
Connections ). This behavior is a direct consequence of the
HTTP/1.x delivery model, which ensures that only one
response can be delivered at a time (response queuing) per
connection. Worse, this also results in head-of-line
blocking and inefficient use of the underlying TCP
connection.
The new binary framing layer in HTTP/2 removes these
limitations, and enables full request and response
multiplexing, by allowing the client and server to break
down an HTTP message into independent frames, interleave
them, and then reassemble them on the other end.
As it says in the thing you quoted, the correct approach is to use multiple TCP connections.
The only advantage of HTTP/3 over that is that it only pays for the latency overhead of connection establishment once instead of once per stream. This is a very small optimization that is only relevant in a very narrow set of cases.
making 10 concurrent HTTP GET requests to the same server should not require you to make 10 connections to that server
muxing multiple logical connections/streams over a single physical connection is, like, networking 101 type stuff
you're out of your element donny, go home
there's plenty to criticize about HTTP/2 and HTTP/3 but they're definitely beneficial in many circumstances