Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

11–20 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#12
post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed by big tech companies and then implemented eagerly by them; see for example DHCP option 108.

In a sense the need for IPv6 is driven by corporates just like that for HTTP/3.

Re: HTTP/3 is everywhere but nowhere

#13
post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

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.

Re: HTTP/3 is everywhere but nowhere

#14
post #4

as an indie web master, some percentage improvement on ttfb brings zero benefit to me and my users, but requiring or recommending it to users only help big tech.

Could you elaborate on why faster responses don't benefit you or your users?

Re: HTTP/3 is everywhere but nowhere

#15
> You'll start to see lack of HTTP/3 support used as a signal to trigger captchas & CDN blocks, like as TLS fingerprinting is already today. HTTP/3 support could very quickly & easily become a way to detect many non-browser clients, cutting long-tail clients off from the modern web entirely.

That explains it. I've seen this when using 3 year old browsers on retail web sites recently. A few cloud providers think I’m a bot.

Re: HTTP/3 is everywhere but nowhere

#16
post #5

How much does http/3 help for server to server traffic? Seems like larger websites can use a CDN or load balancer to do termination and then use http 1.1 to the back end. Is that good enough with large pipes and a high number of connections?

QUIC was not designed for server-to-server. In that use case, you’ll [1]likely experience poor performance due to higher CPU usage (since QUIC is a user-space protocol without TCP optimizations at the kernel/NIC level) and lower throughput.

[1]This is based on public benchmarks, try searching for `TCP vs QUIC`

Re: HTTP/3 is everywhere but nowhere

#17
post #12
post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed…

Ummm… Google invented QUIC and pushed it into Chrome and shuttled it through IETF to be ratified as a standard. Some of the large OSS projects are maintained by large companies (eg quiche is by Cloudflare) and Microsoft has MsQuic which you can link against directly or just use the kernel mode version built into the OS directly since Windows 11. The need for QUIC is actually even more driven by corporates since IPv6 was a very small comparative pain point compared to better reaching customers with large latency network connections.

Re: HTTP/3 is everywhere but nowhere

#18
post #6

My recent projects in C++ are just using cURL, but given some of the versions of cURL I have to support are 10 years old it isn't being turned on anytime soon. Even the latest deployments on Rocky 9 are using a 4 year old version of cURL When you're writing libraries distributed as binaries for other teams you can't just statically link whatever you want willy nilly.

What prevents you from using a package manager linking statically with a recent libcurl ?

I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible.

You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.

Re: HTTP/3 is everywhere but nowhere

#19
post #12
post #10

Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.

The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed…

IPv6 always seemed to me to be driven by a certain class of purist networking geeks. Then some corporations started getting on board like you said, but many couldn't care less.
Post reply on HN