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

31–40 of 84 posts

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

#31

Post by jeltz »

sebazzz wrote: post #18
move-on-by wrote: post #8

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?

Yes, but that is essentially what QUIC is, a new transport layer protocol andHTTP/3 is then ran over QUIC. QUIC is right now implemented in user space but nothing prevents it from being implemented in the kernel.

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

#32

Post by acdha »

scarlac wrote: post #29
cletus wrote: post #25

So in a former life I worked on Google Fiber and, among other things, wrote a pure JS Speedtest (before Ookla had one alhtough there's might've been in beta by then). It's still there ( http://speed.googlefiber.net ). This was necessary because Google Fiber installers use Chromebooks to verify installations and Chromebooks don't support Flash. This is a surprisingly difficult problem, especially given the constraints…

They did mention multiple geographic locations as well as RTT (Round Trip Time) which is somewhat equivalent to latency, no?

The challenge to control for is that they used WebPageTest, which tends to have locations in data centers near where they do. Using the traffic shaping options can add latency but what you really want is random latency and packet loss to simulate real-world usage.

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

#33

Post by sholladay »

In Node.js (curious to hear about other ecosystems), HTTP/2 hasn't even caught on yet. Sure, it's technically supported by Node core and various frameworks, but hardly anyone is really using it. Most of the benefits that HTTP/2 brings to the table require a new model that doesn't map cleanly to the traditional request/response lifecycle. It seems harder to program applications using HTTP/2 because of that. Perhaps some of it is what we are used to and the burden of learning something new, but I don't think that's the whole story. I wonder if future HTTP versions will address this in some way or if it is going to continue to be the new normal. It will be interesting to see what the adoption curve looks like for HTTP/3 and onward. I'm still building everything on HTTP/1.1 (RFC 7230) and have no plans to change that any time soon, even though I can appreciate the features that are available in the newer versions.

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

#34

Post by ComputerGuru »

londons_explore wrote: post #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 co…

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 attempting to move from one to the other so that it can theoretically be a “seamless” experience. In theory, anyway.

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

#36

Post by Androider »

ComputerGuru wrote: post #34
londons_explore wrote: post #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 co…

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.

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

#37

Post by ajrw »

cb22 wrote: post #26
georgyo wrote: post #22

Earlier quoted context omitted.

The application layer is the only place these changes can go anymore. IPv6 is a good example that protocol layer changes are really slow to roll out. You may also be interested in SCTP, which is awesome on paper and works well across the internet. But since most firewalls only understand TCP, UDP, and ICMP other protocols get auto dropped. SCTP could have been amazing. https://en.m.wikipedia.org/wiki/Stream_Control_T…

> SCTP could have been amazing It still is, it's part of the WebRTC spec, and when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! (or TCP, possibly with a TURN relay, which may end up tunneling the whole thing over TLS over TCP :)) There are a lot of acronyms in WebRTC, thankfully there's https://webrtcglossary.com

Wow, I knew it was using SCTP but I didn't know that was inside the DTLS channel. That seems like a lot of overhead.

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

#38

Post by underdeserver »

ATsch wrote: post #28
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,…

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…

How would the server know that the destination IP changed?

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

#39

Post by Androider »

sholladay wrote: post #33

In Node.js (curious to hear about other ecosystems), HTTP/2 hasn't even caught on yet. Sure, it's technically supported by Node core and various frameworks, but hardly anyone is really using it. Most of the benefits that HTTP/2 brings to the table require a new model that doesn't map cleanly to the traditional request/response lifecycle. It seems harder to program applications using HTTP/2 because of that. Perhaps so…

Turns out it's not really an issue in practice, since you rarely serve naked Node.js to the Internet. If you put something like a load balancer (ELB) or reverse proxy (Nginx) in front of your service which speaks HTTP/2, you already get 95% of the benefits. I expect HTTP/3 to likewise just be a toggle offered by AWS/GCP/Azure/NGinx etc. in the future, and your users will see an immediate benefit.
Post reply on HN