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

61–70 of 84 posts

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

#61

Post by Matthias247 »

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 ?

Both share the same attributes: The spec allows them to work, but they require lots of effort on the implementation side to get it right. HTTP/2 require a library which does sane write scheduling and prioritization to make it work.

QUIC handoffs are a lot more complicated. They will require a library which supports all the necessary features. And it will require infrastructure which supports it. Without infrastructure support, packets from the client might get routed to the wrong host after a IP tuple change, and can from there on not associated with the QUIC connection.

My guess is some QUIC deployments will figure out how to make it work - others likely won't, since a lot of efforts is involved.

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

#62

Post by Matthias247 »

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…

> 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

This is not true. The only HTTP/2 feature that doesn't fit into the traditional HTTP semantics is PUSH. And even that is the request/response model - the only difference is that the request is injected also from the server side and not being received from the client. We just pretend we would have received such a request from the client, send the response towards the client, and hope the client won't reject it.

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

#63

Post by Matthias247 »

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…

> - Send too much traffic and you can crash the browser, particularly on mobile devices;

Surprised to hear that. Sending data should never lead to a crash. Even an aborted request wouldn't be great. When was that? Hope these things got fixed.

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

#64

Post by labawi »

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…

What does the wifi handoff you mention actually do?

I know of a standard for 802.1X preauthentication, that does 802.1X authentication via old AP before roaming.

If your APs aren't doing NAT or stateful firewall, then there is no state to transfer, except automatic updating of MAC addresses on switches, and the authentication of the client which shouldn't require any cross-communication unless using 802.1X with mentioned preauthentication. You will lose packets in flight while switching, but it shouldn't take long.

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

#65

Post by labawi »

Matthias247 wrote: post #62
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…

> 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 This is not true. The only HTTP/2 feature that doesn't fit into the traditional HTTP semantics is PUSH. And even that is the request/response model - the only difference is that the request is injected also from the server side and not being received from the client. We jus…

0-RTT requests mess with the traditional lifecycle and have security implications that many won't handle safely.

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

#66

Post by steveklabnik »

Androider wrote: post #39
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.

Cloudflare includes such a toggle for HTTP/3, though to be honest I forget if it's still in a closed beta or more generally available.

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

#67

Post by jeltz »

toast0 wrote: post #47
sebazzz wrote: 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. Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?

You can't get promoted at Google by making TCP on Android better, but you can for releasing HTTP over TCP over UDP.

Maybe not but IETF took over the development from Google and now Quic is a generic and widely useful transport protocol. What is needed is kernel support and hardware accelerators.

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

#68

Post by Matthias247 »

labawi wrote: post #65
Matthias247 wrote: post #62

Earlier quoted context omitted.

> 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 This is not true. The only HTTP/2 feature that doesn't fit into the traditional HTTP semantics is PUSH. And even that is the request/response model - the only difference is that the request is injected also from the server side and not being received from the client. We jus…

0-RTT requests mess with the traditional lifecycle and have security implications that many won't handle safely.

0-RTT requests certainly have security implications. However they are not part of HTTP/2, but of TLS1.3 (and QUIC). They are orthogonal concerns, even though it's a valid layering concern: We have a transport layer concern leaking up into the HTTP layer - whether it's HTTP/1.1, /2 or /3.

Also 0-RTT requests still follow the request/response model.

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

#69

Post by labawi »

Matthias247 wrote: post #58
mcguire wrote: post #53

Earlier quoted context omitted.

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.

Can the transport path be hijacked from a single captured packet? As in capture a single packet, scribble an address and the connection now goes via Pentagon or China.

I know it's possible for wireguard, maybe mosh.

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

#70

Post by keithwinstein »

labawi wrote: post #69
Matthias247 wrote: post #58

Earlier quoted context omitted.

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.

Can the transport path be hijacked from a single captured packet? As in capture a single packet, scribble an address and the connection now goes via Pentagon or China. I know it's possible for wireguard, maybe mosh.

No -- Mosh is careful to make sure that a transient network attack can only result in a transient application-layer consequence. So a single misrouted IP datagram can't permanently affect the connection. Mosh does this at the cost of having client-only mobility; the client keeps sending to the same server address for the life of the connection.
Post reply on HN