So of course HTTP/2 will outperform, that's what it's designed to do.
Now try again, but use one connection per thread, and connect it before you start benchmarking, i.e. use it the way it's meant to be used.
But either way, yes, that's fundamentally a benefit of being able to use HTTP. We can multiplex multiple sessions over one underlying connection.
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.
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.
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.
But you do you.
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.
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.
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.
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...
https://github.com/pion/webrtc/tree/master/examples/ice-sing... is one example of that.