<div dir="ltr">Hi Valentin:<div><br></div><div>Are you talking about the same "push" as I am? HTTP/2, or at least SPDY, had the ability to *push* content like CSS in advance of the request, pushing content into the browsers cache *before* it needs it. I'm not talking about long polling or other technology. I've only read about this technology, though. I've never seen it implemented in practice. And for prioritization, it's about choosing to send more important content before less important content. I don't think you are correct in terms of future potential here. But, it's very likely that you are correct in terms of *current* potential. That is, I think this technology is too new for people to understand it and really think about how to leverage it. It sounds like you don't even know about it...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 10:45 AM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday 18 March 2015 04:32:55 Mark Mielke wrote:<br>
> I think the ability to "push" content,and prioritize requests are examples<br>
<span class="">> of capabilities that might require intelligence upstream, and therefore a<br>
> requirement to proxy HTTP/2 upstream.<br>
<br>
</span>"Server push" doesn't require HTTP/2 for upstream connection.<br>
<br>
Upstreams don't request content, instead they return it, so there's nothing<br>
to prioritize from the upstream point of view.<br>
<span class=""><br>
<br>
> However, I expect much of this is<br>
> still theoretical at this point, and until there are actually upstream<br>
> servers that are providing effective capabilities here, HTTP/1.1 will<br>
> perform just as good as HTTP/2?<br>
<br>
</span>HTTP/1.1 actually can perform better than HTTP/2.<br>
<br>
HTTP/1.1 has less overhead by default (since it doesn't introduce another<br>
framing layer and another flow control over TCP), and it also uses more<br>
connections, which means more TCP window, more socket buffers and less<br>
impact from packet loss.<br>
<br>
There's almost no reason for HTTP/2 to perform better unless you're doing<br>
many handshakes over high latency network or sending hundreds of kilobytes<br>
of headers.<br>
<br>
  wbr, Valentin V. Bartenev<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br></div>
</div>