Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing HTTP/3 vs. HTTP/2 Performance

blog.cloudflare.com

Post reply on HN
Print view View original

51–60 of 84 posts

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

#51

Post by ldng »

Androider wrote: post #36
ComputerGuru wrote: post #34

Earlier quoted context omitted.

This is called WiFi handoff and any enterprise AP deployment worth a damn should have this sorted out, albeit in a proprietary manner. The WiFi standard already has a client establishing a connection to a new AP before giving up the old one at the actual “physical” transport layer, these proprietary extensions exchange existing connection state information over the wired backbone between APs when a client is attempti…

Presumably HTTP/3 could do WiFi-> 4G -> WiFi -> 5G -> WiFi... hand-offs as you're moving around.

Genuinely asking, is it actually working or is that like the promises of multiplexing in HTTP/2 that don't really work IRL ?

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

#52

Post by mcguire »

rixed wrote: post #48
ATsch wrote: post #28

Earlier quoted context omitted.

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible. In TCP, a connection is uniquely identified by the following tuple: (src ip, src port, dst ip, dst port) The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever k…

Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is att…

Each Ethernet interface has a unique address; using them is widely regarded as a privacy violation.

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

#53

Post by mcguire »

BenjiWiebe wrote: post #43
underdeserver wrote: post #38

Earlier quoted context omitted.

How would the server know that the destination IP changed?

When the acknowledgement packet suddenly comes from a new IP address, referencing an existing connection ID.

There's security implications...

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

#55

Post by salmaanp »

BenjiWiebe wrote: post #43
underdeserver wrote: post #38

Earlier quoted context omitted.

How would the server know that the destination IP changed?

When the acknowledgement packet suddenly comes from a new IP address, referencing an existing connection ID.

this sounds similar to SSL resumption

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

#56

Post by vbezhenar »

kortex wrote: post #12
jrochkind1 wrote: post #5

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…

That's definitely not the case with my ISP. I'm routinely using IPsec VPN which uses UDP packets and the only (barely) noticeable difference is +100ms latency. Actually I'm often getting better Internet experience with VPN, presumably because of different routes to VPN server and target website.

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

#57

Post by vbezhenar »

ldng wrote: post #51
Androider wrote: post #36

Earlier quoted context omitted.

Presumably HTTP/3 could do WiFi-> 4G -> WiFi -> 5G -> WiFi... hand-offs as you're moving around.

Genuinely asking, is it actually working or is that like the promises of multiplexing in HTTP/2 that don't really work IRL ?

What's wrong with HTTP/2 multiplexing?

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

#58

Post by Matthias247 »

mcguire wrote: post #53
BenjiWiebe wrote: post #43

Earlier quoted context omitted.

When the acknowledgement packet suddenly comes from a new IP address, referencing an existing connection ID.

There's security implications...

Those are addressed by the QUIC specification, by having lots of encryption. The whole content of QUIC packets is encrypted. You can't really do a lot with connection IDs. And for most of the packets you can't even observe the full connection ID, since an abbreviated version is sent.

Acknowledgements are encrypted.

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

#59

Post by labawi »

rixed wrote: post #48
ATsch wrote: post #28

Earlier quoted context omitted.

There's something else, performance aside, that's really exciting about HTTP/3: Fixing a decades old layering violation that has made truly mobile internet impossible. In TCP, a connection is uniquely identified by the following tuple: (src ip, src port, dst ip, dst port) The issue is that we depend not only on layer 4 details (port numbers) but also on layer 3 information (IP addresses). This means we can not ever k…

Part of me consider HTTP/3 as an application protocol and disagree with this. This is not a problem for HTTP to solve but a problem for the routing protocol to solve. Is it desirable to reinvent a routing protocol at the application layer, so that we can use it as another transport protocol and so on? Shouldn't we be using a single, unique 128bit address for every device regardless of which physical network it is att…

I agree it would be appropriate to solve roaming on a lower layer, so any application can roam.

However, the solution should not and cannot be a global routing table. Aside from privacy issues, routing tables are very expensive. It needs to be decentralized, done on or at least near the endpoints, similar to programs like mosh, wireguard etc. Though there are certain security and privacy trade-offs in mentioned protocols that may not be appropriate.

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

#60

Post by elithrar »

jrochkind1 wrote: post #5

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,…

> As a developer of web apps, I will personally continue to not think that much about HTTP/3. Perhaps in the future network/systems engineers will have figured out how to make it bear fruit? I don't know, but it seems to me of unclear wisdom to count on it.

Congestion control algorithm - and congestion window sizing/tuning - plays a not-insignificant role in throughput, especially when comparing a 15KiB object vs. a 1MiB object. It's often _more_ outsized for those "medium sized" objects, as too small a window won't scale up by the time the transfer completes in some cases.

In other words: this is a good post, but the caveats around congestion control algorithm are a little understated w.r.t. the benchmarks.

Post reply on HN