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

Nginx HTTP/2 server push support

hg.nginx.org

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Nginx HTTP/2 server push support

#41

Post by pas »

donatj wrote: post #35
vertex-four wrote: post #26

Earlier quoted context omitted.

I think (not sure if this has been agreed as best practice) that you can use cookies to decide which content to push. This should work in most cases - set a cookie that lasts as long as your users' cache, and don't do server push if that cookie exists.

Ugh. That would work, but it’s such a hack. There should be a mechanism specifically for this. Is there’s no other good way?

The problem is cache coherency, also known as consistency protocols. It's The Hard Problem of computing science, because you have to synchronize state. You have to use information to tell the other party what do you have, and that can be done with a HTTP header, like the Cookie.

Re: Nginx HTTP/2 server push support

#43

Post by dalore »

TheAceOfHearts wrote: post #21

Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…

Good questions. I was looking at H2O and they solve this using what they call http-casper: https://h2o.examp1e.net/configure/http2_directives.html#http...

> When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possession of the content. The fingerprint is stored in a cookie...

That sounds interesting solution.

Actually it looks like this tool along with nginx pagespeed would work well and require no changing in build tools.

Nginx pagespeed supports parsing and optimizing the html (and linked resources), including inserting prelink headers. Which will now get pushed. It requires no change in build process.

> Won't a gzipped bundle typically produce a smaller payload?

With http2 it's better to unbundle these days as the best reason for bundling was to not create new tcp connections which require ramp up time to be useful. Now with http2 the same tcp connection is used but multiplexed. So the main reason for bundling goes away. As to it producing smaller payloads, it might be the case but not that much smaller that it's worth it since it's the same tcp connection. Better to have it in unbundled then it gets parsed and processed in chunked streams of files. The client is able to use and process the files as they come in without having to load the whole bundle and process at once. Making the site a bit more responsive.

Re: Nginx HTTP/2 server push support

#44

Post by drcongo »

pgjones wrote: post #27

Server push in Python https://pgjones.gitlab.io/quart/serving_http2.html#server-pu... (I am the Quart author, thought this would be interesting and relevant).

As someone who loves Flask and finds Django infuriating, I've been keeping an eye on Quart, it looks really interesting.

Re: Nginx HTTP/2 server push support

#47

Post by niftich »

As more software is adding support for HTTP/2 server push, I hope they'll start supporting a higher-level, implementation-agnostic, declarative way of specifying resources to push, which operates at a layer higher than server config directives.

Google has a dead-simple JSON format [1] for this from 2015.

[1] https://github.com/GoogleChromeLabs/http2-push-manifest

Re: Nginx HTTP/2 server push support

#48

Post by theandrewbailey »

TheAceOfHearts wrote: post #21

Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…

I upgraded my blog's server a few months ago and got HTTP/2 automatically. I didn't change any architecture (still one CSS and one JS files, no pushing), and it definitely feels faster, because (I think) of the multiplexing and the TCP and TLS overheads on the extra connections are gone.

I'm skeptical of not bundling resources "because HTTP/2". I think it's still a good idea to keep good HTTP/1 performance for the 10%-20% of traffic that doesn't support HTTP/2. Even when everyone supports HTTP/2, if you're loading a bunch of other data from the same domain (like images), I'm doubtful that the improvement from unbundling resources would be noticeable.

Re: Nginx HTTP/2 server push support

#49

Post by josephscott »

dalore wrote: post #43
TheAceOfHearts wrote: post #21

Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…

Good questions. I was looking at H2O and they solve this using what they call http-casper: https://h2o.examp1e.net/configure/http2_directives.html#http... > When enabled, H2O maintains a fingerprint of the web browser cache, and cancels server-push suggested by the handlers if the client is known to be in possession of the content. The fingerprint is stored in a cookie... That sounds interesting solution. Actually it…

That is the theory. The real world however can be very messy. More than two years ago Khan Academy measured how this would work for them - http://engineering.khanacademy.org/posts/js-packaging-http2.... - here was their summary:

> The reality is not so rosy. Due to degraded compression performance, the size of the data download with individual source files ends up being higher than with packages, despite having achieved 'no wasted bytes'. Likewise, the promised download efficiency has yet to show up in the wild, at least for us. It seems that, for the moment at least, JavaScript packaging is here to stay.

My personal experience has been you have to confirm the theory of how HTTP/2 related changes will perform with actual measurements. I've seen some pages get faster in HTTP/2 by no longer bundling, and in other cases seen then become slower. So far the only way to know for sure is to measure the result.

Re: Nginx HTTP/2 server push support

#50

Post by sebastiaand »

donatj wrote: post #35
vertex-four wrote: post #26

Earlier quoted context omitted.

I think (not sure if this has been agreed as best practice) that you can use cookies to decide which content to push. This should work in most cases - set a cookie that lasts as long as your users' cache, and don't do server push if that cookie exists.

Ugh. That would work, but it’s such a hack. There should be a mechanism specifically for this. Is there’s no other good way?

There is an experimental RFC currently being discussed: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-di... The technique is derived from the H2O Casper work (and by the same author).

I have a Javascript service worker implementation here: https://www.npmjs.com/package/cache-digest-immutable

Note: This is still based on a Golomb-coded set (GCS). Current proposal under discussion is to use a Cuckoo filter. Takes slightly more bandwidth but allows removal when browser caches evict items.

Post reply on HN