HTTP/3 is everywhere but nowhere
33 points by eduard
33 points by eduard
There are a rare few external libraries for some languages, but all are experimental and/or independent of other core networking APIs. Despite mobile networking being a key use case for HTTP/3, Android’s most popular HTTP library has no support
Completely ignoring the fact that Apple’s APIs have supported QUIC and HTTP/3 since about 2021. That means pretty much all native iOS and Mac apps support it, i.e. programs that use NSURLConnection or Network.framework instead of low-level sockets. That’s a pretty good fraction of mobile networking right there.
I have to assume the author either lives in a reality distortion field where Apple doesn’t exist, or just implicitly considers non-open-source unworthy of mention.
Their counter arguments to my post are a bit weird.
Latency of responses isn’t just network RTT: a slow server response because of server processing will block your TCP connection just as hard as network latency.
My post was in the context of application servers with a fixed capacity.
Your load balancer is often not co-located with your backend, e.g. if you serve everything through a geographically distributed CDN,
Here again it’s weird. Perhaps I didn’t spell it out exactly, but I of course meant for connection over LAN. Connections from a CDN to your datacenter would absolutely benefit from HTTP/2, I never claimed the opposite.
Then it mention things like Mobile and IoT which is totally out of scope. Even later it mention things like connection migrations.
But perhaps it just isn’t clear which part are answering my post and which parts are just mentioning other benefits of HTTP/2 and 3.
it’s hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started
Ummm..?? Caddy enables HTTP/3 by default since September 2022 (v2.6) and Caddy is, like, almost the default choice for “just serve a website from this unix box” these days.
You overestimate the amount of nginx & Apache deployments, which are bound to keep a bigger share of the market since people are mostly familiar with them and there’s documentation all over the web.
Caddy doesn’t yet have its own line in the Netcraft web server survey but that line for “other” servers is getting very high. I wonder what it includes.
I was investigating that for Ubuntu and came to the same conclusions (except the part where this would serve as fingerprinting/discrimination). Very large companies have enabled HTTP/3 and it is in browsers too (sometimes made by the same company). Integrating the support in the distribution as opposed to integrating it only in a few select applications, is another matter.
Debian has switched to gnutls and nghttp3 for HTTP/3 support in curl . However, for long-term support reasons, Ubuntu isn’t keen on adding more libs in “main” so nghttp3 (and ngtcp2 which it depends upon) has been put aside for now. Since it’s not easy to do, this raises the actual question: is there a need to hurry or even do it at all? Everything works, there are no HTTP/3 servers apart from huge companies which expect users to come through browsers (which support it anyway). So why do it?
Sure, everybody would like to enable HTTP/3 but the rewards look almost non-existant in practice and the cost is pretty high, especially when using openssl in most places. There simply isn’t an easy solution.
BTW, there’s https://github.com/curl/curl/wiki/curl-distro-discussion-2025 where one of the planned topic is “HTTP/3 - updates on status and discussions on how to (possibly) enable this in curl for distros going forward”. The “(possibly)” part is spot on.
HTTP/3 seems kinda like a lot of other industrial machinery: very useful, very powerful, but a bit too big and awkward to be easily affordable to average people. Developing and deploying it seems an easy enough task for companies with the resources of Google or Cloudflare, but it will take longer to filter down to the mere mortals implementing curl.
And the benefits are smaller at a personal scale as well; apparently nginx has supported QUIC for a couple years now, but my website and wiki run on a $4/mo Hetzner VPS and despite apparently getting a couple thousand hits per day (mostly webcrawlers) seems to hover at about 2% CPU usage. I’ll probably turn QUIC on eventually just for fun.
I can take advantage of HTTP/3 in a 20-line quickie demo app written in Swift (or Obj-C, or with some more work C.) It’s not that it’s “too big and awkward”, it’s just that the open source world seems to have dropped the ball on supporting it.
I don’t agree with it being a case of “just” dropping the ball. HTTP 3.0 is a rather complex beast, and given that both HTTP 1.1 and HTTP 2.0 are good enough for maybe 95% of all use cases, there’s just not really that much of a reason to focus on HTTP 3.0 unless you’re some behemoth like Cloudflare.
There are also technical issues such as QUIC not being supported natively at the hardware level, meaning HTTP3/QUIC connections may end up using more of the CPU compared to HTTP2/TCP (though that is at least mostly a matter of time before it’s resolved).
I’ve been looking to deploy HTTP/3 support with H2O once merged. I haven’t looked into the implementation, which makes me curious how it works since they use OpenSSL for TLS & curl --only-http3 successfully returns the basic proper data.
I think there’s an ugly hack for HTTP/3 support with openssl, which nginx relies on (and now haproxy?). Maybe they do the same.