Hacker News Reader

Comment by perbu | Hacker News Reader

I am not at all convinced that the measly 1-4% performance we'll manage to eek out of this is worth the effort and complexity.

View on HN

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:

https://dropbox.tech/frontend/investigating-the-impact-of-ht...

(Discussed at https://news.ycombinator.com/item?id=36027702.)

Quote from article:

  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:

https://github.com/aiortc/aioquic/blob/main/examples/http3_s...

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.

> The average amount of time users are willing to wait for a web page to load will remain the same

People have definitely gotten more impatient over the years.

Actually, you're right. TikTok, Instagram et al. demonstrate that people have gotten more impatient... to get more crap!

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.

Interesting, how does QUIC help with 'arbitrary censorship'?

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.

Here is a relevant HN discussion thread from 2016 about TLS 1.3, most of which applies to HTTP/3: https://news.ycombinator.com/item?id=12641880

> 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'.

Access to some external sites might be necessary in some cases. They still have to monitor such connections.

This also means you can tunnel http3 traffic through cloudflare without them decrypting it?

Well, if your intention is to use Cloudflare's network for your H3 tunnels, then expect an API for it soon: https://blog.cloudflare.com/building-privacy-into-internet-s...

See: https://ooni.org/post/2022-quick-look-quic-censorship/

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.

And a good improvement on head of line blocking that http2 introduced?

That performance impact is worth millions of dollars in improved conversions.

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.

It might be a good idea to not let software/hardware you don't trust onto your own networks.

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.

It dates back to a more draconic era of firewall management, but has also worked its way into DHCP (https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto...).

But doesn't snooping/modifying that traffic still require breaking TLS, which is only possible if you can install a root certificate on your device?

> 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?

It doesn't. HN users tend to believe that everything is some crazy conspiracy targeted at them and their pi hole setup.

Reply on news.ycombinator.com