What do you all think about HTTP/3 AKA QUIC?

[trosel]

The few negative comments in this thread are the most insightful ones to me: https://news.ycombinator.com/item?id=37777050

I wondered if Reticulum people have the same critiques of HTTP/3

[markqvist]

Instead of reinventing excellent short-format prose, I will just quote people more eloquent than me:

Imagine you are holding a 200 requests/page bag of excrement and it’s generating too much load on all systems involved.

What do we do? Empty the bag? No, we do not. That doesn’t scale.

We create the most elaborate, over the top efficient bag-of-excrement-conveyer-belt you ever came across. We’ll move these babies in no time flat.

Don’t worry about side-loading 24 fonts in 3 formats and whatnot. Especially do not worry about having to load three different trackers to “map” your “customer journeys”.

No sir, your customer journeys are fully mapped, enterprise-ready and surely to be ignored by everyone. We got you covered with QUIC. Reimagining “data transport”, for your benefit.

• SanderNL

And:

Let's put it this way, imagine going to the doctor, complaining about how you’re putting on a little extra weight, your legs are getting tired, and you’re short of breath. The doctor, instead of suggesting the radical idea of a diet or exercise, goes, “Aha! What you need, my friend, is a super-fast, mechanized, all-terrain wheelchair that can drift corners at 60 mph. That’ll get you to the fridge and back in record time, ensuring your problematic lifestyle remains unscathed by reality!”

When life gives you lemons, don’t make lemonade. Construct an intricate, high-speed, international lemon delivery system, ensuring everyone gets to share in your citrusy misery, QUICly.

So here’s to QUIC, the glorious facilitator of our cybernetic decadence, ensuring that the digital freight train of unnecessary features, exhaustive trackers, and bandwidth-gulping page elements gets to you so fast, you won’t have time to realize you didn’t need any of it in the first place.

Buckle up, folks, because the future of web browsing is here and it’s screaming down the information superhighway like a minivan packed with screaming toddlers, on fire, yet somehow, inexplicably, punctual.

• satellite2

I could elaborate, but I really don't see the need.

[trosel]

One complaint I saw was that QUIC (HTTP3) was designed for corporations and not for individuals.

Does Reticulum fill in for this problem then?

[faragher]

Your broader question aside, it can't be answered directly. Current HTTP requests are over TCP. QUIC is over UDP apparently (which can be faster but also removes features which may be re-implemented in software to ensure compatibility, thus being a wash). Reticulum is similar to TCP or UDP, and therefore can't be compared to these standards.

If you're curious about how Reticulum compares to TCP/UDP, the theoretical performance is irrelevant. TCP has nearly 50 years worth of optimization and dedicated hardware. The ecosystem is built for TCP and any change, Reticulum or HTTP3, will require new browsers and infrastructure. UDP has the advantage of being a current standard, so it will probably be an easier transition.

[faragher]

In an attempt to be a terrible resource, I will comment on something I know nothing about, am not interested in, and know only through the comments of others. :D

I can only speak to the fundamental issues that this seeks to address. First, two projects I worked on, then two hardware configurations, just to frame my understanding of the problem.

I was contracted to make a web page once. The two conditions were that it was to be as small as possible and that it was made by hand (for similar reasons). I think I got the entire web page down to 29 kilobytes per load, images and all. Tiled images, a lack of scripting, and efficient compression made the page very bandwidth efficient and being flat it had no client-side CPU demands after loading (no server-side scripts, either)

Another project had me scraping news sites. A single Yahoo News side was one megabyte of code. No images, no videos, no CSS or linked scripts, that single http request transferred a megabyte of data, most of which was scripts to be run on the local machine. Images were mostly uncompressed and often transferred at full size and scaled down on my end, thus increasing both bandwidth and resource usage (cycles and memory) on my end. Considering these were generated dynamically from database requests and external calls, their load must be similarly large.

Ignoring the pre-Internet and Prodigy era connections, most of my early years on the Internet were spent on a 56*kbps modem. (*Due to Federal restrictions, data transfer was actually capped at 52kbps, something every modem in the world told you on the box, but we all called it 56k because reasons) I remember running a Pentium 2 in the 100 MHz range with about 400 megs of RAM (yes, I think it was 256 and 128, but I was scavenging, not looking for performance). I couldn't use an MP3 player and do anything else, but I could surf the web just fine.

These days I have four hyperthreaded cores, 32 gigs of RAM, and a four gigabyte commit for Chrome. I can play games, listen to music, watch a video, and stream local video streams at the same time . . . but sometimes web browsing does get slow.

The three problems are scope, availability, and what I'll term "nonsense" because my usual term is not safe for polite discussion.

Scope: Web browsers used to deliver flat text and images. Things like Flash were the exceptions, and were transferred once as a package and life was good. HTML5 and various other updates made it so dynamic web pages quickly became the norm, streaming data back and forth, infinitely scrolling, and generally turning a page viewer into the world's worst virtual machine. Is it convenient to use a web browser to access a library, stream a security camera, run a word processor, or control farm equipment? Yes. Is it a lossy procedure as opposed to using dedicated software? It doesn't have to be, but it usually is.

Availability: People have tremendous processing power and storage space in their computers and even phones. I'm pretty sure my $4 ESP32 outperforms my old 386. At least before the $1000 upgrade to 8 megs of RAM. ($2000-3000 today) Always-on Internet also means the developer can expect to transfer data in both directions through the life of the connection. Why serve one ad when you can cycle them? The browser can send back so much information, why not catalog it and sell it? Why pay someone to write tight code when a library is kinda efficient and you can just expect the processing power of the server and client to power through in a reasonable timeframe?

As an aside, I am still floored that Intermediate Languages and JIT compilers are a thing. Compiling "Hello World" used to be a chore, now things just generate machine code on the fly. Amazing and absurd.

"Nonsense:" The consumer is the product, and scraping data from them, from agent to browser resolution to notifications to location sharing, they want data to target and sell. This needs significant code and bandwidth to really be effective. Then there's the nonsense like Facebook making a barely functional garbage mobile page to encourage App usage, which can track more things and send push notifications. And "We don't support your browser" to make sure all of these bloatware "features" are available to send home data.

To boot: if you build a bigger pipe, they'll just send more . . . water.

Our latency is shockingly low and our throughput insane. Even with wireless access points or even 5G uplinks. I'm still using LTE and am amazed at what I can get. Even when I'm in places with only basic cellular data on a roaming plan, I can do so much . . . just not Facebook, Yahoo, or the bloated crew.

Final point: Citrix-style thin clients are dial-up era technology. I still use them over slow links. Terminal sessions, well, we've seen what RNode can do with a terminal session. You can make something like SSH, or you can do a full HD stream like GeForce Now (although even they do some clever compression). The problem is that everyone seems to think they're the only thing the client is doing and "if they don't have the hardware, they can always upgrade."

The problem will continue until they stop running the Red Queen's Race and realize a little more efficiency will do more than all the hardware and protocol changes in the world.

[markqvist]

And in case anyone reading doesn't care much for sarcastic short-form, this is the real answer.

[kc1awv]

To boot: if you build a bigger pipe, they'll just send more . . . water.

What ever happened to 'efficiently moving important data from point A to point B'? Oh, that's right... marketing. Because who cares if that important email gets to you? We've got something to sell! Introducing the HyperBlender 9001! You need it, because we told you so. Be the envy of your friends! You don't want them thinking you can't afford one, right? RIGHT?!

[faragher]

The 9001? That's six months old! You need the 9002! It has a new hat.

[faragher]

Also, as hesitant as I am to quote a line from a random manga I read in the 90s, it's mainstream enough now.

"You should choose a machine for what you need it to do, not for the specs."

So by and large, I have to simply wonder if this is actually needed or just the flavor of the week.

[Charlotte-br560]

While HTTP/3 (QUIC) offers promising advancements, it's essential to address concerns raised regarding performance overhead and complexity. It's valuable to weigh these considerations carefully. As for Reticulum's perspective, it would be beneficial to hear their insights directly.