| ▲ | ckbkr10 6 hours ago |
| Sounds overly complicated, I doubt this will have a widespread adoption |
|
| ▲ | gucci-on-fleek 5 hours ago | parent | next [-] |
| 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... |
| |
| ▲ | mgaunard 5 hours ago | parent [-] | | and then cloudflare converts that to http/2 or even 1.1 for the backend | | |
| ▲ | vanviegen 5 hours ago | parent [-] | | So? Those protocols work fine within the reliable low latency network of a datacenter. | | |
| ▲ | wongarsu 4 hours ago | parent [-] | | 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 | | |
| ▲ | klempner 4 hours ago | parent | next [-] | | 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. | | |
| ▲ | hshdhdhehd 3 hours ago | parent [-] | | 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. |
| |
| ▲ | immibis 8 minutes ago | parent | prev [-] | | 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. |
|
|
|
|
|
| ▲ | ofrzeta 5 hours ago | parent | prev | next [-] |
| "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 |
| |
| ▲ | karel-3d 5 hours ago | parent | next [-] | | 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. | | | |
| ▲ | pimterry 5 hours ago | parent | prev [-] | | 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-... | | |
| ▲ | taffer 4 hours ago | parent [-] | | 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. | | |
|
|
|
| ▲ | frmdstryr 2 hours ago | parent | prev [-] |
| Also apparently slower over fast connections https://arxiv.org/pdf/2310.09423 |
