undefined | Better HN

0 pointsmgaunard3y ago0 comments

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.

0 comments

mattrobenolt3y ago

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.

mgaunardOP3y ago

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.

hardwaresofton3y ago

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.

1 more reply

mattrobenolt3y ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

mattrobenolt3y ago

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.

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?

mgaunardOP3y ago

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

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.

hardwaresofton3y ago

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.

1 more reply

mattrobenolt3y ago

But you do you.

1 more reply

j / k navigate · click thread line to collapse