12 ms·

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

• miohtama 3y ago
  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.
  • peoplefromibiza 3y ago
    > - 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
    • Spivak 3y ago
      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.
      • peoplefromibiza 3y ago
        > 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.
        • Spivak 3y ago
          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.
        • megous 3y ago
• satellite2 3y ago
  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.
  • pdimitar 3y ago
    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.
    • ToucanLoucan 3y ago
      > 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.
• rrdharan 3y ago
  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..
  • satellite2 3y ago
    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.
• djha-skin 3y ago
  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.
  • redundantly 3y ago
    <insert 'Why Don't We Have Both?' meme here> 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.
    • djha-skin 3y ago
      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.
      • deleted 3y ago
        [deleted]
  • BitPirate 3y ago
    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.
• afavour 3y ago
  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.
  • SanderNL 3y ago
    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.
  • jeroenhd 3y ago
    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.
    • Karrot_Kream 3y ago
      > 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
• blauditore 3y ago
  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.
• simiones 3y ago
  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).
  • xorcist 3y ago
    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.
    • taway1237 3y ago
      isn't QUIC the new TCP in this case?
      • NoGravitas 3y ago
        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.
• cryptonector 3y ago
  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.
  • SanderNL 3y ago
    “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.
    • Dylan16807 3y ago
      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.
• agumonkey 3y ago
  time to browse some gopher pages
• bastawhiz 3y ago
  > 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.
  • SanderNL 3y ago
    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.
    • bastawhiz 3y ago
      > 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.
• dark-star 3y ago
  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
  • SanderNL 3y ago
    The problem is ditching it for .. what? Bloated messes. Be careful throwing babies out with bath waters.
• deleted 3y ago
  [deleted]