Cloudflare Makes Open-Source h3i For HTTP/3 Testing & Debugging

[phoronix]

Phoronix: Cloudflare Makes Open-Source h3i For HTTP/3 Testing & Debugging

Cloudflare is ending 2024 by announcing a new open-source project: h3i for low-level HTTP/3 testing and debugging...

https://www.phoronix.com/news/Cloudflare-Open-Source-h3i

[hf_139]

Meanwhile nginx still has no stable HTTP3 support (it has it experimental).
All those huge corporations relying on nginx for over a decade, didn't profit nginx development at all.
The corpos rather made their own forks and rust rewrites, than contributing back, and then only give a fraction of their software to the community.

[Daktyl198]

Meanwhile nginx still has no stable HTTP3 support (it has it experimental).
All those huge corporations relying on nginx for over a decade, didn't profit nginx development at all.
The corpos rather made their own forks and rust rewrites, than contributing back, and then only give a fraction of their software to the community.

Corporations have pumped a ton of money into the nginx project. The fact that the nginx project is poorly run has nothing to do with corporations. Cloudflare has had a performant, open source HTTP/3 (QUIC) library available for over 5 years that the nginx devs could have either integrated directly (like the 3rd party nginx patch does) or copied from to re-write it in C. Instead they choose to spend their money not on developers implementing features users want, but on executives and marketing.

[peterdk]

Yeah, really like Cloudflare doing this. They seem to be invested in their software, but also share it with the rest. And it's nice if a heavy behemoth like Cloudflare builds software they run themselves on heavy workloads, benefits others.

[dev_null]

http3 is very bad protocol. Super overcomplicated and it is monolithic like systemd or even worse. Undebuggable. Not suitable for backends because it imposes encryption where it only hampers. Extremely hard to proxy / load balance traffic. No easy to compile and use C/C++ libraries.

As a developer I very hope http3 will die soon and in pain.

even a test tool is written in Rust to keep things super-complicated further. Its good though that these unlucky unhappy beings who have bad karma and have to deal with it will suffer a little less now

[bacteriamanicure]

http3 is very bad protocol. Super overcomplicated and it is monolithic like systemd or even worse. Undebuggable. Not suitable for backends because it imposes encryption where it only hampers. Extremely hard to proxy / load balance traffic. No easy to compile and use C/C++ libraries.

As a developer I very hope http3 will die soon and in pain.

even a test tool is written in Rust to keep things super-complicated further. Its good though that these unlucky unhappy beings who have bad karma and have to deal with it will suffer a little less now

Heads up: The people you're trying to reach stop listening when you go "Rust bad"

[hf_139]

Corporations have pumped a ton of money into the nginx project. The fact that the nginx project is poorly run has nothing to do with corporations. Cloudflare has had a performant, open source HTTP/3 (QUIC) library available for over 5 years that the nginx devs could have either integrated directly (like the 3rd party nginx patch does) or copied from to re-write it in C. Instead they choose to spend their money not on developers implementing features users want, but on executives and marketing.

Cloudflare only gives you little scraps and then stops development on it. It's a big unknown if quiche is production ready and i don't think cloudflare themself uses it anymore? At least its development is pretty much dead.
The nginx management might be bad, but i am sure that they won't oppose a corpo paid developer who actually upstreams changes. For all the billions of $$$ that got made on top of nginx, the contributions of corpos are really pathetic. Same with redis, btw., corpos only got interested into paying for its development once redis changed to a license that would make it impossible for them to use.... and then they threw their corporate redis fork onto the Linux Foundation, because they still preferred to get a community of fools to work for them for free.

[browseria]

http3 is very bad protocol...

Why?

...Super overcomplicated and it is monolithic like systemd or even worse...

http3 (RFC 9114) is almost exactly the same as http2 (RFC 9113) and http1 (RFC 9112), so unless you feel HTTP/2 and HTTP/1 are overcomplicated, http3 isn't any worse. Monolithic - I don't see how, http is strictly an application layer protocol, it delegates everything not application related to a lower level protocol, the very opposite of monolithic. I don't see how this relates to systemd at all...can you explain that?

...Undebuggable. Not suitable for backends because it imposes encryption where it only hampers. Extremely hard to proxy / load balance traffic...

It is true that encryption is mandatory in http3, but it happens at the security layer via TLS, not in the http3 protocol, so http3 changes nothing there. It is just as "debuggable" as http2 with TLS. http3 uses QUIC (RFC 9000) over UDP instead of TCP in the transport and network layers, this can cause problems with some firewalls that don't have good support for either QUIC or UDP, but that isn't a problem of the http3 protocol.

...No easy to compile and use C/C++ libraries...even a test tool is written in Rust to keep things super-complicated further...

A quick google search on "http3 c library" and "http3 c++ library" shows that this is not the case. Heck, even curl provides native (albeit experimental) http3 support, and it's creator, Daniel Stenberg has written a book on http3 and largely addresses your criticisms in it.

[dev_null]

Why?



http3 (RFC 9114) is almost exactly the same as http2 (RFC 9113) and http1 (RFC 9112), so unless you feel HTTP/2 and HTTP/1 are overcomplicated, http3 isn't any worse. Monolithic - I don't see how, http is strictly an application layer protocol, it delegates everything not application related to a lower level protocol, the very opposite of monolithic. I don't see how this relates to systemd at all...can you explain that?



It is true that encryption is mandatory in http3, but it happens at the security layer via TLS, not in the http3 protocol, so http3 changes nothing there. It is just as "debuggable" as http2 with TLS. http3 uses QUIC (RFC 9000) over UDP instead of TCP in the transport and network layers, this can cause problems with some firewalls that don't have good support for either QUIC or UDP, but that isn't a problem of the http3 protocol.


A quick google search on "http3 c library" and "http3 c++ library" shows that this is not the case. Heck, even curl provides native (albeit experimental) http3 support, and it's creator, Daniel Stenberg has written a book on http3 and largely addresses your criticisms in it.

Okay, I'll elaborate a little bit more, if it's not obvious.

1. HTTP3 re-implements other protocols but just in a different way. It has its own TCP (QUIC), it has it's own TLS, it has its own WebSocket, I'm surprised a little bit it doesn't have its own more secure and robust UDP or OSI Layer 2 sub-protocol. So it's bloating and complication already, then you cannot separate one from another.
2. Next thing are HTTP3 streams. There is webtransport API, let's assume I want to use it instead of WebSocket. My natural desire is to use nginx (or whatever server) to reverse-proxy webtransport to some backend service which may be independent of main website (let's say website is rendered using PHP, wordpress, laravel not so important) but I want WebTransport to be handled by C++ service or by Node JS or by Python.... so nginx (or any other server) needs to decompose this HTTP3 connection to two ones. At least at the moment of the start of July 2024 I didn't find a solution how I can do it.
3. HTTP1(.1) is text, you can clearly see what's going on. HTTP2 is binary, you need a special traffic analyzer in order to understand what's going on, it's not plain, it's complex by design
4. HTTP2 is also wrong. HTTP3 is just further development in the wrong direction. It tries to solve TCP problem of HTTP2 (what actually is clear even before you start design of it, if you think about it just a little bit upfront) and okay, it solves it with QUIC making things even more harder to debug and understand.
5. So why all of this (HTTP2 and 3) Just on behalf of making connections faster and on behalf of saving tiny amount of trafic (I say tiny because a web-sites are huhely bloated nowadays and it will be 1 MB or so easily because of high-res pictures, while all HTTP3 saved you couple of kilobytes) and with faster connections there may be another solution, like what TLS 3.0+ gives.
I want to say that complexity of HTTP3 doesn't worth it. You put 10005000 effort to complicate things and get tiny almost unmeasurable benefit.

In regard to the libraries as I see it's slightly enhances, last time I checked curl didn't work with it or I failed to launch it in a limited time. Though curl states it's experimental and it depends on another stack of libraries, i.e. if you want to use it in your own project you will need to deal with all the dependencies, while there are no such ones for regular http. Interesting if it's possible to use the streams from it, or it only gives very-high level "just test that it works somehow" support.

It doesn't deny the fact I want to state that it's overcomplicated without enough necessity. I.e. tiny benefits GREAT overcomplication.

[aviallon]

http3 is very bad protocol. Super overcomplicated and it is monolithic like systemd or even worse. Undebuggable. Not suitable for backends because it imposes encryption where it only hampers. Extremely hard to proxy / load balance traffic. No easy to compile and use C/C++ libraries.

As a developer I very hope http3 will die soon and in pain.

even a test tool is written in Rust to keep things super-complicated further. Its good though that these unlucky unhappy beings who have bad karma and have to deal with it will suffer a little less now

What I personally do not understand is using a layered protocol (QUIC), over UDP, while there already exist a very old protocol already doing what was needed: SCTP.
It provides a packet based exchange (instead of streams), can optionally use packet retransmission, can use multiple paths, and is already supported by *NIX since… ages.