[mgaunard]

Multiplexing is already done for you by your kernel, it's called having multiple TCP sessions.

The whole premise of HTTP/[23] is to do the same thing as you do with N TCP sessions, but paying for the session establishment latency only once instead of N times.

And most applications couldn't care less about that latency, because you only do it once.

[mattrobenolt]

My apologies for not meeting your bar. I guess you missed the parts where it's faster in a lot of other cases too, and not slower in any.

To me, the fact that it's not slower at all is the big win. I didn't anticipate that the results of this are going to say "this is 5x better". The stereotype is that if it's over HTTP, it must be slower.

And by every measure, it's not slower. In cases, that may be edge to you, or don't care about extra latency, they're still improved. Why would you not want something that's generically better?

There are many other things that are beneficial with using HTTP as a transport that haven't even been discussed here since this was entirely focused on performance. Without at least matching in performance, not many of the other things would matter.

[mgaunard]

99% of benchmarks are wrong and lead to misleading conclusions. You didn't provide the code so it cannot be independently reviewed.

This article IMO contributes to spreading the misinformation that HTTP/[23] is useful for many applications, when it is actually a very niche protocol only useful to web browsers, or other similar applications that continuously need to connect to endpoints they don't know in advance.

Web tech has already done sufficient damage by pushing HTTP/1.1 and SSL everywhere in IT, we don't need to force those protocols onto everything.

[hardwaresofton]

Would you mind expanding on other protocols that would be better?

I personally cant think of a protocol I’d rather have go everywhere than QUIC/HTTP3.

Forced TLS is disappointing (there’s some discussion), but the upside is that this means SNI works and you can now very easily route UDP traffic via SNI.

Given the flexibility of HTTP/3 I wouldnt mind having it everywhere.

[mgaunard]

HTTP/3 is just a way to have multiple reliable connections with less latency in establishing them than with TCP.

What you can use instead is simply TCP.

TCP is simple, mature, has all kinds of support in software and hardware.

The only advantage of HTTP/3 doesn't matter to most use cases and doesn't warrant its complexity and throwing away all the networking ecosystem built on TCP.

[hardwaresofton]

Sure -- but I do value the fact that UDP + some upper layer option is better than plain TCP (essentially you can always build TCP on top of UDP but not UDP on top of TCP per-say). There's no reason that advancements in TCP cannot be "backported" to QUIC or UDP

I'd go so far as to say that it's possible TCP should always have been another layer up the stack rather than an alternative to UDP.

But coming back to concrete use cases, here's one I've been kicking around in my head lately -- it would be great to build a video calling application that relied exclusively on SFUs (so just redistributing frames, no WebRTC stuff) but only needed one port for all the traffic. It seems that HTTP/3 brings benefits to this use case, two things in particular:

- Running all off of ~one port (443/tcp or 443/udp)

- The ability to easily take advantage of a bidirectional stream with UDP semantics (I guess HTTP/2 could have done this), something we rely on WebRTC to do now.

I say this because I've felt the pain of trying to set up complicated video conferencing software and while WebRTC is awesome, it is a bit heavy weight, if you're alright with an intermediary forwarding the frames.

[EDIT]: as far as perf goes, Cloudflare has a good blog post on this: https://blog.cloudflare.com/cubic-and-hystart-support-in-qui...

[Sean-Der]

You can run all your WebRTC traffic off a single port. You use the remote 3 tuple (IP, Port, Protocol) to demux traffic.

https://github.com/pion/webrtc/tree/master/examples/ice-sing... is one example of that.

[mattrobenolt]

Check your bias. This was clearly communicated as an experiment with surprising results. In some contexts, we don't have a choice but to support HTTP. So simply wanted to see how it stood up to a traditional mysql client.

But you do you.

[mattrobenolt]

Also ever heard of gRPC? It's pretty popular and widely used. Whether you like it or not or whether it's the most optimal in theory, in practice HTTP is heavily heavily used for communicating between components.

To me, HTTP sits in a similar boat as JSON. Is it perfect? Is it good? Not necessary. But it's extremely extremely scrutinized and optimized due to its ubiquity in ways that other protocols and formats haven't been.

This was the entire point of this experiment and it's proved successful. The bias I wanted to challenge is exactly what you mentioned. Turns out, using HTTP as a transport and protobuf for encoding (which is basically gRPC) is comparable.