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

101–110 of 142 posts

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

#101

Post by majewsky »

derefr wrote: post #57
Bjartr wrote: post #52

Earlier quoted context omitted.

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 shade…

I don't know if you're being ironic or not. We would obviously not have as many great games if only math nerds were allowed to design them.

In fact, games are one of the few areas where all those compute/storage resources in private PCs are mostly justified.

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

#102

Post by [deleted] »

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…

[deleted]

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

#103

Post by kevincox »

bawolff wrote: post #43
xeeeeeeeeeeenu wrote: post #18

Sadly, HTTP 103 hints, which provide a much saner way to preload content, are still unimplemented in all major browsers.

I'm not sure if i see much benefit over just having a header on the 200 response. I suppose if it takes a bunch of time to generate the response body, but most of the time where this sort of thing would make a difference you probably already have the response body for the main request cached on the server side.

I guess the advantage is that you can send this before you know the status code of the response? For example if you know what CSS+JS file the client will need but still need to generate the page which may 500, 404 or 302.

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

#104

Post by kevincox »

Town0 wrote: post #20

What if on link hover, some javascript code notifies the server and the server pushes the page? When the user clicks the link the page will have already been downloaded. Would that not be possible and useful?

This is a really weird system you have devised.

You are making a custom request to ask the server to push something to the browser.

Browser: POST /preload?url=/next-page Server: PUSH /next-page

Just cut out the middleman and make a regular request.

Browser: GET /next-page

Even better use browser preloading mechanisms so that the browser knows how to best prioritize them. In fact if you do it this way the browser can even start downloading subresources and prerendering the page.

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

#105

Post by techdragon »

brabel wrote: post #94
josephg wrote: post #90

Earlier quoted context omitted.

Websockets are different again from both server push and h2 streams. Server push was a feature added in http2 for populating the browser’s cache. Websockets are an http/1.1 extension for tcp-like bidirectional messaging. Server push, websockets, h2 steams and webtransport are all different things.

Don't forget Server Sent Events[1] as well, which is yet another different technology. [1] https://en.wikipedia.org/wiki/Server-sent_events

Yea but unlike http2 push, server sent events were actually useful! You could use it super easily and by holding open a connection and pushing down little json or XML payloads you could build all sorts of things easily in JavaScript. I even saw super basic chat functionally built using two Iframes a form in one and the chat log pushed back from the server as a stream of valid but open ended HTML abusing how lax the browser was about parsing missing certain closing tags at the time. SSE was and still is super easy to use and a very useful option if you can’t or don’t want to shift to web sockets.

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

#106

Post by kevincox »

seanwilson wrote: post #84
jahewson wrote: post #49

Earlier quoted context omitted.

Server push arguably doesn’t bring caching benefits if you have to push the same CSS file as part of every request for any page. With browsers already able to eagerly parse out of the head and HTTP/2 multiplexing concurrent connections you’re looking at saving a single round-trip time, once and adding bandwidth overhead to every other request for a page.

There's no solution to fix this problem with push though by changing how push works? A single round trip is significant on slow mobile connections.

No, it's not possible. It will take a round trip for the client to tell the server if an object is cached.

So you have two options:

1. Pessimistically start pushing the response, and stop if the client tells you it is already cached

2. Optimistically don't push the response until the client tells you that it doesn't have it cached.

The first option is what push does.

The second option is basically equivalent to sending a `Link: rel=preload` header.

So I guess one way to look at is that we had both choices available. But it turns out that Push wasn't used much and probably isn't the best option.

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

#107

Post by darkwater »

randomtree wrote: post #81

HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!) I use it on my pet project website, and it allows for a remarkable first page load time. And I don't have to make all these old-school tricks, like inlining CSS & JS. HTTP/2 Push allows for such a pleasant website development. You ca…

> The fact that 99% of people are too lazy to learn a new trick shouldn't really hamstring people into using 30-year old tricks to get to a decent latency!

What amazes me is that in this its own protocol. Any insights on that?

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

#108

Post by kevincox »

londons_explore wrote: post #76
francislavoie wrote: post #53

Well that sucks. Caddy has supported HTTP/2 push for a very long time (except for a few months after v2 was released since it was a total rewrite). https://caddyserver.com/docs/caddyfile/directives/push

I just finished 3 weeks implementing server push for my web app which cuts typical load times in half :-(. I guess I'll have to go back to putting all the images base64 encoded into the html :-(

Depending on how big your pages are and how fast they are generated preload is probably a better alternative.

Instead of pushing the images just set headers for the images above the fold:

    Link: ; rel=preload; as=image
The browser will then request the images it doesn't have cached already.

The advantage to this method is that the browser can look up the images in its cache first and avoid transferring unnecessary data.

The downside is that it will take at least one round trip for the browser to request them. So if your HTML is short and quick to generate the connection might go idle before your receive these requests.

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

#109

Post by shakna »

kevincox wrote: post #100
jaffathecake wrote: post #60

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 prio…

Note that this is also available via the `Link:` HTTP header. This means that you can get the preload hint to the browser quite early so there shouldn't be too much delay before it makes the request. Of course if your HTML is small it may still be slightly slower than push. However the advantage is that you don't push cached resources over and over again.

Unfortunately, as far as I'm aware, Link is only a RFC (5988, 8288), and nobody has actually implemented using it.

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

#110

Post by seanwilson »

kevincox wrote: post #106
seanwilson wrote: post #84

Earlier quoted context omitted.

There's no solution to fix this problem with push though by changing how push works? A single round trip is significant on slow mobile connections.

No, it's not possible. It will take a round trip for the client to tell the server if an object is cached. So you have two options: 1. Pessimistically start pushing the response, and stop if the client tells you it is already cached 2. Optimistically don't push the response until the client tells you that it doesn't have it cached. The first option is what push does. The second option is basically equivalent to sendi…

> It will take a round trip for the client to tell the server if an object is cached.

Why wouldn't the client be able to give the server some information about what it has cached already when it makes the initial GET request for the HTML page?

Post reply on HN