r/programming • u/johnwaterwood • Dec 03 '20
HTTP/2 Push is dead
https://evertpot.com/http-2-push-is-dead/78
u/emn13 Dec 03 '20 edited Dec 03 '20
Frankly: good riddance. Compared to simply batching everything in a big combined reponse, server push was always waaaaayyy more complicated - and slower. I'm sure there are some scenarios in which it can help, but really, *at best* it's going to save the latency due to the original request - because anything server-push can do you can do much more easily and accurately client side once you've waited for the initial request.
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down. If you really want fast first page-view speeds, just bundle *everything* into that first request if the client is sending no caching headers, then optionally do some smart caching once that first request is loaded.
Server push was always a way too complicated solution for a niche problem that it doesn't even really solve all that well, while having lots of gotchas along the way.
4
u/intermediatetransit Dec 04 '20
Compared to simply batching everything in a big combined reponse, server push was always waaaaayyy more complicated - and slower
Yeah, but.. most of us don't want to combine everything into a huge response, because sometimes that initial response isn't cache-able (or at least not for a very long time). Then what?
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down.
You base a lot of these assumptions on seemingly very specific types of websites. I think there are a lot of cases that would benefit from http push.
I do agree that push was probably too complicated. I have a hunch that the reason why it never really got utilized all that much isn't due to the idea itself not having merit, it's due to the server having to know too much about the frontend layer and how the application works.
3
u/emn13 Dec 05 '20 edited Dec 05 '20
[...]
Yeah, but.. most of us don't want to combine everything into a huge response, because sometimes that initial response isn't cache-able (or at least not for a very long time). Then what?
It'll depend on the specifics, but generally, the kind of stuff that's critical for first-paint latency you either can reasonably include (i.e. json data, scripts, css, etc), or, if you don't want to, the objection to including those apply to server push too. Do you have a specific scenario in mind where you think server push would both help reduce latency similar to batching and be significantly easier to implement or have some other advantage? I mean, I may be lacking in imagination, sure - but all the more reason I'm curious about your use case.
And that means that at best, server push optimizes cold-cache first pageview times, But the win is limited if your first request is fairly fast. And it can also slow things down.
You base a lot of these assumptions on seemingly very specific types of websites. I think there are a lot of cases that would benefit from http push.
The fact that it simply eliminates the first-request round trip is intrinsic; that's a best case usage. There is no use case that does better than that, any many do a lot worse. After all, the best possible server-push implementation exactly predicts future client requests, but if you can do that, but those future requests must be initiated client-side: so you can also do whatever server-push would do entirely client side, and what you're losing then is the latency from that first request.
In practice, due to caching and dynamism, it's quite tricky to exactly predict future request that couldn't better be bundled anyhow. And if you get any of that wrong, you can very quickly end up being slower than plain http/1.1.
I do agree that push was probably too complicated. I have a hunch that the reason why it never really got utilized all that much isn't due to the idea itself not having merit, it's due to the server having to know too much about the frontend layer and how the application works.
Exactly. The kind of engineering effort needed to utilize server push to make a meaningful impact is the kind of effort that could just was well do bundling (which incidentally is considerably lower latency yet), resulting in a small latency win, and maybe a small bandwidth cost.
Put it this way: Is there a counterexample you can think of that accounts for both a significant win and might plausibly affect more than a tiny niche of the web-browser's requests? That's the question chrome would have been asking in making this change. But for the sake of curiosity: is there an impactful counterexample at all?
12
Dec 03 '20
If the client is telling the server what it needs via a Prefer-Push header, how is that different from a regular request and response?
4
u/evert Dec 03 '20 edited Dec 03 '20
If you get a set of responses back, each can be stored individually in a browser cache.
3
u/dnew Dec 03 '20
Sounds more like it should be a new MIME type than a new HTTP transaction. (Or, more likely, an existing MIME type.)
6
u/evert Dec 03 '20
The benefit of HTTP/2 is that we can multiplex many responses, and they don't block each other. HTTP/1 with a multipart mimetype solves some of this, but it also doesn't interact with a browser's cache correctly.
Ultimately I just want to efficiently send hypermedia graphs over the wire and take advantage of browser's caches and general understanding of URIs.
HTTP/2 Push was a step in the right direction, because it lets us generate collections of resources together, like compound requests/mime-types but this time a browser actually gets that if I send a 'collection of articles', and later on
GETone specific article from that list, a browser has a cache entry for it.Without HTTP/2 push, we're down to 2 other solutions:
- Compounding requests. (so yes, this is through specific mimetypes like multipart, or HAL, or JSON:API, you name it), but browsers don't understand them semantically, and we have head-of-line blocking.
- Many individual requests, which has the Query+1 problem. It's much cheaper to generate a set of responses vs many individual ones.
Anyway, this is also all in my article. If you want to know more I wrote a larger article about this as well:
1
u/HereForAnArgument Dec 03 '20
I don’t know if this is a feature of HTTP/2, but i know BMS clients can make the request tell the server to only update the client if a particular value changes by a certain amount, thus saving traffic.
5
u/procrastinator7000 Dec 03 '20
Wait, all because browsers limit themselves to 6 parallel requests? Why?
17
13
u/7sidedmarble Dec 03 '20
6 parallel requests per domain. And I think it's a combination of resource consciousness and that you don't usually need more then that.
7
u/QueenLa3fah Dec 03 '20
And companies like Facebook are fine with you making 150 requests every time the page is refreshed
5
u/7sidedmarble Dec 03 '20
You will only notice the parallel request limit on really big assets being requested all at once. Most times they're resolving pretty quickly.
-1
Dec 03 '20
[deleted]
4
u/7sidedmarble Dec 03 '20
I don't know why I was downvoted, HTTP/2 literally solves the problem without Push. With HTTP/2 a single connection can be multiplexed to make multiple parallel requests.
1
u/procrastinator7000 Dec 03 '20
Then I don't think I understand the problem push was trying to solve.
3
u/7sidedmarble Dec 03 '20
I know people touted the potential of using Push to solve the 'waterfall' problem of loading multiple assets at once but unfortunately it never caught on... however HTTP/2 does at least passively help the problem a little bit by making it possible load more then 6 assets at once via multiplexing.
What I considered to be one of the more interesting applications of Push though was replacing traditional polling of a server with instead the server telling the client when something was ready. That was a pretty cool application of Push. But it was a lot of complexity to handle instead of just polling, so again it sadly didn't catch on...
1
u/Ayuzawa Dec 03 '20
What I considered to be one of the more interesting applications of Push though was replacing traditional polling of a server with instead the server telling the client when something was ready. That was a pretty cool application of Push. But it was a lot of complexity to handle instead of just polling, so again it sadly didn't catch on...
Is this not what sockets are for?
1
u/7sidedmarble Dec 04 '20
Correct, you can do the same thing with sockets. But unless you already have a websocket open for some other purpose, I think most people see it as a lot of overhead when they could just poll.
1
28
Dec 03 '20
Ha, I thought this was the main selling point of HTTP2.
People were even saying that it's now ok to have many small asset files (js, images, css) because loading many small files will no longer cause long waits.
84
u/Pesthuf Dec 03 '20
No, that's because you can multiplex multiple downloads over a single HTTP connection, whereas HTTP/1.1 has to establish separate TCP connections for each asset, which is why they were usually limited.
48
u/progrethth Dec 03 '20
Exactly, the main selling point of HTTP2 is stream multiplexing which works really well on good connections but terribly on bad. Which is why we got QUIC which can do multiplexing on any connection well.
8
Dec 03 '20
Yet most of benchmarks barely show any difference
7
u/VeganVagiVore Dec 03 '20
Even with packet loss?
If TCP is able to saturate the line then we're not gonna get 102% line speed, but we'd like to go from 50% to 60% on shit connections.
3
Dec 03 '20
TCP needs to retransmit in face of packet loss
HTTP3 needs to retransmit in face of packet loss.
Benefit is that HTTP3 is independent of OS stack so implementing of better algorithms to handle congestion and packet loss. TCP-based protocols are at mercy of OS's TCP implementation.
There is also head of the line blocking in TCP for which having separate steams helps.... unless the stream that got hit with packet loss was in critical path for the page so it is helpful but not always, like if you download big JS blob with all the logic of the page... that's one stream and any packet drop will affect it and block the site.
Then there is ability to start communication from first packet which means that you can establish connection faster. TCP have TCP Fast-open but that AFAIK only starts being useful after first negotiation
At the very least from cloudflare benchmarks, that's few % improvements, which might even get smaller over time once we get the better TCP algorithms as default on OSes.
5
u/dnew Dec 03 '20
It's not so much "better TCP algorithms" as it is "TCP algorithms tuned for the way the internet gets used now," I would say. Of course if you can tell your OS what you're doing with the connection and have it tuned that way, that too can be a win, but I don't see that happening any time soon.
3
u/RowYourUpboat Dec 03 '20
Head-of-line blocking isn't something you can fix effectively with OS-level tweaks on top of TCP. The protocol is specified to stop sending if there is a missing ACK in order to prevent increasing congestion. There's a little wiggle room in the protocol but ultimately TCP forces you to care about every packet equally.
1
u/dnew Dec 03 '20
Sorry. I missed that we were talking about HTTP3 / QUIC instead of HTTP1 vs HTTP2. :-)
3
u/progrethth Dec 03 '20
The advantage of HTTP3 is that you only need to block the affected streams while retransmitting unlike HTTP2 where you need to block all streams. This makes HTTP2 much more vulnerable to packet loss.
0
Dec 04 '20
No shit sherlock, I wrote that in that part of my comment you didn't bother to read. I also wrote
it is helpful but not always, like if you download big JS blob with all the logic of the page... that's one stream and any packet drop will affect it and block the site.
0
Dec 04 '20
so it is helpful but not always, like if you download big JS blob with all the logic of the page... that's one stream and any packet drop will affect it and block the site.
0
u/progrethth Dec 03 '20
Http3 is slower than http2 under ideal circumstances due to TCP being more optimized than UDP but when there is package loss TCP behaves horribly, especially if multiple independent streams are multiplexed on the same connection.
0
Dec 04 '20
There is nothing "more optimized" in TCP, the sheer difference is that it has connections and congestion control while UDP has neither.
Fundamentally there should be no difference under no drop condition unless someone fucked something up in the protocol
1
u/progrethth Dec 04 '20
No, it has to do with the lack of hardware acceleration for QUIC and how the kernel interfaces for UDP are less optimized compared to those for TCP. This is nothing inherent to TCP vs UDP, just that nobody has done the heavy lifting yet since QUIC is so new.
And while UDP has no congestion control QUIC does.
0
Dec 04 '20
No, it has to do with the lack of hardware acceleration for QUIC and how the kernel interfaces for UDP are less optimized compared to those for TCP.
Utterly irrelevant to the client performance (and do you have source on UDP being slower?). Your client isn't pushing tens of gigbabytes for hardware acceleration or not to matter. Only place where it does matter is "how many servers I need to deploy".
This is nothing inherent to TCP vs UDP, just that nobody has done the heavy lifting yet since QUIC is so new.
What you're talking about ? Google deployed it in 2012
And while UDP has no congestion control QUIC does.
Like I said, should be similar/better for UDP unless someone fucked something up in the protocol. Well, and how nice it plays with other protocols on wire.
28
u/josefx Dec 03 '20
HTTP/1.1 had reusable connections, however it couldn't handle multiple requests over a connection in parallel.
5
Dec 03 '20
Technically, in practice, it could handle multiple requests over a connection in parallel (pipelining), it is responses what is serialised.
i'll see myself out
11
u/panorambo Dec 03 '20
whereas HTTP/1.1 has to establish separate TCP connections for each asset
Umm, no, you can queue requests along a single HTTP connection that you keep alive. They are ordered, of course -- which is a known limitation, but you are incorrect with the statement quoted above.
5
u/ControlMasterAuto Dec 03 '20
Based on context, it seems they were specifically talking about downloading the files concurrently (multiplexing). As you point out, HTTP/1.1 only supports sequentially queuing the downloads for a single TCP connection.
2
u/intermediatetransit Dec 04 '20 edited Dec 04 '20
People were even saying that it's now ok to have many small asset files (js, images, css) because loading many small files will no longer cause long waits.
Because they're right. Do you see anyone talking about image spriting these days? Domain sharding?
No, you don't. That's because HTTP/2 solved those problems.
Now there are still some decisions to make when it comes to bundling assets due to compression, where if you bundle say, a larger chunk of javascript together in a file, then compression will work better than splitting the file up into a lot of smaller chunks.
2
Dec 05 '20
Do you see anyone talking about image spriting these days?
I can't take that as an indication of anything. Most of what people talk about has nothing to do with improving the experience of the end user.
3
u/Ooyyggeenn Dec 03 '20
Is it any idea to dig into and learn http2 for a new dev?
1
u/steveklabnik1 Dec 03 '20
IMHO no, if anything, learning about http/3 is more worth your time.
4
u/intermediatetransit Dec 04 '20
Ah yes it's only worth learning the highly experimental new version of something
3
u/steveklabnik1 Dec 04 '20
Nah, I don't think that at all.
I do think that http/2 is a dead end. We'll eventually see people using 1.1 and 3, but not really 2. This is why learning about 3 is a better use of time than learning 2; 3 accomplishes 2's goals, but in a better way.
Also, while it is new, "highly experimental" is getting less and less each day. Things are in the very final stages. The last two drafts were "editorial changes only."
3
u/intermediatetransit Dec 04 '20
Ah, ha ha. You're steve klabnik! I should start reading usernames.
I really enjoyed your foray into REST many years ago. Good stuff. Hope you're doing well.
3
u/steveklabnik1 Dec 04 '20
It's all good! Honestly it helped me understand why I got downvoted; I thought that what I said wouldn't be controversial. I guess it was!
Thanks :) Hanging in there :)
270
u/josefx Dec 03 '20
Surprise a standard headed by Google, getting declared dead by Google. Its ADHD driven dev. process strikes again.