Quantcast

HTTP/2 on the Upstream

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HTTP/2 on the Upstream

Igal @ Lucee.org

According to https://www.nginx.com/blog/http2-module-nginx/#QandA nginx only supports HTTP/2 on the client side, but it is possible to configure proxy_pass to use HTTP/2.

There is a huge benefit in supporting HTTP/2 on the Upstream, as that will allow the Upstream servers to perform HTTP/2 Push (https://en.wikipedia.org/wiki/HTTP/2_Server_Push).

While nginx can not know which resources should be pushed on a dynamic page, as dynamic pages can not be simply cached across different users, the Upstream servers can know which resources should be pushed.

I really think that nginx should reconsider its position on this matter.

In the meantime, where can I find documentation on how to configure proxy_pass to use HTTP/2?

Thank you,

Igal Sapir
Lucee Core Developer
Lucee.org


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Valentin V. Bartenev-3
On Wednesday 12 April 2017 11:40:16 Igal @ Lucee.org wrote:
> According to https://www.nginx.com/blog/http2-module-nginx/#QandA nginx
> only supports HTTP/2 on the client side, but it is possible to configure
> proxy_pass to use HTTP/2.
>
> There is a huge benefit in supporting HTTP/2 on the Upstream, as that
> will allow the Upstream servers to perform HTTP/2 Push
> (https://en.wikipedia.org/wiki/HTTP/2_Server_Push).
[..]

That's not related.

Server Push doesn't require HTTP/2 from the Upstream side.  Moreover,
upstream usually don't have access to the static resources that are
served directly from nginx.

>
> While nginx can not know which resources should be pushed on a dynamic
> page, as dynamic pages can not be simply cached across different users,
> the Upstream servers can know which resources should be pushed.
>
> I really think that nginx should reconsider its position on this matter.
>
> In the meantime, where can I find documentation on how to configure
> proxy_pass to use HTTP/2?
>

There's no such documentation since HTTP/2 isn't supported by the proxy
module.

  wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Maxim Dounin
In reply to this post by Igal @ Lucee.org
Hello!

On Wed, Apr 12, 2017 at 11:40:16AM -0700, Igal @ Lucee.org wrote:

> According to https://www.nginx.com/blog/http2-module-nginx/#QandA nginx
> only supports HTTP/2 on the client side, but it is possible to configure
> proxy_pass to use HTTP/2.
>
> There is a huge benefit in supporting HTTP/2 on the Upstream, as that
> will allow the Upstream servers to perform HTTP/2 Push
> (https://en.wikipedia.org/wiki/HTTP/2_Server_Push).
>
> While nginx can not know which resources should be pushed on a dynamic
> page, as dynamic pages can not be simply cached across different users,
> the Upstream servers can know which resources should be pushed.
>
> I really think that nginx should reconsider its position on this matter.

There is nothing to stop a backend from performing a push based on
the knowledge.  It's just a matter of providing upstream servers
with a way to push resources, e.g., via something like the
X-Accel-Push header or something like this.  This doesn't need
HTTP/2 between nginx and upstream servers.

Moreover, using HTTP/2 with ability to push things will likely be
a problem here, as in most cases dynamic pages are generated
separately from static assets.  Using nginx to do the actual
push is likely to be much more optimal here.

> In the meantime, where can I find documentation on how to configure
> proxy_pass to use HTTP/2?

You can't, nginx only supports HTTP/2 on the client side.  The
actual answer was "Now you can't configure HTTP/2 with
proxy_pass...", see here:

https://youtu.be/4OiyssTW4BA?t=14m34s

The transcript needs to be fixed, thanks.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Igal @ Lucee.org

Thank you, Maxim and Valentin, for your prompt replies.  I will reply here to both so that we can maintain a single thread for this issue:

On 4/12/2017 12:57 PM, Valentin V. Bartenev wrote:

Server Push doesn't require HTTP/2 from the Upstream side.  Moreover,
upstream usually don't have access to the static resources that are
served directly from nginx.

On 4/12/2017 12:59 PM, Maxim Dounin wrote:
There is nothing to stop a backend from performing a push based on 
the knowledge.  It's just a matter of providing upstream servers 
with a way to push resources, e.g., via something like the 
X-Accel-Push header or something like this.  This doesn't need 
HTTP/2 between nginx and upstream servers.

Moreover, using HTTP/2 with ability to push things will likely be 
a problem here, as in most cases dynamic pages are generated 
separately from static assets.  Using nginx to do the actual 
push is likely to be much more optimal here.

These are both good points, but it is my understanding that the server that Pushes the resources needs to know which resources need to be pushed, is that not the case?

If my Upstream (Tomcat, for example) generates a dynamic page for the client, then it can keep track of all of the images on that page and then push them.  How can the Upstream "tell" nginx what to Push?

Please watch the clip at https://youtu.be/QpLtBftqM04?t=34m51s until about 36m12s where Simone Bordet, a Jetty developer, claims that HA Proxy is a better proxy solution than nginx because it talks HTTP/2 to the Upstream.

Also please note that the Servlet 4.0 specification plans to add a Push() API to push resources to the clients.  If nginx doesn't use HTTP/2 to talk to my Servlet engine (Tomcat, Jetty, etc.), this functionality will not be available as the Servlet engine will treat the request as an HTTP/1.

On 4/12/2017 12:59 PM, Maxim Dounin wrote:
The actual answer was "Now you can't configure HTTP/2 with 
proxy_pass...", see here:

https://youtu.be/4OiyssTW4BA?t=14m34s

The transcript needs to be fixed, thanks.

Well noted, thanks for clarifying.


Igal Sapir
Lucee Core Developer
Lucee.org


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: HTTP/2 on the Upstream

Lukas Tribus
> Please watch the clip at https://youtu.be/QpLtBftqM04?t=34m51s until
> about 36m12s where Simone Bordet, a Jetty developer, claims that
> HA Proxy is a better proxy solution than nginx because it talks
> HTTP/2 to the Upstream.

This statement is misleading.

As of now, haproxy does not support HTTP/2.

What you can do with haproxy is forward arbitrary TCP protocols, TLS
offload and NPN/ALPN negotiate whatever you like with the client. This
makes it possible to ALPN-negotiate H2 and forward whatever cleartext
TCP protocol you like. This includes HTTP/2.

Saying "Haproxy can talk HTTP/2 to the backend" is certainly wrong in
the context you are interpreting it.


The only thing missing to achieve the same thing in nginx, is afaik arbitrary
ALPN protocol negotiation with the client int the ngx_stream_ssl_module.

But that also does not make nginx HTTP/2 capable on the backend side.



Lukas
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Igal @ Lucee.org
In reply to this post by Igal @ Lucee.org
Hello,

On 4/12/2017 12:59 PM, Maxim Dounin wrote:
It's just a matter of providing upstream servers 
with a way to push resources, e.g., via something like the 
X-Accel-Push header or something like this.  This doesn't need 
HTTP/2 between nginx and upstream servers.

On 4/12/2017 2:13 PM, Igal @ Lucee.org wrote:

If my Upstream (Tomcat, for example) generates a dynamic page for the client, then it can keep track of all of the images on that page and then push them.  How can the Upstream "tell" nginx what to Push?


Upon studying HTTP/2 Push further I have learned that the way to do so is with the "Link" header, e.g.

Link: </res/css/style.css>; rel=preload; as=style, </res/min/script.js>; rel=preload; as=script

Chrome developer tools confirms that these assets are being pushed, so it's all good.

You can ignore my previous email if you read this one in time.

Thank you,

Igal Sapir
Lucee Core Developer
Lucee.org




_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Maxim Dounin
Hello!

On Wed, Apr 12, 2017 at 05:08:53PM -0700, Igal @ Lucee.org wrote:

> On 4/12/2017 12:59 PM, Maxim Dounin wrote:
> > It's just a matter of providing upstream servers
> > with a way to push resources, e.g., via something like the
> > X-Accel-Push header or something like this.  This doesn't need
> > HTTP/2 between nginx and upstream servers.
>
> On 4/12/2017 2:13 PM, Igal @ Lucee.org wrote:
> >
> > If my Upstream (Tomcat, for example) generates a dynamic page for the
> > client, then it can keep track of all of the images on that page and
> > then push them.  How can the Upstream "tell" nginx what to Push?
> >
>
> Upon studying HTTP/2 Push further I have learned that the way to do so
> is with the "Link" header, e.g.
>
> Link: </res/css/style.css>; rel=preload; as=style, </res/min/script.js>;
> rel=preload; as=script
>
> Chrome developer tools confirms that these assets are being pushed, so
> it's all good.

Note: there is no HTTP/2 push support in nginx as of now.  If you
indeed see the resources being pushed with the "Link" header,
likely you are using cloudflare and this is something Cloudflare
does for you.

Note well that pushing all of the resources used on the page
is very likely to do more harm than good, since in many cases
browsers already have static resources cached.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP/2 on the Upstream

Igal @ Lucee.org
Maxim,

On 4/13/2017 8:07 AM, Maxim Dounin wrote:
Note: there is no HTTP/2 push support in nginx as of now.  If you 
indeed see the resources being pushed with the "Link" header, 
likely you are using cloudflare and this is something Cloudflare 
does for you.
Thank you for clarifying.  That did puzzle me a bit and I thought that I simply misunderstood the Push process.

What I see in Developer Tools is that the resources that I reference in the "Link" header are downloaded first, and are downloaded faster.  The "Initiator" of those resources shows as "Other", as opposed to most other resources who show something like a URI.

Note well that pushing all of the resources used on the page 
is very likely to do more harm than good, since in many cases 
browsers already have static resources cached.
Understood.  I am only "pushing" (I guess not a real push, but a suggestion to the browser via the "Link" header) links to a few resources that are required for loading and rendering the page, like the stylesheet, javascript, and image sprite.

Thanks,

Igal Sapir
Lucee Core Developer
Lucee.org


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Loading...