5 ms·

So we needed HTTP2 to deliver ads, trackers and bloated frontend frameworks faster. And now it delivers attacks faster too.

Borg3 3y ago
[flagged]
shepherdjerred 3y ago
Are you suggesting that we didn't need HTTP2? What's the real alternative here?
- Etheryte 3y ago
  Nothing in their comment claims that, there's no need to bring absurd strawmen into the discussion.
  - ramranch 3y ago
    It does strongly imply it. HTTP2 is needed for more than just the bloatware of the modern internet.
  - shepherdjerred 3y ago
    I'm just trying to figure out what the parent was trying to communicate, since the comment by itself didn't add much to the discussion. It seems that they're more upset by the state of web development today than they are by HTTP2 or anything else that this thread pertains to.
  - tsimionescu 3y ago
    The comment lists three negative things as "the reason we needed HTTP/2". I don't even see how you could read it other than implying that HTTP/2 was not actually necessary.
- the8472 3y ago
  In some alternative history there would have been a push to make http 1.1 pipelining work, trim fat from bloated websites (loading cookie consent banners from a 3rd party domain is a travesty on several levels) and maybe use websockets for tiny API requests. And the prioritization attributes on various resources. Then shoveling everything over ~2 TCP connections would have done the job?
  - comex 3y ago
    Personally, as a website visitor and occasional author, I don’t want the performance to be good enough to ‘do the job’. I want it to be as fast as possible. I want it to be instant. For that we need unbloated websites and better protocols. It’s not a competition. After all, you don’t need bloat to suffer from head-of-line blocking. You just need a few images. (Though, personally I’m a much bigger fan of HTTP/3 than HTTP/2. With a more principled solution to head-of-line blocking and proper 0-RTT, HTTP/3 makes a stronger case for why we need a new protocol than HTTP/2 did. I don’t know why HTTP/2 had to exist at all, really, when QUIC already existed by the time HTTP/2 was being standardized. Oh well.)
    - the8472 3y ago
      > It’s not a competition. But it is in the context of the 3-way tradeoff we're talking about here. complexity of the site vs. load time vs. protocol complexity > You just need a few images. On the HTTP level those can be deferred after the html/styles/js. Then you already have the content. What on your site would be "blocked" at that point? It's just images holding up each other. On the TCP level SACK and FRTO should resolve most instances of HOL after 1 RTT. It's not perfect but I suspect a lot of people experience "slowness" not because the underlying protocols are bad but because they're on old implementations. Or because they're on networks with bufferbloat. Upgrade those and we don't need those complex workarounds. As for HTTP/3... it's a mixed bag. The basic idea is great. The execution is another googleism. They didn't have the patience to get it into OSes, so now every client has to implement its own network stack which multiplies the things that need patching if something goes wrong. And it runs over UDP instead of being a different transport on the IP level like SCTP. And TLS is a good default but the whole CA-thing shouldn't have been mandatory. And header compression also seems like a cure for a disease of their own making, compare which the number of headers you need for HTTP 1.0.
- bsder 3y ago
  SCTP (Stream Control Transmission Protocol) or the equivalent. HTTP is really the wrong layer for things like bonding multiple connections, congestion adjustments, etc. Unfortunately, most computers only pass TCP and UDP (Windows and middleboxes). So, protocol evolution is a dead end. Thus you have to piggyback on what computers will let through--so you're stuck with creating an HTTP flavor of TCP.
  - murderfs 3y ago
    QUIC (the basis for HTTP/3) is basically the spiritual successor to SCTP, except with TLS baked in, so compared with SCTP+DTLS, connection establishment requires significantly fewer roundtrips (0 round trips for session resumption, 1 roundtrip at worst, compared to 4 or so for DTLS).
jeroenhd 3y ago
HTTP/2 makes the browsing experience of high-latency connections a lot more tolerable. It also makes loading web pages in general faster. Luckily, HTTP/1.1 still works. You can always enable it in your browser configuration and in your web servers if you don't like the protocol.
- tlamponi 3y ago
  > HTTP/2 makes the browsing experience of high-latency connections a lot more tolerable. It also makes loading web pages in general faster. HTTP/3 does that in my experience (lots of train rides with spotty onboard Wi-Fi) quite a bit better though. As HTTP/2 is still affected by head-of-line blocking and a single packet loss can block all other streams, even if the lost packet didn't hold data for them.

Borg3 3y ago

[flagged]

shepherdjerred 3y ago

Are you suggesting that we didn't need HTTP2? What's the real alternative here?

Etheryte 3y ago
Nothing in their comment claims that, there's no need to bring absurd strawmen into the discussion.
- ramranch 3y ago
  It does strongly imply it. HTTP2 is needed for more than just the bloatware of the modern internet.
- shepherdjerred 3y ago
  I'm just trying to figure out what the parent was trying to communicate, since the comment by itself didn't add much to the discussion. It seems that they're more upset by the state of web development today than they are by HTTP2 or anything else that this thread pertains to.
- tsimionescu 3y ago
  The comment lists three negative things as "the reason we needed HTTP/2". I don't even see how you could read it other than implying that HTTP/2 was not actually necessary.
the8472 3y ago
In some alternative history there would have been a push to make http 1.1 pipelining work, trim fat from bloated websites (loading cookie consent banners from a 3rd party domain is a travesty on several levels) and maybe use websockets for tiny API requests. And the prioritization attributes on various resources. Then shoveling everything over ~2 TCP connections would have done the job?
- comex 3y ago
  Personally, as a website visitor and occasional author, I don’t want the performance to be good enough to ‘do the job’. I want it to be as fast as possible. I want it to be instant. For that we need unbloated websites and better protocols. It’s not a competition. After all, you don’t need bloat to suffer from head-of-line blocking. You just need a few images. (Though, personally I’m a much bigger fan of HTTP/3 than HTTP/2. With a more principled solution to head-of-line blocking and proper 0-RTT, HTTP/3 makes a stronger case for why we need a new protocol than HTTP/2 did. I don’t know why HTTP/2 had to exist at all, really, when QUIC already existed by the time HTTP/2 was being standardized. Oh well.)
  - the8472 3y ago
    > It’s not a competition. But it is in the context of the 3-way tradeoff we're talking about here. complexity of the site vs. load time vs. protocol complexity > You just need a few images. On the HTTP level those can be deferred after the html/styles/js. Then you already have the content. What on your site would be "blocked" at that point? It's just images holding up each other. On the TCP level SACK and FRTO should resolve most instances of HOL after 1 RTT. It's not perfect but I suspect a lot of people experience "slowness" not because the underlying protocols are bad but because they're on old implementations. Or because they're on networks with bufferbloat. Upgrade those and we don't need those complex workarounds. As for HTTP/3... it's a mixed bag. The basic idea is great. The execution is another googleism. They didn't have the patience to get it into OSes, so now every client has to implement its own network stack which multiplies the things that need patching if something goes wrong. And it runs over UDP instead of being a different transport on the IP level like SCTP. And TLS is a good default but the whole CA-thing shouldn't have been mandatory. And header compression also seems like a cure for a disease of their own making, compare which the number of headers you need for HTTP 1.0.
bsder 3y ago
SCTP (Stream Control Transmission Protocol) or the equivalent. HTTP is really the wrong layer for things like bonding multiple connections, congestion adjustments, etc. Unfortunately, most computers only pass TCP and UDP (Windows and middleboxes). So, protocol evolution is a dead end. Thus you have to piggyback on what computers will let through--so you're stuck with creating an HTTP flavor of TCP.
- murderfs 3y ago
  QUIC (the basis for HTTP/3) is basically the spiritual successor to SCTP, except with TLS baked in, so compared with SCTP+DTLS, connection establishment requires significantly fewer roundtrips (0 round trips for session resumption, 1 roundtrip at worst, compared to 4 or so for DTLS).

jeroenhd 3y ago

HTTP/2 makes the browsing experience of high-latency connections a lot more tolerable. It also makes loading web pages in general faster. Luckily, HTTP/1.1 still works. You can always enable it in your browser configuration and in your web servers if you don't like the protocol.

tlamponi 3y ago
> HTTP/2 makes the browsing experience of high-latency connections a lot more tolerable. It also makes loading web pages in general faster. HTTP/3 does that in my experience (lots of train rides with spotty onboard Wi-Fi) quite a bit better though. As HTTP/2 is still affected by head-of-line blocking and a single packet loss can block all other streams, even if the lost packet didn't hold data for them.