Hacker News Reader

Comment by GuB-42 | Hacker News Reader

Most of the complexity actually comes from encryption. If you don't need encryption, HTTP/1.1 is great. Especially since unencrypted HTTP/2 and 3 are usually not supported.

HTTP/2 is sometimes considered a mistake.

HTTP/3 is certainly more complex than HTTP/1.1, but that's in large part because it is actually several protocols in one. It replaces TCP with QUIC and therefore implements its features. It also has encryption built-in, so it also provides some of TLS features.

It is based on UDP, but ideally it should QUIC/IP, the only reason why UDP is in the middle is to facilitate adoption.

So if you consider HTTP/3 with builtin TLS vs HTTP/1.1+TLS+TCP, I don't think there is much of a difference in complexity.

View on HN

It's more complex for server builders and client library builders (libcurl, netty, etc.). For web application developers, it's essentially zero effort if you use decent cloud based hosting.

We have our stuff in Google cloud. I just launched a website (while spaceX was launching a rocket) there. Simple bucket behind our load balancer. It serves http3 if your browser can handle it. If you check with curl (which can't) it falls back to http2. Our API runs there as well and a few other things. Just works. It's not even a configuration option. It's just part of the package.

Most of this stuff is either necessary complexity or useful complexity. Running without TLS is not really something you should be doing over a public network. And some people would argue even on a private network. So that's necessary complexity.

UDP vs. TCP is a no-brainer as well for mobile and roaming type use cases. Just a lot easier to deal with via UDP. With TCP you have to deal with connections timing out, connection overhead, etc. With UDP, which is connection less, switching networks is a lot less dramatic.

And then there's the notion of not needing multiple connections to download/stream multiple things. Since UDP has no connections, HTTP3 multiplexes it's own notion of "connections" on top of that. So, you are not constrained by browsers limiting you to just 4 or 8 connections per website (or whatever the number is these days). A bit more complex to implement but useful.

Then HTTP[23] are significantly more costly to implement, they are a mistake then.

Nothing to brag about then.

I don't really see how one leads to another, could you elaborate? Looking at these protocols, it seems to me that later versions of HTTP attempt to address errors resulting from the overly simplistic design of HTTP/1.1.

That's a pretty silly take. You're basically asserting that implementation difficulty is always the main priority, and there can never be any worthwhile tradeoffs that could offset that complexity.

But in reality, the world probably only needs a few dozen H3 implementations, just like there are only tens of production TCP stacks. But those implementations will be used by billions of people, hundreds of billions of machines, and handle effectively all data transmission of the entire humanity.

The leverage is massive, even the most minor improvements will be able to pay off any level of engineering effort.

Enter IPv6. Same arguments, it's 'only' a matter of implementation. 30 years later still most of the implementations are worse than IPv4.

At least IPv6 is reasonably scaled for our world which IPv4 was never meant to be (The abomination of NAT).

TLS is more costly to implement than simply not encrypting or signing anything.

Sometimes cost of implementation isn't the only consideration.

We should have stayed in Gopher.

Even HTTP1.0 is fairly enough and dead simple to implement.

Usually, just a bunch of planned obsolescence fan boys.

Reply on news.ycombinator.com