Live data from Hacker News

Comparing HTTP/3 vs. HTTP/2 Performance

blog.cloudflare.com

11–20 of 84 posts

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#11

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

I think they should also have 1.1 in the benchmark results, because it's still very much in widespread use.

Personally, whenever I've experienced "this site is slow", it's either because the server is really congested or there's something else taking the time (like copious amounts of JS executing on the client); both cases in which the tiny improvements (if any) of a protocol version would have zero effect.

When you consider that there's an additional huge chunk of complexity (= bugs) added by these new protocols, for small or even negative performance improvement, it really seems like there is no value being added --- it's more of a burden on everyone except those working on it.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#12

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

Not a network engineer, but I expect TCP and UDP traffic are currently shaped differently by ISPs, possibly with preference to TCP. If your connection is solid, there isn't a huge benefit to QUIC, so you may end up seeing a slight degradation.

Syncthing uses a bunch of protocols by default to find clients, including TCP, QUIC and a few others. If you want to have some insight into how your network behaves with these protocols head-to-head, spin up syncthing and wireshark.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#13

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm…

Indeed, the part that they illustrated with Pong does show that in environments where you lose packets or have to reconnect there should be a more noticeable advantage.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#14
post #7

This does not mention if the tests also simulated and measured packet loss. With a good network connection with little packet loss, I wouldn't expect much benefit to /3. Especially since all the server and client implementations are immature and in user space without kernel support. The benefits should show up with (poor) mobile connections.

IME cellular connections don't exhibit much packet loss. The lower level layer of the mobile network usually ensures that the packets are usually eventually delivered, they just take a while. This makes sense since internet protocols are designed to interpret packet loss as congestion and will slow down transmission when it occurs.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#15
It is possible to compare HTTP/3 to HTTP/2 & HTTP/1 using Python, as Hypercorn (via aioquic for HTTP/3) supports all three.

When I compared late last year I found HTTP/3 to be noticeably slower, https://pgjones.dev/blog/early-look-at-http3-2019/ however my test was much less comprehensive than the one here.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#16
A major benefit of HTTP/3 is the ability to transparently switch from one network connection to another without restarting requests.

You could be midway through a gaming session over websocket, and walk away from your wifi, and you shouldn't notice a glitch.

Nearly nothing else offers that ability, and it's very annoying, especially in offices with hundreds of wifi access points - I should be able to walk down the corridor on a video call without glitchiness!

MPTCP (developed mostly by Apple) offers the same, but Google and Microsoft are holding it back, for some unknown reason.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#17
So I can't find the reference but I believe there was a paper a few months back claiming that there were big issues with fairness (as I understand the word) with other protocols.

The gist of it was that Quic tends to just flat out choke out TCP running on the same network paths?

Anyone know about this?

There is some mention of BBRv2 improving fairness but not the outside academic paper I was looking for -

https://datatracker.ietf.org/meeting/106/materials/slides-10...

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#18

So, as far as the results: In their synthetic benchmarks, they find negligible to no improvement: > For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s And in their closer to real world benchmarks,…

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm…

> I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions.

Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#19
post #18

Earlier quoted context omitted.

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm…

> I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?

HTTP/3 is using QUIC which is UDP based.

Re: Comparing HTTP/3 vs. HTTP/2 Performance

#20
post #18

Earlier quoted context omitted.

I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. HTTP/2 was a massive improvement on HTTP/1.2 that had some really impressive stats to back it up. HTTP/3 isn't going to have that. Being on-par with HTTP/2 in excellent conditions is expected. The little game animation backs that up - if all the data arrives in both HTTP/2 & HTTP/3 then its a wash. I'm…

> I'm certainly no network engineer, but my understanding is that HTTP/3 really shines in poor networking conditions. Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?

In theory, yes. In practice, TCP has "ossified". That is to say; all the routers and networking equipment, around the world, would have to be upgraded to support changes to TCP, which in practice will never happen. Look at IPv6 adaption rates as an example.
Post reply on HN