5 ms·

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.

by perbu 3y ago

dochtman 3y ago
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-http3-on-network-latency-for-search https://dropbox.tech/frontend/investigating-the-impact-of-ht... (Discussed at https://news.ycombinator.com/item?id=36027702 https://news.ycombinator.com/item?id=36027702.)
- robocat 3y ago
  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.
  - still_grokking 3y ago
    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_server.py https://github.com/aiortc/aioquic/blob/main/examples/http3_s...
- speed_spread 3y ago
  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.
  - re-thc 3y ago
    > 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.
    - speed_spread 3y ago
      Actually, you're right. TikTok, Instagram et al. demonstrate that people have gotten more impatient... to get more crap!
ignoramous 3y ago
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.
- ledgerdev 3y ago
  Interesting, how does QUIC help with 'arbitrary censorship'?
  - 634636346 3y ago
    See: https://ooni.org/post/2022-quick-look-quic-censorship/ 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.
  - jupp0r 3y ago
    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 https://news.ycombinator.com/item?id=12641880
    - rini17 3y ago
      This also means you can tunnel http3 traffic through cloudflare without them decrypting it?
      - deleted 3y ago
        [deleted]
      - 3y ago
intelVISA 3y ago
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.
- still_grokking 3y ago
  > 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.)
  - firstlink 3y ago
    > 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.
  - askvictor 3y ago
    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.
wbl 3y ago
That performance impact is worth millions of dollars in improved conversions.

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.

by perbu 3y ago

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.

dochtman 3y ago

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-http3-on-network-latency-for-search https://dropbox.tech/frontend/investigating-the-impact-of-ht... (Discussed at https://news.ycombinator.com/item?id=36027702 https://news.ycombinator.com/item?id=36027702.)

robocat 3y ago
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.
- still_grokking 3y ago
  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_server.py https://github.com/aiortc/aioquic/blob/main/examples/http3_s...
speed_spread 3y ago
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.
- re-thc 3y ago
  > 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.
  - speed_spread 3y ago
    Actually, you're right. TikTok, Instagram et al. demonstrate that people have gotten more impatient... to get more crap!

ignoramous 3y ago

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.

ledgerdev 3y ago
Interesting, how does QUIC help with 'arbitrary censorship'?
- 634636346 3y ago
  See: https://ooni.org/post/2022-quick-look-quic-censorship/ 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.
- jupp0r 3y ago
  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 https://news.ycombinator.com/item?id=12641880
  - rini17 3y ago
    This also means you can tunnel http3 traffic through cloudflare without them decrypting it?
    - deleted 3y ago
      [deleted]
    - 3y ago

intelVISA 3y ago

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.

still_grokking 3y ago
> 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.)
- firstlink 3y ago
  > 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.
- askvictor 3y ago
  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.

wbl 3y ago

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