Welcome! Log In Create A New Profile

Advanced

HTTP/2 on the Upstream

Posted by Igal @ Lucee.org 
Igal @ Lucee.org
HTTP/2 on the Upstream
April 12, 2017 08:50PM
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 http://lucee.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Valentin V. Bartenev
Re: HTTP/2 on the Upstream
April 12, 2017 10:00PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Maxim Dounin
Re: HTTP/2 on the Upstream
April 12, 2017 10:10PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Igal @ Lucee.org
Re: HTTP/2 on the Upstream
April 12, 2017 11:20PM
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 http://lucee.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Lukas Tribus
AW: HTTP/2 on the Upstream
April 13, 2017 01:20AM
> 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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Igal @ Lucee.org
Re: HTTP/2 on the Upstream
April 13, 2017 02:20AM
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 http://lucee.org/



_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Maxim Dounin
Re: HTTP/2 on the Upstream
April 13, 2017 05:10PM
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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Igal @ Lucee.org
Re: HTTP/2 on the Upstream
April 13, 2017 05:20PM
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 http://lucee.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login