Hacker News Reader

Comment by ckbkr10 | Hacker News Reader

Sounds overly complicated, I doubt this will have a widespread adoption

About 30% percent of traffic to Cloudflare uses HTTP/3 [0], so it seems pretty popular already. For comparison, this is 3× as much traffic as HTTP/1.1.

[0]: https://radar.cloudflare.com/adoption-and-usage#http1x-vs-ht...

and then cloudflare converts that to http/2 or even 1.1 for the backend

So? Those protocols work fine within the reliable low latency network of a datacenter.

I'd even go as far as claiming that on reliable wired connections (like between cloudflare and your backend) HTTP/2 is superior to HTTP/3. Choosing HTTP/3 for that part of the journey would be a downgrade

At the very least, the benefits of QUIC are very very dubious for low RTT connections like inside a datacenter, especially when you're losing a bunch of hardware support and moving a fair bit of actual work to userspace where threads need to be scheduled etc. On the other hand Cloudflare to backend is not necessarily low RTT and likely has nonzero congestion.

With that said, I am 100% in agreement that the primary benefits of QUIC in most cases would be between client and CDN, whereas the costs are comparable at every hop.

Is CF typically serving from the edge, or serving from the nearest to the server? I imagine it would be from the edge so that it can CDN what it can. So... most of the time it wont be a low latency connection from CF to backend. Unless your back end is globally distributed too.

Also, within a single server, you should not use HTTP between your frontend nginx and your application server - use FastCGI or SCGI instead, as they preserve metadata (like client IP) much better. You can also use them over the network within a datacenter, in theory.

Is the protocol inherently inferior in situations like that, or is this because we've spent decades optimizing for TCP and building into kernels and hardware? If we imagine a future where QUIC gets that kind of support, will it still be a downgrade?

There is no performance disadvantage at the normal speed of most implementations. With a good QUIC implementation and a good network stack you can drive ~100 Gb/s per core on a regular processor from userspace with 1500-byte MTU with no segmentation offload if you use a unencrypted QUIC configuration. If you use encryption, then you will bottleneck on the encryption/decryption bandwidth of ~20-50 Gb/s depending on your processor.

On the Linux kernel [1], for some benchmark they average ~24 Gb/s for unencrypted TCP from kernel space with 1500-byte MTU using segmentation offload. For encrypted transport, they average ~11 Gb/s. Even using 9000-byte MTU for unencrypted TCP they only average ~39 Gb/s. So there is no inherent disadvantage when considering implementations of this performance level.

And yes, that is a link to a Linux kernel QUIC vs Linux kernel TCP comparison. And yes, the Linux kernel QUIC implementation is only driving ~5 Gb/s which is 20x slower than what I stated is possible for a QUIC implementation above. Every QUIC implementation in the wild is dreadfully slow compared to what you could actually achieve with a proper implementation.

Theoretically, there is a small fundamental advantage to TCP due to not having multiple streams which could allow it maybe a ~2x performance advantage when comparing perfectly optimal implementations. But, you are comparing a per-core control plane throughput using 1500-byte MTU of, by my estimation, ~300 Gb/s on QUIC vs ~600 Gb/s on TCP at which point both are probably bottlenecking on your per-core memory bandwidth anyways.

[1] https://lwn.net/ml/all/cover.1751743914.git.lucien.xin@gmail...

"As of September 2024, HTTP/3 is supported by more than 95% of major web browsers in use and 34% of the top 10 million websites."

https://en.wikipedia.org/wiki/HTTP/3

A lot of servers still don't support that.

Go http webserver doesn't support http 3 without external libraries. Nginx doesn't support http 3. Apache doesn't support http 3. node.js doesn't support http 3. Kubernetes ingress doesn't support http 3.

should I go on?

edit: even curl itself - which created the original document linked above - has http 3 just in an experimental build.

>Nginx doesn't support http 3

nginx do support it.

https://nginx.org/en/docs/quic.html

ah okay i was wrong there, mea culpa

The guy's point still stands - lots of popular software do not yet support http3.

And I see I was not that wrong; the module is still marked as "experimental" and not built by default.

https://nginx.org/en/docs/http/ngx_http_v3_module.html

Well this statement have to be precised.

caddyserver v2 supports HTTP/3 and it's an webserver written in go https://caddyserver.com/features

FYI: There is also an rust webserver which supports HTTP/3. https://v2.ferronweb.org/

Go built-in webserver.

> edit: even curl itself - which created the original document linked above - has http 3 just in an experimental build.

It's not experimental when built with ngtcp2, which is what you will get on distros like Debian 13-backports (plain Debian 13 uses OpenSSL-QUIC), Debian 14 and onward, Arch Linux and Gentoo.

Reference: https://curl.se/docs/http3.html

Yes and, at the same time practical support within programming language standard libraries & common tooling lags way behind: https://httptoolkit.com/blog/http3-quic-open-source-support-...

You will get most of the benefits of HTTP 3 even if your app libraries run HTTP 1.1, as long as the app is behind a reverse proxy that speaks HTTP 3.

I use HAproxy to get HTTP/3.

https://www.haproxy.org/

https://haproxy.debian.net/

https://www.haproxy.com/blog/how-to-enable-quic-load-balanci...

Yep, for example, Caddy (zero special configuration to enable HTTP 3)

Also apparently slower over fast connections https://arxiv.org/pdf/2310.09423

A decrease in throughput is a small price to pay for progress

Reply on news.ycombinator.com