Hacker News Reader

Comment by hl05 | Hacker News Reader

Do we need HTTP/3?

We don't need anything. Like any technology it has pros and cons. The pro side being it improves performance for users with certain network conditions.

For unreliable networks we do need it. TCP has always performed poorly when there is a lot of packet loss.

My personal opinion would prefer to improve those networks vs going UDP for http(s). Until spoofing, amplification attacks on UDP are properly tackled and not causing most internet outages, I'm not really looking forward to a UDP web (http/3)

Does http3 have a problem with amplification on the first answer packet?

I'm not sure spoofing is something transport protocols have to solve though. Authenticated bgp and source filtering is the layer for it and we needed it for decades already.

If I remember the amplification is about 3x, you need acks for the server to send more than that.

> Until spoofing, amplification attacks on UDP are properly tackled

This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.

Wasn’t that the whole reason behind improved congestion algorithms like bbr which no longer assumed minor packet loss was the sign of congestion?

That all depends on the congestion control algorithm. Different implementations of TCP can use different algorithms while still being compatible. The same is true of QUIC.

The recently published QUIC standard specifies a tweaked version of TCP NewReno. See https://www.rfc-editor.org/rfc/rfc9002.txt and https://datatracker.ietf.org/doc/html/rfc6582 But AFAIU this is not the algorithm Google itself uses for QUIC, nor the one they used for their famous benchmarks showing latency improvements on mobile.

To derive maximum benefit (or even just most of the benefit) of a tailored congestion control algorithm, you'll want to control both sides, keeping them in sync as you iterate improvements and changes. And maintain different flavors for different application environments. Only huge companies like Google and Facebook will be able to do this effectively.

QUIC does have more than just different congestion control For example it has forward error correction which can be very important for lossy connections.

There are other improvements that can't really be added to TCP either such as roaming between IP addresses. (MPTCP exists but IIUC requires make-before-break which is not always possible).

I have the opinion that we don't need anything past HTTP/1.1 on 3G internet. Anything better is a luxury which is not necessary. But that's my threshold of comfort.

How long does it take to fully load the average web page over 3G?

I don't know about average web pages, but websites that I use regularly are loading quite fast. 3G in my village is something around 10 Mbits/s, youtube is absolutely fine, for example.

PS may be it's not strictly 3G, but it's displayed as 3G on my phone.

According to Google, 3G is generally limited to 3Mbps in practice (7Mbps in theory) so I think you might be getting lucky

You would be right if 3G didn't jump down to 2G randomly, 4G does not have this flaw, 5G is meaningless.

HTTP/1.1 is the final transport for humanity, but you need fiber (external IP, preferably static, but operators/governements are not helping) to sell something.

HTTP/2 has head of line blocking issue.

HTTP/3 wont become a standard outside of biased actors like Google.

Http3 works or will work soon in major browsers and cdn's. It will cary a large chunk of internet traffic.

A lot of the world has killed off 2G (e.g. in Australia it all got shut down 3–5 years ago), and it’s on the chopping block in a lot of the rest of the world (e.g. looks like the remaining 2G services in the USA goes EOL by the end of next year). 3G is also already on the chopping block in many places (e.g. looks like next year in the USA, and in Australia its spectrum has steadily been being reallocated in recent years, and the biggest telco is scheduled to kill it altogether in 2024). Fortunately after that it’s designed in compatible ways, so 4G and 5G and whatever comes after that can all coexist.

For the HTTP versions, I’d put it more this way:

HTTP/1.1 is the baseline that will continue to work forever.

HTTP/2 is normally a significant improvement over HTTP/1.1, but it has one crucial flaw which makes it worse than the alternative of half a dozen HTTP/1.1 connections on connections with high packet loss.

HTTP/3 is the best of both worlds, roundly better than HTTP/1 and HTTP/2, but because it’s using UDP, it’ll have some teething issues for a few years because of badly-configured corporate equipment. But it will become widely supported in server software—there’s no reason for it not to.

I think most reasons for sequels is that people need something to do, HTTP/1.1 works for everything but people needs to feel they can improve things.

Unfortunately everything peaks because of physics and energy.

I'm not adding HTTP/2 or 3 to my HTTP app. server; HTTP/1.1 does everything I'll ever need and I have to focus on other things!

You're probably not serving millions of users every day though.

Btw, most production setups don't really have to do anything to support it, as pretty much all load balancers already do. And there isn't any big performance gain if it's only intranet traffic.

Luxury! Back in my time we had to wait for the mailman to bring us our webpages on printed out paper! That we had to read by the light of candles which we had to make ourselves! These young kids with their fancy "HTTP is a requirement" mindset.

/s of course. But what a wonderfully arbitrary threshold to set it at 3G+HTTP/1.1 :)

No... it is just a nice to have for some large sites. For most HTTP/1.1 is still good enough

The google thinks so.

Reply on news.ycombinator.com