Latency at higher percentiles (crappier internet connections) improves pretty meaningfully in most of the articles I've seen. Here's a recent one from Dropbox:
For the majority of our global users, HTTP3 reduced network latencies by 5-15ms (or 5%). While this is an improvement, these wins would appear negligible to the average user. At p90, however, HTTP3 demonstrated massive improvements, with a latency reduction of 48ms (or 13%)—and at p95, a reduction of 146ms (21%). This could be explained by the fact that HTTP3 is better at handling packet drops in parallel connections by eliminating head-of-line blocking; because packet drops are more likely to occur in networks with suboptimal connection quality, the benefits of HTTP3 are more visible at the higher percentiles.
Given that the majority of people uses the web through very often quite crappy mobile links HTTP/3 is actually a significant win from the user experience perspective. It can be all the difference between "site is completely unusable" and "site is slow, but you get through".
Of course it's true that QUIC is a complexity monster. OTOH HTTP/3 is actually quite simple when you have the QUIC layer implemented. A simple HTTP/3 server is no more than this:
The average amount of time users are willing to wait for a web page to load will remain the same, thus any latency reduction will simply be eaten up by more crap being served, because greed. The constraints aren't technical, they're human.
QUIC is also more of a response to the havoc wreaked by network middleware, ageing kernel network stacks, and arbitrary censorship. In another sense, QUIC is an attempt to revive the end-to-end principle.
It mandates perfect forward secrecy TLS cipher modes mandatory which makes it impossible for man-in-the-middle hardware to intercept and read users' connections while still pretending to be secure.
There was quite a bit of pushback on this in the IETF from financial institutions that think they have mandatory obligations to spy on their employees.
> There was quite a bit of pushback on this in the IETF from financial institutions that think they have mandatory obligations to spy on their employees.
To be fair, they do have mandatory requirements to prevent their employees from doing some things online in some cases. For example - some of the rules around coordination on a trading floor: https://www.sec.gov/rules/sro/nyse/2017/34-80374-ex5.pdf
Or - in many cases they are legally required to retain a copy of communications sent, and there are a large number of sites that offer diverse services banks want that also happen to have "chat/email" hidden as a feature. That's legally communication, and they often can't collect and retain it.
Long story short - they don't really care so much, because many of them are already doing this collection now in other ways... my first job out of college 13 years ago was helping large banks transition this monitoring and policy enforcement to browser extensions (Guess who was grumbling about the MV3 changes in chrome, for very similar reasons).
Now they're moving to directly adding the monitoring in the OS/Kernel
> Now they're moving to directly adding the monitoring in the OS/Kernel
Does this mean financial software has root-kits build in? Good to know!
So this means every banking computer is fundamentally compromised at the OS level. Let' see how long it takes until this backfires. Could be a nice global firework when it goes off.
Who exactly builds those root-kits? How good are they protected against supply chain attacks?
Good to know, thanks for the perspective. I only know that there was huge pushback against these somewhat niche (but still important) requirements making TLS 1.3 less secure for everybody. I'm glad somebody held firm.
They are of course free to use http in a closed environment, without any encryption. Or use any internal proprietary protocols. There is absolutely nor reason to mandate the world to follow their 'requirements'.
I assume Google and co. will fix this if it ever starts to seriously benefit platforms like KiwiFarms, which in the last year was being blocked by CenturyLink, a major US ISP. I also predict these QUICfixes will be met with broad enthusiasm by HNers.
Bear in mind QUIC was primarily designed to improve advertisement penetration by making it harder for good actors to interdict and remove bad domains. (Something like dns-over-http/3 is, allegedly, referred to internally at Google as the anti-Pi-hole)
plus, in real-world use cases it's probably a perf loss running TLS like this fwiw.
> Bear in mind QUIC was primarily designed to improve advertisement penetration by making it harder for good actors to interdict and remove bad domains.
Are there any prove points for this claim besides this shout-out?
QUIC is more like a modern TCP. What you do with such a protocol is unrelated to the protocol as such. You can open secure connections and stream data with it. That's all. Everything else is on the application side.
> Something like dns-over-http/3 is, allegedly, referred to internally at Google as the anti-Pi-hole
This claim sounds like anti QUIC FUD.
Nothing can stop you from using a Pi-hole like device as your primary DNS resolver!
(OK, I admit Google could try to hard-code their DNS servers in Chrome. But I'm very unsure they would make it through the following shit storm in one piece.)
Not OP, but Google do hard-code their DNS servers in other products (e.g. Chromecast), so they'll bypass your pi-hole. It is possible to intercept DNS traffic to 8.8.8.8 and redirect it to your own router, however. With DNS-over-HTTPS this is impossible short of installing custom SSL root certs on the device, which is close to impossible. But that's got nothing to do with QUIC or HTTP/3, but is effectively just enforcing signed DNS requests.
Some (most?) browsers support a non-transparent forward proxy. But you really have to trust it, because you're giving it man-in-the-middle control over all of your browser sessions.
> Google could try to hard-code their DNS servers in Chrome
More relevantly, there's no reason they couldn't do the same before HTTP/3. Even with DNS traffic hijacking, they could just as well do DNS-over-TLS. Infiltrating advertising-related DNS is completely orthogonal to HTTP/3; agreed that the gp comment is FUD.
Google is an advertising company. Why on earth would anything they do NOT be in order to improve advertisement delivery? I don't understand the water-carrying in this thread, but filter bypass has been the primary criticism of this technology since it was invented.
> Bear in mind QUIC was primarily designed to improve advertisement penetration by making it harder for good actors to interdict and remove bad domains.
What? What is your source on this? How does the protocol stop you from using e.g. uBlock to filter the domains at the application level?
