Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: Intent to Remove: HTTP/2 and gQUIC server push

groups.google.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#51

Post by [deleted] »

rektide wrote: post #48
toast0 wrote: post #41

Earlier quoted context omitted.

Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look. If it's not useful, why keep support for it? As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.

It's good enough for the Web Push Protocol[1], which underpins all the notification systems on the web. This is literally how every notification message that you do not ever accept in to your browser gets delivered. This also highlights the core missing WTF, which is that the server can PUSH a resource, but there is no way for the client page to tell. 5 years latter, we've talked & talked & talked about it[2], but no…

[deleted]

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#52

Post by Bjartr »

Lorin wrote: post #39
AnIdiotOnTheNet wrote: post #11

Earlier quoted context omitted.

Things weren't just slower, they were orders of magnitude slower. It's ridiculous how we've managed to make computers ludicrously fast and the developer response has been to keep adding garbage until they are slow again.

Same with disk sizes and game file sizes, it's common to see 60gb+ installs for AAA titles.

Games specifically primarily take up space due to art assets. A high fidelity modern AAA game full of thousands of 4k+ textures, super-high-poly models, detailed animations, and hours of high quality audio is going to take up a lot of space. There are certainly optimizations to be had, but there's no way a 60GB+ game today would ever fit on, say, a DVD, at the same level of fidelity while maintaining the same player experience.

Higher compression means longer load times, so there's incentive to not compress more than absolutely necessary, and the biggest games tend to have huge worlds, which means you can't hold the whole world in memory at once. So you have to stream it in.

It's a constant balancing act between your nominal hardware target, the space the game will take up, up-front load times, and the amount of stuff that can be in a scene before the hardware can't keep up and you get model/texture streaming pop-in, stuttering, or an otherwise degraded player experience.

Perhaps in the next few years we'll see games leveraging super-resolution AI to quickly produce usably high-res textures from lower-res installed ones in storage faster than a directly compressed equivalent could be.... or games will leverage the same to take what they already ship and make it even higher detail...

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#54

Post by francislavoie »

toast0 wrote: post #41
rektide wrote: post #23

To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome…

Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look. If it's not useful, why keep support for it? As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.

Think of a framework like Laravel; you can make the Laravel app write "Link" headers for each of the JS or CSS assets declared in its views being rendered. Then, a server, say Caddy which supports push out of the box https://caddyserver.com/docs/caddyfile/directives/push will read the Link headers from the response from PHP, and push them on its behalf. Super simple to implement.

Adoption has been low because there hasn't been enough time for people to get comfortable with and switch to more modern web servers that support this type of thing, and most frameworks haven't figured out that having these sorts of features on by default could have major benefits. But it could happen.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#55

Post by saurik »

johncolanduoni wrote: post #42
peterwwillis wrote: post #32

Earlier quoted context omitted.

WebTransport is the kind of stuff that makes me lose faith in the capacity for humanity to consciously evolve. It's like your great-great-great-grandparents built a house out of brick. Each new generation there's more people. Everyone wants to live in the same house, but they can't all fit. They try to build the house larger, but it will only work so high with brick. So they start shoving tin and iron and steel into…

Or maybe, people want to do real-time networking in the browser without having to delve into the mess that is the all-singing, all-dancing WebRTC? Or they want battle tested protocol encryption libraries and flow control in their native app that can do unreliable and out of order delivery? It’s great fun to write these metaphors about HTTP/N and friends, but the last one improved network performance for mobile device…

WebRTC does not seem intrinsically more difficult to work with than WebTransport (as someone who works with WebRTC daily at super low levels and also has read about WebTransport and even watched talks about it at the standards committee and is now just annoyed as they didn't even have the decency to replace all of the WebRTC data channel use cases :/). WebRTC is actually a ridiculously easy stack: it is seriously just SCTP over DTLS (with a small bit of ICE, to maintain the connection, that isn't really required anyway). To the extent to which the code sucks--and that's frankly the core problem literally everyone has with it--it can be fixed pretty easily rather than tacking more BS on top, but somehow everyone wants to fix it with new specifications rather than improving the engineering (which I think is related to the problem the other comment brings up); even just some better build engineering would make it easier to compile (which is the #1 reason people seem to hate on WebRTC, not that it is actually *that difficult to compile... but it certainly isn't an invalid complaint).

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#56

Post by jsnell »

rektide wrote: post #23

To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome…

> But I do not see support as optional.

That's funny, given the HTTP/2 RFC does see the support as optional.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#57

Post by derefr »

Bjartr wrote: post #52
Lorin wrote: post #39

Earlier quoted context omitted.

Same with disk sizes and game file sizes, it's common to see 60gb+ installs for AAA titles.

Games specifically primarily take up space due to art assets. A high fidelity modern AAA game full of thousands of 4k+ textures, super-high-poly models, detailed animations, and hours of high quality audio is going to take up a lot of space. There are certainly optimizations to be had, but there's no way a 60GB+ game today would ever fit on, say, a DVD, at the same level of fidelity while maintaining the same player…

> but there's no way a 60GB+ game today would ever fit on, say, a DVD, at the same level of fidelity while maintaining the same player experience.

I mean, you could make a modern open-world game where all the textures are procedurally generated from set formulae, ala https://en.wikipedia.org/wiki/.kkrieger .

It might even load quickly, if the texture generation algorithms were themselves parallelized as compute shaders.

But it'd be a 100% different approach to an art pipeline, one where you can't just throw industry artists/designers at the problem of "adding content" to your world, but instead have to essentially hire mathematicians (sort of like Pixar does when they're building something new.) Costly!

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#58

Post by rektide »

jsnell wrote: post #56
rektide wrote: post #23

To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome…

> But I do not see support as optional. That's funny, given the HTTP/2 RFC does see the support as optional.

Damn james, killing me.

Philosophically, I am highly opposed to the browser opting not do support this.

Webdevs have been waiting for half a decade for some way to use PUSH in a reactive manner, as I linked further in this thread,

And instead we get this absolute unit of a response.

This is just absolutely hogwash james. I can not. Truly epic tragedy that they would do this to the web, to promising technology, after so so so little time to try to work things out, after so little support from the browser to try to make this useful.

You're not wrong but I am super disappointed to see such a lukewarm take from someone I respect & expect a far more decent viewpoint from.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#59

Post by yc12340 »

HTTP/2 server push is odd. When you can get the most benefit out of it, you usually don't care, because your resources are small and load quickly anyway. And when you care (because your resources are big don't load quickly enough), HTTP push actually hurts you, because you are pushing the same big resource on every page load.

I have tried to use it once, and the hassle of distinguishing between first time visits and repeated visits is simply not worth it. Even the hassle of using is usually not worth it in large apps — if you have time for that, it can be better spent on reducing size of assets.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#60

Post by jaffathecake »

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though....

Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher priority resources.

is much simpler to understand and use, and can be optimised by the browser.

Disclaimer: I work on the Chrome team, but I'm not on the networking team, and wasn't involved in this decision.

Post reply on HN