Hacker News Reader

Comment by SanderNL | Hacker News Reader

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.

Edit: Of course I didn’t read the article, but now I did and it’s somehow worse than I thought. “Why TCP is not optimal for today’s web”: no answers. There are literally no answers here. Other than, TCP is old. Old things are difficult.

View on HN

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.

While I partially sympathize and agree with your pessimism, you underestimate the impact of regular users disengaging from various places of the internet exactly because it gets more and more meaningless, watered down, and doesn't provide any value over super brief validation.

And while that super brief validation is still a very strong hook for metric tons of people out there, people do start to disengage. The sense of novelty and wonder is wearing off for many. I'm seeing it among my acquaintances at least (and they are not the least bit technical and don't want to be).

That the future of the internet looks very grim is unequivocally true though. But there's a lot that can and will be done still.

> While I partially sympathize and agree with your pessimism, you underestimate the impact of regular users disengaging from various places of the internet exactly because it gets more and more meaningless, watered down, and doesn't provide any value over super brief validation.

Thank fuck. Burn it down. Take us all the way back to vBulletin, MSN Messenger and Limewire. I have seen the future and it sucks. The past sucked too but at least my grandparents weren't getting radicalized by HillaryForJail2024 on Facebook.

The market for electric wheelchairs/mobility scooters is doing really well, now that you mention it!

That reminds me of this classic 1990s internet description http://stuartcheshire.org/rants/InfoHighway.html

That pitch for the most metal Mad Max sequel was pure molten gold and still holds up.

You made my week, I think this is my favorite piece of writing in a while.

"A little kid on a tricycle with a squirtgun filled with HYDROCHLORIC ACID. "

I was going to write something along the lines how happy I am that someone solved the problem of the time to first byte when at least two javascript frameworks and three telemetry packages, each including a dozen of resources, are required for just about any page. But you put it so much more eloquently.

If you do not know the answer yet,as it sounds like you do, but there is a ting of rant there, let me expand what was said in the article:

TCP/IP was build for 80s/90s when

- Amount of data transferred was low

- Data access patterns were different

- Most TCP/IP was in university networks

- There were no consumer users

- Everyone on Internet could be trusted

Today we have

- 3B more people using Internet

- 5B people living in authoritative regimes where the government wants to jail them for saying wrong thing on Internet

- Mobile users

- Wireless users (subject to different packet loss conditions)

- You can stream 4k movies in your pocket

- You can search and find any piece of information online under one second

To get the low latencies and high bandwidths for mobile links TCP/IP can do it, but QUIC and HTTP/3 does it much better. Plus it's always encrypted, making all kind of middlebox attacks harder.

> - 5B people living in authoritative regimes

it's actually 1.9B

> where the government wants to jail them for saying wrong thing on Internet

that happens across all the spectrum of types of systems of government

And you put those two statements together and you're back to the 5B number. I don't really care if your system of choosing leaders is democratic elections if at the same time you're burning books.

> and you're back to the 5B number

no, if you include anybody in the World, you are back at 7B

The point was that you contradicted yourself: if 3B people use the internet (as you said) only 3B people are in danger of being spied through the internet.

> I don't really care if your system of choosing leaders is democratic elections

Unfortunately the dictionary does.

And one does not imply the other, I mean it's one thing to have cameras in the streets for (allegedly) safety purpose and another thing entirely to be hanged from a crane if you're gay.

Let's not pretend that everything is the same everywhere just because we don't like or agree with a particular aspect of what happens in our own country.

I think you meant to reply to someone else, I said nothing about the internet only that the math of

"5B people live under authoritarian regimes."

"Actually it's only 1.9B if you use my definition of authoritarian, the rest are just authoritarian behaviors."

Okay so to everyone but you 5B live under authoritarian regimes then -- "Not technically authoritarianism" is not something you should feel the need to say about countries you're arguing aren't authoritarian.

> another thing entirely to be hanged from a crane if you're gay

I know right, we're so much more civilized. We just lock them up if they do gay stuff in public, require sexual education to teach that homosexuality is an "unacceptable lifestyle choice", define consensual sex between two homosexual teenagers as rape, and and have a standing legal theory that people just can't help it if they are thrown into a blind rage and attack a gay person for being gay that in 2023 is still a legal defense in 33 states. And that's just the gays, the political punching bag de jour is trans people and they get it even worse.

> no, if you include anybody in the World, you are back at 7B

you should update your numbers

While trimming fat from excessively complex web pages would be nice, HTTP over TLS over TCP has some very clear fundamental inefficiencies that need to be addressed sooner or later.

The biggest one is that there is just no reason to negotiate multiple encrypted sessions between the same client and server just to achieve multiple parallel reliable streams of data. But since TLS is running over TCP, and a TCP connection has a single stream of data (per direction) you are forced to negotiate multiple TLS sessions if you want multiple parallel streams, which needlessly uses server resources and needlessly uses network resources.

Additionally, because TCP and TLS are separate protocols, TCP+TLS connection negotiation is needlessly chatty: the TLS negotiation packets could very well serve as SYN/SYN-ACK/ACK on their own, but the design of TCP stacks prevents this.

I believe it would be theoretically possible to simply set the SYN flags on the Client Hello and Server Hello TLS packets to achieve the TCP handshake at the same time as the TLS handshake, but I don't think any common TCP/IP stack implementation would actually allow that (you could probably do it with TCP Fast Open for the Client Hello, but I don't think there is any way to send the Server Hello payload in a a SYN-ACK packet with the default stacks on Linux, Windows, or any of the BSDs).

And, since you'd still need to do this multiple times in order to have multiple independent data streams, it's probably not worth the change compared to solving both problems in a new transport protocol (the way QUIC has).

The right way would probably be to implement a real TCP replacement. Look at SCTP for inspiration. There are certainly things that could be improved and would be even nore useful than multiplexing, such as working congestion control and multipath.

I understand that HTTP is the new TCP, but I don't have to like it.

isn't QUIC the new TCP in this case?

Sort of? Except being implemented on top of IP, like TCP and UDP are, it's implemented on top of UDP, mainly so that existing middleboxes don't have to be updated. Either a TCP replacement or a major version update to TCP would be the Right Thing, but we can't have good things.

That's.... exactly what QUIC is? I don't understand your comment

QUIC runs over UDP. In this sense it is more like a tunneling protocol than a layer 4 one.

Is there anything in the design of UDP that constrains what QUIC would have wanted to do? If it used a different ID in the IP packet, would it really change anything about the UDP headers?

I would say UDP is such a simplistic protocol you can actually see it more as a protocol-building framework than a layer in-and-of itself.

If everything is just datagrams, what good are datagrams? Are we forever bound to use deep inspection just to keep acceptable service in our networks?

Having a separate layer for data connections was a good idea for many reasons which have been clear for over four decades.

I'm not sure what you mean. What does UDP have to do with acceptable service? If you want to prioritize certain kinds of traffic, you either to do deep packet inspection, or you trust IP-level QOS info (which you probably shouldn't). There is no other way. No one sane prioritizes UDP in general, you prioritize things like VoIP, for which you anyway need to do DPI.

And separating data connections from encryption has in fact proven to be a a bad idea over those 40 years.

The difference seems pretty academic. Practicality >> purity, especially when trying to get new networking protocols deployed to ~4e9 people

What a contrast HN provides. The top post is some really interesting detail about the QUIC protocol, the things it can do and the efficiencies it enables. Immediately followed by this rant about web pages being too big these days.

The duality of Hacker News.

Welcome to the desert of the real. That's some real diversity for you.

Not everything that shines is gold my friend.

But I concede my comments are really ranty. Sorry about that. It's frustration.

Like a true HN centrist, I agree with both.

QUIC is really cool technology. It can solve a wide range of problems that aren't necessarily HTTP based.

However, HTTP/3 is using QUIC as a patch over badly designed websites and services.

QUIC doesn't solve the problem, it provides another path around the source of the problems. This blog was written by Akamai, a CDN that makes profits off the problem of "my website is too fat to lose quickly anymore". I don't blame them, they should sezie the opportunity when they can, but their view is obviously biased.

QUIC makes most sense for sites that can optimise it, like the Googles, Cloudflares, and Akamais of the world. For the average website, it's just another technology decision you now need to make when setting up a website.

> However, HTTP/3 is using QUIC as a patch over badly designed websites and services.

Most "modern bloated" SPAs are tiny. The default MSS for most TCP implementations is 1460 bytes, that's 1.42 kB max per packet. Just the TCP handshake packets themselves (3 * 1460) can hold almost as much data as it takes to get a standard SPA. This says nothing about the TLS handshake itself which adds another 3 packets to connection establishment. Most SPAs send small and receive small payloads; a compressed JSON exchange can easily fit in a single packet (1.42 kB.)

The actual amount of bandwidth on the wire between a server-side rendered "fast" app and a "modern bloated" SPA isn't very different, the difference is in how they send and receive data. SSR pages send a thin request (HTTP GET) and receive a large payload; generally the payload is much larger than the connection establishment overhead, so they make good use of their connection. On the other hand, a naive SPA will involve opening and closing tens or even hundreds of connections which will lead to a huge waste (6 packets per TLS+TCP connection) of overhead. QUIC makes it possible to have small connection-oriented request/response semantics on the internet with minimal fuss.

That said the problem with rants like GP's comment is that they don't serve to illuminate but serve to push on us, the readers, the author's agitated emotional state. Instead of having a discussion about bandwidth and connection overheads, or even trying to frame the discussion in terms of what "waste" really is, we get emotional content that begs us to either agree with an upvote or disagree with a downvote with nothing of substance to discuss. Any discussion website is only as strong as its weakest content and if content like this continues to get lots of upvotes shrug

> Just the TCP handshake packets themselves (3 * 1460) can hold almost as much data as it takes to get a standard SPA.

I have no idea in what reality you live where you encounter SPAs of a few Kbs. Don’t even know what to say if that’s your experience.

> That said the problem with rants like GP's comment is that they don't serve to illuminate but serve to push on us, the readers, the author's agitated emotional state.

You are absolutely right there. I will try to refrain from these “frustration posts” in the future. Sorry about that.

> I have no idea in what reality you live where you encounter SPAs of a few Kbs. Don’t even know what to say if that’s your experience.

Let's look at a SPA version of HN [1] and compare it against base HN. This base SPA page fetches 21 KiB of data. The base version of HN fetches 36 KiB of data. Most SPAs are much less information dense and have a lot more CSS and media than non-SPA websites. In a world without SPAs these sites would not be leaner, they would instead just insert tons of CSS style links and img tags to fetch the media themselves, resulting in the same amount of bandwidth.

If your argument is that websites should be leaner regardless, well in my experience most users would rather put up with a slow good-looking page than a fast spartan one. It's a hallmark of a nerd that's willing to cut corners just to get access to the information they want.

[1]: https://hn.premii.com/

Although HN is a very bad example of an “average” anything, it’s still a good catch. Thanks for reminding me. SPAs can definitely be leaner than regular websites. Never disagreed on that one to be honest. SPA or not is just a delivery method. Clean SPA or clean “regular” site, it’s all good.

Again I was just venting and that sucks. Yelling at the cloud(s).

To be honest, I share your aesthetic principles, but other than the other nerds in my life nobody else does shrug. I remember the '90s pop-up hell and hated that too. I just spend my time on the net in places that I enjoy.

This comment has a real grain of truth to it: reducing request load on your users has way more bang for the buck than changing protocols.

At my company we did a test for HTTP2 and HTTP3 versus HTTP 1.1 in South America on a 4G connection. We found that Netflix loaded in less than 2 and 1/2 seconds regardless of what protocols the client supported.

We determined that if we enable the HTTP2 or 3, We would save perhaps a second or two load time, but that if we reduced the request load we could perhaps save on the order of tens of seconds.

Joking aside, we should be happy for any improvement that can be obtained. A single second saved for a single connection on its own is insignificant, but dozens or hundreds of connections for a single user, multiplied by the thousands or possibly millions of users, that's a huge amount of time saved.

Sure, yeah, it's all sunshine and roses for the client, but I'm a DevOps engineer. It is very difficult on the server side.

You can enable it on CDNs pretty easily these days, but enabling it on the API side is more difficult. The nginx ingress controller for kubernetes doesn't support HTTP3 yet. It supports HTTP2, but I've heard that you can get into trouble with timeouts or something if you don't tune HTTP2 right. It does look like it's doable though, certainly more doable than HTTP3.

HTTP2 is a moderate lift from a systems administration standpoint, but it's also a risk. It means changing the infrastructure enough that outages can occur, so that I'd rather do this lift when things are more stable and the holiday season is over.

I'm pretty sure that Netflix operates a decent amount of servers in South America which would result in low latency connections.

HTTP/3 really starts to shine once high latency and/or packetloss are involved.

Translation:

  Making the network more efficient
  enbiggens the amount of excrement
  you can put in that bag.
  
  Efficiency bad!!

> Edit: Of course I didn’t read the article, but now I did and it’s somehow worse than I thought. “Why TCP is not optimal for today’s web”: no answers. There are literally no answers here. Other than, TCP is old. Old things are difficult.

I think you just didn't read the article period. That QUIC hides a lot of metadata that TCP doesn't was covered, for example, and there's stuff about multipath, etc. And clearly, yes, TCP is old, and a lot of the extensions done to it over the years (e.g., window scaling, SACK) are great but still not perfect (especially window scaling) and it's getting harder to improve the whole thing, and then there's congestion control. But TCP was never going to be replaced by SCTP because SCTP was a new protocol number above IP and that meant lots of middleboxes dropped it, so any new thing would have to be run over UDP, and it would have to be popular in the big tech set, else it wouldn't get deployed either.

“Efficiency” for whom and for what? Think deep before you all bow down before our overlords and ditch clear and simple protocols for “efficiency”.

I know what QUIC is for and I know it’s strengths. I just want the web to be simple and accessible. It’s great Netflix and friends can stream content efficiently. It’s another thing to push this to the “open web” and declare it The Protocol.

Sometimes a webpage just wants to have a bunch of images, which is not a bad thing, and something like this helps it load better.

> It’s great Netflix and friends can stream content efficiently.

This barely affects streaming. Streams work fine with a single TCP connection.

This is like arguing chip companies shouldn’t make chips that are faster and more power efficient just because the web sucks and Electron is a pig.

Sure, we should just make chip innovation illegal and mandate Gemini instead of HTML/JS, I’m sure that’ll work out great..

That's actually an excellent idea you've got here. Let's make chip companies design weight loss chips, were Electron running apps are forced to run on a purposely built slow core, like your doctor prescribing going to the gym.

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

Sorry, this is a purely garbage comment. A "web 1.0" page with a photo gallery of a few hundred thumbnails can take a dozen seconds or more to load on my phone over 5G. Why? Because browsers limit you to six HTTP/1.1 connections each downloading a single image at a time, requested serially one after the other. A few big images? The rest of the page stops loading (regardless of the importance of the assets being loaded) until those images are done. It has nothing to do with how much bandwidth I have, it has everything to do with the insubstantial nature of HTTP/1.1 and TCP as protocols for downloading multiple files.

For literally decades, we've been jumping through hoops to avoid these problems, even on "web 1.0" sites. In 2006 when I was building web pages at a cookie cutter company, rounded corners were done with "sliding doors" because loading each corner as its own image was too slow (and border-radius hadn't been invented). Multitudes of tools to build "sprite sheets" of images that are transformed and cropped to avoid loading lots of little icons, like the file type icons on web directories of old. The "old web" sites that HN adores tend to run astoundingly badly on HTTP/1.1.

Not only do H2 and H3 fundamentally solve these _generational problems_, they've made the initial loads far faster by reducing the overhead of TLS handshakes (yet another sticking point of TLS holdouts!) and improved user privacy by encrypting more data. H2 and H3 would _absolutely_ have been welcomed with open arms fifteen years ago, long before the age of "24 fonts in 3 formats" because the problems were still present back then, regardless of whether you'd like to pretend they didn't.

We should be celebrating that these protocols made _the whole internet_ faster, not just the bloated ones that you're upset about.

That has absolutely no bearing on TCP. A bunch of images could load on a single TCP connection just fine.

Don’t confuse browsers and HTTP with the underlying protocol.

TCP has its flaws, but I don’t see how HTTP and its request/response monopoly is one of them.

> A bunch of images could load on a single TCP connection just fine.

"Just fine" is subjective here. Of course they could load, but with certain performance characteristics.

> That has absolutely no bearing on TCP

It does, actually. Every packet requires a full round trip done sequentially. H3 significantly relaxes this because it has an understanding of what's actually being transmitted. An unreliable connection will inherently be far slower over TCP than over H3 because any delayed or lost packets or acks need to be retransmitted before the next packet goes out. H3 makes intermittent packet loss affect fewer files being transferred and reduces the impact of latency on a packet-by-packet basis.

The vast majority of Internet users aren't on highly reliable broadband. H3 is a win for all of those people.

Ah! That’s interesting. I have to do some more reading instead of yelling at the clouds. Thanks for that.

This is what always happens, because it's not the same people/teams/companies filling the bags and building the conveyor belts, and because it's easier that way.

Another reason is that people are reluctant to give away any sort of convenience or vanity (a few nicer pixels in their website design) just for saving someone else's resources (bandwith/data/latency of server & and user). For the same reason people are driving SUVs in cities - it's a horrible misfit, but makes them feel good about very marginal benefits.

I think the problems of TCP (especially in a network with high latency spikes, non-negligible packet drop rates or when roaming through multiple networks while driving 160kp/h on the Autobahn) are pretty obvious, even if you leave the security/encryption aspect out of the picture... But maybe that's only me

The problem is ditching it for .. what? Bloated messes.

Be careful throwing babies out with bath waters.

time to browse some gopher pages

Reply on news.ycombinator.com