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

Nginx-1.14.0 stable version has been released

nginx.org

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Nginx-1.14.0 stable version has been released

#41

Post by zzzcpan »

niftich wrote: post #34
zzzcpan wrote: post #24

Earlier quoted context omitted.

Pushes are probably best implemented in a caching layer, not manually describing what to push. A web server should not just cache resources, but also learn what kind of resources are often requested with each page and just push those next time someone makes a request. And some sort of push prediction policy should be configurable.

It's not sensible for pushes to be implemented in a caching layer, because pushes are effectively the manual overrides to the User-Agent's own caching; conversely, the User-Agent's cache is perfectly appropriate as a cache, and doesn't need HTTP/2 Push to work. HTTP/2 Push is effectively the server declaring they know better, so they prime the UA's cache to avoid additional roundtrips. Nginx does have a module [1] an…

If you can predict with high enough accuracy what resource is going to be requested by the client next, I don't see why pushing it would be a bad idea. Speculation is how we hide latency after all.

And if you think about it, static pushes in general have very limited usefulness, almost non existent. Imagine when some url becomes popular and almost all of the requests to that url come from people who never visited the website before. It would make sense for a web server to learn what kind of resources clients request with that url and start pushing those resources to people ahead of time.

Re: Nginx-1.14.0 stable version has been released

#42

Post by rakoo »

tekromancr wrote: post #36
Wingwing wrote: post #31

Earlier quoted context omitted.

That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?

The client will kill the connection if it has the file cached, sooooo, not much.

It's 2G. By the time the cancel is received by the server, the server will have sent the resource, the bytes will have traveled and the user will be billed.

Re: Nginx-1.14.0 stable version has been released

#43

Post by zedpm »

The mirror module is exciting. Sometimes it's nice to have no-consequences testing of production traffic in a staging environment. Unless you have something like Envoy and its shadowing functionality [0] to handle the mirroring, you end up using a tool like GoReplay [1] to duplicate the traffic to another environment and ignore the responses. This looks like a cleaner and simpler way to accomplish the task.

[0] https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/ro... [1] https://goreplay.org/

Re: Nginx-1.14.0 stable version has been released

#44

Post by pas »

zzzcpan wrote: post #41
niftich wrote: post #34

Earlier quoted context omitted.

It's not sensible for pushes to be implemented in a caching layer, because pushes are effectively the manual overrides to the User-Agent's own caching; conversely, the User-Agent's cache is perfectly appropriate as a cache, and doesn't need HTTP/2 Push to work. HTTP/2 Push is effectively the server declaring they know better, so they prime the UA's cache to avoid additional roundtrips. Nginx does have a module [1] an…

If you can predict with high enough accuracy what resource is going to be requested by the client next, I don't see why pushing it would be a bad idea. Speculation is how we hide latency after all. And if you think about it, static pushes in general have very limited usefulness, almost non existent. Imagine when some url becomes popular and almost all of the requests to that url come from people who never visited the…

For that it's easier to parse the pushed content. If it's HTML, then catch stlyesheets, JS, and some other static things. It doesn't have to be flawless, after all it's just a speed-up. (And if you want a speed up write nice markup.)

Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's not new, but still needs to push things because it's too old, and since then that particular page's background changed, etc.).

And in case of an Angular/React/SPA thing, then the "bundler/compiler" should create a list of things to push for various URLs. Or the Angular/React team should talk with the Nginx team to figure out how to speed up things. (In case of SSR - server side rendering - the NodeJS server can emit the necessary Link headers, for example.)

Re: Nginx-1.14.0 stable version has been released

#46

Post by zzzcpan »

pas wrote: post #44
zzzcpan wrote: post #41

Earlier quoted context omitted.

If you can predict with high enough accuracy what resource is going to be requested by the client next, I don't see why pushing it would be a bad idea. Speculation is how we hide latency after all. And if you think about it, static pushes in general have very limited usefulness, almost non existent. Imagine when some url becomes popular and almost all of the requests to that url come from people who never visited the…

For that it's easier to parse the pushed content. If it's HTML, then catch stlyesheets, JS, and some other static things. It doesn't have to be flawless, after all it's just a speed-up. (And if you want a speed up write nice markup.) Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's no…

Common, how parsing things is easier, than gathering some very basic stats?

Re: Nginx-1.14.0 stable version has been released

#47

Post by Twirrim »

Wingwing wrote: post #31
untog wrote: post #28

Earlier quoted context omitted.

The client can cancel the push. But yes, there's definitely wasted bandwidth here - the reason to still do it is that connections are now fast enough that the extra download time is small compared to the time required to parse HTML/send new HTTP request/receive response/render CSS.

That's a very Silicon Valley way to look at things. How much does that bandwidth cost on dial-up or 2G?

A copy of the spec can be found here:

https://http2.github.io/http2-spec/#PushResources

There's a few interesting things here that I want to point out: * "A client can request that server push be disabled" This is part an explicit parameter in the client request to a server for anything, https://http2.github.io/http2-spec/#SETTINGS_ENABLE_PUSH.

* "Pushed responses that are cacheable (see [RFC7234], Section 3) can be stored by the client, if it implements an HTTP cache. Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present ([RFC7234], Section 5.2.2)) while the stream identified by the promised stream ID is still open"

Note that pushed content first starts with a PUSH_PROMISE message to the client, which the client can decide on its own volition to reject. Note the spec for a PUSH_PROMISE frame is here, https://http2.github.io/http2-spec/#PUSH_PROMISE and it's extremely small. Even on 2G or dial-up it's by design negligible.

* "Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the promised response until after the promised stream has closed.

If the client determines, for any reason, that it does not wish to receive the pushed response from the server or if the server takes too long to begin sending the promised response, the client can send a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code and referencing the pushed stream's identifier. "

Wittingly or otherwise, your message comes across as "everyone on the standards boards are idiots, don't think about anything beyond the valley, and I'm smarter than they are." That's beyond ridiculous. The standard was designed by subject matter experts from right across the world, with interests in web technologies across all sorts of markets, including the developing nations where every single byte is important. There's a lot that has been designed in to the HTTP 2.0 specification to account for that and to explicitly try to improve end user experience under those conditions.

Re: Nginx-1.14.0 stable version has been released

#48

Post by untog »

rakoo wrote: post #42
tekromancr wrote: post #36

Earlier quoted context omitted.

The client will kill the connection if it has the file cached, sooooo, not much.

It's 2G. By the time the cancel is received by the server, the server will have sent the resource, the bytes will have traveled and the user will be billed.

The client can disable push, so if it's on 2G, it can avoid this issue entirely.

Re: Nginx-1.14.0 stable version has been released

#49

Post by Twirrim »

rakoo wrote: post #42
tekromancr wrote: post #36

Earlier quoted context omitted.

The client will kill the connection if it has the file cached, sooooo, not much.

It's 2G. By the time the cancel is received by the server, the server will have sent the resource, the bytes will have traveled and the user will be billed.

First you get a PUSH_PROMISE request that is a single frame. It's tiny.

That tells the client what the server wants to send.

The client can respond with a an RST_STREAM frame https://http2.github.io/http2-spec/#RST_STREAM Again, that's a single frame.

By design it's meant to be extremely small and quick even on high latency, and/or low bandwidth connections.

Re: Nginx-1.14.0 stable version has been released

#50

Post by pas »

zzzcpan wrote: post #46
pas wrote: post #44

Earlier quoted context omitted.

For that it's easier to parse the pushed content. If it's HTML, then catch stlyesheets, JS, and some other static things. It doesn't have to be flawless, after all it's just a speed-up. (And if you want a speed up write nice markup.) Similarly, it should be the backend behind the reverse-proxy that knows what's the page that has been just rendered, and knows about the user's session (is it brand new, or maybe it's no…

Common, how parsing things is easier, than gathering some very basic stats?

Gathering stats requires keeping them somewhere. Making inferences. Documenting the inference engine. Explaining the magic to users. Sounds a lot more complicated than explaining that what HTML tags will be parsed.

Proxies are already complicated as is. Caching proxies more so. (Think of how Varnish has a - probably Turing complete - DSL to decide what to serve and/or cache and when, and how.)

Post reply on HN