HTTP/3 support is a bit frustrating, since it's highlighted a serious split in engineering effort & focus, which has created a two-tier internet: browsers & big CDNs do support and use HTTP/3 heavily, but most small tools, servers and programming languages don't have stable built-in support at all (e.g. no support in the standard libraries for Go, Node.js, Python, etc) for either clients or servers. Even big tools like Nginx only have experimental support, disabled by default: https://nginx.org/en/docs/http/ngx_http_v3_module.html
Many years after this article was posted, OpenSSL does now have QUIC _client_ support (from 3.2: https://github.com/openssl/openssl/blob/master/README-QUIC.m...) but server support is still not available (and for Node at least, OpenSSL's approach here has been one of the main blockers for serious built-in HTTP/3 support).
There are some native libraries you can use to work around this, but they're not easy to set up in many cases and they're totally separate from each languages normal network stack. As a typical developer, the general solution is still 'just use HTTP/2 everywhere', even as HTTP/3 use on the browser web spikes higher and higher.
It's all HTTP/1.1 at the application layer, still. The HTTP/2 and HTTP/3 are mostly a binary encoding scheme (to use on top of good old TLS on top of TCP) and a different transport protocol (on top of UDP instead of TCP), respectively, but their goal is to carry good old HTTP/1.1 messages around.
My main reason is because there is no support for it in Ruby yet, been waiting for a while. Usually I would try to release such a missing gem myself but HTTP/3 is waaay to complex for me.
Also, I remember when asking for why there was no support for HTTP/3 yet in Rails, someone responded something along the lines of no true benefit of using H3 over H2. But I can't find that comment again.
I didn't catch this until I got to the part about OpenSSL 3 being delayed... I'm not sure I see much value in reading about how HTTP/3 support was in 2021, and without (2021) in the title it's more misleading than anything
Nginx ingress, arguably the most popular reverse proxy for Kubernetes, is also lacking any HTTP3 support because of this slow progress. The related issue is 5y/o and the feature is now planned for its successor.
https://github.com/kubernetes/ingress-nginx/issues/4760
What do I have to do to support H3 in my app? Is this like TLS, which is terminated by some reverse proxy and the application still just uses http 1? Or does it have to be in the application itself? IIRC H3 requires TLS, so it might be better at the reverse proxy? But do I still get the benefits of H3 if I do that?
Since the connection between your reverse proxy and your application server is probably much more reliable and lower latency than between your user and your reverse proxy, you should still benefit in the typical reverse proxy setup.
Not sure if this could work for you, but I use HAProxy (not for failover, but just as a front end). It terminates TLS and supports http3. I was already using it for http2 (TLS required for that), so enabling http3 involved upgrading and editing the config a little bit. I'm pretty sure the web servers behind it use http1.1 to HAProxy, then HAProxy talks http3 to clients.
It will be better with a reverse proxy. Decoupling the app and the ingress is always a good practice when you can afford an extra layer. The app itself is sufficient with HTTP/1.1 if the internal network is secure and performant (which it almost always is a container network nowadays).
I'm really missing HTTP/3 in ingress-nginx for Kubernetes. I guess most people use a CDN/Load Balancer in front of it. I didn't find a good general purpose alternative for ingress-nginx yet.
I know this list, and I always came back to ingress-nginx after trying out an alternative. ingress-nginx works best for me, it just doesn't have HTTP/3 and it doesn't seem to be a priority for the project.
I guess most people just use Cloudflare or similar Gateways for HTTP/3 support, which is probably the best option for now.
iirc there were some benchmarks for quic vs standard http1/2 and the quic was essentially on par. the only thing it provided was faster something(really don't remember) but overall there was no difference to the client.
Many years after this article was posted, OpenSSL does now have QUIC _client_ support (from 3.2: https://github.com/openssl/openssl/blob/master/README-QUIC.m...) but server support is still not available (and for Node at least, OpenSSL's approach here has been one of the main blockers for serious built-in HTTP/3 support).
There are some native libraries you can use to work around this, but they're not easy to set up in many cases and they're totally separate from each languages normal network stack. As a typical developer, the general solution is still 'just use HTTP/2 everywhere', even as HTTP/3 use on the browser web spikes higher and higher.