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

111–120 of 142 posts

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

#111

Post by breakingcups »

divbzero wrote: post #28
xeeeeeeeeeeenu wrote: post #18

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

For people like me who are unfamiliar with the proposal, 103 Early Hints [1] would work like this. Client request: GET / HTTP/1.1 Host: example.com Server response: HTTP/1.1 103 Early Hints Link: ; rel=preload; as=style Link: ; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: ; rel=preload; as=style Link: ; rel=preload; as=scr…

So at best this saves a couple of bytes until you get to the html header which can link to these resources with preload attributes anyway?

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

#112

Post by littlecranky67 »

dsign wrote: post #80

Five years ago, we built a company around HTTP/2 server push. Here is what we learned: - The interaction of HTTP/2 push with browser caches were left unspecified for the most part, and browsers implemented different ad-hoc policies. - Safari in particular was pretty bad. - Since HTTP/2 Push worked at a different layer than the rest of a web application, our offering centered around reverse-engineering traffic pattern…

This and so much this. I also worked with HTTP/2 (when it was still a SPDY draft) and came to the same conclusions: TCP peculiarities (most notably congestion control and its dynamic window scaling) mostly eradicate the benefits of HTTP/2. HTTP/1.1 was using 5-6 different TCP connections (which re-use OS level window scaling caches), while HTTP/2 you had to transfer all resources through a single TCP connection.

People often claim HTTP/2 to be superior due to its multiplexing capabilities, but always reason with the mental model of having true stream-based flows and leaving TCP completely out of the argument loop. But guess what, that model is just a model, indeed you have packet-based TCP flows that are abstracted away to mimic a continuous stream as a socket - and those matter.

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

#113

Post by kevincox »

seanwilson wrote: post #110
kevincox wrote: post #106

Earlier quoted context omitted.

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?

"It is not possible" is an overly strong claim. But the options I can think of are not great.

Uploading an entire list of cached resources probably isn't feasible (and probably not possible or a privacy concern).

You could maybe do a bloom filter but probably still have privacy concerns.

There is a solution that mostly works. You can use cookies! A simple solution might be setting a cookie for the app version when you respond. On the next request you can avoid pushing resources that haven't changed between the client's last version and the current one. Or you can even try to set cookies for each asset, however I'm not sure that is a good strategy.

But this is still not perfect. The presence of the cookie doesn't mean the resource was ever downloaded (maybe it was aborted partway though?) and things can get purged from the cache and the cookie has no way of knowing.

You can also try to do out-of-band info. For example storing in a database which resources the client has downloaded before and a bunch of heuristics to determine if they are likely still in the cache. But at the end of the day only the client knows that.

So the TL;DR is I'm not sure this is possible. You are looking for `required resources - cached resources` and since `cached resources` is sensitive and probably much larger it is way easier to do this computation on the client.

So TL;DR it might be possible but is very tricky. The current state-of-the art isn't anywhere near a perfect solution.

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

#114

Post by draw_down »

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…

Sorry we can’t boil the ocean to preserve your nice dev experience. Welcome to building for the web. Those old tricks exist for a reason: it’s not the client’s problem, it’s your problem.

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

#115

Post by Town0 »

kevincox wrote: post #104
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…

Weird? Having the html downloaded for the link you're about to click, and used by the browser if the user clicks on the link, is by far the most balanced and simple implementation of prefetching. Everything is handled by the http2 push technology. No excessive javascript nonsense, no altering the Dom, and no downloading and prerendering of everything behind a link you might not even click. Absolutely flawless and perfect enhancement to a browsing experience so long as the spec allows for this.

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

#116

Post by Town0 »

kevincox wrote: post #104
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…

Are you saying that a simple javascript http request would get cached by the browser and used if the user clicks on the link? If so my apologies. I don't make websites yet. That would indeed do the same thing that I'm proposing.

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

#117

Post by littlecranky67 »

kdunglas wrote: post #89

Server Push has a use case for web APIs. I just published a benchmark showing that under certain conditions APIs using Server Push (such as APIs implementing the https://vulcain.rocks specification) can be 4x times faster than APIs generating compound documents (GraphQL-like): https://github.com/dunglas/api-parallelism-benchmark They key point for performance is to send relations in parallel in separate HTTP streams.…

I'm sorry to disappoint you, but your benchmark methodology is flawed. You did not consider TCP congestion control/window scaling. TCP connections between to peers are "cold" (=slow) after the 3-way handshake, and it takes several roundtrips to "warm" them up (allow data to be sent at a level that saturates your bandwidth). The mistake you (and most other people performing HTTP load benchmarks) made, is that the Kernel (Linux, but also all other major OS Kernels) caches the state of the "warm" connection based on the IP adress. So basically, when you run this kind of benchmark with 1000 subsequent runs, only your first run uses a "cold" TCP connection. All other 999 runs will re-use the cached TCP congestion control send window, and start with a "hot" connection.

The bad news: For website requests Here is an analogy: If you want to compare the acceleration of 2 cars, you would have race them from point A to point B starting at a velocity of 0mph at point A, and measure the time it takes to reach to point B. In your benchmark, you basically allowed the cars to start 100 meters before point A, and will measure the time it takes between passing point A and B. Frankly, for cars, acceleration decreases with increasing velocity; for TCP its the other way around: the amount of data allowed to send on a round trip gets larger with every rountrip (usually somewhat exponentially).

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

#118

Post by earthboundkid »

techdragon wrote: post #105
brabel wrote: post #94

Earlier quoted context omitted.

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

Most applications that use WebSockets should be using SSE instead, but WS has better mindshare, and SSE doesn't work in IE11.

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

#119

Post by earthboundkid »

randomtree wrote: post #97
aitchnyu wrote: post #93

Earlier quoted context omitted.

Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.

Yep, inlining only optimizes first page load.

The whole point of this discussion is that push only optimizes the first load, and then it pessimizes all subsequent loads. That's why no one adopted it.

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

#120

Post by earthboundkid »

divbzero wrote: post #24
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?

There are libraries [1] that achieve what you describe. [1]: http://instantclick.io/ "InstantClick"

Yes, TurboLinks is another library that does this: https://github.com/turbolinks/turbolinks
Post reply on HN