Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

191–200 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#191

Post by IgorPartola »

wizzwizz4 wrote: post #181
IgorPartola wrote: post #170

Earlier quoted context omitted.

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.

The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.

But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.

Re: HTTP/3 is everywhere but nowhere

#192

Post by motorest »

IgorPartola wrote: post #170
motorest wrote: post #143

Earlier quoted context omitted.

> A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have. The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?

I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.

> I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load.

That's a software architecture problem, not a transport layer problem.

Re: HTTP/3 is everywhere but nowhere

#193

Post by wizzwizz4 »

IgorPartola wrote: post #191
wizzwizz4 wrote: post #181

Earlier quoted context omitted.

The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.

But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.

Your static and dynamic assets should be served from different domains anyway, to reduce the overhead of authentication headers / improve cache coherency. https://sstatic.net/ quotes a good explanation, apparently mirrored https://checkmyws.github.io/yslow-rules/. (The original Yahoo Best Practices for Speeding Up Your Web Site article has been taken down.)

Re: HTTP/3 is everywhere but nowhere

#194

Post by zokier »

While this article is about H3, I think there is wider issue at play; in general I think the gap of availble tools (/libraries/etc) between these faang megacorps and your average dev has grown very wide. Googles internal tooling maybe is the most famed, I'm sure some xooglers can tell more. This is very sad to see after seeing the massive democratization of sw development in the 00s-10s. I'm concerned about what the impact of having this two classes of developers will have on the community and ecosystem. I suppose this h3 phenomenon is one consequence.

Re: HTTP/3 is everywhere but nowhere

#195

Post by kelnos »

XorNot wrote: post #105
eptcyka wrote: post #77

Earlier quoted context omitted.

Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.

The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?" The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.

Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself.

Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways".

Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.

Re: HTTP/3 is everywhere but nowhere

#196

Post by hylaride »

surajrmal wrote: post #80
hylaride wrote: post #36

Earlier quoted context omitted.

99% of the benefit of HTTP/3 is on distributed web serving where clients are connecting to multiple remote ends on a web page (which lets be honest, is mostly used for serving ads faster). Why would the open source community prioritize this?

The open source community is full of companies who make money from things like ads.

Yes, but they've likely already optimized any code that's part of their ad networks to support http/3 anyways. They're not necessarily going to lose sleep if other components doesn't support it.

Re: HTTP/3 is everywhere but nowhere

#197

Post by waynesonfire »

celsoazevedo wrote: post #116
TheRealPomax wrote: post #101

Earlier quoted context omitted.

And yet, compared to the time you're waiting for that mast head jpeg to load, plus an even bigger "react app bundle", also completely irrelevant. HTTP/3 makes a meaningful difference for machines that need to work with HTTP endpoints, which is what Google needed it for: it will save them (and any other web based system similar to theirs) tons of time and bandwidth, which at their scale directly translates to dollars…

Almost every optimization is irrelevant if we apply the same reasoning to everything. Add all savings together and it does make a difference to real people using the web in the real world.

Google operates at such a scale that tiny increases of performances allows them to support a team of engineers and saves money on the bottom line.

For example, Google hires 10 engineers, they deploy HTTP/3, it saves 0.5% cpu usage, Google saves a million dollars and covers the salary of the said 10 engineers.

For the vast majority of society, the savings don't matter. Perhaps even deploying it is a net-negative with a ROI of decades. Or, the incentives can be misaligned leading to exploitation of personal information. For example, see chrome manifest v3.

It's okay to question whether we need it.

Re: HTTP/3 is everywhere but nowhere

#199

Post by Orygin »

arccy wrote: post #23
jsheard wrote: post #13

Earlier quoted context omitted.

Nginx (F5) and Go (Google) are hardly scrappy open source projects with limited resources. The former is semi-commercial, you can pay for Nginx and still not have stable HTTP3 support. Google was one of the main drivers of the HTTP3 spec and has supported it both in Chromium and on their own cloud for years, but for whatever reason they haven't put the same effort into Go's stdlib.

It's in progress: quic is in testing in http://pkg.go.dev/golang.org/x/net/quic and http3 is being implemented https://github.com/golang/go/issues/70914 Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.

The backwards compatibility guarantees are for the language and not the standard library. They won't make breaking changes nilly willy but it can and has happened for the std.

Re: HTTP/3 is everywhere but nowhere

#200

Post by hylaride »

arccy wrote: post #107
hylaride wrote: post #45

Earlier quoted context omitted.

Because the faster response is negligible when you're an indie web host that can serve content over a single connection with reasonable speed. Where HTTP/3 really "shines" is when you connect to a web site that then has dozens of connections to other hosts (internal or external)...which is facebook/google/ad companies. HTTP/3 speeds up that kind of content by reducing connection startup times to all of them, which ca…

but it doesn't help for different external connections, each one needs a new connection. it's good for multiple resources from the same host, maybe you have a lot of images on your photo blog or something

http3 has enhancements that speed up initial handshakes for new connections (QUIC essentially is UDP plus combining TLS and a native reliability layer to replace separate initial SYNs for them separately). So when you go to a page with tons of ads/trackers/javascript libraries, you're not left waiting as long for the ads to serve while browser reaches out to all those components and does separate TCP, TLS, and HTTP connections.

But users of most other websites won't see a ton of noticable benefits unless they have facebook/netflix/google levels of traffic. And at that point, you're either highly focused on the end user component code or you've outsourced it to a CDN that'll do the http3 for you anyways.

Post reply on HN