4 ms·
I don't have access to the paper but based on the abstract and a quick scan of the presentation, I can confirm that I have seen results like this in Caddy, whic
by mholt 2y ago
I don't have access to the paper but based on the abstract and a quick scan of the presentation, I can confirm that I have seen results like this in Caddy, which enables HTTP/3 out of the box.
HTTP/3 implementations vary widely at the moment, and will likely take another decade to optimize to homogeneity. But even then, QUIC requires a lot of state management that TCP doesn't have to worry about (even in the kernel). There's a ton of processing involved with every UDP packet, and small MTUs, still engrained into many middle boxes and even end-user machines these days, don't make it any better.
So, yeah, as I felt about QUIC ... oh, about 6 years ago or so... HTTP/2 is actually really quite good enough for most use cases. The far reaches of the world and those without fast connections will benefit, but the majority of global transmissions will likely be best served with HTTP/2.
Intuitively, I consider each HTTP major version an increased order of magnitude in complexity. From 1 to 2 the main complexities are binary (that's debatable, since it's technically simpler from an encoding standpoint), compression, and streams; then with HTTP/3 there's _so, so much_ it does to make it work. It _can_ be faster -- that's proven -- but only when networks are slow.
TCP congestion control is its own worst enemy, but when networks aren't congested (and with the right algorithm)... guess what. It's fast! And the in-order packet transmissions (head-of-line blocking) makes endpoint code so much simpler and faster. It's no wonder TCP is faster these days when networks are fast.
I think servers should offer HTTP/3 but clients should be choosy when to use it, for the sake of their own experience/performance.
- deleted 2y ago[deleted]
- altairprime 2y agoThe performance gap is shown to be due to hardware offloading, not due to congestion control, in the arxiv paper above.
- vlovich123 2y agoAnd because Quic is encrypted at a fundamental level, offload likely means needing to share keys with the network card which is a trust concern.
- 10000truths 2y agoThis is already how TLS offload is implemented for NICs that support it. The handshake isn't offloaded, only the data path. So essentially, the application performs the handshake, then it calls setsockopt to convert the TCP socket to a kTLS socket, then it passes the shared key, IV, etc. to the kTLS socket, and the OS's network stack passes those parameters to the NIC. From there, the NIC only handles the bulk encryption/decryption and record encapsulation/decapsulation. This approach keeps the drivers' offload implementations simple, while still allowing the application/OS to manage the session state.
- vlovich123 2y agoSure, similar mechanisms are available but for TCP ack offloading and TLS encryption/decryption offloading are distinct features. With QUIC there’s no separation which changes the threat model. Of course the root architectural problem is that this kind of stuff is part of the NIC instead of an “encryption accelerator” that can be requested to operate with a key ID on a RAM region and then the kernel only needs to give the keys to the SE (and potentially that’s where they even originate instead of ever living anywhere else)
- jstarks 2y agoYour NIC can already access arbitrary RAM via DMA. It can read your keys already.
- altairprime 2y agoThat is often incorrect for Apple computers, whether x64+T2 or aarch64: https://support.apple.com/fr-tn/guide/security/seca4960c2b5/web https://support.apple.com/fr-tn/guide/security/seca4960c2b5/... And it’s often incorrect on x64 PCs when IOMMU access is appropriately segmented. See also e.g. Thunderclap: https://www.ndss-symposium.org/wp-content/uploads/ndss2019_05A-1_Markettos_slides.pdf https://www.ndss-symposium.org/wp-content/uploads/ndss2019_0... It may still be true in some cases, but it shouldn’t be taken for granted that it’s always true.
- yencabulator 2y ago
- truetraveller 2y agoI'd say Http1.1 is good enough for most people, especially with persistent connections. Http2 is an exponential leap in complexity, and burdensome/error-prone for clients to implement.
- 01HNNWZ0MV43FF 2y agoYeah I imagine 1 + 3 being popular. 1.1 is so simple to implement and WebTransport / QUIC is basically a teeny VPN connection.
- apitman 2y agoThe day they come for HTTP/1.1 is the day I die on a hill.
- Sparkyte 2y agoAgreed on this.
- geocar 2y agoI turned off HTTP2 and HTTP3 a few months ago. I see a few million daily page views: Memory usage has been down, latency has been down, network accounting (bandwidth) is about the same. Revenue (ads) is up. > It _can_ be faster -- that's proven -- but only when networks are slow. It can be faster in a situation that doesn't exist. It sounds charitable to say something like "when networks are slow" -- but because everyone has had a slow network experience, they are going to think that QUIC would help them out, but real world slow network problems don't look like the ones that QUIC solves. In the real world, QUIC wastes memory and money and increases latency on the average case. Maybe some Google engineers can come up with a clever heuristic involving TCP options or the RTT information to "switch on QUIC selectively" but honestly I wish they wouldn't bother, simply because I don't want to waste my time benchmarking another half-baked google fart.
- withinboredom 2y agoThe thing is, very few people who use "your website" are on slow, congested networks. The number of people who visit google on a slow, congested network (airport wifi, phones at conferences, etc) is way greater than that. This is a protocol to solve a google problem, not a general problem or even a general solution.
- geocar 2y agoSince I buy ads on Google to my site I would argue it’s representative of Google’s traffic. But nice theory.
- withinboredom 2y agoIt's not. Think about what you search for on your mobile, while out or traveling, and what you search for on desktop/wifi. They are vastly different. Your traffic is not representative of the majority of searches.
- geocar 2y agoI'm sure the majority of searches are for "google" and "facebook" and you're right in a way: I'm not interested in those users. I'm only interested in searches that advertisers are interested in, but this is also where Google gets their revenue from, so we are aligned with which users we want to prioritise, so I do not understand who you possibly think QUIC is for if not Google's ad business?